Merge pull request #32118 from nate-double-u/merged-main-dev-1.24

Merged main into dev-1.24
2022-03-16 08:26:12 +00:00
parent 7201a0b2a4 5a0f2583c6
commit c0aed1902b
155 changed files with 12643 additions and 2225 deletions
@@ -153,6 +153,7 @@ aliases:
    # dchen1107
    # haibinxie
    # hanjiayao
+    - howieyuen
    # lichuqiang
    - SataQiu
    - tanjunchen
@@ -15,7 +15,7 @@ Diese Seite ist eine Übersicht über Kubernetes.

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

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

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

@@ -22,30 +22,30 @@ Da Mitwirkende nicht ihren eigenen Pull Request freigeben können, brauchst du m

 Alle Lokalisierungsteams müssen sich mit ihren eigenen Ressourcen selbst tragen. Die Kubernetes-Website ist gerne bereit, deine Arbeit zu beherbergen, aber es liegt an dir, sie zu übersetzen.

-### Finden deinen Zwei-Buchstaben-Sprachcode
+### Ermittlung deines Zwei-Buchstaben-Sprachcodes

 Rufe den [ISO 639-1 Standard](https://www.loc.gov/standards/iso639-2/php/code_list.php) auf und finde deinen Zwei-Buchstaben-Ländercode zur Lokalisierung. Zum Beispiel ist der Zwei-Buchstaben-Code für Korea `ko`.

-### Duplizieren und klonen des Repositories
+### Duplizieren und Klonen des Repositories

-Als erstes [erstells du dir deine eigenes Duplikat](/docs/contribute/new-content/new-content/#fork-the-repo) vom [kubernetes/website] Repository.
+Als erstes [erstellst du dir deine eigenes Duplikat](/docs/contribute/new-content/new-content/#fork-the-repo) vom [kubernetes/website] Repository.

-Dann klonst du das Duplikat und `cd` hinein:
+Dann klonst du das Duplikat und wechselst in das neu erstellte Verzeichnis:

 ```shell
 git clone https://github.com/<username>/website
 cd website
 ```

-### Eröffne ein Pull Request
+### Eröffnen eines Pull Requests

 Als nächstes [eröffnest du einen Pull Request](/docs/contribute/new-content/open-a-pr/#open-a-pr) (PR) um eine Lokalisierung zum `kubernetes/website` Repository hinzuzufügen.

-Der PR muss die [minimalen Inhaltsanforderungen](#mindestanforderungen) erfüllen bevor dieser genehmigt werden kann.
+Der PR muss die [minimalen Inhaltsanforderungen](#mindestanforderungen) erfüllen, bevor dieser genehmigt werden kann.

-Wie der PR für eine neue Lokalisierung aussieht kannst du dir an dem PR für die [Französische Dokumentation](https://github.com/kubernetes/website/pull/12548) ansehen.
+Wie der PR für eine neue Lokalisierung aussieht, kannst du dir an dem PR für die [Französische Dokumentation](https://github.com/kubernetes/website/pull/12548) ansehen.

-### Trete der Kubernetes GitHub Organisation bei
+### Tritt der Kubernetes GitHub Organisation bei

 Sobald du eine Lokalisierungs-PR eröffnet hast, kannst du Mitglied der Kubernetes GitHub Organisation werden. Jede Person im Team muss einen eigenen [Antrag auf Mitgliedschaft in der Organisation](https://github.com/kubernetes/org/issues/new/choose) im `kubernetes/org`-Repository erstellen.

@@ -96,7 +96,7 @@ weight = 3

 Wenn du deinem Block einen Parameter `weight` zuweist, suche den Sprachblock mit dem höchsten Gewicht und addiere 1 zu diesem Wert.

-Weitere Informationen zu Hugos Multilingualen Support findest du unter "[Multilingual Mode](https://gohugo.io/content-management/multilingual/)" auf in der Hugo Dokumentation.
+Weitere Informationen zu Hugos multilingualem Support findest du unter "[Multilingual Mode](https://gohugo.io/content-management/multilingual/)" auf in der Hugo Dokumentation.

 ### Neuen Lokalisierungsordner erstellen

@@ -213,7 +213,7 @@ Die neueste Version ist {{< latest-version >}}, so dass der neueste Versionszwei

 ### Seitenverlinkung in der Internationalisierung

-Lokalisierungen müssen den Inhalt von [`i18n/de.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) in einer neuen sprachspezifischen Datei enthalten. Als Beispiel: `i18n/de.toml`.
+Lokalisierungen müssen den Inhalt von [`i18n/de.toml`](https://github.com/kubernetes/website/blob/main/i18n/en.toml) in einer neuen sprachspezifischen Datei enthalten. Als Beispiel: `i18n/de.toml`.

 Füge eine neue Lokalisierungsdatei zu `i18n/` hinzu. Zum Beispiel mit Deutsch (`de`):

@@ -278,7 +278,7 @@ Die Teams müssen den lokalisierten Inhalt in demselben Versionszweig zusammenf

 Ein Genehmiger muss einen Entwicklungszweig aufrechterhalten, indem er seinen Quellzweig auf dem aktuellen Stand hält und Merge-Konflikte auflöst. Je länger ein Entwicklungszweig geöffnet bleibt, desto mehr Wartung erfordert er in der Regel. Ziehe in Betracht, regelmäßig Entwicklungszweige zusammenzuführen und neue zu eröffnen, anstatt einen extrem lang laufenden Entwicklungszweig zu unterhalten.

-Zu Beginn jedes Team-Meilensteins ist es hilfreich, ein Problem [Vergleich der Upstream-Änderungen](https://github.com/kubernetes/website/blob/master/scripts/upstream_changes.py) zwischen dem vorherigen Entwicklungszweig und dem aktuellen Entwicklungszweig zu öffnen.
+Zu Beginn jedes Team-Meilensteins ist es hilfreich, ein Problem [Vergleich der Upstream-Änderungen](https://github.com/kubernetes/website/blob/main/scripts/upstream_changes.py) zwischen dem vorherigen Entwicklungszweig und dem aktuellen Entwicklungszweig zu öffnen.

 Während nur Genehmiger einen neuen Entwicklungszweig eröffnen und Pull-Anfragen zusammenführen können, kann jeder eine Pull-Anfrage für einen neuen Entwicklungszweig eröffnen. Es sind keine besonderen Genehmigungen erforderlich.

@@ -301,5 +301,3 @@ Sobald eine Lokalisierung die Anforderungen an den Arbeitsablauf und die Mindest

 - Die Sprachauswahl auf der Website aktivieren
 - Die Verfügbarkeit der Lokalisierung über die Kanäle der [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF), einschließlich des [Kubernetes Blogs](https://kubernetes.io/blog/) veröffentlichen.
-
-
@@ -0,0 +1,94 @@
+---
+title: Bei SIG Docs mitmachen
+content_type: concept
+weight: 60
+card:
+  name: contribute
+  weight: 60
+---
+
+<!-- overview -->
+
+Die SIG Docs ist eine der [Special Interest Groups](https://github.com/kubernetes/community/blob/master/sig-list.md) (Fachspezifischen Interessengruppen) innerhalb des Kubernetes-Projekts, die sich auf das Schreiben, Aktualisieren und Pflegen der Dokumentation für Kubernetes als Ganzes konzentriert. Weitere Informationen über die SIG findest du unter SIG Docs im [GitHub Repository der Community](https://github.com/kubernetes/community/tree/master/sig-docs).
+
+SIG Docs begrüßt Inhalte und Bewertungen von allen Mitwirkenden. Jeder kann einen
+Pull Request (PR) eröffnen, und jeder ist willkommen, Fragen zum Inhalt zu stellen oder Kommentare
+zu laufenden Pull Requests abzugeben.
+
+Du kannst dich ausserdem als [Member](/de/docs/contribute/participate/roles-and-responsibilities/#member),
+[Reviewer](/de/docs/contribute/participate/roles-and-responsibilities/#reviewer), oder
+[Approver](/de/docs/contribute/participate/roles-and-responsibilities/#approver) beteiligen.
+Diese Rollen erfordern einen erweiterten Zugriff und bringen bestimmte Verantwortlichkeiten zur Genehmigung und Bestätigung von Änderungen mit sich.
+Unter [community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) findest du weitere Informationen darüber, wie die Mitgliedschaft in der Kubernetes-Community funktioniert.
+
+Der Rest dieses Dokuments umreißt einige spezielle Vorgehensweisen dieser Rollen innerhalb von SIG Docs, die für die Pflege eines der öffentlichsten Aushängeschilder von Kubernetes verantwortlich ist - die Kubernetes-Website und die Dokumentation.
+
+<!-- body -->
+## SIG Docs Vorstand
+
+Jede SIG, auch die SIG Docs, wählt ein oder mehrere SIG-Mitglieder, die als
+Vorstand fungieren. Sie sind die Kontaktstellen zwischen der SIG Docs und anderen Teilen der
+der Kubernetes-Organisation. Sie benötigen umfassende Kenntnisse über die Struktur
+des Kubernetes-Projekts als Ganzes und wie SIG Docs darin arbeitet. Hier findest alle weiteren Informationen zu den aktuellen Vorsitzenden und der [Leitung](https://github.com/kubernetes/community/tree/master/sig-docs#leadership).
+
+## SIG Docs-Teams und Automatisierung
+
+Die Automatisierung in SIG Docs stützt sich auf zwei verschiedene Mechanismen:
+GitHub-Teams und OWNERS-Dateien.
+
+### GitHub Teams
+
+Es gibt zwei Kategorien von SIG Docs [Teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) auf GitHub:
+
+- `@sig-docs-{language}-owners` sind Genehmiger und Verantwortliche
+- `@sig-docs-{language}-reviewers` sind Reviewer
+
+Jede Gruppe kann in GitHub-Kommentaren mit ihrem `@name` referenziert werden, um mit allen Mitgliedern dieser Gruppe zu kommunizieren.
+
+Manchmal überschneiden sich Prow- und GitHub-Teams, ohne eine genaue Übereinstimmung. Für die Zuordnung von Issues, Pull-Requests und zur Unterstützung von PR-Genehmigungen verwendet die
+Automatisierung die Informationen aus den `OWNERS`-Dateien.
+
+### OWNERS Dateien und Front-Matter
+
+Das Kubernetes-Projekt verwendet ein Automatisierungstool namens prow für die Automatisierung im Zusammenhang mit GitHub-Issues und Pull-Requests. 
+Das [Kubernetes-Website-Repository](https://github.com/kubernetes/website) verwendet zwei [prow-Plugins](https://github.com/kubernetes/test-infra/tree/master/prow/plugins):
+
+- blunderbuss
+- approve
+
+Diese beiden Plugins nutzen die
+[OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) und
+[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES)
+Dateien auf der obersten Ebene des GitHub-Repositorys `kubernetes/website`, um zu steuern
+wie prow innerhalb des Repositorys arbeitet.
+
+Eine OWNERS-Datei enthält eine Liste von Personen, die SIG Docs-Reviewer und
+Genehmiger sind. OWNERS-Dateien können auch in Unterverzeichnissen existieren und bestimmen, wer
+Dateien in diesem Unterverzeichnis und seinen Unterverzeichnissen als Gutachter oder
+Genehmiger bestätigen darf. Weitere Informationen über OWNERS-Dateien im Allgemeinen findest du unter
+[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md).
+
+Außerdem kann eine einzelne Markdown-Datei in ihrem Front-Matter (Vorspann) Reviewer und Genehmiger auflisten.
+Entweder durch Auflistung einzelner GitHub-Benutzernamen oder GitHub-Gruppen.
+
+Die Kombination aus OWNERS-Dateien und Front-Matter in Markdown-Dateien bestimmt, welche Empfehlungen PR-Eigentümer von automatisierten Systemen erhalten, und wen sie um eine technische und redaktionelle Überprüfung ihres PRs bitten sollen.
+## So funktioniert das Zusammenführen
+
+Wenn ein Pull Request mit der Branch (Ast) zusammengeführt wird, in dem der Inhalt bereitgestellt werden soll, wird dieser Inhalt auf http://kubernetes.io veröffentlicht. Um sicherzustellen, dass die Qualität der veröffentlichten Inhalte hoch ist, beschränken wir das Zusammenführen von Pull Requests auf
+SIG Docs Freigabeberechtigte. So funktioniert es:
+
+- Wenn eine Pull-Anfrage sowohl das `lgtm`- als auch das `approve`-Label hat, kein `hold`-Label hat, 
+  und alle Tests bestanden sind, wird der Pull Request automatisch  zusammengeführt.
+- Jedes Kubernetes-Mitglied kann das `lgtm`-Label hinzufügen, indem es einen `/lgtm`-Kommentar hinzufügt.
+- Mitglieder der Kubernetes-Organisation und SIG Docs-Genehmiger können kommentieren, um das automatische Zusammenführen eines Pull Requests zu verhindern (durch Hinzufügen eines `/hold`-Kommentars
+  kann ein vorheriger `/lgtm`-Kommentar zurückgehalten werden).
+- Nur SIG Docs-Genehmiger können einen Pull Request zusammenführen indem sie einen `/approve` Kommentar hinzufügen. 
+  Einige Genehmiger übernehmen auch weitere spezielle Rollen, wie zum Beispiel [PR Wrangler](/docs/contribute/participate/pr-wranglers/) oder [SIG Docs Vorsitzende](#sig-docs-chairperson).
+
+## {{% heading "whatsnext" %}}
+
+Weitere Informationen über die Mitarbeit an der Kubernetes-Dokumentation findest du unter:
+
+- [Neue Inhalte beisteuern](/docs/contribute/new-content/overview/)
+- [Inhalte überprüfen](/docs/contribute/review/reviewing-prs)
+- [Styleguide für die Dokumentation](/docs/contribute/style/)
@@ -0,0 +1,81 @@
+---
+title: PR Wranglers
+content_type: concept
+weight: 20
+---
+
+<!-- overview -->
+
+SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#approvers) übernehmen einwöchige Schichten um die [Pull Requests](https://github.com/kubernetes/website/wiki/PR-Wranglers) des Repositories zu verwalten.
+
+Dieser Abschnitt behandelt die Aufgaben eines PR-Wranglers. Weitere Informationen über gute Reviews findest du unter [Überprüfen von Änderungen](/docs/contribute/review/).
+<!-- body -->
+
+## Aufgaben
+
+Tägliche Aufgaben in einer einwöchigen Schicht als PR Wrangler:
+
+- Sortiere und kennzeichne täglich eingehende Probleme. Siehe [Einstufung und Kategorisierung von Problemen](/docs/contribute/review/for-approvers/#triage-and-categorize-issues) für Richtlinien, wie SIG Docs Metadaten verwendet.
+- Überprüfe [offene Pull Requests](https://github.com/kubernetes/website/pulls) auf Qualität und Einhaltung der [Style](/docs/contribute/style/style-guide/) und [Content](/docs/contribute/style/content-guide/) Leitfäden.
+    - Beginne mit den kleinsten PRs (`size/XS`) und ende mit den größten (`size/XXL`). Überprüfe so viele PRs, wie du kannst.
+- Achte darauf, dass die PR-Autoren den [CLA](https://github.com/kubernetes/community/blob/master/CLA.md) unterschreiben.
+    - Verwende [dieses](https://github.com/zparnold/k8s-docs-pr-botherer) Skript, um diejenigen, die den CLA noch nicht unterschrieben haben, daran zu erinnern, dies zu tun.
+- Gib Feedback zu den Änderungen und bitte die Mitglieder anderer SIGs um technische Überprüfung.
+    - Gib inline Vorschläge für die vorgeschlagenen inhaltlichen Änderungen in den PR ein.
+    - Wenn du den Inhalt überprüfen musst, kommentiere den PR und bitte um weitere Details.
+    - Vergebe das/die entsprechende(n) `sig/`-Label.
+    - Falls nötig, weise die Reviever aus dem Block `revievers:` im Vorspann der Datei zu.
+- Benutze den Kommentar `/approve`, um einen PR zum Zusammenführen zu genehmigen. Führe den PR zusammen, wenn er inhaltlich und technisch einwandfrei ist.
+    - PRs sollten einen `/lgtm`-Kommentar von einem anderen Mitglied haben, bevor sie zusammengeführt werden.
+    - Erwäge, technisch korrekte Inhalte zu akzeptieren, die nicht den [Stilrichtlinien](/docs/contribute/style/style-guide/) entsprechen. Eröffne ein neues Thema mit dem Label `good first issue`, um Stilprobleme anzusprechen.
+
+### Hilfreiche GitHub-Anfragen für Wranglers
+
+Die folgenden Anfragen sind beim Wrangling hilfreich.
+Wenn du diese Anfragen abgearbeitet hast, ist die verbleibende Liste der zu prüfenden PRs meist klein.
+Diese Anfragen schließen Lokalisierungs-PRs aus. Alle Anfragen beziehen sich auf den `main`-Branch, außer der letzten.
+
+- [Kein CLA, nicht zusammenfürbar](https://github.com/kubernetes/website/pulls?q=is%3Aopen+ist%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3Alanguage%2Fen):
+  Erinnere den Beitragenden daran, den CLA zu unterschreiben. Wenn sowohl der Bot als auch ein Mensch sie daran erinnert haben, schließe
+  den PR und erinnere die Autoren daran, dass sie ihn erneut öffnen können, nachdem sie den CLA unterschrieben haben.
+  **Überprüfe keine PRs, deren Autoren den CLA nicht unterschrieben haben!**
+- [Benötigt LGTM](https://github.com/kubernetes/website/pulls?q=is%3Aopen+ist%3Apr+-label%3A%22cncf-cla%3A+kein%22+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+-label%3Algtm):
+  Listet PRs auf, die ein LGTM von einem Mitglied benötigen. Wenn der PR eine technische Überprüfung benötigt, schalte einen der vom Bot vorgeschlagenen Reviewer ein. Wenn der Inhalt überarbeitet werden muss, füge Vorschläge und Feedback in-line hinzu.
+- [Hat LGTM, braucht die Zustimmung von Docs](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+):
+  Listet PRs auf, die einen `/approve`-Kommentar benötigen, um zusammengeführt zu werden.
+- [Quick Wins](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amain+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): Listet PRs gegen den Hauptzweig auf, die nicht eindeutig blockiert sind. (ändere "XS" in der Größenbezeichnung, wenn du dich durch die PRs arbeitest [XS, S, M, L, XL, XXL]).
+- [Nicht gegen den `main`-Branch](https://github.com/kubernetes/website/pulls?q=is%3Aopen+ist%3Apr+label%3Alanguage%2Fen+-base%3Amain): Wenn der PR gegen einen `dev-`Ast gerichtet ist, ist er für eine kommende Veröffentlichung. Weise diesen dem [Docs Release Manager](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles) zu: `/assign @<manager's_github-username>`. Wenn der PR gegen einen alten Ast gerichtet ist, hilf dem Autor herauszufinden, ob er auf den richtigen Ast gerichtet ist.
+
+### Hilfreiche Prow-Befehle für Wranglers
+
+```
+# Englisches Label hinzufügen
+/language en
+
+# füge dem PR ein Squash-Label hinzu, wenn es mehr als einen Commit gibt
+/label tide/merge-method-squash
+
+# einen PR ueber Prow neu betiteln (z.B. als Work-in-Progress [WIP])
+/retitle [WIP] <TITLE>
+```
+
+### Wann sind Pull Requests zu schließen
+
+Reviews und Genehmigungen sind ein Mittel, um unsere PR-Warteschlange kurz und aktuell zu halten. Ein weiteres Mittel ist das Schließen.
+
+PRs werden geschlossen, wenn:
+- Der Autor den CLA seit zwei Wochen nicht unterschrieben hat.
+
+    Die Autoren können den PR wieder öffnen, nachdem sie den CLA unterschrieben haben. Dies ist ein risikoarmer Weg, um sicherzustellen, dass nichts zusammengeführt wird, ohne dass ein CLA unterzeichnet wurde.
+
+- Der Autor hat seit Zwei oder mehr Wochen nicht auf Kommentare oder Feedback geantwortet.
+
+Hab keine Angst, Pull Requests zu schließen. Mitwirkende können sie leicht wieder öffnen und die laufenden Arbeiten fortsetzen. Oft ist es die Nachricht über die Schließung, die einen Autor dazu anspornt, seinen Beitrag wieder aufzunehmen und zu beenden.
+
+Um eine Pull-Anfrage zu schließen, hinterlasse einen `/close`-Kommentar zu dem PR.
+
+{{< note >}}
+
+Der [`fejta-bot`](https://github.com/fejta-bot) Bot markiert Themen nach 90 Tagen Inaktivität als veraltet. Nach weiteren 30 Tagen markiert er Issues als faul und schließt sie.  PR-Beauftragte sollten Themen nach 14-30 Tagen Inaktivität schließen.
+
+{{< /note >}}
@@ -0,0 +1,227 @@
+---
+title: Rollen und Verantwortlichkeiten
+content_type: concept
+weight: 10
+---
+
+<!-- overview -->
+
+Jeder kann zu Kubernetes beitragen. Wenn deine Beiträge zu SIG Docs wachsen, kannst du dich für verschiedene Stufen der Mitgliedschaft in der Community bewerben.
+Diese Rollen ermöglichen es dir, mehr Verantwortung innerhalb der Gemeinschaft zu übernehmen.
+Jede Rolle erfordert mehr Zeit und Engagement. Die Rollen sind:
+
+- Jeder: kann regelmäßig zur Kubernetes-Dokumentation beitragen
+- Member: können Issues zuweisen und einstufen und Pull Requests unverbindlich prüfen
+- Reviewer: können die Überprüfung von Dokumentations-Pull-Requests leiten und für die Qualität einer Änderung bürgen
+- Approver: können die Überprüfung von Dokumentations- und Merge-Änderungen leiten
+
+<!-- body -->
+
+## Jeder
+
+Jeder mit einem GitHub-Konto kann zu Kubernetes beitragen. SIG Docs heißt alle neuen Mitwirkenden willkommen!
+
+Jeder kann:
+
+- Ein Problem in einem beliebigen [Kubernetes](https://github.com/kubernetes/)
+  Repository, einschließlich
+  [`kubernetes/website`](https://github.com/kubernetes/website) melden
+- Unverbindliches Feedback zu einem Pull Request geben
+- Zu einer Lokalisierung beitragen
+- Verbesserungen auf [Slack](https://slack.k8s.io/) oder der
+  [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) vorschlagen.
+
+Nach dem [Signieren des CLA](/docs/contribute/new-content/overview/#sign-the-cla) kann jeder auch:
+
+- eine Pull-Anfrage öffnen, um bestehende Inhalte zu verbessern, neue Inhalte hinzuzufügen oder einen Blogbeitrag oder eine Fallstudie zu schreiben
+- Diagramme, Grafiken und einbettbare Screencasts und Videos erstellen
+
+Weitere Informationen findest du unter [neue Inhalte beisteuern](/docs/contribute/new-content/).
+
+## Member
+
+Ein Member (Mitglied) ist jemand, der bereits mehrere Pull Requests an
+`kubernetes/website` eingereicht hat. Mitglieder sind ein Teil der
+[Kubernetes GitHub Organisation](https://github.com/kubernetes).
+
+Member können:
+
+- Alles tun, was unter [Jeder](#jeder) aufgeführt ist
+- Den Kommentar `/lgtm` verwenden, um einem Pull Request das Label LGTM (looks good to me) hinzuzufügen
+
+  {{< note >}}
+  Die Verwendung von `/lgtm` löst eine Automatisierung aus. Wenn du eine unverbindliche
+  Zustimmung geben willst, funktioniert der Kommentar "LGTM" auch!
+  {{< /note >}}
+
+- Verwende den Kommentar `/hold`, um das Zusammenführen eines Pull Requests zu blockieren.
+- Benutze den Kommentar `/assign`, um einem Pull Request einen Reviewer zuzuweisen.
+- Unverbindliche Überprüfung von Pull Requests
+- Nutze die Automatisierung, um Issues zu sortieren und zu kategorisieren
+- Neue Funktionen dokumentieren
+
+### Mitglied werden
+
+Du kannst ein Mitglied werden, nachdem du mindestens 5 substantielle Pull Requests eingereicht hast und die anderen
+[Anforderungen](https://github.com/kubernetes/community/blob/master/community-membership.md#member) erforderst: 
+
+1. Finde zwei [Reviewer](#reviewers) oder [Approver](#approvers), die deine Mitgliedschaft [sponsern](/docs/contribute/advanced#sponsor-a-new-contributor).
+
+   Bitte um Sponsoring im [#sig-docs channel on Slack](https://kubernetes.slack.com) oder auf der
+   [SIG Docs Mailingliste](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
+
+   {{< note >}}
+   Schicke keine direkte E-Mail oder Slack-Direktnachricht an ein einzelnes
+   SIG Docs-Mitglied. Du musst das Sponsoring beantragen, bevor du deine Bewerbung einreichst.
+   {{< /note >}}
+
+1. Eröffne ein GitHub-Issue im
+   [`kubernetes/org`](https://github.com/kubernetes/org/) Repository. Verwende dabei das
+   **Organization Membership Request** issue template.
+
+1. Informiere deine Sponsoren über das GitHub-Issue. Du kannst entweder:
+   - Ihren GitHub-Benutzernamen in deinem Issue (`@<GitHub-Benutzername>`) erwähnen
+   - Ihnen den Issue-Link über Slack oder per E-Mail senden.
+
+     Die Sponsoren werden deine Anfrage mit einer "+1"-Stimme genehmigen. Sobald deine Sponsoren
+     genehmigen, fügt dich ein Kubernetes-GitHub-Admin als Mitglied hinzu.
+     Herzlichen Glückwunsch!
+
+     Wenn dein Antrag auf Mitgliedschaft nicht angenommen wird, erhältst du eine Rückmeldung.
+     Nachdem du dich mit dem Feedback auseinandergesetzt hast, kannst du dich erneut bewerben.
+
+1. Nimm die Einladung zur Kubernetes GitHub Organisation in deinem E-Mail-Konto an.
+
+   {{< note >}}
+   GitHub sendet die Einladung an die Standard-E-Mail-Adresse in deinem Konto.
+   {{< /note >}}
+
+## Reviewer
+
+Reviewer (Gutachteren) sind dafür verantwortlich, offene Pull Requests zu überprüfen. Anders als bei den Mitgliedern
+musst du auf das Feedback der Prüfer eingehen. Reviewer sind Mitglieder des
+[@kubernetes/sig-docs-{language}-reviews](https://github.com/orgs/kubernetes/teams?query=sig-docs)
+GitHub-Teams.
+
+Gutachteren können:
+
+- Alles tun, was unter [Jeder](#jeder) und [Member](#member) aufgeführt ist
+- Pull Requests überprüfen und verbindliches Feedback geben
+
+  {{< note >}}
+  Um unverbindliches Feedback zu geben, stellst du deinen Kommentaren eine Formulierung wie "Optional:" voran.
+  {{< /note >}}
+
+- Bearbeite benutzerseitige Zeichenfolgen im Code
+- Verbessere Code-Kommentare
+
+### Zuweisung von Reviewern zu Pull Requests
+
+Die Automatisierung weist allen Pull Requests Reviewer zu. Du kannst eine
+Review von einer bestimmten Person anfordern, indem du einen Kommentar schreibst: `/assign
+[@_github_handle]`.
+
+Wenn der zugewiesene Prüfer den PR nicht kommentiert hat, kann ein anderer Prüfer
+einspringen. Du kannst bei Bedarf auch technische Prüfer zuweisen.
+
+### Verwendung von `/lgtm`
+
+LGTM steht für "Looks good to me" und zeigt an, dass ein Pull Request
+technisch korrekt und bereit zum Zusammenführen ist. Alle PRs brauchen einen `/lgtm` Kommentar von einem
+Reviewer und einen `/approve` Kommentar von einem Approver, um zusammengeführt zu werden.
+
+Ein `/lgtm`-Kommentar vom Reviewer ist verbindlich und löst eine Automatisierung aus, die das `lgtm`-Label hinzufügt.
+
+### Reviewer werden
+
+Wenn du die
+[Anforderungen](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer) erfüllst,
+kannst du ein SIG Docs-Reviewer werden. Reviewer in anderen SIGs müssen sich gesondert für den Reviewer-Status in SIG Docs bewerben.
+
+So bewirbst du dich:
+
+1. Eröffne einen Pull Request, in dem du deinen GitHub-Benutzernamen in einen Abschnitt der
+   [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) Datei
+   im `kubernetes/website` Repository hinzufügt.
+
+   {{< note >}}
+   Wenn du dir nicht sicher bist, wo du dich hinzufügen sollst, füge dich zu `sig-docs-de-reviews` hinzu.
+   {{< /note >}}
+
+1. Weise den PR einem oder mehreren SIG-Docs-Genehmigern zu (Benutzernamen, die unter
+   `sig-docs-{language}-owners` aufgelisted sind).
+   Wenn der PR genehmigt wurde, fügt dich ein SIG Docs-Lead dem entsprechenden GitHub-Team hinzu. Sobald du hinzugefügt bist,
+   wird [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
+   dich als Reviewer für neue Pull Requests vorschlagen und zuweisen.
+
+
+## Approver
+
+
+Approver (Genehmiger) prüfen und genehmigen Pull Requests zum Zusammenführen. Genehmigende sind Mitglieder des
+[@kubernetes/sig-docs-{language}-owners](https://github.com/orgs/kubernetes/teams/?query=sig-docs)
+GitHub-Teams.
+
+Genehmigende können Folgendes tun:
+
+- Alles, was unter [Jeder](#jeder), [Member](#member) und [Reviewer](#reviewes) aufgeführt ist
+- Inhalte von Mitwirkenden veröffentlichen, indem sie Pull Requests mit dem Kommentar `/approve` genehmigen und zusammenführen
+- Verbesserungen für den Style Guide vorschlagen
+- Verbesserungsvorschläge für Docs-Tests einbringen
+- Verbesserungsvorschläge für die Kubernetes-Website oder andere Tools machen
+
+Wenn der PR bereits einen `/lgtm` hat, oder wenn der Genehmigende ebenfalls mit
+`/lgtm` kommentiert, wird der PR automatisch zusammengeführt. Ein SIG Docs-Genehmiger sollte nur ein
+`/lgtm` für eine Änderung hinterlassen, die keine weitere technische Überprüfung erfordert.
+
+### Pull Requests genehmigen
+
+Genehmiger und SIG Docs-Leads sind die Einzigen, die Pull Requests
+in das Website-Repository aufnehmen. Damit sind bestimmte Verantwortlichkeiten verbunden.
+
+- Genehmigende können den Befehl `/approve` verwenden, der PRs in das Repository einfügt.
+
+  {{< warning >}}
+  Ein unvorsichtiges Zusammenführen kann die Website lahmlegen, also sei dir sicher, dass du es auch so meinst, wenn du etwas zusammenführst.
+  {{< /warning >}}
+
+- Vergewissere dich, dass die vorgeschlagenen Änderungen den
+  [Beitragsrichtlinien](/docs/contribute/style/content-guide/#contributing-content) entsprechen.
+
+  Wenn du jemals eine Frage hast oder dir bei etwas nicht sicher bist, fordere einfach Hilfe an, um eine zusätzliche Überprüfung zu erhalten.
+
+- Vergewissere dich, dass die Netlify-Tests erfolgreich sind, bevor du einen PR mittels `/approve` genehmigst.
+
+    <img src="/images/docs/contribute/netlify-pass.png" width="75%" alt="Netlify-Tests müssen vor der Freigabe bestanden werden" />
+
+- Besuche die Netlify-Seitenvorschau für den PR, um sicherzustellen, dass alles gut aussieht, bevor du es genehmigst.
+
+- Nimm am [PR Wrangler Rotationsplan](https://github.com/kubernetes/website/wiki/PR-Wranglers)
+  für wöchentliche Rotationen teil. SIG Docs erwartet von allen Genehmigern, dass sie an dieser
+  Rotation teilnehmen. Siehe [PR-Wranglers](/docs/contribute/participate/pr-wranglers/).
+  für weitere Details.
+
+### Approver werden
+
+Wenn du die [Anforderungen](https://github.com/kubernetes/community/blob/master/community-membership.md#approver) erfüllst,
+kannst du ein SIG Docs Approver werden. Genehmigende in anderen SIGs müssen sich separat für den Approver-Status in SIG Docs bewerben.
+
+So bewirbst du dich:
+
+1. Eröffne eine Pull-Anfrage, in der du dich in einem Abschnitt der
+   [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS)
+   Datei im `kubernetes/website` Repository hinzuzufügen.
+
+    {{< note >}}
+    Wenn du dir nicht sicher bist, wo du dich hinzufügen sollst, füge dich zu `sig-docs-de-owners` hinzu.
+    {{< /note >}}
+
+2. Weise den PR einem oder mehreren aktuellen SIG Docs Genehmigern zu.
+
+Wenn der PR genehmigt wurde, fügt dich ein SIG Docs-Lead dem entsprechenden GitHub-Team hinzu. Sobald du hinzugefügt bist,
+wird [@k8s-ci-robot](https://github.com/kubernetes/test-infra/tree/master/prow#bots-home)
+dich als Reviewer für neue Pull Requests vorschlagen und zuweisen.
+
+## {{% heading "whatsnext" %}}
+
+-  Erfahre mehr über [PR-Wrangling](/de/docs/contribute/participate/pr-wranglers/), eine Rolle, die alle Genehmiger im Wechsel übernehmen.
@@ -100,7 +100,7 @@ Das auflisten der Autoskalierer geschieht über `kubectl get hpa` und eine detai
 Letzendlich können wir einen Autoskalierer mit `kubectl delete hpa` löschen.

 Zusätzlich gibt es einen speziellen Befehl `kubectl autoscale` zur einfachen Erstellung eines Horizontal Pod Autoscalers.
-Wenn du beispielsweise `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80` ausführst, wird ein Autoskalierer für den Replication Set *foo* erstellt, wobei die Ziel-CPU-Auslastung auf `80%` und die Anzahl der Replikate zwischen 2 und 5 gesetzt wird.
+Wenn du beispielsweise `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80` ausführst, wird ein Autoskalierer für den ReplicaSet *foo* erstellt, wobei die Ziel-CPU-Auslastung auf `80%` und die Anzahl der Replikate zwischen 2 und 5 gesetzt wird.
 Die Detaildokumentation von `kubectl autoscale` kann [hier](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) gefunden werden.

 ## Autoskalieren während rollierender Updates
@@ -105,7 +105,7 @@ Der Pod führt einen Container basierend auf dem bereitgestellten Docker-Image a
    hello-node-5f76cf6ccf-br9b5   1/1       Running   0          1m
    ```

-4. Cluster Events anzigen:
+4. Cluster Events anzeigen:

    ```shell
    kubectl get events
@@ -3,6 +3,7 @@ layout: blog
 title: "Remembering Dan Kohn"
 date: 2020-11-02
 slug: remembering-dan-kohn
+evergreen: true
 ---

 **Author**: The Kubernetes Steering Committee
@@ -154,7 +154,7 @@ deployment.apps/my-deployment created
 persistentvolumeclaim/my-pvc created
 ```

-If you're interested in learning more about `kubectl`, go ahead and read [kubectl Overview](/docs/reference/kubectl/overview/).
+If you're interested in learning more about `kubectl`, go ahead and read [Command line tool (kubectl)](/docs/reference/kubectl/).

 ## Using labels effectively

@@ -79,7 +79,7 @@ addressing, and it can be used in combination with other CNI plugins.

 ### CNI-Genie from Huawei

-[CNI-Genie](https://github.com/cni-genie/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/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/flannel-io/flannel#flannel), [Calico](https://projectcalico.docs.tigera.io/about/about-calico/), [Weave-net](https://www.weave.works/oss/net/).
+[CNI-Genie](https://github.com/cni-genie/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-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/flannel-io/flannel#flannel), [Calico](https://projectcalico.docs.tigera.io/about/about-calico/), [Weave-net](https://www.weave.works/oss/net/).

 CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/cni-genie/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.

@@ -26,7 +26,7 @@ many core Kubernetes functions are now built using custom resources, making Kube
 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
+[kubectl](/docs/reference/kubectl/), just as they do for built-in resources like
 *Pods*.

 ## Custom controllers
@@ -23,7 +23,7 @@ The Kubernetes API lets you query and manipulate the state of API objects in Kub
 (for example: Pods, Namespaces, ConfigMaps, and Events).

 Most operations can be performed through the
-[kubectl](/docs/reference/kubectl/overview/) command-line interface or other
+[kubectl](/docs/reference/kubectl/) 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.
@@ -83,10 +83,19 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to

 The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](https://kubernetes.io/docs/reference/kubernetes-api/) can help you find the spec format for all of the objects you can create using Kubernetes.

-For example, the reference for Pod details the [`spec` field](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
-for a Pod in the API, and the reference for Deployment details the [`spec` field](/docs/reference/kubernetes-api/workload-resources/deployment-v1/#DeploymentSpec) for Deployments.
-In those API reference pages you'll see mention of PodSpec and DeploymentSpec. These names are implementation details of the Golang code that Kubernetes uses to implement its API.
-
+For example, see the [`spec` field](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
+for the Pod API reference.
+For each Pod, the `.spec` field specifies the pod and its desired state (such as the container image name for
+each container within that pod).
+Another example of an object specification is the
+[`spec` field](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec)
+for the StatefulSet API. For StatefulSet, the `.spec` field specifies the StatefulSet and
+its desired state.
+Within the `.spec` of a StatefulSet is a [template](/docs/concepts/workloads/pods/#pod-templates)
+for Pod objects. That template describes Pods that the StatefulSet controller will create in order to
+satisfy the StatefulSet specification.
+Different kinds of object can also have different `.status`; again, the API reference pages
+detail the structure of that `.status` field, and its content for each different type of object.

 ## {{% heading "whatsnext" %}}

@@ -27,7 +27,8 @@ updates.
 ## What is a Pod Security Policy?

 A _Pod Security Policy_ is a cluster-level resource that controls security
-sensitive aspects of the pod specification. The [PodSecurityPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) objects
+sensitive aspects of the pod specification. The
+[PodSecurityPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) objects
 define a set of conditions that a pod must run with in order to be accepted into
 the system, as well as defaults for the related fields. They allow an
 administrator to control the following:
@@ -54,10 +55,10 @@ administrator to control the following:

 ## Enabling Pod Security Policies

-Pod security policy control is implemented as an optional [admission
-controller](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy).
-PodSecurityPolicies are enforced by [enabling the admission
-controller](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in),
+Pod security policy control is implemented as an optional
+[admission controller](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy).
+PodSecurityPolicies are enforced by
+[enabling the admission controller](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in),
 but doing so without authorizing any policies **will prevent any pods from being created** in the
 cluster.

@@ -69,9 +70,9 @@ controller.
 ## Authorizing Policies

 When a PodSecurityPolicy resource is created, it does nothing. In order to use
-it, the requesting user or target pod's [service
-account](/docs/tasks/configure-pod-container/configure-service-account/) must be
-authorized to use the policy, by allowing the `use` verb on the policy.
+it, the requesting user or target pod's
+[service account](/docs/tasks/configure-pod-container/configure-service-account/)
+must be authorized to use the policy, by allowing the `use` verb on the policy.

 Most Kubernetes pods are not created directly by users. Instead, they are
 typically created indirectly as part of a
@@ -132,6 +133,7 @@ subjects:
 If a `RoleBinding` (not a `ClusterRoleBinding`) is used, it will only grant
 usage for pods being run in the same namespace as the binding. This can be
 paired with system groups to grant access to all pods run in the namespace:
+
 ```yaml
 # Authorize all service accounts in a namespace:
 - kind: Group
@@ -143,25 +145,27 @@ paired with system groups to grant access to all pods run in the namespace:
  name: system:authenticated
 ```

-For more examples of RBAC bindings, see [Role Binding
-Examples](/docs/reference/access-authn-authz/rbac#role-binding-examples).
-For a complete example of authorizing a PodSecurityPolicy, see
-[below](#example).
+For more examples of RBAC bindings, see
+[RoleBinding examples](/docs/reference/access-authn-authz/rbac#role-binding-examples).
+For a complete example of authorizing a PodSecurityPolicy, see [below](#example).

 ### Recommended Practice

-PodSecurityPolicy is being replaced by a new, simplified `PodSecurity` {{< glossary_tooltip
-text="admission controller" term_id="admission-controller" >}}. For more details on this change, see
-[PodSecurityPolicy Deprecation: Past, Present, and
-Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). Follow these
-guidelines to simplify migration from PodSecurityPolicy to the new admission controller:
+PodSecurityPolicy is being replaced by a new, simplified `PodSecurity`
+{{< glossary_tooltip text="admission controller" term_id="admission-controller" >}}.
+For more details on this change, see
+[PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/).
+Follow these guidelines to simplify migration from PodSecurityPolicy to the
+new admission controller:
+
+1. Limit your PodSecurityPolicies to the policies defined by the
+   [Pod Security Standards](/docs/concepts/security/pod-security-standards):

-1. Limit your PodSecurityPolicies to the policies defined by the [Pod Security Standards](/docs/concepts/security/pod-security-standards):
   - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
   - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
   - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}}

-2. Only bind PSPs to entire namespaces, by using the `system:serviceaccounts:<namespace>` group
+1. Only bind PSPs to entire namespaces, by using the `system:serviceaccounts:<namespace>` group
   (where `<namespace>` is the target namespace). For example:

   ```yaml
@@ -217,8 +221,8 @@ only non-mutating PodSecurityPolicies are used to validate the pod.

 ## Example

-_This example assumes you have a running cluster with the PodSecurityPolicy
-admission controller enabled and you have cluster admin privileges._
+This example assumes you have a running cluster with the PodSecurityPolicy
+admission controller enabled and you have cluster admin privileges.

 ### Set up

@@ -364,12 +368,24 @@ Let's try that again, slightly differently:

 ```shell
 kubectl-user create deployment pause --image=k8s.gcr.io/pause
+```
+
+```none
 deployment "pause" created
-
+```
+```shell
 kubectl-user get pods
-No resources found.
+```

+```
+No resources found.
+```
+
+```shell
 kubectl-user get events | head -n 2
+```
+
+```
 LASTSEEN   FIRSTSEEN   COUNT     NAME              KIND         SUBOBJECT                TYPE      REASON                  SOURCE                                  MESSAGE
 1m         2m          15        pause-7774d79b5   ReplicaSet                            Warning   FailedCreate            replicaset-controller                   Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request
 ```
@@ -390,6 +406,9 @@ is `default`:
 kubectl-admin create rolebinding default:psp:unprivileged \
    --role=psp:unprivileged \
    --serviceaccount=psp-example:default
+```
+
+```none
 rolebinding "default:psp:unprivileged" created
 ```

@@ -398,6 +417,9 @@ eventually succeed in creating the pod:

 ```shell
 kubectl-user get pods --watch
+```
+
+```none
 NAME                    READY     STATUS    RESTARTS   AGE
 pause-7774d79b5-qrgcb   0/1       Pending   0         1s
 pause-7774d79b5-qrgcb   0/1       Pending   0         1s
@@ -411,6 +433,9 @@ Delete the namespace to clean up most of the example resources:

 ```shell
 kubectl-admin delete ns psp-example
+```
+
+```
 namespace "psp-example" deleted
 ```

@@ -419,6 +444,9 @@ up separately:

 ```shell
 kubectl-admin delete psp example
+```
+
+```
 podsecuritypolicy "example" deleted
 ```

@@ -435,7 +463,8 @@ several security mechanisms.

 {{< codenew file="policy/restricted-psp.yaml" >}}

-See [Pod Security Standards](/docs/concepts/security/pod-security-standards/#policy-instantiation) for more examples.
+See [Pod Security Standards](/docs/concepts/security/pod-security-standards/#policy-instantiation)
+for more examples.

 ## Policy Reference

@@ -471,17 +500,17 @@ and `max`(inclusive). Defaults to no allowed host ports.
 **Volumes** - Provides a list of allowed volume types. The allowable values
 correspond to the volume sources that are defined when creating a volume. For
 the complete list of volume types, see [Types of
-Volumes](/docs/concepts/storage/volumes/#types-of-volumes). Additionally, `*`
-may be used to allow all volume types.
+Volumes](/docs/concepts/storage/volumes/#types-of-volumes). Additionally,
+`*` may be used to allow all volume types.

 The **recommended minimum set** of allowed volumes for new PSPs are:

- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- secret
- projected
+- `configMap`
+- `downwardAPI`
+- `emptyDir`
+- `persistentVolumeClaim`
+- `secret`
+- `projected`

 {{< warning >}}
 PodSecurityPolicy does not limit the types of `PersistentVolume` objects that
@@ -493,10 +522,10 @@ should be granted permission to create `PersistentVolume` objects.
 **FSGroup** - Controls the supplemental group applied to some volumes.

 - *MustRunAs* - Requires at least one `range` to be specified. Uses the
-minimum value of the first range as the default. Validates against all ranges.
+  minimum value of the first range as the default. Validates against all ranges.
 - *MayRunAs* - Requires at least one `range` to be specified. Allows
-`FSGroups` to be left unset without providing a default. Validates against
-all ranges if `FSGroups` is set.
+  `FSGroups` to be left unset without providing a default. Validates against
+  all ranges if `FSGroups` is set.
 - *RunAsAny* - No default provided. Allows any `fsGroup` ID to be specified.

 **AllowedHostPaths** - This specifies a list of host paths that are allowed
@@ -515,7 +544,8 @@ For example:
      readOnly: true # only allow read-only mounts
 ```

-{{< warning >}}There are many ways a container with unrestricted access to the host
+{{< warning >}}
+There are many ways a container with unrestricted access to the host
 filesystem can escalate privileges, including reading data from other
 containers, and abusing the credentials of system services, such as Kubelet.

@@ -556,33 +586,33 @@ spec:
 **RunAsUser** - Controls which user ID the containers are run with.

 - *MustRunAs* - Requires at least one `range` to be specified. Uses the
-minimum value of the first range as the default. Validates against all ranges.
+  minimum value of the first range as the default. Validates against all ranges.
 - *MustRunAsNonRoot* - Requires that the pod be submitted with a non-zero
-`runAsUser` or have the `USER` directive defined (using a numeric UID) in the
-image. Pods which have specified neither `runAsNonRoot` nor `runAsUser` settings
-will be mutated to set `runAsNonRoot=true`, thus requiring a defined non-zero 
-numeric `USER` directive in the container. No default provided. Setting 
-`allowPrivilegeEscalation=false` is strongly recommended with this strategy.
+  `runAsUser` or have the `USER` directive defined (using a numeric UID) in the
+  image. Pods which have specified neither `runAsNonRoot` nor `runAsUser` settings
+  will be mutated to set `runAsNonRoot=true`, thus requiring a defined non-zero 
+  numeric `USER` directive in the container. No default provided. Setting 
+  `allowPrivilegeEscalation=false` is strongly recommended with this strategy.
 - *RunAsAny* - No default provided. Allows any `runAsUser` to be specified.

 **RunAsGroup** - Controls which primary group ID the containers are run with.

 - *MustRunAs* - Requires at least one `range` to be specified. Uses the
-minimum value of the first range as the default. Validates against all ranges.
+  minimum value of the first range as the default. Validates against all ranges.
 - *MayRunAs* - Does not require that RunAsGroup be specified. However, when RunAsGroup
-is specified, they have to fall in the defined range.
+  is specified, they have to fall in the defined range.
 - *RunAsAny* - No default provided. Allows any `runAsGroup` to be specified.


 **SupplementalGroups** - Controls which group IDs containers add.

 - *MustRunAs* - Requires at least one `range` to be specified. Uses the
-minimum value of the first range as the default. Validates against all ranges.
+  minimum value of the first range as the default. Validates against all ranges.
 - *MayRunAs* - Requires at least one `range` to be specified. Allows
-`supplementalGroups` to be left unset without providing a default.
-Validates against all ranges if `supplementalGroups` is set.
+  `supplementalGroups` to be left unset without providing a default.
+  Validates against all ranges if `supplementalGroups` is set.
 - *RunAsAny* - No default provided. Allows any `supplementalGroups` to be
-specified.
+  specified.

 ### Privilege Escalation

@@ -627,8 +657,8 @@ added. Capabilities listed in `RequiredDropCapabilities` must not be included in
 `AllowedCapabilities` or `DefaultAddCapabilities`.

 **DefaultAddCapabilities** - The capabilities which are added to containers by
-default, in addition to the runtime defaults. See the [Docker
-documentation](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)
+default, in addition to the runtime defaults. See the
+[Docker documentation](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)
 for the default list of capabilities when using the Docker runtime.

 ### SELinux
@@ -655,16 +685,17 @@ denoted as the string `Unmasked`.

 ### AppArmor

-Controlled via annotations on the PodSecurityPolicy. Refer to the [AppArmor
-documentation](/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations).
+Controlled via annotations on the PodSecurityPolicy. Refer to the
+[AppArmor documentation](/docs/tutorials/security/apparmor/#podsecuritypolicy-annotations).

 ### Seccomp

 As of Kubernetes v1.19, you can use the `seccompProfile` field in the
-`securityContext` of Pods or containers to [control use of seccomp
-profiles](/docs/tutorials/clusters/seccomp). In prior versions, seccomp was
-controlled by adding annotations to a Pod. The same PodSecurityPolicies can be
-used with either version to enforce how these fields or annotations are applied.
+`securityContext` of Pods or containers to
+[control use of seccomp profiles](/docs/tutorials/security/seccomp/).
+In prior versions, seccomp was controlled by adding annotations to a Pod. The
+same PodSecurityPolicies can be used with either version to enforce how these
+fields or annotations are applied.

 **seccomp.security.alpha.kubernetes.io/defaultProfileName** - Annotation that
 specifies the default seccomp profile to apply to containers. Possible values
@@ -681,10 +712,10 @@ are:
  flag is not defined, the default path will be used, which is
  `<root-dir>/seccomp` where `<root-dir>` is specified by the `--root-dir` flag.

-{{< note >}}
+  {{< note >}}
  The `--seccomp-profile-root` flag is deprecated since Kubernetes
  v1.19. Users are encouraged to use the default path.
-{{< /note >}}
+  {{< /note >}}

 **seccomp.security.alpha.kubernetes.io/allowedProfileNames** - Annotation that
 specifies which values are allowed for the pod seccomp annotations. Specified as
@@ -696,18 +727,22 @@ default cannot be changed.

 By default, all safe sysctls are allowed. 

- `forbiddenSysctls` - excludes specific sysctls. You can forbid a combination of safe and unsafe sysctls in the list. To forbid setting any sysctls, use `*` on its own.
- `allowedUnsafeSysctls` - allows specific sysctls that had been disallowed by the default list, so long as these are not listed in `forbiddenSysctls`.
+- `forbiddenSysctls` - excludes specific sysctls. You can forbid a combination
+  of safe and unsafe sysctls in the list. To forbid setting any sysctls, use
+  `*` on its own.
+- `allowedUnsafeSysctls` - allows specific sysctls that had been disallowed by
+  the default list, so long as these are not listed in `forbiddenSysctls`.

-Refer to the [Sysctl documentation](
-/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy).
+Refer to the [Sysctl documentation](/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy).

 ## {{% heading "whatsnext" %}}

- See [PodSecurityPolicy Deprecation: Past, Present, and
-  Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/) to learn about
-  the future of pod security policy.
+- See [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)
+  to learn about the future of pod security policy.

- See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) for policy recommendations.
+- See [Pod Security Standards](/docs/concepts/security/pod-security-standards/)
+  for policy recommendations.
+
+- Refer to [PodSecurityPolicy reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)
+  for the API details.

- Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details.
@@ -6,14 +6,117 @@ weight: 70

 {{< glossary_definition term_id="api-eviction" length="short" >}} </br>

-You can request eviction by directly calling the Eviction API 
-using a client of the kube-apiserver, like the `kubectl drain` command. 
-This creates an `Eviction` object, which causes the API server to terminate the Pod. 
+You can request eviction by calling the Eviction API directly, or programmatically
+using a client of the {{<glossary_tooltip term_id="kube-apiserver" text="API server">}}, like the `kubectl drain` command. This
+creates an `Eviction` object, which causes the API server to terminate the Pod.

 API-initiated evictions respect your configured [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/)
 and [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination). 

+Using the API to create an Eviction object for a Pod is like performing a
+policy-controlled [`DELETE` operation](/docs/reference/kubernetes-api/workload-resources/pod-v1/#delete-delete-a-pod)
+on the Pod. 
+
+## Calling the Eviction API
+
+You can use a [Kubernetes language client](/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api)
+to access the Kubernetes API and create an `Eviction` object. To do this, you
+POST the attempted operation, similar to the following example:
+
+{{< tabs name="Eviction_example" >}}
+{{% tab name="policy/v1" %}}
+{{< note >}}
+`policy/v1` Eviction is available in v1.22+. Use `policy/v1beta1` with prior releases.
+{{< /note >}}
+
+```json
+{
+  "apiVersion": "policy/v1",
+  "kind": "Eviction",
+  "metadata": {
+    "name": "quux",
+    "namespace": "default"
+  }
+}
+```
+{{% /tab %}}
+{{% tab name="policy/v1beta1" %}}
+{{< note >}}
+Deprecated in v1.22 in favor of `policy/v1`
+{{< /note >}}
+
+```json
+{
+  "apiVersion": "policy/v1beta1",
+  "kind": "Eviction",
+  "metadata": {
+    "name": "quux",
+    "namespace": "default"
+  }
+}
+```
+{{% /tab %}}
+{{< /tabs >}}
+
+Alternatively, you can attempt an eviction operation by accessing the API using
+`curl` or `wget`, similar to the following example:
+
+```bash
+curl -v -H 'Content-type: application/json' https://your-cluster-api-endpoint.example/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json
+```
+
+## How API-initiated eviction works
+
+When you request an eviction using the API, the API server performs admission
+checks and responds in one of the following ways:
+
+* `200 OK`: the eviction is allowed, the `Eviction` subresource is created, and
+  the Pod is deleted, similar to sending a `DELETE` request to the Pod URL.
+* `429 Too Many Requests`: the eviction is not currently allowed because of the
+  configured {{<glossary_tooltip term_id="pod-disruption-budget" text="PodDisruptionBudget">}}.
+  You may be able to attempt the eviction again later. You might also see this
+  response because of API rate limiting. 
+* `500 Internal Server Error`: the eviction is not allowed because there is a
+  misconfiguration, like if multiple PodDisruptionBudgets reference the same Pod.
+
+If the Pod you want to evict isn't part of a workload that has a
+PodDisruptionBudget, the API server always returns `200 OK` and allows the
+eviction. 
+
+If the API server allows the eviction, the Pod is deleted as follows:
+
+1. The `Pod` resource in the API server is updated with a deletion timestamp,
+   after which the API server considers the `Pod` resource to be terminated. The
+   `Pod` resource is also marked with the configured grace period.
+1. The {{<glossary_tooltip term_id="kubelet" text="kubelet">}} on the node where the local Pod is running notices that the `Pod`
+   resource is marked for termination and starts to gracefully shut down the
+   local Pod.
+1. While the kubelet is shutting the Pod down, the control plane removes the Pod
+   from {{<glossary_tooltip term_id="endpoint" text="Endpoint">}} and
+   {{<glossary_tooltip term_id="endpoint-slice" text="EndpointSlice">}}
+   objects. As a result, controllers no longer consider the Pod as a valid object.
+1. After the grace period for the Pod expires, the kubelet forcefully terminates
+   the local Pod.
+1. The kubelet tells the API server to remove the `Pod` resource.
+1. The API server deletes the `Pod` resource.
+
+## Troubleshooting stuck evictions
+
+In some cases, your applications may enter a broken state, where the Eviction
+API will only return `429` or `500` responses until you intervene. This can 
+happen if, for example, a ReplicaSet creates pods for your application but new 
+pods do not enter a `Ready` state. You may also notice this behavior in cases
+where the last evicted Pod had a long termination grace period.
+
+If you notice stuck evictions, try one of the following solutions: 
+
+* Abort or pause the automated operation causing the issue. Investigate the stuck
+  application before you restart the operation.
+* Wait a while, then directly delete the Pod from your cluster control plane
+  instead of using the Eviction API.
+
 ## {{% heading "whatsnext" %}}

-* Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
-* Learn about [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
+* Learn how to protect your applications with a [Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/).
+* Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
+* Learn about [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/).
@@ -167,7 +167,7 @@ To do so, add an `addedAffinity` to the args of the [`NodeAffinity` plugin](/doc
 in the [scheduler configuration](/docs/reference/scheduling/config/). For example:

 ```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration

 profiles:
@@ -38,7 +38,7 @@ Below is an example configuration that sets
 resources `intel.com/foo` and `intel.com/bar`.

 ```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration
 profiles:
 # ...
@@ -255,10 +255,11 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
    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 125% of the desired number of Pods are up (25% max surge).

-    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
+    For example, if you look at the above Deployment closely, you will see that it first creates a new Pod,
+    then deletes an old Pod, and creates another new one. 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.
+    It makes sure that at least 3 Pods are available and that at max 4 Pods in total are available. In case of
+    a Deployment with 4 replicas, the number of Pods would be between 3 and 5.

 * Get details of your Deployment:
  ```shell
@@ -305,10 +306,17 @@ up to 3 replicas, as well as scaling down the old ReplicaSet to 0 replicas.
    ```
    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.
+    (nginx-deployment-1564180365) and scaled it up to 1 and waited for it to come up. Then it scaled down the old ReplicaSet
+    to 2 and scaled up the new ReplicaSet to 2 so that at least 3 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.
+
+{{< note >}}
+Kubernetes doesn't count terminating Pods when calculating the number of `availableReplicas`, which must be between
+`replicas - maxUnavailable` and `replicas + maxSurge`. As a result, you might notice that there are more Pods than
+expected during a rollout, and that the total resources consumed by the Deployment is more than `replicas + maxSurge`
+until the `terminationGracePeriodSeconds` of the terminating Pods expires.
+{{< /note >}}

 ### Rollover (aka multiple updates in-flight)

@@ -266,7 +266,7 @@ Note that we recommend using Deployments instead of directly using Replica Sets,

 ### Deployment (Recommended)

-[`Deployment`](/docs/concepts/workloads/controllers/deployment/) is a higher-level API object that updates its underlying Replica Sets and their Pods. Deployments are recommended if you want the rolling update functionality because, they are declarative, server-side, and have additional features.
+[`Deployment`](/docs/concepts/workloads/controllers/deployment/) is a higher-level API object that updates its underlying Replica Sets and their Pods. Deployments are recommended if you want the rolling update functionality,  because they are declarative, server-side, and have additional features.

 ### Bare Pods

@@ -296,7 +296,7 @@ replication controllers, replica sets or stateful sets that the Pod belongs to.
 An example configuration might look like follows:

 ```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration

 profiles:
@@ -352,7 +352,7 @@ you can disable those defaults by setting `defaultingType` to `List` and leaving
 empty `defaultConstraints` in the `PodTopologySpread` plugin configuration:

 ```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta3
 kind: KubeSchedulerConfiguration

 profiles:
@@ -95,9 +95,9 @@ class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey
 class S,T,U spacewhite
 class first,second,third white
 {{</ mermaid >}}
-***Figure - Getting started for a new contributor***
+Figure 1. Getting started for a new contributor.

-The figure above outlines a roadmap for new contributors. You can follow some or all of the steps for `Sign up` and `Review`. Now you are ready to open PRs that achieve your contribution objectives with some listed under `Open PR`. Again, questions are always welcome!
+Figure 1 outlines a roadmap for new contributors. You can follow some or all of the steps for `Sign up` and `Review`. Now you are ready to open PRs that achieve your contribution objectives with some listed under `Open PR`. Again, questions are always welcome!

 Some tasks require more trust and more access in the Kubernetes organization.
 See [Participating in SIG Docs](/docs/contribute/participate/) for more details about
@@ -105,7 +105,7 @@ roles and permissions.

 ## Your first contribution

-You can prepare for your first contribution by reviewing several steps beforehand. The figure below outlines the steps and the details follow. 
+You can prepare for your first contribution by reviewing several steps beforehand. Figure 2 outlines the steps and the details follow. 

 <!-- See https://github.com/kubernetes/website/issues/28808 for live-editor URL to this figure -->
 <!-- You can also cut/paste the mermaid code into the live editor at https://mermaid-js.github.io/mermaid-live-editor to play around with it -->
@@ -136,7 +136,7 @@ class A,B,D,E,F,G grey
 class S,T spacewhite
 class first,second white
 {{</ mermaid >}}
-***Figure - Preparation for your first contribution***
+Figure 2. Preparation for your first contribution.

 - Read the [Contribution overview](/docs/contribute/new-content/overview/) to
  learn about the different ways you can contribute.
@@ -22,6 +22,34 @@ Most of the blog's content is about things happening in the core project, but we

 Anyone can write a blog post and submit it for review.

+### Submit a Post
+
+Blog posts should not be commercial in nature and should consist of original content that applies broadly to the Kubernetes community.
+Appropriate blog content includes:
+
+- New Kubernetes capabilities
+- Kubernetes projects updates
+- Updates from Special Interest Groups
+- Tutorials and walkthroughs
+- Thought leadership around Kubernetes
+- Kubernetes Partner OSS integration
+- **Original content only**
+
+Unsuitable content includes:
+
+- Vendor product pitches
+- Partner updates without an integration and customer story
+- Syndicated posts (language translations ok)
+
+To submit a blog post, follow these steps:
+
+1. [Sign the CLA](https://kubernetes.io/docs/contribute/start/#sign-the-cla) if you have not yet done so.
+1. Have a look at the Markdown format for existing blog posts in the [website repository](https://github.com/kubernetes/website/tree/master/content/en/blog/_posts).
+1. Write out your blog post in a text editor of your choice.
+1. On the same link from step 2, click the Create new file button. Paste your content into the editor. Name the file to match the proposed title of the blog post, but don’t put the date in the file name. The blog reviewers will work with you on the final file name and the date the blog will be published.
+1. When you save the file, GitHub will walk you through the pull request process.
+1. A blog post reviewer will review your submission and work with you on feedback and final details. When the blog post is approved, the blog will be scheduled for publication.
+
 ### Guidelines and expectations

 - Blog posts should not be vendor pitches. 
@@ -43,7 +43,7 @@ client libraries:

 ## CLI

-* [kubectl](/docs/reference/kubectl/overview/) - Main CLI tool for running commands and managing Kubernetes clusters.
+* [kubectl](/docs/reference/kubectl/) - 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/) - CLI tool to easily provision a secure Kubernetes cluster.

@@ -29,7 +29,7 @@ To set feature gates for a component, such as kubelet, use the `--feature-gates`
 flag assigned to a list of feature pairs:

 ```shell
--feature-gates="...,GracefulNodeShutdown=true"
+--feature-gates=...,GracefulNodeShutdown=true
 ```

 The following tables are a summary of the feature gates that you can set on
@@ -622,8 +622,10 @@ Each feature gate is designed for enabling/disabling a specific feature:
  operations from in-tree plugins to corresponding pre-installed CSI plugins
 - `CSIMigrationAWS`: Enables shims and translation logic to route volume
  operations from the AWS-EBS in-tree plugin to EBS CSI plugin. Supports
-  falling back to in-tree EBS plugin if a node does not have EBS CSI plugin
-  installed and configured. Requires CSIMigration feature flag enabled.
+  falling back to in-tree EBS plugin for mount operations to nodes that have
+  the feature disabled or that do not have EBS CSI plugin installed and
+  configured. Does not support falling back for provision operations, for those
+  the CSI plugin must be installed and configured.
 - `CSIMigrationAWSComplete`: Stops registering the EBS in-tree plugin in
  kubelet and volume controllers and enables shims and translation logic to
  route volume operations from the AWS-EBS in-tree plugin to EBS CSI plugin.
@@ -633,9 +635,11 @@ Each feature gate is designed for enabling/disabling a specific feature:
  which prevents the registration of in-tree EBS plugin.
 - `CSIMigrationAzureDisk`: Enables shims and translation logic to route volume
  operations from the Azure-Disk in-tree plugin to AzureDisk CSI plugin.
-  Supports falling back to in-tree AzureDisk plugin if a node does not have
-  AzureDisk CSI plugin installed and configured. Requires CSIMigration feature
-  flag enabled.
+  Supports falling back to in-tree AzureDisk plugin for mount operations to
+  nodes that have the feature disabled or that do not have AzureDisk CSI plugin
+  installed and configured. Does not support falling back for provision
+  operations, for those the CSI plugin must be installed and configured.
+  Requires CSIMigration feature flag enabled.
 - `CSIMigrationAzureDiskComplete`: Stops registering the Azure-Disk in-tree
  plugin in kubelet and volume controllers and enables shims and translation
  logic to route volume operations from the Azure-Disk in-tree plugin to
@@ -645,9 +649,11 @@ Each feature gate is designed for enabling/disabling a specific feature:
  `InTreePluginAzureDiskUnregister` feature flag which prevents the registration of in-tree AzureDisk plugin.
 - `CSIMigrationAzureFile`: Enables shims and translation logic to route volume
  operations from the Azure-File in-tree plugin to AzureFile CSI plugin.
-  Supports falling back to in-tree AzureFile plugin if a node does not have
-  AzureFile CSI plugin installed and configured. Requires CSIMigration feature
-  flag enabled.
+  Supports falling back to in-tree AzureFile plugin for mount operations to
+  nodes that have the feature disabled or that do not have AzureFile CSI plugin
+  installed and configured. Does not support falling back for provision
+  operations, for those the CSI plugin must be installed and configured.
+  Requires CSIMigration feature flag enabled.
 - `CSIMigrationAzureFileComplete`: Stops registering the Azure-File in-tree
  plugin in kubelet and volume controllers and enables shims and translation
  logic to route volume operations from the Azure-File in-tree plugin to
@@ -658,8 +664,11 @@ Each feature gate is designed for enabling/disabling a specific feature:
   of in-tree AzureFile plugin.
 - `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.
+  back to in-tree GCE plugin for mount operations to nodes that have the
+  feature disabled or that do not have PD CSI plugin installed and configured.
+  Does not support falling back for provision operations, for those the CSI
+  plugin must be installed and configured. Requires CSIMigration feature flag
+  enabled.
 - `csiMigrationRBD`: Enables shims and translation logic to route volume
  operations from the RBD in-tree plugin to Ceph RBD CSI plugin. Requires
  CSIMigration and csiMigrationRBD feature flags enabled and Ceph CSI plugin
@@ -675,8 +684,11 @@ Each feature gate is designed for enabling/disabling a specific feature:
  been deprecated in favor of the `InTreePluginGCEUnregister` feature flag which prevents the registration of in-tree GCE PD plugin.
 - `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.
+  falling back to in-tree Cinder plugin for mount operations to nodes that have
+  the feature disabled or that do not have Cinder CSI plugin installed and
+  configured. Does not support falling back for provision operations, for those
+  the CSI plugin must be 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.
@@ -684,9 +696,12 @@ Each feature gate is designed for enabling/disabling a specific feature:
  CSI plugin installed and configured on all nodes in the cluster. This flag has
  been deprecated in favor of the `InTreePluginOpenStackUnregister` feature flag which prevents the registration of in-tree openstack cinder plugin.
 - `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.
+  from the vSphere in-tree plugin to vSphere CSI plugin. Supports falling back
+  to in-tree vSphere plugin for mount operations to nodes that have the feature
+  disabled or that do not have vSphere CSI plugin installed and configured.
+  Does not support falling back for provision operations, for those the CSI
+  plugin must be 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
@@ -4,16 +4,19 @@ id: kubectl
 date: 2018-04-12
 full_link: /docs/user-guide/kubectl-overview/
 short_description: >
-  A command line tool for communicating with a Kubernetes API server.
+  A command line tool for communicating with a Kubernetes cluster.

 aka:
+- kubectl
 tags:
 - tool
 - fundamental
 ---
- A command line tool for communicating with a {{< glossary_tooltip text="Kubernetes API" term_id="kubernetes-api" >}} server.
+Command line tool for communicating with a Kubernetes cluster's
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}},
+using the Kubernetes API.

 <!--more--> 

-You can use kubectl to create, inspect, update, and delete Kubernetes objects.
+You can use `kubectl` to create, inspect, update, and delete Kubernetes objects.

@@ -1,5 +1,556 @@
 ---
-title: "kubectl"
+title: Command line tool (kubectl)
+content_type: reference
 weight: 60
+no_list: true
+card:
+  name: reference
+  weight: 20
 ---

+<!-- overview -->
+{{< glossary_definition prepend="Kubernetes provides a" term_id="kubectl" length="short" >}}
+
+This tool is named `kubectl`.
+
+For configuration, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory.
+You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
+files by setting the `KUBECONFIG` environment variable or by setting the
+[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.
+
+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/tools/#kubectl);
+for a quick guide, see the [cheat sheet](/docs/reference/kubectl/cheatsheet/).
+If you're used to using the `docker` command-line tool, [`kubectl` for Docker Users](/docs/reference/kubectl/docker-cli-to-kubectl/) explains some equivalent commands for Kubernetes.
+
+<!-- body -->
+
+## Syntax
+
+Use the following syntax to run `kubectl` commands from your terminal window:
+
+```shell
+kubectl [command] [TYPE] [NAME] [flags]
+```
+
+where `command`, `TYPE`, `NAME`, and `flags` are:
+
+* `command`: Specifies the operation that you want to perform on one or more resources, 
+for example `create`, `get`, `describe`, `delete`.
+
+* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and
+  you can specify the singular, plural, or abbreviated forms.
+  For example, the following commands produce the same output:
+
+   ```shell
+   kubectl get pod pod1
+   kubectl get pods pod1
+   kubectl get po pod1
+   ```
+
+* `NAME`: Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, for example `kubectl get pods`.
+
+   When performing an operation on multiple resources, you can specify each resource by type and name or specify one or more files:
+
+   * 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-configuration-tips) since YAML tends to be more user-friendly, especially for configuration files.<br/>
+     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/>
+
+{{< caution >}}
+Flags that you specify from the command line override default values and any corresponding environment variables.
+{{< /caution >}}
+
+If you need help, run `kubectl help` from the terminal window.
+
+## In-cluster authentication and namespace overrides
+
+By default `kubectl` will first determine if it is running within a pod, and thus in a cluster. It starts by checking for the `KUBERNETES_SERVICE_HOST` and `KUBERNETES_SERVICE_PORT` environment variables and the existence of a service account token file at `/var/run/secrets/kubernetes.io/serviceaccount/token`. If all three are found in-cluster authentication is assumed.
+
+To maintain backwards compatibility, if the `POD_NAMESPACE` environment variable is set during in-cluster authentication it will override the default namespace from the service account token. Any manifests or tools relying on namespace defaulting will be affected by this.
+
+**`POD_NAMESPACE` environment variable**
+
+If the `POD_NAMESPACE` environment variable is set, cli operations on namespaced resources will default to the variable value. For example, if the variable is set to `seattle`, `kubectl get pods` would return pods in the `seattle` namespace. This is because pods are a namespaced resource, and no namespace was provided in the command. Review the output of `kubectl api-resources` to determine if a resource is namespaced. 
+
+Explicit use of `--namespace <value>` overrides this behavior. 
+
+**How kubectl handles ServiceAccount tokens**
+
+If:
+* there is Kubernetes service account token file mounted at
+  `/var/run/secrets/kubernetes.io/serviceaccount/token`, and
+* the `KUBERNETES_SERVICE_HOST` environment variable is set, and
+* the `KUBERNETES_SERVICE_PORT` environment variable is set, and
+* you don't explicitly specify a namespace on the kubectl command line
+
+then kubectl assumes it is running in your cluster. The kubectl tool looks up the
+namespace of that ServiceAccount (this is the same as the namespace of the Pod)
+and acts against that namespace. This is different from what happens outside of a
+cluster; when kubectl runs outside a cluster and you don't specify a namespace,
+the kubectl command acts against the `default` namespace.
+
+## Operations
+
+The following table includes short descriptions and the general syntax for all of the `kubectl` operations:
+
+Operation       | Syntax    |       Description
+-------------------- | -------------------- | --------------------
+`alpha`    | `kubectl alpha SUBCOMMAND [flags]` | List the available commands that correspond to alpha features, which are not enabled in Kubernetes clusters by default.
+`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> | Add or update the annotations of one or more resources.
+`api-resources`    | `kubectl api-resources [flags]` | List the API resources that are available.
+`api-versions`    | `kubectl api-versions [flags]` | List the API versions that are available.
+`apply`            | `kubectl apply -f FILENAME [flags]`| Apply a configuration change to a resource from a file or stdin.
+`attach`        | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | Attach to a running container either to view the output stream or interact with the container (stdin).
+`auth`    | `kubectl auth [flags] [options]` | Inspect authorization.
+`autoscale`    | <code>kubectl autoscale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]</code> | Automatically scale the set of pods that are managed by a replication controller.
+`certificate`    | `kubectl certificate SUBCOMMAND [options]` | Modify certificate resources.
+`cluster-info`    | `kubectl cluster-info [flags]` | Display endpoint information about the master and services in the cluster.
+`completion`    | `kubectl completion SHELL [options]` | Output shell completion code for the specified shell (bash or zsh).
+`config`        | `kubectl config SUBCOMMAND [flags]` | Modifies kubeconfig files. See the individual subcommands for details.
+`convert`    | `kubectl convert -f FILENAME [options]` | Convert config files between different API versions. Both YAML and JSON formats are accepted. Note - requires `kubectl-convert` plugin to be installed.
+`cordon`    | `kubectl cordon NODE [options]` | Mark node as unschedulable.
+`cp`    | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | Copy files and directories to and from containers.
+`create`        | `kubectl create -f FILENAME [flags]` | Create one or more resources from a file or stdin.
+`delete`        | <code>kubectl delete (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label &#124; --all]) [flags]</code> | Delete resources either from a file, stdin, or specifying label selectors, names, resource selectors, or resources.
+`describe`    | <code>kubectl describe (-f FILENAME &#124; TYPE [NAME_PREFIX &#124; /NAME &#124; -l label]) [flags]</code> | Display the detailed state of one or more resources.
+`diff`        | `kubectl diff -f FILENAME [flags]`| Diff file or stdin against live configuration.
+`drain`    | `kubectl drain NODE [options]` | Drain node in preparation for maintenance.
+`edit`        | <code>kubectl edit (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [flags]</code> | Edit and update the definition of one or more resources on the server by using the default editor.
+`exec`        | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Execute a command against a container in a pod.
+`explain`    | `kubectl explain  [--recursive=false] [flags]` | Get documentation of various resources. For instance pods, nodes, services, etc.
+`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> | Expose a replication controller, service, or pod as a new Kubernetes service.
+`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> | List one or more resources.
+`kustomize`    | `kubectl kustomize <dir> [flags] [options]` | List a set of API resources generated from instructions in a kustomization.yaml file. The argument must be the path to the directory containing the file, or a git repository URL with a path suffix specifying same with respect to the repository root.
+`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> | Add or update the labels of one or more resources.
+`logs`        | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Print the logs for a container in a pod.
+`options`    | `kubectl options` | List of global command-line options, which apply to all commands.
+`patch`        | <code>kubectl patch (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --patch PATCH [flags]</code> | Update one or more fields of a resource by using the strategic merge patch process.
+`plugin`    | `kubectl plugin [flags] [options]` | Provides utilities for interacting with plugins.
+`port-forward`    | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | Forward one or more local ports to a pod.
+`proxy`        | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Run a proxy to the Kubernetes API server.
+`replace`        | `kubectl replace -f FILENAME` | Replace a resource from a file or stdin.
+`rollout`    | `kubectl rollout SUBCOMMAND [options]` | Manage the rollout of a resource. Valid resource types include: deployments, daemonsets and statefulsets.
+`run`        | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server&#124;client&#124;none] [--overrides=inline-json] [flags]</code> | Run a specified image on the cluster.
+`scale`        | <code>kubectl scale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | Update the size of the specified replication controller.
+`set`    | `kubectl set SUBCOMMAND [options]` | Configure application resources.
+`taint`    | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | Update the taints on one or more nodes.
+`top`    | `kubectl top [flags] [options]` | Display Resource (CPU/Memory/Storage) usage.
+`uncordon`    | `kubectl uncordon NODE [options]` | Mark node as schedulable.
+`version`        | `kubectl version [--client] [flags]` | Display the Kubernetes version running on the client and server.
+`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> | Experimental: Wait for a specific condition on one or many resources.
+
+To learn more about command operations, see the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation.
+
+## Resource types
+
+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.19.1.)
+
+| 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 |
+| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim |
+| `persistentvolumes` | `pv` | | false | PersistentVolume |
+| `pods` | `po` | | true | Pod |
+| `podtemplates` | | | true | PodTemplate |
+| `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 |
+| `apiservices` | | apiregistration.k8s.io | false | APIService |
+| `controllerrevisions` | | apps | true | ControllerRevision |
+| `daemonsets` | `ds` | apps | true | DaemonSet |
+| `deployments` | `deploy` | apps | true | Deployment |
+| `replicasets` | `rs` | apps | true | ReplicaSet |
+| `statefulsets` | `sts` | apps | true | StatefulSet |
+| `tokenreviews` | | authentication.k8s.io | false | TokenReview |
+| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview |
+| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview |
+| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview |
+| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview |
+| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler |
+| `cronjobs` | `cj` | batch | true | CronJob |
+| `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 |
+| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole |
+| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding |
+| `roles` | | rbac.authorization.k8s.io | true | Role |
+| `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 |
+| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
+
+## Output options
+
+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/reference/kubectl/kubectl/) reference documentation.
+
+### Formatting output
+
+The default output format for all `kubectl` commands is the human readable plain-text format. To output details to your terminal window in a specific format, you can add either the `-o` or `--output` flags to a supported `kubectl` command.
+
+#### Syntax
+
+```shell
+kubectl [command] [TYPE] [NAME] -o <output_format>
+```
+
+Depending on the `kubectl` operation, the following output formats are supported:
+
+Output format | Description
+--------------| -----------
+`-o custom-columns=<spec>` | Print a table using a comma separated list of [custom columns](#custom-columns).
+`-o custom-columns-file=<filename>` | Print a table using the [custom columns](#custom-columns) template in the `<filename>` file.
+`-o json`     | Output a JSON formatted API object.
+`-o jsonpath=<template>` | Print the fields defined in a [jsonpath](/docs/reference/kubectl/jsonpath/) expression.
+`-o jsonpath-file=<filename>` | Print the fields defined by the [jsonpath](/docs/reference/kubectl/jsonpath/) expression in the `<filename>` file.
+`-o name`     | Print only the resource name and nothing else.
+`-o wide`     | Output in the plain-text format with any additional information. For pods, the node name is included.
+`-o yaml`     | Output a YAML formatted API object.
+
+##### Example
+
+In this example, the following command outputs the details for a single pod as a YAML formatted object:
+
+```shell
+kubectl get pod web-pod-13je7 -o yaml
+```
+
+Remember: See the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation
+for details about which output format is supported by each command.
+
+#### Custom columns
+
+To define custom columns and output only the details that you want into a table, you can use the `custom-columns` option.
+You can choose to define the custom columns inline or use a template file: `-o custom-columns=<spec>` or `-o custom-columns-file=<filename>`.
+
+##### Examples
+
+Inline:
+
+```shell
+kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
+```
+
+Template file:
+
+```shell
+kubectl get pods <pod-name> -o custom-columns-file=template.txt
+```
+
+where the `template.txt` file contains:
+
+```
+NAME          RSRC
+metadata.name metadata.resourceVersion
+```
+The result of running either command is similar to:
+
+```
+NAME           RSRC
+submit-queue   610995
+```
+
+#### Server-side columns
+
+`kubectl` supports receiving specific column information from the server about objects.
+This means that for any given resource, the server will return columns and rows relevant to that resource, for the client to print.
+This allows for consistent human-readable output across clients used against the same cluster, by having the server encapsulate the details of printing.
+
+This feature is enabled by default. To disable it, add the
+`--server-print=false` flag to the `kubectl get` command.
+
+##### Examples
+
+To print information about the status of a pod, use a command like the following:
+
+```shell
+kubectl get pods <pod-name> --server-print=false
+```
+
+The output is similar to:
+
+```
+NAME       AGE
+pod-name   1m
+```
+
+### Sorting list objects
+
+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.
+
+#### Syntax
+
+```shell
+kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>
+```
+
+##### Example
+
+To print a list of pods sorted by name, you run:
+
+```shell
+kubectl get pods --sort-by=.metadata.name
+```
+
+## Examples: Common operations
+
+Use the following set of examples to help you familiarize yourself with running the commonly used `kubectl` operations:
+
+`kubectl apply` - Apply or Update a resource from a file or stdin.
+
+```shell
+# Create a service using the definition in example-service.yaml.
+kubectl apply -f example-service.yaml
+
+# Create a replication controller using the definition in example-controller.yaml.
+kubectl apply -f example-controller.yaml
+
+# Create the objects that are defined in any .yaml, .yml, or .json file within the <directory> directory.
+kubectl apply -f <directory>
+```
+
+`kubectl get` - List one or more resources.
+
+```shell
+# List all pods in plain-text output format.
+kubectl get pods
+
+# List all pods in plain-text output format and include additional information (such as node name).
+kubectl get pods -o wide
+
+# List the replication controller with the specified name in plain-text output format. Tip: You can shorten and replace the 'replicationcontroller' resource type with the alias 'rc'.
+kubectl get replicationcontroller <rc-name>
+
+# List all replication controllers and services together in plain-text output format.
+kubectl get rc,services
+
+# List all daemon sets in plain-text output format.
+kubectl get ds
+
+# List all pods running on node server01
+kubectl get pods --field-selector=spec.nodeName=server01
+```
+
+`kubectl describe` - Display detailed state of one or more resources, including the uninitialized ones by default.
+
+```shell
+# Display the details of the node with name <node-name>.
+kubectl describe nodes <node-name>
+
+# Display the details of the pod with name <pod-name>.
+kubectl describe pods/<pod-name>
+
+# Display the details of all the pods that are managed by the replication controller named <rc-name>.
+# Remember: Any pods that are created by the replication controller get prefixed with the name of the replication controller.
+kubectl describe pods <rc-name>
+
+# Describe all pods
+kubectl describe pods
+```
+
+{{< note >}}
+The `kubectl get` command is usually used for retrieving one or more
+resources of the same resource type. It features a rich set of flags that allows
+you to customize the output format using the `-o` or `--output` flag, for example.
+You can specify the `-w` or `--watch` flag to start watching updates to a particular
+object. The `kubectl describe` command is more focused on describing the many
+related aspects of a specified resource. It may invoke several API calls to the
+API server to build a view for the user. For example, the `kubectl describe node`
+command retrieves not only the information about the node, but also a summary of
+the pods running on it, the events generated for the node etc.
+{{< /note >}}
+
+`kubectl delete` - Delete resources either from a file, stdin, or specifying label selectors, names, resource selectors, or resources.
+
+```shell
+# Delete a pod using the type and name specified in the pod.yaml file.
+kubectl delete -f pod.yaml
+
+# Delete all the pods and services that have the label '<label-key>=<label-value>'.
+kubectl delete pods,services -l <label-key>=<label-value>
+
+# Delete all pods, including uninitialized ones.
+kubectl delete pods --all
+```
+
+`kubectl exec` - Execute a command against a container in a pod.
+
+```shell
+# Get output from running 'date' from pod <pod-name>. By default, output is from the first container.
+kubectl exec <pod-name> -- date
+
+# Get output from running 'date' in container <container-name> of pod <pod-name>.
+kubectl exec <pod-name> -c <container-name> -- date
+
+# 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 logs` - Print the logs for a container in a pod.
+
+```shell
+# Return a snapshot of the logs from pod <pod-name>.
+kubectl logs <pod-name>
+
+# Start streaming the logs from pod <pod-name>. This is similar to the 'tail -f' Linux command.
+kubectl logs -f <pod-name>
+```
+
+`kubectl diff` - View a diff of the proposed updates to a cluster.
+
+```shell
+# Diff resources included in "pod.json".
+kubectl diff -f pod.json
+
+# Diff file read from stdin.
+cat service.yaml | kubectl diff -f -
+```
+
+## Examples: Creating and using plugins
+
+Use the following set of examples to help you familiarize yourself with writing and using `kubectl` plugins:
+
+```shell
+# create a simple plugin in any language and name the resulting executable file
+# so that it begins with the prefix "kubectl-"
+cat ./kubectl-hello
+```
+```shell
+#!/bin/sh
+
+# this plugin prints the words "hello world"
+echo "hello world"
+```
+With a plugin written, let's make it executable:
+```bash
+chmod a+x ./kubectl-hello
+
+# and move it to a location in our PATH
+sudo mv ./kubectl-hello /usr/local/bin
+sudo chown root:root /usr/local/bin
+
+# You have now created and "installed" a kubectl plugin.
+# You can begin using this plugin by invoking it from kubectl as if it were a regular command
+kubectl hello
+```
+```
+hello world
+```
+
+```shell
+# You can "uninstall" a plugin, by removing it from the folder in your
+# $PATH where you placed it
+sudo rm /usr/local/bin/kubectl-hello
+```
+
+In order to view all of the plugins that are available to `kubectl`, use
+the `kubectl plugin list` subcommand:
+
+```shell
+kubectl plugin list
+```
+The output is similar to:
+```
+The following kubectl-compatible plugins are available:
+
+/usr/local/bin/kubectl-hello
+/usr/local/bin/kubectl-foo
+/usr/local/bin/kubectl-bar
+```
+
+`kubectl plugin list` also warns you about plugins that are not
+executable, or that are shadowed by other plugins; for example:
+```shell
+sudo chmod -x /usr/local/bin/kubectl-foo # remove execute permission
+kubectl plugin list
+```
+```
+The following kubectl-compatible plugins are available:
+
+/usr/local/bin/kubectl-hello
+/usr/local/bin/kubectl-foo
+  - warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
+/usr/local/bin/kubectl-bar
+
+error: one plugin warning was found
+```
+
+You can think of plugins as a means to build more complex functionality on top
+of the existing kubectl commands:
+
+```shell
+cat ./kubectl-whoami
+```
+The next few examples assume that you already made `kubectl-whoami` have
+the following contents:
+```shell
+#!/bin/bash
+
+# this plugin makes use of the `kubectl config` command in order to output
+# information about the current user, based on the currently selected context
+kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
+```
+
+Running the above command gives you an output containing the user for the
+current context in your KUBECONFIG file:
+
+```shell
+# make the file executable
+sudo chmod +x ./kubectl-whoami
+
+# and move it into your PATH
+sudo mv ./kubectl-whoami /usr/local/bin
+
+kubectl whoami
+Current user: plugins-user
+```
+
+## {{% heading "whatsnext" %}}
+
+* Read the `kubectl` reference documentation:
+  * the kubectl [command reference](/docs/reference/kubectl/kubectl/)
+  * the [command line arguments](/docs/reference/generated/kubectl/kubectl-commands/) reference
+* Learn about [`kubectl` usage conventions](/docs/reference/kubectl/conventions/)
+* Read about [JSONPath support](/docs/reference/kubectl/jsonpath/) in kubectl
+* Read about how to [extend kubectl with plugins](/docs/tasks/extend-kubectl/kubectl-plugins)
+  * To find out more about plugins, take a look at the [example CLI plugin](https://github.com/kubernetes/sample-cli-plugin).
@@ -5,6 +5,7 @@ reviewers:
 - krousey
 - clove
 content_type: concept
+weight: 10 # highlight it
 card:
  name: reference
  weight: 30
@@ -423,7 +424,7 @@ kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.
 kubectl get pods -A -o=custom-columns='DATA:metadata.*'
 ```

-More examples in the kubectl [reference documentation](/docs/reference/kubectl/overview/#custom-columns).
+More examples in the kubectl [reference documentation](/docs/reference/kubectl/#custom-columns).

 ### Kubectl output verbosity and debugging

@@ -444,7 +445,7 @@ Verbosity | Description

 ## {{% heading "whatsnext" %}}

-* Read the [kubectl overview](/docs/reference/kubectl/overview/) and learn about [JsonPath](/docs/reference/kubectl/jsonpath).
+* Read the [kubectl overview](/docs/reference/kubectl/) and learn about [JsonPath](/docs/reference/kubectl/jsonpath).

 * See [kubectl](/docs/reference/kubectl/kubectl/) options.

@@ -1,7 +1,6 @@
 ---
 title: JSONPath Support
 content_type: concept
-weight: 25
 ---

 <!-- overview -->
@@ -1,5 +1,6 @@
 ---
 title: kubectl Commands
+weight: 20
 ---

 [kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/)
@@ -1,548 +0,0 @@
---
-reviewers:
- hw-qiaolei
-title: Overview of kubectl
-content_type: concept
-weight: 20
-card:
-  name: reference
-  weight: 20
---
-
-<!-- overview -->
-The kubectl command line tool lets you control Kubernetes clusters.
-For configuration, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory.
-You can specify other [kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
-files by setting the KUBECONFIG environment variable or by setting the
-[`--kubeconfig`](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) flag.
-
-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/tools/).
-
-<!-- body -->
-
-## Syntax
-
-Use the following syntax to run `kubectl` commands from your terminal window:
-
-```shell
-kubectl [command] [TYPE] [NAME] [flags]
-```
-
-where `command`, `TYPE`, `NAME`, and `flags` are:
-
-* `command`: Specifies the operation that you want to perform on one or more resources, 
-for example `create`, `get`, `describe`, `delete`.
-
-* `TYPE`: Specifies the [resource type](#resource-types). Resource types are case-insensitive and
-  you can specify the singular, plural, or abbreviated forms.
-  For example, the following commands produce the same output:
-
-   ```shell
-   kubectl get pod pod1
-   kubectl get pods pod1
-   kubectl get po pod1
-   ```
-
-* `NAME`: Specifies the name of the resource. Names are case-sensitive. If the name is omitted, details for all resources are displayed, for example `kubectl get pods`.
-
-   When performing an operation on multiple resources, you can specify each resource by type and name or specify one or more files:
-
-   * 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-configuration-tips) since YAML tends to be more user-friendly, especially for configuration files.<br/>
-     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/>
-
-{{< caution >}}
-Flags that you specify from the command line override default values and any corresponding environment variables.
-{{< /caution >}}
-
-If you need help, run `kubectl help` from the terminal window.
-
-## In-cluster authentication and namespace overrides
-
-By default `kubectl` will first determine if it is running within a pod, and thus in a cluster. It starts by checking for the `KUBERNETES_SERVICE_HOST` and `KUBERNETES_SERVICE_PORT` environment variables and the existence of a service account token file at `/var/run/secrets/kubernetes.io/serviceaccount/token`. If all three are found in-cluster authentication is assumed.
-
-To maintain backwards compatibility, if the `POD_NAMESPACE` environment variable is set during in-cluster authentication it will override the default namespace from the service account token. Any manifests or tools relying on namespace defaulting will be affected by this.
-
-**`POD_NAMESPACE` environment variable**
-
-If the `POD_NAMESPACE` environment variable is set, cli operations on namespaced resources will default to the variable value. For example, if the variable is set to `seattle`, `kubectl get pods` would return pods in the `seattle` namespace. This is because pods are a namespaced resource, and no namespace was provided in the command. Review the output of `kubectl api-resources` to determine if a resource is namespaced. 
-
-Explicit use of `--namespace <value>` overrides this behavior. 
-
-**How kubectl handles ServiceAccount tokens**
-
-If:
-* there is Kubernetes service account token file mounted at
-  `/var/run/secrets/kubernetes.io/serviceaccount/token`, and
-* the `KUBERNETES_SERVICE_HOST` environment variable is set, and
-* the `KUBERNETES_SERVICE_PORT` environment variable is set, and
-* you don't explicitly specify a namespace on the kubectl command line
-
-then kubectl assumes it is running in your cluster. The kubectl tool looks up the
-namespace of that ServiceAccount (this is the same as the namespace of the Pod)
-and acts against that namespace. This is different from what happens outside of a
-cluster; when kubectl runs outside a cluster and you don't specify a namespace,
-the kubectl command acts against the `default` namespace.
-
-## Operations
-
-The following table includes short descriptions and the general syntax for all of the `kubectl` operations:
-
-Operation       | Syntax    |       Description
-------------------- | -------------------- | --------------------
-`alpha`    | `kubectl alpha SUBCOMMAND [flags]` | List the available commands that correspond to alpha features, which are not enabled in Kubernetes clusters by default.
-`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> | Add or update the annotations of one or more resources.
-`api-resources`    | `kubectl api-resources [flags]` | List the API resources that are available.
-`api-versions`    | `kubectl api-versions [flags]` | List the API versions that are available.
-`apply`            | `kubectl apply -f FILENAME [flags]`| Apply a configuration change to a resource from a file or stdin.
-`attach`        | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | Attach to a running container either to view the output stream or interact with the container (stdin).
-`auth`    | `kubectl auth [flags] [options]` | Inspect authorization.
-`autoscale`    | <code>kubectl autoscale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]</code> | Automatically scale the set of pods that are managed by a replication controller.
-`certificate`    | `kubectl certificate SUBCOMMAND [options]` | Modify certificate resources.
-`cluster-info`    | `kubectl cluster-info [flags]` | Display endpoint information about the master and services in the cluster.
-`completion`    | `kubectl completion SHELL [options]` | Output shell completion code for the specified shell (bash or zsh).
-`config`        | `kubectl config SUBCOMMAND [flags]` | Modifies kubeconfig files. See the individual subcommands for details.
-`convert`    | `kubectl convert -f FILENAME [options]` | Convert config files between different API versions. Both YAML and JSON formats are accepted. Note - requires `kubectl-convert` plugin to be installed.
-`cordon`    | `kubectl cordon NODE [options]` | Mark node as unschedulable.
-`cp`    | `kubectl cp <file-spec-src> <file-spec-dest> [options]` | Copy files and directories to and from containers.
-`create`        | `kubectl create -f FILENAME [flags]` | Create one or more resources from a file or stdin.
-`delete`        | <code>kubectl delete (-f FILENAME &#124; TYPE [NAME &#124; /NAME &#124; -l label &#124; --all]) [flags]</code> | Delete resources either from a file, stdin, or specifying label selectors, names, resource selectors, or resources.
-`describe`    | <code>kubectl describe (-f FILENAME &#124; TYPE [NAME_PREFIX &#124; /NAME &#124; -l label]) [flags]</code> | Display the detailed state of one or more resources.
-`diff`        | `kubectl diff -f FILENAME [flags]`| Diff file or stdin against live configuration.
-`drain`    | `kubectl drain NODE [options]` | Drain node in preparation for maintenance.
-`edit`        | <code>kubectl edit (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) [flags]</code> | Edit and update the definition of one or more resources on the server by using the default editor.
-`exec`        | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | Execute a command against a container in a pod.
-`explain`    | `kubectl explain  [--recursive=false] [flags]` | Get documentation of various resources. For instance pods, nodes, services, etc.
-`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> | Expose a replication controller, service, or pod as a new Kubernetes service.
-`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> | List one or more resources.
-`kustomize`    | `kubectl kustomize <dir> [flags] [options]` | List a set of API resources generated from instructions in a kustomization.yaml file. The argument must be the path to the directory containing the file, or a git repository URL with a path suffix specifying same with respect to the repository root.
-`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> | Add or update the labels of one or more resources.
-`logs`        | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | Print the logs for a container in a pod.
-`options`    | `kubectl options` | List of global command-line options, which apply to all commands.
-`patch`        | <code>kubectl patch (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --patch PATCH [flags]</code> | Update one or more fields of a resource by using the strategic merge patch process.
-`plugin`    | `kubectl plugin [flags] [options]` | Provides utilities for interacting with plugins.
-`port-forward`    | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | Forward one or more local ports to a pod.
-`proxy`        | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | Run a proxy to the Kubernetes API server.
-`replace`        | `kubectl replace -f FILENAME` | Replace a resource from a file or stdin.
-`rollout`    | `kubectl rollout SUBCOMMAND [options]` | Manage the rollout of a resource. Valid resource types include: deployments, daemonsets and statefulsets.
-`run`        | <code>kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server&#124;client&#124;none] [--overrides=inline-json] [flags]</code> | Run a specified image on the cluster.
-`scale`        | <code>kubectl scale (-f FILENAME &#124; TYPE NAME &#124; TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags]</code> | Update the size of the specified replication controller.
-`set`    | `kubectl set SUBCOMMAND [options]` | Configure application resources.
-`taint`    | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | Update the taints on one or more nodes.
-`top`    | `kubectl top [flags] [options]` | Display Resource (CPU/Memory/Storage) usage.
-`uncordon`    | `kubectl uncordon NODE [options]` | Mark node as schedulable.
-`version`        | `kubectl version [--client] [flags]` | Display the Kubernetes version running on the client and server.
-`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> | Experimental: Wait for a specific condition on one or many resources.
-
-To learn more about command operations, see the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation.
-
-## Resource types
-
-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.19.1.)
-
-| 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 |
-| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim |
-| `persistentvolumes` | `pv` | | false | PersistentVolume |
-| `pods` | `po` | | true | Pod |
-| `podtemplates` | | | true | PodTemplate |
-| `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 |
-| `apiservices` | | apiregistration.k8s.io | false | APIService |
-| `controllerrevisions` | | apps | true | ControllerRevision |
-| `daemonsets` | `ds` | apps | true | DaemonSet |
-| `deployments` | `deploy` | apps | true | Deployment |
-| `replicasets` | `rs` | apps | true | ReplicaSet |
-| `statefulsets` | `sts` | apps | true | StatefulSet |
-| `tokenreviews` | | authentication.k8s.io | false | TokenReview |
-| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview |
-| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview |
-| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview |
-| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview |
-| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler |
-| `cronjobs` | `cj` | batch | true | CronJob |
-| `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 |
-| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole |
-| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding |
-| `roles` | | rbac.authorization.k8s.io | true | Role |
-| `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 |
-| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment |
-
-## Output options
-
-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/reference/kubectl/kubectl/) reference documentation.
-
-### Formatting output
-
-The default output format for all `kubectl` commands is the human readable plain-text format. To output details to your terminal window in a specific format, you can add either the `-o` or `--output` flags to a supported `kubectl` command.
-
-#### Syntax
-
-```shell
-kubectl [command] [TYPE] [NAME] -o <output_format>
-```
-
-Depending on the `kubectl` operation, the following output formats are supported:
-
-Output format | Description
--------------| -----------
-`-o custom-columns=<spec>` | Print a table using a comma separated list of [custom columns](#custom-columns).
-`-o custom-columns-file=<filename>` | Print a table using the [custom columns](#custom-columns) template in the `<filename>` file.
-`-o json`     | Output a JSON formatted API object.
-`-o jsonpath=<template>` | Print the fields defined in a [jsonpath](/docs/reference/kubectl/jsonpath/) expression.
-`-o jsonpath-file=<filename>` | Print the fields defined by the [jsonpath](/docs/reference/kubectl/jsonpath/) expression in the `<filename>` file.
-`-o name`     | Print only the resource name and nothing else.
-`-o wide`     | Output in the plain-text format with any additional information. For pods, the node name is included.
-`-o yaml`     | Output a YAML formatted API object.
-
-##### Example
-
-In this example, the following command outputs the details for a single pod as a YAML formatted object:
-
-```shell
-kubectl get pod web-pod-13je7 -o yaml
-```
-
-Remember: See the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation
-for details about which output format is supported by each command.
-
-#### Custom columns
-
-To define custom columns and output only the details that you want into a table, you can use the `custom-columns` option.
-You can choose to define the custom columns inline or use a template file: `-o custom-columns=<spec>` or `-o custom-columns-file=<filename>`.
-
-##### Examples
-
-Inline:
-
-```shell
-kubectl get pods <pod-name> -o custom-columns=NAME:.metadata.name,RSRC:.metadata.resourceVersion
-```
-
-Template file:
-
-```shell
-kubectl get pods <pod-name> -o custom-columns-file=template.txt
-```
-
-where the `template.txt` file contains:
-
-```
-NAME          RSRC
-metadata.name metadata.resourceVersion
-```
-The result of running either command is similar to:
-
-```
-NAME           RSRC
-submit-queue   610995
-```
-
-#### Server-side columns
-
-`kubectl` supports receiving specific column information from the server about objects.
-This means that for any given resource, the server will return columns and rows relevant to that resource, for the client to print.
-This allows for consistent human-readable output across clients used against the same cluster, by having the server encapsulate the details of printing.
-
-This feature is enabled by default. To disable it, add the
-`--server-print=false` flag to the `kubectl get` command.
-
-##### Examples
-
-To print information about the status of a pod, use a command like the following:
-
-```shell
-kubectl get pods <pod-name> --server-print=false
-```
-
-The output is similar to:
-
-```
-NAME       AGE
-pod-name   1m
-```
-
-### Sorting list objects
-
-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.
-
-#### Syntax
-
-```shell
-kubectl [command] [TYPE] [NAME] --sort-by=<jsonpath_exp>
-```
-
-##### Example
-
-To print a list of pods sorted by name, you run:
-
-```shell
-kubectl get pods --sort-by=.metadata.name
-```
-
-## Examples: Common operations
-
-Use the following set of examples to help you familiarize yourself with running the commonly used `kubectl` operations:
-
-`kubectl apply` - Apply or Update a resource from a file or stdin.
-
-```shell
-# Create a service using the definition in example-service.yaml.
-kubectl apply -f example-service.yaml
-
-# Create a replication controller using the definition in example-controller.yaml.
-kubectl apply -f example-controller.yaml
-
-# Create the objects that are defined in any .yaml, .yml, or .json file within the <directory> directory.
-kubectl apply -f <directory>
-```
-
-`kubectl get` - List one or more resources.
-
-```shell
-# List all pods in plain-text output format.
-kubectl get pods
-
-# List all pods in plain-text output format and include additional information (such as node name).
-kubectl get pods -o wide
-
-# List the replication controller with the specified name in plain-text output format. Tip: You can shorten and replace the 'replicationcontroller' resource type with the alias 'rc'.
-kubectl get replicationcontroller <rc-name>
-
-# List all replication controllers and services together in plain-text output format.
-kubectl get rc,services
-
-# List all daemon sets in plain-text output format.
-kubectl get ds
-
-# List all pods running on node server01
-kubectl get pods --field-selector=spec.nodeName=server01
-```
-
-`kubectl describe` - Display detailed state of one or more resources, including the uninitialized ones by default.
-
-```shell
-# Display the details of the node with name <node-name>.
-kubectl describe nodes <node-name>
-
-# Display the details of the pod with name <pod-name>.
-kubectl describe pods/<pod-name>
-
-# Display the details of all the pods that are managed by the replication controller named <rc-name>.
-# Remember: Any pods that are created by the replication controller get prefixed with the name of the replication controller.
-kubectl describe pods <rc-name>
-
-# Describe all pods
-kubectl describe pods
-```
-
-{{< note >}}
-The `kubectl get` command is usually used for retrieving one or more
-resources of the same resource type. It features a rich set of flags that allows
-you to customize the output format using the `-o` or `--output` flag, for example.
-You can specify the `-w` or `--watch` flag to start watching updates to a particular
-object. The `kubectl describe` command is more focused on describing the many
-related aspects of a specified resource. It may invoke several API calls to the
-API server to build a view for the user. For example, the `kubectl describe node`
-command retrieves not only the information about the node, but also a summary of
-the pods running on it, the events generated for the node etc.
-{{< /note >}}
-
-`kubectl delete` - Delete resources either from a file, stdin, or specifying label selectors, names, resource selectors, or resources.
-
-```shell
-# Delete a pod using the type and name specified in the pod.yaml file.
-kubectl delete -f pod.yaml
-
-# Delete all the pods and services that have the label '<label-key>=<label-value>'.
-kubectl delete pods,services -l <label-key>=<label-value>
-
-# Delete all pods, including uninitialized ones.
-kubectl delete pods --all
-```
-
-`kubectl exec` - Execute a command against a container in a pod.
-
-```shell
-# Get output from running 'date' from pod <pod-name>. By default, output is from the first container.
-kubectl exec <pod-name> -- date
-
-# Get output from running 'date' in container <container-name> of pod <pod-name>.
-kubectl exec <pod-name> -c <container-name> -- date
-
-# 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 logs` - Print the logs for a container in a pod.
-
-```shell
-# Return a snapshot of the logs from pod <pod-name>.
-kubectl logs <pod-name>
-
-# Start streaming the logs from pod <pod-name>. This is similar to the 'tail -f' Linux command.
-kubectl logs -f <pod-name>
-```
-
-`kubectl diff` - View a diff of the proposed updates to a cluster.
-
-```shell
-# Diff resources included in "pod.json".
-kubectl diff -f pod.json
-
-# Diff file read from stdin.
-cat service.yaml | kubectl diff -f -
-```
-
-## Examples: Creating and using plugins
-
-Use the following set of examples to help you familiarize yourself with writing and using `kubectl` plugins:
-
-```shell
-# create a simple plugin in any language and name the resulting executable file
-# so that it begins with the prefix "kubectl-"
-cat ./kubectl-hello
-```
-```shell
-#!/bin/sh
-
-# this plugin prints the words "hello world"
-echo "hello world"
-```
-With a plugin written, let's make it executable:
-```bash
-chmod a+x ./kubectl-hello
-
-# and move it to a location in our PATH
-sudo mv ./kubectl-hello /usr/local/bin
-sudo chown root:root /usr/local/bin
-
-# You have now created and "installed" a kubectl plugin.
-# You can begin using this plugin by invoking it from kubectl as if it were a regular command
-kubectl hello
-```
-```
-hello world
-```
-
-```shell
-# You can "uninstall" a plugin, by removing it from the folder in your
-# $PATH where you placed it
-sudo rm /usr/local/bin/kubectl-hello
-```
-
-In order to view all of the plugins that are available to `kubectl`, use
-the `kubectl plugin list` subcommand:
-
-```shell
-kubectl plugin list
-```
-The output is similar to:
-```
-The following kubectl-compatible plugins are available:
-
-/usr/local/bin/kubectl-hello
-/usr/local/bin/kubectl-foo
-/usr/local/bin/kubectl-bar
-```
-
-`kubectl plugin list` also warns you about plugins that are not
-executable, or that are shadowed by other plugins; for example:
-```shell
-sudo chmod -x /usr/local/bin/kubectl-foo # remove execute permission
-kubectl plugin list
-```
-```
-The following kubectl-compatible plugins are available:
-
-/usr/local/bin/kubectl-hello
-/usr/local/bin/kubectl-foo
-  - warning: /usr/local/bin/kubectl-foo identified as a plugin, but it is not executable
-/usr/local/bin/kubectl-bar
-
-error: one plugin warning was found
-```
-
-You can think of plugins as a means to build more complex functionality on top
-of the existing kubectl commands:
-
-```shell
-cat ./kubectl-whoami
-```
-The next few examples assume that you already made `kubectl-whoami` have
-the following contents:
-```shell
-#!/bin/bash
-
-# this plugin makes use of the `kubectl config` command in order to output
-# information about the current user, based on the currently selected context
-kubectl config view --template='{{ range .contexts }}{{ if eq .name "'$(kubectl config current-context)'" }}Current user: {{ printf "%s\n" .context.user }}{{ end }}{{ end }}'
-```
-
-Running the above command gives you an output containing the user for the
-current context in your KUBECONFIG file:
-
-```shell
-# make the file executable
-sudo chmod +x ./kubectl-whoami
-
-# and move it into your PATH
-sudo mv ./kubectl-whoami /usr/local/bin
-
-kubectl whoami
-Current user: plugins-user
-```
-
-## {{% heading "whatsnext" %}}
-
-* Start using the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) commands.
-
-* To find out more about plugins, take a look at the [example cli plugin](https://github.com/kubernetes/sample-cli-plugin).
-
@@ -2,6 +2,7 @@
 title: Well-Known Labels, Annotations and Taints
 content_type: concept
 weight: 20
+no_list: true
 ---

 <!-- overview -->
@@ -12,7 +13,7 @@ This document serves both as a reference to the values and as a coordination poi

 <!-- body -->

-## Core
+## Labels, annotations and taints used on API objects

 ### kubernetes.io/arch

@@ -482,6 +483,14 @@ you through the steps you follow to apply a seccomp profile to a Pod or to one o
 its containers. That tutorial covers the supported mechanism for configuring seccomp in Kubernetes,
 based on setting `securityContext` within the Pod's `.spec`.

+## Annotations used for audit
+
+- [`pod-security.kubernetes.io/exempt`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-exempt)
+- [`pod-security.kubernetes.io/enforce-policy`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-enforce-policy)
+- [`pod-security.kubernetes.io/audit-violations`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-audit-violations)
+
+See more details on the [Audit Annotations](/docs/reference/labels-annotations-taints/audit-annotations/) page.
+
 ## kubeadm

 ### kubeadm.alpha.kubernetes.io/cri-socket
@@ -0,0 +1,59 @@
+---
+title: "Audit Annotations"
+weight: 1
+---
+
+<!-- overview -->
+
+This page serves as a reference for the audit annotations of the kubernetes.io
+namespace. These annotations apply to `Event` object from API group
+`audit.k8s.io`.
+
+{{< note >}}
+The following annotations are not used within the Kubernetes API. When you
+[enable auditing](/docs/tasks/debug-application-cluster/audit/) in your cluster,
+audit event data is written using `Event` from API group `audit.k8s.io`.
+The annotations apply to audit events. Audit events are different from objects in the
+[Event API](/docs/reference/kubernetes-api/cluster-resources/event-v1/) (API group
+`events.k8s.io`).
+{{< /note >}}
+
+<!-- body -->
+
+## pod-security.kubernetes.io/exempt
+
+Example: `pod-security.kubernetes.io/exempt: namespace`
+
+Value **must** be one of `user`, `namespace`, or `runtimeClass` which correspond to
+[Pod Security Exemption](/docs/concepts/security/pod-security-admission/#exemptions)
+dimensions. This annotation indicates on which dimension was based the exemption
+from the PodSecurity enforcement.
+
+
+## pod-security.kubernetes.io/enforce-policy
+
+Example: `pod-security.kubernetes.io/enforce-policy: restricted:latest`
+
+Value **must** be `privileged:<version>`, `baseline:<version>`,
+`restricted:<version>` which correspond to [Pod Security
+Standard](/docs/concepts/security/pod-security-standards) levels accompanied by
+a version which **must** be `latest` or a valid Kubernetes version in the format
+`v<MAJOR>.<MINOR>`. This annotations informs about the enforcement level that
+allowed or denied the pod during PodSecurity admission.
+
+See [Pod Security Standards](/docs/concepts/security/pod-security-standards/)
+for more information.
+
+## pod-security.kubernetes.io/audit-violations
+
+Example:  `pod-security.kubernetes.io/audit-violations: would violate
+PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container
+"example" must set securityContext.allowPrivilegeEscalation=false), ...`
+
+Value details an audit policy violation, it contains the
+[Pod Security Standard](/docs/concepts/security/pod-security-standards/) level
+that was transgressed as well as the specific policies on the fields that were
+violated from the PodSecurity enforcement.
+
+See [Pod Security Standards](/docs/concepts/security/pod-security-standards/)
+for more information.
@@ -85,7 +85,7 @@ might have to add an equivalent field or represent it as an annotation.
   * **Beta API versions must be supported for 9 months or 3 releases (whichever is longer) after deprecation**
   * **Alpha API versions may be removed in any release without prior deprecation notice**

-This ensures beta API support covers the [maximum supported version skew of 2 releases](/docs/setup/release/version-skew-policy/).
+This ensures beta API support covers the [maximum supported version skew of 2 releases](/releases/version-skew-policy/).

 {{< note >}}
 There are no current plans for a major version revision of Kubernetes that removes GA APIs.
@@ -231,7 +231,7 @@ See the [list of add-ons](/docs/concepts/cluster-administration/addons/) to expl
 ## {{% heading "whatsnext" %}}


-* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/overview/).
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/).
 * Learn more about `kops` [advanced usage](https://kops.sigs.k8s.io/) for tutorials, best practices and advanced configuration options.
 * Follow `kops` community discussions on Slack: [community discussions](https://github.com/kubernetes/kops#other-ways-to-communicate-with-the-contributors)
 * Contribute to `kops` by addressing or raising an issue [GitHub Issues](https://github.com/kubernetes/kops/issues)
@@ -283,6 +283,15 @@ If your network is not working or CoreDNS is not in the `Running` state, check o
 [troubleshooting guide](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/)
 for `kubeadm`.

+### Managed node labels
+
+By default, kubeadm enables the [NodeRestriction](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
+admission controller that restricts what labels can be self-applied by kubelets on node registration.
+The admission controller documentation covers what labels are permitted to be used with the kubelet `--node-labels` option.
+The `node-role.kubernetes.io/control-plane` label is such a restricted label and kubeadm manually applies it using
+a privileged client after a node has been created. To do that manually you can do the same by using `kubectl label`
+and ensure it is using a privileged kubeconfig such as the kubeadm managed `/etc/kubernetes/admin.conf`.
+
 ### Control plane node isolation

 By default, your cluster will not schedule Pods on the control plane nodes for security
@@ -494,7 +503,7 @@ options.
 * <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/).
+* Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/).
 * 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
@@ -164,10 +164,15 @@ It augments the basic
 [`kubelet.service` for RPM](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/rpm/kubelet/kubelet.service) or
 [`kubelet.service` for DEB](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service):

+{{< note >}}
+The contents below are just an example. If you don't want to use a package manager
+follow the guide outlined in the [Without a package manager](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#k8s-install-2))
+section.
+{{< /note >}}
+
 ```none
 [Service]
-Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf
--kubeconfig=/etc/kubernetes/kubelet.conf"
+Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
 Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
 # This is a file that "kubeadm init" and "kubeadm join" generate at runtime, populating
 the KUBELET_KUBEADM_ARGS variable dynamically
@@ -201,5 +206,3 @@ The DEB and RPM packages shipped with the Kubernetes releases are:
 | `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-sigs/cri-tools). |
-
-
@@ -267,8 +267,8 @@ on Kubernetes dual-stack support see [Dual-stack support with kubeadm](/docs/set

    ```sh
    root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml
-    root@HOST1 $ kubeadm init phase etcd local --config=/tmp/${HOST1}/kubeadmcfg.yaml
-    root@HOST2 $ kubeadm init phase etcd local --config=/tmp/${HOST2}/kubeadmcfg.yaml
+    root@HOST1 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
+    root@HOST2 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml
    ```

 1. Optional: Check the cluster health
@@ -29,7 +29,7 @@ This guide walks you through the steps to configure and deploy a Windows contain
 control plane and a [worker node running Windows Server](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
 * It is important to note that creating and deploying services and workloads on Kubernetes 
 behaves in much the same way for Linux and Windows containers. 
-[Kubectl commands](/docs/reference/kubectl/overview/) to interface with the cluster are identical. 
+[Kubectl commands](/docs/reference/kubectl/) to interface with the cluster are identical. 
 The example in the section below is provided to jumpstart your experience with Windows containers.

 ## Getting Started: Deploying a Windows container
@@ -27,8 +27,8 @@ kubectl config view
 ```

 Many of the [examples](/docs/reference/kubectl/cheatsheet/) provide an introduction to using
-kubectl and complete documentation is found in the
-[kubectl manual](/docs/reference/kubectl/overview/).
+`kubectl`, and complete documentation is found in the
+[kubectl reference](/docs/reference/kubectl/).

 ## Directly accessing the REST API

@@ -31,7 +31,7 @@ kubectl config view
 ```

 Many of the [examples](https://github.com/kubernetes/examples/tree/master/) provide an introduction to using
-kubectl. Complete documentation is found in the [kubectl manual](/docs/reference/kubectl/overview/).
+kubectl. Complete documentation is found in the [kubectl manual](/docs/reference/kubectl/).

 ### Directly accessing the REST API

@@ -43,6 +43,7 @@ first drain the node (or nodes) that you are upgrading. In the case of control p
 they could be running CoreDNS Pods or other critical workloads. For more information see
 [Draining nodes](/docs/tasks/administer-cluster/safely-drain-node/).
 - All containers are restarted after upgrade, because the container spec hash value is changed.
+- To verify that the kubelet service has successfully restarted after the kubelet has been upgraded, you can execute `systemctl status kubelet`  or view the service logs with `journalctl -xeu kubelet`.

 <!-- steps -->

@@ -49,6 +49,24 @@ Rootless Podman is not supported.

 <!-- Supporting rootless podman is discussed in https://github.com/kubernetes/minikube/issues/8719 -->

+## Running Kubernetes inside Unprivileged Containers
+
+{{% thirdparty-content %}}
+
+### sysbox
+
+[Sysbox](https://github.com/nestybox/sysbox) is an open-source container runtime
+(similar to "runc") that supports running system-level workloads such as Docker
+and Kubernetes inside unprivileged containers isolated with the Linux user
+namespace.
+
+See [Sysbox Quick Start Guide: Kubernetes-in-Docker](https://github.com/nestybox/sysbox/blob/master/docs/quickstart/kind.md) for more info.
+
+Sysbox supports running Kubernetes inside unprivileged containers without
+requiring Cgroup v2 and without the `KubeletInUserNamespace` feature gate. It
+does this by exposing specially crafted `/proc` and `/sys` filesystems inside
+the container plus several other advanced OS virtualization techniques.
+
 ## Running Rootless Kubernetes directly on a host

 {{% thirdparty-content %}}
@@ -235,7 +253,7 @@ This feature gate also allows kube-proxy to ignore an error during setting `RLIM
 The `KubeletInUserNamespace` feature gate was introduced in Kubernetes v1.22 with "alpha" status.

 Running kubelet in a user namespace without using this feature gate is also possible
-by mounting a specially crafted proc filesystem, but not officially supported.
+by mounting a specially crafted proc filesystem (as done by [Sysbox](https://github.com/nestybox/sysbox)), but not officially supported.

 ### Configuring kube-proxy

@@ -272,4 +290,3 @@ on the rootlesscontaine.rs website.
 - [Usernetes](https://github.com/rootless-containers/usernetes)
 - [Running K3s with rootless mode](https://rancher.com/docs/k3s/latest/en/advanced/#running-k3s-with-rootless-mode-experimental)
 - [KEP-2033: Kubelet-in-UserNS (aka Rootless mode)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2033-kubelet-in-userns-aka-rootless)
-
@@ -22,7 +22,7 @@ Historically, Kubernetes was written to work specifically with Docker Engine.
 Kubernetes took care of networking and scheduling, relying on Docker Engine for launching
 and running containers (within Pods) on a node. Some information that is relevant to telemetry,
 such as a pod name, is only available from Kubernetes components. Other data, such as container
-metrics, is not the responsibility of the container runtime. Early yelemetry agents needed to query the
+metrics, is not the responsibility of the container runtime. Early telemetry agents needed to query the
 container runtime **and** Kubernetes to report an accurate picture. Over time, Kubernetes gained
 the ability to support multiple runtimes, and now supports any runtime that is compatible with
 the container runtime interface.
@@ -91,7 +91,7 @@ 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
-[the design proposal](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
+[the design proposal](https://git.k8s.io/design-proposals-archive/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
@@ -23,8 +23,6 @@ This task also assumes that you have met the following prerequisites:
     and have [configured PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) for
     applications that need them.

-
-
 <!-- steps -->

 ## (Optional) Configure a disruption budget {#configure-poddisruptionbudget}
@@ -100,95 +98,12 @@ replicas to fall below the specified budget are blocked.

 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.
+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) 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 (more precisely: to attempt to
-*create* an Eviction), you POST an attempted operation. Here's an example:
-
-{{< tabs name="Eviction_example" >}}
-{{% tab name="policy/v1" %}}
-{{< note >}}
-`policy/v1` Eviction is available in v1.22+. Use `policy/v1beta1` with prior releases.
-{{< /note >}}
-
-```json
-{
-  "apiVersion": "policy/v1",
-  "kind": "Eviction",
-  "metadata": {
-    "name": "quux",
-    "namespace": "default"
-  }
-}
-```
-{{% /tab %}}
-{{% tab name="policy/v1beta1" %}}
-{{< note >}}
-Deprecated in v1.22 in favor of `policy/v1`
-{{< /note >}}
-
-```json
-{
-  "apiVersion": "policy/v1beta1",
-  "kind": "Eviction",
-  "metadata": {
-    "name": "quux",
-    "namespace": "default"
-  }
-}
-```
-{{% /tab %}}
-{{< /tabs >}}
-
-You can attempt an eviction using `curl`:
-
-```bash
-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 as if you sent
-  a `DELETE` request to the Pod's URL and received 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.
- 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:
-
- 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.
-
-## 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.
+For more information, see [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/).

 ## {{% heading "whatsnext" %}}

-
 * Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/).

@@ -36,7 +36,7 @@ accomplish commonly used tasks, and [Tutorials](/docs/tutorials/) are more
 comprehensive walkthroughs of real-world, industry-specific, or end-to-end
 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/reference/kubectl/overview/).
+and command-line interfaces (CLIs), such as [`kubectl`](/docs/reference/kubectl/).

 ## Help! My question isn't covered!  I need help now!

@@ -725,7 +725,7 @@ For example:
      properties:
        spec:
          type: object
-          x-kubernetes-validation-rules:
+          x-kubernetes-validations:
            - rule: "self.minReplicas <= self.replicas"
              message: "replicas should be greater than or equal to minReplicas."
            - rule: "self.replicas <= self.maxReplicas"
@@ -829,7 +829,7 @@ Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6
      ...
      openAPIV3Schema:
        type: object
-        x-kubernetes-validation-rules:
+        x-kubernetes-validations:
          - rule: "self.status.availableReplicas >= self.spec.minReplicas"
        properties:
            spec:
@@ -856,7 +856,7 @@ Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6
        properties:
          spec:
            type: object
-            x-kubernetes-validation-rules:
+            x-kubernetes-validations:
              - rule: "has(self.foo)"
            properties:
              ...
@@ -874,7 +874,7 @@ Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6
        properties:
          spec:
            type: object
-            x-kubernetes-validation-rules:
+            x-kubernetes-validations:
              - rule: "self['xyz'].foo > 0"
            additionalProperties:
              ...
@@ -894,7 +894,7 @@ Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6
          ...
          foo:
            type: array
-            x-kubernetes-validation-rules:
+            x-kubernetes-validations:
              - rule: "size(self) == 1"
            items:
              type: string
@@ -912,7 +912,7 @@ Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6
              ...
              foo:
                type: integer
-                x-kubernetes-validation-rules:
+                x-kubernetes-validations:
                - rule: "self > 0"
  ```
 Examples:
@@ -1125,7 +1125,7 @@ with `foo` pruned and defaulted because the field is non-nullable, `bar` maintai

 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.
+The [kubectl](/docs/reference/kubectl/) 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.

 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).
@@ -18,7 +18,7 @@ draft](https://github.com/ietf-wg-acme/acme/).

 {{< note >}}
 Certificates created using the `certificates.k8s.io` API are signed by a
-dedicated CA. It is possible to configure your cluster to use the cluster root
+[dedicated CA](#a-note-to-cluster-administrators). 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.
 {{< /note >}}
@@ -42,16 +42,25 @@ install it via your operating system's software sources, or fetch it from

 ## Trusting TLS in a cluster

-Trusting the custom CA from an application running as a pod usually requires
+Trusting the [custom CA](#a-note-to-cluster-administrators) 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.

-You can distribute the CA certificate as a
-[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap) that your
-pods have access to use.
+{{< note >}}
+Even though the custom CA certificate may be included in the filesystem (in the
+ConfigMap `kube-root-ca.crt`),
+you should not use that certificate authority for any purpose other than to verify internal
+Kubernetes endpoints. An example of an internal Kubernetes endpoint is the
+Service named `kubernetes` in the default namespace.
+
+If you want to use a custom certificate authority for your workloads, you should generate
+that CA separately, and distribute its CA certificate using a 
+[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap) that your pods 
+have access to read.
+{{< /note >}}

 ## Requesting a certificate

@@ -136,7 +136,7 @@ Pod runs a Container based on the provided Docker image.
    ```

 {{< note >}}
-For more information about `kubectl` commands, see the [kubectl overview](/docs/reference/kubectl/overview/).
+For more information about `kubectl` commands, see the [kubectl overview](/docs/reference/kubectl/).
 {{< /note >}}

 ## Create a Service
@@ -8,21 +8,23 @@ weight: 10
 This tutorial applies only for new clusters.
 {{% /alert %}}

-Pod Security admission (PSA) is enabled by default in v1.23 and later, as it [graduated
-to beta](/blog/2021/12/09/pod-security-admission-beta/). Pod Security Admission
+Pod Security admission (PSA) is enabled by default in v1.23 and later, as it
+[graduated to beta](/blog/2021/12/09/pod-security-admission-beta/). Pod Security Admission
 is an admission controller that applies 
-[Pod Security Standards](docs/concepts/security/pod-security-standards/) 
+[Pod Security Standards](/docs/concepts/security/pod-security-standards/) 
 when pods are created. In this tutorial, you will enforce the `baseline` Pod Security Standard,
 one namespace at a time.

 You can also apply Pod Security Standards to multiple namespaces at once at the cluster
-level. For instructions, refer to [Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss).
+level. For instructions, refer to
+[Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss).
+
 ## {{% heading "prerequisites" %}}

 Install the following on your workstation:

 - [KinD](https://kind.sigs.k8s.io/docs/user/quick-start/#installation)
- [kubectl](https://kubernetes.io/docs/tasks/tools/)
+- [kubectl](/docs/tasks/tools/)

 ## Create cluster

@@ -31,7 +33,9 @@ Install the following on your workstation:
   ```shell
   kind create cluster --name psa-ns-level --image kindest/node:v1.23.0
   ```
+
   The output is similar to this:
+
   ```
   Creating cluster "psa-ns-level" ...
    ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 
@@ -49,10 +53,12 @@ Install the following on your workstation:
   ```

 1. Set the kubectl context to the new cluster:
+
   ```shell
   kubectl cluster-info --context kind-psa-ns-level
   ```
   The output is similar to this:
+
   ```
   Kubernetes control plane is running at https://127.0.0.1:50996
   CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
@@ -67,7 +73,9 @@ Create a new namespace called `example`:
 ```shell
 kubectl create ns example
 ```
+
 The output is similar to this:
+
 ```
 namespace/example created
 ```
@@ -89,7 +97,7 @@ namespace/example created
   `warn` and `audit` for `restricted` Pod Security Standards as per the latest
   version (default value)

-    ```
+   ```shell
   kubectl label --overwrite ns example \
     pod-security.kubernetes.io/enforce=baseline \
     pod-security.kubernetes.io/enforce-version=latest \
@@ -117,21 +125,26 @@ namespace/example created
           - containerPort: 80
   EOF
   ```
+
 1. Apply the pod spec to the cluster in `example` namespace:
+
   ```shell
   kubectl apply -n example -f /tmp/pss/nginx-pod.yaml
   ```
   The output is similar to this:
+
   ```
   Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
   pod/nginx created
   ```

 1. Apply the pod spec to the cluster in `default` namespace:
+
   ```shell
   kubectl apply -n default -f /tmp/pss/nginx-pod.yaml
   ```
   Output is similar to this:
+
   ```
   pod/nginx created
   ```
@@ -149,11 +162,13 @@ Run `kind delete cluster -name psa-ns-level` to delete the cluster created.
 - Run a
  [shell script](/examples/security/kind-with-namespace-level-baseline-pod-security.sh)
  to perform all the preceding steps all at once.
+
  1. Create KinD cluster
  2. Create new namespace
  3. Apply `baseline` Pod Security Standard in `enforce` mode while applying
     `restricted` Pod Security Standard also in `warn` and `audit` mode.
  4. Create a new pod with the following pod security standards applied
+
 - [Pod Security Admission](/docs/concepts/security/pod-security-admission/)
 - [Pod Security Standards](/docs/concepts/security/pod-security-standards/)
 - [Apply Pod Security Standards at the cluster level](/docs/tutorials/security/cluster-level-pss/)
@@ -78,10 +78,10 @@ releases may also occur in between these.

 | Monthly Patch Release | Cherry Pick Deadline | Target date |
 | --------------------- | -------------------- | ----------- |
-| February 2022         | 2022-02-11           | 2022-02-16  |
 | March 2022            | 2022-03-11           | 2022-03-16  |
 | April 2022            | 2022-04-08           | 2022-04-13  |
 | May 2022              | 2022-05-13           | 2022-05-18  |
+| June 2022             | 2022-06-10           | 2022-06-15  |

 ## Detailed Release History for Active Branches

@@ -93,6 +93,7 @@ End of Life for **1.23** is **2023-02-28**.

 | Patch Release | Cherry Pick Deadline | Target Date | Note |
 |---------------|----------------------|-------------|------|
+| 1.23.5        | 2022-03-11           | 2022-03-16  |      |
 | 1.23.4        | 2022-02-11           | 2022-02-16  |      |
 | 1.23.3        | 2022-01-24           | 2022-01-25  | [Out-of-Band Release](https://groups.google.com/u/2/a/kubernetes.io/g/dev/c/Xl1sm-CItaY) |
 | 1.23.2        | 2022-01-14           | 2022-01-19  |      |
@@ -106,6 +107,7 @@ End of Life for **1.22** is **2022-10-28**

 | Patch Release | Cherry Pick Deadline | Target Date | Note |
 |---------------|----------------------|-------------|------|
+| 1.22.8        | 2022-03-11           | 2022-03-16  |      |
 | 1.22.7        | 2022-02-11           | 2022-02-16  |      |
 | 1.22.6        | 2022-01-14           | 2022-01-19  |      |
 | 1.22.5        | 2021-12-10           | 2021-12-15  |      |
@@ -122,6 +124,7 @@ End of Life for **1.21** is **2022-06-28**

 | Patch Release | Cherry Pick Deadline | Target Date | Note |
 | ------------- | -------------------- | ----------- | ---------------------------------------------------------------------- |
+| 1.21.11       | 2022-03-11           | 2022-03-16  |                                                                        |
 | 1.21.10       | 2022-02-11           | 2022-02-16  |                                                                        |
 | 1.21.9        | 2022-01-14           | 2022-01-19  |                                                                        |
 | 1.21.8        | 2021-12-10           | 2021-12-15  |                                                                        |
@@ -133,38 +136,13 @@ End of Life for **1.21** is **2022-06-28**
 | 1.21.2        | 2021-06-12           | 2021-06-16  |                                                                        |
 | 1.21.1        | 2021-05-07           | 2021-05-12  | [Regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs) |

-### 1.20
-
-**1.20** enters maintenance mode on **2021-12-28**
-
-End of Life for **1.20** is **2022-02-28**
-
-| Patch Release | Cherry Pick Deadline | Target Date | Note |
-| ------------- | -------------------- | ----------- | ----------------------------------------------------------------------------------- |
-| 1.20.16       | 2022-02-11           | 2022-02-16  | If there is critical/blocker patches to be released                                 |
-| 1.20.15       | 2022-01-14           | 2022-01-19  |                                                                                     |
-| 1.20.14       | 2021-12-10           | 2021-12-15  |                                                                                     |
-| 1.20.13       | 2021-11-12           | 2021-11-17  |                                                                                     |
-| 1.20.12       | 2021-10-22           | 2021-10-27  |                                                                                     |
-| 1.20.11       | 2021-09-10           | 2021-09-15  |                                                                                     |
-| 1.20.10       | 2021-08-07           | 2021-08-11  |                                                                                     |
-| 1.20.9        | 2021-07-10           | 2021-07-14  |                                                                                     |
-| 1.20.8        | 2021-06-12           | 2021-06-16  |                                                                                     |
-| 1.20.7        | 2021-05-07           | 2021-05-12  | [Regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs)              |
-| 1.20.6        | 2021-04-09           | 2021-04-14  |                                                                                     |
-| 1.20.5        | 2021-03-12           | 2021-03-17  |                                                                                     |
-| 1.20.4        | 2021-02-12           | 2021-02-18  |                                                                                     |
-| 1.20.3        | 2021-02-12           | 2021-02-17  | [Conformance Tests Issue](https://groups.google.com/g/kubernetes-dev/c/oUpY9vWgzJo) |
-| 1.20.2        | 2021-01-08           | 2021-01-13  |                                                                                     |
-| 1.20.1        | 2020-12-11           | 2020-12-18  | [Tagging Issue](https://groups.google.com/g/kubernetes-dev/c/dNH2yknlCBA)           |
-
-
 ## Non-Active Branch History

 These releases are no longer supported.

 | Minor Version | Final Patch Release | EOL Date   | Note                                                                   |
 | ------------- | ------------------- | ---------- | ---------------------------------------------------------------------- |
+| 1.20          | 1.20.15             | 2022-02-28 |                                                                        |
 | 1.19          | 1.19.16             | 2021-10-28 |                                                                        |
 | 1.18          | 1.18.20             | 2021-06-18 | Created to resolve regression introduced in 1.18.19                    |
 | 1.18          | 1.18.19             | 2021-05-12 | [Regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs) |
@@ -763,4 +763,4 @@ Puedes ver que el Contenedor fué terminado a causa de `reason:OOM Killed`, dond

 * Lee [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) referencia de API

-* Lee sobre [project quotas](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) en XFS
+* Lee sobre [cuotas de proyecto](https://xfs.org/index.php/XFS_FAQ#Q:_Quota:_Do_quotas_work_on_XFS.3F) en XFS
@@ -3,7 +3,7 @@ kind: CronJob
 metadata:
  name: hello
 spec:
-  schedule: "*/1 * * * *"
+  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
@@ -0,0 +1,60 @@
+---
+title: ローカルでのサービス開発・デバッグ
+content_type: task
+---
+
+<!-- overview -->
+
+Kubernetesアプリケーションは通常、複数の独立したサービスから構成され、それぞれが独自のコンテナで動作しています。これらのサービスをリモートのKubernetesクラスター上で開発・デバッグするには、[get a shell on a running container](/docs/task/debug-application-cluster/get-shell-running-container/)してリモートシェル内でツールを実行しなければならず面倒な場合があります。
+
+`telepresence`は、リモートKubernetesクラスターにサービスをプロキシーしながら、ローカルでサービスを開発・デバッグするプロセスを容易にするためのツールです。
+`telepresence` を使用すると、デバッガーやIDEなどのカスタムツールをローカルサービスで使用でき、ConfigMapやsecret、リモートクラスター上で動作しているサービスへのフルアクセスをサービスに提供します。
+
+このドキュメントでは、リモートクラスタ上で動作しているサービスをローカルで開発・デバッグするために`telepresence`を使用する方法を説明します。
+
+## {{% heading "prerequisites" %}}
+
+* Kubernetesクラスターがインストールされていること
+* クラスターと通信するために `kubectl` が設定されていること
+* [telepresence](https://www.telepresence.io/reference/install)がインストールされていること
+
+<!-- steps -->
+
+## リモートクラスター上でシェルの取得
+
+ターミナルを開いて、引数なしで`telepresence`を実行すると、`telepresence`シェルが表示されます。
+このシェルはローカルで動作し、ローカルのファイルシステムに完全にアクセスすることができます。
+
+この`telepresence`シェルは様々な方法で使用することができます。
+例えば、ラップトップでシェルスクリプトを書いて、それをシェルから直接リアルタイムで実行することができます。これはリモートシェルでもできますが、好みのコードエディターが使えないかもしれませんし、コンテナが終了するとスクリプトは削除されます。
+
+終了してシェルを閉じるには`exit`と入力してください。
+
+## 既存サービスの開発・デバッグ
+
+Kubernetes上でアプリケーションを開発する場合、通常は1つのサービスをプログラミングまたはデバッグすることになります。
+そのサービスは、テストやデバッグのために他のサービスへのアクセスを必要とする場合があります。
+継続的なデプロイメントパイプラインを使用することも一つの選択肢ですが、最速のデプロイメントパイプラインでさえ、プログラムやデバッグサイクルに遅延が発生します。
+
+既存のデプロイメントとtelepresenceプロキシーを交換するには、`--swap-deployment` オプションを使用します。
+スワップすることで、ローカルでサービスを実行し、リモートのKubernetesクラスターに接続することができます。
+リモートクラスター内のサービスは、ローカルで実行されているインスタンスにアクセスできるようになりました。
+
+telepresenceを「--swap-deployment」で実行するには、次のように入力します。
+
+`telepresence --swap-deployment $DEPLOYMENT_NAME`
+
+ここで、$DEPLOYMENT_NAMEは既存のDeploymentの名前です。
+
+このコマンドを実行すると、シェルが起動します。そのシェルで、サービスを起動します。
+そして、ローカルでソースコードの編集を行い、保存すると、すぐに変更が反映されるのを確認できます。
+また、デバッガーやその他のローカルな開発ツールでサービスを実行することもできます。
+
+## {{% heading "whatsnext" %}}
+
+もしハンズオンのチュートリアルに興味があるなら、Google Kubernetes Engine上でGuestbookアプリケーションをローカルに開発する手順を説明した[こちらのチュートリアル](https://cloud.google.com/community/tutorials/developing-services-with-k8s)をチェックしてみてください。
+
+telepresenceには、状況に応じて[numerous proxying options](https://www.telepresence.io/reference/methods)があります。
+
+さらに詳しい情報は、[telepresence website](https://www.telepresence.io)をご覧ください。
+
@@ -11,7 +11,7 @@ slug: kubernetes-gathering-videos
 title: " Kubernetes Gathering Videos "
 date: 2015-03-23
 slug: kubernetes-gathering-videos
-url: /blog/2015/03/Kubernetes-Gathering-Videos
+url: /zh/blog/2015/03/Kubernetes-Gathering-Videos
 ---
 -->

@@ -9,7 +9,7 @@ slug: weekly-kubernetes-community-hangout
 title: " Weekly Kubernetes Community Hangout Notes - March 27 2015 "
 date: 2015-03-28
 slug: weekly-kubernetes-community-hangout
-url: /blog/2015/03/Weekly-Kubernetes-Community-Hangout
+url: /zh/blog/2015/03/Weekly-Kubernetes-Community-Hangout
 ---
 -->

@@ -9,7 +9,7 @@ slug: welcome-to-kubernetes-blog
 title: Welcome to the Kubernetes Blog!
 date: 2015-03-20
 slug: welcome-to-kubernetes-blog
-url: /blog/2015/03/Welcome-To-Kubernetes-Blog
+url: /zh/blog/2015/03/Welcome-To-Kubernetes-Blog
 ---
 -->

@@ -9,7 +9,7 @@ url: /zh/blog/2015/04/Borg-Predecessor-To-Kubernetes
 title: " Borg: The Predecessor to Kubernetes "
 date: 2015-04-23
 slug: borg-predecessor-to-kubernetes
-url: /blog/2015/04/Borg-Predecessor-To-Kubernetes
+url: /zh/blog/2015/04/Borg-Predecessor-To-Kubernetes
 ---
 -->
 <!--
@@ -2,14 +2,14 @@
 title: " 每周 Kubernetes 社区例会笔记 - 2015年4月3日 "
 date: 2015-04-04
 slug: weekly-kubernetes-community-hangout
-url: /blog/2015/04/Weekly-Kubernetes-Community-Hangout
+url: /zh/blog/2015/04/Weekly-Kubernetes-Community-Hangout
 ---
 <!--
 ---
 title: " Weekly Kubernetes Community Hangout Notes - April 3 2015 "
 date: 2015-04-04
 slug: weekly-kubernetes-community-hangout
-url: /blog/2015/04/Weekly-Kubernetes-Community-Hangout
+url: /zh/blog/2015/04/Weekly-Kubernetes-Community-Hangout
 ---
 -->
 <!--
@@ -9,7 +9,7 @@ slug: weekly-kubernetes-community-hangout_17
 title: " Weekly Kubernetes Community Hangout Notes - April 17 2015 "
 date: 2015-04-17
 slug: weekly-kubernetes-community-hangout_17
-url: /blog/2015/04/Weekly-Kubernetes-Community-Hangout_17
+url: /zh/blog/2015/04/Weekly-Kubernetes-Community-Hangout_17
 ---
 -->

@@ -9,7 +9,7 @@ slug: weekly-kubernetes-community-hangout_29
 title: " Weekly Kubernetes Community Hangout Notes - April 24 2015 "
 date: 2015-04-30
 slug: weekly-kubernetes-community-hangout_29
-url: /blog/2015/04/Weekly-Kubernetes-Community-Hangout_29
+url: /zh/blog/2015/04/Weekly-Kubernetes-Community-Hangout_29
 ---

 -->
@@ -3,14 +3,14 @@
 title: " AppC Support for Kubernetes through RKT "
 date: 2015-05-04
 slug: appc-support-for-kubernetes-through-rkt
-url: /blog/2015/05/Appc-Support-For-Kubernetes-Through-Rkt
+url: /zh/blog/2015/05/Appc-Support-For-Kubernetes-Through-Rkt
 ---
 -->
 ---
 title: " 通过 RKT 对 Kubernetes 的 AppC 支持 "
 date: 2015-05-04
 slug: appc-support-for-kubernetes-through-rkt
-url: /blog/2015/05/Appc-Support-For-Kubernetes-Through-Rkt
+url: /zh/blog/2015/05/Appc-Support-For-Kubernetes-Through-Rkt
 ---
 <!--
 We very recently accepted a pull request to the Kubernetes project to add appc support for the Kubernetes community. &nbsp;Appc is a new open container specification that was initiated by CoreOS, and is supported through CoreOS rkt container runtime.
@@ -9,7 +9,7 @@ slug: kubernetes-on-openstack
 title: " Kubernetes on OpenStack "
 date: 2015-05-19
 slug: kubernetes-on-openstack
-url: /blog/2015/05/Kubernetes-On-Openstack
+url: /zh/blog/2015/05/Kubernetes-On-Openstack
 ---
 -->

@@ -9,7 +9,7 @@ slug: weekly-kubernetes-community-hangout
 title: " Weekly Kubernetes Community Hangout Notes - May 1 2015 "
 date: 2015-05-11
 slug: weekly-kubernetes-community-hangout
-url: /blog/2015/05/Weekly-Kubernetes-Community-Hangout
+url: /zh/blog/2015/05/Weekly-Kubernetes-Community-Hangout
 ---
 -->

@@ -9,7 +9,7 @@ slug: slides-cluster-management-with
 title: " Slides: Cluster Management with Kubernetes, talk given at the University of Edinburgh "
 date: 2015-06-26
 slug: slides-cluster-management-with
-url: /blog/2015/06/Slides-Cluster-Management-With
+url: /zh/blog/2015/06/Slides-Cluster-Management-With
 ---
 -->

@@ -7,7 +7,7 @@ slug: announcing-first-kubernetes-enterprise
 title: " Announcing the First Kubernetes Enterprise Training Course "
 date: 2015-07-08
 slug: announcing-first-kubernetes-enterprise
-url: /blog/2015/07/Announcing-First-Kubernetes-Enterprise
+url: /zh/blog/2015/07/Announcing-First-Kubernetes-Enterprise
 --- -->

 <!-- At Google we rely on Linux application containers to run our core infrastructure. Everything from Search to Gmail runs in containers. &nbsp;In fact, we like containers so much that even our Google Compute Engine VMs run in containers! &nbsp;Because containers are critical to our business, we have been working with the community on many of the basic container technologies (from cgroups to Docker’s LibContainer) and even decided to build the next generation of Google’s container scheduling technology, Kubernetes, in the open. -->
@@ -3,7 +3,7 @@
 title: " Weekly Kubernetes Community Hangout Notes - July 31 2015 "
 date: 2015-08-04
 slug: weekly-kubernetes-community-hangout
-url: /blog/2015/08/Weekly-Kubernetes-Community-Hangout
+url: /zh/blog/2015/08/Weekly-Kubernetes-Community-Hangout
 ---
 -->

@@ -11,7 +11,7 @@ url: /blog/2015/08/Weekly-Kubernetes-Community-Hangout
 title: " Kubernetes社区每周环聊笔记-2015年7月31日 "
 date: 2015-08-04
 slug: weekly-kubernetes-community-hangout
-url: /blog/2015/08/Weekly-Kubernetes-Community-Hangout
+url: /zh/blog/2015/08/Weekly-Kubernetes-Community-Hangout
 ---

 <!--
@@ -2,14 +2,14 @@
 title: " Kubernetes 1.1 性能升级，工具改进和社区不断壮大  "
 date: 2015-11-09
 slug: kubernetes-1-1-performance-upgrades-improved-tooling-and-a-growing-community
-url: /blog/2015/11/Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community
+url: /zh/blog/2015/11/Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community
 ---
 <!--
 ---
 title: " Kubernetes 1.1 Performance upgrades, improved tooling and a growing community  "
 date: 2015-11-09
 slug: kubernetes-1-1-performance-upgrades-improved-tooling-and-a-growing-community
-url: /blog/2015/11/Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community
+url: /zh/blog/2015/11/Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community
 ---
 -->
 <!--
@@ -9,7 +9,7 @@ slug: managing-kubernetes-pods-services-and-replication-controllers-with-puppet
 title: " Managing Kubernetes Pods, Services and Replication Controllers with Puppet "
 date: 2015-12-17
 slug: managing-kubernetes-pods-services-and-replication-controllers-with-puppet
-url: /blog/2015/12/Managing-Kubernetes-Pods-Services-And-Replication-Controllers-With-Puppet
+url: /zh/blog/2015/12/Managing-Kubernetes-Pods-Services-And-Replication-Controllers-With-Puppet
 ---
 -->

@@ -2,14 +2,14 @@
 title: " Kubernetes 社区会议记录 - 20160114 "
 date: 2016-01-28
 slug: kubernetes-community-meeting-notes
-url: /blog/2016/01/Kubernetes-Community-Meeting-Notes
+url: /zh/blog/2016/01/Kubernetes-Community-Meeting-Notes
 ---
 <!--
 ---
 title: " Kubernetes Community Meeting Notes - 20160114 "
 date: 2016-01-28
 slug: kubernetes-community-meeting-notes
-url: /blog/2016/01/Kubernetes-Community-Meeting-Notes
+url: /zh/blog/2016/01/Kubernetes-Community-Meeting-Notes
 ---
 -->
 <!--
@@ -11,7 +11,7 @@ slug: simple-leader-election-with-kubernetes
 title: "Kubernetes 和 Docker 简单的 leader election"
 date: 2016-01-11
 slug: simple-leader-election-with-kubernetes
-url: /blog/2016/01/Simple-Leader-Election-With-Kubernetes
+url: /zh/blog/2016/01/Simple-Leader-Election-With-Kubernetes

 <!--
 Kubernetes simplifies the deployment and operational management of services running on clusters. However, it also simplifies the development of these services. In this post we'll see how you can use Kubernetes to easily perform leader election in your distributed application. Distributed applications usually replicate the tasks of a service for reliability and scalability, but often it is necessary to designate one of the replicas as the leader who is responsible for coordination among all of the replicas.
@@ -8,7 +8,7 @@ slug: why-kubernetes-doesnt-use-libnetwork
 title: " Why Kubernetes doesn’t use libnetwork "
 date: 2016-01-14
 slug: why-kubernetes-doesnt-use-libnetwork
-url: /blog/2016/01/Why-Kubernetes-Doesnt-Use-Libnetwork
+url: /zh/blog/2016/01/Why-Kubernetes-Doesnt-Use-Libnetwork
 --- -->

 <!-- Kubernetes has had a very basic form of network plugins since before version 1.0 was released — around the same time as Docker's [libnetwork](https://github.com/docker/libnetwork) and Container Network Model ([CNM](https://github.com/docker/libnetwork/blob/master/docs/design.md)) was introduced. Unlike libnetwork, the Kubernetes plugin system still retains its "alpha" designation. Now that Docker's network plugin support is released and supported, an obvious question we get is why Kubernetes has not adopted it yet. After all, vendors will almost certainly be writing plugins for Docker — we would all be better off using the same drivers, right?   -->
@@ -9,7 +9,7 @@ slug: kubecon-eu-2016-kubernetes-community-in
 title: " KubeCon EU 2016: Kubernetes Community in London "
 date: 2016-02-24
 slug: kubecon-eu-2016-kubernetes-community-in
-url: /blog/2016/02/Kubecon-Eu-2016-Kubernetes-Community-In
+url: /zh/blog/2016/02/Kubecon-Eu-2016-Kubernetes-Community-In
 ---
 -->

@@ -8,7 +8,7 @@ slug: kubernetes-community-meeting-notes
 title: " Kubernetes community meeting notes - 20160204 "
 date: 2016-02-09
 slug: kubernetes-community-meeting-notes
-url: /blog/2016/02/Kubernetes-Community-Meeting-Notes
+url: /zh/blog/2016/02/Kubernetes-Community-Meeting-Notes
 ---
 -->
 <!--
@@ -2,14 +2,14 @@
 title: " 容器世界现状，2016年1月 "
 date: 2016-02-01
 slug: state-of-container-world-january-2016
-url: /blog/2016/02/State-Of-Container-World-January-2016
+url: /zh/blog/2016/02/State-Of-Container-World-January-2016
 ---
 <!--
 ---
 title: " State of the Container World, January 2016 "
 date: 2016-02-01
 slug: state-of-container-world-january-2016
-url: /blog/2016/02/State-Of-Container-World-January-2016
+url: /zh/blog/2016/02/State-Of-Container-World-January-2016
 ---
 -->
 <!--
@@ -2,7 +2,7 @@
 title: "Kubernetes 社区会议记录 - 20160218"
 date: 2016-02-23
 slug: kubernetes-community-meeting-notes_23
-url: /blog/2016/02/kubernetes-community-meeting-notes_23
+url: /zh/blog/2016/02/kubernetes-community-meeting-notes_23
 ---

 <!--
@@ -10,8 +10,8 @@ url: /blog/2016/02/kubernetes-community-meeting-notes_23
 title: " Kubernetes Community Meeting Notes - 20160218 "
 date: 2016-02-23
 slug: kubernetes-community-meeting-notes_23
-url: /blog/2016/02/kubernetes-community-meeting-notes_23
-url: /blog/2016/02/kubernetes-community-meeting-notes_23
+url: /zh/blog/2016/02/kubernetes-community-meeting-notes_23
+url: /zh/blog/2016/02/kubernetes-community-meeting-notes_23
 ---
 -->

@@ -2,14 +2,14 @@
 title: " 在 Rancher 中添加对 Kuernetes 的支持 "
 date: 2016-04-08
 slug: adding-support-for-kubernetes-in-rancher
-url: /blog/2016/04/Adding-Support-For-Kubernetes-In-Rancher
+url: /zh/blog/2016/04/Adding-Support-For-Kubernetes-In-Rancher
 ---
 <!--
 ---
 title: " Adding Support for Kubernetes in Rancher "
 date: 2016-04-08
 slug: adding-support-for-kubernetes-in-rancher
-url: /blog/2016/04/Adding-Support-For-Kubernetes-In-Rancher
+url: /zh/blog/2016/04/Adding-Support-For-Kubernetes-In-Rancher
 ---
 -->
 <!--
@@ -9,7 +9,7 @@ url: /zh/blog/2016/04/Kubernetes-Network-Policy-APIs
 title: " SIG-Networking: Kubernetes Network Policy APIs Coming in 1.3 "
 date: 2016-04-18
 slug: kubernetes-network-policy-apis
-url: /blog/2016/04/Kubernetes-Network-Policy-APIs
+url: /zh/blog/2016/04/Kubernetes-Network-Policy-APIs
 ---
 -->
 <!--
@@ -2,14 +2,14 @@
 title: " SIG-ClusterOps: 提升 Kubernetes 集群的可操作性和互操作性 "
 date: 2016-04-19
 slug: sig-clusterops-promote-operability-and-interoperability-of-k8s-clusters
-url: /blog/2016/04/Sig-Clusterops-Promote-Operability-And-Interoperability-Of-K8S-Clusters
+url: /zh/blog/2016/04/Sig-Clusterops-Promote-Operability-And-Interoperability-Of-K8S-Clusters
 ---
 <!--
 ---
 title: " SIG-ClusterOps: Promote operability and interoperability of Kubernetes clusters "
 date: 2016-04-19
 slug: sig-clusterops-promote-operability-and-interoperability-of-k8s-clusters
-url: /blog/2016/04/Sig-Clusterops-Promote-Operability-And-Interoperability-Of-K8S-Clusters
+url: /zh/blog/2016/04/Sig-Clusterops-Promote-Operability-And-Interoperability-Of-K8S-Clusters
 ---
 -->
 <!--
@@ -2,14 +2,14 @@
 title: " CoreOS Fest 2016: CoreOS 和 Kubernetes 在柏林（和旧金山）社区见面会 "
 date: 2016-05-03
 slug: coreosfest2016-kubernetes-community
-url: /blog/2016/05/Coreosfest2016-Kubernetes-Community
+url: /zh/blog/2016/05/Coreosfest2016-Kubernetes-Community
 ---
 <!--
 ---
 title: " CoreOS Fest 2016: CoreOS and Kubernetes Community meet in Berlin (& San Francisco) "
 date: 2016-05-03
 slug: coreosfest2016-kubernetes-community
-url: /blog/2016/05/Coreosfest2016-Kubernetes-Community
+url: /zh/blog/2016/05/Coreosfest2016-Kubernetes-Community
 ---
 -->
 <!--
@@ -2,14 +2,14 @@
 题目: " 将端到端的 Kubernetes 测试引入 Azure （第二部分） "
 日期: 2016-07-18
 slug: bringing-end-to-end-kubernetes-testing-to-azure-2
-url: /blog/2016/07/Bringing-End-To-End-Kubernetes-Testing-To-Azure-2
+url: /zh/blog/2016/07/Bringing-End-To-End-Kubernetes-Testing-To-Azure-2
 ---
 <!--
 ---
 title: " Bringing End-to-End Kubernetes Testing to Azure (Part 2) "
 date: 2016-07-18
 slug: bringing-end-to-end-kubernetes-testing-to-azure-2
-url: /blog/2016/07/Bringing-End-To-End-Kubernetes-Testing-To-Azure-2
+url: /zh/blog/2016/07/Bringing-End-To-End-Kubernetes-Testing-To-Azure-2
 ---
 -->

@@ -9,7 +9,7 @@ slug: citrix-netscaler-and-kubernetes
 title: " Citrix + Kubernetes = A Home Run "
 date: 2016-07-14
 slug: citrix-netscaler-and-kubernetes
-url: /blog/2016/07/Citrix-Netscaler-And-Kubernetes
+url: /zh/blog/2016/07/Citrix-Netscaler-And-Kubernetes
 ---
 -->

@@ -9,7 +9,7 @@ slug: dashboard-web-interface-for-kubernetes
 title: " Dashboard - Full Featured Web Interface for Kubernetes "
 date: 2016-07-15
 slug: dashboard-web-interface-for-kubernetes
-url: /blog/2016/07/Dashboard-Web-Interface-For-Kubernetes
+url: /zh/blog/2016/07/Dashboard-Web-Interface-For-Kubernetes
 ---
 -->

@@ -9,7 +9,7 @@ slug: oh-the-places-you-will-go
 title: " Happy Birthday Kubernetes. Oh, the places you’ll go! "
 date: 2016-07-21
 slug: oh-the-places-you-will-go
-url: /blog/2016/07/Oh-The-Places-You-Will-Go
+url: /zh/blog/2016/07/Oh-The-Places-You-Will-Go
 ---
 -->

@@ -2,14 +2,14 @@
 title: "容器中运行有状态的应用！？ Kubernetes 1.3 说 “是！” "
 date: 2016-07-13
 slug: stateful-applications-in-containers-kubernetes
-url: /blog/2016/07/stateful-applications-in-containers-kubernetes
+url: /zh/blog/2016/07/stateful-applications-in-containers-kubernetes
 ---
 <!--
 ---
 title: " Stateful Applications in Containers!? Kubernetes 1.3 Says “Yes!” "
 date: 2016-07-13
 slug: stateful-applications-in-containers-kubernetes
-url: /blog/2016/07/stateful-applications-in-containers-kubernetes
+url: /zh/blog/2016/07/stateful-applications-in-containers-kubernetes
 ---
 -->

@@ -9,7 +9,7 @@ url: /zh/blog/2016/08/Stateful-Applications-Using-Kubernetes-Datera
 title: " Scaling Stateful Applications using Kubernetes Pet Sets and FlexVolumes with Datera Elastic Data Fabric "
 date: 2016-08-29
 slug: stateful-applications-using-kubernetes-datera
-url: /blog/2016/08/Stateful-Applications-Using-Kubernetes-Datera
+url: /zh/blog/2016/08/Stateful-Applications-Using-Kubernetes-Datera
 ---
 --->

@@ -9,7 +9,7 @@ slug: five-days-of-kubernetes-18
 title: " Five Days of Kubernetes 1.8 "
 date: 2017-10-24
 slug: five-days-of-kubernetes-18
-url: /blog/2017/10/Five-Days-Of-Kubernetes-18
+url: /zh/blog/2017/10/Five-Days-Of-Kubernetes-18
 ---
 -->

@@ -2,14 +2,14 @@
 title: " Kubernetes 社区指导委员会选举结果 "
 date: 2017-10-05
 slug: kubernetes-community-steering-committee-election-results
-url: /blog/2017/10/Kubernetes-Community-Steering-Committee-Election-Results
+url: /zh/blog/2017/10/Kubernetes-Community-Steering-Committee-Election-Results
 ---
 <!--
 ---
 title: " Kubernetes Community Steering Committee Election Results "
 date: 2017-10-05
 slug: kubernetes-community-steering-committee-election-results
-url: /blog/2017/10/Kubernetes-Community-Steering-Committee-Election-Results
+url: /zh/blog/2017/10/Kubernetes-Community-Steering-Committee-Election-Results
 ---
 -->
 <!--
@@ -9,7 +9,7 @@ slug: autoscaling-in-kubernetes
 title: " Autoscaling in Kubernetes "
 date: 2017-11-17
 slug: autoscaling-in-kubernetes
-url: /blog/2017/11/Autoscaling-In-Kubernetes
+url: /zh/blog/2017/11/Autoscaling-In-Kubernetes
 ---
 -->

@@ -2,14 +2,14 @@
 title: Kubernetes 1.9 对 Windows Server 容器提供 Beta 版本支持
 date: 2018-01-09
 slug: kubernetes-v19-beta-windows-support
-url: /blog/2018/01/Kubernetes-V19-Beta-Windows-Support
+url: /zh/blog/2018/01/Kubernetes-V19-Beta-Windows-Support
 ---
 <!--
 ---
 title: Kubernetes v1.9 releases beta support for Windows Server Containers
 date: 2018-01-09
 slug: kubernetes-v19-beta-windows-support
-url: /blog/2018/01/Kubernetes-V19-Beta-Windows-Support
+url: /zh/blog/2018/01/Kubernetes-V19-Beta-Windows-Support
 ---
 --->

@@ -9,7 +9,7 @@ url: /zh/blog/2018/03/Principles-Of-Container-App-Design
 title: "Principles of Container-based Application Design"
 date: 2018-03-15
 slug: principles-of-container-app-design
-url: /blog/2018/03/Principles-Of-Container-App-Design
+url: /zh/blog/2018/03/Principles-Of-Container-App-Design
 ---
 -->

@@ -0,0 +1,88 @@
+---
+title: 容器运行时接口（CRI）
+content_type: concept
+weight: 50
+---
+
+<!-- 
+title: Container Runtime Interface (CRI)
+content_type: concept
+weight: 50
+-->
+
+<!-- overview -->
+<!-- 
+The CRI is a plugin interface which enables the kubelet to use a wide variety of
+container runtimes, without having a need to recompile the cluster components.
+
+You need a working
+{{<glossary_tooltip text="container runtime" term_id="container-runtime">}} on
+each Node in your cluster, so that the
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} can launch
+{{< glossary_tooltip text="Pods" term_id="pod" >}} and their containers.
+-->
+CRI 是一个插件接口，它使 kubelet 能够使用各种容器运行时，无需重新编译集群组件。
+
+你需要在集群中的每个节点上都有一个可以正常工作的
+{{<glossary_tooltip text="容器运行时" term_id="container-runtime">}}，
+这样
+{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 能启动
+{{< glossary_tooltip text="Pod" term_id="pod" >}} 及其容器。
+
+{{< glossary_definition prepend="容器运行时接口（CRI）是" term_id="container-runtime-interface" length="all" >}}
+
+<!-- body -->
+<!-- ## The API {#api} -->
+## API {#api}
+
+{{< feature-state for_k8s_version="v1.23" state="stable" >}}
+
+<!--
+The kubelet acts as a client when connecting to the container runtime via gRPC.
+The runtime and image service endpoints have to be available in the container
+runtime, which can be configured separately within the kubelet by using the
+`--image-service-endpoint` and `--container-runtime-endpoint` [command line
+flags](/docs/reference/command-line-tools-reference/kubelet)
+-->
+当通过 gRPC 连接到容器运行时时，kubelet 充当客户端。
+运行时和镜像服务端点必须在容器运行时中可用，可以使用
+[命令行标志](/zh/docs/reference/command-line-tools-reference/kubelet)的
+`--image-service-endpoint` 和 `--container-runtime-endpoint`
+在 kubelet 中单独配置。
+
+<!-- 
+For Kubernetes v{{< skew currentVersion >}}, the kubelet prefers to use CRI `v1`.
+If a container runtime does not support `v1` of the CRI, then the kubelet tries to
+negotiate any older supported version.
+The v{{< skew currentVersion >}} kubelet can also negotiate CRI `v1alpha2`, but
+this version is considered as deprecated.
+If the kubelet cannot negotiate a supported CRI version, the kubelet gives up
+and doesn't register as a node.
+-->
+对 Kubernetes v{{< skew currentVersion >}}，kubelet 偏向于使用 CRI `v1` 版本。
+如果容器运行时不支持 CRI 的 `v1` 版本，那么 kubelet 会尝试协商任何旧的其他支持版本。
+如果 kubelet 无法协商支持的 CRI 版本，则 kubelet 放弃并且不会注册为节点。
+
+<!-- 
+## Upgrading
+
+When upgrading Kubernetes, then the kubelet tries to automatically select the
+latest CRI version on restart of the component. If that fails, then the fallback
+will take place as mentioned above. If a gRPC re-dial was required because the
+container runtime has been upgraded, then the container runtime must also
+support the initially selected version or the redial is expected to fail. This
+requires a restart of the kubelet.
+-->
+## 升级  {#upgrading}
+
+升级 Kubernetes 时，kubelet 会尝试在组件重启时自动选择最新的 CRI 版本。
+如果失败，则将如上所述进行回退。如果由于容器运行时已升级而需要 gRPC 重拨，
+则容器运行时还必须支持最初选择的版本，否则重拨预计会失败。
+这需要重新启动 kubelet。
+
+## {{% heading "whatsnext" %}}
+
+<!-- 
+- Learn more about the CRI [protocol definition](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto)
+-->
+- 了解更多有关 CRI [协议定义](https://github.com/kubernetes/cri-api/blob/c75ef5b/pkg/apis/runtime/v1/api.proto)
@@ -142,11 +142,11 @@ Azure CNI 可以在
 <!--
 ### 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](https://projectcalico.docs.tigera.io/about/about-calico/) 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](https://projectcalico.docs.tigera.io/about/about-calico/) 是一个开源的联网及网络安全方案，
 用于基于容器、虚拟机和本地主机的工作负载。
 Calico 支持多个数据面，包括：纯 Linux eBPF 的数据面、标准的 Linux 联网数据面
 以及 Windows HNS 数据面。Calico 在提供完整的联网堆栈的同时，还可与
@@ -170,22 +170,22 @@ Cilium 支持 L7/HTTP，可以在 L3-L7 上通过使用与网络分离的基于
 <!--
 ### 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](/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](https://docs.projectcalico.org/), [Weave-net](https://www.weave.works/products/weave-net/).
+[CNI-Genie](https://github.com/cni-genie/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-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](https://projectcalico.docs.tigera.io/about/about-calico/), [Weave-net](https://www.weave.works/oss/net/).

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

-[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 是一个 CNI 插件，
+[CNI-Genie](https://github.com/cni-genie/CNI-Genie) 是一个 CNI 插件，
 可以让 Kubernetes 在运行时使用不同的[网络模型](#the-kubernetes-network-model)的
-[实现同时被访问](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)。
+[实现同时被访问](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)。
 这包括以
 [CNI 插件](https://github.com/containernetworking/cni#3rd-party-plugins)运行的任何实现，比如
 [Flannel](https://github.com/coreos/flannel#flannel)、
-[Calico](https://docs.projectcalico.org/)、
-[Weave-net](https://www.weave.works/products/weave-net/)。
+[Calico](https://projectcalico.docs.tigera.io/about/about-calico/)、
+[Weave-net](https://www.weave.works/oss/net/)。

-CNI-Genie 还支持[将多个 IP 地址分配给 Pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multi-ip-addresses-per-pod)，
+CNI-Genie 还支持[将多个 IP 地址分配给 Pod](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod)，
 每个都来自不同的 CNI 插件。

 <!--
@@ -231,6 +231,15 @@ Coil operates with a low overhead compared to bare metal, and allows you to defi
 [Coil](https://github.com/cybozu-go/coil) 是一个为易于集成、提供灵活的出站流量网络而设计的 CNI 插件。
 与裸机相比，Coil 的额外操作开销低，并允许针对外部网络的出站流量任意定义 NAT 网关。

+<!--
+### Contiv-VPP
+
+[Contiv-VPP](https://contivpp.io/) is a user-space, performance-oriented network plugin for
+Kubernetes, using the [fd.io](https://fd.io/) data plane.
+-->
+### Contiv-VPP
+[Contiv-VPP](https://contivpp.io/) 是用于 Kubernetes 的用户空间、面向性能的网络插件，使用 [fd.io](https://fd.io/) 数据平面。
+
 <!--
 ### Contrail/Tungsten Fabric

@@ -272,13 +281,13 @@ With this toolset DANM is able to provide multiple separated network interfaces,
 <!--
 ### Flannel

-[Flannel](https://github.com/coreos/flannel#flannel) is a very simple overlay
+[Flannel](https://github.com/flannel-io/flannel#flannel) is a very simple overlay
 network that satisfies the Kubernetes requirements. Many
 people have reported success with Flannel and Kubernetes.
 -->
 ### Flannel

-[Flannel](https://github.com/coreos/flannel#flannel) 是一个非常简单的能够满足
+[Flannel](https://github.com/flannel-io/flannel#flannel) 是一个非常简单的能够满足
 Kubernetes 所需要的覆盖网络。已经有许多人报告了使用 Flannel 和 Kubernetes 的成功案例。

 <!--
@@ -429,7 +438,7 @@ OVN 是一个由 Open vSwitch 社区开发的开源的网络虚拟化解决方
 <!--
 ### Weave Net from Weaveworks

-[Weave Net](https://www.weave.works/products/weave-net/) is a
+[Weave Net](https://www.weave.works/oss/net/) is a
 resilient and simple to use network for Kubernetes and its hosted applications.
 Weave Net runs as a [CNI plug-in](https://www.weave.works/docs/net/latest/cni-plugin/)
 or stand-alone.  In either version, it doesn't require any configuration or extra code
@@ -437,7 +446,7 @@ to run, and in both cases, the network provides one IP address per pod - as is s
 -->
 ### Weaveworks 的 Weave Net

-[Weave Net](https://www.weave.works/products/weave-net/) 是 Kubernetes 及其
+[Weave Net](https://www.weave.works/oss/net/) 是 Kubernetes 及其
 托管应用程序的弹性且易于使用的网络系统。
 Weave Net 可以作为 [CNI 插件](https://www.weave.works/docs/net/latest/cni-plugin/) 运行或者独立运行。
 在这两种运行方式里，都不需要任何配置或额外的代码即可运行，并且在两种情况下，
@@ -119,7 +119,7 @@ spans for 1 in 10000 requests, and uses the default OpenTelemetry endpoint:
 下面是一个示例配置，它为万分之一的请求记录 spans，并使用了默认的 OpenTelemetry 端口。

 ```yaml
-apiVersion: apiserver.config.k8s.io/v1beta1
+apiVersion: apiserver.config.k8s.io/v1alpha1
 kind: TracingConfiguration
 # default value
 #endpoint: localhost:4317
@@ -128,11 +128,11 @@ samplingRatePerMillion: 100

 <!-- 
 For more information about the `TracingConfiguration` struct, see
-[API server config API (v1beta1)](/docs/reference/config-api/apiserver-config.v1beta1/#apiserver-k8s-io-v1beta1-TracingConfiguration).
+[API server config API (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration).
 -->

 有关 TracingConfiguration 结构体的更多信息，请参阅 
-[API 服务器配置 API (v1beta1)](/docs/reference/config-api/apiserver-config.v1beta1/#apiserver-k8s-io-v1beta1-TracingConfiguration)。
+[API 服务器配置 API (v1alpha1)](/zh/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)。

 <!-- 
 ## Stability
@@ -51,7 +51,7 @@ The Pod name and namespace are available as environment variables through the
 [downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/).

 User defined environment variables from the Pod definition are also available to the Container,
-as are any environment variables specified statically in the Docker image.
+as are any environment variables specified statically in the container image.
 -->
 ### 容器信息

@@ -62,14 +62,13 @@ Pod 名称和命名空间可以通过
 [下行 API](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)
 转换为环境变量。

-Pod 定义中的用户所定义的环境变量也可在容器中使用，就像在 Docker 镜像中静态指定的任何环境变量一样。
+Pod 定义中的用户所定义的环境变量也可在容器中使用，就像在 container 镜像中静态指定的任何环境变量一样。

 <!--
 ### Cluster information

 A list of all services that were running when a Container was created is available to that Container as environment variables.
 This list is limited to services within the same namespace as the new Container's Pod and Kubernetes control plane services.
-Those environment variables match the syntax of Docker links.

 For a service named *foo* that maps to a Container named *bar*,
 the following variables are defined:
@@ -78,7 +77,6 @@ the following variables are defined:

 创建容器时正在运行的所有服务都可用作该容器的环境变量。
 这里的服务仅限于新容器的 Pod 所在的名字空间中的服务，以及 Kubernetes 控制面的服务。
-这些环境变量与 Docker 链接的语法相同。

 对于名为 *foo* 的服务，当映射到名为 *bar* 的容器时，以下变量是被定义了的：

@@ -183,6 +183,15 @@ For more details on setting up CRI runtimes, see [CRI installation](/docs/setup/

 #### dockershim

+<!--
+{{< feature-state for_k8s_version="v1.20" state="deprecated" >}}
+
+Dockershim is deprecated as of Kubernetes v1.20, and will be removed in v1.24. For more information on the deprecation,
+see [dockershim deprecation](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)
+-->
+Dockershim 自 Kubernetes v1.20 起已弃用，并将在 v1.24 中删除。 
+有关弃用的更多信息查看 [dockershim 弃用](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)。
+
 <!--
 RuntimeClasses with dockershim must set the runtime handler to `docker`. Dockershim does not support
 custom configurable runtime handlers.
@@ -14,12 +14,20 @@ weight: 30

 {{< feature-state for_k8s_version="v1.21" state="deprecated" >}}

+{{< caution >}}
 <!--
-PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25. For more information on the deprecation,
+PodSecurityPolicy is deprecated as of Kubernetes v1.21, and **will be removed in v1.25**. We recommend migrating to
+[Pod Security Admission](/docs/concepts/security/pod-security-admission/), or a 3rd party admission plugin.
+For a migration guide, see [Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller](/docs/tasks/configure-pod-container/migrate-from-psp/).
+For more information on the deprecation,
 see [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/).
 -->
-PodSecurityPolicy 在 Kubernetes v1.21 版本中被弃用，将在 v1.25 中删除。
+PodSecurityPolicy 在 Kubernetes v1.21 版本中被弃用，**将在 v1.25 中删除**。
+我们建议迁移到 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission)，
+或者第三方的准入插件。
+若需了解迁移指南，可参阅[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh/docs/tasks/configure-pod-container/migrate-from-psp/)。
 关于弃用的更多信息，请查阅 [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。
+{{< /caution >}}

 <!--
 Pod Security Policies enable fine-grained authorization of pod creation and
@@ -6,10 +6,10 @@ description: >
  在Kubernetes中，调度 (scheduling) 指的是确保 Pods 匹配到合适的节点，
  以便 kubelet 能够运行它们。抢占 (Preemption) 指的是终止低优先级的 Pods 以便高优先级的 Pods 可以
  调度运行的过程。驱逐 (Eviction) 是在资源匮乏的节点上，主动让一个或多个 Pods 失效的过程。
+no_list: true
 ---

 <!--
---
 title: "Scheduling, Preemption and Eviction"
 weight: 90
 content_type: concept
@@ -20,7 +20,6 @@ description: >
  Nodes. Eviction is the process of proactively terminating one or more Pods on
  resource-starved Nodes.
 no_list: true
---
 -->

 <!--
@@ -49,5 +48,5 @@ of terminating one or more Pods on Nodes.
 ## Pod 干扰

 * [Pod 优先级和抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)
-* [节点压力驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)
+* [节点压力驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)
 * [API发起的驱逐](/zh/docs/concepts/scheduling-eviction/api-eviction/)
--- a/Show More
+++ b/Show More