Merge pull request #33336 from nate-double-u/update-release-1.21-config.toml

update release-1.21 config.toml for release 1.24

.github/ISSUE_TEMPLATE/support.md

@@ -11,7 +11,7 @@ STOP -- PLEASE READ!
 
 GitHub is not the right place for support requests.
 
-If you're looking for help, check [Server Fault](https://serverfault.com/questions/tagged/kubernetes).
+If you're looking for help, check [Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)
 
 You can also post your question on the [Kubernetes Slack](http://slack.k8s.io/) or the [Discuss Kubernetes](https://discuss.kubernetes.io/) forum.
 

.github/workflows/OWNERS

@@ -3,9 +3,6 @@
 # When modifying this file, consider the security implications of
 # allowing listed reviewers / approvals to modify or remove any
 # configured GitHub Actions.
-#
-options:
-  no_parent_owners: true
 
 reviewers:
 - sig-docs-leads

CONTRIBUTING.md

@@ -34,6 +34,6 @@ Note that code issues should be filed against the main kubernetes repository, wh
 
 ### Submitting Documentation Pull Requests
 
-If you're fixing an issue in the existing documentation, you should submit a PR against the main branch.  Follow [these instructions to create a documentation pull request against the kubernetes.io repository](http://kubernetes.io/docs/home/contribute/create-pull-request/).
+If you're fixing an issue in the existing documentation, you should submit a PR against the master branch.  Follow [these instructions to create a documentation pull request against the kubernetes.io repository](http://kubernetes.io/docs/home/contribute/create-pull-request/).
 
 For more information, see [contributing to Kubernetes docs](https://kubernetes.io/docs/contribute/).

LICENSE

@@ -33,7 +33,7 @@ exhaustive, and do not form part of our licenses.
      material not subject to the license. This includes other CC-
      licensed material, or material used under an exception or
      limitation to copyright. More considerations for licensors:
-    wiki.creativecommons.org/Considerations_for_licensors
+	wiki.creativecommons.org/Considerations_for_licensors
 
      Considerations for the public: By using one of our public
      licenses, a licensor grants the public permission to use the
@@ -48,9 +48,9 @@ exhaustive, and do not form part of our licenses.
      rights in the material. A licensor may make special requests,
      such as asking that all changes be marked or described.
      Although not required by our licenses, you are encouraged to
-     respect those requests where reasonable. More considerations
-     for the public:
-    wiki.creativecommons.org/Considerations_for_licensees
+     respect those requests where reasonable. More_considerations
+     for the public: 
+	wiki.creativecommons.org/Considerations_for_licensees
 
 =======================================================================
 
@@ -378,7 +378,7 @@ Section 8 -- Interpretation.
 Creative Commons is not a party to its public
 licenses. Notwithstanding, Creative Commons may elect to apply one of
 its public licenses to material it publishes and in those instances
-will be considered the “Licensor.” The text of the Creative Commons
+will be considered the "Licensor." The text of the Creative Commons
 public licenses is dedicated to the public domain under the CC0 Public
 Domain Dedication. Except for the limited purpose of indicating that
 material is shared under a Creative Commons public license or as
@@ -393,4 +393,3 @@ the avoidance of doubt, this paragraph does not form part of the
 public licenses.
 
 Creative Commons may be contacted at creativecommons.org.
-

Makefile

@@ -19,10 +19,10 @@ CCEND=\033[0m
 help: ## Show this help.
 	@awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST)
 
-module-check: ## Check if all of the required submodules are correctly initialized.
+module-check:
 	@git submodule status --recursive | awk '/^[+-]/ {err = 1; printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2} END { if (err != 0) print "You need to run \033[32mmake module-init\033[0m to initialize missing modules first"; exit err }' 1>&2
 
-module-init: ## Initialize required submodules.
+module-init:
 	@echo "Initializing submodules..." 1>&2
 	@git submodule update --init --recursive --depth 1
 
@@ -98,4 +98,4 @@ clean-api-reference: ## Clean all directories in API reference directory, preser
 
 api-reference: clean-api-reference ## Build the API reference pages. go needed
 	cd api-ref-generator/gen-resourcesdocs && \
-		go run cmd/main.go kwebsite --config-dir ../../api-ref-assets/config/ --file ../../api-ref-assets/api/swagger.json --output-dir ../../content/en/docs/reference/kubernetes-api --templates ../../api-ref-assets/templates
+		go run cmd/main.go kwebsite --config-dir config/v1.21/ --file api/v1.21/swagger.json --output-dir ../../content/en/docs/reference/kubernetes-api --templates templates

OWNERS

@@ -8,9 +8,7 @@ approvers:
 
 emeritus_approvers:
 # - chenopis, commented out to disable PR assignments
-# - irvifa, commented out to disable PR assignments
 # - jaredbhatti, commented out to disable PR assignments
-# - kbarnard10, commented out to disable PR assignments
 # - steveperry-53, commented out to disable PR assignments
 - stewart-yu 
 # - zacharysarah, commented out to disable PR assignments

OWNERS_ALIASES

@@ -1,13 +1,13 @@
 aliases:
   sig-docs-blog-owners: # Approvers for blog content
+    - kbarnard10
     - onlydole
     - mrbobbytables
-    - sftim
   sig-docs-blog-reviewers: # Reviewers for blog content
+    - kbarnard10
     - mrbobbytables
     - onlydole
     - sftim
-    - nate-double-u
   sig-docs-de-owners: # Admins for German content
     - bene2k1
     - mkorbi
@@ -20,9 +20,9 @@ aliases:
     - annajung
     - bradtopol
     - celestehorgan
-    - divya-mohan0209
+    - irvifa
     - jimangel
-    - jlbutler
+    - kbarnard10
     - kbhawkey
     - onlydole
     - pi-victor
@@ -34,14 +34,12 @@ aliases:
     - bradtopol
     - celestehorgan
     - daminisatya
-    - divya-mohan0209
     - jimangel
+    - kbarnard10
     - kbhawkey
-    - mehabhalodiya
     - onlydole
     - rajeshdeshpande02
     - sftim
-    - shannonxtreme
     - tengqm
   sig-docs-es-owners: # Admins for Spanish content
     - raelga
@@ -78,19 +76,19 @@ aliases:
     - anthonydahanne
     - feloy
   sig-docs-hi-owners: # Admins for Hindi content
-    - anubha-v-ardhan
-    - divya-mohan0209
+    - avidLearnerInProgress
+    - daminisatya
     - mittalyashu
   sig-docs-hi-reviews: # PR reviews for Hindi content
-    - anubha-v-ardhan
-    - divya-mohan0209
+    - avidLearnerInProgress
+    - daminisatya
     - mittalyashu
-    - verma-kunal
   sig-docs-id-owners: # Admins for Indonesian content
     - ariscahyadi
     - danninov
     - girikuncoro
     - habibrosyad
+    - irvifa
     - phanama
     - wahyuoi
   sig-docs-id-reviews: # PR reviews for Indonesian content
@@ -98,6 +96,7 @@ aliases:
     - danninov
     - girikuncoro
     - habibrosyad
+    - irvifa
     - phanama
     - wahyuoi
   sig-docs-it-owners: # Admins for Italian content
@@ -127,7 +126,6 @@ aliases:
     - ClaudiaJKang
     - gochist
     - ianychoi
-    - jihoon-seo
     - seokho-son
     - ysyukr
   sig-docs-ko-reviews: # PR reviews for Korean content
@@ -135,14 +133,14 @@ aliases:
     - gochist
     - ianychoi
     - jihoon-seo
-    - jmyung
     - pjhwa
     - seokho-son
     - yoonian
     - ysyukr
   sig-docs-leads: # Website chairs and tech leads
-    - divya-mohan0209
+    - irvifa
     - jimangel
+    - kbarnard10
     - kbhawkey
     - onlydole
     - sftim
@@ -171,7 +169,6 @@ aliases:
     - xichengliudui
     # zhangxiaoyu-zidif
   sig-docs-pt-owners: # Admins for Portuguese content
-    - edsoncelio
     - femrtnz
     - jailton
     - jcjesus
@@ -180,7 +177,6 @@ aliases:
     - rikatz
     - yagonobre
   sig-docs-pt-reviews: # PR reviews for Portugese content
-    - edsoncelio
     - femrtnz
     - jailton
     - jcjesus
@@ -228,12 +224,12 @@ aliases:
   # authoritative source: git.k8s.io/community/OWNERS_ALIASES
   committee-steering: # provide PR approvals for announcements
     - cblecker
+    - derekwaynecarr
     - dims
-    - justaugustus
     - liggitt
     - mrbobbytables
+    - nikhita
     - parispittman
-    - tpepper
   # authoritative source: https://git.k8s.io/sig-release/OWNERS_ALIASES
   sig-release-leads:
     - cpanato # SIG Technical Lead
@@ -245,18 +241,19 @@ aliases:
     - saschagrunert # SIG Chair
   release-engineering-approvers:
     - cpanato # Release Manager
-    - palnabarun # Release Manager
+    - hasheddan # subproject owner / Release Manager
     - puerco # Release Manager
     - saschagrunert # subproject owner / Release Manager
     - justaugustus # subproject owner / Release Manager
-    - Verolop # Release Manager
     - xmudrii # Release Manager
   release-engineering-reviewers:
     - ameukam # Release Manager Associate
     - jimangel # Release Manager Associate
     - markyjackson-taulia # Release Manager Associate
     - mkorbi # Release Manager Associate
+    - palnabarun # Release Manager Associate
     - onlydole # Release Manager Associate
     - sethmccombs # Release Manager Associate
     - thejoycekung # Release Manager Associate
-    - wilsonehusin # Release Manager Associate
+    - verolop # Release Manager Associate
+    - wilsonehusin # Release Manager Associate

README-hi.md

@@ -7,7 +7,7 @@
 
 ## डॉक्स में योगदान देना
 
-आप अपने GitHub खाते में इस रिपॉजिटरी की एक copy बनाने के लिए स्क्रीन के ऊपरी-दाएँ क्षेत्र में **Fork** बटन पर क्लिक करें। इस copy को *Fork* कहा जाता है। अपने fork में परिवर्तन करने के बाद जब आप उनको हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं।
+आप अपने GitHub खाते में इस रिपॉजिटरी की एक copy बनाने के लिए स्क्रीन के ऊपरी-दाएँ क्षेत्र में **Fork** बटन पर क्लिक करें। इस copy को *Fork* कहा जाता है। अपने fork में कोई भी परिवर्तन करना चाहते हैं, और जब आप उन परिवर्तनों को हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं।
 
 एक बार जब आपका pull request बन जाता है, तो एक कुबरनेट्स समीक्षक स्पष्ट, कार्रवाई योग्य प्रतिक्रिया प्रदान करने की जिम्मेदारी लेगा। pull request के मालिक के रूप में, **यह आपकी जिम्मेदारी है कि आप कुबरनेट्स समीक्षक द्वारा प्रदान की गई प्रतिक्रिया को संबोधित करने के लिए अपने pull request को संशोधित करें।**
 
@@ -23,12 +23,9 @@
 
 ## `README.md`'s स्थानीयकरण कुबरनेट्स प्रलेखन
 
-आप हिंदी स्थानीयकरण के मैन्टेनरों तक पहुँच सकते हैं:
+आप पर हिंदी स्थानीयकरण के maintainers तक पहुँच सकते हैं:
 
-* Anubhav Vardhan ([Slack](https://kubernetes.slack.com/archives/D0261C0A3R8), [Twitter](https://twitter.com/anubha_v_ardhan), [GitHub](https://github.com/anubha-v-ardhan))
-* Divya Mohan ([Slack](https://kubernetes.slack.com/archives/D027R7BE804), [Twitter](https://twitter.com/Divya_Mohan02), [GitHub](https://github.com/divya-mohan0209))
 * Yashu Mittal ([Twitter](https://twitter.com/mittalyashu77), [GitHub](https://github.com/mittalyashu))
-
 * [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-hi)
 
 ## स्थानीय रूप से डॉकर का उपयोग करके साइट चलाना

README-pl.md

@@ -5,9 +5,9 @@
 W tym repozytorium znajdziesz wszystko, czego potrzebujesz do zbudowania [strony internetowej Kubernetesa wraz z dokumentacją](https://kubernetes.io/). Bardzo nam miło, że chcesz wziąć udział w jej współtworzeniu!
 
 + [Twój wkład w dokumentację](#twój-wkład-w-dokumentację)
-+ [Informacje o wersjach językowych](#różne-wersje-językowe-readmemd)
++ [Informacje o wersjach językowych](#informacje-o-wersjach-językowych)
 
-## Jak używać tego repozytorium
+# Jak używać tego repozytorium
 
 Możesz uruchomić serwis lokalnie poprzez Hugo (Extended version) lub ze środowiska kontenerowego. Zdecydowanie zalecamy korzystanie z kontenerów, bo dzięki temu lokalna wersja będzie spójna z tym, co jest na oficjalnej stronie.
 
@@ -18,18 +18,18 @@ Aby móc skorzystać z tego repozytorium, musisz lokalnie zainstalować:
 - [npm](https://www.npmjs.com/)
 - [Go](https://golang.org/)
 - [Hugo (Extended version)](https://gohugo.io/)
-- Środowisko obsługi kontenerów, np. [Dockera](https://www.docker.com/).
+- Środowisko obsługi kontenerów, np. [Docker-a](https://www.docker.com/).
 
 Przed rozpoczęciem zainstaluj niezbędne zależności. Sklonuj repozytorium i przejdź do odpowiedniego katalogu:
 
-```bash
+```
 git clone https://github.com/kubernetes/website.git
 cd website
 ```
 
 Strona Kubernetesa używa [Docsy Hugo theme](https://github.com/google/docsy#readme). Nawet jeśli planujesz uruchomić serwis w środowisku kontenerowym, zalecamy pobranie podmodułów i innych zależności za pomocą polecenia:
 
-```bash
+```
 # pull in the Docsy submodule
 git submodule update --init --recursive --depth 1
 ```
@@ -38,14 +38,12 @@ git submodule update --init --recursive --depth 1
 
 Aby zbudować i uruchomić serwis wewnątrz środowiska kontenerowego, wykonaj następujące polecenia:
 
-```bash
+```
 make container-image
 make container-serve
 ```
 
-Jeśli widzisz błędy, prawdopodobnie kontener z Hugo nie dysponuje wystarczającymi zasobami. Aby rozwiązać ten problem, zwiększ ilość dostępnych zasobów CPU i pamięci dla Dockera na Twojej maszynie ([MacOSX](https://docs.docker.com/docker-for-mac/#resources) i [Windows](https://docs.docker.com/docker-for-windows/#resources)).
-
-Aby obejrzeć zawartość serwisu, otwórz w przeglądarce adres <http://localhost:1313>. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce.
+Aby obejrzeć zawartość serwisu otwórz w przeglądarce adres http://localhost:1313. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce.
 
 ## Jak uruchomić lokalną kopię strony przy pomocy Hugo?
 
@@ -59,14 +57,13 @@ npm ci
 make serve
 ```
 
-Zostanie uruchomiony lokalny serwer Hugo na porcie 1313. Otwórz w przeglądarce adres <http://localhost:1313>, aby obejrzeć zawartość serwisu. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce.
+Zostanie uruchomiony lokalny serwer Hugo na porcie 1313. Otwórz w przeglądarce adres http://localhost:1313, aby obejrzeć zawartość serwisu. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce.
 
 ## Budowanie dokumentacji źródłowej API
 
 Budowanie dokumentacji źródłowej API zostało opisane w [angielskiej wersji pliku README.md](README.md#building-the-api-reference-pages).
 
 ## Rozwiązywanie problemów
-
 ### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version
 
 Z przyczyn technicznych, Hugo jest rozprowadzany w dwóch wersjach. Aktualny serwis używa tylko wersji **Hugo Extended**. Na stronie z [wydaniami](https://github.com/gohugoio/hugo/releases) poszukaj archiwum z `extended` w nazwie. Dla potwierdzenia, uruchom `hugo version` i poszukaj słowa `extended`.
@@ -75,7 +72,7 @@ Z przyczyn technicznych, Hugo jest rozprowadzany w dwóch wersjach. Aktualny ser
 
 Jeśli po uruchomieniu `make serve` na macOS widzisz następujący błąd:
 
-```bash
+```
 ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files
 make: *** [serve] Error 1
 ```
@@ -105,36 +102,36 @@ sudo chown root:wheel /Library/LaunchDaemons/limit.maxproc.plist
 sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
 ```
 
-Przedstawiony sposób powinien działać dla MacOS w wersjach Catalina i Mojave.
+Przedstawiony sposób powinien działać dla MacOS w wersji Catalina i Mojave.
 
-## Zaangażowanie w prace SIG Docs
+
+# Zaangażowanie w prace SIG Docs
 
 O społeczności SIG Docs i terminach spotkań dowiesz z [jej strony](https://github.com/kubernetes/community/tree/master/sig-docs#meetings).
 
 Możesz kontaktować się z gospodarzami projektu za pomocą:
 
-- [Komunikatora Slack](https://kubernetes.slack.com/messages/sig-docs)
-  - [Tutaj możesz dostać zaproszenie do tej grupy Slacka](https://slack.k8s.io/)
+- [Komunikatora Slack](https://kubernetes.slack.com/messages/sig-docs) [Tutaj możesz dostać zaproszenie do tej grupy Slack-a](https://slack.k8s.io/)
 - [List dyskusyjnych](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
 
-## Twój wkład w dokumentację
+# Twój wkład w dokumentację
 
 Możesz kliknąć w przycisk **Fork** w prawym górnym rogu ekranu, aby stworzyć kopię tego repozytorium na swoim koncie GitHub. Taki rodzaj kopii (odgałęzienia) nazywa się *fork*. Zmieniaj w nim, co chcesz, a kiedy będziesz już gotowy/a przesłać te zmiany do nas, przejdź do swojej kopii i stwórz nowy *pull request*, abyśmy zostali o tym poinformowani.
 
-Po stworzeniu *pull request*, jeden z recenzentów projektu Kubernetes podejmie się przekazania jasnych wskazówek pozwalających podjąć następne działania. Na Tobie, jako właścicielu *pull requesta*, **spoczywa odpowiedzialność za wprowadzenie poprawek zgodnie z uwagami recenzenta.**
+Po stworzeniu *pull request*, jeden z recenzentów projektu Kubernetes podejmie się przekazania jasnych wskazówek pozwalających podjąć następne działania. Na Tobie, jako właścicielu *pull requesta*, **spoczywa odpowiedzialność za wprowadzenie poprawek zgodnie z uwagami recenzenta.** 
 
 Może też się zdarzyć, że swoje uwagi zgłosi więcej niż jeden recenzent, lub że recenzję będzie robił ktoś inny, niż ten, kto został przydzielony na początku.
 
-W niektórych przypadkach, jeśli zajdzie taka potrzeba, recenzent może poprosić dodatkowo o recenzję jednego z recenzentów technicznych. Recenzenci zrobią wszystko, aby odpowiedzieć sprawnie, ale konkretny czas odpowiedzi zależy od wielu czynników.
+W niektórych przypadkach, jeśli zajdzie taka potrzeba, recenzent może poprosić dodatkowo o recenzję jednego z [recenzentów technicznych](https://github.com/kubernetes/website/wiki/Tech-reviewers). Recenzenci zrobią wszystko, aby odpowiedzieć sprawnie, ale konkretny czas odpowiedzi zależy od wielu czynników.
 
 Więcej informacji na temat współpracy przy tworzeniu dokumentacji znajdziesz na stronach:
 
-- [Udział w rozwijaniu dokumentacji](https://kubernetes.io/docs/contribute/)
-- [Rodzaje stron](https://kubernetes.io/docs/contribute/style/page-content-types/)
-- [Styl pisania dokumentacji](http://kubernetes.io/docs/contribute/style/style-guide/)
-- [Lokalizacja dokumentacji Kubernetesa](https://kubernetes.io/docs/contribute/localization/)
+* [Udział w rozwijaniu dokumentacji](https://kubernetes.io/docs/contribute/)
+* [Rodzaje stron](https://kubernetes.io/docs/contribute/style/page-content-types/)
+* [Styl pisania dokumentacji](http://kubernetes.io/docs/contribute/style/style-guide/)
+* [Lokalizacja dokumentacji Kubernetes](https://kubernetes.io/docs/contribute/localization/)
 
-## Różne wersje językowe `README.md`
+# Różne wersje językowe `README.md`
 
 | Język  | Język |
 |---|---|
@@ -146,10 +143,10 @@ Więcej informacji na temat współpracy przy tworzeniu dokumentacji znajdziesz
 | [wietnamski](README-vi.md)   | [rosyjski](README-ru.md)     |
 | [włoski](README-it.md)       | [ukraiński](README-uk.md)    |
 
-## Zasady postępowania
+# Zasady postępowania
 
 Udział w działaniach społeczności Kubernetesa jest regulowany przez [Kodeks postępowania CNCF](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/pl.md).
 
-## Dziękujemy!
+# Dziękujemy!
 
 Kubernetes rozkwita dzięki zaangażowaniu społeczności — doceniamy twój wkład w tworzenie naszego serwisu i dokumentacji!

README-ru.md

@@ -1,6 +1,6 @@
 # Документация по Kubernetes
 
-[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
+[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
 
 Данный репозиторий содержит все необходимые файлы для сборки [сайта Kubernetes и документации](https://kubernetes.io/). Мы благодарим вас за желание внести свой вклад!
 

README.md

@@ -65,23 +65,31 @@ This will start the local Hugo server on port 1313. Open up your browser to <htt
 
 The API reference pages located in `content/en/docs/reference/kubernetes-api` are built from the Swagger specification, using <https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs>.
 
-To update the reference pages for a new Kubernetes release follow these steps:
+To update the reference pages for a new Kubernetes release (replace v1.20 in the following examples with the release to update to):
 
-1. Pull in the `api-ref-generator` submodule:
+1. Pull the `kubernetes-resources-reference` submodule:
 
    ```bash
    git submodule update --init --recursive --depth 1
    ```
 
-2. Update the Swagger specification:
+2. Create a new API revision into the submodule, and add the Swagger specification:
 
    ```bash
-   curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json
+   mkdir api-ref-generator/gen-resourcesdocs/api/v1.20
+   curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-generator/gen-resourcesdocs/api/v1.20/swagger.json
    ```
 
-3. In `api-ref-assets/config/`, adapt the files `toc.yaml` and `fields.yaml` to reflect the changes of the new release.
+3. Copy the table of contents and fields configuration for the new release from a previous one:
 
-4. Next, build the pages:
+   ```bash
+   mkdir api-ref-generator/gen-resourcesdocs/api/v1.20
+   cp api-ref-generator/gen-resourcesdocs/api/v1.19/* api-ref-generator/gen-resourcesdocs/api/v1.20/
+   ```
+
+4. Adapt the files `toc.yaml` and `fields.yaml` to reflect the changes between the two releases
+
+5. Next, build the pages:
 
    ```bash
    make api-reference
@@ -96,7 +104,7 @@ To update the reference pages for a new Kubernetes release follow these steps:
 
    In a web browser, go to <http://localhost:1313/docs/reference/kubernetes-api/> to view the API reference.
 
-5. When all changes of the new contract are reflected into the configuration files `toc.yaml` and `fields.yaml`, create a Pull Request with the newly generated API reference pages.
+6. When all changes of the new contract are reflected into the configuration files `toc.yaml` and `fields.yaml`, create a Pull Request with the newly generated API reference pages.
 
 ## Troubleshooting
 
@@ -146,8 +154,7 @@ Learn more about SIG Docs Kubernetes community and meetings on the [community pa
 
 You can also reach the maintainers of this project at:
 
-- [Slack](https://kubernetes.slack.com/messages/sig-docs)
-  - [Get an invite for this Slack](https://slack.k8s.io/)
+- [Slack](https://kubernetes.slack.com/messages/sig-docs) [Get an invite for this Slack](https://slack.k8s.io/)
 - [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
 
 ## Contributing to the docs

SECURITY.md

@@ -4,6 +4,8 @@
 
 Join the [kubernetes-security-announce] group for security and vulnerability announcements.
 
+You can also subscribe to an RSS feed of the above using [this link][kubernetes-security-announce-rss].
+
 ## Reporting a Vulnerability
 
 Instructions for reporting a vulnerability can be found on the
@@ -15,5 +17,6 @@ Information about supported Kubernetes versions can be found on the
 [Kubernetes version and version skew support policy] page on the Kubernetes website.
 
 [kubernetes-security-announce]: https://groups.google.com/forum/#!forum/kubernetes-security-announce
+[kubernetes-security-announce-rss]: https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50
 [Kubernetes version and version skew support policy]: https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions
 [Kubernetes Security and Disclosure Information]: https://kubernetes.io/docs/reference/issues-security/security/#report-a-vulnerability

SECURITY_CONTACTS

@@ -1,6 +1,6 @@
 # Defined below are the security contacts for this repo.
 #
-# They are the contact point for the Security Response Committee to reach out
+# They are the contact point for the Product Security Committee to reach out
 # to for triaging and handling of incoming issues.
 #
 # The below names agree to abide by the
@@ -10,6 +10,7 @@
 # DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE
 # INSTRUCTIONS AT https://kubernetes.io/security/
 
-divya-mohan0209
+irvifa
 jimangel
-sftim
+kbarnard10
+sftim

api-ref-assets/config/fields.yaml

@@ -1,718 +0,0 @@
-- definition: io.k8s.api.core.v1.PodSpec
-  field_categories:
-  - name: Containers
-    fields:
-    - containers
-    - initContainers
-    - imagePullSecrets
-    - enableServiceLinks
-    - os
-  - name: Volumes
-    fields:
-    - volumes
-  - name: Scheduling
-    fields:
-    - nodeSelector
-    - nodeName
-    - affinity
-    - tolerations
-    - schedulerName
-    - runtimeClassName
-    - priorityClassName
-    - priority
-    - topologySpreadConstraints
-  - name: Lifecycle
-    fields:
-    - restartPolicy
-    - terminationGracePeriodSeconds
-    - activeDeadlineSeconds
-    - readinessGates
-  - name: Hostname and Name resolution
-    fields:
-    - hostname
-    - setHostnameAsFQDN
-    - subdomain
-    - hostAliases
-    - dnsConfig
-    - dnsPolicy
-  - name: Hosts namespaces
-    fields:
-    - hostNetwork
-    - hostPID
-    - hostIPC
-    - shareProcessNamespace
-  - name: Service account
-    fields:
-    - serviceAccountName
-    - automountServiceAccountToken
-  - name: Security context
-    fields:
-    - securityContext
-  - name: Beta level
-    fields:
-    - ephemeralContainers
-    - preemptionPolicy
-    - overhead
-  - name: Deprecated
-    fields:
-    - serviceAccount
-
-- definition: io.k8s.api.core.v1.PodSecurityContext
-  field_categories:
-  - fields:
-    - runAsUser
-    - runAsNonRoot
-    - runAsGroup
-    - supplementalGroups
-    - fsGroup
-    - fsGroupChangePolicy
-    - seccompProfile
-    - seLinuxOptions
-    - sysctls
-    - windowsOptions
-
-- definition: io.k8s.api.core.v1.Toleration
-  field_categories:
-  - fields:
-    - key
-    - operator
-    - value
-    - effect
-    - tolerationSeconds
-
-- definition: io.k8s.api.core.v1.PodStatus
-  field_categories:
-  - fields:
-    - nominatedNodeName
-    - hostIP
-    - startTime
-    - phase
-    - message
-    - reason
-    - podIP
-    - podIPs
-    - conditions
-    - qosClass
-    - initContainerStatuses
-    - containerStatuses
-    - ephemeralContainerStatuses
-
-- definition: io.k8s.api.core.v1.Container
-  field_categories:
-  - fields:
-    - name
-  - name: Image
-    fields:
-    - image
-    - imagePullPolicy
-  - name: Entrypoint
-    fields:
-    - command
-    - args
-    - workingDir
-  - name: Ports
-    fields:
-    - ports
-  - name: Environment variables
-    fields:
-    - env
-    - envFrom
-  - name: Volumes
-    fields:
-    - volumeMounts
-    - volumeDevices
-  - name: Resources
-    fields:
-    - resources
-  - name: Lifecycle
-    fields:
-    - lifecycle
-    - terminationMessagePath
-    - terminationMessagePolicy
-    - livenessProbe
-    - readinessProbe
-    - startupProbe
-  - name: Security Context
-    fields:
-    - securityContext
-  - name: Debugging
-    fields:
-    - stdin
-    - stdinOnce
-    - tty
-
-- definition: io.k8s.api.core.v1.Probe
-  field_categories:
-  - fields:
-    - exec
-    - httpGet
-    - tcpSocket
-    - initialDelaySeconds
-    - terminationGracePeriodSeconds
-    - periodSeconds
-    - timeoutSeconds
-    - failureThreshold
-    - successThreshold
-    - grpc
-
-- definition: io.k8s.api.core.v1.SecurityContext
-  field_categories:
-  - fields:
-    - runAsUser
-    - runAsNonRoot
-    - runAsGroup
-    - readOnlyRootFilesystem
-    - procMount
-    - privileged
-    - allowPrivilegeEscalation
-    - capabilities
-    - seccompProfile
-    - seLinuxOptions
-    - windowsOptions
-
-- definition: io.k8s.api.core.v1.ContainerStatus
-  field_categories:
-  - fields:
-    - name
-    - image
-    - imageID
-    - containerID
-    - state
-    - lastState
-    - ready
-    - restartCount
-    - started
-
-- definition: io.k8s.api.core.v1.ContainerStateTerminated
-  field_categories:
-  - fields:
-    - containerID
-    - exitCode
-    - startedAt
-    - finishedAt
-    - message
-    - reason
-    - signal
-
-- definition: io.k8s.api.core.v1.EphemeralContainer
-  field_categories:
-  - fields:
-    - name
-    - targetContainerName
-  - name: Image
-    fields:
-    - image
-    - imagePullPolicy
-  - name: Entrypoint
-    fields:
-    - command
-    - args
-    - workingDir
-  - name: Environment variables
-    fields:
-    - env
-    - envFrom
-  - name: Volumes
-    fields:
-    - volumeMounts
-    - volumeDevices
-  - name: Lifecycle
-    fields:
-    - terminationMessagePath
-    - terminationMessagePolicy
-  - name: Debugging
-    fields:
-    - stdin
-    - stdinOnce
-    - tty
-  - name: Security context
-    fields:
-    - securityContext
-  - name: Not allowed
-    fields:
-    - ports
-    - resources
-    - lifecycle
-    - livenessProbe
-    - readinessProbe
-    - startupProbe
-
-- definition: io.k8s.api.core.v1.ReplicationControllerSpec
-  field_categories:
-  - fields:
-    - selector
-    - template
-    - replicas
-    - minReadySeconds
-
-- definition: io.k8s.api.core.v1.ReplicationControllerStatus
-  field_categories:
-  - fields:
-    - replicas
-    - availableReplicas
-    - readyReplicas
-    - fullyLabeledReplicas
-    - conditions
-    - observedGeneration
-
-- definition: io.k8s.api.apps.v1.ReplicaSetSpec
-  field_categories:
-  - fields:
-    - selector
-    - template
-    - replicas
-    - minReadySeconds
-
-- definition: io.k8s.api.apps.v1.ReplicaSetStatus
-  field_categories:
-  - fields:
-    - replicas
-    - availableReplicas
-    - readyReplicas
-    - fullyLabeledReplicas
-    - conditions
-    - observedGeneration
-
-- definition: io.k8s.api.apps.v1.DeploymentSpec
-  field_categories:
-  - fields:
-    - selector
-    - template
-    - replicas
-    - minReadySeconds
-    - strategy
-    - revisionHistoryLimit
-    - progressDeadlineSeconds
-    - paused
-
-- definition: io.k8s.api.apps.v1.DeploymentStatus
-  field_categories:
-  - fields:
-    - replicas
-    - availableReplicas
-    - readyReplicas
-    - unavailableReplicas
-    - updatedReplicas
-    - collisionCount
-    - conditions
-    - observedGeneration
-
-- definition: io.k8s.api.apps.v1.DeploymentStrategy
-  field_categories:
-  - fields:
-    - type
-    - rollingUpdate
-
-- definition: io.k8s.api.apps.v1.StatefulSetSpec
-  field_categories:
-  - fields:
-    - serviceName
-    - selector
-    - template
-    - replicas
-    - updateStrategy
-    - podManagementPolicy
-    - revisionHistoryLimit
-    - volumeClaimTemplates
-    - minReadySeconds
-    - persistentVolumeClaimRetentionPolicy
-
-- definition: io.k8s.api.apps.v1.StatefulSetUpdateStrategy
-  field_categories:
-  - fields:
-    - type
-    - rollingUpdate
-
-- definition: io.k8s.api.apps.v1.StatefulSetStatus
-  field_categories:
-  - fields:
-    - replicas
-    - readyReplicas
-    - currentReplicas
-    - updatedReplicas
-    - availableReplicas
-    - collisionCount
-    - conditions
-    - currentRevision
-    - updateRevision
-    - observedGeneration
-
-- definition: io.k8s.api.apps.v1.DaemonSetSpec
-  field_categories:
-  - fields:
-    - selector
-    - template
-    - minReadySeconds
-    - updateStrategy
-    - revisionHistoryLimit
-
-- definition: io.k8s.api.apps.v1.DaemonSetUpdateStrategy
-  field_categories:
-  - fields:
-    - type
-    - rollingUpdate
-
-- definition: io.k8s.api.apps.v1.DaemonSetStatus
-  field_categories:
-  - fields:
-    - numberReady
-    - numberAvailable
-    - numberUnavailable
-    - numberMisscheduled
-    - desiredNumberScheduled
-    - currentNumberScheduled
-    - updatedNumberScheduled
-    - collisionCount
-    - conditions
-    - observedGeneration
-
-- definition: io.k8s.api.batch.v1.JobSpec
-  field_categories:
-  - name: Replicas
-    fields:
-    - template
-    - parallelism
-  - name: Lifecycle
-    fields:
-    - completions
-    - completionMode
-    - backoffLimit
-    - activeDeadlineSeconds
-    - ttlSecondsAfterFinished
-    - suspend
-  - name: Selector
-    fields:
-    - selector
-    - manualSelector
-
-- definition: io.k8s.api.batch.v1.JobStatus
-  field_categories:
-  - fields:
-    - startTime
-    - completionTime
-    - active
-    - failed
-    - succeeded
-    - completedIndexes
-    - conditions
-    - uncountedTerminatedPods
-  - name: Alpha level
-    fields:
-    - ready
-
-- definition: io.k8s.api.batch.v1.CronJobSpec
-  field_categories:
-  - fields:
-    - jobTemplate
-    - schedule
-    - concurrencyPolicy
-    - startingDeadlineSeconds
-    - suspend
-    - successfulJobsHistoryLimit
-    - failedJobsHistoryLimit
-
-- definition: io.k8s.api.autoscaling.v2beta2.HorizontalPodAutoscalerSpec
-  field_categories:
-  - fields:
-    - maxReplicas
-    - scaleTargetRef
-    - minReplicas
-    - behavior
-    - metrics
-
-- definition: io.k8s.api.autoscaling.v2beta2.HPAScalingPolicy
-  field_categories:
-  - fields:
-    - type
-    - value
-    - periodSeconds
-
-- definition: io.k8s.api.autoscaling.v2.HorizontalPodAutoscalerSpec
-  field_categories:
-  - fields:
-    - maxReplicas
-    - scaleTargetRef
-    - minReplicas
-    - behavior
-    - metrics
-
-- definition: io.k8s.api.autoscaling.v2.HPAScalingPolicy
-  field_categories:
-  - fields:
-    - type
-    - value
-    - periodSeconds
-
-- definition: io.k8s.api.core.v1.ServiceSpec
-  field_categories:
-  - fields:
-    - selector
-    - ports
-    - type
-    - ipFamilies
-    - ipFamilyPolicy
-    - clusterIP
-    - clusterIPs
-    - externalIPs
-    - sessionAffinity
-    - loadBalancerIP
-    - loadBalancerSourceRanges
-    - loadBalancerClass
-    - externalName
-    - externalTrafficPolicy
-    - internalTrafficPolicy
-    - healthCheckNodePort
-    - publishNotReadyAddresses
-    - sessionAffinityConfig
-    - allocateLoadBalancerNodePorts
-
-- definition: io.k8s.api.core.v1.ServicePort
-  field_categories:
-  - fields:
-    - port
-    - targetPort
-    - protocol
-    - name
-    - nodePort
-    - appProtocol
-
-- definition: io.k8s.api.core.v1.EndpointSubset
-  field_categories:
-  - fields:
-    - addresses
-    - notReadyAddresses
-    - ports
-
-- definition: io.k8s.api.core.v1.EndpointPort
-  field_categories:
-  - fields:
-    - port
-    - protocol
-    - name
-    - appProtocol
-
-- definition: io.k8s.api.discovery.v1.EndpointPort
-  field_categories:
-  - fields:
-    - port
-    - protocol
-    - name
-    - appProtocol
-
-- definition: io.k8s.api.core.v1.Volume
-  field_categories:
-  - fields:
-    - name
-  - name: Exposed Persistent volumes
-    fields:
-    - persistentVolumeClaim
-  - name: Projections
-    fields:
-    - configMap
-    - secret
-    - downwardAPI
-    - projected
-  - name: Local / Temporary Directory
-    fields:
-    - emptyDir
-    - hostPath
-  - name: Persistent volumes
-    fields:
-    - awsElasticBlockStore
-    - azureDisk
-    - azureFile
-    - cephfs
-    - cinder
-    - csi
-    - fc
-    - flexVolume
-    - flocker
-    - gcePersistentDisk
-    - glusterfs
-    - iscsi
-    - nfs
-    - photonPersistentDisk
-    - portworxVolume
-    - quobyte
-    - rbd
-    - scaleIO
-    - storageos
-    - vsphereVolume
-  - name: Alpha level
-    fields:
-    - ephemeral
-  - name: Deprecated
-    fields:
-    - gitRepo
-
-- definition: io.k8s.api.core.v1.ConfigMapVolumeSource
-  field_categories:
-  - fields:
-    - name
-    - optional
-    - defaultMode
-    - items
-
-- definition: io.k8s.api.core.v1.SecretVolumeSource
-  field_categories:
-  - fields:
-    - secretName
-    - optional
-    - defaultMode
-    - items
-
-- definition: io.k8s.api.core.v1.ConfigMapProjection
-  field_categories:
-  - fields:
-    - name
-    - optional
-    - items
-
-- definition: io.k8s.api.core.v1.SecretProjection
-  field_categories:
-  - fields:
-    - name
-    - optional
-    - items
-
-- definition: io.k8s.api.core.v1.ProjectedVolumeSource
-  field_categories:
-  - fields:
-    - defaultMode
-    - sources
-
-- definition: io.k8s.api.core.v1.PersistentVolumeClaimSpec
-  field_categories:
-  - fields:
-    - accessModes
-    - selector
-    - resources
-    - volumeName
-    - storageClassName
-    - volumeMode
-  - name: Alpha level
-    fields:
-    - dataSource
-    - dataSourceRef
-
-- definition: io.k8s.api.core.v1.PersistentVolumeSpec
-  field_categories:
-  - fields:
-    - accessModes
-    - capacity
-    - claimRef
-    - mountOptions
-    - nodeAffinity
-    - persistentVolumeReclaimPolicy
-    - storageClassName
-    - volumeMode
-  - name: Local
-    fields:
-    - hostPath
-    - local
-  - name: Persistent volumes
-    fields:
-    - awsElasticBlockStore
-    - azureDisk
-    - azureFile
-    - cephfs
-    - cinder
-    - csi
-    - fc
-    - flexVolume
-    - flocker
-    - gcePersistentDisk
-    - glusterfs
-    - iscsi
-    - nfs
-    - photonPersistentDisk
-    - portworxVolume
-    - quobyte
-    - rbd
-    - scaleIO
-    - storageos
-    - vsphereVolume
-
-- definition: io.k8s.api.rbac.v1.PolicyRule
-  field_categories:
-  - fields:
-    - apiGroups
-    - resources
-    - verbs
-    - resourceNames
-    - nonResourceURLs
-
-- definition: io.k8s.api.networking.v1.NetworkPolicySpec
-  field_categories:
-  - fields:
-    - podSelector
-    - policyTypes
-    - ingress
-    - egress
-
-- definition: io.k8s.api.networking.v1.NetworkPolicyEgressRule
-  field_categories:
-  - fields:
-    - to
-    - ports
-
-- definition: io.k8s.api.networking.v1.NetworkPolicyPort
-  field_categories:
-  - fields:
-    - port
-    - endPort
-    - protocol
-
-- definition: io.k8s.api.policy.v1beta1.PodSecurityPolicySpec
-  field_categories:
-  - fields:
-    - runAsUser
-    - runAsGroup
-    - fsGroup
-    - supplementalGroups
-    - seLinux
-    - readOnlyRootFilesystem
-    - privileged
-    - allowPrivilegeEscalation
-    - defaultAllowPrivilegeEscalation
-    - allowedCSIDrivers
-    - allowedCapabilities
-    - requiredDropCapabilities
-    - defaultAddCapabilities
-    - allowedFlexVolumes
-    - allowedHostPaths
-    - allowedProcMountTypes
-    - allowedUnsafeSysctls
-    - forbiddenSysctls
-    - hostIPC
-    - hostNetwork
-    - hostPID
-    - hostPorts
-    - runtimeClass
-    - volumes
-
-- definition: io.k8s.apimachinery.pkg.apis.meta.v1.ObjectMeta
-  field_categories:
-  - fields:
-    - name
-    - generateName
-    - namespace
-    - labels
-    - annotations
-  - name: System
-    fields:
-    - finalizers
-    - managedFields
-    - ownerReferences
-  - name: Read-only
-    fields:
-    - creationTimestamp
-    - deletionGracePeriodSeconds
-    - deletionTimestamp
-    - generation
-    - resourceVersion
-    - selfLink
-    - uid
-  - name: Ignored
-    fields:
-    - clusterName

api-ref-assets/config/toc.yaml

@@ -1,270 +0,0 @@
-# Copyright 2016 The Kubernetes Authors.
-# Copyright 2020 Philippe Martin
-# 
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-# 
-#     http://www.apache.org/licenses/LICENSE-2.0
-# 
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-parts:
-- name: Workload Resources
-  chapters:
-  - name: Pod
-    group: ""
-    version: v1
-    otherDefinitions:
-    - PodSpec
-    - Container
-    - EphemeralContainer
-    - LifecycleHandler
-    - NodeAffinity
-    - PodAffinity
-    - PodAntiAffinity
-    - Probe
-    - PodStatus
-    - PodList
-  - name: PodTemplate
-    group: ""
-    version: v1
-  - name: ReplicationController
-    group: ""
-    version: v1
-  - name: ReplicaSet
-    group: apps
-    version: v1
-  - name: Deployment
-    group: apps
-    version: v1
-  - name: StatefulSet
-    group: apps
-    version: v1
-  - name: ControllerRevision
-    group: apps
-    version: v1
-  - name: DaemonSet
-    group: apps
-    version: v1
-  - name: Job
-    group: batch
-    version: v1
-  - name: CronJob
-    group: batch
-    version: v1
-  - name: HorizontalPodAutoscaler
-    group: autoscaling
-    version: v1
-  - name: HorizontalPodAutoscaler
-    group: autoscaling
-    version: v2
-  - name: HorizontalPodAutoscaler
-    group: autoscaling
-    version: v2beta2
-  - name: PriorityClass
-    group: scheduling.k8s.io
-    version: v1
-- name: Service Resources
-  chapters:
-  - name: Service
-    group: ""
-    version: v1
-  - name: Endpoints
-    group: ""
-    version: v1
-  - name: EndpointSlice
-    group: discovery.k8s.io
-    version: v1
-  - name: Ingress
-    group: networking.k8s.io
-    version: v1
-    otherDefinitions:
-    - IngressSpec
-    - IngressBackend
-    - IngressStatus
-    - IngressList
-  - name: IngressClass
-    group: networking.k8s.io
-    version: v1
-- name: Config and Storage Resources
-  chapters:
-  - name: ConfigMap
-    group: ""
-    version: v1
-  - name: Secret
-    group: ""
-    version: v1
-  - name: Volume
-    key: io.k8s.api.core.v1.Volume
-    otherDefinitions:
-    - DownwardAPIVolumeFile
-    - KeyToPath
-  - name: PersistentVolumeClaim
-    group: ""
-    version: v1
-  - name: PersistentVolume
-    group: ""
-    version: v1
-  - name: StorageClass
-    group: storage.k8s.io
-    version: v1
-  - name: VolumeAttachment
-    group: storage.k8s.io
-    version: v1
-  - name: CSIDriver
-    group: storage.k8s.io
-    version: v1
-  - name: CSINode
-    group: storage.k8s.io
-    version: v1
-  - name: CSIStorageCapacity
-    group: storage.k8s.io
-    version: v1beta1
-- name: Authentication Resources
-  chapters:
-  - name: ServiceAccount
-    group: ""
-    version: v1
-  - name: TokenRequest
-    group: authentication.k8s.io
-    version: v1
-  - name: TokenReview
-    group: authentication.k8s.io
-    version: v1
-  - name: CertificateSigningRequest
-    group: certificates.k8s.io
-    version: v1
-- name: Authorization Resources
-  chapters:
-  - name: LocalSubjectAccessReview
-    group: authorization.k8s.io
-    version: v1
-  - name: SelfSubjectAccessReview
-    group: authorization.k8s.io
-    version: v1
-  - name: SelfSubjectRulesReview
-    group: authorization.k8s.io
-    version: v1
-  - name: SubjectAccessReview
-    group: authorization.k8s.io
-    version: v1
-  - name: ClusterRole
-    group: rbac.authorization.k8s.io
-    version: v1
-  - name: ClusterRoleBinding
-    group: rbac.authorization.k8s.io
-    version: v1
-  - name: Role
-    group: rbac.authorization.k8s.io
-    version: v1
-  - name: RoleBinding
-    group: rbac.authorization.k8s.io
-    version: v1
-- name: Policy Resources
-  chapters:
-  - name: LimitRange
-    group: ""
-    version: v1
-  - name: ResourceQuota
-    group: ""
-    version: v1
-  - name: NetworkPolicy
-    group: networking.k8s.io
-    version: v1
-  - name: PodDisruptionBudget
-    group: policy
-    version: v1
-  - name: PodSecurityPolicy
-    group: policy
-    version: v1beta1
-- name: Extend Resources
-  chapters:
-  - name: CustomResourceDefinition
-    group: apiextensions.k8s.io
-    version: v1
-    otherDefinitions:
-    - CustomResourceDefinitionSpec
-    - JSONSchemaProps
-    - CustomResourceDefinitionStatus
-    - CustomResourceDefinitionList
-  - name: MutatingWebhookConfiguration
-    group: admissionregistration.k8s.io
-    version: v1
-  - name: ValidatingWebhookConfiguration
-    group: admissionregistration.k8s.io
-    version: v1
-- name: Cluster Resources
-  chapters:
-  - name: Node
-    group: ""
-    version: v1
-  - name: Namespace
-    group: ""
-    version: v1
-  - name: Event
-    group: events.k8s.io
-    version: v1
-  - name: APIService
-    group: apiregistration.k8s.io
-    version: v1
-  - name: Lease
-    group: coordination.k8s.io
-    version: v1
-  - name: RuntimeClass
-    group: node.k8s.io
-    version: v1
-  - name: FlowSchema
-    group: flowcontrol.apiserver.k8s.io
-    version: v1beta2
-  - name: PriorityLevelConfiguration
-    group: flowcontrol.apiserver.k8s.io
-    version: v1beta2
-  - name: Binding
-    group: ""
-    version: v1
-  - name: ComponentStatus
-    group: ""
-    version: v1
-- name: Common Definitions
-  chapters:
-  - name: DeleteOptions
-    key: io.k8s.apimachinery.pkg.apis.meta.v1.DeleteOptions
-  - name: LabelSelector
-    key: io.k8s.apimachinery.pkg.apis.meta.v1.LabelSelector
-  - name: ListMeta
-    key: io.k8s.apimachinery.pkg.apis.meta.v1.ListMeta
-  - name: LocalObjectReference
-    key: io.k8s.api.core.v1.LocalObjectReference
-  - name: NodeSelectorRequirement
-    key: io.k8s.api.core.v1.NodeSelectorRequirement
-  - name: ObjectFieldSelector
-    key: io.k8s.api.core.v1.ObjectFieldSelector
-  - name: ObjectMeta
-    key: io.k8s.apimachinery.pkg.apis.meta.v1.ObjectMeta
-  - name: ObjectReference
-    key: io.k8s.api.core.v1.ObjectReference
-  - name: Patch
-    key: io.k8s.apimachinery.pkg.apis.meta.v1.Patch
-  - name: Quantity
-    key: "io.k8s.apimachinery.pkg.api.resource.Quantity"
-  - name: ResourceFieldSelector
-    key: io.k8s.api.core.v1.ResourceFieldSelector
-  - name: Status
-    key: io.k8s.apimachinery.pkg.apis.meta.v1.Status
-  - name: TypedLocalObjectReference
-    key: io.k8s.api.core.v1.TypedLocalObjectReference
-skippedResources:
-- APIGroup
-- APIGroupList
-- APIResourceList
-- APIVersions
-- Eviction
-- Scale
-- Status
-- StorageVersion
-- StorageVersionList

api-ref-assets/templates/chapter-single-definition.tmpl

@@ -1,83 +0,0 @@
----
-api_metadata:
-  apiVersion: "{{.ApiVersion}}"
-  import: "{{.Import}}"
-  kind: "{{.Kind}}"
-content_type: "api_reference"
-description: "{{.Metadata.Description}}"
-title: "{{.Metadata.Title}}"
-weight: {{.Metadata.Weight}}
-auto_generated: true
----
-
-<!--
-The file is auto-generated from the Go source code of the component using a generic
-[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
-to generate the reference documentation, please read
-[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
-To update the reference content, please follow the 
-[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
-guide. You can file document formatting bugs against the
-[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
--->
-
-{{if .ApiVersion}}`apiVersion: {{.ApiVersion}}`{{end}}
-
-{{if .Import}}`import "{{.Import}}"`{{end}}
-
-{{range .Sections}}
-{{.Description | replace "<" "\\<" }}
-
-<hr>
-{{range .Fields}}
-{{ ""  | indent .Indent | indent .Indent}}- {{.Name}}{{if .Value}}: {{.Value}}{{end}}
-{{if .Description}}
-{{.Description | replace "<" "\\<" | indent 2 | indent .Indent | indent .Indent}}
-{{- end}}
-{{if .TypeDefinition}}
-{{ ""  | indent .Indent | indent .Indent}}  <a name="{{.Type}}"></a>
-{{.TypeDefinition | indent 2 | indent .Indent | indent .Indent}}
-{{end}}
-{{- end}}{{/* range .Fields */}}
-
-{{range .FieldCategories}}
-### {{.Name}} {#{{"-" | regexReplaceAll "[^a-zA-Z0-9]+" .Name }}}{{/* explicitly set fragment to keep capitalization */}}
-
-{{range .Fields}}
-{{ ""  | indent .Indent | indent .Indent}}- {{.Name}}{{if .Value}}: {{.Value}}{{end}}
-{{if .Description}}
-{{.Description | replace "<" "\\<" | indent 2 | indent .Indent | indent .Indent}}
-{{- end}}
-{{if .TypeDefinition}}
-{{ ""  | indent .Indent | indent .Indent}}  <a name="{{.Type}}"></a>
-{{.TypeDefinition | indent 2 | indent .Indent | indent .Indent}}
-{{end}}
-{{- end}}{{/* range .Fields */}}
-
-{{- end}}{{/* range .FieldCategories */}}
-
-{{range .Operations}}
-
-### `{{.Verb}}` {{.Title}}
-
-#### HTTP Request
-
-{{.RequestMethod}} {{.RequestPath}}
-
-#### Parameters
-
-{{range .Parameters}}
-- {{.Title}}
-
-{{.Description | indent 2}}
-
-{{end}}{{/* range .Parameters */}}
-
-#### Response
-
-{{range .Responses}}
-{{.Code}}{{if .Type}} ({{.Type}}){{end}}: {{.Description}}
-{{end}}{{/* range .Responses */}}
-
-{{- end}}{{/* range .Operations */}}
-{{- end}}{{/* range .Sections */}}

api-ref-assets/templates/chapter.tmpl

@@ -1,85 +0,0 @@
----
-api_metadata:
-  apiVersion: "{{.ApiVersion}}"
-  import: "{{.Import}}"
-  kind: "{{.Kind}}"
-content_type: "api_reference"
-description: "{{.Metadata.Description}}"
-title: "{{.Metadata.Title}}"
-weight: {{.Metadata.Weight}}
-auto_generated: true
----
-
-<!--
-The file is auto-generated from the Go source code of the component using a generic
-[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
-to generate the reference documentation, please read
-[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
-To update the reference content, please follow the 
-[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
-guide. You can file document formatting bugs against the
-[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
--->
-
-{{if .ApiVersion}}`apiVersion: {{.ApiVersion}}`{{end}}
-
-{{if .Import}}`import "{{.Import}}"`{{end}}
-
-{{range .Sections}}
-## {{.Name}} {#{{"-" | regexReplaceAll "[^a-zA-Z0-9]+" .Name }}}{{/* explicitly set fragment to keep capitalization */}}
-
-{{.Description | replace "<" "\\<" }}
-
-<hr>
-{{range .Fields}}
-{{ ""  | indent .Indent | indent .Indent}}- {{.Name}}{{if .Value}}: {{.Value}}{{end}}
-{{if .Description}}
-{{.Description | replace "<" "\\<" | indent 2 | indent .Indent | indent .Indent}}
-{{- end}}
-{{if .TypeDefinition}}
-{{ ""  | indent .Indent | indent .Indent}}  <a name="{{.Type}}"></a>
-{{.TypeDefinition | indent 2 | indent .Indent | indent .Indent}}
-{{end}}
-{{- end}}{{/* range .Fields */}}
-
-{{range .FieldCategories}}
-### {{.Name}}
-
-{{range .Fields}}
-{{ ""  | indent .Indent | indent .Indent}}- {{.Name}}{{if .Value}}: {{.Value}}{{end}}
-{{if .Description}}
-{{.Description | replace "<" "\\<" | indent 2 | indent .Indent | indent .Indent}}
-{{- end}}
-{{if .TypeDefinition}}
-{{ ""  | indent .Indent | indent .Indent}}  <a name="{{.Type}}"></a>
-{{.TypeDefinition | indent 2 | indent .Indent | indent .Indent}}
-{{end}}
-{{- end}}{{/* range .Fields */}}
-
-{{- end}}{{/* range .FieldCategories */}}
-
-{{range .Operations}}
-
-### `{{.Verb}}` {{.Title}}
-
-#### HTTP Request
-
-{{.RequestMethod}} {{.RequestPath}}
-
-#### Parameters
-
-{{range .Parameters}}
-- {{.Title}}
-
-{{.Description | indent 2}}
-
-{{end}}{{/* range .Parameters */}}
-
-#### Response
-
-{{range .Responses}}
-{{.Code}}{{if .Type}} ({{.Type}}){{end}}: {{.Description}}
-{{end}}{{/* range .Responses */}}
-
-{{- end}}{{/* range .Operations */}}
-{{- end}}{{/* range .Sections */}}

api-ref-assets/templates/part-index.tmpl

@@ -1,17 +0,0 @@
----
-title: "{{.Title}}"
-weight: {{.Weight}}
-auto_generated: true
----
-
-<!--
-The file is auto-generated from the Go source code of the component using a generic
-[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
-to generate the reference documentation, please read
-[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
-To update the reference content, please follow the 
-[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
-guide. You can file document formatting bugs against the
-[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
--->
-

assets/scss/_base.scss

@@ -810,10 +810,11 @@ section#cncf {
   }
 }
 
-// Header filler size adjustment
-
-.header-hero.filler {
-  height: $hero-padding-top;
+.td-search {
+  header > .header-filler {
+    height: $hero-padding-top;
+    background-color: black;
+  }
 }
 
 // Docs specific
@@ -858,6 +859,17 @@ section#cncf {
 
 /* DOCUMENTATION */
 
+body.td-documentation {
+    header > .header-filler {
+      height: $hero-padding-top;
+      background-color: black;
+    }
+    /* Special case for if an announcement is active */
+    header section#announcement ~ .header-filler {
+      display: none;
+    }
+}
+
 // nav-tabs and tab-content
 .nav-tabs {
   border-bottom: none !important;

assets/scss/_custom.scss

@@ -7,7 +7,7 @@ $announcement-size-adjustment: 8px;
   }
 
   main {
-    *:not(figure) > img {
+    img {
       max-width: 100%;
     }
 
@@ -26,10 +26,6 @@ $announcement-size-adjustment: 8px;
   }
 }
 
-.header-hero #quickstartButton.button {
-  margin-top: 1em;
-}
-
 section {
   .main-section {
     @media only screen and (min-width: 1024px) {
@@ -38,11 +34,8 @@ section {
   }
 }
 
-body {
-  header + .td-outer {
-    min-height: 50vh;
-    height: auto;
-  }
+.td-outer {
+  padding: 0 !important;
 }
 
 
@@ -222,14 +215,8 @@ footer {
   padding: 1rem !important;
   min-height: initial !important;
 
-  > div, > p {
-    max-width: 95%;
-    @media only screen and (min-width: 768px) {
-      max-width: calc(min(80rem,90vw)); // avoid spreading too wide
-    }
-  }
-
-  > .footer__links {
+  .footer__links {
+    width: 100%;
     margin: auto;
     padding-bottom: 1rem;
 
@@ -239,8 +226,6 @@ footer {
     }
 
     @media only screen and (min-width: 768px) {
-      max-width: calc(min(60rem,90vw)); // avoid spreading too wide
-
       nav {
         display: flex;
         flex-direction: row;
@@ -313,12 +298,6 @@ footer {
   padding-top: 1.5rem !important;
   top: 5rem !important;
 
-  @supports (position: sticky) {
-    position: sticky !important;
-    height: calc(100vh - 10rem);
-    overflow-y: auto;
-  }
-
   #TableOfContents {
     padding-top: 1rem;
   }
@@ -334,68 +313,37 @@ main {
 
 // blockquotes and callouts
 
-body {
-  .alert {
-    // Override Docsy styles
+.td-content, body {
+  blockquote.callout {
     padding: 0.4rem 0.4rem 0.4rem 1rem;
-    border-top: 1px solid #eee;
-    border-bottom: 1px solid #eee;
-    border-right: 1px solid #eee;
-    border-radius: 0.25em;
-    border-left-width: 0.5em; // fallback in case calc() is missing
+    border: 1px solid #eee;
+    border-left-width: 0.5em;
     background: #fff;
     color: #000;
     margin-top: 0.5em;
     margin-bottom: 0.5em;
   }
-  // Set minimum width and radius for alert color
-  .alert {
-      border-left-width: calc(max(0.5em, 4px));
-      border-top-left-radius: calc(max(0.5em, 4px));
-      border-bottom-left-radius: calc(max(0.5em, 4px));
+  blockquote.callout {
+    border-radius: calc(1em/3);
   }
-  .alert.callout.caution {
+  .callout.caution {
     border-left-color: #f0ad4e;
   }
-  .alert.callout.note {
+
+  .callout.note {
     border-left-color: #428bca;
   }
-  .alert.callout.warning {
+
+  .callout.warning {
     border-left-color: #d9534f;
   }
-  .alert.third-party-content {
-    border-left-color: #444;
-  }
 
-  h1:first-of-type + .alert.callout {
+  h1:first-of-type + blockquote.callout {
     margin-top: 1.5em;
   }
 }
 
-// Special color for third party content disclaimers
-.alert.third-party-content { border-left-color: #222 };
-
-// Highlight disclaimer when targeted as a fragment
-
-#third-party-content-disclaimer {
-  color: #000;
-  background: #f8f9fa;
-  transition: all 0.5s ease;
-}
-
-@keyframes disclaimer-highlight {
-  from { background: #f8f922; color: #000; }
-  50% { background: #f8f944; color: #000; }
-  to { background: #f8f9cb; color: #000; }
-}
-
-#third-party-content-disclaimer:target {
-  color: #000;
-  animation: disclaimer-highlight 1.25s ease;
-  background: #f8f9cb;
-}
-
-.deprecation-warning, .pageinfo.deprecation-warning {
+.deprecation-warning {
     padding: 20px;
     margin: 20px 0;
     background-color: #faf5b6;
@@ -406,12 +354,6 @@ body.td-home .deprecation-warning, body.td-blog .deprecation-warning, body.td-do
     border-radius: 3px;
 }
 
-
-.td-documentation .td-content > .highlight {
-  max-width: initial;
-  width: 100%;
-}
-
 body.td-home #deprecation-warning {
     max-width: 1000px;
     margin-top: 2.5rem;
@@ -582,6 +524,34 @@ main.content {
   }
 }
 
+/* ANNOUNCEMENTS */
+section#fp-announcement ~ .header-hero {
+    padding: $announcement-size-adjustment  0;
+
+    > div {
+       margin-top: $announcement-size-adjustment;
+       margin-bottom: $announcement-size-adjustment;
+    }
+
+    h1, h2, h3, h4, h5 {
+      margin: $announcement-size-adjustment 0;
+    }
+}
+
+section#announcement ~ .header-hero {
+    padding: #{$announcement-size-adjustment / 2} 0;
+
+    > div {
+       margin-top: #{$announcement-size-adjustment / 2};
+       margin-bottom: #{$announcement-size-adjustment / 2};
+       padding-bottom: #{$announcement-size-adjustment / 2};
+    }
+
+    h1, h2, h3, h4, h5 {
+      margin: #{$announcement-size-adjustment / 2} 0;
+    }
+}
+
 /* DOCUMENTATION */
 
 /* Don't show lead text */
@@ -607,15 +577,15 @@ body.td-documentation {
 
 @media print {
   /* Do not print announcements */
-  #announcement {
+  #announcement, section#announcement, #fp-announcement, section#fp-announcement {
     display: none;
   }
 }
 
-#announcement {
+#announcement, #fp-announcement {
   > * {
     color: inherit;
-    background: transparent;
+    background: inherit;
   }
 
   a {
@@ -629,117 +599,42 @@ body.td-documentation {
   }
 }
 
+#announcement {
+  padding-top: 105px;
+  padding-bottom: 25px;
+}
+
 .header-hero {
   padding-top: 40px;
 }
 
-#announcement {
-  .announcement-main {
-    margin-left: auto;
-    margin-right: auto;
+/* Extra announcement height only for landscape viewports */
+@media (min-aspect-ratio: 8/9) {
+  #fp-announcement {
+    min-height: 25vh;
+  }
+}
+
+#fp-announcement aside {
+  padding-top: 115px;
+  padding-bottom: 25px;
+}
+
+.announcement {
+  .content {
     margin-bottom: 0px;
-
-    // for padding-top see _size.scss
-    padding-bottom: calc(max(2em, 2rem));
-
-    max-width: calc(min(1200px - 8em, 80vw));
   }
 
 
-  /* always white */
-  h1, h2, h3, h4, h5, h6, p * {
-    color: #ffffff;
-    background: transparent;
-
-    img.event-logo {
-      display: inline-block;
-      max-height: calc(min(80px, 8em));
-      max-width: calc(min(240px, 33vw));
-      float: right;
+  > p {
+    .gridPage #announcement .content p,
+    .announcement > h4,
+    .announcement > h3 {
+      color: #ffffff;
     }
   }
 }
 
-#announcement + .header-hero {
-  padding-top: 2em;
-}
-
-// Extra padding for anything except wide viewports
-@media (min-width: 992px) {
-  #announcement aside { // more specific
-    .announcement-main {
-      padding-top: calc(max(8em, 8rem));
-    }
-  }
-}
-
-@media (max-width: 768px) {
-  #announcement {
-    padding-top: 4rem;
-    padding-bottom: 4rem;
-    .announcement-main, aside .announcement-main {
-      padding-top: calc(min(2rem,2em));
-    }
-  }
-}
-
-@media (max-width: 480px) {
-  #announcement {
-    padding-bottom: 0.5em;
-  }
-  #announcement aside {
-    h1, h2, h3, h4, h5, h6 {
-      img.event-logo {
-        margin-left: auto;
-        margin-right: auto;
-        margin-bottom: 0.75em;
-        display: block;
-        max-height: initial;
-        max-width: calc(min(calc(100vw - 2em), 240px));
-        float: initial;
-      }
-    }
-  }
-}
-
-#announcement + .header-hero.filler {
-  display: none;
-}
-
-@media (min-width: 768px) {
-  #announcement + .header-hero {
-    display: none;
-  }
-}
-
-figure {
-  > figcaption {
-    padding-top: 1em;
-    margin-bottom: 3em;
-  }
-}
-
-// Clamp size for release logos
-figure.release-logo {
-  > figcaption {
-    font-size: 1.8em;
-  }
-  > img {
-    max-width: 100%;
-    max-height: calc(max(40em,min(80vh,70em)));
-    height: auto;
-    width: auto;
-  }
-}
-
-
-// Match Docsy-imposed max width on text body
-@media (min-width: 1200px) {
-  body.td-blog main .td-content > figure {
-    max-width: 80%;
-  }
-}
-
 .td-content {
   table code {
     background-color: inherit !important;
@@ -747,76 +642,3 @@ figure.release-logo {
     font-size: inherit !important;
   }
 }
-
-/* Force size constraints on figures */
-figure {
-  &.diagram-small img {
-    max-height: clamp(20mm,12em,80vh);
-    margin-left: auto;
-    margin-right: auto;
-    display: block;
-  }
-  &.diagram-medium img {
-    max-height: clamp(25mm,20em,80vh);
-    margin-left: auto;
-    margin-right: auto;
-    display: block;
-  }
-  &.diagram-large img {
-    max-width: clamp(0vw, 95vw, 100%);
-    max-height: calc(80vh - 8rem);
-  }
-}
-
-@media only screen and (min-width: 768px) {
-  figure {
-    &.diagram-small, &.diagram-medium {
-      max-width: 80%;
-    }
-    &.diagram-large {
-      max-width: 100%;
-      width: 100%;
-    }
-    &.diagram-small img {
-      max-width: clamp(30rem, 45ch, 100mm);
-    }
-    &.diagram-medium img {
-      max-width: clamp(50rem, 20ch, 160mm);
-    }
-    &.diagram-large img {
-      max-width: clamp(25vw, 95vw, 100%);
-      max-height: calc(100vh - 10rem);
-    }
-  }
-}
-
-// Indent definition lists
-dl {
-  padding-left: 1.5em;
-
-  // Add vertical space before definitions
-  > *:not(dt) + dt, dt:first-child {
-    margin-top: 1.5em;
-  }
-}
-
-.release-details {
-  padding-left: 2em;
-
-  > :not(p) {
-    font-size: 1.125em;
-  }
-
-  .release-inline-heading, .release-inline-value {
-    display: inline-block
-  }
-
-  .release-inline-value {
-    padding-left: 0.25em;
-  }
-
-  p {
-     margin-top: 1em;
-     margin-bottom: 1em;
-  }
-}

assets/scss/_size.scss

@@ -18,11 +18,3 @@ section,
   line-height: $vendor-strip-height;
   font-size: $vendor-strip-font-size;
 }
-
-#announcement {
-  min-height: $hero-padding-top;
-
-  .announcement-main {
-    padding-top: calc(max(8em, 8rem, #{$hero-padding-top} / 3));
-  }
-}

cloudbuild.yaml

@@ -8,7 +8,7 @@ options:
   substitution_option: ALLOW_LOOSE
 steps:
     # It's fine to bump the tag to a recent version, as needed
-  - name: "gcr.io/k8s-staging-test-infra/gcb-docker-gcloud:v20210917-12df099d55"
+  - name: "gcr.io/k8s-testimages/gcb-docker-gcloud:v20190906-745fed4"
     entrypoint: make
     env:
       - DOCKER_CLI_EXPERIMENTAL=enabled

config.toml

@@ -123,7 +123,6 @@ id = "UA-00000000-0"
 [params]
 copyright_k8s = "The Kubernetes Authors"
 copyright_linux =  "Copyright © 2020 The Linux Foundation ®."
-
 # privacy_policy = "https://policies.google.com/privacy"
 
 # First one is picked as the Twitter card image if not set on page.
@@ -139,13 +138,13 @@ time_format_default = "January 02, 2006 at 3:04 PM PST"
 description = "Production-Grade Container Orchestration"
 showedit = true
 
-latest = "v1.23"
+latest = "v1.24"
 
-fullversion = "v1.23.0"
-version = "v1.23"
-githubbranch = "main"
-docsbranch = "main"
-deprecated = false
+fullversion = "v1.21.12"
+version = "v1.21"
+githubbranch = "release-1.21"
+docsbranch = "release-1.21"
+deprecated = true
 currentUrl = "https://kubernetes.io/docs/home/"
 nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/"
 
@@ -179,46 +178,44 @@ js = [
 ]
 
 [[params.versions]]
-fullversion = "v1.23.0"
-version = "v1.23"
-githubbranch = "v1.23.0"
+fullversion = "v1.24.0"
+version = "v1.24"
+githubbranch = "v1.24.0"
 docsbranch = "main"
 url = "https://kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.22.4"
+fullversion = "v1.23.6"
+version = "v1.23"
+githubbranch = "v1.23.6"
+docsbranch = "release-1.23"
+url = "https://v1-23.docs.kubernetes.io"
+
+[[params.versions]]
+fullversion = "v1.22.9"
 version = "v1.22"
-githubbranch = "v1.22.4"
+githubbranch = "v1.22.9"
 docsbranch = "release-1.22"
 url = "https://v1-22.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.21.7"
+fullversion = "v1.21.12"
 version = "v1.21"
-githubbranch = "v1.21.7"
+githubbranch = "v1.21.12"
 docsbranch = "release-1.21"
 url = "https://v1-21.docs.kubernetes.io"
 
 [[params.versions]]
-fullversion = "v1.20.13"
+fullversion = "v1.20.15"
 version = "v1.20"
-githubbranch = "v1.20.13"
+githubbranch = "v1.20.15"
 docsbranch = "release-1.20"
 url = "https://v1-20.docs.kubernetes.io"
 
-[[params.versions]]
-fullversion = "v1.19.16"
-version = "v1.19"
-githubbranch = "v1.19.16"
-docsbranch = "release-1.19"
-url = "https://v1-19.docs.kubernetes.io"
-
 # User interface configuration
 [params.ui]
 # Enable to show the side bar menu in its compact state.
 sidebar_menu_compact = false
-# https://github.com/gohugoio/hugo/issues/8918#issuecomment-903314696
-sidebar_cache_limit = 1
 #  Set to true to disable breadcrumb navigation.
 breadcrumb_disable = false
 #  Set to true to hide the sidebar search box (the top nav search box will still be displayed if search is enabled)

content/de/_index.html

@@ -9,7 +9,7 @@ cid: home
 {{% blocks/feature image="flower" %}}
 ### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen.
 
-Es gruppiert Container, aus denen sich eine Anwendung zusammensetzt, in logische Einheiten, um die Verwaltung und Erkennung zu erleichtern. Kubernetes baut auf [15 Jahre Erfahrung in Bewältigung von Produktions-Workloads bei Google](http://queue.acm.org/detail.cfm?id=2898444), kombiniert mit Best-of-Breed-Ideen und Praktiken aus der Community.
+Es gruppiert Container, aus denen sich eine Anwendung zusammensetzt, in logische Einheiten, um die Verwaltung und Erkennung zu erleichtern. Kubernetes baut auf [15 Jahre Erfahrung in Bewältigung von Produktions-Workloads bei Google] (http://queue.acm.org/detail.cfm?id=2898444), kombiniert mit Best-of-Breed-Ideen und Praktiken aus der Community.
 {{% /blocks/feature %}}
 
 {{% blocks/feature image="scalable" %}}
@@ -42,12 +42,12 @@ Kubernetes ist Open Source und bietet Dir die Freiheit, die Infrastruktur vor Or
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Video ansehen</button>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Besuche die KubeCon Europe vom 16. bis 20. Mai 2022</a>      
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Besuche die KubeCon - 13-16 August 2020 in Amsterdam</a>
         <br>
         <br>
         <br>
         <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna22" button id="desktopKCButton">Besuchen die KubeCon North America vom 24. bis 28. Oktober 2022</a>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Besuche die KubeCon - 17-20 November 2020 in Boston</a>
 </div>
 <div id="videoPlayer">
     <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
@@ -57,4 +57,4 @@ Kubernetes ist Open Source und bietet Dir die Freiheit, die Infrastruktur vor Or
 
 {{< blocks/kubernetes-features >}}
 
-{{< blocks/case-studies >}}
+{{< blocks/case-studies >}}

content/de/community/_index.html

@@ -4,253 +4,58 @@ layout: basic
 cid: community
 ---
 
-<div class="newcommunitywrapper">
-<div class="banner1">
-  <img src="/images/community/kubernetes-community-final-02.jpg" alt="Kubernetes-Konferenz Galerie" style="width:100%;padding-left:0px" class="desktop">
-  <img src="/images/community/kubernetes-community-02-mobile.jpg" alt="Kubernetes-Konferenz Galerie" style="width:100%;padding-left:0px" class="mobile">
-</div>
+<section id="mainContent">
+    <main>
+        <div class="content">
+            <h3>Die Gewissheit, dass Kubernetes überall und für alle gut funktioniert.</h3>
+            <p>Verbinden Sie sich mit der Kubernetes-Community in unserem <a href="http://slack.k8s.io/">Slack Kanal</a>, <a href="https://discuss.kubernetes.io/">Diskussionsforum</a>, oder beteiligen Sie sich an der <a href="https://groups.google.com/g/kubernetes-dev"> Kubernetes-dev-Google-Gruppe</a>. Eine wöchentliches Community-Meeting findet per Videokonferenz statt, um den Stand der Dinge zu diskutieren, folgen Sie
+		<a href="https://github.com/kubernetes/community/blob/master/events/community-meeting.md">diesen Anweisungen</a> für Informationen wie Sie teilnehmen können.</p>
+            <p>Sie können Kubernetes auch auf der ganzen Welt über unsere
+                <a href="https://www.meetup.com/topics/kubernetes/">Kubernetes Meetup Community</a> und der
+                <a href="https://www.meetup.com/Kubernetes-Cloud-Native-Online-Meetup/">Kubernetes Cloud Native Meetup Community</a> beitreten.</p>
+          </div>
+        <div class="content">
+            <h3>Special Interest Groups (SIGs)</h3>
+            <p>Haben Sie ein besonderes Interesse daran, wie Kubernetes mit einer anderen Technologie arbeitet?  Werfen Sie einen Blick auf unsere kontinuierlich wachsende
+                <a href="https://git.k8s.io/community/sig-list.md">Listen von SIGs</a>, von AWS und Openstack bis hin zu Big Data und Skalierbarkeit, es gibt einen Platz für Sie, an dem Sie mitwirken können, und Anweisungen zur Gründung einer neuen SIG finden, wenn Ihr besonderes Interesse (noch) nicht abgedeckt ist.
+            </p>
 
-<div class="intro">
-<br class="mobile">
-<p>Die Kubernetes-Community - Nutzer, Mitwirkende und die Kultur, die wir gemeinsam aufgebaut haben - ist einer der Hauptgründe für den kometenhaften Aufstieg dieses Open-Source-Projekts. Unsere Kultur und unsere Werte wachsen und entwickeln sich mit dem Wachstum und der Veränderung des Projekts selbst. Wir alle arbeiten gemeinsam an der ständigen Verbesserung des Projekts und der Art und Weise, wie wir daran arbeiten.
-<br><br>Wir sind die Leute, die Probleme und Pull-Requests einreichen, an SIG-Treffen (Special Interest Groups), Kubernetes-Treffen und der KubeCon teilnehmen, sich für die Einführung und Innovation von Kubernetes einsetzen, <code>kubectl get pods</code> ausführen und auf tausend andere wichtige Arten beitragen. Lies weiter, um zu erfahren, wie Du dich engagieren und Teil dieser faszinierenden Gemeinschaft werden kannst.</p>
-<br class="mobile">
-</div>
+            <p>Als Mitglied der Kubernetes-Community sind Sie herzlich eingeladen, an allen SIG-Treffen teilzunehmen, die Sie interessieren. Eine Registrierung ist nicht erforderlich.</p>
 
-<div class="community__navbar">
+        </div>
 
-<a href="#values">Gemeinschaftswerte</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-<a href="#conduct">Verhaltenskodex </a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-<a href="#videos">Videos</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-<a href="#discuss">Diskussionen</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-<a href="#events">Veranstaltungen und meetups</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-<a href="#news">Neuigkeiten</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-<a href="/releases">Releases</a>
+        <div class="content">
+          <h3>Verhaltensregeln</h3>
+          <p>Die Kubernetes-Community schätzt Respekt und Inklusivität und setzt einen <a href="code-of-conduct/">Verhaltenskodex</a>
+            in allen Interaktionen durch. Wenn Sie einen Verstoß gegen den Verhaltenskodex bei einer Veranstaltung oder Sitzung,
+            in Slack oder in einem anderen Kommunikationsmechanismus feststellen, wenden Sie sich
+            bitte an das <a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct">Kubernetes Code of Conduct Committee</a> <a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>. Ihre Anonymität wird geschützt.
+          </p>
+         </div>
+    </main>
+</section>
 
-</div>
-<br class="mobile"><br class="mobile">
-<div class="imagecols">
-<br class="mobile">
-  <div class="imagecol">
-    <img src="/images/community/kubernetes-community-final-03.jpg" alt="Kubernetes-Konferenz Galerie" style="width:100%" class="desktop">
-  </div>
-
-  <div class="imagecol">
-    <img src="/images/community/kubernetes-community-final-04.jpg" alt="Kubernetes-Konferenz Galerie" style="width:100%" class="desktop">
-  </div>
-
-  <div class="imagecol" style="margin-right:0% important">
-    <img src="/images/community/kubernetes-community-final-05.jpg" alt="Kubernetes-Konferenz Galerie" style="width:100%;margin-right:0% important" class="desktop">
-  </div>
-  <img src="/images/community/kubernetes-community-04-mobile.jpg" alt="Kubernetes-Konferenz Galerie" style="width:100%;margin-bottom:3%" class="mobile">
-<a name="values"></a>
-</div>
-
-<div><a name="values"></a></div>
-<div class="conduct">
-<div class="conducttext">
-<br class="mobile"><br class="mobile">
-<br class="tablet"><br class="tablet">
-<div class="conducttextnobutton" style="margin-bottom:2%"><h1>Gemeinschaftswerte</h1>
-Die Werte der Kubernetes-Community sind der Grundstein für den anhaltenden Erfolg des Projekts.<br>
-Diese Prinzipien leiten jeden Aspekt des Kubernetes-Projekts.
-<br>
-<a href="/community/values/">
-<br class="mobile"><br class="mobile">
-<span class="fullbutton">
-  MEHR ERFAHREN
-</span>
-</a>
-</div><a name="conduct"></a>
-</div>
-</div>
-
-
-
-<div class="conduct">
-<div class="conducttext">
-<br class="mobile"><br class="mobile">
-<br class="tablet"><br class="tablet">
-<div class="conducttextnobutton" style="margin-bottom:2%"><h1>Verhaltenskodex</h1>
-Die Kubernetes-Gemeinschaft legt Wert auf Respekt und Inklusivität und setzt bei allen Interaktionen einen Verhaltenskodex durch. Wenn Du einen Verstoß gegen den Verhaltenskodex bei einer Veranstaltung oder einem Treffen, in Slack oder in einem anderen Kommunikationsmechanismus bemerkst, wende dich an das Kubernetes Code of Conduct Committee unter <a href="mailto:conduct@kubernetes.io" style="color:#0662EE;font-weight:300">conduct@kubernetes.io</a>. Alle Berichte werden vertraulich behandelt. Du kannst&nbsp;<a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct" style="color:#0662EE;font-weight:300">hier</a> mehr über den Ausschuss erfahren.
-<br>
-<a href="https://kubernetes.io/de/community/code-of-conduct/">
-<br class="mobile"><br class="mobile">
-
-<span class="fullbutton">
-MEHR ERFAHREN
-</span>
-</a>
-</div><a name="videos"></a>
-</div>
-</div>
-
-
-
-<div class="videos">
-<br class="mobile"><br class="mobile">
-<br class="tablet"><br class="tablet">
-<h1 style="margin-top:0px">Videos</h1>
-
-<div style="margin-bottom:4%;font-weight:300;text-align:center;padding-left:10%;padding-right:10%">Wir sind auf YouTube, und zwar oft. Abonniere uns für eine Vielzahl von&nbsp;Themen.</div>
-
-<div class="videocontainer">
-
-<div class="video">
-
-  <iframe width="100%" height="250" src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg" title="Monatliche Bürozeiten" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
-
-<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg">
-<div class="videocta">
-Monatliche Bürozeiten ansehen&nbsp;&#9654;</div>
-</a>
-</div>
-
-<div class="video">
-  <iframe width="100%" height="250" src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ" title="Wöchentliche Treffen der Gemeinschaft" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
-<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ">
-<div class="videocta">
-Wöchentliche Treffen der Gemeinschaft ansehen&nbsp;&#9654;
-</div>
-</a>
-</div>
-
-<div class="video">
-
-<iframe width="100%" height="250" src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F" title="Vortrag eines Mitglieds der Gemeinschaft" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
-
-<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F">
-<div class="videocta">
-Vortrag eines Mitglieds der Gemeinschaft ansehen&nbsp;&#9654;
-</div>
-
-</a>
-<a name="discuss"></a>
-</div>
-</div>
-</div>
-
-
-<div class="resources">
-<br class="mobile"><br class="mobile">
-<br class="tablet"><br class="tablet">
-<h1 style="padding-top:1%">Diskussionen</h1>
-
-<div style="font-weight:300;text-align:center">Wir reden gerne und viel. Triff uns auf einer dieser Plattformen und beteilige dich an den Diskussionen.</div>
-
-<div class="resourcecontainer">
-
-<div class="resourcebox">
-<img src="/images/community/discuss.png" alt=Forum" style="width:80%;padding-bottom:2%">
-<a href="https://discuss.kubernetes.io/" style="color:#0662EE;display:block;margin-top:1%">
-forum&nbsp;&#9654;
-</a>
-<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
-Themenbezogene technische Diskussionen, die eine Brücke zu Docs, StackOverflow und vielem mehr schlagen.
-</div>
-</div>
-
-<div class="resourcebox">
-<img src="/images/community/twitter.png" alt="Twitter" style="width:80%;padding-bottom:2%">
-<a href="https://twitter.com/kubernetesio" style="color:#0662EE;display:block;margin-top:1%">
-twitter&nbsp;&#9654;
-</a>
-<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">Echtzeit-Ankündigungen von Blogeinträgen, Veranstaltungen, Neuigkeiten und Ideen
-</div>
-</div>
-
-<div class="resourcebox">
-<img src="/images/community/github.png" alt="GitHub" style="width:80%;padding-bottom:2%">
-<a href="https://github.com/kubernetes/kubernetes" style="color:#0662EE;display:block;margin-top:1%">
-github&nbsp;&#9654;
-</a>
-<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
-Die gesamte Projekt- und Problemverfolgung und natürlich der Code
-</div>
-</div>
-
-<div class="resourcebox">
-<img src="/images/community/stack.png" alt="Stack Overflow" style="width:80%;padding-bottom:2%">
-<a href="https://stackoverflow.com/search?q=kubernetes" style="color:#0662EE;display:block;margin-top:1%">
-stack overflow&nbsp;&#9654;
-</a>
-<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
-  Technische Problemlösung für jeden Anwendungsfall
-  <a name="events"></a>
-</div>
-</div>
-
-<!--
-<div class="resourcebox">
-
-<img src="/images/community/slack.png" style="width:80%">
-
-slack&nbsp;&#9654;
-
-<div class="resourceboxtext" style="font-size:11px;text-transform:none !important;font-weight:200;line-height:1.4em;color:#333333;margin-top:4%">
-With 170+ channels, you'll find one that fits your needs.
-</div>
-
-</div>-->
-
-</div>
-</div>
-<div class="events">
-  <br class="mobile"><br class="mobile">
-  <br class="tablet"><br class="tablet">
-<div class="eventcontainer">
- <h1 style="color:white !important">Bevorstehende Veranstaltungen</h1>
-    {{< upcoming-events >}}
-</div>
-</div>
-
-<div class="meetups">
-<div class="meetupcol">
-<div class="meetuptext">
-<h1 style="text-align:left">Globale Gemeinschaft</h1>
-Mit mehr als 150 Treffen auf der ganzen Welt, Tendenz steigend, solltest du deine lokalen Kube-Leute finden. Wenn keins in der Nähe ist, nimm die Sache in die Hand und gründe dein eigenes.
-</div>
-<a href="https://www.meetup.com/topics/kubernetes/">
-<div class="button">
-EIN MEETUP FINDEN
-</div>
-</a>
-<a name="news"></a>
-</div>
-</div>
-
-
-<!--
-<div class="contributor">
-<div class="contributortext">
-<br>
-<h1 style="text-align:left">
-New Contributors Site
- </h1>
-Text about new contributors site.
-
-<br><br>
-
-<div class="button">
-VISIT SITE
-</div>
-</div>
-</div>
-
--->
-
-<div class="news">
-<br class="mobile"><br class="mobile">
-<br class="tablet"><br class="tablet">
-<h1 style="margin-bottom:2%">Aktuelle Neuigkeiten</h1>
-
-<br>
-<div class="twittercol1">
-<a class="twitter-timeline" data-tweet-limit="1" href="https://twitter.com/kubernetesio?ref_src=twsrc%5Etfw">Tweets von kubernetesio</a> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
-</div>
-
-<br>
-<br><br><br><br>
-</div>
-
-</div>
+<section id="talkToUs">
+    <main>
+        <h3>Talk to Us!</h3>
+        <h4>Wir würden uns freuen, von Ihnen zu hören, wie Sie Kubernetes verwenden<br>und was wir tun können, um es besser zu machen.</h4>
+        <div id="bigSocial">
+            <div>
+                <a href="https://twitter.com/kubernetesio">@kubernetesio</a>
+                <p>Erhalten Sie die neuesten Nachrichten und Updates.</p>
+            </div>
+            <div>
+                <a href="https://github.com/kubernetes/kubernetes">Github Project</a>
+                <p>Informieren Sie sich über das Projekt und erwägen Sie, einen Beitrag zu leisten.</p>
+            </div>
+            <div>
+                <a href="http://slack.k8s.io/">#kubernetes-users</a>
+                <p>Unser Slack-Kanal ist der beste Weg, um unsere Ingenieure zu kontaktieren und Ihre Ideen mit ihnen zu teilen.</p>
+            </div>
+            <div>
+                <a href="http://stackoverflow.com/questions/tagged/kubernetes">Stack Overflow</a>
+                <p>Unser Benutzerforum ist ein großartiger Ort, um Community-Support zu erhalten.</p>
+            </div>
+        </div>
+    </main>
+</section>

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

@@ -28,7 +28,7 @@ Die Add-Ons in den einzelnen Kategorien sind alphabetisch sortiert - Die Reihenf
 * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), basierend auf [Tungsten Fabric](https://tungsten.io), ist eine Open Source, multi-Cloud Netzwerkvirtualisierungs- und Policy-Management Plattform. Contrail und Tungsten Fabric sind mit Orechstratoren wie z.B. Kubernetes, OpenShift, OpenStack und Mesos integriert und bieten Isolationsmodi für Virtuelle Maschinen, Container (bzw. Pods) und Bare Metal workloads.
 * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) ist ein Overlay-Network-Provider der mit Kubernetes genutzt werden kann.
 * [Knitter](https://github.com/ZTE/Knitter/) ist eine Network-Lösung die Mehrfach-Network in Kubernetes ermöglicht.
-* Multus ist ein Multi-Plugin für Mehrfachnetzwerk-Unterstützung um alle CNI-Plugins (z.B. Calico, Cilium, Contiv, Flannel), zusätzlich zu SRIOV-, DPDK-, OVS-DPDK- und VPP-Basierten Workloads in Kubernetes zu unterstützen.
+* [Multus](https://github.com/Intel-Corp/multus-cni) ist ein Multi-Plugin für Mehrfachnetzwerk-Unterstützung um alle CNI-Plugins (z.B. Calico, Cilium, Contiv, Flannel), zusätzlich zu SRIOV-, DPDK-, OVS-DPDK- und VPP-Basierten Workloads in Kubernetes zu unterstützen.
 * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) bietet eine Integration zwischen VMware NSX-T und einem Orchestator wie z.B. Kubernetes. Außerdem bietet es eine Integration zwischen NSX-T und Containerbasierten CaaS/PaaS-Plattformen wie z.B. Pivotal Container Service (PKS) und OpenShift.
 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) ist eine SDN-Plattform die Policy-Basiertes Networking zwischen Kubernetes Pods und nicht-Kubernetes Umgebungen inklusive Sichtbarkeit und Security-Monitoring bereitstellt.
 * [Romana](http://romana.io) ist eine Layer 3 Network-Lösung für Pod-Netzwerke welche auch die [NetworkPolicy API](/docs/concepts/services-networking/network-policies/) unterstützt. Details zur Installation als kubeadm Add-On sind [hier](https://github.com/romana/romana/tree/master/containerize) verfügbar.

content/de/docs/tutorials/_index.md

@@ -50,8 +50,6 @@ Bevor Sie die einzelnen Lernprogramme durchgehen, möchten Sie möglicherweise e
 
 * [AppArmor](/docs/tutorials/clusters/apparmor/)
 
-* [seccomp](/docs/tutorials/clusters/seccomp/)
-
 ## Services
 
 * [Source IP verwenden](/docs/tutorials/services/source-ip/)

content/de/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html

@@ -5,7 +5,7 @@ weight: 20
 
 <!DOCTYPE html>
 
-<html lang="de">
+<html lang="en">
 
 <body>
 

content/de/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html

@@ -5,7 +5,7 @@ weight: 20
 
 <!DOCTYPE html>
 
-<html lang="de">
+<html lang="en">
 
 <body>
 

content/de/docs/tutorials/kubernetes-basics/explore/explore-intro.html

@@ -5,7 +5,7 @@ weight: 10
 
 <!DOCTYPE html>
 
-<html lang="de">
+<html lang="en">
 
 <body>
 

content/de/docs/tutorials/kubernetes-basics/expose/expose-interactive.html

@@ -5,7 +5,7 @@ weight: 20
 
 <!DOCTYPE html>
 
-<html lang="de">
+<html lang="en">
 
 <body>
 

content/de/docs/tutorials/kubernetes-basics/expose/expose-intro.html

@@ -5,7 +5,7 @@ weight: 10
 
 <!DOCTYPE html>
 
-<html lang="de">
+<html lang="en">
 
 <body>
 

content/de/docs/tutorials/kubernetes-basics/update/update-interactive.html

@@ -5,7 +5,7 @@ weight: 20
 
 <!DOCTYPE html>
 
-<html lang="de">
+<html lang="en">
 
 <body>
 

content/de/docs/tutorials/kubernetes-basics/update/update-intro.html

@@ -5,7 +5,7 @@ weight: 10
 
 <!DOCTYPE html>
 
-<html lang="de">
+<html lang="en">
 
 <body>
 

content/de/includes/partner-style.css

@@ -1,201 +0,0 @@
-/*  SECTIONS  */
-.section {
-	clear: both;
-	padding: 0px;
-	margin-bottom: 2em;
-}
-
-.kcsp_section {
-	clear: both;
-	padding: 0px;
-	margin-bottom: 2em;
-}
-
-/*  COLUMN SETUP  */
-.col {
-	display: block;
-	float:left;
-	margin: 1% 0 1% 1.6%;
-	background-color: #f9f9f9;
-}
-.col:first-child { margin-left: 0; }
-
-
-/*  GROUPING  */
-.group:before,
-.group:after {
-	content:"";
-	display:table;
-}
-.group:after {
-	clear:both;
-}
-.group {
-    zoom:1; /* For IE 6/7 */
-}
-
-/*  GRID OF THREE  */
-.span_3_of_3 {
-	width: 35%;
-	background-color: #f9f9f9;
-	padding: 20px;
-}
-.span_2_of_3 {
-	width: 35%;
-	background-color: #f9f9f9;
-	padding: 20px;
-}
-.span_1_of_3 {
-	width: 35%;
-	background-color: #f9f9f9;
-	padding: 20px;
-}
-
-.col-container {
-    display: table; /* Make the container element behave like a table */
-    width: 100%; /* Set full-width to expand the whole page */
-		padding-bottom: 30px;
-}
-
-.col-nav {
-    display: table-cell; /* Make elements inside the container behave like table cells */
-		width: 18%;
-		background-color: #f9f9f9;
-		padding: 20px;
-		border: 5px solid white;
-}
-
-/*  GO FULL WIDTH AT LESS THAN 480 PIXELS */
-
-@media only screen and (max-width: 480px) {
-	.col { margin: 1% 0 1% 0%;}
-	.span_3_of_3, .span_2_of_3, .span_1_of_3 { width: 100%; }
-}
-
-@media only screen and (max-width: 650px) {
-    .col-nav {
-        display: block;
-        width: 100%;
-    }
-}
-
-.button{
-  max-width: 100%;
-	box-sizing: border-box;
-	margin: 0;
-	display: inline-block;
-	border-radius: 6px;
-	padding: 0 20px;
-	line-height: 40px;
-	color: #ffffff;
-	font-size: 16px;
-	background-color: #3371e3;
-	text-decoration: none;
- }
-
-h5 {
-	font-size: 16px;
-	line-height: 1.5em;
-	margin-bottom: 2em;
-}
-
-#usersGrid a {
-	display: inline-block;
-	background-color: #f9f9f9;
-}
-
-#ktpContainer, #distContainer, #kcspContainer, #isvContainer, #servContainer {
-	position: relative;
-	width: 100%;
-	display: flex;
-	justify-content: space-between;
-	flex-wrap: wrap;
-}
-
-#isvContainer {
-	margin-bottom: 80px;
-}
-
-#kcspContainer {
-	margin-bottom: 80px;
-}
-
-#distContainer {
-	margin-bottom: 80px;
-}
-
-#ktpContainer {
-	margin-bottom: 80px;
-}
-
-.partner-box {
-	position: relative;
-	width: 47%;
-	max-width: 48%;
-	min-width: 48%;
-	margin-bottom: 20px;
-	padding: 20px;
-	flex: 1;
-	display: flex;
-	justify-content: left;
-	align-items: flex-start;
-}
-
-.partner-box img {
-	background-color: #f9f9f9;
-}
-
-.partner-box > div {
-	margin-left: 30px;
-}
-
-.partner-box a {
-	color: #3576E3;
-}
-
-@media screen and (max-width: 1024px) {
-	.partner-box {
-		flex-direction: column;
-		justify-content: flex-start;
-	}
-
-	.partner-box > div {
-		margin: 20px 0 0;
-	}
-}
-
-@media screen and (max-width: 568px) {
-	#ktpContainer, #distContainter, #kcspContainer, #isvContainer, #servContainer {
-		justify-content: center;
-	}
-
-	.partner-box {
-		flex-direction: column;
-		justify-content: flex-start;
-		width: 100%;
-		max-width: 100%;
-		min-width: 100%;
-	}
-
-	.partner-box > div {
-		margin: 20px 0 0;
-	}
-}
-
-@media screen and (max-width: 568px) {
-	#ktpContainer, #distContainer, #kcspContainer, #isvContainer, #servContainer {
-		justify-content: center;
-	}
-
-	.partner-box {
-		flex-direction: column;
-		justify-content: flex-start;
-		width: 100%;
-		max-width: 100%;
-		min-width: 100%;
-	}
-
-	.partner-box > div {
-		margin: 20px 0 0;
-	}
-}

content/de/partners/_index.html

@@ -1,53 +1,91 @@
 ---
 title: Partner
 bigheader: Kubernetes Partner
-abstract: Erweiterung des Kubernetes-Ökosystems.
+abstract: Entwicklung des Kubernetes-Ökosystems.
 class: gridPage
 cid: partners
 ---
 
 <section id="users">
-    <h5>Kubernetes arbeitet mit Partnern zusammen, um eine starke, lebendige Codebasis zu schaffen, die ein Spektrum von ergänzenden Plattformen unterstützt.</h5>
-    <div class="col-container">
-      <div class="col-nav">
-        <center>
-          <h5>
-            <b>Kubernetes-zertifizierte Service-Anbieter</b>
-          </h5>
-          <br>Geprüfte Dienstleister mit umfassender Erfahrung bei der erfolgreichen Einführung von Kubernetes in Unternehmen.
-          <br><br><br>
-          <button class="button landscape-trigger landscape-default" data-landscape-types="kubernetes-certified-service-provider" id="kcsp">KCSP Partner anzeigen</button>
-          <br><br>Interessiert daran, ein
-          <a href="https://www.cncf.io/certification/kcsp/">KCSP</a> zu werden?
-        </center>
-      </div>
-      <div class="col-nav">
-        <center>
-          <h5>
-            <b>Zertifizierte Kubernetes-Distributionen, gehostete Plattformen und Installationssysteme</b>
-          </h5>Die Softwarekonformität stellt sicher, dass die Kubernetes-Version eines jeden Anbieters die erforderlichen APIs unterstützt.
-          <br><br><br>
-          <button class="button landscape-trigger" data-landscape-types="certified-kubernetes-distribution,certified-kubernetes-hosted,certified-kubernetes-installer" id="conformance">Konforme Partner anzeigen</button>
-          <br><br>Interessiert daran,
-          <a href="https://www.cncf.io/certification/software-conformance/">Kubernetes Zertifiziert</a> zu werden?
-        </center>
-      </div>
-      <div class="col-nav">
-        <center>
-          <h5>
-            <b>Kubernetes Schulungspartner</b>
-          </h5>
-          <br>Geprüfte Schulungsanbieter mit umfassender Erfahrung in der Weiterbildung im Bereich Cloud Native Technology.
-          <br><br><br>
-          <button class="button landscape-trigger" data-landscape-types="kubernetes-training-partner" id="ktp">KTP Partner anzeigen</button>
-          <br><br>Interessiert daran, ein
-          <a href="https://www.cncf.io/certification/training/">KTP</a> zu werden?
-        </center>
-      </div>
+    <main>
+        <h5>Kubernetes arbeitet mit Partnern zusammen, um eine starke, dynamische Codebasis zu schaffen, die ein Spektrum von aufeinander abgestimmten Plattformen unterstützt.</h5>
+        <div class="col-container">
+          <div class="col-nav">
+            <center>
+              <h5>
+                <b>Kubernetes zertifizierte Service Provider</b>
+              </h5>
+              <br>Geprüfte Service Provider mit großer Erfahrung, die Unternehmen bei der erfolgreichen Einführung von Kubernetes unterstützen.
+              <br><br><br>
+              <button id="kcsp" class="button" onClick="updateSrc(this.id)">KCSP-Partner anzeigen</button>
+              <br><br>Interessiert daran, ein <a href="https://www.cncf.io/certification/kcsp/">KCSP</a> zu werden?
+            </center>
+          </div>
+          <div class="col-nav">
+            <center>
+              <h5>
+                <b>Kubernetes-Distributionen, gehostete Plattformen und zertifizierte Installateure</b>
+              </h5>Software-Konformität stellt sicher, dass die Kubernetes-Versionen aller Hersteller die erforderlichen APIs unterstützen.
+              <br><br><br>
+              <button id="conformance" class="button" onClick="updateSrc(this.id)">Zertifizierte Partner anzeigen</button>
+              <br><br>Interessiert daran, <a href="https://www.cncf.io/certification/software-conformance/">Kubernetes zertifiziert</a> zu werden?
+            </center>
+          </div>
+          <div class="col-nav">
+            <center>
+              <h5><b>Kubernetes Training Partner</b></h5>
+              <br>Geprüfte Schulungsanbieter, die über umfassende Erfahrung in Cloud Native Technologietrainings verfügen.
+              <br><br><br><br>
+              <button id="ktp" class="button" onClick="updateSrc(this.id)">KTP Partner anzeigen</button>
+              <br><br>Interessiert daran, ein <a href="https://www.cncf.io/certification/training/">KTP</a> zu werden?
+            </center>
+          </div>
+        </div>
+<script src="https://code.jquery.com/jquery-3.3.1.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>
+<script type="text/javascript">
+
+			var defaultLink = "https://landscape.cncf.io/category=kubernetes-certified-service-provider&format=card-mode&grouping=category&embed=yes";
+			var firstLink = "https://landscape.cncf.io/category=certified-kubernetes-distribution,certified-kubernetes-hosted,certified-kubernetes-installer&format=card-mode&grouping=category&embed=yes";
+      var secondLink = "https://landscape.cncf.io/category=kubernetes-training-partner&format=card-mode&grouping=category&embed=yes";
+
+      function updateSrc(buttonId) {
+      	if (buttonId == "kcsp") {
+        		$("#landscape").attr("src",defaultLink);
+            window.location.hash = "#kcsp";
+        }
+        if (buttonId == "conformance") {
+         		$("#landscape").attr("src",firstLink);
+            window.location.hash = "#conformance";
+        }
+        if (buttonId == "ktp") {
+        		$("#landscape").attr("src",secondLink);
+            window.location.hash = "#ktp";
+        }
+      }
+
+      // Automatically load the correct iframe based on the URL fragment
+      document.addEventListener('DOMContentLoaded', function() {
+        var showContent = "kcsp";
+        if (window.location.hash) {
+          console.log('hash is:', window.location.hash.substring(1));
+          showContent = window.location.hash.substring(1);
+        }
+        updateSrc(showContent);
+      });
+</script>
+<body>
+    <div id="frameHolder">
+      <iframe id="landscape" frameBorder="0" scrolling="no" style="width: 1px; min-width: 100%" src=""></iframe>
+      <script src="https://landscape.cncf.io/iframeResizer.js"></script>
     </div>
-    {{< cncf-landscape helpers=true >}}
+</body>
+    </main>
 </section>
 
 <style>
     {{< include "partner-style.css" >}}
-</style>
+</style>
+
+<script>
+    {{< include "partner-script.js" >}}
+</script>

content/de/training/_index.html

@@ -1,137 +0,0 @@
----
-title: Schulungen
-bigheader: Kubernetes Schulungen und Zertifizierungen
-abstract: Schulungsprogramme, Zertifizierungen und Partner.
-layout: basic
-cid: training
-class: training
----
-
-<section class="call-to-action">
-  <div class="main-section">
-    <div class="call-to-action" id="cta-certification">
-      <div class="cta-text">
-        <h2>Gestalte deine Cloud Native Karriere</h2>
-        <p>Kubernetes ist das Herzstück der Cloud Native-Bewegung. Mit den Schulungen und Zertifizierungen der Linux Foundation und unserer Schulungspartner kannst Du in deine Karriere investieren, Kubernetes lernen und deine Cloud Native-Projekte zum Erfolg führen.</p>
-      </div>
-      <div class="logo-certification cta-image" id="logo-kcnf">
-        <img src="/images/training/kubernetes-kcnf-white.svg" />
-      </div>
-      <div class="logo-certification cta-image" id="logo-cka">
-        <img src="/images/training/kubernetes-cka-white.svg"/>
-      </div>
-      <div class="logo-certification cta-image" id="logo-ckad">
-        <img src="/images/training/kubernetes-ckad-white.svg"/>
-      </div>
-      <div class="logo-certification cta-image" id="logo-cks">
-        <img src="/images/training/kubernetes-cks-white.svg"/>
-      </div>
-    </div>
-  </div>
-</section>
-
-<section>
-  <div class="main-section padded">
-    <center>
-      <h2>Nimm an einen kostenlosen Kurs bei edX teil</h2>
-    </center>
-  <div class="col-container">
-    <div class="col-nav">
-      <center>
-        <h5>
-          <b>Einf&uuml;hrung in Kubernetes <br> &nbsp;</b>
-        </h5>
-        <p>M&ouml;chtest Du Kubernetes lernen? Erfahre alles über dieses leistungsstarke System zur Verwaltung von Containeranwendungen.</p>
-        <br>
-        <a href="https://www.edx.org/course/introduction-to-kubernetes" target="_blank" class="button">Zum Kurs</a>
-      </center>
-    </div>
-    <div class="col-nav">
-      <center>
-        <h5>
-          <b>Einführung in Cloud-Infrastruktur Technologien</b>
-        </h5>
-        <p>Lerne die Grundlagen für den Aufbau und die Verwaltung von Cloud-Technologien direkt von der Linux Foundation, dem Marktführer im Bereich Open Source.</p>
-        <br>
-        <a href="https://www.edx.org/course/introduction-to-cloud-infrastructure-technologies" target="_blank" class="button">Zum Kurs</a>
-      </center>
-    </div>
-    <div class="col-nav">
-      <center>
-        <h5>
-          <b>Einf&uuml;hrung in Linux</b>
-        </h5>
-        <p>Du hast nie Linux gelernt? Willst du eine Auffrischung? Erarbeite dir gute Linux-Kenntnisse über die grafische Oberfläche und die Kommandozeile der wichtigsten Linux-Distributionen.</p>
-        <br>
-        <a href="https://www.edx.org/course/introduction-to-linux" target="_blank" class="button">Zum Kurs</a>
-      </center>
-    </div>
-  </div>
-</section>
-
-<div class="padded lighter-gray-bg">
-  <div class="main-section two-thirds-centered">
-    <center>
-      <h2>Mit der Linux Foundation lernen</h2>
-      <p>Die Linux Foundation bietet Kurse für alle Aspekte der Entwicklung und des Betriebs von Kubernetes-Anwendungen an, die entweder von Lehrkräften geleitet werden oder zum Selbststudium geeignet sind.</p>
-      <br/><br/>
-      <a href="https://training.linuxfoundation.org/training/course-catalog/?_sft_technology=kubernetes" target="_blank" class="button">Kurse anzeigen</a>
-    </center>
-  </div>
-</div>
-
-<section id="get-certified">
-  <div class="main-section padded">
-    <h2>Werde Kubernetes zertifiziert</h2>
-    <div class="col-container">
-      <div class="col-nav">
-        <h5>
-          <b>Kubernetes and Cloud Native Associate (KCNA)</b>
-        </h5>
-        <p>Die Prüfung zum Kubernetes and Cloud Native Associate (KCNA) weist die grundlegenden Kenntnisse und Fähigkeiten eines Benutzers in Kubernetes und dem breiteren Cloud Native-Ökosystem nach.</p>
-        <p>Ein zertifizierter KCNA bestätigt konzeptionelles Wissen über das gesamte Cloud Native Ecosystem, mit besonderem Fokus auf Kubernetes.</p>
-        <br>
-        <a href="https://training.linuxfoundation.org/certification/kubernetes-cloud-native-associate/" target="_blank" class="button">Zur Zertifizierung</a>
-      </div>
-      <div class="col-nav">
-          <h5>
-            <b>Certified Kubernetes Application Developer (CKAD)</b>
-          </h5>
-          <p>Die Prüfung zum Certified Kubernetes Application Developer (Zertifizierter Kubernetes-Anwendungsentwickler) bescheinigt, dass Teilnehmer Cloud Native-Anwendungen für Kubernetes entwerfen, erstellen, konfigurieren und bereitstellen können.</p>
-          <p>Ein CKAD kann Anwendungsressourcen definieren und zentrale Elemente verwenden, um skalierbare Anwendungen und Tools in Kubernetes zu erstellen, zu überwachen und Fehler zu beheben.</p>
-          <br>
-          <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-application-developer-ckad/" target="_blank" class="button">Zur Zertifizierung</a>
-      </div>
-      <div class="col-nav">
-          <h5>
-            <b>Certified Kubernetes Administrator (CKA)</b>
-          </h5>
-          <p>Das Certified Kubernetes Administrator (CKA)-Programm garantiert, dass CKAs die Fähigkeiten, das Wissen und die Kompetenz besitzen, um die Aufgaben eines Kubernetes-Administrators zu erfüllen.</p>
-          <p>Ein zertifizierter Kubernetes-Administrator hat nachgewiesen, dass er in der Lage ist, grundlegende Installationen durchzuführen sowie Kubernetes-Cluster in einer Produktionsumgebung zu konfigurieren und zu verwalten.</p>
-          <br>
-          <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/" target="_blank" class="button">Zur Zertifizierung</a>
-      </div>
-      <div class="col-nav">
-          <h5>
-            <b>Certified Kubernetes Security Specialist (CKS)</b>
-          </h5>
-          <p>Das Programm Certified Kubernetes Security Specialist (CKS) bietet die Gewissheit, dass der Zertifikatsinhaber mit einem breiten Spektrum an Best Practices vertraut ist und diese beherrscht. Die CKS-Zertifizierung umfasst Fähigkeiten zur Sicherung von Container-basierten Anwendungen und Kubernetes-Plattformen während der Erstellung, Bereitstellung und Laufzeit.</p>
-          <p><em>Kandidaten für den CKS müssen über eine aktuelle Zertifizierung als Certified Kubernetes Administrator (CKA) verfügen, um nachzuweisen, dass sie über ausreichende Kubernetes-Kenntnisse verfügen, bevor sie sich für den CKS anmelden.</em></p>
-          <br>
-          <a href="https://training.linuxfoundation.org/certification/certified-kubernetes-security-specialist/" target="_blank" class="button">Zur Zertifizierung</a>
-      </div>
-    </div>
-  </div>
-</section>
-
-<div class="padded lighter-gray-bg">
-  <div class="main-section two-thirds-centered">
-    <center>
-      <h2>Kubernetes Schulungspartner</h2>
-      <p>Unser Netzwerk von Kubernetes-Schulungspartnern bietet Schulungsangebote für Kubernetes- und Cloud Native-Projekte.</p>
-    </center>
-  </div>
-  <div class="main-section landscape-section">
-    {{< cncf-landscape helpers=false category="kubernetes-training-partner" >}}
-  </div>
-</div>

content/en/_index.html

@@ -43,12 +43,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
         <button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
         <br>
         <br>
+        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Attend KubeCon North America on October 11-15, 2021</a>
+        <br>
+        <br>
+        <br>
+        <br>
         <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Attend KubeCon Europe on May 17-20, 2022</a>
-        <br>
-        <br>
-        <br>
-        <br>
-        <a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna22" button id="desktopKCButton">Attend KubeCon North America on October 24-28, 2022</a>
 </div>
 <div id="videoPlayer">
     <iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>

content/en/blog/_posts/2016-08-00-Kubernetes-Namespaces-Use-Cases-Insights.md

@@ -125,7 +125,7 @@ You may wish to, but you cannot create a hierarchy of namespaces. Namespaces can
 
 
 
-Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-). 
+Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/user-guide/kubectl/kubectl_config_set-context/). 
 
 
 

content/en/blog/_posts/2016-11-00-Visualize-Kubelet-Performance-With-Node-Dashboard.md

@@ -5,11 +5,6 @@ slug: visualize-kubelet-performance-with-node-dashboard
 url: /blog/2016/11/Visualize-Kubelet-Performance-With-Node-Dashboard
 ---
 
-_Since this article was published, the Node Performance Dashboard was retired and is no longer available._
-
-_This retirement happened in early 2019, as part of the_ `kubernetes/contrib`
-_[repository deprecation](https://github.com/kubernetes-retired/contrib/issues/3007)_.
-
 In Kubernetes 1.4, we introduced a new node performance analysis tool, called the _node performance dashboard_, to visualize and explore the behavior of the Kubelet in much richer details. This new feature will make it easy to understand and improve code performance for Kubelet developers, and lets cluster maintainer set configuration according to provided Service Level Objectives (SLOs).  
 
 **Background**  

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

@@ -37,7 +37,7 @@ If you run your storage application on high-end hardware or extra-large instance
 [ZooKeeper](https://zookeeper.apache.org/doc/current/) is an interesting use case for StatefulSet for two reasons. First, it demonstrates that StatefulSet can be used to run a distributed, strongly consistent storage application on Kubernetes. Second, it's a prerequisite for running workloads like [Apache Hadoop](http://hadoop.apache.org/) and [Apache Kakfa](https://kafka.apache.org/) on Kubernetes. An [in-depth tutorial](/docs/tutorials/stateful-application/zookeeper/) on deploying a ZooKeeper ensemble on Kubernetes is available in the Kubernetes documentation, and we’ll outline a few of the key features below.  
 
 **Creating a ZooKeeper Ensemble**  
-Creating an ensemble is as simple as using [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create) to generate the objects stored in the manifest.  
+Creating an ensemble is as simple as using [kubectl create](/docs/user-guide/kubectl/kubectl_create/) to generate the objects stored in the manifest.  
 
 
 ```
@@ -297,7 +297,7 @@ zk-0      0/1       Terminating   0         15m
 
 
 
-You can use [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) to recreate the zk StatefulSet and redeploy the ensemble.
+You can use [kubectl apply](/docs/user-guide/kubectl/kubectl_apply/) to recreate the zk StatefulSet and redeploy the ensemble.
 
 
 

content/en/blog/_posts/2018-10-01-health-checking-grpc.md

@@ -6,10 +6,6 @@ date: 2018-10-01
 
 **Author**: [Ahmet Alp Balkan](https://twitter.com/ahmetb) (Google)
 
-**Update (December 2021):** _Kubernetes now has built-in gRPC health probes starting in v1.23.
-To learn more, see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe).
-This article was originally written about an external tool to achieve the same task._
-
 [gRPC](https://grpc.io) is on its way to becoming the lingua franca for
 communication between cloud-native microservices. If you are deploying gRPC
 applications to Kubernetes today, you may be wondering about the best way to

content/en/blog/_posts/2019-03-29-kube-proxy-subtleties-debugging-an-intermittent-connection-resets.md

@@ -144,9 +144,10 @@ ways to address it.
 - Specifically add an iptables rule to drop the packets that are marked as
   *INVALID*, so it won’t reach to client pod and cause harm.
 
-The [fix](https://github.com/kubernetes/kubernetes/pull/74840) is available in v1.15+.
-However, for the users that are affected by this bug, there is a way to mitigate the
-problem by applying the following rule in your cluster.
+The fix is drafted (https://github.com/kubernetes/kubernetes/pull/74840), but
+unfortunately it didn’t catch the v1.14 release window. However, for the users
+that are affected by this bug, there is a way to mitigate the problem by applying
+the following rule in your cluster.
 
 ```yaml
 apiVersion: extensions/v1beta1

content/en/blog/_posts/2020-10-12-steering-committee-results.md

@@ -29,7 +29,7 @@ They join continuing members Christoph Blecker ([@cblecker](https://github.com/c
   * Josh Berkus ([@jberkus](https://github.com/jberkus)), Red Hat
 * Thanks to the Emeritus Steering Committee Members. Your prior service is appreciated by the community:
   * Aaron Crickenberger ([@spiffxp](https://github.com/spiffxp)), Google
-  * and Lachlan Evenson([@lachie83)](https://github.com/lachie83)), Microsoft
+  * and Lachlan Evenson([@lachie8e)](https://github.com/lachie8e)), Microsoft
 * And thank you to all the candidates who came forward to run for election. As [Jorge Castro put it](https://twitter.com/castrojo/status/1315718627639820288?s=20): we are spoiled with capable, kind, and selfless volunteers who put the needs of the project first.
 
 ## Get Involved with the Steering Committee

content/en/blog/_posts/2020-12-02-dockershim-faq.md

@@ -12,8 +12,6 @@ on the deprecation of Docker as a container runtime for Kubernetes kubelets, and
 what that means, check out the blog post
 [Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/).
 
-Also, you can read [check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) to check whether it does.
-
 ### Why is dockershim being deprecated?
 
 Maintaining dockershim has become a heavy burden on the Kubernetes maintainers.
@@ -30,7 +28,7 @@ as cgroups v2 and user namespaces are being implemented in these newer CRI
 runtimes. Removing support for the dockershim will allow further development in
 those areas.
 
-[drkep]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim
+[drkep]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim
 
 ### Can I still use Docker in Kubernetes 1.20?
 
@@ -44,11 +42,9 @@ startup if using Docker as the runtime.
 
 Given the impact of this change, we are using an extended deprecation timeline.
 It will not be removed before Kubernetes 1.22, meaning the earliest release without
-dockershim would be 1.23 in late 2021. 
-_Update_: removal of dockershim is scheduled for Kubernetes v1.24, see 
-[Dockershim Removal Kubernetes Enhancement Proposal][drkep].
-We will be working closely with vendors and other ecosystem groups to ensure a smooth transition and will evaluate 
-things as the situation evolves.
+dockershim would be 1.23 in late 2021. We will be working closely with vendors
+and other ecosystem groups to ensure a smooth transition and will evaluate things
+as the situation evolves.
 
 
 ### Can I still use dockershim after it is removed from Kubernetes?

content/en/blog/_posts/2021-05-14-using-finalizers-to-control-deletion.md

@@ -190,10 +190,9 @@ kubectl get configmap
 No resources found in default namespace.
 ```
 
-To sum things up, when there's an override owner reference from a child to a parent, deleting the parent deletes the children automatically. This is called `cascade`. The default for cascade is `true`, however, you can use the --cascade=orphan option for `kubectl delete` to delete an object and orphan its children.  *Update: starting with kubectl v1.20, the default for cascade is `background`.*
+To sum things up, when there's an override owner reference from a child to a parent, deleting the parent deletes the children automatically. This is called `cascade`. The default for cascade is `true`, however, you can use the --cascade=false option for `kubectl delete` to delete an object and orphan its children. 
 
-
-In the following example, there is a parent and a child. Notice the owner references are still included. If I delete the parent using --cascade=orphan, the parent is deleted but the child still exists:
+In the following example, there is a parent and a child. Notice the owner references are still included. If I delete the parent using --cascade=false, the parent is deleted but the child still exists:
 
 ```
 kubectl get configmap
@@ -201,7 +200,7 @@ NAME           DATA   AGE
 mymap-child    0      13m8s
 mymap-parent   0      13m8s
 
-kubectl delete --cascade=orphan configmap/mymap-parent
+kubectl delete --cascade=false configmap/mymap-parent
 configmap "mymap-parent" deleted
 
 kubectl get configmap

content/en/blog/_posts/2021-07-14-upcoming-changes-in-kubernetes-1-22/index.md

@@ -19,9 +19,8 @@ is that they have been superseded by a newer, stable (“GA”) API.
 
 Kubernetes 1.22, due for release in August 2021, will remove a number of deprecated
 APIs.
-_Update_:
-[Kubernetes 1.22: Reaching New Peaks](/blog/2021/08/04/kubernetes-1-22-release-announcement/)
-has details on the v1.22 release.
+[Kubernetes 1.22 Release Information](https://www.kubernetes.dev/resources/release/)
+has details on the schedule for the v1.22 release.
 
 ## API removals for Kubernetes v1.22 {#api-changes}
 

content/en/blog/_posts/2021-08-04-kubernetes-release-1.22.md

@@ -1,157 +0,0 @@
----
-layout: blog
-title: 'Kubernetes 1.22: Reaching New Peaks'
-date: 2021-08-04
-slug: kubernetes-1-22-release-announcement
----
-
-**Authors:** [Kubernetes 1.22 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.22/release-team.md)
-
-We’re pleased to announce the release of Kubernetes 1.22, the second release of 2021!
-
-This release consists of 53 enhancements: 13 enhancements have graduated to stable, 24 enhancements are moving to beta, and 16 enhancements are entering alpha. Also, three features have been deprecated.
-
-In April of this year, the Kubernetes release cadence was officially changed from four to three releases yearly. This is the first longer-cycle release related to that change. As the Kubernetes project matures, the number of enhancements per cycle grows. This means more work, from version to version, for the contributor community and Release Engineering team, and it can put pressure on the end-user community to stay up-to-date with releases containing increasingly more features.
-
-Changing the release cadence from four to three releases yearly balances many aspects of the project, both in how contributions and releases are managed, and also in the community's ability to plan for upgrades and stay up to date.
-
-You can read more in the official blog post [Kubernetes Release Cadence Change: Here’s What You Need To Know](https://kubernetes.io/blog/2021/07/20/new-kubernetes-release-cadence/).
-
-
-## Major Themes
-
-### Server-side Apply graduates to GA
-
-[Server-side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) is a new field ownership and object merge algorithm running on the Kubernetes API server. Server-side Apply helps users and controllers manage their resources via declarative configurations. It allows them to create and/or modify their objects declaratively, simply by sending their fully specified intent. After being in beta for a couple releases, Server-side Apply is now generally available.
-
-### External credential providers now stable
-
-Support for Kubernetes client [credential plugins](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins) has been in beta since 1.11, and with the release of Kubernetes 1.22 now graduates to stable. The GA feature set includes improved support for plugins that provide interactive login flows, as well as a number of bug fixes. Aspiring plugin authors can look at [sample-exec-plugin](https://github.com/ankeesler/sample-exec-plugin) to get started.
-
-### etcd moves to 3.5.0
-
-Kubernetes' default backend storage, etcd, has a new release: 3.5.0. The new release comes with improvements to the security, performance, monitoring, and developer experience. There are numerous bug fixes and some critical new features like the migration to structured logging and built-in log rotation. The release comes with a detailed future roadmap to implement a solution to traffic overload. You can read a full and detailed list of changes in the [3.5.0 release announcement](https://etcd.io/blog/2021/announcing-etcd-3.5/).
-
-### Quality of Service for memory resources
-
-Originally, Kubernetes used the v1 cgroups API. With that design, the QoS class for a `Pod` only applied to CPU resources (such as `cpu_shares`). As an alpha feature, Kubernetes v1.22 can now use the cgroups v2 API to control memory allocation and isolation. This feature is designed to improve workload and node availability when there is contention for memory resources, and to improve the predictability of container lifecycle.
-
-### Node system swap support
-
-Every system administrator or Kubernetes user has been in the same boat regarding setting up and using Kubernetes: disable swap space. With the release of Kubernetes 1.22, alpha support is available to run nodes with swap memory. This change lets administrators opt in to configuring swap on Linux nodes, treating a portion of block storage as additional virtual memory.
-
-### Windows enhancements and capabilities
-
-Continuing to support the growing developer community, SIG Windows has released their [Development Environment](https://github.com/kubernetes-sigs/sig-windows-dev-tools/). These new tools support multiple CNI providers and can run on multiple platforms. There is also a new way to run bleeding-edge Windows features from scratch by compiling the Windows kubelet and kube-proxy, then using them along with daily builds of other Kubernetes components.
-
-CSI support for Windows nodes moves to GA in the 1.22 release. In Kubernetes v1.22, Windows privileged containers are an alpha feature. To allow using CSI storage on Windows nodes, [CSIProxy](https://github.com/kubernetes-csi/csi-proxy) enables CSI node plugins to be deployed as unprivileged pods, using the proxy to perform privileged storage operations on the node.
-
-### Default profiles for seccomp
-
-An alpha feature for default seccomp profiles has been added to the kubelet, along with a new command line flag and configuration. When in use, this new feature provides cluster-wide seccomp defaults, using the `RuntimeDefault` seccomp profile rather than `Unconfined` by default. This enhances the default security of the Kubernetes Deployment. Security administrators will now sleep better knowing that workloads are more secure by default. To learn more about the feature, please refer to the official [seccomp tutorial](https://kubernetes.io/docs/tutorials/clusters/seccomp/#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads).
-
-### More secure control plane with kubeadm
-
-A new alpha feature allows running the `kubeadm` control plane components as non-root users. This is a long requested security measure in `kubeadm`. To try it you must enable the `kubeadm` specific RootlessControlPlane feature gate. When you deploy a cluster using this alpha feature, your control plane runs with lower privileges.
-
-For `kubeadm`, Kubernetes 1.22 also brings a new [v1beta3 configuration API](/docs/reference/config-api/kubeadm-config.v1beta3/). This iteration adds some long requested features and deprecates some existing ones. The v1beta3 version is now the preferred API version; the v1beta2 API also remains available and is not yet deprecated.
-
-## Major Changes
-
-### Removal of several deprecated beta APIs
-
-A number of deprecated beta APIs have been removed in 1.22 in favor of the GA version of those same APIs. All existing objects can be interacted with via stable APIs. This removal includes beta versions of the `Ingress`, `IngressClass`, `Lease`, `APIService`, `ValidatingWebhookConfiguration`, `MutatingWebhookConfiguration`, `CustomResourceDefinition`, `TokenReview`, `SubjectAccessReview`, and `CertificateSigningRequest` APIs.
-
-For the full list, check out the [Deprecated API Migration Guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22) as well as the blog post [Kubernetes API and Feature Removals In 1.22: Here’s What You Need To Know](https://blog.k8s.io/2021/07/14/upcoming-changes-in-kubernetes-1-22/). 
-
-###  API changes and improvements for ephemeral containers
-
-The API used to create [Ephemeral Containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/) changes in 1.22. The Ephemeral Containers feature is alpha and disabled by default, and the new API does not work with clients that attempt to use the old API.
-
-For stable features, the kubectl tool follows the Kubernetes [version skew policy](https://kubernetes.io/releases/version-skew-policy/); however, kubectl v1.21 and older do not support the new API for ephemeral containers. If you plan to use `kubectl debug` to create ephemeral containers, and your cluster is running Kubernetes v1.22, you cannot do so with kubectl v1.21 or earlier. Please update kubectl to 1.22 if you wish to use `kubectl debug` with a mix of cluster versions.
-
-## Other Updates
-
-### Graduated to Stable
-
-* [Bound Service Account Token Volumes](https://github.com/kubernetes/enhancements/issues/542)
-* [CSI Service Account Token](https://github.com/kubernetes/enhancements/issues/2047)
-* [Windows Support for CSI Plugins](https://github.com/kubernetes/enhancements/issues/1122)
-* [Warning mechanism for deprecated API use](https://github.com/kubernetes/enhancements/issues/1693)
-* [PodDisruptionBudget Eviction](https://github.com/kubernetes/enhancements/issues/85)
-
-### Notable Feature Updates
-
-* A new [PodSecurity admission](https://github.com/kubernetes/enhancements/issues/2579) alpha feature is introduced, intended as a replacement for PodSecurityPolicy
-* [The Memory Manager](https://github.com/kubernetes/enhancements/issues/1769) moves to beta
-* A new alpha feature to enable [API Server Tracing](https://github.com/kubernetes/enhancements/issues/647)
-* A new v1beta3 version of the [kubeadm configuration](https://github.com/kubernetes/enhancements/issues/970) format
-* [Generic data populators](https://github.com/kubernetes/enhancements/issues/1495) for PersistentVolumes are now available in alpha
-* The Kubernetes control plane will now always use the [CronJobs v2 controller](https://github.com/kubernetes/enhancements/issues/19)
-* As an alpha feature, all Kubernetes node components (including the kubelet, kube-proxy, and container runtime) can be [run as a non-root user](https://github.com/kubernetes/enhancements/issues/2033)
-
-# Release notes
-
-You can check out the full details of the 1.22 release in the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md).
-
-# Availability of release
-
-Kubernetes 1.22 is [available for download](https://kubernetes.io/releases/download/) and also [on the GitHub project](https://github.com/kubernetes/kubernetes/releases/tag/v1.22.0). 
-
-There are some great resources out there for getting started with Kubernetes. You can check out some [interactive tutorials](https://kubernetes.io/docs/tutorials/) on the main Kubernetes site, or run a local cluster on your machine using Docker containers with [kind](https://kind.sigs.k8s.io). If you’d like to try building a cluster from scratch, check out the [Kubernetes the Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way) tutorial by Kelsey Hightower.
-
-# Release Team
-
-This release was made possible by a very dedicated group of individuals, who came together as a team to deliver technical content, documentation, code, and a host of other components that go into every Kubernetes release.
-
-A huge thank you to the release lead Savitha Raghunathan for leading us through a successful release cycle, and to everyone else on the release team for supporting each other, and working so hard to deliver the 1.22 release for the community.
-
-We would also like to take this opportunity to remember Peeyush Gupta, a member of our team that we lost earlier this year. Peeyush was actively involved in SIG ContribEx and the Kubernetes Release Team, most recently serving as the 1.22 Communications lead. His contributions and efforts will continue to reflect in the community he helped build. A [CNCF memorial](https://github.com/cncf/memorials/blob/main/peeyush-gupta.md) page has been created where thoughts and memories can be shared by the community.
-
-# Release Logo
-
-![Kubernetes 1.22 Release Logo](/images/blog/2021-08-04-kubernetes-release-1.22/kubernetes-1.22.png)
-
-Amidst the ongoing pandemic, natural disasters, and ever-present shadow of burnout, the 1.22 release of Kubernetes includes 53 enhancements. This makes it the largest release to date. This accomplishment was only made possible due to the hard-working and passionate Release Team members and the amazing contributors of the Kubernetes ecosystem. The release logo is our reminder to keep reaching for new milestones and setting new records. And it is dedicated to all the Release Team members, hikers, and stargazers!
-
-The logo is designed by [Boris Zotkin](https://www.instagram.com/boris.z.man/). Boris is a Mac/Linux Administrator at the MathWorks. He enjoys simple things in life and loves spending time with his family. This tech-savvy individual is always up for a challenge and happy to help a friend!
-
-# User Highlights
-
-- In May, the CNCF welcomed 27 new organizations across the globe as members of the diverse cloud native ecosystem. These new [members](https://www.cncf.io/announcements/2021/05/05/27-new-members-join-the-cloud-native-computing-foundation/) will participate in CNCF events, including the upcoming [KubeCon + CloudNativeCon NA in Los Angeles](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/) from October 12 – 15, 2021.
-- The CNCF granted Spotify the [Top End User Award](https://www.cncf.io/announcements/2021/05/05/cloud-native-computing-foundation-grants-spotify-the-top-end-user-award/) during [KubeCon + CloudNativeCon EU – Virtual 2021](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/).
-
-# Project Velocity
-
-The [CNCF K8s DevStats project](https://k8s.devstats.cncf.io/) aggregates a number of interesting data points related to the velocity of Kubernetes and various sub-projects. This includes everything from individual contributions to the number of companies that are contributing, and is an illustration of the depth and breadth of effort that goes into evolving this ecosystem.
-
-In the v1.22 release cycle, which ran for 15 weeks (April 26 to August 4), we saw contributions from [1063 companies](https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1&var-period_name=v1.21.0%20-%20now&var-metric=contributions) and [2054 individuals](https://k8s.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=v1.21.0%20-%20now&var-metric=contributions&var-repogroup_name=Kubernetes&var-country_name=All&var-companies=All).
-
-# Ecosystem Updates
-
-- [KubeCon + CloudNativeCon Europe 2021](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) was held in May, the third such event to be virtual. All talks are [now available on-demand](https://www.youtube.com/playlist?list=PLj6h78yzYM2MqBm19mRz9SYLsw4kfQBrC) for anyone that would like to catch up!
-- [Spring Term LFX Program](https://www.cncf.io/blog/2021/07/13/spring-term-lfx-program-largest-graduating-class-with-28-successful-cncf-interns) had the largest graduating class with 28 successful CNCF interns!
-- CNCF launched [livestreaming on Twitch](https://www.cncf.io/blog/2021/06/03/cloud-native-community-goes-live-with-10-shows-on-twitch/) at the beginning of the year targeting definitive interactive media experience for anyone wanting to learn, grow, and collaborate with others in the Cloud Native community from anywhere in the world.
-
-# Event Updates
-
-- [KubeCon + CloudNativeCon North America 2021](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/) will take place in Los Angeles, October 12 – 15, 2021! You can find more information about the conference and registration on the event site.
-- [Kubernetes Community Days](https://community.cncf.io/kubernetes-community-days/about-kcd/) has upcoming events scheduled in Italy, the UK, and in Washington DC.
-
-# Upcoming release webinar
-
-Join members of the Kubernetes 1.22 release team on October 5, 2021 to learn about the major features of this release, as well as deprecations and removals to help plan for upgrades. For more information and registration, visit the [event page](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kubernetes-122-release/) on the CNCF Online Programs site.
-
-# Get Involved
-
-If you’re interested in contributing to the Kubernetes community, Special Interest Groups (SIGs) are a great starting point. Many of them may align with your interests! If there are things you’d like to share with the community, you can join the weekly community meeting, or use any of the following channels:
-
-* Find out more about contributing to Kubernetes at the [Kubernetes Contributors](https://www.kubernetes.dev/) website.
-* Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
-* Join the community discussion on [Discuss](https://discuss.kubernetes.io/)
-* Join the community on [Slack](http://slack.k8s.io/)
-* Share your Kubernetes [story](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
-* Read more about what’s happening with Kubernetes on the [blog](https://kubernetes.io/blog/)
-* Learn more about the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team)
-
-

content/en/blog/_posts/2021-08-06-server-side-apply-ga.md

@@ -1,177 +0,0 @@
----
-layout: blog
-title: "Kubernetes 1.22: Server Side Apply moves to GA"
-date: 2021-08-06
-slug: server-side-apply-ga
----
-
-**Authors:** Jeffrey Ying, Google & Joe Betz, Google
-
-Server-side Apply (SSA) has been promoted to GA in the Kubernetes v1.22 release. The GA milestone means you can depend on the feature and its API, without fear of future backwards-incompatible changes. GA features are protected by the Kubernetes [deprecation policy](/docs/reference/using-api/deprecation-policy/).
-
-## What is Server-side Apply?
-
-Server-side Apply helps users and controllers manage their resources through declarative configurations. Server-side Apply replaces the client side apply feature implemented by “kubectl apply” with a server-side implementation, permitting use by tools/clients other than kubectl. Server-side Apply is a new merging algorithm, as well as tracking of field ownership, running on the Kubernetes api-server. Server-side Apply enables new features like conflict detection, so the system knows when two actors are trying to edit the same field. Refer to the [Server-side Apply Documentation](/docs/reference/using-api/server-side-apply/) and [Beta 2 release announcement](https://kubernetes.io/blog/2020/04/01/kubernetes-1.18-feature-server-side-apply-beta-2/) for more information.
-
-## What’s new since Beta?
-
-Since the [Beta 2 release](https://kubernetes.io/blog/2020/04/01/kubernetes-1.18-feature-server-side-apply-beta-2/) subresources support has been added, and both client-go and Kubebuilder have added comprehensive support for Server-side Apply. This completes the Server-side Apply functionality required to make controller development practical.
-
-### Support for subresources
-
-Server-side Apply now fully supports subresources like `status` and `scale`. This is particularly important for [controllers](/docs/concepts/architecture/controller/), which are often responsible for writing to subresources.
-
-## Server-side Apply support in client-go
-
-Previously, Server-side Apply could only be called from the client-go typed client using the `Patch` function, with `PatchType` set to `ApplyPatchType`.  Now, `Apply` functions are included in the client to allow for a more direct and typesafe way of calling Server-side Apply. Each `Apply` function takes an "apply configuration" type as an argument, which is a structured representation of an Apply request. For example:
-
-```go
-import (
-         ...
-         v1ac "k8s.io/client-go/applyconfigurations/autoscaling/v1"
-)
-
-hpaApplyConfig := v1ac.HorizontalPodAutoscaler(autoscalerName, ns).
-         WithSpec(v1ac.HorizontalPodAutoscalerSpec().
-                  WithMinReplicas(0)
-         )
-
-return hpav1client.Apply(ctx, hpaApplyConfig, metav1.ApplyOptions{FieldManager: "mycontroller", Force: true})
-```
-
-Note in this example that `HorizontalPodAutoscaler` is imported from an "applyconfigurations" package. Each "apply configuration" type represents the same Kubernetes object kind as the corresponding go struct, but where all fields are pointers to make them optional, allowing apply requests to be accurately represented. For example, when the apply configuration in the above example is marshalled to YAML, it produces:
-
-```yaml
-apiVersion: autoscaling/v1
-kind: HorizontalPodAutoscaler
-metadata:
-    name: myHPA
-    namespace: myNamespace
-spec:
-    minReplicas: 0
-```
-
-To understand why this is needed, the above YAML cannot be produced by the v1.HorizontalPodAutoscaler go struct. Take for example:
-
-```go
-hpa := v1.HorizontalPodAutoscaler{
-         TypeMeta: metav1.TypeMeta{
-                  APIVersion: "autoscaling/v1",
-                  Kind:       "HorizontalPodAutoscaler",
-         },
-         ObjectMeta: ObjectMeta{
-                  Namespace: ns,
-                  Name:      autoscalerName,
-         },
-         Spec: v1.HorizontalPodAutoscalerSpec{
-                  MinReplicas: pointer.Int32Ptr(0),
-         },
-}
-```
-
-The above code attempts to declare the same apply configuration as shown in the previous examples, but when marshalled to YAML, produces:
-
-```yaml
-kind: HorizontalPodAutoscaler
-apiVersion: autoscaling/v1
-metadata
-  name: myHPA
-  namespace: myNamespace
-  creationTimestamp: null
-spec:
-  scaleTargetRef:
-    kind: ""
-    name: ""
-  minReplicas: 0
-  maxReplicas: 0
-```
-
-Which, among other things, contains `spec.maxReplicas` set to `0`. This is almost certainly not what the caller intended (the intended apply configuration says nothing about the `maxReplicas` field), and could have serious consequences on a production system: it directs the autoscaler to downscale to zero pods. The problem here originates from the fact that the go structs contain required fields that are zero valued if not set explicitly. The go structs work as intended for create and update operations, but are fundamentally incompatible with apply, which is why we have introduced the generated "apply configuration" types.
-
-The "apply configurations" also have convenience `With<FieldName>` functions that make it easier to build apply requests. This allows developers to set fields without having to deal with the fact that all the fields in the "apply configuration" types are pointers, and are inconvenient to set using go. For example `MinReplicas: &0` is not legal go code, so without the `With` functions, developers would work around this problem by using a library, e.g. `MinReplicas: pointer.Int32Ptr(0)`, but string enumerations like `corev1.Protocol` are still a problem since they cannot be supported by a general purpose library. In addition to the convenience, the `With` functions also isolate developers from the underlying representation, which makes it safer for the underlying representation to be changed to support additional features in the future.
-
-## Using Server-side Apply in a controller
-
-You can use the new support for Server-side Apply no matter how you implemented your controller. However, the new client-go support makes it easier to use Server-side Apply in controllers.
-
-When authoring new controllers to use Server-side Apply, a good approach is to have the controller recreate the apply configuration for an object each time it reconciles that object.  This ensures that the controller fully reconciles all the fields that it is responsible for. Controllers typically should unconditionally set all the fields they own by setting `Force: true` in the `ApplyOptions`. Controllers must also provide a `FieldManager` name that is unique to the reconciliation loop that apply is called from.
-
-When upgrading existing controllers to use Server-side Apply the same approach often works well--migrate the controllers to recreate the apply configuration each time it reconciles any object. Unfortunately, the controller might have multiple code paths that update different parts of an object depending on various conditions. Migrating a controller like this to Server-side Apply can be risky because if the controller forgets to include any fields in an apply configuration that is included in a previous apply request, a field can be accidently deleted. To ease this type of migration, client-go apply support provides a way to replace any controller reconciliation code that performs a "read/modify-in-place/update" (or patch) workflow with a "extract/modify-in-place/apply" workflow. Here's an example of the new workflow:
-
-```go
-fieldMgr := "my-field-manager"
-deploymentClient := clientset.AppsV1().Deployments("default")
-
-// read, could also be read from a shared informer
-deployment, err := deploymentClient.Get(ctx, "example-deployment", metav1.GetOptions{})
-if err != nil {
-  // handle error
-}
-
-// extract
-deploymentApplyConfig, err := appsv1ac.ExtractDeployment(deployment, fieldMgr)
-if err != nil {
-  // handle error
-}
-
-// modify-in-place
-deploymentApplyConfig.Spec.Template.Spec.WithContainers(corev1ac.Container().
-	WithName("modify-slice").
-	WithImage("nginx:1.14.2"),
-)
-
-// apply
-applied, err := deploymentClient.Apply(ctx, deploymentApplyConfig, metav1.ApplyOptions{FieldManager: fieldMgr})
-```
-
-For developers using Custom Resource Definitions (CRDs), the Kubebuilder apply support will provide the same capabilities. Documentation will be included in the Kubebuilder book when available.
-
-## Server-side Apply and CustomResourceDefinitions
-
-It is strongly recommended that all [Custom Resource Definitions](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) (CRDs) have a schema. CRDs without a schema are treated as unstructured data by Server-side Apply. Keys are treated as fields in a struct and lists are assumed to be atomic.
-
-CRDs that specify a schema are able to specify additional annotations in the schema. Please refer to the documentation on the full list of available annotations.
-
-New annotations since beta:
-
-**Defaulting:** Values for fields that appliers do not express explicit interest in should be defaulted. This prevents an applier from unintentionally owning a defaulted field that might cause conflicts with other appliers. If unspecified, the default value is nil or the nil equivalent for the corresponding type.
-
-- Usage: see the [CRD Defaulting](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting) documentation for more details.
-- Golang: `+default=<value>`
-- OpenAPI extension: `default: <value>`
-
-
-Atomic for maps and structs:
-
-**Maps:** By default maps are granular. A different manager is able to manage each map entry. They can also be configured to be atomic such that a single manager owns the entire map.
-
-- Usage: Refer to [Merge Strategy](/docs/reference/using-api/server-side-apply/#merge-strategy) for a more detailed overview
-- Golang: `+mapType=granular/atomic`
-- OpenAPI extension: `x-kubernetes-map-type: granular/atomic`
-
-**Structs:** By default structs are granular and a separate applier may own each field. For certain kinds of structs, atomicity may be desired. This is most commonly seen in small coordinate-like structs such as Field/Object/Namespace Selectors, Object References, RGB values, Endpoints (Protocol/Port pairs), etc.
-
-- Usage: Refer to [Merge Strategy](/docs/reference/using-api/server-side-apply/#merge-strategy) for a more detailed overview
-- Golang: `+structType=granular/atomic`
-- OpenAPI extension: `x-kubernetes-map-type:atomic/granular`
-
-## What's Next?
-
-After Server Side Apply, the next focus for the API Expression working-group is around improving the expressiveness and size of the published Kubernetes API schema. To see the full list of items we are working on, please join our working group and refer to the work items document.
-
-## How to get involved?
-
-The working-group for apply is [wg-api-expression](https://github.com/kubernetes/community/tree/master/wg-api-expression). It is available on slack [#wg-api-expression](https://kubernetes.slack.com/archives/C0123CNN8F3), through the [mailing list](https://groups.google.com/g/kubernetes-wg-api-expression) and we also meet every other Tuesday at 9.30 PT on Zoom.
-
-We would also like to use the opportunity to thank the hard work of all the contributors involved in making this promotion to GA possible:
-
-- Andrea Nodari
-- Antoine Pelisse
-- Daniel Smith
-- Jeffrey Ying
-- Jenny Buckley
-- Joe Betz
-- Julian Modesto
-- Kevin Delgado
-- Kevin Wiesmüller
-- Maria Ntalla

content/en/blog/_posts/2021-08-09-alpha-swap-support.md

@@ -1,142 +0,0 @@
----
-layout: blog
-title: 'New in Kubernetes v1.22: alpha support for using swap memory'
-date: 2021-08-09
-slug: run-nodes-with-swap-alpha
----
-
-**Author:** Elana Hashman (Red Hat)
-
-The 1.22 release introduced alpha support for configuring swap memory usage for
-Kubernetes workloads on a per-node basis.
-
-In prior releases, Kubernetes did not support the use of swap memory on Linux,
-as it is difficult to provide guarantees and account for pod memory utilization
-when swap is involved. As part of Kubernetes' earlier design, swap support was
-considered out of scope, and a kubelet would by default fail to start if swap
-was detected on a node.
-
-However, there are a number of [use cases](https://github.com/kubernetes/enhancements/blob/9d127347773ad19894ca488ee04f1cd3af5774fc/keps/sig-node/2400-node-swap/README.md#user-stories)
-that would benefit from Kubernetes nodes supporting swap, including improved
-node stability, better support for applications with high memory overhead but
-smaller working sets, the use of memory-constrained devices, and memory
-flexibility.
-
-Hence, over the past two releases, [SIG Node](https://github.com/kubernetes/community/tree/master/sig-node#readme) has
-been working to gather appropriate use cases and feedback, and propose a design
-for adding swap support to nodes in a controlled, predictable manner so that
-Kubernetes users can perform testing and provide data to continue building
-cluster capabilities on top of swap. The alpha graduation of swap memory
-support for nodes is our first milestone towards this goal!
-
-## How does it work?
-
-There are a number of possible ways that one could envision swap use on a node.
-To keep the scope manageable for this initial implementation, when swap is
-already provisioned and available on a node, [we have proposed](https://github.com/kubernetes/enhancements/blob/9d127347773ad19894ca488ee04f1cd3af5774fc/keps/sig-node/2400-node-swap/README.md#proposal)
-the kubelet should be able to be configured such that:
-
-- It can start with swap on.
-- It will direct the Container Runtime Interface to allocate zero swap memory
-  to Kubernetes workloads by default.
-- You can configure the kubelet to specify swap utilization for the entire
-  node.
-
-Swap configuration on a node is exposed to a cluster admin via the
-[`memorySwap` in the KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/).
-As a cluster administrator, you can specify the node's behaviour in the
-presence of swap memory by setting `memorySwap.swapBehavior`.
-
-This is possible through the addition of a `memory_swap_limit_in_bytes` field
-to the container runtime interface (CRI). The kubelet's config will control how
-much swap memory the kubelet instructs the container runtime to allocate to
-each container via the CRI. The container runtime will then write the swap
-settings to the container level cgroup.
-
-## How do I use it?
-
-On a node where swap memory is already provisioned, Kubernetes use of swap on a
-node can be enabled by enabling the `NodeSwap` feature gate on the kubelet, and
-disabling the `failSwapOn` [configuration setting](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
-or the `--fail-swap-on` command line flag.
-
-You can also optionally configure `memorySwap.swapBehavior` in order to
-specify how a node will use swap memory. For example,
-
-```yaml
-memorySwap:
-  swapBehavior: LimitedSwap
-```
-
-The available configuration options for `swapBehavior` are:
-
-- `LimitedSwap` (default): Kubernetes workloads are limited in how much swap
-  they can use. Workloads on the node not managed by Kubernetes can still swap.
-- `UnlimitedSwap`: Kubernetes workloads can use as much swap memory as they
-  request, up to the system limit.
-
-If configuration for `memorySwap` is not specified and the feature gate is
-enabled, by default the kubelet will apply the same behaviour as the
-`LimitedSwap` setting.
-
-The behaviour of the `LimitedSwap` setting depends if the node is running with
-v1 or v2 of control groups (also known as "cgroups"):
-
-- **cgroups v1:** Kubernetes workloads can use any combination of memory and
-  swap, up to the pod's memory limit, if set.
-- **cgroups v2:** Kubernetes workloads cannot use swap memory.
-
-### Caveats
-
-Having swap available on a system reduces predictability. Swap's performance is
-worse than regular memory, sometimes by many orders of magnitude, which can
-cause unexpected performance regressions. Furthermore, swap changes a system's
-behaviour under memory pressure, and applications cannot directly control what
-portions of their memory usage are swapped out. Since enabling swap permits
-greater memory usage for workloads in Kubernetes that cannot be predictably
-accounted for, it also increases the risk of noisy neighbours and unexpected
-packing configurations, as the scheduler cannot account for swap memory usage.
-
-The performance of a node with swap memory enabled depends on the underlying
-physical storage. When swap memory is in use, performance will be significantly
-worse in an I/O operations per second (IOPS) constrained environment, such as a
-cloud VM with I/O throttling, when compared to faster storage mediums like
-solid-state drives or NVMe.
-
-Hence, we do not recommend the use of swap for certain performance-constrained
-workloads or environments. Cluster administrators and developers should
-benchmark their nodes and applications before using swap in production
-scenarios, and [we need your help](#how-do-i-get-involved) with that!
-
-## Looking ahead
-
-The Kubernetes 1.22 release introduces alpha support for swap memory on nodes,
-and we will continue to work towards beta graduation in the 1.23 release. This
-will include:
-
-* Adding support for controlling swap consumption at the Pod level via cgroups.
-   * This will include the ability to set a system-reserved quantity of swap
-     from what kubelet detects on the host.
-* Determining a set of metrics for node QoS in order to evaluate the
-  performance and stability of nodes with and without swap enabled.
-* Collecting feedback from test user cases.
-  * We will consider introducing new configuration modes for swap, such as a
-    node-wide swap limit for workloads.
-
-## How can I learn more?
-
-You can review the current [documentation](https://kubernetes.io/docs/concepts/architecture/nodes/#swap-memory)
-on the Kubernetes website.
-
-For more information, and to assist with testing and provide feedback, please
-see [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) and its
-[design proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md).
-
-## How do I get involved?
-
-Your feedback is always welcome! SIG Node [meets regularly](https://github.com/kubernetes/community/tree/master/sig-node#meetings)
-and [can be reached](https://github.com/kubernetes/community/tree/master/sig-node#contact)
-via [Slack](https://slack.k8s.io/) (channel **#sig-node**), or the SIG's
-[mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-node).
-Feel free to reach out to me, Elana Hashman (**@ehashman** on Slack and GitHub)
-if you'd like to help.

content/en/blog/_posts/2021-08-09-csi-windows-support-with-csi-proxy-reaches-ga.md

@@ -1,76 +0,0 @@
----
-layout: blog
-title: 'Kubernetes 1.22: CSI Windows Support (with CSI Proxy) reaches GA'
-date: 2021-08-09
-slug: csi-windows-support-with-csi-proxy-reaches-ga
----
-
-**Authors:** Mauricio Poppe (Google), Jing Xu (Google), and Deep Debroy (Apple)
-
-*The stable version of CSI Proxy for Windows has been released alongside Kubernetes 1.22.  CSI Proxy enables CSI Drivers running on Windows nodes to perform privileged storage operations.*
-
-## Background
-
-Container Storage Interface (CSI) for Kubernetes went GA in the Kubernetes 1.13 release. CSI has become the standard for exposing block and file storage to containerized workloads on Container Orchestration systems (COs) like Kubernetes. It enables third-party storage providers to write and deploy plugins without the need to alter the core Kubernetes codebase. Legacy in-tree drivers are deprecated and new storage features are introduced in CSI, therefore it is important to get CSI Drivers to work on Windows.
-
-A CSI Driver in Kubernetes has two main components: a controller plugin which runs in the control plane and a node plugin which runs on every node.
-
-- The controller plugin generally does not need direct access to the host and can perform all its operations through the Kubernetes API and external control plane services.
-
-- The node plugin, however, requires direct access to the host for making block devices and/or file systems available to the Kubernetes kubelet. Due to the missing capability of running privileged operations from containers on Windows nodes [CSI Proxy was introduced as alpha in Kubernetes 1.18](https://kubernetes.io/blog/2020/04/03/kubernetes-1-18-feature-windows-csi-support-alpha/) as a way to enable containers to perform privileged storage operations. This enables containerized CSI Drivers to run on Windows nodes.
-
-## What's CSI Proxy and how do CSI drivers interact with it?
-
-When a workload that uses persistent volumes is scheduled, it'll go through a sequence of steps defined in the [CSI Spec](https://github.com/container-storage-interface/spec/blob/master/spec.md). First, the workload will be scheduled to run on a node. Then the controller component of a CSI Driver will attach the persistent volume to the node. Finally the node component of a CSI Driver will mount the persistent volume on the node.
-
-The node component of a CSI Driver needs to run on Windows nodes to support Windows workloads. Various privileged operations like scanning of disk devices, mounting of file systems, etc. cannot be done from a containerized application running on Windows nodes yet ([Windows HostProcess containers](https://github.com/kubernetes/enhancements/issues/1981) introduced in Kubernetes 1.22 as alpha enable functionalities that require host access like the operations mentioned before). However, we can perform these operations through a binary (CSI Proxy) that's pre-installed on the Window nodes. CSI Proxy has a client-server architecture and allows CSI drivers to issue privileged storage operations through a gRPC interface exposed over named pipes created during the startup of CSI Proxy.
-
-![CSI Proxy Architecture](/images/blog/2021-08-09-csi-windows-support-with-csi-proxy-reaches-ga/csi-proxy.png)
-
-## CSI Proxy reaches GA
-
-The CSI Proxy development team has worked closely with storage vendors, many of whom started integrating CSI Proxy into their CSI Drivers and provided feedback as early as CSI Proxy design proposal. This cooperation uncovered use cases where additional APIs were needed, found bugs, and identified areas for documentation improvement.
-
-The CSI Proxy design [KEP](https://github.com/kubernetes/enhancements/pull/2737) has been updated to reflect the current CSI Proxy architecture. Additional [development documentation](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/DEVELOPMENT.md) is included for contributors interested in helping with new features or bug fixes.
-
-Before we reached GA we wanted to make sure that our API is simple and consistent. We went through an extensive API review of the v1beta API groups where we made sure that the CSI Proxy API methods and messages are consistent with the naming conventions defined in the [CSI Spec](https://github.com/container-storage-interface/spec/blob/master/spec.md). As part of this effort we're graduating the [Disk](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/disk_v1.md), [Filesystem](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/filesystem_v1.md), [SMB](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/smb_v1.md) and [Volume](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/volume_v1.md) API groups to v1.
-
-Additional Windows system APIs to get information from the Windows nodes and support to mount iSCSI targets in Windows nodes, are available as alpha APIs in the [System API](https://github.com/kubernetes-csi/csi-proxy/tree/v1.0.0/client/api/system/v1alpha1) and the [iSCSI API](https://github.com/kubernetes-csi/csi-proxy/tree/v1.0.0/client/api/iscsi/v1alpha2). These APIs will continue to be improved before we graduate them to v1.
-
-CSI Proxy v1 is compatible with all the previous v1betaX releases. The GA `csi-proxy.exe` binary can handle requests from v1betaX clients thanks to the autogenerated conversion layer that transforms any versioned client request to a version-agnostic request that the server can process. Several [integration tests](https://github.com/kubernetes-csi/csi-proxy/tree/v1.0.0/integrationtests) were added for all the API versions of the API groups that are graduating to v1 to ensure that CSI Proxy is backwards compatible.
-
-Version drift between CSI Proxy and the CSI Drivers that interact with it was also carefully considered. A [connection fallback mechanism](https://github.com/kubernetes-csi/csi-proxy/pull/124) has been provided for CSI Drivers to handle multiple versions of CSI Proxy for a smooth upgrade to v1. This allows CSI Drivers, like the GCE PD CSI Driver, [to recognize which version of the CSI Proxy binary is running](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/pull/738) and handle multiple versions of the CSI Proxy binary deployed on the node.
-
-CSI Proxy v1 is already being used by many CSI Drivers, including the [AWS EBS CSI Driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/pull/966), [Azure Disk CSI Driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver/pull/919), [GCE PD CSI Driver](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/pull/738), and [SMB CSI Driver](https://github.com/kubernetes-csi/csi-driver-smb/pull/319).
-
-## Future plans
-
-We're very excited for the future of CSI Proxy. With the upcoming [Windows HostProcess containers](https://github.com/kubernetes/enhancements/issues/1981), we are considering converting the CSI Proxy in to a library consumed by CSI Drivers in addition to the current client/server design. This will allow us to iterate faster on new features because the `csi-proxy.exe` binary will no longer be needed.
-
-## How to get involved?
-
-This project, like all of Kubernetes, is the result of hard work by many contributors from diverse backgrounds working together. Those interested in getting involved with the design and development of CSI Proxy, or any part of the Kubernetes Storage system, may join the Kubernetes Storage Special Interest Group (SIG). We’re rapidly growing and always welcome new contributors.
-
-For those interested in more details about CSI support in Windows please reach out in the [#csi-windows](https://kubernetes.slack.com/messages/csi-windows) Kubernetes slack channel.
-
-## Acknowledgments
-
-CSI-Proxy received many contributions from members of the Kubernetes community. We thank all of the people that contributed to CSI Proxy with design reviews, bug reports, bug fixes, and for their continuous support in reaching this milestone:
-
-- [Andy Zhang](https://github.com/andyzhangx)
-- [Dan Ilan](https://github.com/jmpfar)
-- [Deep Debroy](https://github.com/ddebroy)
-- [Humble Devassy Chirammal](https://github.com/humblec)
-- [Jing Xu](https://github.com/jingxu97)
-- [Jean Rougé](https://github.com/wk8)
-- [Jordan Liggitt](https://github.com/liggitt)
-- [Kalya Subramanian](https://github.com/ksubrmnn)
-- [Krishnakumar R](https://github.com/kkmsft)
-- [Manuel Tellez](https://github.com/manueltellez)
-- [Mark Rossetti](https://github.com/marosset)
-- [Mauricio Poppe](https://github.com/mauriciopoppe)
-- [Matthew Wong](https://github.com/wongma7)
-- [Michelle Au](https://github.com/msau42)
-- [Patrick Lang](https://github.com/PatrickLang)
-- [Saad Ali](https://github.com/saad-ali)
-- [Yuju Hong](https://github.com/yujuhong)

content/en/blog/_posts/2021-08-11-memory-manager-moves-to-beta.md

@@ -1,144 +0,0 @@
----
-layout: blog
-title: "Kubernetes Memory Manager moves to beta"
-date: 2021-08-11
-slug: kubernetes-1-22-feature-memory-manager-moves-to-beta
----
-
-**Authors:** Artyom Lukianov (Red Hat), Cezary Zukowski (Samsung)
-
-The blog post explains some of the internals of the _Memory manager_, a beta feature
-of Kubernetes 1.22. In Kubernetes, the Memory Manager is a
-[kubelet](https://kubernetes.io/docs/concepts/overview/components/#kubelet) subcomponent.
-The memory manage provides guaranteed memory (and hugepages)
-allocation for pods in the `Guaranteed` [QoS class](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#qos-classes).
-
-This blog post covers:
-
-1. [Why do you need it?](#Why-do-you-need-it?)
-2. [The internal details of how the **MemoryManager** works](#How-does-it-work?)
-3. [Current limitations of the **MemoryManager**](#Current-limitations)
-4. [Future work for the **MemoryManager**](#Future-work-for-the-Memory-Manager)
-
-## Why do you need it?
-
-Some Kubernetes workloads run on nodes with
-[non-uniform memory access](https://en.wikipedia.org/wiki/Non-uniform_memory_access) (NUMA).
-Suppose you have NUMA nodes in your cluster. In that case, you'll know about the potential for extra latency when
-compute resources need to access memory on the different NUMA locality.
-
-To get the best performance and latency for your workload, container CPUs,
-peripheral devices, and memory should all be aligned to the same NUMA
-locality.
-Before Kubernetes v1.22, the kubelet already provided a set of managers to
-align CPUs and PCI devices, but you did not have a way to align memory.
-The Linux kernel was able to make best-effort attempts to allocate 
-memory for tasks from the same NUMA node where the container is
-executing are placed, but without any guarantee about that placement.
-
-## How does it work?
-
-The memory manager is doing two main things:
-- provides the topology hint to the Topology Manager
-- allocates the memory for containers and updates the state
-
-The overall sequence of the Memory Manager under the Kubelet
-
-![MemoryManagerDiagram](/images/blog/2021-08-11-memory-manager-moves-to-beta/MemoryManagerDiagram.svg "MemoryManagerDiagram")
-
-During the Admission phase:
-
-1. When first handling a new pod, the kubelet calls the TopologyManager's `Admit()` method.
-2. The Topology Manager is calling `GetTopologyHints()` for every hint provider including the Memory Manager.
-3. The Memory Manager calculates all possible NUMA nodes combinations for every container inside the pod and returns hints to the Topology Manager.
-4. The Topology Manager calls to `Allocate()` for every hint provider including the Memory Manager.
-5. The Memory Manager allocates the memory under the state according to the hint that the Topology Manager chose.
-
-During Pod creation:
-
-1. The kubelet calls `PreCreateContainer()`.
-2. For each container, the Memory Manager looks the NUMA nodes where it allocated the
-   memory for the container and then returns that information to the kubelet.
-3. The kubelet creates the container, via CRI, using a container specification
-   that incorporates information from the Memory Manager information.
-
-### Let's talk about the configuration
-
-By default, the Memory Manager runs with the `None` policy, meaning it will just
-relax and not do anything. To make use of the Memory Manager, you should set
-two command line options for the kubelet:
-
-- `--memory-manager-policy=Static`
-- `--reserved-memory="<numaNodeID>:<resourceName>=<quantity>"`
-
-The value for `--memory-manager-policy` is straightforward: `Static`. Deciding what to specify for `--reserved-memory` takes more thought. To configure it correctly, you should follow two main rules:
-
-- The amount of reserved memory for the `memory` resource must be greater than zero.
-- The amount of reserved memory for the resource type must be equal
-  to [NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
-  (`kube-reserved + system-reserved + eviction-hard`) for the resource.
-  You can read more about memory reservations in [Reserve Compute Resources for System Daemons](/docs/tasks/administer-cluster/reserve-compute-resources/).
-
-![Reserved memory](/images/blog/2021-08-11-memory-manager-moves-to-beta/ReservedMemory.svg)
-
-## Current limitations
-
-The 1.22 release and promotion to beta brings along enhancements and fixes, but the Memory Manager still has several limitations.
-
-### Single vs Cross NUMA node allocation
-
-The NUMA node can not have both single and cross NUMA node allocations. When the container memory is pinned to two or more NUMA nodes, we can not know from which NUMA node the container will consume the memory.
-
-![Single vs Cross NUMA allocation](/images/blog/2021-08-11-memory-manager-moves-to-beta/SingleCrossNUMAAllocation.svg "SingleCrossNUMAAllocation")
-
-1. The `container1` started on the NUMA node 0 and requests *5Gi* of the memory but currently is consuming only *3Gi* of the memory.
-2. For container2 the memory request is 10Gi, and no single NUMA node can satisfy it.
-3. The `container2` consumes *3.5Gi* of the memory from the NUMA node 0, but once the `container1` will require more memory, it will not have it, and the kernel will kill one of the containers with the *OOM* error.
-
-To prevent such issues, the Memory Manager will fail the admission of the `container2` until the machine has two NUMA nodes without a single NUMA node allocation.
-
-### Works only for Guaranteed pods
-
-The Memory Manager can not guarantee memory allocation for Burstable pods,
-also when the Burstable pod has specified equal memory limit and request.
-
-Let's assume you have two Burstable pods: `pod1` has containers with
-equal memory request and limits, and `pod2` has containers only with a
-memory request set. You want to guarantee memory allocation for the `pod1`.
-To the Linux kernel, processes in either pod have the same *OOM score*,
-once the kernel finds that it does not have enough memory, it can kill
-processes that belong to pod `pod1`.
-
-### Memory fragmentation
-
-The sequence of Pods and containers that start and stop can fragment the memory on NUMA nodes.
-The alpha implementation of the Memory Manager does not have any mechanism to balance pods and defragment memory back.
-
-## Future work for the Memory Manager
-
-We do not want to stop with the current state of the Memory Manager and are looking to
-make improvements, including in the following areas.
-
-### Make the Memory Manager allocation algorithm smarter
-
-The current algorithm ignores distances between NUMA nodes during the
-calculation of the allocation. If same-node placement isn't available, we can still
-provide better performance compared to the current implementation, by changing the
-Memory Manager to prefer the closest NUMA nodes for cross-node allocation.
-
-### Reduce the number of admission errors
-
-The default Kubernetes scheduler is not aware of the node's NUMA topology, and it can be a reason for many admission errors during the pod start.
-We're hoping to add a KEP (Kubernetes Enhancement Proposal) to cover improvements in this area. 
-Follow [Topology aware scheduler plugin in kube-scheduler](https://github.com/kubernetes/enhancements/issues/2044) to see how this idea progresses.
-
-
-## Conclusion
-With the promotion of the Memory Manager to beta in 1.22, we encourage everyone to give it a try and look forward to any feedback you may have. While there are still several limitations, we have a set of enhancements planned to address them and look forward to providing you with many new features in upcoming releases.
-If you have ideas for additional enhancements or a desire for certain features, please let us know. The team is always open to suggestions to enhance and improve the Memory Manager.
-We hope you have found this blog informative and helpful! Let us know if you have any questions or comments.
-
-You can contact us via:
-- The Kubernetes [#sig-node ](https://kubernetes.slack.com/messages/sig-node)
-  channel in Slack (visit https://slack.k8s.io/ for an invitation if you need one)
-- The SIG Node mailing list, [kubernetes-sig-node@googlegroups.com](https://groups.google.com/g/kubernetes-sig-node)

content/en/blog/_posts/2021-08-16-support-for-hostprocess-containers/index.md

@@ -1,79 +0,0 @@
----
-layout: blog
-title: 'Alpha in v1.22: Windows HostProcess Containers'
-date: 2021-08-16
-slug: windows-hostprocess-containers
----
-
-**Authors:** Brandon Smith (Microsoft)
-
-Kubernetes v1.22 introduced a new alpha feature for clusters that
-include Windows nodes: HostProcess containers.
-
-HostProcess containers aim to extend the Windows container model to enable a wider 
-range of Kubernetes cluster management scenarios. HostProcess containers run 
-directly on the host and maintain behavior and access similar to that of a regular 
-process. With HostProcess containers, users can package and distribute management 
-operations and functionalities that require host access while retaining versioning 
-and deployment methods provided by containers. This allows Windows containers to 
-be used for a variety of device plugin, storage, and networking management scenarios 
-in Kubernetes. With this comes the enablement of host network mode—allowing
-HostProcess containers to be created within the host's network namespace instead of 
-their own. HostProcess containers can also be built on top of existing Windows server 
-2019 (or later) base images, managed through the Windows container runtime, and run 
-as any user that is available on or in the domain of the host machine.
-
-Linux privileged containers are currently used for a variety of key scenarios in 
-Kubernetes, including kube-proxy (via kubeadm), storage, and networking scenarios. 
-Support for these scenarios in Windows previously required workarounds via proxies 
-or other implementations. Using HostProcess containers, cluster operators no longer 
-need to log onto and individually configure each Windows node for administrative 
-tasks and management of Windows services. Operators can now utilize the container 
-model to deploy management logic to as many clusters as needed with ease. 
-
-## How does it work?
-
-Windows HostProcess containers are implemented with Windows _Job Objects_, a break from the
-previous container model using server silos. Job objects are components of the Windows OS which offer the ability to 
-manage a group of processes as a group (a.k.a. _jobs_) and assign resource constraints to the 
-group as a whole. Job objects are specific to the Windows OS and are not associated with the Kubernetes [Job API](https://kubernetes.io/docs/concepts/workloads/controllers/job/). They have no process or file system isolation, 
-enabling the privileged payload to view and edit the host file system with the 
-correct permissions, among other host resources. The init process, and any processes 
-it launches or that are explicitly launched by the user, are all assigned to the 
-job object of that container. When the init process exits or is signaled to exit, 
-all the processes in the job will be signaled to exit, the job handle will be 
-closed and the storage will be unmounted.
-
-HostProcess and Linux privileged containers enable similar scenarios but differ 
-greatly in their implementation (hence the naming difference). HostProcess containers 
-have their own pod security policies. Those used to configure Linux privileged 
-containers **do not** apply. Enabling privileged access to a Windows host is a 
-fundamentally different process than with Linux so the configuration and 
-capabilities of each differ significantly. Below is a diagram detailing the 
-overall architecture of Windows HostProcess containers:
-
-{{< figure src="hostprocess-architecture.png" alt="HostProcess Architecture" >}}
-
-## How do I use it?
-
-HostProcess containers can be run from within a 
-[HostProcess Pod](/docs/tasks/configure-pod-container/create-hostprocess-pod). 
-With the feature enabled on Kubernetes version 1.22, a containerd container runtime of 
-1.5.4 or higher, and the latest version of hcsshim, deploying a pod spec with the 
-[correct HostProcess configuration](/docs/tasks/configure-pod-container/create-hostprocess-pod/#before-you-begin) 
-will enable you to run HostProcess containers. To get started with running 
-Windows containers see the general guidance for [Windows in Kubernetes](/docs/setup/production-environment/windows/)
-
-## How can I learn more?
-
-- Work through [Create a Windows HostProcess Pod](/docs/tasks/configure-pod-container/create-hostprocess-pod/)
-
-- Read about Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-standards/)
-
-- Read the enhancement proposal [Windows Privileged Containers and Host Networking Mode](https://github.com/kubernetes/enhancements/tree/master/keps/sig-windows/1981-windows-privileged-container-support) (KEP-1981)
-
-## How do I get involved?
-
-HostProcess containers are in active development. SIG Windows welcomes suggestions from the community.
-Get involved with [SIG Windows](https://github.com/kubernetes/community/tree/master/sig-windows)
-to contribute!

content/en/blog/_posts/2021-08-25-seccomp-default.md

@@ -1,267 +0,0 @@
----
-layout: blog
-title: "Enable seccomp for all workloads with a new v1.22 alpha feature"
-date: 2021-08-25
-slug: seccomp-default
----
-
-**Author:** Sascha Grunert, Red Hat
-
-This blog post is about a new Kubernetes feature introduced in v1.22, which adds
-an additional security layer on top of the existing seccomp support. Seccomp is
-a security mechanism for Linux processes to filter system calls (syscalls) based
-on a set of defined rules. Applying seccomp profiles to containerized workloads
-is one of the key tasks when it comes to enhancing the security of the
-application deployment. Developers, site reliability engineers and
-infrastructure administrators have to work hand in hand to create, distribute
-and maintain the profiles over the applications life-cycle.
-
-You can use the [`securityContext`][seccontext] field of Pods and their
-containers can be used to adjust security related configurations of the
-workload. Kubernetes introduced dedicated [seccomp related API
-fields][seccontext] in this `SecurityContext` with the [graduation of seccomp to
-General Availability (GA)][ga] in v1.19.0. This enhancement allowed an easier
-way to specify if the whole pod or a specific container should run as:
-
-[seccontext]: /docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1
-[ga]: https://kubernetes.io/blog/2020/08/26/kubernetes-release-1.19-accentuate-the-paw-sitive/#graduated-to-stable
-
-- `Unconfined`: seccomp will not be enabled
-- `RuntimeDefault`: the container runtimes default profile will be used
-- `Localhost`: a node local profile will be applied, which is being referenced
-  by a relative path to the seccomp profile root (`<kubelet-root-dir>/seccomp`)
-  of the kubelet
-
-With the graduation of seccomp, nothing has changed from an overall security
-perspective, because `Unconfined` is still the default. This is totally fine if
-you consider this from the upgrade path and backwards compatibility perspective of
-Kubernetes releases. But it also means that it is more likely that a workload
-runs without seccomp at all, which should be fixed in the long term.
-
-## `SeccompDefault` to the rescue
-
-Kubernetes v1.22.0 introduces a new kubelet [feature gate][gate]
-`SeccompDefault`, which has been added in `alpha` state as every other new
-feature. This means that it is disabled by default and can be enabled manually
-for every single Kubernetes node.
-
-[gate]: /docs/reference/command-line-tools-reference/feature-gates
-
-What does the feature do? Well, it just changes the default seccomp profile from
-`Unconfined` to `RuntimeDefault`. If not specified differently in the pod
-manifest, then the feature will add a higher set of security constraints by
-using the default profile of the container runtime. These profiles may differ
-between runtimes like [CRI-O][crio] or [containerd][ctrd]. They also differ for
-its used hardware architectures. But generally speaking, those default profiles
-allow a common amount of syscalls while blocking the more dangerous ones, which
-are unlikely or unsafe to be used in a containerized application.
-
-[crio]: https://github.com/cri-o/cri-o/blob/fe30d62/vendor/github.com/containers/common/pkg/seccomp/default_linux.go#L45
-[ctrd]: https://github.com/containerd/containerd/blob/e1445df/contrib/seccomp/seccomp_default.go#L51
-
-### Enabling the feature
-
-Two kubelet configuration changes have to be made to enable the feature:
-
-1. **Enable the feature** gate by setting the `SeccompDefault=true` via the command
-   line (`--feature-gates`) or the [kubelet configuration][kubelet] file.
-2. **Turn on the feature** by enabling the feature by adding the
-   `--seccomp-default` command line flag or via the [kubelet
-   configuration][kubelet] file (`seccompDefault: true`).
-
-[kubelet]: /docs/tasks/administer-cluster/kubelet-config-file
-
-The kubelet will error on startup if only one of the above steps have been done.
-
-### Trying it out
-
-If the feature is enabled on a node, then you can create a new workload like
-this:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: test-pod
-spec:
-  containers:
-    - name: test-container
-      image: nginx:1.21
-```
-
-Now it is possible to inspect the used seccomp profile by using
-[`crictl`][crictl] while investigating the containers [runtime
-specification][rspec]:
-
-[crictl]: https://github.com/kubernetes-sigs/cri-tools
-[rspec]: https://github.com/opencontainers/runtime-spec/blob/0c021c1/config-linux.md#seccomp
-
-```bash
-CONTAINER_ID=$(sudo crictl ps -q --name=test-container)
-sudo crictl inspect $CONTAINER_ID | jq .info.runtimeSpec.linux.seccomp
-```
-
-```yaml
-{
-  "defaultAction": "SCMP_ACT_ERRNO",
-  "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32"],
-  "syscalls": [
-    {
-      "names": ["_llseek", "_newselect", "accept", …, "write", "writev"],
-      "action": "SCMP_ACT_ALLOW"
-    },
-    …
-  ]
-}
-```
-
-You can see that the lower level container runtime ([CRI-O][crio-home] and
-[runc][runc] in our case), successfully applied the default seccomp profile.
-This profile denies all syscalls per default, while allowing commonly used ones
-like [`accept`][accept] or [`write`][write].
-
-[crio-home]: https://github.com/cri-o/cri-o
-[runc]: https://github.com/opencontainers/runc
-[accept]: https://man7.org/linux/man-pages/man2/accept.2.html
-[write]: https://man7.org/linux/man-pages/man2/write.2.html
-
-Please note that the feature will not influence any Kubernetes API for now.
-Therefore, it is not possible to retrieve the used seccomp profile via `kubectl`
-`get` or `describe` if the [`SeccompProfile`][api] field is unset within the
-`SecurityContext`.
-
-[api]: https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1
-
-The feature also works when using multiple containers within a pod, for example
-if you create a pod like this:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: test-pod
-spec:
-  containers:
-    - name: test-container-nginx
-      image: nginx:1.21
-      securityContext:
-        seccompProfile:
-          type: Unconfined
-    - name: test-container-redis
-      image: redis:6.2
-```
-
-then you should see that the `test-container-nginx` runs without a seccomp profile:
-
-```bash
-sudo crictl inspect $(sudo crictl ps -q --name=test-container-nginx) |
-    jq '.info.runtimeSpec.linux.seccomp == null'
-true
-```
-
-Whereas the container `test-container-redis` runs with `RuntimeDefault`:
-
-```bash
-sudo crictl inspect $(sudo crictl ps -q --name=test-container-redis) |
-    jq '.info.runtimeSpec.linux.seccomp != null'
-true
-```
-
-The same applies to the pod itself, which also runs with the default profile:
-
-```bash
-sudo crictl inspectp (sudo crictl pods -q --name test-pod) |
-    jq '.info.runtimeSpec.linux.seccomp != null'
-true
-```
-
-### Upgrade strategy
-
-It is recommended to enable the feature in multiple steps, whereas different
-risks and mitigations exist for each one.
-
-#### Feature gate enabling
-
-Enabling the feature gate at the kubelet level will not turn on the feature, but
-will make it possible by using the `SeccompDefault` kubelet configuration or the
-`--seccomp-default` CLI flag. This can be done by an administrator for the whole
-cluster or only a set of nodes.
-
-#### Testing the Application
-
-If you're trying this within a dedicated test environment, you have to ensure
-that the application code does not trigger syscalls blocked by the
-`RuntimeDefault` profile before enabling the feature on a node. This can be done
-by:
-
-- _Recommended_: Analyzing the code (manually or by running the application with
-  [strace][strace]) for any executed syscalls which may be blocked by the
-  default profiles. If that's the case, then you can override the default by
-  explicitly setting the pod or container to run as `Unconfined`. Alternatively,
-  you can create a custom seccomp profile (see optional step below).
-  profile based on the default by adding the additional syscalls to the
-  `"action": "SCMP_ACT_ALLOW"` section.
-
-- _Recommended_: Manually set the profile to the target workload and use a
-  rolling upgrade to deploy into production. Rollback the deployment if the
-  application does not work as intended.
-
-- _Optional_: Run the application against an end-to-end test suite to trigger
-  all relevant code paths with `RuntimeDefault` enabled. If a test fails, use
-  the same mitigation as mentioned above.
-
-- _Optional_: Create a custom seccomp profile based on the default and change
-  its default action from `SCMP_ACT_ERRNO` to `SCMP_ACT_LOG`. This means that
-  the seccomp filter for unknown syscalls will have no effect on the application
-  at all, but the system logs will now indicate which syscalls may be blocked.
-  This requires at least a Kernel version 4.14 as well as a recent [runc][runc]
-  release. Monitor the application hosts audit logs (defaults to
-  `/var/log/audit/audit.log`) or syslog entries (defaults to `/var/log/syslog`)
-  for syscalls via `type=SECCOMP` (for audit) or `type=1326` (for syslog).
-  Compare the syscall ID with those [listed in the Linux Kernel
-  sources][syscalls] and add them to the custom profile. Be aware that custom
-  audit policies may lead into missing syscalls, depending on the configuration
-  of auditd.
-
-- _Optional_: Use cluster additions like the [Security Profiles Operator][spo]
-  for profiling the application via its [log enrichment][logs] capabilities or
-  recording a profile by using its [recording feature][rec]. This makes the
-  above mentioned manual log investigation obsolete.
-
-[syscalls]: https://github.com/torvalds/linux/blob/7bb7f2a/arch/x86/entry/syscalls/syscall_64.tbl
-[spo]: https://github.com/kubernetes-sigs/security-profiles-operator
-[logs]: https://github.com/kubernetes-sigs/security-profiles-operator/blob/c90ef3a/installation-usage.md#record-profiles-from-workloads-with-profilerecordings
-[rec]: https://github.com/kubernetes-sigs/security-profiles-operator/blob/c90ef3a/installation-usage.md#using-the-log-enricher
-[strace]: https://man7.org/linux/man-pages/man1/strace.1.html
-
-#### Deploying the modified application
-
-Based on the outcome of the application tests, it may be required to change the
-application deployment by either specifying `Unconfined` or a custom seccomp
-profile. This is not the case if the application works as intended with
-`RuntimeDefault`.
-
-#### Enable the kubelet configuration
-
-If everything went well, then the feature is ready to be enabled by the kubelet
-configuration or its corresponding CLI flag. This should be done on a per-node
-basis to reduce the overall risk of missing a syscall during the investigations
-when running the application tests. If it's possible to monitor audit logs
-within the cluster, then it's recommended to do this for eventually missed
-seccomp events. If the application works as intended then the feature can be
-enabled for further nodes within the cluster.
-
-## Conclusion
-
-Thank you for reading this blog post! I hope you enjoyed to see how the usage of
-seccomp profiles has been evolved in Kubernetes over the past releases as much
-as I do. On your own cluster, change the default seccomp profile to
-`RuntimeDefault` (using this new feature) and see the security benefits, and, of
-course, feel free to reach out any time for feedback or questions.
-
----
-
-_Editor's note: If you have any questions or feedback about this blog post, feel
-free to reach out via the [Kubernetes slack in #sig-node][slack]._
-
-[slack]: https://kubernetes.slack.com/messages/sig-node

content/en/blog/_posts/2021-08-27-minreadysecond-statefulsets.md

@@ -1,48 +0,0 @@
----
-layout: blog
-title: 'Minimum Ready Seconds for StatefulSets'
-date: 2021-08-27
-slug: minreadyseconds-statefulsets
----
-
-**Authors:** Ravi Gudimetla (Red Hat), Maciej Szulik (Red Hat)
-
-This blog describes the notion of Availability for `StatefulSet` workloads, and a new alpha feature in Kubernetes 1.22 which adds `minReadySeconds` configuration for `StatefulSets`.
-
-## What problems does this solve?
-
-Prior to Kubernetes 1.22 release, once a `StatefulSet` `Pod` is in the `Ready` state it is considered `Available` to receive traffic. For some of the `StatefulSet` workloads, it may not be the case. For example, a workload like Prometheus with multiple instances of Alertmanager, it should be considered `Available` only when Alertmanager's state transfer is complete, not when the `Pod` is in `Ready` state. Since `minReadySeconds` adds buffer, the state transfer may be complete before the `Pod` becomes `Available`. While this is not a fool proof way of identifying if the state transfer is complete or not, it gives a way to the end user to express their intention of waiting for sometime before the `Pod` is considered `Available` and it is ready to serve requests. 
-
-Another case, where `minReadySeconds` helps is when using `LoadBalancer` `Services` with cloud providers. Since `minReadySeconds` adds latency after a `Pod` is `Ready`, it provides buffer time to prevent killing pods in rotation before new pods show up. Imagine a load balancer in unhappy path taking 10-15s to propagate. If you have 2 replicas then, you'd kill the second replica only after the first one is up but in reality, first replica cannot be seen because it is not yet ready to serve requests.
-
-So, in general, the notion of `Availability` in `StatefulSets` is pretty useful and this feature helps in solving the above problems. This is a feature that already exists for `Deployments` and `DaemonSets` and we now have them for `StatefulSets` too to give users consistent workload experience.
-
-
-## How does it work?
-
-The statefulSet controller watches for both `StatefulSets` and the `Pods` associated with them. When the feature gate associated with this feature is enabled, the statefulSet controller identifies how long a particular `Pod` associated with a `StatefulSet` has been in the `Running` state.
-
-If this value is greater than or equal to the time specified by the end user in `.spec.minReadySeconds` field, the statefulSet controller updates a field called `availableReplicas` in the `StatefulSet`'s status subresource to include this `Pod`. The `status.availableReplicas` in `StatefulSet`'s status is an integer field which tracks the number of pods that are `Available`.
-
-## How do I use it?
-
-You are required to prepare the following things in order to try out the feature:
-
-   - Download and install a kubectl greater than v1.22.0 version
-   - Switch on the feature gate with the command line flag `--feature-gates=StatefulSetMinReadySeconds=true` on `kube-apiserver` and `kube-controller-manager`
-
-After successfully starting `kube-apiserver` and `kube-controller-manager`, you will see `AvailableReplicas` in the status and `minReadySeconds` of spec (with a default value of 0). 
-
-Specify a value for `minReadySeconds` for any StatefulSet and you can check if `Pods` are available or not by checking `AvailableReplicas` field using:
-`kubectl get statefulset/<name_of_the_statefulset> -o yaml`
-
-## How can I learn more?
-
-- Read the KEP: [minReadySeconds for StatefulSets](https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/2599-minreadyseconds-for-statefulsets#readme)
-- Read the documentation: [Minimum ready seconds](/docs/concepts/workloads/controllers/statefulset/#minimum-ready-seconds) for StatefulSet
-- Review the [API definition](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/) for StatefulSet
-
-## How do I get involved?
-
-Please reach out to us in the [#sig-apps](https://kubernetes.slack.com/archives/C18NZM5K9) channel on Slack (visit https://slack.k8s.io/ for an invitation if you need one), or on the SIG Apps mailing list: kubernetes-sig-apps@googlegroups.com
-

content/en/blog/_posts/2021-08-30-volume-populators-alpha.md

@@ -1,219 +0,0 @@
----
-layout: blog
-title: "Kubernetes 1.22: A New Design for Volume Populators"
-date: 2021-08-30
-slug: volume-populators-redesigned
----
-
-**Authors:**
-Ben Swartzlander (NetApp)
-
-Kubernetes v1.22, released earlier this month, introduced a redesigned approach for volume
-populators. Originally implemented
-in v1.18, the API suffered from backwards compatibility issues. Kubernetes v1.22 includes a new API
-field called `dataSourceRef` that fixes these problems.
-
-## Data sources
-
-Earlier Kubernetes releases already added a `dataSource` field into the
-[PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) API,
-used for cloning volumes and creating volumes from snapshots. You could use the `dataSource` field when
-creating a new PVC, referencing either an existing PVC or a VolumeSnapshot in the same namespace.
-That also modified the normal provisioning process so that instead of yielding an empty volume, the
-new PVC contained the same data as either the cloned PVC or the cloned VolumeSnapshot.
-
-Volume populators embrace the same design idea, but extend it to any type of object, as long
-as there exists a [custom resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
-to define the data source, and a populator controller to implement the logic. Initially,
-the `dataSource` field was directly extended to allow arbitrary objects, if the `AnyVolumeDataSource`
-feature gate was enabled on a cluster. That change unfortunately caused backwards compatibility
-problems, and so the new `dataSourceRef` field was born.
-
-In v1.22 if the `AnyVolumeDataSource` feature gate is enabled, the `dataSourceRef` field is
-added, which behaves similarly to the `dataSource` field except that it allows arbitrary
-objects to be specified. The API server ensures that the two fields always have the same
-contents, and neither of them are mutable. The differences is that at creation time
-`dataSource` allows only PVCs or VolumeSnapshots, and ignores all other values, while
-`dataSourceRef` allows most types of objects, and in the few cases it doesn't allow an
-object (core objects other than PVCs) a validation error occurs.
-
-When this API change graduates to stable, we would deprecate using `dataSource` and recommend
-using `dataSourceRef` field for all use cases.
-In the v1.22 release, `dataSourceRef` is available (as an alpha feature) specifically for cases
-where you want to use for custom volume populators.
-
-## Using populators
-
-Every volume populator must have one or more CRDs that it supports. Administrators may
-install the CRD and the populator controller and then PVCs with a `dataSourceRef` specifies
-a CR of the type that the populator supports will be handled by the populator controller
-instead of the CSI driver directly.
-
-Underneath the covers, the CSI driver is still invoked to create an empty volume, which
-the populator controller fills with the appropriate data. The PVC doesn't bind to the PV
-until it's fully populated, so it's safe to define a whole application manifest including
-pod and PVC specs and the pods won't begin running until everything is ready, just as if
-the PVC was a clone of another PVC or VolumeSnapshot.
-
-## How it works
-
-PVCs with data sources are still noticed by the external-provisioner sidecar for the
-related storage class (assuming a CSI provisioner is used), but because the sidecar
-doesn't understand the data source kind, it doesn't do anything. The populator controller
-is also watching for PVCs with data sources of a kind that it understands and when it
-sees one, it creates a temporary PVC of the same size, volume mode, storage class,
-and even on the same topology (if topology is used) as the original PVC. The populator
-controller creates a worker pod that attaches to the volume and writes the necessary
-data to it, then detaches from the volume and the populator controller rebinds the PV
-from the temporary PVC to the orignal PVC.
-
-## Trying it out
-
-The following things are required to use volume populators:
-* Enable the `AnyVolumeDataSource` feature gate
-* Install a CRD for the specific data source / populator
-* Install the populator controller itself
-
-Populator controllers may use the [lib-volume-populator](https://github.com/kubernetes-csi/lib-volume-populator)
-library to do most of the Kubernetes API level work. Individual populators only need to
-provide logic for actually writing data into the volume based on a particular CR
-instance. This library provides a sample populator implementation.
-
-These optional components improve user experience:
-* Install the VolumePopulator CRD
-* Create a VolumePopulator custom respource for each specific data source
-* Install the [volume data source validator](https://github.com/kubernetes-csi/volume-data-source-validator)
-  controller (alpha)
-
-The purpose of these components is to generate warning events on PVCs with data sources
-for which there is no populator.
-
-## Putting it all together
-
-To see how this works, you can install the sample "hello" populator and try it
-out.
-
-First install the volume-data-source-validator controller.
-
-```terminal
-kubectl apply -f https://github.com/kubernetes-csi/volume-data-source-validator/blob/master/deploy/kubernetes/rbac-data-source-validator.yaml
-kubectl apply -f https://github.com/kubernetes-csi/volume-data-source-validator/blob/master/deploy/kubernetes/setup-data-source-validator.yaml
-```
-
-Next install the example populator.
-
-```terminal
-kubectl apply -f https://github.com/kubernetes-csi/lib-volume-populator/blob/master/example/hello-populator/crd.yaml
-kubectl apply -f https://github.com/kubernetes-csi/lib-volume-populator/blob/master/example/hello-populator/deploy.yaml
-```
-
-Create an instance of the `Hello` CR, with some text.
-
-```yaml
-apiVersion: hello.k8s.io/v1alpha1
-kind: Hello
-metadata:
-  name: example-hello
-spec:
-  fileName: example.txt
-  fileContents: Hello, world!
-```
-
-Create a PVC that refers to that CR as its data source.
-
-```yaml
-apiVersion: v1
-kind: PersistentVolumeClaim
-metadata:
-  name: example-pvc
-spec:
-  accessModes:
-  - ReadWriteOnce
-  resources:
-    requests:
-      storage: 10Mi
-  dataSourceRef:
-    apiGroup: hello.k8s.io
-    kind: Hello
-    name: example-hello
-  volumeMode: Filesystem
-```
-
-Next, run a job that reads the file in the PVC.
-
-```yaml
-apiVersion: batch/v1
-kind: Job
-metadata:
-  name: example-job
-spec:
-  template:
-    spec:
-      containers:
-        - name: example-container
-          image: busybox:latest
-          command:
-            - cat
-            - /mnt/example.txt
-          volumeMounts:
-            - name: vol
-              mountPath: /mnt
-      restartPolicy: Never
-      volumes:
-        - name: vol
-          persistentVolumeClaim:
-            claimName: example-pvc
-```
-
-Wait for the job to complete (including all of its dependencies).
-
-```terminal
-kubectl wait --for=condition=Complete job/example-job
-```
-
-And last examine the log from the job.
-
-```terminal
-kubectl logs job/example-job
-Hello, world!
-```
-
-Note that the volume already contained a text file with the string contents from
-the CR. This is only the simplest example. Actual populators can set up the volume
-to contain arbitrary contents.
-
-## How to write your own volume populator
-
-Developers interested in writing new poplators are encouraged to use the
-[lib-volume-populator](https://github.com/kubernetes-csi/lib-volume-populator) library
-and to only supply a small controller wrapper around the library, and a pod image
-capable of attaching to volumes and writing the appropriate data to the volume.
-
-Individual populators can be extremely generic such that they work with every type
-of PVC, or they can do vendor specific things to rapidly fill a volume with data
-if the volume was provisioned by a specific CSI driver from the same vendor, for
-example, by communicating directly with the storage for that volume.
-
-## The future
-
-As this feature is still in alpha, we expect to update the out of tree controllers
-with more tests and documentation. The community plans to eventually re-implement
-the populator library as a sidecar, for ease of operations.
-
-We hope to see some official community-supported populators for some widely-shared
-use cases. Also, we expect that volume populators will be used by backup vendors
-as a way to "restore" backups to volumes, and possibly a standardized API to do
-this will evolve.
-
-## How can I learn more?
-
-The enhancement proposal,
-[Volume Populators](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1495-volume-populators), includes lots of detail about the history and technical implementation
-of this feature.
-
-[Volume populators and data sources](/docs/concepts/storage/persistent-volumes/#volume-populators-and-data-sources), within the documentation topic about persistent volumes,
-explains how to use this feature in your cluster.
-
-Please get involved by joining the Kubernetes storage SIG to help us enhance this
-feature. There are a lot of good ideas already and we'd be thrilled to have more!
-

content/en/blog/_posts/2021-09-03-api-server-tracing.md

@@ -1,67 +0,0 @@
----
-layout: blog
-title: 'Alpha in Kubernetes v1.22: API Server Tracing'
-date: 2021-09-03
-slug: api-server-tracing
----
-
-**Authors:** David Ashpole (Google)
-
-In distributed systems, it can be hard to figure out where problems are. You grep through one component's logs just to discover that the source of your problem is in another component.  You search there only to discover that you need to enable debug logs to figure out what really went wrong... And it goes on. The more complex the path your request takes, the harder it is to answer questions about where it went.  I've personally spent many hours doing this dance with a variety of Kubernetes components. Distributed tracing is a tool which is designed to help in these situations, and the Kubernetes API Server is, perhaps, the most important Kubernetes component to be able to debug. At Kubernetes' Sig Instrumentation, our mission is to make it easier to understand what's going on in your cluster, and we are happy to announce that distributed tracing in the Kubernetes API Server reached alpha in 1.22.
-
-## What is Tracing?
-
-Distributed tracing links together a bunch of super-detailed information from multiple different sources, and structures that telemetry into a single tree for that request.  Unlike logging, which limits the quantity of data ingested by using log levels, tracing collects all of the details and uses sampling to collect only a small percentage of requests.  This means that once you have a trace which demonstrates an issue, you should have all the information you need to root-cause the problem--no grepping for object UID required! My favorite aspect, though, is how useful the visualizations of traces are.  Even if you don't understand the inner workings of the API Server, or don't have a clue what an etcd "Transaction" is, I'd wager you (yes, you!) could tell me roughly what the order of events was, and which components were involved in the request.  If some step takes a long time, it is easy to tell where the problem is.
-
-## Why OpenTelemetry?
-
-It's important that Kubernetes works well for everyone, regardless of who manages your infrastructure, or which vendors you choose to integrate with.  That is particularly true for Kubernetes' integrations with telemetry solutions.  OpenTelemetry, being a CNCF project, shares these core values, and is creating exactly what we need in Kubernetes: A set of open standards for Tracing client library APIs and a standard trace format. By using OpenTelemetry, we can ensure users have the freedom to choose their backend, and ensure vendors have a level playing field. The timing couldn't be better: the OpenTelemetry golang API and SDK are very close to their 1.0 release, and will soon offer backwards-compatibility for these open standards.
-
-## Why instrument the API Server?
-
-The Kubernetes API Server is a great candidate for tracing for a few reasons:
-
-* It follows the standard "RPC" model (serve a request by making requests to downstream components), which makes it easy to instrument.
-* Users are latency-sensitive: If a request takes more than 10 seconds to complete, many clients will time-out.
-* It has a complex service topology: A single request could require consulting a dozen webhooks, or involve multiple requests to etcd.
-
-## Trying out APIServer Tracing with a webhook
-
-### Enabling API Server Tracing
-
-1. Enable the APIServerTracing [feature-gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/).
-
-2. Set our configuration for tracing by pointing the `--tracing-config-file` flag on the kube-apiserver at our config file, which contains:
-
-```yaml
-apiVersion: apiserver.config.k8s.io/v1alpha1
-kind: TracingConfiguration
-# 1% sampling rate
-samplingRatePerMillion: 10000
-```
-
-### Enabling Etcd Tracing
-
-Add `--experimental-enable-distributed-tracing`,  `--experimental-distributed-tracing-address=0.0.0.0:4317`, `--experimental-distributed-tracing-service-name=etcd` flags to etcd to enable tracing.  Note that this traces every request, so it will probably generate a lot of traces if you enable it.
-
-### Example Trace: List Nodes
-
-I could've used any trace backend, but decided to use Jaeger, since it is one of the most popular open-source tracing projects.  I deployed [the Jaeger All-in-one container](https://hub.docker.com/r/jaegertracing/all-in-one) in my cluster, deployed [the OpenTelemetry collector](https://github.com/open-telemetry/opentelemetry-collector) on my control-plane node ([example](https://github.com/dashpole/dashpole_demos/tree/master/otel/controlplane)), and captured traces like this one:
-
-![Jaeger screenshot showing API server and etcd trace](/images/blog/2021-09-03-api-server-tracing/example-trace-1.png "Jaeger screenshot showing API server and etcd trace")
-
-The teal lines are from the API Server, and includes it serving a request to `/api/v1/nodes`, and issuing a grpc `Range` RPC to ETCD.  The yellow-ish line is from ETCD handling the `Range` RPC.
-
-### Example Trace: Create Pod with Mutating Webhook
-
-I instrumented the [example webhook](https://github.com/kubernetes-sigs/controller-runtime/tree/master/examples/builtins) with OpenTelemetry (I had to [patch](https://github.com/dashpole/controller-runtime/commit/85fdda7ba03dd2c22ef62c1a3dbdf5aa651f90da) controller-runtime, but it makes a neat demo), and routed traces to Jaeger as well.  I collected traces like this one:
-
-![Jaeger screenshot showing API server, admission webhook, and etcd trace](/images/blog/2021-09-03-api-server-tracing/example-trace-2.png "Jaeger screenshot showing API server, admission webhook, and etcd trace")
-
-Compared with the previous trace, there are two new spans: A teal span from the API Server making a request to the admission webhook, and a brown span from the admission webhook serving the request.  Even if you didn't instrument your webhook, you would still get the span from the API Server making the request to the webhook.
-
-## Get involved!
-
-As this is our first attempt at adding distributed tracing to a Kubernetes component, there is probably a lot we can improve! If my struggles resonated with you, or if you just want to try out the latest Kubernetes has to offer, please give the feature a try and open issues with any problem you encountered and ways you think the feature could be improved.
-
-This is just the very beginning of what we can do with distributed tracing in Kubernetes. If there are other components you think would benefit from distributed tracing, or want to help bring API Server Tracing to GA, join sig-instrumentation at our [regular meetings](https://github.com/kubernetes/community/tree/master/sig-instrumentation#instrumentation-special-interest-group) and get involved!

content/en/blog/_posts/2021-09-13-read-write-once-pod-access-mode-alpha.md

@@ -1,287 +0,0 @@
----
-layout: blog
-title: "Introducing Single Pod Access Mode for PersistentVolumes"
-date: 2021-09-13
-slug: read-write-once-pod-access-mode-alpha
----
-
-**Author:** Chris Henzie (Google)
-
-Last month's release of Kubernetes v1.22 introduced a new ReadWriteOncePod access mode for [PersistentVolumes](/docs/concepts/storage/persistent-volumes/#persistent-volumes) and [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
-With this alpha feature, Kubernetes allows you to restrict volume access to a single pod in the cluster.
-
-## What are access modes and why are they important?
-
-When using storage, there are different ways to model how that storage is consumed.
-
-For example, a storage system like a network file share can have many users all reading and writing data simultaneously.
-In other cases maybe everyone is allowed to read data but not write it.
-For highly sensitive data, maybe only one user is allowed to read and write data but nobody else.
-
-In the world of Kubernetes, [access modes](/docs/concepts/storage/persistent-volumes/#access-modes) are the way you can define how durable storage is consumed.
-These access modes are a part of the spec for PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs).
-
-```yaml
-kind: PersistentVolumeClaim
-apiVersion: v1
-metadata:
-  name: shared-cache
-spec:
-  accessModes:
-  - ReadWriteMany # Allow many nodes to access shared-cache simultaneously.
-  resources:
-    requests:
-      storage: 1Gi
-```
-
-Before v1.22, Kubernetes offered three access modes for PVs and PVCs:
-
-- ReadWriteOnce – the volume can be mounted as read-write by a single node
-- ReadOnlyMany – the volume can be mounted read-only by many nodes
-- ReadWriteMany – the volume can be mounted as read-write by many nodes
-
-These access modes are enforced by Kubernetes components like the `kube-controller-manager` and `kubelet` to ensure only certain pods are allowed to access a given PersistentVolume.
-
-## What is this new access mode and how does it work?
-
-Kubernetes v1.22 introduced a fourth access mode for PVs and PVCs, that you can use for CSI volumes:
-
-- ReadWriteOncePod – the volume can be mounted as read-write by a single pod
-
-If you create a pod with a PVC that uses the ReadWriteOncePod access mode, Kubernetes ensures that pod is the only pod across your whole cluster that can read that PVC or write to it.
-
-If you create another pod that references the same PVC with this access mode, the pod will fail to start because the PVC is already in use by another pod.
-For example:
-
-```
-Events:
-  Type     Reason            Age   From               Message
-  ----     ------            ----  ----               -------
-  Warning  FailedScheduling  1s    default-scheduler  0/1 nodes are available: 1 node has pod using PersistentVolumeClaim with the same name and ReadWriteOncePod access mode.
-```
-
-### How is this different than the ReadWriteOnce access mode?
-
-The ReadWriteOnce access mode restricts volume access to a single *node*, which means it is possible for multiple pods on the same node to read from and write to the same volume.
-This could potentially be a major problem for some applications, especially if they require at most one writer for data safety guarantees.
-
-With ReadWriteOncePod these issues go away.
-Set the access mode on your PVC, and Kubernetes guarantees that only a single pod has access.
-
-## How do I use it?
-
-The ReadWriteOncePod access mode is in alpha for Kubernetes v1.22 and is only supported for CSI volumes.
-As a first step you need to enable the ReadWriteOncePod [feature gate](/docs/reference/command-line-tools-reference/feature-gates) for `kube-apiserver`, `kube-scheduler`, and `kubelet`.
-You can enable the feature by setting command line arguments:
-
-```
---feature-gates="...,ReadWriteOncePod=true"
-```
-
-You also need to update the following CSI sidecars to these versions or greater:
-
-- [csi-provisioner:v3.0.0+](https://github.com/kubernetes-csi/external-provisioner/releases/tag/v3.0.0)
-- [csi-attacher:v3.3.0+](https://github.com/kubernetes-csi/external-attacher/releases/tag/v3.3.0)
-- [csi-resizer:v1.3.0+](https://github.com/kubernetes-csi/external-resizer/releases/tag/v1.3.0)
-
-### Creating a PersistentVolumeClaim
-
-In order to use the ReadWriteOncePod access mode for your PVs and PVCs, you will need to create a new PVC with the access mode:
-
-```yaml
-kind: PersistentVolumeClaim
-apiVersion: v1
-metadata:
-  name: single-writer-only
-spec:
-  accessModes:
-  - ReadWriteOncePod # Allow only a single pod to access single-writer-only.
-  resources:
-    requests:
-      storage: 1Gi
-```
-
-If your storage plugin supports [dynamic provisioning](/docs/concepts/storage/dynamic-provisioning/), new PersistentVolumes will be created with the ReadWriteOncePod access mode applied.
-
-#### Migrating existing PersistentVolumes
-
-If you have existing PersistentVolumes, they can be migrated to use ReadWriteOncePod.
-
-In this example, we already have a "cat-pictures-pvc" PersistentVolumeClaim that is bound to a "cat-pictures-pv" PersistentVolume, and a "cat-pictures-writer" Deployment that uses this PersistentVolumeClaim.
-
-As a first step, you need to edit your PersistentVolume's `spec.persistentVolumeReclaimPolicy` and set it to `Retain`.
-This ensures your PersistentVolume will not be deleted when we delete the corresponding PersistentVolumeClaim:
-
-```shell
-kubectl patch pv cat-pictures-pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
-```
-
-Next you need to stop any workloads that are using the PersistentVolumeClaim bound to the PersistentVolume you want to migrate, and then delete the PersistentVolumeClaim.
-
-Once that is done, you need to clear your PersistentVolume's `spec.claimRef.uid` to ensure PersistentVolumeClaims can bind to it upon recreation:
-
-```shell
-kubectl scale --replicas=0 deployment cat-pictures-writer
-kubectl delete pvc cat-pictures-pvc
-kubectl patch pv cat-pictures-pv -p '{"spec":{"claimRef":{"uid":""}}}'
-```
-
-After that you need to replace the PersistentVolume's access modes with ReadWriteOncePod:
-
-```shell
-kubectl patch pv cat-pictures-pv -p '{"spec":{"accessModes":["ReadWriteOncePod"]}}'
-```
-
-{{< note >}}
-The ReadWriteOncePod access mode cannot be combined with other access modes.
-Make sure ReadWriteOncePod is the only access mode on the PersistentVolume when updating, otherwise the request will fail.
-{{< /note >}}
-
-Next you need to modify your PersistentVolumeClaim to set ReadWriteOncePod as the only access mode.
-You should also set your PersistentVolumeClaim's `spec.volumeName` to the name of your PersistentVolume.
-
-Once this is done, you can recreate your PersistentVolumeClaim and start up your workloads:
-
-```shell
-# IMPORTANT: Make sure to edit your PVC in cat-pictures-pvc.yaml before applying. You need to:
-# - Set ReadWriteOncePod as the only access mode
-# - Set spec.volumeName to "cat-pictures-pv"
-
-kubectl apply -f cat-pictures-pvc.yaml
-kubectl apply -f cat-pictures-writer-deployment.yaml
-```
-
-Lastly you may edit your PersistentVolume's `spec.persistentVolumeReclaimPolicy` and set to it back to `Delete` if you previously changed it.
-
-```shell
-kubectl patch pv cat-pictures-pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}'
-```
-
-You can read [Configure a Pod to Use a PersistentVolume for Storage](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/) for more details on working with PersistentVolumes and PersistentVolumeClaims.
-
-## What volume plugins support this?
-
-The only volume plugins that support this are CSI drivers.
-SIG Storage does not plan to support this for in-tree plugins because they are being deprecated as part of [CSI migration](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#what-is-the-timeline-status).
-Support may be considered for beta for users that prefer to use the legacy in-tree volume APIs with CSI migration enabled.
-
-## As a storage vendor, how do I add support for this access mode to my CSI driver?
-
-The ReadWriteOncePod access mode will work out of the box without any required updates to CSI drivers, but [does require updates to CSI sidecars](#update-your-csi-sidecars).
-With that being said, if you would like to stay up to date with the latest changes to the CSI specification (v1.5.0+), read on.
-
-Two new access modes were introduced to the CSI specification in order to disambiguate the legacy [`SINGLE_NODE_WRITER`](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L418-L420) access mode.
-They are [`SINGLE_NODE_SINGLE_WRITER` and `SINGLE_NODE_MULTI_WRITER`](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L437-L447).
-In order to communicate to sidecars (like the [external-provisioner](https://github.com/kubernetes-csi/external-provisioner)) that your driver understands and accepts these two new CSI access modes, your driver will also need to advertise the `SINGLE_NODE_MULTI_WRITER` capability for the [controller service](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L1073-L1081) and [node service](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L1515-L1524).
-
-If you'd like to read up on the motivation for these access modes and capability bits, you can also read the [CSI Specification Changes, Volume Capabilities](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/2485-read-write-once-pod-pv-access-mode/README.md#csi-specification-changes-volume-capabilities) section of KEP-2485 (ReadWriteOncePod PersistentVolume Access Mode).
-
-### Update your CSI driver to use the new interface
-
-As a first step you will need to update your driver's `container-storage-interface` dependency to v1.5.0+, which contains support for these new access modes and capabilities.
-
-### Accept new CSI access modes
-
-If your CSI driver contains logic for validating CSI access modes for requests , it may need updating.
-If it currently accepts `SINGLE_NODE_WRITER`, it should be updated to also accept `SINGLE_NODE_SINGLE_WRITER` and `SINGLE_NODE_MULTI_WRITER`.
-
-Using the [GCP PD CSI driver validation logic](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/blob/v1.2.2/pkg/gce-pd-csi-driver/utils.go#L116-L130) as an example, here is how it can be extended:
-
-```diff
-diff --git a/pkg/gce-pd-csi-driver/utils.go b/pkg/gce-pd-csi-driver/utils.go
-index 281242c..b6c5229 100644
---- a/pkg/gce-pd-csi-driver/utils.go
-+++ b/pkg/gce-pd-csi-driver/utils.go
-@@ -123,6 +123,8 @@ func validateAccessMode(am *csi.VolumeCapability_AccessMode) error {
-        case csi.VolumeCapability_AccessMode_SINGLE_NODE_READER_ONLY:
-        case csi.VolumeCapability_AccessMode_MULTI_NODE_READER_ONLY:
-        case csi.VolumeCapability_AccessMode_MULTI_NODE_MULTI_WRITER:
-+       case csi.VolumeCapability_AccessMode_SINGLE_NODE_SINGLE_WRITER:
-+       case csi.VolumeCapability_AccessMode_SINGLE_NODE_MULTI_WRITER:
-        default:
-                return fmt.Errorf("%v access mode is not supported for for PD", am.GetMode())
-        }
-```
-
-### Advertise new CSI controller and node service capabilities
-
-Your CSI driver will also need to return the new `SINGLE_NODE_MULTI_WRITER` capability as part of the `ControllerGetCapabilities` and `NodeGetCapabilities` RPCs.
-
-Using the [GCP PD CSI driver capability advertisement logic](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/blob/v1.2.2/pkg/gce-pd-csi-driver/gce-pd-driver.go#L54-L77) as an example, here is how it can be extended:
-
-```diff
-diff --git a/pkg/gce-pd-csi-driver/gce-pd-driver.go b/pkg/gce-pd-csi-driver/gce-pd-driver.go
-index 45903f3..0d7ea26 100644
---- a/pkg/gce-pd-csi-driver/gce-pd-driver.go
-+++ b/pkg/gce-pd-csi-driver/gce-pd-driver.go
-@@ -56,6 +56,8 @@ func (gceDriver *GCEDriver) SetupGCEDriver(name, vendorVersion string, extraVolu
-                csi.VolumeCapability_AccessMode_SINGLE_NODE_WRITER,
-                csi.VolumeCapability_AccessMode_MULTI_NODE_READER_ONLY,
-                csi.VolumeCapability_AccessMode_MULTI_NODE_MULTI_WRITER,
-+               csi.VolumeCapability_AccessMode_SINGLE_NODE_SINGLE_WRITER,
-+               csi.VolumeCapability_AccessMode_SINGLE_NODE_MULTI_WRITER,
-        }
-        gceDriver.AddVolumeCapabilityAccessModes(vcam)
-        csc := []csi.ControllerServiceCapability_RPC_Type{
-@@ -67,12 +69,14 @@ func (gceDriver *GCEDriver) SetupGCEDriver(name, vendorVersion string, extraVolu
-                csi.ControllerServiceCapability_RPC_EXPAND_VOLUME,
-                csi.ControllerServiceCapability_RPC_LIST_VOLUMES,
-                csi.ControllerServiceCapability_RPC_LIST_VOLUMES_PUBLISHED_NODES,
-+               csi.ControllerServiceCapability_RPC_SINGLE_NODE_MULTI_WRITER,
-        }
-        gceDriver.AddControllerServiceCapabilities(csc)
-        ns := []csi.NodeServiceCapability_RPC_Type{
-                csi.NodeServiceCapability_RPC_STAGE_UNSTAGE_VOLUME,
-                csi.NodeServiceCapability_RPC_EXPAND_VOLUME,
-                csi.NodeServiceCapability_RPC_GET_VOLUME_STATS,
-+               csi.NodeServiceCapability_RPC_SINGLE_NODE_MULTI_WRITER,
-        }
-        gceDriver.AddNodeServiceCapabilities(ns)
-```
-
-### Implement `NodePublishVolume` behavior
-
-The CSI spec outlines expected behavior for the `NodePublishVolume` RPC when called more than once for the same volume but with different arguments (like the target path).
-Please refer to [the second table in the NodePublishVolume section of the CSI spec](https://github.com/container-storage-interface/spec/blob/v1.5.0/spec.md#nodepublishvolume) for more details on expected behavior when implementing in your driver.
-
-### Update your CSI sidecars
-
-When deploying your CSI drivers, you must update the following CSI sidecars to versions that depend on CSI spec v1.5.0+ and the Kubernetes v1.22 API.
-The minimum required versions are:
-
-- [csi-provisioner:v3.0.0+](https://github.com/kubernetes-csi/external-provisioner/releases/tag/v3.0.0)
-- [csi-attacher:v3.3.0+](https://github.com/kubernetes-csi/external-attacher/releases/tag/v3.3.0)
-- [csi-resizer:v1.3.0+](https://github.com/kubernetes-csi/external-resizer/releases/tag/v1.3.0)
-
-## What’s next?
-
-As part of the beta graduation for this feature, SIG Storage plans to update the Kubenetes scheduler to support pod preemption in relation to ReadWriteOncePod storage.
-This means if two pods request a PersistentVolumeClaim with ReadWriteOncePod, the pod with highest priority will gain access to the PersistentVolumeClaim and any pod with lower priority will be preempted from the node and be unable to access the PersistentVolumeClaim.
-
-## How can I learn more?
-
-Please see [KEP-2485](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/2485-read-write-once-pod-pv-access-mode/README.md) for more details on the ReadWriteOncePod access mode and motivations for CSI spec changes.
-
-## How do I get involved?
-
-The [Kubernetes #csi Slack channel](https://kubernetes.slack.com/messages/csi) and any of the [standard SIG Storage communication channels](https://github.com/kubernetes/community/blob/master/sig-storage/README.md#contact) are great mediums to reach out to the SIG Storage and the CSI teams.
-
-Special thanks to the following people for their insightful reviews and design considerations:
-
-* Abdullah Gharaibeh (ahg-g)
-* Aldo Culquicondor (alculquicondor)
-* Ben Swartzlander (bswartz)
-* Deep Debroy (ddebroy)
-* Hemant Kumar (gnufied)
-* Humble Devassy Chirammal (humblec)
-* James DeFelice (jdef)
-* Jan Šafránek (jsafrane)
-* Jing Xu (jingxu97)
-* Jordan Liggitt (liggitt)
-* Michelle Au (msau42)
-* Saad Ali (saad-ali)
-* Tim Hockin (thockin)
-* Xing Yang (xing-yang)
-
-If you’re interested in getting involved with the design and development of CSI or any part of the Kubernetes storage system, join the [Kubernetes Storage Special Interest Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG).
-We’re rapidly growing and always welcome new contributors.

content/en/blog/_posts/2021-09-27-SIG-Node-Spotlight/index.md

@@ -1,72 +0,0 @@
----
-layout: blog
-title: "Spotlight on SIG Node"
-date: 2021-09-27
-slug: sig-node-spotlight-2021
----
-
-**Author:** Dewan Ahmed, Red Hat
-
-## Introduction
-
-In Kubernetes, a _Node_ is a representation of a single machine in your cluster. [SIG Node](https://github.com/kubernetes/community/tree/master/sig-node) owns that very important Node component and supports various subprojects such as Kubelet, Container Runtime Interface (CRI) and more to support how the pods and host resources interact. In this blog, we have summarized our conversation with [Elana Hashman (EH)](https://twitter.com/ehashdn) & [Sergey Kanzhelev (SK)](https://twitter.com/SergeyKanzhelev), who walk us through the various aspects of being a part of the SIG and share some insights about how others can get involved.
-
-## A summary of our conversation
-
-### Could you tell us a little about what SIG Node does?
-
-SK: SIG Node is a vertical SIG responsible for the components that support the controlled interactions between the pods and host resources. We manage the lifecycle of pods that are scheduled to a node. This SIG's focus is to enable a broad set of workload types, including workloads with hardware specific or performance sensitive requirements. All while maintaining isolation boundaries between pods on a node, as well as the pod and the host. This SIG maintains quite a few components and has many external dependencies (like container runtimes or operating system features), which makes the complexity we deal with huge. We tame the complexity and aim to continuously improve node reliability.
-
-### "SIG Node is a vertical SIG" could you explain a bit more?
-
-EH: There are two kinds of SIGs: horizontal and vertical. Horizontal SIGs are concerned with a particular function of every component in Kubernetes: for example, SIG Security considers security aspects of every component in Kubernetes, or SIG Instrumentation looks at the logs, metrics, traces and events of every component in Kubernetes. Such SIGs don't tend to own a lot of code.
-
-Vertical SIGs, on the other hand, own a single component, and are responsible for approving and merging patches to that code base. SIG Node owns the "Node" vertical, pertaining to the kubelet and its lifecycle. This includes the code for the kubelet itself, as well as the node controller, the container runtime interface, and related subprojects like the node problem detector. 
-
-### How did the CI subproject start? Is this specific to SIG Node and how does it help the SIG?
-
-SK: The subproject started as a follow up after one of the releases was blocked by numerous test failures of critical tests. These tests haven’t started falling all at once, rather continuous lack of attention led to slow degradation of tests quality. SIG Node was always prioritizing quality and reliability, and forming of the subproject was a way to highlight this priority.
-
-### As the 3rd largest SIG in terms of number of issues and PRs, how does your SIG juggle so much work?
-
-EH: It helps to be organized. When I increased my contributions to the SIG in January of 2021, I found myself overwhelmed by the volume of pull requests and issues and wasn't sure where to start. We were already tracking test-related issues and pull requests on the CI subproject board, but that was missing a lot of our bugfixes and feature work. So I began putting together a triage board for the rest of our pull requests, which allowed me to sort each one by status and what actions to take, and documented its use for other contributors. We closed or merged over 500 issues and pull requests tracked by our two boards in each of the past two releases. The Kubernetes devstats showed that we have significantly increased our velocity as a result.
-
-In June, we ran our first bug scrub event to work through the backlog of issues filed against SIG Node, ensuring they were properly categorized. We closed over 130 issues over the course of this 48 hour global event, but as of writing we still have 333 open issues. 
-
-### Why should new and existing contributors consider joining SIG Node?
-
-SK: Being a SIG Node contributor gives you skills and recognition that are rewarding and useful. Understanding under the hood of a kubelet helps architecting better apps, tune and optimize those apps, and gives leg up in issues troubleshooting. If you are a new contributor, SIG Node gives you the foundational knowledge that is key to understanding why other Kubernetes components are designed the way they are. Existing contributors may benefit as many features will require SIG Node changes one way or another. So being a SIG Node contributor helps building features in other SIGs faster.
-
-SIG Node maintains numerous components, many of which have dependency on external projects or OS features. This makes the onboarding process quite lengthy and demanding. But if you are up for a challenge, there is always a place for you, and a group of people to support. 
-
-### What do you do to help new contributors get started?
-
-EH: Getting started in SIG Node can be intimidating, since there is so much work to be done, our SIG meetings are very large, and it can be hard to find a place to start.
-
-I always encourage new contributors to work on things that they have some investment in already. In SIG Node, that might mean volunteering to help fix a bug that you have personally been affected by, or helping to triage bugs you care about by priority.
-
-To come up to speed on any open source code base, there are two strategies you can take: start by exploring a particular issue deeply, and follow that to expand the edges of your knowledge as needed, or briefly review as many issues and change requests as you possibly can to get a higher level picture of how the component works. Ultimately, you will need to do both if you want to become a Node reviewer or approver.
-
-[Davanum Srinivas](https://twitter.com/dims) and I each ran a cohort of group mentoring to help teach new contributors the skills to become Node reviewers, and if there's interest we can work to find a mentor to run another session. I also encourage new contributors to attend our Node CI Subproject meeting: it's a smaller audience and we don't record the triage sessions, so it can be a less intimidating way to get started with the SIG. 
-
-### Are there any particular skills you’d like to recruit for? What skills are contributors to SIG Usability likely to learn?
-
-SK: SIG Node works on many workstreams in very different areas. All of these areas are on system level. For the typical code contributions you need to have a passion for building and utilizing low level APIs and writing performant and reliable components. Being a contributor you will learn how to debug and troubleshoot, profile, and monitor these components, as well as user workload that is run by these components. Often, with the limited to no access to Nodes, as they are running production workloads.
-
-The other way of contribution is to help document SIG node features. This type of contribution requires a deep understanding of features, and ability to explain them in simple terms.
-
-Finally, we are always looking for feedback on how best to run your workload. Come and  explain specifics of it, and what features in SIG Node components may help to run it better. 
-
-### What are you getting positive feedback on, and what’s coming up next for SIG Node?
-
-EH: Over the past year SIG Node has adopted some new processes to help manage our feature development and Kubernetes enhancement proposals, and other SIGs have looked to us for inspiration in managing large workloads. I hope that this is an area we can continue to provide leadership in and further iterate on.
-
-We have a great balance of new features and deprecations in flight right now. Deprecations of unused or difficult to maintain features help us keep technical debt and maintenance load under control, and examples include the dockershim and DynamicKubeletConfiguration deprecations. New features will unlock additional functionality in end users' clusters, and include exciting features like support for cgroups v2, swap memory, graceful node shutdowns, and device management policies.
-
-### Any closing thoughts/resources you’d like to share?
-
-SK/EH: It takes time and effort to get to any open source community. SIG Node may overwhelm you at first with the number of participants, volume of work, and project scope. But it is totally worth it. Join our welcoming community! [SIG Node GitHub Repo](https://github.com/kubernetes/community/tree/master/sig-node) contains many useful resources including Slack, mailing list and other contact info. 
-
-## Wrap Up
-
-SIG Node hosted a [KubeCon + CloudNativeCon Europe 2021 talk](https://www.youtube.com/watch?v=z5aY4e2RENA) with an intro and deep dive to their awesome SIG. Join the SIG's meetings to find out about the most recent research results, what the plans are for the forthcoming year, and how to get involved in the upstream Node team as a contributor!

content/en/blog/_posts/2021-09-29-data-duplication-in-data-heavy-k8s-env.md

@@ -1,243 +0,0 @@
----
-layout: blog
-title: "How to Handle Data Duplication in Data-Heavy Kubernetes Environments"
-date: 2021-09-29
-slug: how-to-handle-data-duplication-in-data-heavy-kubernetes-environments 
----
-
-**Authors:**
-Augustinas Stirbis (CAST AI)
-
-## Why Duplicate Data?
-
-It’s convenient to create a copy of your application with a copy of its state for each team. 
-For example, you might want a separate database copy to test some significant schema changes 
-or develop other disruptive operations like bulk insert/delete/update...
-
-**Duplicating data takes a lot of time.** That’s because you need first to download 
-all the data from a source block storage provider to compute and then send 
-it back to a storage provider again. There’s a lot of network traffic and CPU/RAM used in this process.
-Hardware acceleration by offloading certain expensive operations to dedicated hardware is 
-**always a huge performance boost**. It reduces the time required to complete an operation by orders 
-of magnitude.
-
-## Volume Snapshots to the rescue
-
-Kubernetes introduced [VolumeSnapshots](/docs/concepts/storage/volume-snapshots/) as alpha in 1.12,
-beta in 1.17, and the Generally Available version in 1.20. 
-VolumeSnapshots use specialized APIs from storage providers to duplicate volume of data.
-
-Since data is already in the same storage device (array of devices), duplicating data is usually 
-a metadata operation for storage providers with local snapshots (majority of on-premise storage providers).
-All you need to do is point a new disk to an immutable snapshot and only 
-save deltas (or let it do a full-disk copy). As an operation that is inside the storage back-end,
-it’s much quicker and usually doesn’t involve sending traffic over the network.
-Public Clouds storage providers under the hood work a bit differently. They save snapshots
-to Object Storage and then copy back from Object storage to Block storage when "duplicating" disk.
-Technically there is a lot of Compute and network resources spent on Cloud providers side,
-but from Kubernetes user perspective VolumeSnapshots work the same way whether is it local or
-remote snapshot storage provider and no Compute and Network resources are involved in this operation.
-
-## Sounds like we have our solution, right?
-
-Actually, VolumeSnapshots are namespaced, and Kubernetes protects namespaced data from 
-being shared between tenants (Namespaces). This Kubernetes limitation is a conscious design 
-decision so that a Pod running in a different namespace can’t mount another application’s
-[PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC).
-
-One way around it would be to create multiple volumes with duplicate data in one namespace.
-However, you could easily reference the wrong copy.
-
-So the idea is to separate teams/initiatives by namespaces to avoid that and generally 
-limit access to the production namespace.
-
-## Solution? Creating a Golden Snapshot externally
-
-Another way around this design limitation is to create Snapshot externally (not through Kubernetes).
-This is also called pre-provisioning a snapshot manually. Next, I will import it 
-as a multi-tenant golden snapshot that can be used for many namespaces. Below illustration will be 
-for AWS EBS (Elastic Block Storage) and GCE PD (Persistent Disk) services.
-
-### High-level plan for preparing the Golden Snapshot
-
-1. Identify Disk (EBS/Persistent Disk) that you want to clone with data in the cloud provider
-2. Make a Disk Snapshot (in cloud provider console)
-3. Get Disk Snapshot ID
-
-### High-level plan for cloning data for each team
-
-1. Create Namespace “sandbox01”
-2. Import Disk Snapshot (ID) as VolumeSnapshotContent to Kubernetes
-3. Create VolumeSnapshot in the Namespace "sandbox01" mapped to VolumeSnapshotContent
-4. Create the PersistentVolumeClaim from VolumeSnapshot
-5. Install Deployment or StatefulSet with PVC
-
-## Step 1: Identify Disk
-
-First, you need to identify your golden source. In my case, it’s a PostgreSQL database
-on PersistentVolumeClaim “postgres-pv-claim” in the “production” namespace.
-
-```terminal
-kubectl -n <namespace> get pvc <pvc-name> -o jsonpath='{.spec.volumeName}'
-```
-
-The output will look similar to:
-```
-pvc-3096b3ba-38b6-4fd1-a42f-ec99176ed0d90
-```
-
-## Step 2: Prepare your golden source
-
-You need to do this once or every time you want to refresh your golden data.
-
-### Make a Disk Snapshot
-
-Go to AWS EC2 or GCP Compute Engine console and search for an EBS volume
-(on AWS) or Persistent Disk (on GCP), that has a label matching the last output.
-In this case I saw: `pvc-3096b3ba-38b6-4fd1-a42f-ec99176ed0d9`.
-
-Click on Create snapshot and give it a name. You can do it in Console manually,
-in AWS CloudShell / Google Cloud Shell, or in the terminal. To create a snapshot in the
-terminal you must have the AWS CLI tool (`aws`) or Google's CLI (`gcloud`)
-installed and configured.
-
-Here’s the command to create snapshot on GCP:
-
-```terminal
-gcloud compute disks snapshot <cloud-disk-id> --project=<gcp-project-id> --snapshot-names=<set-new-snapshot-name> --zone=<availability-zone> --storage-location=<region>
-```
-{{< figure src="/images/blog/2021-09-07-data-duplication-in-data-heavy-k8s-env/create-volume-snapshot-gcp.png" alt="Screenshot of a terminal showing volume snapshot creation on GCP" title="GCP snapshot creation" >}}
-
-
-GCP identifies the disk by its PVC name, so it’s direct mapping. In AWS, you need to 
-find volume by the CSIVolumeName AWS tag with PVC name value first that will be used for snapshot creation.
-
-{{< figure src="/images/blog/2021-09-07-data-duplication-in-data-heavy-k8s-env/identify-volume-aws.png" alt="Screenshot of AWS web console, showing EBS volume identification" title="Identify disk ID on AWS" >}}
-
-Mark done Volume (volume-id) ```vol-00c7ecd873c6fb3ec``` and ether create EBS snapshot in AWS Console, or use ```aws cli```.
-
-```terminal
-aws ec2 create-snapshot --volume-id '<volume-id>' --description '<set-new-snapshot-name>' --tag-specifications 'ResourceType=snapshot'
-```
-
-## Step 3: Get your Disk Snapshot ID
-
-In AWS, the command above will output something similar to:
-```terminal
-"SnapshotId": "snap-09ed24a70bc19bbe4"
-```
-
-If you’re using the GCP cloud, you can get the snapshot ID from the gcloud command by querying for the snapshot’s given name:
-
-```terminal
-gcloud compute snapshots --project=<gcp-project-id> describe <new-snapshot-name> | grep id:
-```
-You should get similar output to:
-```
-id: 6645363163809389170
-```
-
-## Step 4: Create a development environment for each team
-
-Now I have my Golden Snapshot, which is immutable data. Each team will get a copy 
-of this data, and team members can modify it as they see fit, given that a new EBS/persistent 
-disk will be created for each team.
-
-Below I will define a manifest for each namespace. To save time, you can replace
-the namespace name (such as changing “sandbox01” → “sandbox42”) using tools
-such as `sed` or `yq`, with Kubernetes-aware templating tools like
-[Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/),
-or using variable substitution in a CI/CD pipeline.
-
-Here's an example manifest:
-
-```yaml
----
-apiVersion: snapshot.storage.k8s.io/v1
-kind: VolumeSnapshotContent
-metadata:
- name: postgresql-orders-db-sandbox01
- namespace: sandbox01
-spec:
- deletionPolicy: Retain
- driver: pd.csi.storage.gke.io
- source:
-   snapshotHandle: 'gcp/projects/staging-eu-castai-vt5hy2/global/snapshots/6645363163809389170'
- volumeSnapshotRef:
-   kind: VolumeSnapshot
-   name: postgresql-orders-db-snap
-   namespace: sandbox01
----
-apiVersion: snapshot.storage.k8s.io/v1
-kind: VolumeSnapshot
-metadata:
- name: postgresql-orders-db-snap
- namespace: sandbox01
-spec:
- source:
-   volumeSnapshotContentName: postgresql-orders-db-sandbox01
-```
-
-In Kubernetes, VolumeSnapshotContent (VSC) objects are not namespaced.
-However, I need a separate VSC for each different namespace to use, so the
-`metadata.name` of each VSC must also be different. To make that straightfoward,
-I used the target namespace as part of the name.
-
-Now it’s time to replace the driver field with the CSI (Container Storage Interface) driver
-installed in your K8s cluster. Major cloud providers have CSI driver for block storage that
-support VolumeSnapshots but quite often CSI drivers are not installed by default, consult
-with your Kubernetes provider. 
-
-That manifest above defines a VSC that works on GCP.
-On AWS, driver and SnashotHandle values might look like:
-
-```YAML
-  driver: ebs.csi.aws.com
-  source:
-    snapshotHandle: "snap-07ff83d328c981c98"
-```
-
-At this point, I need to use the *Retain* policy, so that the CSI driver doesn’t try to
-delete my manually created EBS disk snapshot.
-
-For GCP, you will have to build this string by hand - add a full project ID and snapshot ID.
-For AWS, it’s just a plain snapshot ID.
-
-VSC also requires specifying which VolumeSnapshot (VS) will use it, so VSC and VS are
-referencing each other.
-
-Now I can create PersistentVolumeClaim from VS above. It’s important to set this first:
-
-
-```yaml
----
-apiVersion: v1
-kind: PersistentVolumeClaim
-metadata:
- name: postgres-pv-claim
- namespace: sandbox01
-spec:
- dataSource:
-   kind: VolumeSnapshot
-   name: postgresql-orders-db-snap
-   apiGroup: snapshot.storage.k8s.io
- accessModes:
-   - ReadWriteOnce
- resources:
-   requests:
-     storage: 21Gi
-```
-
-If default StorageClass has [WaitForFirstConsumer](https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode) policy,
-then the actual Cloud Disk will be created from the Golden Snapshot only when some Pod bounds that PVC.
-
-Now I assign that PVC to my Pod (in my case, it’s Postgresql) as I would with any other PVC.
-
-```terminal
-kubectl -n <namespace> get volumesnapshotContent,volumesnapshot,pvc,pod
-```
-
-Both VS and VSC should be *READYTOUSE* true, PVC bound, and the Pod (from Deployment or StatefulSet) running.
-
-**To keep on using data from my Golden Snapshot, I just need to repeat this for the
-next namespace and voilà! No need to waste time and compute resources on the duplication process.**

content/en/blog/_posts/2021-10-05-nsa-cisa-hardening.md

@@ -1,417 +0,0 @@
----
-layout: blog
-title: A Closer Look at NSA/CISA Kubernetes Hardening Guidance
-date: 2021-10-05
-slug: nsa-cisa-kubernetes-hardening-guidance
----
-
-**Authors:** Jim Angel (Google), Pushkar Joglekar (VMware), and Savitha
-Raghunathan (Red Hat)
-
-{{% alert title="Disclaimer" %}}
-The open source tools listed in this article are to serve as examples only 
-and are in no way a direct recommendation from the Kubernetes community or authors.
-{{% /alert %}}
-
-## Background
-
-USA's National Security Agency (NSA) and the Cybersecurity and Infrastructure
-Security Agency (CISA)
-released, "[Kubernetes Hardening Guidance](https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF)"
-on August 3rd, 2021. The guidance details threats to Kubernetes environments
-and provides secure configuration guidance to minimize risk.
-
-The following sections of this blog correlate to the sections in the NSA/CISA guidance. 
-Any missing sections are skipped because of limited opportunities to add 
-anything new to the existing content. 
-
-_Note_: This blog post is not a substitute for reading the guide. Reading the published 
-guidance is recommended before proceeding as the following content is 
-complementary.
-
-## Introduction and Threat Model
-
-Note that the threats identified as important by the NSA/CISA, or the intended audience of this guidance, may be different from the threats that other enterprise users of Kubernetes consider important. This section 
-is still useful for organizations that care about data, resource theft and 
-service unavailability.
-
-The guidance highlights the following three sources of compromises:
-
-- Supply chain risks
-- Malicious threat actors
-- Insider threats (administrators, users, or cloud service providers)
-
-The [threat model](https://en.wikipedia.org/wiki/Threat_model) tries to take a step back and review threats that not only
-exist within the boundary of a Kubernetes cluster but also include the underlying
-infrastructure and surrounding workloads that Kubernetes does not manage.
-
-For example, when a workload outside the cluster shares the same physical
-network, it has access to the kubelet and to control plane components: etcd, controller manager, scheduler and API
-server. Therefore, the guidance recommends having network level isolation
-separating Kubernetes clusters from other workloads that do not need connectivity
-to Kubernetes control plane nodes. Specifically, scheduler, controller-manager,
-etcd only need to be accessible to the API server. Any interactions with Kubernetes
-from outside the cluster can happen by providing access to API server port.
-
-List of ports and protocols for each of these components are
-defined in [Ports and Protocols](/docs/reference/ports-and-protocols/)
-within the Kubernetes documentation.
-
-> Special note: kube-scheduler and kube-controller-manager uses different ports than the ones mentioned in the guidance
-
-The [Threat modelling](https://cnsmap.netlify.app/threat-modelling) section
-from the CNCF [Cloud Native Security Whitepaper + Map](https://github.com/cncf/tag-security/tree/main/security-whitepaper)
-provides another perspective on approaching threat modelling Kubernetes, from a
-cloud native lens.
-
-## Kubernetes Pod security
-
-Kubernetes by default does not guarantee strict workload isolation between pods
-running in the same node in a cluster. However, the guidance provides several 
-techniques to enhance existing isolation and reduce the attack surface in case of a 
-compromise.
-
-### "Non-root" containers and "rootless" container engines
-
-Several best practices related to basic security principle of least privilege
-i.e. provide only the permissions are needed; no more, no less, are worth a
-second look.
-
-The guide recommends setting non-root user at build time instead of relying on
-setting `runAsUser` at runtime in your Pod spec. This is a good practice and provides
-some level of defense in depth. For example, if the container image is built with user `10001`
-and the Pod spec misses adding the `runAsuser` field in its `Deployment` object. In this
-case there are certain edge cases that are worth exploring for awareness:
-
-1. Pods can fail to start, if the user defined at build time is different from
-   the one defined in pod spec and some files are as a result inaccessible.
-2. Pods can end up sharing User IDs unintentionally. This can be problematic
-   even if the User IDs are non-zero in a situation where a container escape to
-   host file system is possible. Once the attacker has access to the host file
-   system, they get access to all the file resources that are owned by other
-   unrelated pods that share the same UID.
-3. Pods can end up sharing User IDs, with other node level processes not managed
-   by Kubernetes e.g. node level daemons for auditing, vulnerability scanning,
-   telemetry. The threat is similar to the one above where host file system
-   access can give attacker full access to these node level daemons without
-   needing to be root on the node.
-
-However, none of these cases will have as severe an impact as a container
-running as root being able to escape as a root user on the host, which can provide 
-an attacker with complete control of the worker node, further allowing lateral
-movement to other worker or control plane nodes.
-
-Kubernetes 1.22 introduced
-an [alpha feature](/docs/tasks/administer-cluster/kubelet-in-userns/)
-that specifically reduces the impact of such a control plane component running
-as root user to a non-root user through user namespaces.
-
-That ([alpha stage](/docs/reference/command-line-tools-reference/feature-gates/#feature-stages)) support for user namespaces / rootless mode is available with
-the following container runtimes:
-
-- [Docker Engine](https://docs.docker.com/engine/security/rootless/)
-- [Podman](https://developers.redhat.com/blog/2020/09/25/rootless-containers-with-podman-the-basics)
-
-Some distributions support running in rootless mode, like the following:
-
-- [kind](https://kind.sigs.k8s.io/docs/user/rootless/)
-- [k3s](https://rancher.com/docs/k3s/latest/en/advanced/#running-k3s-with-rootless-mode-experimental)
-- [Usernetes](https://github.com/rootless-containers/usernetes)
-
-### Immutable container filesystems
-
-The NSA/CISA Kubernetes Hardening Guidance highlights an often overlooked feature `readOnlyRootFileSystem`, with a
-working example in [Appendix B](https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF#page=42). This example limits execution and tampering of
-containers at runtime. Any read/write activity can then be limited to few
-directories by using `tmpfs` volume mounts.
-
-However, some applications that modify the container filesystem at runtime, like exploding a WAR or JAR file at container startup, 
-could face issues when enabling this feature. To avoid this issue, consider making minimal changes to the filesystem at runtime 
-when possible.
-
-### Building secure container images
-
-Kubernetes Hardening Guidance also recommends running a scanner at deploy time as an admission controller,
-to prevent vulnerable or misconfigured pods from running in the cluster.
-Theoretically, this sounds like a good approach but there are several caveats to
-consider before this can be implemented in practice:
-
-- Depending on network bandwidth, available resources and scanner of choice,
-  scanning for vulnerabilities for an image can take an indeterminate amount of
-  time. This could lead to slower or unpredictable pod start up times, which
-  could result in spikes of unavailability when apps are serving peak load.
-- If the policy that allows or denies pod startup is made using incorrect or
-  incomplete data it could result in several false positive or false negative
-  outcomes like the following:
-  - inside a container image, the `openssl` package is detected as vulnerable. However,
-    the application is written in Golang and uses the Go `crypto` package for TLS. Therefore, this vulnerability
-    is not in the code execution path and as such has minimal impact if it
-    remains unfixed.
-  - A vulnerability is detected in the `openssl` package for a Debian base image.
-    However, the upstream Debian community considers this as a Minor impact
-    vulnerability and as a result does not release a patch fix for this
-    vulnerability. The owner of this image is now stuck with a vulnerability that
-    cannot be fixed and a cluster that does not allow the image to run because
-    of predefined policy that does not take into account whether the fix for a
-    vulnerability is available or not
-  - A Golang app is built on top of a [distroless](https://github.com/GoogleContainerTools/distroless)
-    image, but it is compiled with a Golang version that uses a vulnerable [standard library](https://pkg.go.dev/std).
-    The scanner has
-    no visibility into golang version but only on OS level packages. So it 
-    allows the pod to run in the cluster in spite of the image containing an 
-    app binary built on vulnerable golang.
-
-To be clear, relying on vulnerability scanners is absolutely a good idea but
-policy definitions should be flexible enough to allow:
-
-- Creation of exception lists for images or vulnerabilities through labelling
-- Overriding the severity with a risk score based on impact of a vulnerability
-- Applying the same policies at build time to catch vulnerable images with
-  fixable vulnerabilities before they can be deployed into Kubernetes clusters
-
-Special considerations like offline vulnerability database fetch, may also be
-needed, if the clusters run in an air-gapped environment and the scanners
-require internet access to update the vulnerability database.
-
-### Pod Security Policies
-
-Since Kubernetes v1.21, the [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) 
-API and related features are [deprecated](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/),
-but some of the guidance in this section will still apply for the next few years, until cluster operators
-upgrade their clusters to newer Kubernetes versions.
-
-The Kubernetes project is working on a replacement for PodSecurityPolicy.
-Kubernetes v1.22 includes an alpha feature called [Pod Security Admission](/docs/concepts/security/pod-security-admission/)
-that is intended to allow enforcing a minimum level of isolation between pods.
-
-The built-in isolation levels for Pod Security Admission are derived
-from [Pod Security Standards](/docs/concepts/security/pod-security-standards/), which is a superset of all the components mentioned in Table I [page 10](https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF#page=17) of
-the guidance.
-
-Information about migrating from PodSecurityPolicy to the Pod Security
-Admission feature is available
-in
-[Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller](/docs/tasks/configure-pod-container/migrate-from-psp/).
-
-One important behavior mentioned in the guidance that remains the same between
-Pod Security Policy and its replacement is that enforcing either of them does
-not affect pods that are already running. With both PodSecurityPolicy and Pod Security Admission,
-the enforcement happens during the pod creation
-stage.
-
-### Hardening container engines
-
-Some container workloads are less trusted than others but may need to run in the
-same cluster. In those cases, running them on dedicated nodes that include
-hardened container runtimes that provide stricter pod isolation boundaries can
-act as a useful security control.
-
-Kubernetes supports
-an API called [RuntimeClass](/docs/concepts/containers/runtime-class/) that is
-stable / GA (and, therefore, enabled by default) stage as of Kubernetes v1.20.
-RuntimeClass allows you to ensure that Pods requiring strong isolation are scheduled onto
-nodes that can offer it.
-
-Some third-party projects that you can use in conjunction with RuntimeClass are:
-
-- [kata containers](https://github.com/kata-containers/kata-containers/blob/main/docs/how-to/how-to-use-k8s-with-cri-containerd-and-kata.md#create-runtime-class-for-kata-containers)
-- [gvisor](https://gvisor.dev/docs/user_guide/containerd/quick_start/)
-
-As discussed here and in the guidance, many features and tooling exist in and around
-Kubernetes that can enhance the isolation boundaries between
-pods. Based on relevant threats and risk posture, you should pick and choose
-between them, instead of trying to apply all the recommendations. Having said that, cluster
-level isolation i.e. running workloads in dedicated clusters, remains the strictest workload 
-isolation mechanism, in spite of improvements mentioned earlier here and in the guide.
-
-## Network Separation and Hardening
-
-Kubernetes Networking can be tricky and this section focuses on how to secure
-and harden the relevant configurations. The guide identifies the following as key
-takeaways: 
-- Using NetworkPolicies to create isolation between resources,
-- Securing the control plane
-- Encrypting traffic and sensitive data
-
-### Network Policies
-
-Network policies can be created with the help of network plugins. In order to
-make the creation and visualization easier for users, Cilium supports
-a [web GUI tool](https://editor.cilium.io). That web GUI lets you create Kubernetes
-NetworkPolicies (a generic API that nevertheless requires a compatible CNI plugin),
-and / or Cilium network policies (CiliumClusterwideNetworkPolicy and CiliumNetworkPolicy,
-which only work in clusters that use the Cilium CNI plugin).
-You can use these APIs to restrict network traffic between pods, and therefore minimize the
-attack vector.
-
-Another scenario that is worth exploring is the usage of external IPs. Some
-services, when misconfigured, can create random external IPs. An attacker can take
-advantage of this misconfiguration and easily intercept traffic. This vulnerability
-has been reported
-in [CVE-2020-8554](https://www.cvedetails.com/cve/CVE-2020-8554/).
-Using [externalip-webhook](https://github.com/kubernetes-sigs/externalip-webhook)
-can mitigate this vulnerability by preventing the services from using random
-external IPs. [externalip-webhook](https://github.com/kubernetes-sigs/externalip-webhook) 
-only allows creation of services that don't require external IPs or whose 
-external IPs are within the range specified by the administrator.
-
-> CVE-2020-8554 - Kubernetes API server in all versions allow an attacker
-> who is able to create a ClusterIP service and set the `spec.externalIPs` field,
-> to intercept traffic to that IP address. Additionally, an attacker who is able to
-> patch the `status` (which is considered a privileged operation and should not
-> typically be granted to users) of a LoadBalancer service can set the
-> `status.loadBalancer.ingress.ip` to similar effect.
-
-### Resource Policies
-
-In addition to configuring ResourceQuotas and limits, consider restricting how many process
-IDs (PIDs) a given Pod can use, and also to reserve some PIDs for node-level use to avoid
-resource exhaustion. More details to apply these limits can be
-found in [Process ID Limits And Reservations](/docs/concepts/policy/pid-limiting/).
-
-### Control Plane Hardening
-
-In the next section, the guide covers control plane hardening. It is worth
-noting that
-from [Kubernetes 1.20](https://github.com/kubernetes/kubernetes/issues/91506),
-insecure port from API server, has been removed.
-
-### Etcd
-
-As a general rule, the etcd server should be configured to only trust
-certificates assigned to the API server. It limits the attack surface and prevents a
-malicious attacker from gaining access to the cluster. It might be beneficial to
-use a separate CA for etcd, as it by default trusts all the certificates issued
-by the root CA.
-
-### Kubeconfig Files
-
-In addition to specifying the token and certificates directly, `.kubeconfig`
-supports dynamic retrieval of temporary tokens using auth provider plugins.
-Beware of the possibility of malicious
-shell [code execution](https://banzaicloud.com/blog/kubeconfig-security/) in a
-`kubeconfig` file. Once attackers gain access to the cluster, they can steal ssh
-keys/secrets or more.
-
-### Secrets
-Kubernetes [Secrets](/docs/concepts/configuration/secret/) is the native way of managing secrets as a Kubernetes
-API object. However, in some scenarios such as a desire to have a single source of truth for all app secrets, irrespective of whether they run on Kubernetes or not, secrets can be managed loosely coupled with 
-Kubernetes and consumed by pods through side-cars or init-containers with minimal usage of Kubernetes Secrets API. 
-
-[External secrets providers](https://github.com/external-secrets/kubernetes-external-secrets)
-and [csi-secrets-store](https://github.com/kubernetes-sigs/secrets-store-csi-driver)
-are some of these alternatives to Kubernetes Secrets
-
-## Log Auditing
-
-The NSA/CISA guidance stresses monitoring and alerting based on logs. The key points
-include logging at the host level, application level, and on the cloud. When
-running Kubernetes in production, it's important to understand who's
-responsible, and who's accountable, for each layer of logging.
-
-### Kubernetes API auditing
-
-One area that deserves more focus is what exactly should alert or be logged. The
-document outlines a sample policy in [Appendix L: Audit Policy](https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF#page=55) that logs all
-RequestResponse's including metadata and request / response bodies. While helpful for a demo, it may not be practical for production.
-
-Each organization needs to evaluate their
-own threat model and build an audit policy that complements or helps troubleshooting incident response. Think
-about how someone would attack your organization and what audit trail could identify it. Review more advanced options for tuning audit logs in the official [audit logging documentation](/docs/tasks/debug-application-cluster/audit/#audit-policy).
-It's crucial to tune your audit logs to only include events that meet your threat model. A minimal audit policy that logs everything at `metadata` level can also be a good starting point. 
-
-Audit logging configurations can also be tested with
-kind following these [instructions](https://kind.sigs.k8s.io/docs/user/auditing).
-
-### Streaming logs and auditing
-
-Logging is important for threat and anomaly detection. As the document outlines,
-it's a best practice to scan and alert on logs as close to real time as possible
-and to protect logs from tampering if a compromise occurs. It's important to
-reflect on the various levels of logging and identify the critical areas such as
-API endpoints.
-
-Kubernetes API audit logging can stream to a webhook and there's an example in [Appendix N: Webhook configuration](https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF#page=58). Using a webhook could be a method that
-stores logs off cluster and/or centralizes all audit logs. Once logs are
-centrally managed, look to enable alerting based on critical events. Also ensure
-you understand what the baseline is for normal activities.
-
-### Alert identification
-
-While the guide stressed the importance of notifications, there is not a blanket
-event list to alert from. The alerting requirements vary based on your own
-requirements and threat model. Examples include the following events:
-
-- Changes to the `securityContext` of a Pod
-- Updates to admission controller configs
-- Accessing certain files / URLs
-
-### Additional logging resources
-
-- [Seccomp Security Profiles and You: A Practical Guide - Duffie Cooley](https://www.youtube.com/watch?v=OPuu8wsu2Zc)
-- [TGI Kubernetes 119: Gatekeeper and OPA](https://www.youtube.com/watch?v=ZJgaGJm9NJE)
-- [Abusing The Lack of Kubernetes Auditing Policies](https://www.lacework.com/blog/hiding-in-plaintext-sight-abusing-the-lack-of-kubernetes-auditing-policies/)
-- [Enable seccomp for all workloads with a new v1.22 alpha feature](https://kubernetes.io/blog/2021/08/25/seccomp-default/)
-- [This Week in Cloud Native: Auditing / Pod Security](https://www.twitch.tv/videos/1147889860)
-
-## Upgrading and Application Security practices
-
-Kubernetes releases three times per year, so upgrade-related toil is a common problem for
-people running production clusters. In addition to this, operators must
-regularly upgrade the underlying node's operating system and running
-applications. This is a best practice to ensure continued support and to reduce
-the likelihood of bugs or vulnerabilities.
-
-Kubernetes supports the three most recent stable releases. While each Kubernetes
-release goes through a large number of tests before being published, some
-teams aren't comfortable running the latest stable release until some time has
-passed. No matter what version you're running, ensure that patch upgrades
-happen frequently or automatically. More information can be found in
-the [version skew](/releases/version-skew-policy/) policy
-pages.
-
-When thinking about how you'll manage node OS upgrades, consider ephemeral
-nodes. Having the ability to destroy and add nodes allows your team to respond
-quicker to node issues. In addition, having deployments that tolerate node
-instability (and a culture that encourages frequent deployments) allows for
-easier cluster upgrades.
-
-Additionally, it's worth reiterating from the guidance that periodic 
-vulnerability scans and penetration tests can be performed on the various system
-components to proactively look for insecure configurations and vulnerabilities.
-
-### Finding release & security information
-
-To find the most recent Kubernetes supported versions, refer to
-[https://k8s.io/releases](https://k8s.io/releases), which includes minor versions. It's good to stay up to date with
-your minor version patches.
-
-If you're running a managed Kubernetes offering, look for their release
-documentation and find their various security channels.
-
-Subscribe to
-the [Kubernetes Announce mailing list](https://groups.google.com/g/kubernetes-announce).
-The Kubernetes Announce mailing list is searchable for terms such
-as "[Security Advisories](https://groups.google.com/g/kubernetes-announce/search?q=%5BSecurity%20Advisory%5D)".
-You can set up alerts and email notifications as long as you know what key
-words to alert on.
-
-## Conclusion
-
-In summary, it is fantastic to see security practitioners sharing this
-level of detailed guidance in public. This guidance further highlights
-Kubernetes going mainstream and how securing Kubernetes clusters and the
-application containers running on Kubernetes continues to need attention and focus of
-practitioners. Only a few weeks after the guidance was published, an open source
-tool [kubescape](https://github.com/armosec/kubescape) to validate cluster
-against this guidance became available.
-
-This tool can be a great starting point to check the current state of your
-clusters, after which you can use the information in this blog post and in the guidance to assess 
-where improvements can be made.
-
-Finally, it is worth reiterating that not all controls in this guidance will
-make sense for all practitioners. The best way to know which controls matter is
-to rely on the threat model of your own Kubernetes environment.
-
-_A special shout out and thanks to Rory McCune (@raesene) for his inputs to this blog post_

content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md

@@ -1,142 +0,0 @@
----
-layout: blog
-title: "Introducing ClusterClass and Managed Topologies in Cluster API"
-date: 2021-10-08
-slug: capi-clusterclass-and-managed-topologies
----
-
-**Author:** Fabrizio Pandini (VMware)
-
-The [Cluster API community](https://cluster-api.sigs.k8s.io/) is happy to announce the implementation of *ClusterClass and Managed Topologies*, a new feature that will greatly simplify how you can provision, upgrade, and operate multiple Kubernetes clusters in a declarative way.
-
-## A little bit of context…
-
-Before getting into the details, let's take a step back and look at the history of Cluster API.
-
-The [Cluster API project](https://github.com/kubernetes-sigs/cluster-api/) started three years ago, and the first releases focused on extensibility and implementing a declarative API that allows a seamless experience across infrastructure providers. This was a success with many cloud providers: AWS, Azure, Digital Ocean, GCP, Metal3, vSphere and still counting.
-
-With extensibility addressed, the focus shifted to features, like automatic control plane and etcd management, health-based machine remediation, machine rollout strategies and more.
-
-Fast forwarding to 2021, with lots of companies using Cluster API to manage fleets of Kubernetes clusters running workloads in production, the community focused its effort on stabilization of both code, APIs, documentation, and on extensive test signals which inform Kubernetes releases.
-
-With solid foundations in place, and a vibrant and welcoming community that still continues to grow, it was time to plan another iteration on our UX for both new and advanced users.
-
-Enter ClusterClass and Managed Topologies, tada!
-
-## ClusterClass
-
-As the name suggests, ClusterClass and managed topologies are built in two parts.
-
-The idea behind ClusterClass is simple: define the shape of your cluster once, and reuse it many times, abstracting the complexities and the internals of a Kubernetes cluster away.
-
-![Defining a ClusterClass](/images/blog/2021-10-08-clusterclass-and-managed-topologies/clusterclass.svg)
-
-ClusterClass, at its heart, is a collection of Cluster and Machine templates. You can use it as a “stamp” that can be leveraged to create many clusters of a similar shape.
-
-```yaml
----
-apiVersion: cluster.x-k8s.io/v1beta1
-kind: ClusterClass
-metadata:
-  name: my-amazing-cluster-class
-spec:
-  controlPlane:
-    ref:
-      apiVersion: controlplane.cluster.x-k8s.io/v1beta1
-      kind: KubeadmControlPlaneTemplate
-      name: high-availability-control-plane
-    machineInfrastructure:
-      ref:
-        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
-        kind: DockerMachineTemplate
-        name: control-plane-machine
-  workers:
-    machineDeployments:
-      - class: type1-workers
-        template:
-          bootstrap:
-            ref:
-              apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
-              kind: KubeadmConfigTemplate
-              name: type1-bootstrap
-          infrastructure:
-            ref:
-              apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
-              kind: DockerMachineTemplate
-              name: type1-machine
-      - class: type2-workers
-        template:
-          bootstrap:
-            ref:
-              apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
-              kind: KubeadmConfigTemplate
-              name: type2-bootstrap
-          infrastructure:
-            ref:
-              kind: DockerMachineTemplate
-              apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
-              name: type2-machine
-  infrastructure:
-    ref:
-      apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
-      kind: DockerClusterTemplate
-      name: cluster-infrastructure
-
-```
-
-The possibilities are endless; you can get a default ClusterClass from the community, “off-the-shelf” classes from your vendor of choice, “certified” classes from the platform admin in your company, or even create custom ones for advanced scenarios.
-
-## Managed Topologies
-
-Managed Topologies let you put the power of ClusterClass into action.
-
-Given a ClusterClass, you can create many Clusters of a similar shape by providing a single resource, the Cluster.
-
-![Create a Cluster with ClusterClass](/images/blog/2021-10-08-clusterclass-and-managed-topologies/create-cluster.svg)
-
-Here is an example:
-
-```yaml
----
-apiVersion: cluster.x-k8s.io/v1beta1
- kind: Cluster
- metadata:
-   name: my-amazing-cluster
-   namespace: bar
- spec:
-   topology: # define a managed topology
-     class: my-amazing-cluster-class # use the ClusterClass mentioned earlier
-     version: v1.21.2
-     controlPlane:
-       replicas: 3
-     workers:
-       machineDeployments:
-       - class: type1-workers
-         name: big-pool-of-machines
-         replicas: 5
-       - class: type2-workers
-         name: small-pool-of-machines
-         replicas: 1
-```
-
-But there is more than simplified cluster creation. Now the Cluster acts as a single control point for your entire topology.
-
-All the power of Cluster API, extensibility, lifecycle automation, stability, all the features required for managing an enterprise grade Kubernetes cluster on the infrastructure provider of your choice are now at your fingertips: you can create your Cluster, add new machines, upgrade to the next Kubernetes version, and all from a single place.
-
-It is just as simple as it looks!
-
-## What’s next
-
-While the amazing Cluster API community is working hard to deliver the first version of ClusterClass and managed topologies later this year, we are already looking forward to what comes next for the project and its ecosystem.
-
-There are a lot of great ideas and opportunities ahead!
-
-We want to make managed topologies even more powerful and flexible, allowing users to dynamically change bits of a ClusterClass according to the specific needs of a Cluster; this will ensure the same simple and intuitive UX for solving complex problems like e.g. selecting machine image for a specific Kubernetes version and for a specific region of your infrastructure provider, or injecting proxy configurations in the entire Cluster, and so on.
-
-Stay tuned for what comes next, and if you have any questions, comments or suggestions:
-
-* Chat with us on the Kubernetes [Slack](http://slack.k8s.io/):[#cluster-api](https://kubernetes.slack.com/archives/C8TSNPY4T)
-* Join the SIG Cluster Lifecycle [Google Group](https://groups.google.com/g/kubernetes-sig-cluster-lifecycle) to receive calendar invites and gain access to documents
-* Join our [Zoom meeting](https://zoom.us/j/861487554), every Wednesday at 10:00 Pacific Time
-* Check out the [ClusterClass quick-start](https://cluster-api.sigs.k8s.io/user/quick-start.html) for the Docker provider (CAPD) in the Cluster API book.
-* _UPDATE_: Check out the [ClusterClass experimental feature](https://cluster-api.sigs.k8s.io/tasks/experimental-features/cluster-class/index.html) documentation in the Cluster API book.

content/en/blog/_posts/2021-10-18-kpng-specialized-proxiers.md

@@ -1,241 +0,0 @@
----
-layout: blog
-title: "Use KPNG to Write Specialized kube-proxiers"
-date: 2021-10-18
-slug: use-kpng-to-write-specialized-kube-proxiers
----
-
-**Author**: Lars Ekman (Ericsson)
-
-The post will show you how to create a specialized service kube-proxy
-style network proxier using Kubernetes Proxy NG
-[kpng](https://github.com/kubernetes-sigs/kpng) without interfering
-with the existing kube-proxy. The kpng project aims at renewing the
-the default Kubernetes Service implementation, the "kube-proxy". An
-important feature of kpng is that it can be used as a library to
-create proxiers outside K8s. While this is useful for CNI-plugins that
-replaces the kube-proxy it also opens the possibility for anyone to
-create a proxier for a special purpose.
-
-
-## Define a service that uses a specialized proxier
-
-```
-apiVersion: v1
-kind: Service
-metadata:
-  name: kpng-example
-  labels:
-    service.kubernetes.io/service-proxy-name: kpng-example
-spec:
-  clusterIP: None
-  ipFamilyPolicy: RequireDualStack
-  externalIPs:
-  - 10.0.0.55
-  - 1000::55
-  selector:
-    app: kpng-alpine
-  ports:
-  - port: 6000
-```
-
-If the `service.kubernetes.io/service-proxy-name` label is defined the
-`kube-proxy` will ignore the service. A custom controller can watch
-services with the label set to it's own name, "kpng-example" in
-this example, and setup specialized load-balancing.
-
-The `service.kubernetes.io/service-proxy-name` label is [not
-new](https://kubernetes.io/docs/reference/labels-annotations-taints/#servicekubernetesioservice-proxy-name),
-but so far is has been quite hard to write a specialized proxier.
-
-The common use for a specialized proxier is assumed to be handling
-external traffic for some use-case not supported by K8s. In that
-case `ClusterIP` is not needed, so we use a "headless" service in this
-example.
-
-
-## Specialized proxier using kpng
-
-A [kpng](https://github.com/kubernetes-sigs/kpng) based proxier
-consists of the `kpng` controller handling all the K8s api related
-functions, and a "backend" implementing the load-balancing. The
-backend can be linked with the `kpng` controller binary or be a
-separate program communicating with the controller using gRPC.
-
-```
-kpng kube --service-proxy-name=kpng-example to-api
-```
-
-This starts the `kpng` controller and tell it to watch only services
-with the "kpng-example" service proxy name. The "to-api" parameter
-will open a gRPC server for backends.
-
-You can test this yourself outside your cluster. Please see the example
-below.
-
-Now we start a backend that simply prints the updates from the
-controller.
-
-```
-$ kubectl apply -f kpng-example.yaml
-$ kpng-json | jq     # (this is the backend)
-{
-  "Service": {
-    "Namespace": "default",
-    "Name": "kpng-example",
-    "Type": "ClusterIP",
-    "IPs": {
-      "ClusterIPs": {},
-      "ExternalIPs": {
-        "V4": [
-          "10.0.0.55"
-        ],
-        "V6": [
-          "1000::55"
-        ]
-      },
-      "Headless": true
-    },
-    "Ports": [
-      {
-        "Protocol": 1,
-        "Port": 6000,
-        "TargetPort": 6000
-      }
-    ]
-  },
-  "Endpoints": [
-    {
-      "IPs": {
-        "V6": [
-          "1100::202"
-        ]
-      },
-      "Local": true
-    },
-    {
-      "IPs": {
-        "V4": [
-          "11.0.2.2"
-        ]
-      },
-      "Local": true
-    },
-    {
-      "IPs": {
-        "V4": [
-          "11.0.1.2"
-        ]
-      }
-    },
-    {
-      "IPs": {
-        "V6": [
-          "1100::102"
-        ]
-      }
-    }
-  ]
-}
-```
-
-A real backend would use some mechanism to load-balance traffic from
-the external IPs to the endpoints.
-
-
-
-## Writing a backend
-
-The `kpng-json` backend looks like this:
-
-```go
-package main
-import (
-        "os"
-        "encoding/json"
-        "sigs.k8s.io/kpng/client"
-)
-func main() {
-        client.Run(jsonPrint)
-}
-func jsonPrint(items []*client.ServiceEndpoints) {
-        enc := json.NewEncoder(os.Stdout)
-        for _, item := range items {
-                _ = enc.Encode(item)
-        }
-}
-```
-
-(yes, that is the entire program)
-
-A real backend would of course be much more complex, but this
-illustrates how `kpng` let you focus on load-balancing.
-
-You can have several backends connected to a `kpng` controller, so
-during development or debug it can be useful to let something like the
-`kpng-json` backend run in parallel with your real backend.
-
-
-## Example
-
-
-The complete example can be found [here](https://github.com/kubernetes-sigs/kpng/tree/master/examples/pipe-exec).
-
-As an example we implement an "all-ip" backend. It direct all traffic
-for the externalIPs to a local endpoint, regardless of ports and upper
-layer protocols. There is a
-[KEP](https://github.com/kubernetes/enhancements/pull/2611) for this
-function and this example is a much simplified version.
-
-To direct all traffic from an external address to a local POD [only
-one iptables rule is
-needed](https://github.com/kubernetes/enhancements/pull/2611#issuecomment-895061013),
-for instance;
-
-```
-ip6tables -t nat -A PREROUTING -d 1000::55/128 -j DNAT --to-destination 1100::202
-```
-
-As you can see the addresses are in the call to the backend and all it
-have to do is:
-
-* Extract the addresses with `Local: true`
-* Setup iptables rules for the `ExternalIPs`
-
-A script doing that may look like:
-
-```
-xip=$(cat /tmp/out | jq -r .Service.IPs.ExternalIPs.V6[0])
-podip=$(cat /tmp/out | jq -r '.Endpoints[]|select(.Local == true)|select(.IPs.V6 != null)|.IPs.V6[0]')
-ip6tables -t nat -A PREROUTING -d $xip/128 -j DNAT --to-destination $podip
-```
-
-Assuming the JSON output above is stored in `/tmp/out` ([jq](https://stedolan.github.io/jq/) is an *awesome* program!).
-
-
-As this is an example we make it really simple for ourselves by using
-a minor variation of the `kpng-json` backend above. Instead of just
-printing, a program is called and the JSON output is passed as `stdin`
-to that program. The backend can be tested stand-alone:
-
-```
-CALLOUT=jq kpng-callout
-```
-
-Where `jq` can be replaced with your own program or script. A script
-may look like the example above.  For more info and the complete
-example please see [https://github.com/kubernetes-sigs/kpng/tree/master/examples/pipe-exec](https://github.com/kubernetes-sigs/kpng/tree/master/examples/pipe-exec).
-
-
-## Summary
-
-While [kpng](https://github.com/kubernetes-sigs/kpng) is in early
-stage of development this post wants to show how you may build your
-own specialized K8s proxiers in the future. The only thing your
-applications need to do is to add the
-`service.kubernetes.io/service-proxy-name` label in the Service
-manifest.
-
-It is a tedious process to get new features into the `kube-proxy` and
-it is not unlikely that they will be rejected, so to write a
-specialized proxier may be the only option.

content/en/blog/_posts/2021-11-08-steering-committee-results-2021.md

@@ -1,56 +0,0 @@
----
-layout: blog
-title: "Announcing the 2021 Steering Committee Election Results"
-date: 2021-11-08
-slug: steering-committee-results-2021
----
-
-**Author**: Kaslin Fields
-
-The [2021 Steering Committee Election](https://github.com/kubernetes/community/tree/master/events/elections/2021) is now complete. The Kubernetes Steering Committee consists of 7 seats, 4 of which were up for election in 2021. Incoming committee members serve a term of 2 years, and all members are elected by the Kubernetes Community.
-
-This community body is significant since it oversees the governance of the entire Kubernetes project. With that great power comes great responsibility. You can learn more about the steering committee’s role in their [charter](https://github.com/kubernetes/steering/blob/master/charter.md).
-
-## Results
-
-Congratulations to the elected committee members whose two year terms begin immediately (listed in alphabetical order by GitHub handle):
-
-* **Christoph Blecker ([@cblecker](https://github.com/cblecker)), Red Hat**
-* **Stephen Augustus ([@justaugustus](https://github.com/justaugustus)), Cisco**
-* **Paris Pittman ([@parispittman](https://github.com/parispittman)), Apple**
-* **Tim Pepper ([@tpepper](https://github.com/tpepper)), VMware**
-
-They join continuing members:
-
-* **Davanum Srinivas ([@dims](https://github.com/dims)), VMware**
-* **Jordan Liggitt ([@liggitt](https://github.com/liggitt)), Google**
-* **Bob Killen ([@mrbobbytables](https://github.com/mrbobbytables)), Google**
-
-Paris Pittman and Christoph Blecker are returning Steering Committee Members.
-
-## Big Thanks
-
-Thank you and congratulations on a successful election to this round’s election officers:
-
-* Alison Dowdney, ([@alisondy](https://github.com/alisondy))
-* Noah Kantrowitz ([@coderanger](https://github.com/coderanger))
-* Josh Berkus ([@jberkus](https://github.com/jberkus))
-
-Special thanks to Arnaud Meukam ([@ameukam](https://github.com/ameukam)), k8s-infra liaison, who enabled our voting software on community-owned infrastructure.
-
-Thanks to the Emeritus Steering Committee Members. Your prior service is appreciated by the community:
-
-* Derek Carr ([@derekwaynecarr](https://github.com/derekwaynecarr))
-* Nikhita Raghunath ([@nikhita](https://github.com/nikhita))
-
-And thank you to all the candidates who came forward to run for election.
-
-## Get Involved with the Steering Committee
-
-This governing body, like all of Kubernetes, is open to all. You can follow along with Steering Committee [backlog items](https://github.com/kubernetes/steering/projects/1) and weigh in by filing an issue or creating a PR against their [repo](https://github.com/kubernetes/steering). They have an open meeting on [the first Monday at 9:30am PT of every month](https://github.com/kubernetes/steering) and regularly attend Meet Our Contributors. They can also be contacted at their public mailing list steering@kubernetes.io.
-
-You can see what the Steering Committee meetings are all about by watching past meetings on the [YouTube Playlist](https://www.youtube.com/playlist?list=PL69nYSiGNLP1yP1B_nd9-drjoxp0Q14qM).
-
----
-
-_This post was written by the [Upstream Marketing Working Group](https://github.com/kubernetes/community/tree/master/communication/marketing-team#contributor-marketing). If you want to write stories about the Kubernetes community, learn more about us._

content/en/blog/_posts/2021-11-09-non-root-containers-and-devices.md

@@ -1,238 +0,0 @@
----
-layout: blog
-title: 'Non-root Containers And Devices'
-date: 2021-11-09
-slug: non-root-containers-and-devices
----
-
-**Author:** Mikko Ylinen (Intel)
-
-The user/group ID related security settings in Pod's `securityContext` trigger a problem when users want to
-deploy containers that use accelerator devices (via [Kubernetes Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)) on Linux. In this blog
-post I talk about the problem and describe the work done so far to address it. It's not meant to be a long story about getting the [k/k issue](https://github.com/kubernetes/kubernetes/issues/92211) fixed.
-
-Instead, this post aims to raise awareness of the issue and to highlight important device use-cases too. This is needed as Kubernetes works on new related features such as support for user namespaces.
-
-## Why non-root containers can't use devices and why it matters
-One of the key security principles for running containers in Kubernetes is the
-principle of least privilege. The Pod/container `securityContext` specifies the config
-options to set, e.g., Linux capabilities, MAC policies, and user/group ID values to achieve this.
-
-Furthermore, the cluster admins are supported with tools like [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) (deprecated) or
-[Pod Security Admission](/docs/concepts/security/pod-security-admission/) (alpha) to enforce the desired security settings for pods that are being deployed in
-the cluster. These settings could, for instance, require that containers must be `runAsNonRoot` or
-that they are forbidden from running with root's group ID in `runAsGroup` or `supplementalGroups`.
-
-In Kubernetes, the kubelet builds the list of [`Device`](https://pkg.go.dev/k8s.io/cri-api@v0.22.1/pkg/apis/runtime/v1#Device) resources to be made available to a container
-(based on inputs from the Device Plugins) and the list is included in the CreateContainer CRI message
-sent to the CRI container runtime. Each `Device` contains little information: host/container device
-paths and the desired devices cgroups permissions.
-
-The [OCI Runtime Spec for Linux Container Configuration](https://github.com/opencontainers/runtime-spec/blob/master/config-linux.md)
-expects that in addition to the devices cgroup fields, more detailed information about the devices
-must be provided:
-
-```yaml
-{
-        "type": "<string>",
-        "path": "<string>",
-        "major": <int64>,
-        "minor": <int64>,
-        "fileMode": <uint32>,
-        "uid": <uint32>,
-        "gid": <uint32>
-},
-```
-
-The CRI container runtimes (containerd, CRI-O) are responsible for obtaining this information
-from the host for each `Device`. By default, the runtimes copy the host device's user and group IDs:
-
-- `uid` (uint32, OPTIONAL) - id of device owner in the container namespace.  
-- `gid` (uint32, OPTIONAL) - id of device group in the container namespace.
-
-Similarly, the runtimes prepare other mandatory `config.json` sections based on the CRI fields,
-including the ones defined in `securityContext`: `runAsUser`/`runAsGroup`, which become part of the POSIX
-platforms user structure via:
-
-- `uid` (int, REQUIRED) specifies the user ID in the container namespace.  
-- `gid` (int, REQUIRED) specifies the group ID in the container namespace.  
-- `additionalGids` (array of ints, OPTIONAL) specifies additional group IDs in the container namespace to be added to the process.
-
-However, the resulting `config.json` triggers a problem when trying to run containers with
-both devices added and with non-root uid/gid set via `runAsUser`/`runAsGroup`: the container user process
-has no permission to use the device even when its group id (gid, copied from host) was permissive to
-non-root groups. This is because the container user does not belong to that host group (e.g., via `additionalGids`).
-
-Being able to run applications that use devices as non-root user is normal and expected to work so that
-the security principles can be met. Therefore, several alternatives were considered to get the gap filled with what the PodSec/CRI/OCI supports today.
-
-## What was done to solve the issue?
-You might have noticed from the problem definition that it would at least be possible to workaround
-the problem by manually adding the device gid(s) to `supplementalGroups`, or in
-the case of just one device, set `runAsGroup` to the device's group id. However, this is problematic because the device gid(s) may have
-different values depending on the nodes' distro/version in the cluster. For example, with GPUs the following commands for different distros and versions return different gids:
-
-Fedora 33:
-```
-$ ls -l /dev/dri/
-total 0
-drwxr-xr-x. 2 root root         80 19.10. 10:21 by-path
-crw-rw----+ 1 root video  226,   0 19.10. 10:42 card0
-crw-rw-rw-. 1 root render 226, 128 19.10. 10:21 renderD128
-$ grep -e video -e render /etc/group
-video:x:39:
-render:x:997:
-```
-
-Ubuntu 20.04:
-```
-$ ls -l /dev/dri/
-total 0
-drwxr-xr-x 2 root root         80 19.10. 17:36 by-path
-crw-rw---- 1 root video  226,   0 19.10. 17:36 card0
-crw-rw---- 1 root render 226, 128 19.10. 17:36 renderD128
-$ grep -e video -e render /etc/group
-video:x:44:
-render:x:133:
-```
-
-Which number to choose in your `securityContext`? Also, what if the `runAsGroup`/`runAsUser` values cannot be hard-coded because
-they are automatically assigned during pod admission time via external security policies?
-
-Unlike volumes with `fsGroup`, the devices have no official notion of `deviceGroup`/`deviceUser` that the CRI runtimes (or kubelet)
-would be able to use. We considered using container annotations set by the device plugins (e.g., `io.kubernetes.cri.hostDeviceSupplementalGroup/`) to get custom OCI `config.json` uid/gid values.
-This would have required changes to all existing device plugins which was not ideal.
-
-Instead, a solution that is *seamless* to end-users without getting the device plugin vendors involved was preferred. The selected approach was
-to re-use `runAsUser` and `runAsGroup` values in `config.json` for devices:
-
-```yaml
-{
-        "type": "c",
-        "path": "/dev/foo",
-        "major": 123,
-        "minor": 4,
-        "fileMode": 438,
-        "uid": <runAsUser>,
-        "gid": <runAsGroup>
-},
-```
-
-With `runc` OCI runtime (in non-rootless mode), the device is created (`mknod(2)`) in
-the container namespace and the ownership is changed to `runAsUser`/`runAsGroup` using `chmod(2)`.
-
-{{< note >}}
-[Rootless mode](/docs/tasks/administer-cluster/kubelet-in-userns/) and devices is not supported.
-{{</note>}}
-Having the ownership updated in the container namespace is justified as the user process is the only one accessing the device. Only `runAsUser`/`runAsGroup`
-are taken into account, and, e.g., the `USER` setting in the container is currently ignored.
-
-While it is likely that the "faulty" deployments (i.e., non-root `securityContext` + devices) do not exist, to be absolutely sure no
-deployments break, an opt-in config entry in both containerd and CRI-O to enable the new behavior was added. The following:
-
-`device_ownership_from_security_context (bool)`
-
-defaults to `false` and must be enabled to use the feature.
-
-## See non-root containers using devices after the fix
-To demonstrate the new behavior, let's use a Data Plane Development Kit (DPDK) application using hardware accelerators, Kubernetes CPU manager, and HugePages as an example. The cluster runs containerd with:
-
-```toml
-[plugins]
-  [plugins."io.containerd.grpc.v1.cri"]
-    device_ownership_from_security_context = true
-```
-
-or CRI-O with:
-
-```toml
-[crio.runtime]
-device_ownership_from_security_context = true
-```
-
-and the `Guaranteed` QoS Class Pod that runs DPDK's crypto-perf test utility with this YAML:
-
-```yaml
-...
-metadata:
-  name: qat-dpdk
-spec:
-  securityContext:
-    runAsUser: 1000
-    runAsGroup: 2000
-    fsGroup: 3000
-  containers:
-  - name: crypto-perf
-    image: intel/crypto-perf:devel
-    ...
-    resources:
-      requests:
-        cpu: "3"
-        memory: "128Mi"
-        qat.intel.com/generic: '4'
-        hugepages-2Mi: "128Mi"
-      limits:
-        cpu: "3"
-        memory: "128Mi"
-        qat.intel.com/generic: '4'
-        hugepages-2Mi: "128Mi"
-  ...
-```
-
-To verify the results, check the user and group ID that the container runs as:
-
-```
-$ kubectl exec -it qat-dpdk -c crypto-perf -- id
-```
-
-They are set to non-zero values as expected:
-
-```
-uid=1000 gid=2000 groups=2000,3000
-```
-
-Next, check the device node permissions (`qat.intel.com/generic` exposes `/dev/vfio/` devices) are accessible to `runAsUser`/`runAsGroup`:
-
-```
-$ kubectl exec -it qat-dpdk -c crypto-perf -- ls -la /dev/vfio
-total 0
-drwxr-xr-x 2 root root      140 Sep  7 10:55 .
-drwxr-xr-x 7 root root      380 Sep  7 10:55 ..
-crw------- 1 1000 2000 241,   0 Sep  7 10:55 58
-crw------- 1 1000 2000 241,   2 Sep  7 10:55 60
-crw------- 1 1000 2000 241,  10 Sep  7 10:55 68
-crw------- 1 1000 2000 241,  11 Sep  7 10:55 69
-crw-rw-rw- 1 1000 2000  10, 196 Sep  7 10:55 vfio
-```
-
-Finally, check the non-root container is also allowed to create HugePages:
-
-```
-$ kubectl exec -it qat-dpdk -c crypto-perf -- ls -la /dev/hugepages/
-```
-
-`fsGroup` gives a `runAsUser` writable HugePages emptyDir mountpoint:
-
-```
-total 0
-drwxrwsr-x 2 root 3000   0 Sep  7 10:55 .
-drwxr-xr-x 7 root root 380 Sep  7 10:55 ..
-```
-
-## Help us test it and provide feedback!
-The functionality described here is expected to help with cluster security and the configurability of device permissions. To allow
-non-root containers to use devices requires cluster admins to opt-in to the functionality by setting
-`device_ownership_from_security_context = true`. To make it a default setting, please test it and provide your feedback (via SIG-Node meetings or issues)!
-The flag is available in CRI-O v1.22 release and queued for containerd v1.6.
-
-More work is needed to get it *properly* supported. It is known to work with `runc` but it also needs to be made to function
-with other OCI runtimes too, where applicable. For instance, Kata Containers supports device passthrough and allows it to make devices
-available to containers in VM sandboxes too.
-
-Moreover, the additional challenge comes with support of user names and devices. This problem is still [open](https://github.com/kubernetes/enhancements/pull/2101)
-and requires more brainstorming.
-
-Finally, it needs to be understood whether `runAsUser`/`runAsGroup` are enough or if device specific settings similar to `fsGroups` are needed in PodSpec/CRI v2.
-
-## Thanks
-My thanks goes to Mike Brown (IBM, containerd), Peter Hunt (Redhat, CRI-O), and Alexander Kanevskiy (Intel) for providing all the feedback and good conversations.

content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md

@@ -1,64 +0,0 @@
----
-layout: blog
-title: "Dockershim removal is coming. Are you ready?"
-date: 2021-11-12
-slug: are-you-ready-for-dockershim-removal
----
-
-**Author:** Sergey Kanzhelev, Google. With reviews from Davanum Srinivas, Elana Hashman, Noah Kantrowitz, Rey Lejano.
-
-{{% alert color="info" title="Poll closed" %}}
-This poll closed on January 7, 2022.
-{{% /alert %}}
-
-Last year we announced that Dockershim is being deprecated: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/).
-Our current plan is to remove dockershim from the Kubernetes codebase soon.
-We are looking for feedback from you whether you are ready for dockershim
-removal and to ensure that you are ready when the time comes.
-
-<del>Please fill out this survey: https://forms.gle/svCJmhvTv78jGdSx8</del>
-
-The dockershim component that enables Docker as a Kubernetes container runtime is
-being deprecated in favor of runtimes that directly use the [Container Runtime Interface](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)
-created for Kubernetes. Many Kubernetes users have migrated to
-other container runtimes without problems. However we see that dockershim is
-still very popular. You may see some public numbers in recent [Container Report](https://www.datadoghq.com/container-report/#8) from DataDog.
-Some Kubernetes hosting vendors just recently enabled other runtimes support
-(especially for Windows nodes). And we know that many third party tools vendors
-are still not ready: [migrating telemetry and security agents](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/#telemetry-and-security-agent-vendors).
-
-At this point, we believe that there is feature parity between Docker and the
-other runtimes. Many end-users have used our [migration guide](/docs/tasks/administer-cluster/migrating-from-dockershim/)
-and are running production workload using these different runtimes. The plan of
-record today is that dockershim will be removed in version 1.24, slated for
-release around April of next year. For those developing or running alpha and
-beta versions, dockershim will be removed in December at the beginning of the
-1.24 release development cycle.
-
-There is only one month left to give us feedback. We want you to tell us how
-ready you are.
-
-<del>We are collecting opinions through this survey: https://forms.gle/svCJmhvTv78jGdSx8</del>
-To better understand preparedness for the dockershim removal, our survey is
-asking the version of Kubernetes you are currently using, and an estimate of
-when you think you will adopt Kubernetes 1.24. All the aggregated information
-on dockershim removal readiness will be published.
-Free form comments will be reviewed by SIG Node leadership. If you want to
-discuss any details of migrating from dockershim, report bugs or adoption
-blockers, you can use one of the SIG Node contact options any time:
-https://github.com/kubernetes/community/tree/master/sig-node#contact
-
-Kubernetes is a mature project. This deprecation is another
-step in the effort to get away from permanent beta features and providing more
-stability and compatibility guarantees. With the migration from dockershim you
-will get more flexibility and choice of container runtime features as well as
-less dependencies of your apps on specific underlying technology. Please take
-time to review the [dockershim migration documentation](/docs/tasks/administer-cluster/migrating-from-dockershim/)
-and consult your Kubernetes hosting vendor (if you have one) what container runtime options are available for you.
-Read up [container runtime documentation with instructions on how to use containerd and CRI-O](/docs/setup/production-environment/container-runtimes/#container-runtimes)
-to help prepare you when you're ready to upgrade to 1.24. CRI-O, containerd, and
-Docker with [Mirantis cri-dockerd](https://github.com/Mirantis/cri-dockerd) are
-not the only container runtime options, we encourage you to explore the [CNCF landscape on container runtimes](https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category)
-in case another suits you better.
-
-Thank you!

content/en/blog/_posts/2021-11-26-memory-qos-cgroups-v2/container-memory-min.svg

@@ -1,87 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!-- Generated by CodeCogs with dvisvgm 2.9.1 -->
-<svg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' width='389.559851pt' height='13.50934pt' viewBox='-.239051 -.240635 389.559851 13.50934'>
-<defs>
-<path id='g1-61' d='M8.069738-3.873474C8.237111-3.873474 8.452304-3.873474 8.452304-4.088667C8.452304-4.315816 8.249066-4.315816 8.069738-4.315816H1.028144C.860772-4.315816 .645579-4.315816 .645579-4.100623C.645579-3.873474 .848817-3.873474 1.028144-3.873474H8.069738ZM8.069738-1.649813C8.237111-1.649813 8.452304-1.649813 8.452304-1.865006C8.452304-2.092154 8.249066-2.092154 8.069738-2.092154H1.028144C.860772-2.092154 .645579-2.092154 .645579-1.876961C.645579-1.649813 .848817-1.649813 1.028144-1.649813H8.069738Z'/>
-<path id='g1-91' d='M2.988792 2.988792V2.546451H1.829141V-8.524035H2.988792V-8.966376H1.3868V2.988792H2.988792Z'/>
-<path id='g1-93' d='M1.853051-8.966376H.251059V-8.524035H1.41071V2.546451H.251059V2.988792H1.853051V-8.966376Z'/>
-<path id='g0-58' d='M2.199751-.573848C2.199751-.920548 1.912827-1.159651 1.625903-1.159651C1.279203-1.159651 1.0401-.872727 1.0401-.585803C1.0401-.239103 1.327024 0 1.613948 0C1.960648 0 2.199751-.286924 2.199751-.573848Z'/>
-<path id='g0-97' d='M3.598506-1.422665C3.53873-1.219427 3.53873-1.195517 3.371357-.968369C3.108344-.633624 2.582316-.119552 2.020423-.119552C1.530262-.119552 1.255293-.561893 1.255293-1.267248C1.255293-1.924782 1.625903-3.263761 1.853051-3.765878C2.259527-4.60274 2.82142-5.033126 3.287671-5.033126C4.076712-5.033126 4.23213-4.052802 4.23213-3.957161C4.23213-3.945205 4.196264-3.789788 4.184309-3.765878L3.598506-1.422665ZM4.363636-4.483188C4.23213-4.794022 3.90934-5.272229 3.287671-5.272229C1.936737-5.272229 .478207-3.526775 .478207-1.75741C.478207-.573848 1.171606 .119552 1.984558 .119552C2.642092 .119552 3.203985-.394521 3.53873-.789041C3.658281-.083686 4.220174 .119552 4.578829 .119552S5.224408-.095641 5.439601-.526027C5.630884-.932503 5.798257-1.661768 5.798257-1.709589C5.798257-1.769365 5.750436-1.817186 5.678705-1.817186C5.571108-1.817186 5.559153-1.75741 5.511333-1.578082C5.332005-.872727 5.104857-.119552 4.614695-.119552C4.267995-.119552 4.244085-.430386 4.244085-.669489C4.244085-.944458 4.27995-1.075965 4.387547-1.542217C4.471233-1.841096 4.531009-2.10411 4.62665-2.450809C5.068991-4.244085 5.176588-4.674471 5.176588-4.746202C5.176588-4.913574 5.045081-5.045081 4.865753-5.045081C4.483188-5.045081 4.387547-4.62665 4.363636-4.483188Z'/>
-<path id='g0-99' d='M4.674471-4.495143C4.447323-4.495143 4.339726-4.495143 4.172354-4.351681C4.100623-4.291905 3.969116-4.112578 3.969116-3.921295C3.969116-3.682192 4.148443-3.53873 4.375592-3.53873C4.662516-3.53873 4.985305-3.777833 4.985305-4.25604C4.985305-4.829888 4.435367-5.272229 3.610461-5.272229C2.044334-5.272229 .478207-3.56264 .478207-1.865006C.478207-.824907 1.123786 .119552 2.343213 .119552C3.969116 .119552 4.99726-1.147696 4.99726-1.303113C4.99726-1.374844 4.925529-1.43462 4.877709-1.43462C4.841843-1.43462 4.829888-1.422665 4.722291-1.315068C3.957161-.298879 2.82142-.119552 2.367123-.119552C1.542217-.119552 1.279203-.836862 1.279203-1.43462C1.279203-1.853051 1.482441-3.012702 1.912827-3.825654C2.223661-4.387547 2.86924-5.033126 3.622416-5.033126C3.777833-5.033126 4.435367-5.009215 4.674471-4.495143Z'/>
-<path id='g0-100' d='M6.01345-7.998007C6.025405-8.045828 6.049315-8.117559 6.049315-8.177335C6.049315-8.296887 5.929763-8.296887 5.905853-8.296887C5.893898-8.296887 5.308095-8.249066 5.248319-8.237111C5.045081-8.225156 4.865753-8.201245 4.65056-8.18929C4.351681-8.16538 4.267995-8.153425 4.267995-7.938232C4.267995-7.81868 4.363636-7.81868 4.531009-7.81868C5.116812-7.81868 5.128767-7.711083 5.128767-7.591532C5.128767-7.519801 5.104857-7.424159 5.092902-7.388294L4.363636-4.483188C4.23213-4.794022 3.90934-5.272229 3.287671-5.272229C1.936737-5.272229 .478207-3.526775 .478207-1.75741C.478207-.573848 1.171606 .119552 1.984558 .119552C2.642092 .119552 3.203985-.394521 3.53873-.789041C3.658281-.083686 4.220174 .119552 4.578829 .119552S5.224408-.095641 5.439601-.526027C5.630884-.932503 5.798257-1.661768 5.798257-1.709589C5.798257-1.769365 5.750436-1.817186 5.678705-1.817186C5.571108-1.817186 5.559153-1.75741 5.511333-1.578082C5.332005-.872727 5.104857-.119552 4.614695-.119552C4.267995-.119552 4.244085-.430386 4.244085-.669489C4.244085-.71731 4.244085-.968369 4.327771-1.303113L6.01345-7.998007ZM3.598506-1.422665C3.53873-1.219427 3.53873-1.195517 3.371357-.968369C3.108344-.633624 2.582316-.119552 2.020423-.119552C1.530262-.119552 1.255293-.561893 1.255293-1.267248C1.255293-1.924782 1.625903-3.263761 1.853051-3.765878C2.259527-4.60274 2.82142-5.033126 3.287671-5.033126C4.076712-5.033126 4.23213-4.052802 4.23213-3.957161C4.23213-3.945205 4.196264-3.789788 4.184309-3.765878L3.598506-1.422665Z'/>
-<path id='g0-101' d='M2.139975-2.773599C2.462765-2.773599 3.275716-2.797509 3.849564-3.012702C4.758157-3.359402 4.841843-4.052802 4.841843-4.267995C4.841843-4.794022 4.387547-5.272229 3.598506-5.272229C2.343213-5.272229 .537983-4.136488 .537983-2.008468C.537983-.753176 1.255293 .119552 2.343213 .119552C3.969116 .119552 4.99726-1.147696 4.99726-1.303113C4.99726-1.374844 4.925529-1.43462 4.877709-1.43462C4.841843-1.43462 4.829888-1.422665 4.722291-1.315068C3.957161-.298879 2.82142-.119552 2.367123-.119552C1.685679-.119552 1.327024-.657534 1.327024-1.542217C1.327024-1.709589 1.327024-2.008468 1.506351-2.773599H2.139975ZM1.566127-3.012702C2.080199-4.853798 3.21594-5.033126 3.598506-5.033126C4.124533-5.033126 4.483188-4.722291 4.483188-4.267995C4.483188-3.012702 2.570361-3.012702 2.068244-3.012702H1.566127Z'/>
-<path id='g0-105' d='M3.383313-1.709589C3.383313-1.769365 3.335492-1.817186 3.263761-1.817186C3.156164-1.817186 3.144209-1.78132 3.084433-1.578082C2.773599-.490162 2.283437-.119552 1.888917-.119552C1.745455-.119552 1.578082-.155417 1.578082-.514072C1.578082-.836862 1.721544-1.195517 1.853051-1.554172L2.689913-3.777833C2.725778-3.873474 2.809465-4.088667 2.809465-4.315816C2.809465-4.817933 2.450809-5.272229 1.865006-5.272229C.765131-5.272229 .32279-3.53873 .32279-3.443088C.32279-3.395268 .37061-3.335492 .454296-3.335492C.561893-3.335492 .573848-3.383313 .621669-3.550685C.908593-4.554919 1.362889-5.033126 1.829141-5.033126C1.936737-5.033126 2.139975-5.021171 2.139975-4.638605C2.139975-4.327771 1.984558-3.93325 1.888917-3.670237L1.052055-1.446575C.980324-1.255293 .908593-1.06401 .908593-.848817C.908593-.310834 1.279203 .119552 1.853051 .119552C2.952927 .119552 3.383313-1.625903 3.383313-1.709589ZM3.287671-7.460025C3.287671-7.639352 3.144209-7.854545 2.881196-7.854545C2.606227-7.854545 2.295392-7.591532 2.295392-7.280697C2.295392-6.981818 2.546451-6.886177 2.689913-6.886177C3.012702-6.886177 3.287671-7.197011 3.287671-7.460025Z'/>
-<path id='g0-109' d='M2.462765-3.502864C2.486675-3.574595 2.785554-4.172354 3.227895-4.554919C3.53873-4.841843 3.945205-5.033126 4.411457-5.033126C4.889664-5.033126 5.057036-4.674471 5.057036-4.196264C5.057036-4.124533 5.057036-3.88543 4.913574-3.323537L4.614695-2.092154C4.519054-1.733499 4.291905-.848817 4.267995-.71731C4.220174-.537983 4.148443-.227148 4.148443-.179328C4.148443-.011955 4.27995 .119552 4.459278 .119552C4.817933 .119552 4.877709-.155417 4.985305-.585803L5.702615-3.443088C5.726526-3.53873 6.348194-5.033126 7.663263-5.033126C8.141469-5.033126 8.308842-4.674471 8.308842-4.196264C8.308842-3.526775 7.84259-2.223661 7.579577-1.506351C7.47198-1.219427 7.412204-1.06401 7.412204-.848817C7.412204-.310834 7.782814 .119552 8.356663 .119552C9.468493 .119552 9.886924-1.637858 9.886924-1.709589C9.886924-1.769365 9.839103-1.817186 9.767372-1.817186C9.659776-1.817186 9.647821-1.78132 9.588045-1.578082C9.313076-.621669 8.870735-.119552 8.392528-.119552C8.272976-.119552 8.081694-.131507 8.081694-.514072C8.081694-.824907 8.225156-1.207472 8.272976-1.338979C8.488169-1.912827 9.026152-3.323537 9.026152-4.016936C9.026152-4.734247 8.607721-5.272229 7.699128-5.272229C6.898132-5.272229 6.252553-4.817933 5.774346-4.112578C5.738481-4.758157 5.34396-5.272229 4.447323-5.272229C3.383313-5.272229 2.82142-4.519054 2.606227-4.220174C2.570361-4.901619 2.080199-5.272229 1.554172-5.272229C1.207472-5.272229 .932503-5.104857 .705355-4.65056C.490162-4.220174 .32279-3.490909 .32279-3.443088S.37061-3.335492 .454296-3.335492C.549938-3.335492 .561893-3.347447 .633624-3.622416C.812951-4.327771 1.0401-5.033126 1.518306-5.033126C1.793275-5.033126 1.888917-4.841843 1.888917-4.483188C1.888917-4.220174 1.769365-3.753923 1.685679-3.383313L1.350934-2.092154C1.303113-1.865006 1.171606-1.327024 1.111831-1.111831C1.028144-.800996 .896638-.239103 .896638-.179328C.896638-.011955 1.028144 .119552 1.207472 .119552C1.350934 .119552 1.518306 .047821 1.613948-.131507C1.637858-.191283 1.745455-.609714 1.80523-.848817L2.068244-1.924782L2.462765-3.502864Z'/>
-<path id='g0-110' d='M2.462765-3.502864C2.486675-3.574595 2.785554-4.172354 3.227895-4.554919C3.53873-4.841843 3.945205-5.033126 4.411457-5.033126C4.889664-5.033126 5.057036-4.674471 5.057036-4.196264C5.057036-3.514819 4.566874-2.15193 4.327771-1.506351C4.220174-1.219427 4.160399-1.06401 4.160399-.848817C4.160399-.310834 4.531009 .119552 5.104857 .119552C6.216687 .119552 6.635118-1.637858 6.635118-1.709589C6.635118-1.769365 6.587298-1.817186 6.515567-1.817186C6.40797-1.817186 6.396015-1.78132 6.336239-1.578082C6.06127-.597758 5.606974-.119552 5.140722-.119552C5.021171-.119552 4.829888-.131507 4.829888-.514072C4.829888-.812951 4.961395-1.171606 5.033126-1.338979C5.272229-1.996513 5.774346-3.335492 5.774346-4.016936C5.774346-4.734247 5.355915-5.272229 4.447323-5.272229C3.383313-5.272229 2.82142-4.519054 2.606227-4.220174C2.570361-4.901619 2.080199-5.272229 1.554172-5.272229C1.171606-5.272229 .908593-5.045081 .705355-4.638605C.490162-4.208219 .32279-3.490909 .32279-3.443088S.37061-3.335492 .454296-3.335492C.549938-3.335492 .561893-3.347447 .633624-3.622416C.824907-4.351681 1.0401-5.033126 1.518306-5.033126C1.793275-5.033126 1.888917-4.841843 1.888917-4.483188C1.888917-4.220174 1.769365-3.753923 1.685679-3.383313L1.350934-2.092154C1.303113-1.865006 1.171606-1.327024 1.111831-1.111831C1.028144-.800996 .896638-.239103 .896638-.179328C.896638-.011955 1.028144 .119552 1.207472 .119552C1.350934 .119552 1.518306 .047821 1.613948-.131507C1.637858-.191283 1.745455-.609714 1.80523-.848817L2.068244-1.924782L2.462765-3.502864Z'/>
-<path id='g0-111' d='M5.451557-3.287671C5.451557-4.423412 4.710336-5.272229 3.622416-5.272229C2.044334-5.272229 .490162-3.550685 .490162-1.865006C.490162-.729265 1.231382 .119552 2.319303 .119552C3.90934 .119552 5.451557-1.601993 5.451557-3.287671ZM2.331258-.119552C1.733499-.119552 1.291158-.597758 1.291158-1.43462C1.291158-1.984558 1.578082-3.203985 1.912827-3.801743C2.450809-4.722291 3.120299-5.033126 3.610461-5.033126C4.196264-5.033126 4.65056-4.554919 4.65056-3.718057C4.65056-3.239851 4.399502-1.960648 3.945205-1.231382C3.455044-.430386 2.797509-.119552 2.331258-.119552Z'/>
-<path id='g0-112' d='M.514072 1.518306C.430386 1.876961 .382565 1.972603-.107597 1.972603C-.251059 1.972603-.37061 1.972603-.37061 2.199751C-.37061 2.223661-.358655 2.319303-.227148 2.319303C-.071731 2.319303 .095641 2.295392 .251059 2.295392H.765131C1.016189 2.295392 1.625903 2.319303 1.876961 2.319303C1.948692 2.319303 2.092154 2.319303 2.092154 2.10411C2.092154 1.972603 2.008468 1.972603 1.80523 1.972603C1.255293 1.972603 1.219427 1.888917 1.219427 1.793275C1.219427 1.649813 1.75741-.406476 1.829141-.681445C1.960648-.3467 2.283437 .119552 2.905106 .119552C4.25604 .119552 5.71457-1.637858 5.71457-3.395268C5.71457-4.495143 5.092902-5.272229 4.196264-5.272229C3.431133-5.272229 2.785554-4.531009 2.654047-4.363636C2.558406-4.961395 2.092154-5.272229 1.613948-5.272229C1.267248-5.272229 .992279-5.104857 .765131-4.65056C.549938-4.220174 .382565-3.490909 .382565-3.443088S.430386-3.335492 .514072-3.335492C.609714-3.335492 .621669-3.347447 .6934-3.622416C.872727-4.327771 1.099875-5.033126 1.578082-5.033126C1.853051-5.033126 1.948692-4.841843 1.948692-4.483188C1.948692-4.196264 1.912827-4.076712 1.865006-3.861519L.514072 1.518306ZM2.582316-3.730012C2.666002-4.064757 3.000747-4.411457 3.19203-4.578829C3.323537-4.698381 3.718057-5.033126 4.172354-5.033126C4.698381-5.033126 4.937484-4.507098 4.937484-3.88543C4.937484-3.311582 4.60274-1.960648 4.303861-1.338979C4.004981-.6934 3.455044-.119552 2.905106-.119552C2.092154-.119552 1.960648-1.147696 1.960648-1.195517C1.960648-1.231382 1.984558-1.327024 1.996513-1.3868L2.582316-3.730012Z'/>
-<path id='g0-113' d='M5.272229-5.152677C5.272229-5.212453 5.224408-5.260274 5.164633-5.260274C5.068991-5.260274 4.60274-4.829888 4.375592-4.411457C4.160399-4.94944 3.789788-5.272229 3.275716-5.272229C1.924782-5.272229 .466252-3.526775 .466252-1.75741C.466252-.573848 1.159651 .119552 1.972603 .119552C2.606227 .119552 3.132254-.358655 3.383313-.633624L3.395268-.621669L2.940971 1.171606L2.833375 1.601993C2.725778 1.960648 2.546451 1.960648 1.984558 1.972603C1.853051 1.972603 1.733499 1.972603 1.733499 2.199751C1.733499 2.283437 1.80523 2.319303 1.888917 2.319303C2.056289 2.319303 2.271482 2.295392 2.438854 2.295392H3.658281C3.837609 2.295392 4.040847 2.319303 4.220174 2.319303C4.291905 2.319303 4.435367 2.319303 4.435367 2.092154C4.435367 1.972603 4.339726 1.972603 4.160399 1.972603C3.598506 1.972603 3.56264 1.888917 3.56264 1.793275C3.56264 1.733499 3.574595 1.721544 3.610461 1.566127L5.272229-5.152677ZM3.58655-1.422665C3.526775-1.219427 3.526775-1.195517 3.359402-.968369C3.096389-.633624 2.570361-.119552 2.008468-.119552C1.518306-.119552 1.243337-.561893 1.243337-1.267248C1.243337-1.924782 1.613948-3.263761 1.841096-3.765878C2.247572-4.60274 2.809465-5.033126 3.275716-5.033126C4.064757-5.033126 4.220174-4.052802 4.220174-3.957161C4.220174-3.945205 4.184309-3.789788 4.172354-3.765878L3.58655-1.422665Z'/>
-<path id='g0-114' d='M4.65056-4.889664C4.27995-4.817933 4.088667-4.554919 4.088667-4.291905C4.088667-4.004981 4.315816-3.90934 4.483188-3.90934C4.817933-3.90934 5.092902-4.196264 5.092902-4.554919C5.092902-4.937484 4.722291-5.272229 4.124533-5.272229C3.646326-5.272229 3.096389-5.057036 2.594271-4.327771C2.510585-4.961395 2.032379-5.272229 1.554172-5.272229C1.08792-5.272229 .848817-4.913574 .705355-4.65056C.502117-4.220174 .32279-3.502864 .32279-3.443088C.32279-3.395268 .37061-3.335492 .454296-3.335492C.549938-3.335492 .561893-3.347447 .633624-3.622416C.812951-4.339726 1.0401-5.033126 1.518306-5.033126C1.80523-5.033126 1.888917-4.829888 1.888917-4.483188C1.888917-4.220174 1.769365-3.753923 1.685679-3.383313L1.350934-2.092154C1.303113-1.865006 1.171606-1.327024 1.111831-1.111831C1.028144-.800996 .896638-.239103 .896638-.179328C.896638-.011955 1.028144 .119552 1.207472 .119552C1.338979 .119552 1.566127 .035866 1.637858-.203238C1.673724-.298879 2.116065-2.10411 2.187796-2.379078C2.247572-2.642092 2.319303-2.893151 2.379078-3.156164C2.426899-3.323537 2.47472-3.514819 2.510585-3.670237C2.546451-3.777833 2.86924-4.363636 3.16812-4.62665C3.311582-4.758157 3.622416-5.033126 4.112578-5.033126C4.303861-5.033126 4.495143-4.99726 4.65056-4.889664Z'/>
-<path id='g0-115' d='M2.725778-2.391034C2.929016-2.355168 3.251806-2.283437 3.323537-2.271482C3.478954-2.223661 4.016936-2.032379 4.016936-1.458531C4.016936-1.08792 3.682192-.119552 2.295392-.119552C2.044334-.119552 1.147696-.155417 .908593-.812951C1.3868-.753176 1.625903-1.123786 1.625903-1.3868C1.625903-1.637858 1.458531-1.769365 1.219427-1.769365C.956413-1.769365 .609714-1.566127 .609714-1.028144C.609714-.32279 1.327024 .119552 2.283437 .119552C4.100623 .119552 4.638605-1.219427 4.638605-1.841096C4.638605-2.020423 4.638605-2.355168 4.25604-2.737733C3.957161-3.024658 3.670237-3.084433 3.024658-3.21594C2.701868-3.287671 2.187796-3.395268 2.187796-3.93325C2.187796-4.172354 2.402989-5.033126 3.53873-5.033126C4.040847-5.033126 4.531009-4.841843 4.65056-4.411457C4.124533-4.411457 4.100623-3.957161 4.100623-3.945205C4.100623-3.694147 4.327771-3.622416 4.435367-3.622416C4.60274-3.622416 4.937484-3.753923 4.937484-4.25604S4.483188-5.272229 3.550685-5.272229C1.984558-5.272229 1.566127-4.040847 1.566127-3.550685C1.566127-2.642092 2.450809-2.450809 2.725778-2.391034Z'/>
-<path id='g0-116' d='M2.402989-4.805978H3.502864C3.730012-4.805978 3.849564-4.805978 3.849564-5.021171C3.849564-5.152677 3.777833-5.152677 3.53873-5.152677H2.486675L2.929016-6.898132C2.976837-7.065504 2.976837-7.089415 2.976837-7.173101C2.976837-7.364384 2.82142-7.47198 2.666002-7.47198C2.570361-7.47198 2.295392-7.436115 2.199751-7.053549L1.733499-5.152677H.609714C.37061-5.152677 .263014-5.152677 .263014-4.925529C.263014-4.805978 .3467-4.805978 .573848-4.805978H1.637858L.848817-1.649813C.753176-1.231382 .71731-1.111831 .71731-.956413C.71731-.394521 1.111831 .119552 1.78132 .119552C2.988792 .119552 3.634371-1.625903 3.634371-1.709589C3.634371-1.78132 3.58655-1.817186 3.514819-1.817186C3.490909-1.817186 3.443088-1.817186 3.419178-1.769365C3.407223-1.75741 3.395268-1.745455 3.311582-1.554172C3.060523-.956413 2.510585-.119552 1.817186-.119552C1.458531-.119552 1.43462-.418431 1.43462-.681445C1.43462-.6934 1.43462-.920548 1.470486-1.06401L2.402989-4.805978Z'/>
-<path id='g0-117' d='M4.076712-.6934C4.23213-.02391 4.805978 .119552 5.092902 .119552C5.475467 .119552 5.762391-.131507 5.953674-.537983C6.156912-.968369 6.312329-1.673724 6.312329-1.709589C6.312329-1.769365 6.264508-1.817186 6.192777-1.817186C6.085181-1.817186 6.073225-1.75741 6.025405-1.578082C5.810212-.753176 5.595019-.119552 5.116812-.119552C4.758157-.119552 4.758157-.514072 4.758157-.669489C4.758157-.944458 4.794022-1.06401 4.913574-1.566127C4.99726-1.888917 5.080946-2.211706 5.152677-2.546451L5.642839-4.495143C5.726526-4.794022 5.726526-4.817933 5.726526-4.853798C5.726526-5.033126 5.583064-5.152677 5.403736-5.152677C5.057036-5.152677 4.97335-4.853798 4.901619-4.554919C4.782067-4.088667 4.136488-1.518306 4.052802-1.099875C4.040847-1.099875 3.574595-.119552 2.701868-.119552C2.080199-.119552 1.960648-.657534 1.960648-1.099875C1.960648-1.78132 2.295392-2.737733 2.606227-3.53873C2.749689-3.921295 2.809465-4.076712 2.809465-4.315816C2.809465-4.829888 2.438854-5.272229 1.865006-5.272229C.765131-5.272229 .32279-3.53873 .32279-3.443088C.32279-3.395268 .37061-3.335492 .454296-3.335492C.561893-3.335492 .573848-3.383313 .621669-3.550685C.908593-4.578829 1.374844-5.033126 1.829141-5.033126C1.948692-5.033126 2.139975-5.021171 2.139975-4.638605C2.139975-4.327771 2.008468-3.981071 1.829141-3.526775C1.303113-2.10411 1.243337-1.649813 1.243337-1.291158C1.243337-.071731 2.163885 .119552 2.654047 .119552C3.419178 .119552 3.837609-.406476 4.076712-.6934Z'/>
-<path id='g0-121' d='M3.144209 1.338979C2.82142 1.793275 2.355168 2.199751 1.769365 2.199751C1.625903 2.199751 1.052055 2.175841 .872727 1.625903C.908593 1.637858 .968369 1.637858 .992279 1.637858C1.350934 1.637858 1.590037 1.327024 1.590037 1.052055S1.362889 .681445 1.183562 .681445C.992279 .681445 .573848 .824907 .573848 1.41071C.573848 2.020423 1.08792 2.438854 1.769365 2.438854C2.964882 2.438854 4.172354 1.338979 4.507098 .011955L5.678705-4.65056C5.69066-4.710336 5.71457-4.782067 5.71457-4.853798C5.71457-5.033126 5.571108-5.152677 5.391781-5.152677C5.284184-5.152677 5.033126-5.104857 4.937484-4.746202L4.052802-1.231382C3.993026-1.016189 3.993026-.992279 3.897385-.860772C3.658281-.526027 3.263761-.119552 2.689913-.119552C2.020423-.119552 1.960648-.777086 1.960648-1.099875C1.960648-1.78132 2.283437-2.701868 2.606227-3.56264C2.737733-3.90934 2.809465-4.076712 2.809465-4.315816C2.809465-4.817933 2.450809-5.272229 1.865006-5.272229C.765131-5.272229 .32279-3.53873 .32279-3.443088C.32279-3.395268 .37061-3.335492 .454296-3.335492C.561893-3.335492 .573848-3.383313 .621669-3.550685C.908593-4.554919 1.362889-5.033126 1.829141-5.033126C1.936737-5.033126 2.139975-5.033126 2.139975-4.638605C2.139975-4.327771 2.008468-3.981071 1.829141-3.526775C1.243337-1.960648 1.243337-1.566127 1.243337-1.279203C1.243337-.143462 2.056289 .119552 2.654047 .119552C3.000747 .119552 3.431133 .011955 3.849564-.430386L3.861519-.418431C3.682192 .286924 3.56264 .753176 3.144209 1.338979Z'/>
-</defs>
-<g id='page1' transform='matrix(1.13 0 0 1.13 -63.986043 -64.41)'>
-<use x='56.413267' y='65.753425' xlink:href='#g0-109'/>
-<use x='66.652534' y='65.753425' xlink:href='#g0-101'/>
-<use x='72.077974' y='65.753425' xlink:href='#g0-109'/>
-<use x='82.317241' y='65.753425' xlink:href='#g0-111'/>
-<use x='87.944679' y='65.753425' xlink:href='#g0-114'/>
-<use x='93.545152' y='65.753425' xlink:href='#g0-121'/>
-<use x='99.681804' y='65.753425' xlink:href='#g0-58'/>
-<use x='102.933465' y='65.753425' xlink:href='#g0-109'/>
-<use x='113.172732' y='65.753425' xlink:href='#g0-105'/>
-<use x='117.166164' y='65.753425' xlink:href='#g0-110'/>
-<use x='127.474599' y='65.753425' xlink:href='#g1-61'/>
-<use x='139.90008' y='65.753425' xlink:href='#g0-112'/>
-<use x='145.775223' y='65.753425' xlink:href='#g0-111'/>
-<use x='151.402661' y='65.753425' xlink:href='#g0-100'/>
-<use x='157.485354' y='65.753425' xlink:href='#g0-58'/>
-<use x='160.737015' y='65.753425' xlink:href='#g0-115'/>
-<use x='166.251021' y='65.753425' xlink:href='#g0-112'/>
-<use x='172.126164' y='65.753425' xlink:href='#g0-101'/>
-<use x='177.551604' y='65.753425' xlink:href='#g0-99'/>
-<use x='182.589592' y='65.753425' xlink:href='#g0-58'/>
-<use x='185.841254' y='65.753425' xlink:href='#g0-99'/>
-<use x='190.879242' y='65.753425' xlink:href='#g0-111'/>
-<use x='196.50668' y='65.753425' xlink:href='#g0-110'/>
-<use x='203.494285' y='65.753425' xlink:href='#g0-116'/>
-<use x='207.721445' y='65.753425' xlink:href='#g0-97'/>
-<use x='213.866389' y='65.753425' xlink:href='#g0-105'/>
-<use x='217.859822' y='65.753425' xlink:href='#g0-110'/>
-<use x='224.847427' y='65.753425' xlink:href='#g0-101'/>
-<use x='230.272867' y='65.753425' xlink:href='#g0-114'/>
-<use x='235.873341' y='65.753425' xlink:href='#g0-115'/>
-<use x='241.387347' y='65.753425' xlink:href='#g1-91'/>
-<use x='244.639008' y='65.753425' xlink:href='#g0-105'/>
-<use x='248.63244' y='65.753425' xlink:href='#g1-93'/>
-<use x='251.884101' y='65.753425' xlink:href='#g0-58'/>
-<use x='255.135763' y='65.753425' xlink:href='#g0-114'/>
-<use x='260.736236' y='65.753425' xlink:href='#g0-101'/>
-<use x='266.161676' y='65.753425' xlink:href='#g0-115'/>
-<use x='271.675682' y='65.753425' xlink:href='#g0-111'/>
-<use x='277.303119' y='65.753425' xlink:href='#g0-117'/>
-<use x='283.965559' y='65.753425' xlink:href='#g0-114'/>
-<use x='289.566032' y='65.753425' xlink:href='#g0-99'/>
-<use x='294.604021' y='65.753425' xlink:href='#g0-101'/>
-<use x='300.029461' y='65.753425' xlink:href='#g0-115'/>
-<use x='305.543467' y='65.753425' xlink:href='#g0-58'/>
-<use x='308.795128' y='65.753425' xlink:href='#g0-114'/>
-<use x='314.395601' y='65.753425' xlink:href='#g0-101'/>
-<use x='319.821042' y='65.753425' xlink:href='#g0-113'/>
-<use x='325.440198' y='65.753425' xlink:href='#g0-117'/>
-<use x='332.102638' y='65.753425' xlink:href='#g0-101'/>
-<use x='337.528078' y='65.753425' xlink:href='#g0-115'/>
-<use x='343.042083' y='65.753425' xlink:href='#g0-116'/>
-<use x='347.269243' y='65.753425' xlink:href='#g0-115'/>
-<use x='352.783249' y='65.753425' xlink:href='#g1-91'/>
-<use x='356.03491' y='65.753425' xlink:href='#g0-109'/>
-<use x='366.274177' y='65.753425' xlink:href='#g0-101'/>
-<use x='371.699617' y='65.753425' xlink:href='#g0-109'/>
-<use x='381.938884' y='65.753425' xlink:href='#g0-111'/>
-<use x='387.566322' y='65.753425' xlink:href='#g0-114'/>
-<use x='393.166795' y='65.753425' xlink:href='#g0-121'/>
-<use x='399.303447' y='65.753425' xlink:href='#g1-93'/>
-</g>
-</svg>

content/en/blog/_posts/2021-11-26-memory-qos-cgroups-v2/index.md

@@ -1,118 +0,0 @@
----
-layout: blog
-title: 'Quality-of-Service for Memory Resources'
-date: 2021-11-26
-slug: qos-memory-resources
----
-
-**Authors:** Tim Xu (Tencent Cloud)
-
-Kubernetes v1.22, released in August 2021, introduced a new alpha feature that improves how Linux nodes implement memory resource requests and limits.
-
-In prior releases, Kubernetes did not support memory quality guarantees. 
-For example, if you set container resources as follows:
-```
-apiVersion: v1
-kind: Pod
-metadata:
-  name: example
-spec:
-  containers:
-  - name: nginx
-    resources:
-      requests:
-        memory: "64Mi"
-        cpu: "250m"
-      limits:
-        memory: "64Mi"
-        cpu: "500m"
-```
-`spec.containers[].resources.requests`(e.g. cpu, memory) is designed for scheduling. When you create a Pod, the Kubernetes scheduler selects a node for the Pod to run on. Each node has a maximum capacity for each of the resource types: the amount of CPU and memory it can provide for Pods. The scheduler ensures that, for each resource type, the sum of the resource requests of the scheduled Containers is less than the capacity of the node.
-
-`spec.containers[].resources.limits` is passed to the container runtime when the kubelet starts a container. CPU is considered a "compressible" resource. If your app starts hitting your CPU limits, Kubernetes starts throttling your container, giving your app potentially worse performance. However, it won’t be terminated. That is what "compressible" means.
-
-In cgroup v1, and prior to this feature, the container runtime never took into account and effectively ignored spec.containers[].resources.requests["memory"]. This is unlike CPU, in which the container runtime consider both requests and limits. Furthermore, memory actually can't be compressed in cgroup v1. Because there is no way to throttle memory usage, if a container goes past its memory limit it will be terminated by the kernel with an OOM (Out of Memory) kill.
-
-Fortunately, cgroup v2 brings a new design and implementation to achieve full protection on memory. The new feature relies on cgroups v2 which most current operating system releases for Linux already provide. With this experimental feature, [quality-of-service for pods and containers](/docs/tasks/configure-pod-container/quality-service-pod/) extends to cover not just CPU time but memory as well.
-
-## How does it work?
-Memory QoS uses the memory controller of cgroup v2 to guarantee memory resources in Kubernetes. Memory requests and limits of containers in pod are used to set specific interfaces `memory.min` and `memory.high` provided by the memory controller. When `memory.min` is set to memory requests, memory resources are reserved and never reclaimed by the kernel; this is how Memory QoS ensures the availability of memory for Kubernetes pods. And if memory limits are set in the container, this means that the system needs to limit container memory usage, Memory QoS uses `memory.high` to throttle workload approaching it's memory limit, ensuring that the system is not overwhelmed by instantaneous memory allocation.
-
-![](./memory-qos-cal.svg)
-
-The following table details the specific functions of these two parameters and how they correspond to Kubernetes container resources.
-
-<table>
-    <tr>
-        <th style="text-align:center">File</th>
-        <th style="text-align:center">Description</th>
-   </tr>
-   <tr>
-        <td>memory.min</td>
-        <td><code>memory.min</code> specifies a minimum amount of memory the cgroup must always retain, i.e., memory that can never be reclaimed by the system. If the cgroup's memory usage reaches this low limit and can’t be increased, the system OOM killer will be invoked.
-        <br>
-        <br>
-        <i>We map it to the container's memory request</i>
-        </td>
-   </tr>
-   <tr>
-       <td>memory.high</td>
-       <td><code>memory.high</code> is the memory usage throttle limit. This is the main mechanism to control a cgroup's memory use. If a cgroup's memory use goes over the high boundary specified here, the cgroup’s processes are throttled and put under heavy reclaim pressure. The default is max, meaning there is no limit. 
-       <br>
-       <br>
-       <i>We use a formula to calculate <code>memory.high</code>, depending on container's memory limit or node allocatable memory (if container's memory limit is empty) and a throttling factor. Please refer to the KEP for more details on the formula.</i>
-       </td>
-   </tr>
-</table>
-
-When container memory requests are made, kubelet passes `memory.min` to the back-end CRI runtime (possibly containerd, cri-o) via the `Unified` field in CRI during container creation. The `memory.min` in container level cgroup will be set to:  
-
-![](./container-memory-min.svg)  
-<sub>i: the i<sup>th</sup> container in one pod</sub>
-
-Since the `memory.min` interface requires that the ancestor cgroup directories are all set, the pod and node cgroup directories need to be set correctly. 
-
-`memory.min` in pod level cgroup:  
-![](./pod-memory-min.svg)  
-<sub>i: the i<sup>th</sup> container in one pod</sub>
-
-`memory.min` in node level cgroup:  
-![](./node-memory-min.svg)  
-<sub>i: the i<sup>th</sup> pod in one node, j: the j<sup>th</sup> container in one pod</sub>
-
-Kubelet will manage the cgroup hierarchy of the pod level and node level cgroups directly using runc libcontainer library, while container cgroup limits are managed by the container runtime.
-
-For memory limits, in addition to the original way of limiting memory usage, Memory QoS adds an additional feature of throttling memory allocation. A throttling factor is introduced as a multiplier (default is 0.8). If the result of multiplying memory limits by the factor is greater than memory requests, kubelet will set `memory.high` to the value and use `Unified` via CRI. And if the container does not specify memory limits, kubelet will use node allocatable memory instead. The `memory.high` in container level cgroup is set to:
-
-![](./container-memory-high.svg)  
-<sub>i: the i<sup>th</sup> container in one pod</sub>
-
-This can can help improve stability when pod memory usage increases, ensuring that memory is throttled as it approaches the memory limit.
-
-## How do I use it?
-Here are the prerequisites for enabling Memory QoS on your Linux node, some of these are related to [Kubernetes support for cgroup v2](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2254-cgroup-v2).
-
-1. Kubernetes since v1.22
-2. [runc](https://github.com/opencontainers/runc) since v1.0.0-rc93; [containerd](https://containerd.io/) since 1.4; [cri-o](https://cri-o.io/) since 1.20
-3. Linux kernel minimum version: 4.15, recommended version: 5.2+
-4. Linux image with cgroupv2 enabled or enabling cgroupv2 unified_cgroup_hierarchy manually
-
-OCI runtimes such as runc and crun already support cgroups v2 [`Unified`](https://github.com/opencontainers/runtime-spec/blob/master/config-linux.md#unified), and Kubernetes CRI has also made the desired changes to support passing [`Unified`](https://github.com/kubernetes/kubernetes/pull/102578). However, CRI Runtime support is required as well. Memory QoS in Alpha phase is designed to support containerd and cri-o. Related PR [Feature: containerd-cri support LinuxContainerResources.Unified #5627](https://github.com/containerd/containerd/pull/5627) has been merged and will be released in containerd 1.6. CRI-O [implement kube alpha features for 1.22 #5207](https://github.com/cri-o/cri-o/pull/5207) is still in WIP.
-
-With those prerequisites met, you can enable the memory QoS feature gate (see [Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/)).
-    
-## How can I learn more?
-
-You can find more details as follows:
-- [Support Memory QoS with cgroup v2](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2570-memory-qos/#readme)
-- [cgroup v2](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2254-cgroup-v2/#readme)
-
-## How do I get involved?
-You can reach SIG Node by several means:
-- Slack: [#sig-node](https://kubernetes.slack.com/messages/sig-node)
-- [Mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-node)
-- [Open Community Issues/PRs](https://github.com/kubernetes/community/labels/sig%2Fnode)
-
-You can also contact me directly:
-- GitHub / Slack: @xiaoxubeii
-- Email: xiaoxubeii@gmail.com

content/en/blog/_posts/2021-11-26-memory-qos-cgroups-v2/node-memory-min.svg

@@ -1,98 +0,0 @@
-<?xml version='1.0' encoding='UTF-8'?>
-<!-- Generated by CodeCogs with dvisvgm 2.9.1 -->
-<svg version='1.1' xmlns='http://www.w3.org/2000/svg' xmlns:xlink='http://www.w3.org/1999/xlink' width='446.671233pt' height='30.306891pt' viewBox='-.239051 -.248234 446.671233 30.306891'>
-<defs>
-<path id='g0-88' d='M15.135243 16.737235L16.581818 12.911582H16.282939C15.816687 14.154919 14.54944 14.96787 13.174595 15.326526C12.923537 15.386301 11.75193 15.697136 9.456538 15.697136H2.247572L8.332752 8.5599C8.416438 8.464259 8.440349 8.428394 8.440349 8.368618C8.440349 8.344707 8.440349 8.308842 8.356663 8.18929L2.785554 .573848H9.336986C10.938979 .573848 12.026899 .74122 12.134496 .765131C12.780075 .860772 13.820174 1.06401 14.764633 1.661768C15.063512 1.853051 15.876463 2.391034 16.282939 3.359402H16.581818L15.135243 0H1.004234C.729265 0 .71731 .011955 .681445 .083686C.669489 .119552 .669489 .3467 .669489 .478207L6.993773 9.133748L.800996 16.390535C.681445 16.533998 .681445 16.593773 .681445 16.605729C.681445 16.737235 .789041 16.737235 1.004234 16.737235H15.135243Z'/>
-<path id='g1-105' d='M2.375093-4.97335C2.375093-5.148692 2.247572-5.276214 2.064259-5.276214C1.857036-5.276214 1.625903-5.084932 1.625903-4.845828C1.625903-4.670486 1.753425-4.542964 1.936737-4.542964C2.14396-4.542964 2.375093-4.734247 2.375093-4.97335ZM1.211457-2.048319L.781071-.948443C.74122-.828892 .70137-.73325 .70137-.597758C.70137-.207223 1.004234 .079701 1.42665 .079701C2.199751 .079701 2.526526-1.036115 2.526526-1.139726C2.526526-1.219427 2.462765-1.243337 2.406974-1.243337C2.311333-1.243337 2.295392-1.187547 2.271482-1.107846C2.088169-.470237 1.761395-.143462 1.44259-.143462C1.346949-.143462 1.251308-.183313 1.251308-.398506C1.251308-.589788 1.307098-.73325 1.41071-.980324C1.490411-1.195517 1.570112-1.41071 1.657783-1.625903L1.904857-2.271482C1.976588-2.454795 2.072229-2.701868 2.072229-2.83736C2.072229-3.235866 1.753425-3.514819 1.346949-3.514819C.573848-3.514819 .239103-2.399004 .239103-2.295392C.239103-2.223661 .294894-2.191781 .358655-2.191781C.462267-2.191781 .470237-2.239601 .494147-2.319303C.71731-3.076463 1.083935-3.291656 1.323039-3.291656C1.43462-3.291656 1.514321-3.251806 1.514321-3.028643C1.514321-2.948941 1.506351-2.83736 1.42665-2.598257L1.211457-2.048319Z'/>
-<path id='g1-106' d='M3.291656-4.97335C3.291656-5.124782 3.172105-5.276214 2.980822-5.276214C2.741719-5.276214 2.534496-5.053051 2.534496-4.845828C2.534496-4.694396 2.654047-4.542964 2.84533-4.542964C3.084433-4.542964 3.291656-4.766127 3.291656-4.97335ZM1.625903 .398506C1.506351 .884682 1.115816 1.40274 .629639 1.40274C.502117 1.40274 .382565 1.370859 .366625 1.362889C.613699 1.243337 .645579 1.028144 .645579 .956413C.645579 .765131 .502117 .661519 .334745 .661519C.103611 .661519-.111582 .860772-.111582 1.123786C-.111582 1.42665 .183313 1.625903 .637609 1.625903C1.123786 1.625903 2.000498 1.323039 2.239601 .366625L2.956912-2.486675C2.980822-2.582316 2.996762-2.646077 2.996762-2.765629C2.996762-3.203985 2.646077-3.514819 2.183811-3.514819C1.338979-3.514819 .844832-2.399004 .844832-2.295392C.844832-2.223661 .900623-2.191781 .964384-2.191781C1.052055-2.191781 1.060025-2.215691 1.115816-2.335243C1.354919-2.885181 1.761395-3.291656 2.1599-3.291656C2.327273-3.291656 2.422914-3.180075 2.422914-2.917061C2.422914-2.805479 2.399004-2.693898 2.375093-2.582316L1.625903 .398506Z'/>
-<path id='g3-61' d='M8.069738-3.873474C8.237111-3.873474 8.452304-3.873474 8.452304-4.088667C8.452304-4.315816 8.249066-4.315816 8.069738-4.315816H1.028144C.860772-4.315816 .645579-4.315816 .645579-4.100623C.645579-3.873474 .848817-3.873474 1.028144-3.873474H8.069738ZM8.069738-1.649813C8.237111-1.649813 8.452304-1.649813 8.452304-1.865006C8.452304-2.092154 8.249066-2.092154 8.069738-2.092154H1.028144C.860772-2.092154 .645579-2.092154 .645579-1.876961C.645579-1.649813 .848817-1.649813 1.028144-1.649813H8.069738Z'/>
-<path id='g3-91' d='M2.988792 2.988792V2.546451H1.829141V-8.524035H2.988792V-8.966376H1.3868V2.988792H2.988792Z'/>
-<path id='g3-93' d='M1.853051-8.966376H.251059V-8.524035H1.41071V2.546451H.251059V2.988792H1.853051V-8.966376Z'/>
-<path id='g2-58' d='M2.199751-.573848C2.199751-.920548 1.912827-1.159651 1.625903-1.159651C1.279203-1.159651 1.0401-.872727 1.0401-.585803C1.0401-.239103 1.327024 0 1.613948 0C1.960648 0 2.199751-.286924 2.199751-.573848Z'/>
-<path id='g2-97' d='M3.598506-1.422665C3.53873-1.219427 3.53873-1.195517 3.371357-.968369C3.108344-.633624 2.582316-.119552 2.020423-.119552C1.530262-.119552 1.255293-.561893 1.255293-1.267248C1.255293-1.924782 1.625903-3.263761 1.853051-3.765878C2.259527-4.60274 2.82142-5.033126 3.287671-5.033126C4.076712-5.033126 4.23213-4.052802 4.23213-3.957161C4.23213-3.945205 4.196264-3.789788 4.184309-3.765878L3.598506-1.422665ZM4.363636-4.483188C4.23213-4.794022 3.90934-5.272229 3.287671-5.272229C1.936737-5.272229 .478207-3.526775 .478207-1.75741C.478207-.573848 1.171606 .119552 1.984558 .119552C2.642092 .119552 3.203985-.394521 3.53873-.789041C3.658281-.083686 4.220174 .119552 4.578829 .119552S5.224408-.095641 5.439601-.526027C5.630884-.932503 5.798257-1.661768 5.798257-1.709589C5.798257-1.769365 5.750436-1.817186 5.678705-1.817186C5.571108-1.817186 5.559153-1.75741 5.511333-1.578082C5.332005-.872727 5.104857-.119552 4.614695-.119552C4.267995-.119552 4.244085-.430386 4.244085-.669489C4.244085-.944458 4.27995-1.075965 4.387547-1.542217C4.471233-1.841096 4.531009-2.10411 4.62665-2.450809C5.068991-4.244085 5.176588-4.674471 5.176588-4.746202C5.176588-4.913574 5.045081-5.045081 4.865753-5.045081C4.483188-5.045081 4.387547-4.62665 4.363636-4.483188Z'/>
-<path id='g2-99' d='M4.674471-4.495143C4.447323-4.495143 4.339726-4.495143 4.172354-4.351681C4.100623-4.291905 3.969116-4.112578 3.969116-3.921295C3.969116-3.682192 4.148443-3.53873 4.375592-3.53873C4.662516-3.53873 4.985305-3.777833 4.985305-4.25604C4.985305-4.829888 4.435367-5.272229 3.610461-5.272229C2.044334-5.272229 .478207-3.56264 .478207-1.865006C.478207-.824907 1.123786 .119552 2.343213 .119552C3.969116 .119552 4.99726-1.147696 4.99726-1.303113C4.99726-1.374844 4.925529-1.43462 4.877709-1.43462C4.841843-1.43462 4.829888-1.422665 4.722291-1.315068C3.957161-.298879 2.82142-.119552 2.367123-.119552C1.542217-.119552 1.279203-.836862 1.279203-1.43462C1.279203-1.853051 1.482441-3.012702 1.912827-3.825654C2.223661-4.387547 2.86924-5.033126 3.622416-5.033126C3.777833-5.033126 4.435367-5.009215 4.674471-4.495143Z'/>
-<path id='g2-100' d='M6.01345-7.998007C6.025405-8.045828 6.049315-8.117559 6.049315-8.177335C6.049315-8.296887 5.929763-8.296887 5.905853-8.296887C5.893898-8.296887 5.308095-8.249066 5.248319-8.237111C5.045081-8.225156 4.865753-8.201245 4.65056-8.18929C4.351681-8.16538 4.267995-8.153425 4.267995-7.938232C4.267995-7.81868 4.363636-7.81868 4.531009-7.81868C5.116812-7.81868 5.128767-7.711083 5.128767-7.591532C5.128767-7.519801 5.104857-7.424159 5.092902-7.388294L4.363636-4.483188C4.23213-4.794022 3.90934-5.272229 3.287671-5.272229C1.936737-5.272229 .478207-3.526775 .478207-1.75741C.478207-.573848 1.171606 .119552 1.984558 .119552C2.642092 .119552 3.203985-.394521 3.53873-.789041C3.658281-.083686 4.220174 .119552 4.578829 .119552S5.224408-.095641 5.439601-.526027C5.630884-.932503 5.798257-1.661768 5.798257-1.709589C5.798257-1.769365 5.750436-1.817186 5.678705-1.817186C5.571108-1.817186 5.559153-1.75741 5.511333-1.578082C5.332005-.872727 5.104857-.119552 4.614695-.119552C4.267995-.119552 4.244085-.430386 4.244085-.669489C4.244085-.71731 4.244085-.968369 4.327771-1.303113L6.01345-7.998007ZM3.598506-1.422665C3.53873-1.219427 3.53873-1.195517 3.371357-.968369C3.108344-.633624 2.582316-.119552 2.020423-.119552C1.530262-.119552 1.255293-.561893 1.255293-1.267248C1.255293-1.924782 1.625903-3.263761 1.853051-3.765878C2.259527-4.60274 2.82142-5.033126 3.287671-5.033126C4.076712-5.033126 4.23213-4.052802 4.23213-3.957161C4.23213-3.945205 4.196264-3.789788 4.184309-3.765878L3.598506-1.422665Z'/>
-<path id='g2-101' d='M2.139975-2.773599C2.462765-2.773599 3.275716-2.797509 3.849564-3.012702C4.758157-3.359402 4.841843-4.052802 4.841843-4.267995C4.841843-4.794022 4.387547-5.272229 3.598506-5.272229C2.343213-5.272229 .537983-4.136488 .537983-2.008468C.537983-.753176 1.255293 .119552 2.343213 .119552C3.969116 .119552 4.99726-1.147696 4.99726-1.303113C4.99726-1.374844 4.925529-1.43462 4.877709-1.43462C4.841843-1.43462 4.829888-1.422665 4.722291-1.315068C3.957161-.298879 2.82142-.119552 2.367123-.119552C1.685679-.119552 1.327024-.657534 1.327024-1.542217C1.327024-1.709589 1.327024-2.008468 1.506351-2.773599H2.139975ZM1.566127-3.012702C2.080199-4.853798 3.21594-5.033126 3.598506-5.033126C4.124533-5.033126 4.483188-4.722291 4.483188-4.267995C4.483188-3.012702 2.570361-3.012702 2.068244-3.012702H1.566127Z'/>
-<path id='g2-105' d='M3.383313-1.709589C3.383313-1.769365 3.335492-1.817186 3.263761-1.817186C3.156164-1.817186 3.144209-1.78132 3.084433-1.578082C2.773599-.490162 2.283437-.119552 1.888917-.119552C1.745455-.119552 1.578082-.155417 1.578082-.514072C1.578082-.836862 1.721544-1.195517 1.853051-1.554172L2.689913-3.777833C2.725778-3.873474 2.809465-4.088667 2.809465-4.315816C2.809465-4.817933 2.450809-5.272229 1.865006-5.272229C.765131-5.272229 .32279-3.53873 .32279-3.443088C.32279-3.395268 .37061-3.335492 .454296-3.335492C.561893-3.335492 .573848-3.383313 .621669-3.550685C.908593-4.554919 1.362889-5.033126 1.829141-5.033126C1.936737-5.033126 2.139975-5.021171 2.139975-4.638605C2.139975-4.327771 1.984558-3.93325 1.888917-3.670237L1.052055-1.446575C.980324-1.255293 .908593-1.06401 .908593-.848817C.908593-.310834 1.279203 .119552 1.853051 .119552C2.952927 .119552 3.383313-1.625903 3.383313-1.709589ZM3.287671-7.460025C3.287671-7.639352 3.144209-7.854545 2.881196-7.854545C2.606227-7.854545 2.295392-7.591532 2.295392-7.280697C2.295392-6.981818 2.546451-6.886177 2.689913-6.886177C3.012702-6.886177 3.287671-7.197011 3.287671-7.460025Z'/>
-<path id='g2-106' d='M4.184309-3.789788C4.23213-3.981071 4.23213-4.148443 4.23213-4.196264C4.23213-4.889664 3.718057-5.272229 3.180075-5.272229C1.972603-5.272229 1.327024-3.526775 1.327024-3.443088C1.327024-3.383313 1.374844-3.335492 1.446575-3.335492C1.542217-3.335492 1.554172-3.383313 1.613948-3.502864C2.092154-4.662516 2.689913-5.033126 3.144209-5.033126C3.395268-5.033126 3.526775-4.901619 3.526775-4.483188C3.526775-4.196264 3.490909-4.076712 3.443088-3.861519L2.307347 .645579C2.080199 1.530262 1.518306 2.199751 .860772 2.199751C.812951 2.199751 .561893 2.199751 .334745 2.080199C.621669 2.020423 .848817 1.793275 .848817 1.506351C.848817 1.315068 .705355 1.123786 .442341 1.123786C.131507 1.123786-.155417 1.3868-.155417 1.745455C-.155417 2.235616 .37061 2.438854 .860772 2.438854C1.685679 2.438854 2.773599 1.829141 3.072478 .633624L4.184309-3.789788ZM4.674471-7.460025C4.674471-7.758904 4.423412-7.854545 4.27995-7.854545C3.957161-7.854545 3.682192-7.543711 3.682192-7.280697C3.682192-7.10137 3.825654-6.886177 4.088667-6.886177C4.363636-6.886177 4.674471-7.149191 4.674471-7.460025Z'/>
-<path id='g2-109' d='M2.462765-3.502864C2.486675-3.574595 2.785554-4.172354 3.227895-4.554919C3.53873-4.841843 3.945205-5.033126 4.411457-5.033126C4.889664-5.033126 5.057036-4.674471 5.057036-4.196264C5.057036-4.124533 5.057036-3.88543 4.913574-3.323537L4.614695-2.092154C4.519054-1.733499 4.291905-.848817 4.267995-.71731C4.220174-.537983 4.148443-.227148 4.148443-.179328C4.148443-.011955 4.27995 .119552 4.459278 .119552C4.817933 .119552 4.877709-.155417 4.985305-.585803L5.702615-3.443088C5.726526-3.53873 6.348194-5.033126 7.663263-5.033126C8.141469-5.033126 8.308842-4.674471 8.308842-4.196264C8.308842-3.526775 7.84259-2.223661 7.579577-1.506351C7.47198-1.219427 7.412204-1.06401 7.412204-.848817C7.412204-.310834 7.782814 .119552 8.356663 .119552C9.468493 .119552 9.886924-1.637858 9.886924-1.709589C9.886924-1.769365 9.839103-1.817186 9.767372-1.817186C9.659776-1.817186 9.647821-1.78132 9.588045-1.578082C9.313076-.621669 8.870735-.119552 8.392528-.119552C8.272976-.119552 8.081694-.131507 8.081694-.514072C8.081694-.824907 8.225156-1.207472 8.272976-1.338979C8.488169-1.912827 9.026152-3.323537 9.026152-4.016936C9.026152-4.734247 8.607721-5.272229 7.699128-5.272229C6.898132-5.272229 6.252553-4.817933 5.774346-4.112578C5.738481-4.758157 5.34396-5.272229 4.447323-5.272229C3.383313-5.272229 2.82142-4.519054 2.606227-4.220174C2.570361-4.901619 2.080199-5.272229 1.554172-5.272229C1.207472-5.272229 .932503-5.104857 .705355-4.65056C.490162-4.220174 .32279-3.490909 .32279-3.443088S.37061-3.335492 .454296-3.335492C.549938-3.335492 .561893-3.347447 .633624-3.622416C.812951-4.327771 1.0401-5.033126 1.518306-5.033126C1.793275-5.033126 1.888917-4.841843 1.888917-4.483188C1.888917-4.220174 1.769365-3.753923 1.685679-3.383313L1.350934-2.092154C1.303113-1.865006 1.171606-1.327024 1.111831-1.111831C1.028144-.800996 .896638-.239103 .896638-.179328C.896638-.011955 1.028144 .119552 1.207472 .119552C1.350934 .119552 1.518306 .047821 1.613948-.131507C1.637858-.191283 1.745455-.609714 1.80523-.848817L2.068244-1.924782L2.462765-3.502864Z'/>
-<path id='g2-110' d='M2.462765-3.502864C2.486675-3.574595 2.785554-4.172354 3.227895-4.554919C3.53873-4.841843 3.945205-5.033126 4.411457-5.033126C4.889664-5.033126 5.057036-4.674471 5.057036-4.196264C5.057036-3.514819 4.566874-2.15193 4.327771-1.506351C4.220174-1.219427 4.160399-1.06401 4.160399-.848817C4.160399-.310834 4.531009 .119552 5.104857 .119552C6.216687 .119552 6.635118-1.637858 6.635118-1.709589C6.635118-1.769365 6.587298-1.817186 6.515567-1.817186C6.40797-1.817186 6.396015-1.78132 6.336239-1.578082C6.06127-.597758 5.606974-.119552 5.140722-.119552C5.021171-.119552 4.829888-.131507 4.829888-.514072C4.829888-.812951 4.961395-1.171606 5.033126-1.338979C5.272229-1.996513 5.774346-3.335492 5.774346-4.016936C5.774346-4.734247 5.355915-5.272229 4.447323-5.272229C3.383313-5.272229 2.82142-4.519054 2.606227-4.220174C2.570361-4.901619 2.080199-5.272229 1.554172-5.272229C1.171606-5.272229 .908593-5.045081 .705355-4.638605C.490162-4.208219 .32279-3.490909 .32279-3.443088S.37061-3.335492 .454296-3.335492C.549938-3.335492 .561893-3.347447 .633624-3.622416C.824907-4.351681 1.0401-5.033126 1.518306-5.033126C1.793275-5.033126 1.888917-4.841843 1.888917-4.483188C1.888917-4.220174 1.769365-3.753923 1.685679-3.383313L1.350934-2.092154C1.303113-1.865006 1.171606-1.327024 1.111831-1.111831C1.028144-.800996 .896638-.239103 .896638-.179328C.896638-.011955 1.028144 .119552 1.207472 .119552C1.350934 .119552 1.518306 .047821 1.613948-.131507C1.637858-.191283 1.745455-.609714 1.80523-.848817L2.068244-1.924782L2.462765-3.502864Z'/>
-<path id='g2-111' d='M5.451557-3.287671C5.451557-4.423412 4.710336-5.272229 3.622416-5.272229C2.044334-5.272229 .490162-3.550685 .490162-1.865006C.490162-.729265 1.231382 .119552 2.319303 .119552C3.90934 .119552 5.451557-1.601993 5.451557-3.287671ZM2.331258-.119552C1.733499-.119552 1.291158-.597758 1.291158-1.43462C1.291158-1.984558 1.578082-3.203985 1.912827-3.801743C2.450809-4.722291 3.120299-5.033126 3.610461-5.033126C4.196264-5.033126 4.65056-4.554919 4.65056-3.718057C4.65056-3.239851 4.399502-1.960648 3.945205-1.231382C3.455044-.430386 2.797509-.119552 2.331258-.119552Z'/>
-<path id='g2-112' d='M.514072 1.518306C.430386 1.876961 .382565 1.972603-.107597 1.972603C-.251059 1.972603-.37061 1.972603-.37061 2.199751C-.37061 2.223661-.358655 2.319303-.227148 2.319303C-.071731 2.319303 .095641 2.295392 .251059 2.295392H.765131C1.016189 2.295392 1.625903 2.319303 1.876961 2.319303C1.948692 2.319303 2.092154 2.319303 2.092154 2.10411C2.092154 1.972603 2.008468 1.972603 1.80523 1.972603C1.255293 1.972603 1.219427 1.888917 1.219427 1.793275C1.219427 1.649813 1.75741-.406476 1.829141-.681445C1.960648-.3467 2.283437 .119552 2.905106 .119552C4.25604 .119552 5.71457-1.637858 5.71457-3.395268C5.71457-4.495143 5.092902-5.272229 4.196264-5.272229C3.431133-5.272229 2.785554-4.531009 2.654047-4.363636C2.558406-4.961395 2.092154-5.272229 1.613948-5.272229C1.267248-5.272229 .992279-5.104857 .765131-4.65056C.549938-4.220174 .382565-3.490909 .382565-3.443088S.430386-3.335492 .514072-3.335492C.609714-3.335492 .621669-3.347447 .6934-3.622416C.872727-4.327771 1.099875-5.033126 1.578082-5.033126C1.853051-5.033126 1.948692-4.841843 1.948692-4.483188C1.948692-4.196264 1.912827-4.076712 1.865006-3.861519L.514072 1.518306ZM2.582316-3.730012C2.666002-4.064757 3.000747-4.411457 3.19203-4.578829C3.323537-4.698381 3.718057-5.033126 4.172354-5.033126C4.698381-5.033126 4.937484-4.507098 4.937484-3.88543C4.937484-3.311582 4.60274-1.960648 4.303861-1.338979C4.004981-.6934 3.455044-.119552 2.905106-.119552C2.092154-.119552 1.960648-1.147696 1.960648-1.195517C1.960648-1.231382 1.984558-1.327024 1.996513-1.3868L2.582316-3.730012Z'/>
-<path id='g2-113' d='M5.272229-5.152677C5.272229-5.212453 5.224408-5.260274 5.164633-5.260274C5.068991-5.260274 4.60274-4.829888 4.375592-4.411457C4.160399-4.94944 3.789788-5.272229 3.275716-5.272229C1.924782-5.272229 .466252-3.526775 .466252-1.75741C.466252-.573848 1.159651 .119552 1.972603 .119552C2.606227 .119552 3.132254-.358655 3.383313-.633624L3.395268-.621669L2.940971 1.171606L2.833375 1.601993C2.725778 1.960648 2.546451 1.960648 1.984558 1.972603C1.853051 1.972603 1.733499 1.972603 1.733499 2.199751C1.733499 2.283437 1.80523 2.319303 1.888917 2.319303C2.056289 2.319303 2.271482 2.295392 2.438854 2.295392H3.658281C3.837609 2.295392 4.040847 2.319303 4.220174 2.319303C4.291905 2.319303 4.435367 2.319303 4.435367 2.092154C4.435367 1.972603 4.339726 1.972603 4.160399 1.972603C3.598506 1.972603 3.56264 1.888917 3.56264 1.793275C3.56264 1.733499 3.574595 1.721544 3.610461 1.566127L5.272229-5.152677ZM3.58655-1.422665C3.526775-1.219427 3.526775-1.195517 3.359402-.968369C3.096389-.633624 2.570361-.119552 2.008468-.119552C1.518306-.119552 1.243337-.561893 1.243337-1.267248C1.243337-1.924782 1.613948-3.263761 1.841096-3.765878C2.247572-4.60274 2.809465-5.033126 3.275716-5.033126C4.064757-5.033126 4.220174-4.052802 4.220174-3.957161C4.220174-3.945205 4.184309-3.789788 4.172354-3.765878L3.58655-1.422665Z'/>
-<path id='g2-114' d='M4.65056-4.889664C4.27995-4.817933 4.088667-4.554919 4.088667-4.291905C4.088667-4.004981 4.315816-3.90934 4.483188-3.90934C4.817933-3.90934 5.092902-4.196264 5.092902-4.554919C5.092902-4.937484 4.722291-5.272229 4.124533-5.272229C3.646326-5.272229 3.096389-5.057036 2.594271-4.327771C2.510585-4.961395 2.032379-5.272229 1.554172-5.272229C1.08792-5.272229 .848817-4.913574 .705355-4.65056C.502117-4.220174 .32279-3.502864 .32279-3.443088C.32279-3.395268 .37061-3.335492 .454296-3.335492C.549938-3.335492 .561893-3.347447 .633624-3.622416C.812951-4.339726 1.0401-5.033126 1.518306-5.033126C1.80523-5.033126 1.888917-4.829888 1.888917-4.483188C1.888917-4.220174 1.769365-3.753923 1.685679-3.383313L1.350934-2.092154C1.303113-1.865006 1.171606-1.327024 1.111831-1.111831C1.028144-.800996 .896638-.239103 .896638-.179328C.896638-.011955 1.028144 .119552 1.207472 .119552C1.338979 .119552 1.566127 .035866 1.637858-.203238C1.673724-.298879 2.116065-2.10411 2.187796-2.379078C2.247572-2.642092 2.319303-2.893151 2.379078-3.156164C2.426899-3.323537 2.47472-3.514819 2.510585-3.670237C2.546451-3.777833 2.86924-4.363636 3.16812-4.62665C3.311582-4.758157 3.622416-5.033126 4.112578-5.033126C4.303861-5.033126 4.495143-4.99726 4.65056-4.889664Z'/>
-<path id='g2-115' d='M2.725778-2.391034C2.929016-2.355168 3.251806-2.283437 3.323537-2.271482C3.478954-2.223661 4.016936-2.032379 4.016936-1.458531C4.016936-1.08792 3.682192-.119552 2.295392-.119552C2.044334-.119552 1.147696-.155417 .908593-.812951C1.3868-.753176 1.625903-1.123786 1.625903-1.3868C1.625903-1.637858 1.458531-1.769365 1.219427-1.769365C.956413-1.769365 .609714-1.566127 .609714-1.028144C.609714-.32279 1.327024 .119552 2.283437 .119552C4.100623 .119552 4.638605-1.219427 4.638605-1.841096C4.638605-2.020423 4.638605-2.355168 4.25604-2.737733C3.957161-3.024658 3.670237-3.084433 3.024658-3.21594C2.701868-3.287671 2.187796-3.395268 2.187796-3.93325C2.187796-4.172354 2.402989-5.033126 3.53873-5.033126C4.040847-5.033126 4.531009-4.841843 4.65056-4.411457C4.124533-4.411457 4.100623-3.957161 4.100623-3.945205C4.100623-3.694147 4.327771-3.622416 4.435367-3.622416C4.60274-3.622416 4.937484-3.753923 4.937484-4.25604S4.483188-5.272229 3.550685-5.272229C1.984558-5.272229 1.566127-4.040847 1.566127-3.550685C1.566127-2.642092 2.450809-2.450809 2.725778-2.391034Z'/>
-<path id='g2-116' d='M2.402989-4.805978H3.502864C3.730012-4.805978 3.849564-4.805978 3.849564-5.021171C3.849564-5.152677 3.777833-5.152677 3.53873-5.152677H2.486675L2.929016-6.898132C2.976837-7.065504 2.976837-7.089415 2.976837-7.173101C2.976837-7.364384 2.82142-7.47198 2.666002-7.47198C2.570361-7.47198 2.295392-7.436115 2.199751-7.053549L1.733499-5.152677H.609714C.37061-5.152677 .263014-5.152677 .263014-4.925529C.263014-4.805978 .3467-4.805978 .573848-4.805978H1.637858L.848817-1.649813C.753176-1.231382 .71731-1.111831 .71731-.956413C.71731-.394521 1.111831 .119552 1.78132 .119552C2.988792 .119552 3.634371-1.625903 3.634371-1.709589C3.634371-1.78132 3.58655-1.817186 3.514819-1.817186C3.490909-1.817186 3.443088-1.817186 3.419178-1.769365C3.407223-1.75741 3.395268-1.745455 3.311582-1.554172C3.060523-.956413 2.510585-.119552 1.817186-.119552C1.458531-.119552 1.43462-.418431 1.43462-.681445C1.43462-.6934 1.43462-.920548 1.470486-1.06401L2.402989-4.805978Z'/>
-<path id='g2-117' d='M4.076712-.6934C4.23213-.02391 4.805978 .119552 5.092902 .119552C5.475467 .119552 5.762391-.131507 5.953674-.537983C6.156912-.968369 6.312329-1.673724 6.312329-1.709589C6.312329-1.769365 6.264508-1.817186 6.192777-1.817186C6.085181-1.817186 6.073225-1.75741 6.025405-1.578082C5.810212-.753176 5.595019-.119552 5.116812-.119552C4.758157-.119552 4.758157-.514072 4.758157-.669489C4.758157-.944458 4.794022-1.06401 4.913574-1.566127C4.99726-1.888917 5.080946-2.211706 5.152677-2.546451L5.642839-4.495143C5.726526-4.794022 5.726526-4.817933 5.726526-4.853798C5.726526-5.033126 5.583064-5.152677 5.403736-5.152677C5.057036-5.152677 4.97335-4.853798 4.901619-4.554919C4.782067-4.088667 4.136488-1.518306 4.052802-1.099875C4.040847-1.099875 3.574595-.119552 2.701868-.119552C2.080199-.119552 1.960648-.657534 1.960648-1.099875C1.960648-1.78132 2.295392-2.737733 2.606227-3.53873C2.749689-3.921295 2.809465-4.076712 2.809465-4.315816C2.809465-4.829888 2.438854-5.272229 1.865006-5.272229C.765131-5.272229 .32279-3.53873 .32279-3.443088C.32279-3.395268 .37061-3.335492 .454296-3.335492C.561893-3.335492 .573848-3.383313 .621669-3.550685C.908593-4.578829 1.374844-5.033126 1.829141-5.033126C1.948692-5.033126 2.139975-5.021171 2.139975-4.638605C2.139975-4.327771 2.008468-3.981071 1.829141-3.526775C1.303113-2.10411 1.243337-1.649813 1.243337-1.291158C1.243337-.071731 2.163885 .119552 2.654047 .119552C3.419178 .119552 3.837609-.406476 4.076712-.6934Z'/>
-<path id='g2-121' d='M3.144209 1.338979C2.82142 1.793275 2.355168 2.199751 1.769365 2.199751C1.625903 2.199751 1.052055 2.175841 .872727 1.625903C.908593 1.637858 .968369 1.637858 .992279 1.637858C1.350934 1.637858 1.590037 1.327024 1.590037 1.052055S1.362889 .681445 1.183562 .681445C.992279 .681445 .573848 .824907 .573848 1.41071C.573848 2.020423 1.08792 2.438854 1.769365 2.438854C2.964882 2.438854 4.172354 1.338979 4.507098 .011955L5.678705-4.65056C5.69066-4.710336 5.71457-4.782067 5.71457-4.853798C5.71457-5.033126 5.571108-5.152677 5.391781-5.152677C5.284184-5.152677 5.033126-5.104857 4.937484-4.746202L4.052802-1.231382C3.993026-1.016189 3.993026-.992279 3.897385-.860772C3.658281-.526027 3.263761-.119552 2.689913-.119552C2.020423-.119552 1.960648-.777086 1.960648-1.099875C1.960648-1.78132 2.283437-2.701868 2.606227-3.56264C2.737733-3.90934 2.809465-4.076712 2.809465-4.315816C2.809465-4.817933 2.450809-5.272229 1.865006-5.272229C.765131-5.272229 .32279-3.53873 .32279-3.443088C.32279-3.395268 .37061-3.335492 .454296-3.335492C.561893-3.335492 .573848-3.383313 .621669-3.550685C.908593-4.554919 1.362889-5.033126 1.829141-5.033126C1.936737-5.033126 2.139975-5.033126 2.139975-4.638605C2.139975-4.327771 2.008468-3.981071 1.829141-3.526775C1.243337-1.960648 1.243337-1.566127 1.243337-1.279203C1.243337-.143462 2.056289 .119552 2.654047 .119552C3.000747 .119552 3.431133 .011955 3.849564-.430386L3.861519-.418431C3.682192 .286924 3.56264 .753176 3.144209 1.338979Z'/>
-</defs>
-<g id='page1' transform='matrix(1.13 0 0 1.13 -63.986043 -66.444003)'>
-<use x='56.413267' y='69.937791' xlink:href='#g2-109'/>
-<use x='66.652534' y='69.937791' xlink:href='#g2-101'/>
-<use x='72.077974' y='69.937791' xlink:href='#g2-109'/>
-<use x='82.317241' y='69.937791' xlink:href='#g2-111'/>
-<use x='87.944679' y='69.937791' xlink:href='#g2-114'/>
-<use x='93.545152' y='69.937791' xlink:href='#g2-121'/>
-<use x='99.681804' y='69.937791' xlink:href='#g2-58'/>
-<use x='102.933465' y='69.937791' xlink:href='#g2-109'/>
-<use x='113.172732' y='69.937791' xlink:href='#g2-105'/>
-<use x='117.166164' y='69.937791' xlink:href='#g2-110'/>
-<use x='127.474599' y='69.937791' xlink:href='#g3-61'/>
-<use x='139.90008' y='58.580327' xlink:href='#g0-88'/>
-<use x='147.092819' y='83.774682' xlink:href='#g1-105'/>
-<use x='159.161195' y='58.580327' xlink:href='#g0-88'/>
-<use x='165.85349' y='83.774682' xlink:href='#g1-106'/>
-<use x='178.422309' y='69.937791' xlink:href='#g2-112'/>
-<use x='184.297452' y='69.937791' xlink:href='#g2-111'/>
-<use x='189.92489' y='69.937791' xlink:href='#g2-100'/>
-<use x='196.007582' y='69.937791' xlink:href='#g3-91'/>
-<use x='199.259244' y='69.937791' xlink:href='#g2-105'/>
-<use x='203.252676' y='69.937791' xlink:href='#g3-93'/>
-<use x='206.504337' y='69.937791' xlink:href='#g2-58'/>
-<use x='209.755998' y='69.937791' xlink:href='#g2-115'/>
-<use x='215.270004' y='69.937791' xlink:href='#g2-112'/>
-<use x='221.145147' y='69.937791' xlink:href='#g2-101'/>
-<use x='226.570587' y='69.937791' xlink:href='#g2-99'/>
-<use x='231.608576' y='69.937791' xlink:href='#g2-58'/>
-<use x='234.860237' y='69.937791' xlink:href='#g2-99'/>
-<use x='239.898226' y='69.937791' xlink:href='#g2-111'/>
-<use x='245.525663' y='69.937791' xlink:href='#g2-110'/>
-<use x='252.513269' y='69.937791' xlink:href='#g2-116'/>
-<use x='256.740429' y='69.937791' xlink:href='#g2-97'/>
-<use x='262.885373' y='69.937791' xlink:href='#g2-105'/>
-<use x='266.878805' y='69.937791' xlink:href='#g2-110'/>
-<use x='273.866411' y='69.937791' xlink:href='#g2-101'/>
-<use x='279.291851' y='69.937791' xlink:href='#g2-114'/>
-<use x='284.892324' y='69.937791' xlink:href='#g2-115'/>
-<use x='290.40633' y='69.937791' xlink:href='#g3-91'/>
-<use x='293.657991' y='69.937791' xlink:href='#g2-106'/>
-<use x='299.173487' y='69.937791' xlink:href='#g3-93'/>
-<use x='302.425148' y='69.937791' xlink:href='#g2-58'/>
-<use x='305.676809' y='69.937791' xlink:href='#g2-114'/>
-<use x='311.277283' y='69.937791' xlink:href='#g2-101'/>
-<use x='316.702723' y='69.937791' xlink:href='#g2-115'/>
-<use x='322.216728' y='69.937791' xlink:href='#g2-111'/>
-<use x='327.844166' y='69.937791' xlink:href='#g2-117'/>
-<use x='334.506606' y='69.937791' xlink:href='#g2-114'/>
-<use x='340.107079' y='69.937791' xlink:href='#g2-99'/>
-<use x='345.145068' y='69.937791' xlink:href='#g2-101'/>
-<use x='350.570508' y='69.937791' xlink:href='#g2-115'/>
-<use x='356.084513' y='69.937791' xlink:href='#g2-58'/>
-<use x='359.336175' y='69.937791' xlink:href='#g2-114'/>
-<use x='364.936648' y='69.937791' xlink:href='#g2-101'/>
-<use x='370.362088' y='69.937791' xlink:href='#g2-113'/>
-<use x='375.981245' y='69.937791' xlink:href='#g2-117'/>
-<use x='382.643684' y='69.937791' xlink:href='#g2-101'/>
-<use x='388.069124' y='69.937791' xlink:href='#g2-115'/>
-<use x='393.58313' y='69.937791' xlink:href='#g2-116'/>
-<use x='397.81029' y='69.937791' xlink:href='#g2-115'/>
-<use x='403.324295' y='69.937791' xlink:href='#g3-91'/>
-<use x='406.575957' y='69.937791' xlink:href='#g2-109'/>
-<use x='416.815224' y='69.937791' xlink:href='#g2-101'/>
-<use x='422.240664' y='69.937791' xlink:href='#g2-109'/>
-<use x='432.479931' y='69.937791' xlink:href='#g2-111'/>
-<use x='438.107368' y='69.937791' xlink:href='#g2-114'/>
-<use x='443.707842' y='69.937791' xlink:href='#g2-121'/>
-<use x='449.844493' y='69.937791' xlink:href='#g3-93'/>
-</g>
-</svg>