Compare commits

..

32 Commits

Author SHA1 Message Date
Nate W 40e3e07733 Merge pull request #33336 from nate-double-u/update-release-1.21-config.toml
update release-1.21 config.toml for release 1.24
2022-05-03 16:13:10 -07:00
Nate W aaa5a59792 update release-1.21 config.toml for release 1.24
Signed-off-by: Nate W <4453979+nate-double-u@users.noreply.github.com>
2022-04-29 13:55:14 -07:00
Kubernetes Prow Robot 21f5f1a34d Merge pull request #31377 from sftim/20211207_mark_only_live_site_indexable_v1.21
Mark only live site indexable (v1.21 backport)
2022-01-27 11:03:49 -08:00
Tim Bannister d6f7243168 Mark live site in HTML
This allows CSS, JavaScript etc to detect if the served website is the
live one.
2022-01-17 22:33:54 +00:00
Tim Bannister 61214a707c Make only live website indexable
This change updates how we run Hugo AND changes the logic for checking
whether a page should be indexable (copied with a backport from upstream
Docsy).
2022-01-17 22:33:54 +00:00
Kubernetes Prow Robot 552099c1e8 Merge pull request #30767 from jlbutler/update-121-config-for-123
update release-1.21 config for release 1.23
2021-12-07 15:59:22 -08:00
Jesse Butler 899f88e6fb update release-1.21 config for release 1.23 2021-12-06 11:39:52 -05:00
Kubernetes Prow Robot 722543fcb2 Merge pull request #30600 from kubernetes/dev-1.21-ko.8
[ko] 8th Korean localization work for release-1.21
2021-11-22 19:10:16 -08:00
Kubernetes Prow Robot 4dd537066d Merge pull request #30481 from jihoon-seo/211115_Update_outdated_files_in_dev-1.21-ko.8
[ko] Update outdated in dev-1.21-ko.8 (M13-M40)
2021-11-22 03:49:09 -08:00
Kubernetes Prow Robot 9db19fb922 Merge pull request #30483 from jihoon-seo/211115_ko_Update_links_in_dev-1.21-ko.8
[ko] Update links in dev-1.21-ko.8
2021-11-15 18:23:26 -08:00
Kubernetes Prow Robot 171f7e570c Merge pull request #30416 from seokho-son/out-1.21-ko.8-m6
[ko] Update outdated in dev-1.21-ko.8 (M6-M9)
2021-11-14 21:58:47 -08:00
Kubernetes Prow Robot e87745da8d Merge pull request #30415 from seokho-son/out-1.21-ko.8-m1
[ko] Update outdated in dev-1.21-ko.8 (M1-M5)
2021-11-14 21:56:47 -08:00
Jihoon Seo b1737a87a7 [ko] Update links in dev-1.21-ko.8 2021-11-15 14:38:04 +09:00
Jihoon Seo 29e8f27983 [ko] Update outdated in dev-1.21-ko.8 (M13-M40) 2021-11-15 14:14:47 +09:00
Kubernetes Prow Robot 1e35724ca0 Merge pull request #30418 from seokho-son/out-1.21-ko.8-m41
[ko] Update outdated in dev-1.21-ko.8 (M41-M45)
2021-11-14 18:46:47 -08:00
Kubernetes Prow Robot 7827c02b8e Merge pull request #30417 from seokho-son/out-1.21-ko.8-m10
[ko] Update outdated in dev-1.21-ko.8 (M10-M12)
2021-11-14 18:44:49 -08:00
Seokho Son b1bacf38e2 Update outdated in dev-1.21-ko.8 (M41-M45) 2021-11-14 18:30:14 +09:00
Seokho Son 1ef330fe33 Update outdated in dev-1.21-ko.8 (M10-M12) 2021-11-14 18:24:03 +09:00
Seokho Son e43e7523f5 Update outdated in dev-1.21-ko.8 (M6-M9) 2021-11-14 18:12:23 +09:00
Seokho Son f98830bd39 Update outdated in dev-1.21-ko.8 (M1-M5) 2021-11-14 18:02:03 +09:00
Kubernetes Prow Robot f5229ca882 Merge pull request #30420 from seokho-son/out-1.21-ko.8-m51
[ko] Update outdated in dev-1.21-ko.8 (M51-M55)
2021-11-13 22:06:46 -08:00
Kubernetes Prow Robot ae43ec1bfe Merge pull request #30419 from seokho-son/out-1.21-ko.8-m46
[ko] Update outdated in dev-1.21-ko.8 (M46-M50)
2021-11-13 22:04:47 -08:00
Seokho Son 6675a04821 Update outdated in dev-1.21-ko.8 (M51-M55) 2021-11-10 00:45:57 +09:00
Seokho Son 4700d78095 Update outdated in dev-1.21-ko.8 (M46-M50) 2021-11-10 00:32:07 +09:00
Kubernetes Prow Robot df6cb680e7 Merge pull request #30292 from gochist/dev-1.21-ko.7
[ko] 7th Korean localization work for v1.21
2021-10-28 11:35:00 -07:00
Kubernetes Prow Robot 4e9df579f1 Merge pull request #29754 from reylejano/kubeadm-upgrade-backport-1.21
Update kubeadm upgrade page to use current branch (backport from main and release-1.20)
2021-09-21 18:30:01 -07:00
Rey Lejano a39553d328 update kubeadm upgrade page to use current branch 2021-09-20 13:27:33 -07:00
Kubernetes Prow Robot 2c4f453203 Merge pull request #29331 from dgrisonnet/29323-release-1.21
release-1.21: Update recommended events API
2021-08-12 05:03:47 -07:00
Damien Grisonnet 5d8a406419 kubernetes-api: update recommended events API
In Kubernetes v1.19, the new Events API events.k8s.io was promoted to
v1. As such it now supersedes the original core Events API.

Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
2021-08-11 15:31:09 +02:00
Damien Grisonnet 734db472e2 api-ref-generator: update to include Event changes
Update api-ref-generator submodule to 55bce68 to include changes
updating the recommended Events API from core to events.k8s.io in the
kubernetes-api doc.

Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
2021-08-11 15:30:07 +02:00
Kubernetes Prow Robot 9b94f198c3 Merge pull request #29219 from PI-Victor/config/update-release-1.21
Update config.toml for release-1.21 branch
2021-08-04 15:55:12 -07:00
Victor Palade 828a1bb210 config.toml: update dropdown
This commit will bump all the versions according to the latest
release patches.

Signed-off-by: Victor Palade <victor@cloudflavor.io>
2021-08-04 19:27:19 +02:00
1138 changed files with 19987 additions and 174507 deletions
-3
View File
@@ -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
+5 -6
View File
@@ -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.
+14 -12
View File
@@ -28,14 +28,14 @@ module-init:
all: build ## Build site with production settings and put deliverables in ./public
build: module-check ## Build site with production settings and put deliverables in ./public
hugo --minify
build: module-check ## Build site with non-production settings and put deliverables in ./public
hugo --minify --environment development
build-preview: module-check ## Build site with drafts and future posts enabled
hugo --buildDrafts --buildFuture
hugo --buildDrafts --buildFuture --environment preview
deploy-preview: ## Deploy preview site via netlify
hugo --enableGitInfo --buildFuture -b $(DEPLOY_PRIME_URL)
hugo --enableGitInfo --buildFuture --environment preview -b $(DEPLOY_PRIME_URL)
functions-build:
$(NETLIFY_FUNC) build functions-src
@@ -43,13 +43,15 @@ functions-build:
check-headers-file:
scripts/check-headers-file.sh
production-build: build check-headers-file ## Build the production site and ensure that noindex headers aren't added
production-build: module-check ## Build the production site and ensure that noindex headers aren't added
hugo --minify --environment production
HUGO_ENV=production $(MAKE) check-headers-file
non-production-build: ## Build the non-production site, which adds noindex headers to prevent indexing
hugo --enableGitInfo
non-production-build: module-check ## Build the non-production site, which adds noindex headers to prevent indexing
hugo --enableGitInfo --environment nonprod
serve: module-check ## Boot the development server.
hugo server --buildFuture
hugo server --buildFuture --environment development
docker-image:
@echo -e "$(CCRED)**** The use of docker-image is deprecated. Use container-image instead. ****$(CCEND)"
@@ -70,10 +72,10 @@ container-image: ## Build a container image for the preview of the website
--build-arg HUGO_VERSION=$(HUGO_VERSION)
container-build: module-check
$(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify"
$(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify --environment development"
container-serve: module-check ## Boot the development server using container. Run `make container-image` before this.
$(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir
$(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --environment development --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir
test-examples:
scripts/test_examples.sh install
@@ -88,7 +90,7 @@ docker-internal-linkcheck:
$(MAKE) container-internal-linkcheck
container-internal-linkcheck: link-checker-image-pull
$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture
$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture --environment test
$(CONTAINER_ENGINE) run --mount type=bind,source=$(CURDIR),target=/test --rm wjdp/htmltest htmltest
clean-api-reference: ## Clean all directories in API reference directory, preserve _index.md
@@ -96,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
-2
View File
@@ -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
+16 -17
View File
@@ -1,8 +1,10 @@
aliases:
sig-docs-blog-owners: # Approvers for blog content
- kbarnard10
- onlydole
- mrbobbytables
sig-docs-blog-reviewers: # Reviewers for blog content
- kbarnard10
- mrbobbytables
- onlydole
- sftim
@@ -18,9 +20,9 @@ aliases:
- annajung
- bradtopol
- celestehorgan
- divya-mohan0209
- irvifa
- jimangel
- jlbutler
- kbarnard10
- kbhawkey
- onlydole
- pi-victor
@@ -32,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
@@ -76,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
@@ -96,6 +96,7 @@ aliases:
- danninov
- girikuncoro
- habibrosyad
- irvifa
- phanama
- wahyuoi
sig-docs-it-owners: # Admins for Italian content
@@ -132,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
@@ -168,7 +169,6 @@ aliases:
- xichengliudui
# zhangxiaoyu-zidif
sig-docs-pt-owners: # Admins for Portuguese content
- edsoncelio
- femrtnz
- jailton
- jcjesus
@@ -177,7 +177,6 @@ aliases:
- rikatz
- yagonobre
sig-docs-pt-reviews: # PR reviews for Portugese content
- edsoncelio
- femrtnz
- jailton
- jcjesus
@@ -225,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
@@ -257,4 +256,4 @@ aliases:
- sethmccombs # Release Manager Associate
- thejoycekung # Release Manager Associate
- verolop # Release Manager Associate
- wilsonehusin # Release Manager Associate
- wilsonehusin # Release Manager Associate
+2 -5
View File
@@ -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)
## स्थानीय रूप से डॉकर का उपयोग करके साइट चलाना
+2 -4
View File
@@ -18,7 +18,7 @@ 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:
@@ -43,9 +43,7 @@ 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?
+1 -1
View File
@@ -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/). Мы благодарим вас за желание внести свой вклад!
+16 -9
View File
@@ -73,15 +73,23 @@ To update the reference pages for a new Kubernetes release (replace v1.20 in the
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:
```
curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json
```
```bash
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 @@ curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi
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
+3
View File
@@ -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
+4 -3
View File
@@ -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
File diff suppressed because it is too large Load Diff
-696
View File
@@ -1,696 +0,0 @@
- definition: io.k8s.api.core.v1.PodSpec
field_categories:
- name: Containers
fields:
- containers
- initContainers
- imagePullSecrets
- enableServiceLinks
- 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:
- preemptionPolicy
- overhead
- name: Alpha level
fields:
- ephemeralContainers
- 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
- 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: Not allowed
fields:
- ports
- resources
- lifecycle
- livenessProbe
- readinessProbe
- securityContext
- 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
- 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
- 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.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
-267
View File
@@ -1,267 +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
- Handler
- 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: 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: v1beta1
- name: PriorityLevelConfiguration
group: flowcontrol.apiserver.k8s.io
version: v1beta1
- 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
@@ -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 */}}
-85
View File
@@ -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 */}}
-17
View File
@@ -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.
-->
+16 -4
View File
@@ -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;
+70 -214
View File
@@ -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;
}
@@ -320,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;
@@ -392,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;
@@ -568,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 */
@@ -593,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 {
@@ -615,97 +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;
}
}
// 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;
@@ -713,76 +642,3 @@ body.td-documentation {
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;
}
}
-8
View File
@@ -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));
}
}
+1 -1
View File
@@ -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
+21 -24
View File
@@ -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,12 +138,12 @@ 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.22.4"
version = "v1.22"
githubbranch = "v1.22.4"
docsbranch = "release-1.22"
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)
+4 -4
View File
@@ -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-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Besuche die KubeCon North America vom 11. bis 15. Oktober 2021</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-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Besuche die KubeCon Europe vom 17. bis 20. Mai 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 >}}
+51 -246
View File
@@ -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>
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
-2
View File
@@ -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/)
@@ -5,7 +5,7 @@ weight: 20
<!DOCTYPE html>
<html lang="de">
<html lang="en">
<body>
@@ -5,7 +5,7 @@ weight: 20
<!DOCTYPE html>
<html lang="de">
<html lang="en">
<body>
@@ -5,7 +5,7 @@ weight: 10
<!DOCTYPE html>
<html lang="de">
<html lang="en">
<body>
@@ -5,7 +5,7 @@ weight: 20
<!DOCTYPE html>
<html lang="de">
<html lang="en">
<body>
@@ -5,7 +5,7 @@ weight: 10
<!DOCTYPE html>
<html lang="de">
<html lang="en">
<body>
@@ -5,7 +5,7 @@ weight: 20
<!DOCTYPE html>
<html lang="de">
<html lang="en">
<body>
@@ -5,7 +5,7 @@ weight: 10
<!DOCTYPE html>
<html lang="de">
<html lang="en">
<body>
-201
View File
@@ -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;
}
}
+78 -40
View File
@@ -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>
-137
View File
@@ -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>
+5 -5
View File
@@ -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=kccncna21" 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>
@@ -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 its 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-).&nbsp;
Namespaces are easy to create and use but its 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/).&nbsp;
@@ -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**
@@ -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 well 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.
@@ -144,9 +144,10 @@ ways to address it.
- Specifically add an iptables rule to drop the packets that are marked as
*INVALID*, so it wont 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 didnt 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
@@ -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
@@ -28,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?
@@ -42,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?
@@ -190,9 +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.
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
@@ -200,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
@@ -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}
@@ -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)
Were 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: Heres 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: Heres 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 youd 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 youre 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 youd 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 whats 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)
@@ -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.
## Whats 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
@@ -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.
@@ -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). Were 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)
@@ -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)
Binary file not shown.

Before

Width:  |  Height:  |  Size: 71 KiB

@@ -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!
@@ -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
@@ -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
@@ -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!
@@ -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!
@@ -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 &ndash; the volume can be mounted as read-write by a single node
- ReadOnlyMany &ndash; the volume can be mounted read-only by many nodes
- ReadWriteMany &ndash; 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 &ndash; 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)
## Whats 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 youre 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).
Were rapidly growing and always welcome new contributors.
@@ -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 havent 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 youd 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 whats 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 youd 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!
@@ -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?
Its 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.** Thats 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. Theres 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,
its much quicker and usually doesnt 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 cant mount another applications
[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, its 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.
Heres 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 its 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 youre using the GCP cloud, you can get the snapshot ID from the gcloud command by querying for the snapshots 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 its 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 doesnt 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, its 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. Its 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, its 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.**
@@ -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_
@@ -1,141 +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!
## Whats 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 tutorial](https://cluster-api.sigs.k8s.io/tasks/experimental-features/cluster-classes.html) in the Cluster API book.
@@ -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.
@@ -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 committees 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 rounds 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._
@@ -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.
@@ -1,59 +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.
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.
**Please fill out this survey: https://forms.gle/svCJmhvTv78jGdSx8**.
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.
**We are collecting opinions through this survey: [https://forms.gle/svCJmhvTv78jGdSx8](https://forms.gle/svCJmhvTv78jGdSx8)**
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!
File diff suppressed because one or more lines are too long

Before

Width:  |  Height:  |  Size: 25 KiB

@@ -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>

Before

Width:  |  Height:  |  Size: 23 KiB

@@ -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 wont 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 cant 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 cgroups 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
File diff suppressed because one or more lines are too long

Before

Width:  |  Height:  |  Size: 63 KiB

@@ -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>

Before

Width:  |  Height:  |  Size: 28 KiB

@@ -1,97 +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='411.32491pt' height='36.683306pt' viewBox='-.239051 -.232683 411.32491 36.683306'>
<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='g3-48' d='M3.897385-2.542466C3.897385-3.395268 3.809714-3.913325 3.5467-4.423412C3.196015-5.124782 2.550436-5.300125 2.11208-5.300125C1.107846-5.300125 .74122-4.550934 .629639-4.327771C.342715-3.745953 .326775-2.956912 .326775-2.542466C.326775-2.016438 .350685-1.211457 .73325-.573848C1.099875 .01594 1.689664 .167372 2.11208 .167372C2.494645 .167372 3.180075 .047821 3.57858-.74122C3.873474-1.315068 3.897385-2.024408 3.897385-2.542466ZM2.11208-.055791C1.841096-.055791 1.291158-.183313 1.123786-1.020174C1.036115-1.474471 1.036115-2.223661 1.036115-2.638107C1.036115-3.188045 1.036115-3.745953 1.123786-4.184309C1.291158-4.99726 1.912827-5.076961 2.11208-5.076961C2.383064-5.076961 2.933001-4.941469 3.092403-4.216189C3.188045-3.777833 3.188045-3.180075 3.188045-2.638107C3.188045-2.16787 3.188045-1.45056 3.092403-1.004234C2.925031-.167372 2.375093-.055791 2.11208-.055791Z'/>
<path id='g3-61' d='M5.826152-2.654047C5.945704-2.654047 6.105106-2.654047 6.105106-2.83736S5.913823-3.020672 5.794271-3.020672H.781071C.661519-3.020672 .470237-3.020672 .470237-2.83736S.629639-2.654047 .749191-2.654047H5.826152ZM5.794271-.964384C5.913823-.964384 6.105106-.964384 6.105106-1.147696S5.945704-1.331009 5.826152-1.331009H.749191C.629639-1.331009 .470237-1.331009 .470237-1.147696S.661519-.964384 .781071-.964384H5.794271Z'/>
<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-110' d='M1.594022-1.307098C1.617933-1.42665 1.697634-1.729514 1.721544-1.849066C1.833126-2.279452 1.833126-2.287422 2.016438-2.550436C2.279452-2.940971 2.654047-3.291656 3.188045-3.291656C3.474969-3.291656 3.642341-3.124284 3.642341-2.749689C3.642341-2.311333 3.307597-1.40274 3.156164-1.012204C3.052553-.749191 3.052553-.70137 3.052553-.597758C3.052553-.143462 3.427148 .079701 3.769863 .079701C4.550934 .079701 4.877709-1.036115 4.877709-1.139726C4.877709-1.219427 4.813948-1.243337 4.758157-1.243337C4.662516-1.243337 4.646575-1.187547 4.622665-1.107846C4.431382-.454296 4.096638-.143462 3.793773-.143462C3.666252-.143462 3.602491-.223163 3.602491-.406476S3.666252-.765131 3.745953-.964384C3.865504-1.267248 4.216189-2.183811 4.216189-2.630137C4.216189-3.227895 3.801743-3.514819 3.227895-3.514819C2.582316-3.514819 2.16787-3.124284 1.936737-2.82142C1.880946-3.259776 1.530262-3.514819 1.123786-3.514819C.836862-3.514819 .637609-3.331507 .510087-3.084433C.318804-2.709838 .239103-2.311333 .239103-2.295392C.239103-2.223661 .294894-2.191781 .358655-2.191781C.462267-2.191781 .470237-2.223661 .526027-2.430884C.621669-2.82142 .765131-3.291656 1.099875-3.291656C1.307098-3.291656 1.354919-3.092403 1.354919-2.917061C1.354919-2.773599 1.315068-2.622167 1.251308-2.359153C1.235367-2.295392 1.115816-1.825156 1.083935-1.713574L.789041-.518057C.757161-.398506 .70934-.199253 .70934-.167372C.70934 .01594 .860772 .079701 .964384 .079701C1.107846 .079701 1.227397-.01594 1.283188-.111582C1.307098-.159402 1.370859-.430386 1.41071-.597758L1.594022-1.307098Z'/>
<path id='g4-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='g4-91' d='M2.988792 2.988792V2.546451H1.829141V-8.524035H2.988792V-8.966376H1.3868V2.988792H2.988792Z'/>
<path id='g4-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-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 -62.281577)'>
<use x='56.413267' y='73.369366' xlink:href='#g2-109'/>
<use x='66.652534' y='73.369366' xlink:href='#g2-101'/>
<use x='72.077974' y='73.369366' xlink:href='#g2-109'/>
<use x='82.317241' y='73.369366' xlink:href='#g2-111'/>
<use x='87.944679' y='73.369366' xlink:href='#g2-114'/>
<use x='93.545152' y='73.369366' xlink:href='#g2-121'/>
<use x='99.681804' y='73.369366' xlink:href='#g2-58'/>
<use x='102.933465' y='73.369366' xlink:href='#g2-109'/>
<use x='113.172732' y='73.369366' xlink:href='#g2-105'/>
<use x='117.166164' y='73.369366' xlink:href='#g2-110'/>
<use x='127.474599' y='73.369366' xlink:href='#g4-61'/>
<use x='145.965287' y='58.425345' xlink:href='#g1-110'/>
<use x='139.90008' y='62.011901' xlink:href='#g0-88'/>
<use x='141.682474' y='87.206256' xlink:href='#g1-105'/>
<use x='144.565614' y='87.206256' xlink:href='#g3-61'/>
<use x='151.15212' y='87.206256' xlink:href='#g3-48'/>
<use x='159.161195' y='73.369366' xlink:href='#g2-112'/>
<use x='165.036338' y='73.369366' xlink:href='#g2-111'/>
<use x='170.663775' y='73.369366' xlink:href='#g2-100'/>
<use x='176.746468' y='73.369366' xlink:href='#g2-58'/>
<use x='179.998129' y='73.369366' xlink:href='#g2-115'/>
<use x='185.512135' y='73.369366' xlink:href='#g2-112'/>
<use x='191.387278' y='73.369366' xlink:href='#g2-101'/>
<use x='196.812718' y='73.369366' xlink:href='#g2-99'/>
<use x='201.850707' y='73.369366' xlink:href='#g2-58'/>
<use x='205.102368' y='73.369366' xlink:href='#g2-99'/>
<use x='210.140357' y='73.369366' xlink:href='#g2-111'/>
<use x='215.767794' y='73.369366' xlink:href='#g2-110'/>
<use x='222.7554' y='73.369366' xlink:href='#g2-116'/>
<use x='226.982559' y='73.369366' xlink:href='#g2-97'/>
<use x='233.127504' y='73.369366' xlink:href='#g2-105'/>
<use x='237.120936' y='73.369366' xlink:href='#g2-110'/>
<use x='244.108542' y='73.369366' xlink:href='#g2-101'/>
<use x='249.533982' y='73.369366' xlink:href='#g2-114'/>
<use x='255.134455' y='73.369366' xlink:href='#g2-115'/>
<use x='260.648461' y='73.369366' xlink:href='#g4-91'/>
<use x='263.900122' y='73.369366' xlink:href='#g2-105'/>
<use x='267.893554' y='73.369366' xlink:href='#g4-93'/>
<use x='271.145216' y='73.369366' xlink:href='#g2-58'/>
<use x='274.396877' y='73.369366' xlink:href='#g2-114'/>
<use x='279.99735' y='73.369366' xlink:href='#g2-101'/>
<use x='285.42279' y='73.369366' xlink:href='#g2-115'/>
<use x='290.936796' y='73.369366' xlink:href='#g2-111'/>
<use x='296.564234' y='73.369366' xlink:href='#g2-117'/>
<use x='303.226673' y='73.369366' xlink:href='#g2-114'/>
<use x='308.827147' y='73.369366' xlink:href='#g2-99'/>
<use x='313.865135' y='73.369366' xlink:href='#g2-101'/>
<use x='319.290575' y='73.369366' xlink:href='#g2-115'/>
<use x='324.804581' y='73.369366' xlink:href='#g2-58'/>
<use x='328.056242' y='73.369366' xlink:href='#g2-114'/>
<use x='333.656716' y='73.369366' xlink:href='#g2-101'/>
<use x='339.082156' y='73.369366' xlink:href='#g2-113'/>
<use x='344.701312' y='73.369366' xlink:href='#g2-117'/>
<use x='351.363752' y='73.369366' xlink:href='#g2-101'/>
<use x='356.789192' y='73.369366' xlink:href='#g2-115'/>
<use x='362.303198' y='73.369366' xlink:href='#g2-116'/>
<use x='366.530357' y='73.369366' xlink:href='#g2-115'/>
<use x='372.044363' y='73.369366' xlink:href='#g4-91'/>
<use x='375.296024' y='73.369366' xlink:href='#g2-109'/>
<use x='385.535291' y='73.369366' xlink:href='#g2-101'/>
<use x='390.960731' y='73.369366' xlink:href='#g2-109'/>
<use x='401.199998' y='73.369366' xlink:href='#g2-111'/>
<use x='406.827436' y='73.369366' xlink:href='#g2-114'/>
<use x='412.427909' y='73.369366' xlink:href='#g2-121'/>
<use x='418.564561' y='73.369366' xlink:href='#g4-93'/>
</g>
</svg>

Before

Width:  |  Height:  |  Size: 28 KiB

@@ -1,343 +0,0 @@
---
layout: blog
title: "Contribution, containers and cricket: the Kubernetes 1.22 release interview"
date: 2021-12-01
---
**Author**: Craig Box (Google)
The Kubernetes release train rolls on, and we look ahead to the release of 1.23 next week. [As is our tradition](https://www.google.com/search?q=%22release+interview%22+site%3Akubernetes.io%2Fblog), I'm pleased to bring you a look back at the process that brought us the previous version.
The release team for 1.22 was led by [Savitha Raghunathan](https://twitter.com/coffeeartgirl), who was, at the time, a Senior Platform Engineer at MathWorks. [I spoke to Savitha](https://kubernetespodcast.com/episode/157-kubernetes-1.22/) on the [Kubernetes Podcast from Google](https://kubernetespodcast.com/), the weekly<super>*</super> show covering the Kubernetes and Cloud Native ecosystem.
Our release conversations shine a light on the team that puts together each Kubernetes release. Make sure you [subscribe, wherever you get your podcasts](https://kubernetespodcast.com/subscribe/) so you catch the story of 1.23.
And in case you're interested in why the show has been on a hiatus the last few weeks, all will be revealed in the next episode!
*This transcript has been lightly edited and condensed for clarity.*
---
**CRAIG BOX: Welcome to the show, Savitha.**
SAVITHA RAGHUNATHAN: Hey, Craig. Thanks for having me on the show. How are you today?
**CRAIG BOX: I'm very well, thank you. I've interviewed a lot of people on the show, and you're actually the first person who's asked that of me.**
SAVITHA RAGHUNATHAN: I'm glad. It's something that I always do. I just want to make sure the other person is good and happy.
**CRAIG BOX: That's very kind of you. Thank you for kicking off on a wonderful foot there. I want to ask first of all — you grew up in Chennai. My association with Chennai is the [Super Kings cricket team](https://en.wikipedia.org/wiki/Chennai_Super_Kings). Was cricket part of your upbringing?**
SAVITHA RAGHUNATHAN: Yeah. Actually, a lot. My mom loves watching cricket. I have a younger brother, and when we were growing up, we used to play cricket on the terrace. Everyone surrounding me, my best friends — and even now, my partner — loves watching cricket, too. Cricket is a part of my life.
I stopped watching it a while ago, but I still enjoy a good game.
**CRAIG BOX: It's probably a bit harder in the US. Everything's in a different time zone. I find, with my cricket team being on the other side of the world, that it's a lot easier when they're playing near me, as opposed to trying to keep up with what they're doing when they're playing at 3:00 in the morning.**
SAVITHA RAGHUNATHAN: That is actually one of the things that made me lose touch with cricket. I'm going to give you a piece of interesting information. I never supported Chennai Super Kings. I always supported [Royal Challengers of Bangalore](https://en.wikipedia.org/wiki/Royal_Challengers_Bangalore).
I once went to the stadium, and it was a match between the Chennai Super Kings and the RCB. I was the only one who was cheering whenever the RCB hit a 6, or when they were scoring. I got the stares of thousands of people looking at me. I'm like, "what are you doing?" My friends are like, "you're going to get us killed! Just stop screaming!"
**CRAIG BOX: I hear you. As a New Zealander in the UK, there are a lot of international cricket matches I've been to where I am one of the few people dressed in the full beige kit. But I have to ask, why an affiliation with a different team?**
SAVITHA RAGHUNATHAN: I'm not sure. When the IPL came out, I really liked Virat Kohli. He was playing for RCB at that time, and I think pretty much that's it.
**CRAIG BOX: Well, what I know about the Chennai Super Kings is that their coach is New Zealand's finest batsmen and [air conditioning salesman](https://www.youtube.com/watch?v=vSZAaUCAclw), [Stephen Fleming](https://en.wikipedia.org/wiki/Stephen_Fleming).**
SAVITHA RAGHUNATHAN: Oh, really?
**CRAIG BOX: Yeah, he's a dead ringer for the guy who played the [yellow Wiggle](https://s1.reutersmedia.net/resources/r/?m=02&d=20061130&t=2&i=153531&w=&fh=545px&fw=&ll=&pl=&sq=&r=153531) back in the day.**
SAVITHA RAGHUNATHAN: Oh, interesting. I remember the name, but I cannot put the picture and the name together. I stopped watching cricket once I moved to the States. Then, all my focus was on studies and extracurriculars. I have always been an introvert. The campus — it was a new thing for me — they had international festivals.
And every week, they'd have some kind of new thing going on, so I'd go check them out. I wouldn't participate, but I did go out and check them out. That was a big feat for me around that time because a lot of people — and still, even now, a lot of people — they kind of scare me. I don't know how to make a conversation with everyone.
I'll just go and say, "hi, how are you? OK, I'm good. I'm just going to move on". And I'll just go to the next person. And after two hours, I'm out of that place.
**CRAIG BOX: Perhaps a pleasant side effect of the last 12 months — a lot fewer gatherings of people.**
SAVITHA RAGHUNATHAN: Could be that, but I'm so excited about KubeCon. But when I think about it, I'm like "oh my God. There's going to be a lot of people. What am I going to do? I'm going to meet all my friends over there".
Sometimes I have social anxiety like, what's going to happen?
**CRAIG BOX: What's going to happen is you're going to ask them how they are at the beginning, and they're immediately going to be set at ease.**
SAVITHA RAGHUNATHAN: *laughs* I hope so.
**CRAIG BOX: Let's talk a little bit, then, about your transition from India to the US. You did your undergraduate degree in computer science at the SSN College of Engineering. How did you end up at Arizona State?**
SAVITHA RAGHUNATHAN: I always wanted to pursue higher studies when I was in India, and I didn't have the opportunity immediately. Once I graduated from my school there, I went and I worked for a couple of years. My aim was always to get out of there and come here, do my graduate studies.
Eventually, I want to do a PhD. I have an idea of what I want to do. I always wanted to keep studying. If there's an option that I could just keep studying and not do work or anything of that sort, I'd just pick that other one — I'll just keep studying.
But unfortunately, you need money and other things to live and sustain in this world. So I'm like, OK, I'll take a break from studies, and I will work for a while.
**CRAIG BOX: The road to success is littered with dreams of PhDs. I have a lot of friends who thought that that was the path they were going to take, and they've had a beautiful career and probably aren't going to go back to study. Did you use the [Matlab](https://en.wikipedia.org/wiki/MATLAB) software at all while you were going through your schooling?**
SAVITHA RAGHUNATHAN: No, unfortunately. That is a question that everyone asks. I have not used Matlab. I haven't used it even now. I don't use it for work. I didn't have any necessity for my school work. I didn't have anything to do with Matlab. I never analysed, or did data processing, or anything, with Matlab. So unfortunately, no.
Everyone asks me like, you're working at [MathWorks](https://en.wikipedia.org/wiki/MathWorks). Have you used Matlab? I'm like, no.
**CRAIG BOX: Fair enough. Nor have I. But it's been around since the late 1970s, so I imagine there are a lot of people who will have come across it at some point. Do you work with a lot of people who have been working on it that whole time?**
SAVITHA RAGHUNATHAN: Kind of. Not all the time, but I get to meet some folks who work on the product itself. Most of my interactions are with the infrastructure team and platform engineering teams at MathWorks. One other interesting fact is that when I joined the company — MathWorks has an extensive internal curriculum for training and learning, which I really love. They have an "Intro to Matlab" course, and that's on my bucket of things to do.
It was like 500 years ago. I added it, and I never got to it. I'm like, OK, maybe this year at least I want to get to it and I want to learn something new. My partner used Matlab extensively. He misses it right now at his current employer. And he's like, "you have the entire licence! You have access to the entire suite and you haven't used it?" I'm like, "no!"
**CRAIG BOX: Well, I have bad news for the idea of you doing a PhD, I'm sorry.**
SAVITHA RAGHUNATHAN: Another thing is that none of my family knew about the company MathWorks and Matlab. The only person who knew was my younger brother. He was so proud. He was like, "oh my God".
When he was 12 years old, he started getting involved in robotics and all that stuff. That's how he got introduced to Matlab. He goes absolutely bananas for the swag. So all the t-shirts, all the hoodies — any swag that I get from MathWorks goes to him, without saying.
Over the five, six years, the things that I've got — there was only one sweatshirt that I kept for myself. Everything else I've just given to him. And he cherishes it. He's the only one in my family who knew about Matlab and MathWorks.
Now, everyone knows, because I'm working there. They were initially like, I don't even know that company name. Is it like Amazon? I'm like, no, we make software that can send people to the moon. And we also make software that can do amazing robotic surgeries and even make a car drive on its own. That's something that I take immense pride in.
I know I don't directly work on the product, but I'm enabling the people who are creating the product. I'm really, really proud of that.
**CRAIG BOX: I think Jeff Bezos is working on at least two out of three of those disciplines that you mentioned before, so it's maybe a little bit like Amazon. One thing I've always thought about Matlab is that, because it's called Matlab, it solves that whole problem where [Americans call it math, and the rest of the world call it maths](https://www.grammar.com/math_vs._maths). Why do Americans think there's only one math?**
SAVITHA RAGHUNATHAN: Definitely. I had trouble — growing up in India, it's always British English. And I had so much trouble when I moved here. So many things changed.
One of the things is maths. I always got used to writing maths, physics, and everything.
**CRAIG BOX: They don't call it "physic" in the US, do they?**
SAVITHA RAGHUNATHAN: No, no, they don't. Luckily, they don't. That still stays "physics". But math — I had trouble. It's maths. Even when you do the full abbreviations like mathematics and you are still calling it math, I'm like, mm.
**CRAIG BOX: They can do the computer science abbreviation thing and call it math-7-S or whatever the number of letters is.**
SAVITHA RAGHUNATHAN: Just like Kubernetes. K-8-s.
**CRAIG BOX: Your path to Kubernetes is through MathWorks. They started out as a company making software which was distributed in a physical sense — boxed copies, if you will. I understand now there is a cloud version. Can I assume that that is where the two worlds intersect?**
SAVITHA RAGHUNATHAN: Kind of. I have interaction with the team that supports Matlab on the cloud, but I don't get to work with them on a day-to-day basis. They use Docker containers, and they are building the platform using Kubernetes. So yeah, a little bit of that.
**CRAIG BOX: So what exactly is the platform that you are engineering day to day?**
SAVITHA RAGHUNATHAN: Providing Kubernetes as a platform, obviously — that goes without saying — to some of the internal development teams. In the future we might expand it to more teams within the company. That is a focus area right now, so that's what we are doing. In the process, we might even get to work with the people who are deploying Matlab on the cloud, which is exciting.
**CRAIG BOX: Now, your path to contribution to Kubernetes, you've said before, was through [fixing a 404 error on the Kubernetes.io website](https://github.com/kubernetes/website/pull/15588). Do you remember what the page was?**
SAVITHA RAGHUNATHAN: I do. I was going to something for work, and I came across this changelog. In Kubernetes there's a nice page — once you got to the release page, there would be a long list of changelogs.
One of the things that I fixed was, the person who worked on the feature had changed their GitHub handle, and that wasn't reflected on this page. So that was my first. I got curious and clicked on the links. One of the links was the handle, and that went to a 404. And I was like "Yeah, I'll just fix that. They have done all the hard work. They can get the credit that's due".
It was easy. It wasn't overwhelming for me to pick it up as my first issue. Before that I logged on around Kubernetes for about six to eight months without doing anything because it was just a lot.
**CRAIG BOX: One of the other things that you said about your initial contribution is that you had to learn how to use Git. As a very powerful tool, I find Git is a high barrier to entry for even contributing code to a project. When you want to contribute a blog post or documentation or a fix like you did before, I find it almost impossible to think how a new user would come along and do that. What was your process? Do you think that there's anything we can do to make that barrier lower for new contributors?**
SAVITHA RAGHUNATHAN: Of course. There are more and more tutorials available these days. There is a new contributor workshop. They actually have a [GitHub workflow section](https://www.kubernetes.dev/docs/guide/github-workflow/), [how to do a pull request](https://www.kubernetes.dev/docs/guide/pull-requests/) and stuff like that. I know a couple of folks from SIG Docs that are working on which Git commands that you need, or how to get to writing something small and getting it committed. But more tutorials or more links to intro to Git would definitely help.
The thing is also, someone like a documentation writer — they don't actually want to know the entirety of Git. Honestly, it's an ocean. I don't know how to do it. Most of the time, I still ask for help even though I work with Git on a day to day basis. There are several articles and a lot of help is available already within the community. Maybe we could just add a couple more to [kubernetes.dev](https://kubernetes.dev/). That is an amazing site for all the new contributors and existing contributors who want to build code, who want to write documentation.
We could just add a tutorial there like, "hey, don't know Git, you are new to Git? You just need to know these main things".
**CRAIG BOX: I find it a shame, to be honest, that people need to use Git for that, by comparison to Wikipedia where you can come along, and even though it might be written in Markdown or something like it, it seems like the barrier is a lot lower. Similar to you, I always have to look up anything more complicated than the five or six Git commands that I use on a day to day basis. Even to do simple things, I basically just go and follow a recipe which I find on the internet.**
SAVITHA RAGHUNATHAN: This is how I got introduced to one of the amazing mentors in Kubernetes. Everyone knows him by his handle, Dims. It was my second PR to the Kubernetes website, and I made a mistake. I destroyed the Git history. I could not push my reviews and comments — I addressed them. I couldn't push them back.
My immediate thought was to delete it and recreate, do another pull request. But then I was like, "what happens to others who have already put effort into reviewing them?" I asked for help, and Dims was there.
I would say I just got lucky he was there. And he was like, "OK, let me walk you through". We did troubleshooting through Slack messages. I copied and pasted all the errors. Every single command that he said, I copied and pasted. And then he was like, "OK, run this one. Try this one. And do this one".
Finally, I got it fixed. So you know what I did? I went and I stored the command history somewhere local for the next time when I run into this problem. Luckily, I haven't. But I find the contributors so helpful. They are busy. They have a lot of things to do, but they take moments to stop and help someone who's new.
That is also another part of the reason why I stay — I want to contribute more. It's mainly the community. It's the Kubernetes community. I know you asked me about Git, and I just took the conversation to the Kubernetes community. That's how my brain works.
**CRAIG BOX: A lot of people in the community do that and think that's fantastic, obviously, people like Dims who are just floating around on Slack and seem to have endless time. I don't know how they do it.**
SAVITHA RAGHUNATHAN: I really want to know the secret for endless time. If I only had 48 hours in a day. I would sleep for 16 hours, and I would use the rest of the time for doing the things that I want.
**CRAIG BOX: If I had a chance to sleep up to 48 hours a day, I think it'd be a lot more than 16.**
**Now, one of the areas that you've been contributing to Kubernetes is in the release team. In 1.18, you were a shadow for the docs role. You led that role in 1.19. And you were a release lead shadow for versions 1,20 and 1.21 before finally leading this release, 1.22, which we will talk about soon.**
**How did you get involved? And how did you decide which roles to take as you went through that process?**
SAVITHA RAGHUNATHAN: That is a topic I love to talk about. This was fresh when I started learning about Kubernetes and using Kubernetes at work. And I got so much help from the community, I got interested in contributing back.
At the first KubeCon that I attended in 2018, in Seattle, they had a speed mentoring session. Now they call it "pod mentoring". I went to the session, and said, "hey, I want to contribute. I don't know where to start". And I got a lot of information on how to get started.
One of the places was SIG Release and the release team. I came back and diligently attended all the SIG Release meetings for four to six months. And in between, I applied to the Kubernetes release team — 1.14 and 1.15. I didn't get through. So I took a little bit of a break, and I focused on doing some documentation work. Then I applied for 1.18.
Since I was already working on some kinds of — not like full fledged "documentation" documentation, I still don't write. I eventually want to write something really nice and full fledged documentation like other awesome folks.
**CRAIG BOX: You'll need a lot more than 48 hours in your day to do that.**
SAVITHA RAGHUNATHAN: *laughing* That's how I applied for the docs role, because I know a little bit about the website. I've done a few pull requests and commits. That's how I got started. I applied for that one role, and I got selected for the 1.18 team. That's how my journey just took off.
And the next release, I was leading the documentation team. And as everyone knows, the pandemic hit. It was one of the longest releases. I could lean back on the community. I would just wait for the release team meetings.
It was my way of coping with the pandemic. It took my mind off. It was actually more than a release team, they were people. They were all people first, and we took care of each other. So it felt good.
And then, I became a release lead shadow for 1.20 and 1.21 because I wanted to know more. I wanted to learn more. I wasn't ready. I still don't feel ready, but I have led 1.22. So if I could do it, anyone could do it.
**CRAIG BOX: How much of this work is day job?**
SAVITHA RAGHUNATHAN: I am lucky to be blessed with an awesome team. I do most of my work after work, but there have been times where I have to take meetings and attend to immediate urgent stuff. During the time of exception requests and stuff like that, I take a little bit of time from my work.
My team has been wonderful: they support me in all possible ways, and the management as well. Other than the meetings, I don't do much of the work during the day job. It just takes my focus and attention away too much, and I end up having to spend a lot of time sitting in front of the computer, which I don't like.
Before the pandemic I had a good work life balance. I'd just go to work at 7:00, 7:30, and I'd be back by 4 o'clock. I never touched my laptop ever again. I left all work behind when I came home. So right now, I'm still learning how to get through.
I try to limit the amount of open source work that I do during work time. The release lead shadow and the release lead job — they require a lot of time, effort. So on average, I'd be spending two to three hours post work time on the release activities.
**CRAIG BOX: Before the pandemic, everyone was worried that if we let people work from home, they wouldn't work enough. I think the opposite has actually happened, is that now we're worried that if we let people work from home, they will just get on the computer in the morning and you'll have to pry it out of their hands at midnight.**
SAVITHA RAGHUNATHAN: Yeah, I think the productivity has increased at least twofold, I would say, for everyone, once they started working from home.
**CRAIG BOX: But at the expense of work-life balance, though, because as you say, when you're sitting in the same chair in front of, perhaps, the same computer doing your MathWorks work and then your open source work, they kind of can blur into one perhaps?**
SAVITHA RAGHUNATHAN: That is a challenge. I face it every day. But so many others are also facing it. I implemented a few little tricks to help me. When I used to come back home from work, the first thing I would do is remove my watch. That was an indication that OK, I'm done.
That's the thing that I still do. I just remove my watch, and I just keep it right where my workstation is. And I just close the door so that I never look back. Even going past the room, I don't get a glimpse of my work office. I start implementing tiny little things like that to avoid burnout.
I think I'm still facing a little bit of burnout. I don't know if I have fully recovered from it. I constantly feel like I need a vacation. And I could just take a vacation for like a month or two. If it's possible, I will just do it.
**CRAIG BOX: I do hope that travel opens up for everyone as an opportunity because I know that, for a lot of people, it's not so much they've been working from home but they've been living at work. The idea of taking vacation effectively means, well, I've been stuck in the same place, if I've been under a lockdown. It's hard to justify that. It will be good as things improve worldwide for us to be able to start focusing more on mental health and perhaps getting away from the "everything room," as I sometimes call it.**
SAVITHA RAGHUNATHAN: I'm totally looking forward to it. I hope that travel opens up and I could go home and I could meet my siblings and my aunt and my parents.
**CRAIG BOX: Catch a cricket match?**
SAVITHA RAGHUNATHAN: Yeah. Probably yes, if I have company and if there is anything interesting happening around the time. I don't mind going back to the Chepauk Stadium and catching a match or two.
**CRAIG BOX: Let's turn now to the recently released [Kubernetes 1.22](https://kubernetes.io/blog/2021/08/04/kubernetes-1-22-release-announcement/). Congratulations on the launch.**
SAVITHA RAGHUNATHAN: Thank you.
**CRAIG BOX: Each launch comes with a theme and a mascot or a logo. What is the theme for this release?**
SAVITHA RAGHUNATHAN: The theme for the release is reaching new peaks. I am fascinated with a lot of space travel and chasing stars, the Milky Way. The best place to do that is over the top of a mountain. So that is the release logo, basically. It's a mountain — Mount Rainier. On top of that, there is a Kubernetes flag, and it's overlooking the Milky Way.
It's also symbolic that with every release, that we are achieving something new, bigger, and better, and we are making the release awesome. So I just wanted to incorporate that into the team as to say, we are achieving new things with every release. That's the "reaching new peaks" theme.
**CRAIG BOX: The last couple of releases have both been incrementally larger — as a result, perhaps, of the fact there are now only three releases per year rather than four. There were also changes to the process, where the work has been driven a lot more by the SIGs than by the release team having to go and ask the SIGs what was going on. What can you say about the size and scope of the 1.22 release?**
SAVITHA RAGHUNATHAN: The 1.22 release is the largest release to date. We have 56 enhancements if I'm not wrong, and we have a good amount of features that's graduated as stable. You can now say that Kubernetes as a project has become more mature because you see new features coming in. At the same time, you see the features that weren't used getting deprecated — we have like three deprecations in this release.
Aside from that fact, we also have a big team that's supporting one of the longest releases. This is the first official release cycle after the cadence KEP got approved. Officially, we are at four months, even though 1.19 was six months, and 1.21 was like 3 and 1/2 months, I think, this is the first one after the official KEP approval.
**CRAIG BOX: What changes did you make to the process knowing that you had that extra month?**
SAVITHA RAGHUNATHAN: One of the things the community had asked for is more time for development. We tried to incorporate that in the release schedule. We had about six weeks between the enhancements freeze and the code freeze. That's one.
It might not be visible to everyone, but one of the things that I wanted to make sure of was the health of the team — since it was a long, long release, we had time to plan out, and not have everyone work during the weekends or during their evenings or time off. That actually helped everyone keep their sanity, and also in making good progress and delivering good results at the end of the release. That's one of the process improvements that I'd call out.
We got better by making a post during the exception request process. Everyone works around the world. People from the UK start a little earlier than the people in the US East Coast. The West Coast starts three hours later than the East Coast. We used to make a post every Friday evening saying "hey, we actually received this many requests. We have addressed a number of them. We are waiting on a couple, or whatever. All the release team members are done for the day. We will see you around on Monday. Have a good weekend." Something like that.
We set the expectations from the community as well. We understand things are really important and urgent, but we are done. This gave everyone their time back. They don't have to worry over the weekend thinking like, hey, what's happening? What's happening in the release? They could spend time with their family, or they could do whatever they want to do, like go on a hike, or just sit and watch TV.
There have been weekends that I just did that. I just binge-watched a series. That's what I did.
**CRAIG BOX: Any recommendations?**
SAVITHA RAGHUNATHAN: I'm a big fan of Marvel, so I have watched the new [Loki](https://en.wikipedia.org/wiki/Loki_(TV_series)), which I really love. Loki is one of my favourite characters in Marvel. And I also liked [WandaVision](https://en.wikipedia.org/wiki/WandaVision). That was good, too.
**CRAIG BOX: I've not seen Loki yet, but I've heard it described as the best series of Doctor Who in the last few years.**
SAVITHA RAGHUNATHAN: Really?
**CRAIG BOX: There must be an element of time-travelling in there if that's how people are describing it.**
SAVITHA RAGHUNATHAN: You should really go and watch it whenever you have time. It's really amazing. I might go back and watch it again because I might have missed bits and pieces. That always happens in Marvel movies and the episodes; you need to watch them a couple of times to catch, "oh, this is how they relate".
**CRAIG BOX: Yes, the mark of good media that you want to immediately go back and watch it again once you've seen it.**
**Let's look now at some of the new features in Kubernetes 1.22. A couple of things that have graduated to general availability — server-side apply, external credential providers, a couple of new security features — the replacement for pod security policy has been announced, and seccomp is now available by default.**
**Do you have any favourite features in 1.22 that you'd like to discuss?**
SAVITHA RAGHUNATHAN: I have a lot of them. All my favourite features are related to security. OK, one of them is not security, but a major theme of my favourite KEPs is security. I'll start with the [default seccomp](https://github.com/kubernetes/enhancements/issues/2413). I think it will help make clusters secure by default, and may assist in preventing more vulnerabilities, which means less headaches for the cluster administrators.
This is close to my heart because the base of the MathWorks platform is provisioning Kubernetes clusters. Knowing that they are secure by default will definitely provide me with some good sleep. And also, I'm paranoid about security most of the time. I'm super interested in making everything secure. It might get in the way of making the users of the platform angry because it's not usable in any way.
My next one is [rootless Kubelet](https://github.com/kubernetes/enhancements/issues/2033). That feature's going to enable the cluster admin, the platform developers to deploy Kubernetes components to run in a user namespace. And I think that is also a great addition.
Like you mention, the most awaited drop in for the PSP replacement is here. It's [pod admission control](https://github.com/kubernetes/enhancements/issues/2579). It lets cluster admins apply the pod security standards. And I think it's just not related to the cluster admins. I might have to go back and check on that. Anyone can probably use it — the developers and the admins alike.
It also supports various modes, which is most welcome. There are times where you don't want to just cut the users off because they are trying to do something which is not securely correct. You just want to warn them, hey, this is what you are doing. This might just cause a security issue later, so you might want to correct it. But you just don't want to cut them off from using the platform, or them trying to attempt to do something — deploy their workload and get their day-to-day job done. That is something that I really like, that it also supports a warning mechanism.
Another one which is not security is [node swap support](https://github.com/kubernetes/enhancements/issues/2400). Kubernetes didn't have support for swap before, but it is taken into consideration now. This is an alpha feature. With this, you can take advantage of the swap, which is provisioned on the Linux VMs.
Some of the workloads — when they are deployed, they might need a lot of swap for the start-up — example, like Node and Java applications, which I just took out of their KEP user stories. So if anyone's interested, they can go and look in the KEP. That's useful. And it also increases the node stability and whatnot. So I think it's going to be beneficial for a lot of folks.
We know how Java and containers work. I think it has gotten better, but five years ago, it was so hard to get a Java application to fit in a small container. It always needed a lot of memory, swap, and everything to start up and run. I think this will help the users and help the admins and keep the cost low, and it will tie into so many other things as well. I'm excited about that feature.
Another feature that I want to just call out — I don't use Windows that much, but I just want to give a shout out to the folks who are doing an amazing job bringing all the Kubernetes features to Windows as well, to give a seamless experience.
One of the things is [Windows privileged containers](https://github.com/kubernetes/enhancements/issues/1981). I think it went alpha this release. And that is a wonderful addition, if you ask me. It can take advantage of whatever that's happening on the Linux side. And they can also port it over and see, OK, I can now run Windows containers in a privileged mode.
So whatever they are trying to achieve, they can do it. So that's a noteworthy mention. I need to give a shout out for the folks who work and make things happen in the Windows ecosystem as well.
**CRAIG BOX: One of the things that's great about the release process is the continuity between groups and teams. There's always an emeritus advisor who was a lead from a previous release. One thing that I always ask when I do these interviews is, what is the advice that you give to the next person? When [we talked to Nabarun for the 1.21 interview](https://kubernetespodcast.com/episode/146-kubernetes-1.21/), he said that his advice to you would be "do, delegate, and defer". Figure out what you can do, figure out what you can ask other people to do, and figure out what doesn't need to be done. Were you able to take that advice on board?**
SAVITHA RAGHUNATHAN: Yeah, you won't believe it. [I have it right here stuck to my monitor.](https://twitter.com/KubernetesPod/status/1423188323347177474/photo/3)
**CRAIG BOX: Next to your Git cheat sheet?**
SAVITHA RAGHUNATHAN: *laughs* Absolutely. I just have it stuck there. I just took a look at it.
**CRAIG BOX: Someone that you will have been able to delegate and defer to is Rey Lejano from Rancher Labs and SUSE, who is the release lead to be for 1.23.**
SAVITHA RAGHUNATHAN: I want to tell Rey to beware of the team's mental health. Schedule in such a way that it avoids burnout. Check in, and make sure that everyone is doing good. If they need some kind of help, create a safe space where they can actually ask for help, if they want to step back, if they need someone to cover.
I think that is most important. The releases are successful based on the thousands and thousands of contributors. But when it comes to a release team, you need to have a healthy team where people feel they are in a good place and they just want to make good contributions, which means they want to be heard. That's one thing that I want to tell Rey.
Also collaborate and learn from each other. I constantly learn. I think the team was 39 folks, including me. Every day I learned something or the other, even starting from how to interact.
Sometimes I have learned more leadership skills from my release lead shadows. They are awesome, and they are mature. I constantly learn from them, and I admire them a lot.
It also helps to have good, strong individuals in the team who can step up and help when needed. For example, unfortunately, we lost one of our teammates after the start of the release cycle. That was tragic. His name was [Peeyush Gupta](https://github.com/cncf/memorials/blob/main/peeyush-gupta.md). He was an awesome and wonderful human — very warm.
I didn't get more of a chance to interact with him. I had exchanged a few Slack messages, but I got his warm personality. I just want to take a couple of seconds to remember him. He was awesome.
After we lost him, we had this strong person from the team step up and lead the communications, who had never been a part of the release team before at all. He was a shadow for the first time. His name is Jesse Butler. So he stepped up, and he just took it away. He ran the comms show for 1.22.
That's what the community is about. You take care of team members, and the team will take care of you. So that's one other thing that I want to let Rey know, and maybe whoever — I think it's applicable overall.
**CRAIG BOX: There's a link to a [family education fund for Peeyush Gupta](https://milaap.org/fundraisers/support-peeyush-gupta-family-education), which you can find in the show notes.**
**Five releases in a row now you've been a member of the release team. Will you be putting your feet up now for 1.23?**
SAVITHA RAGHUNATHAN: I am going to take a break for a while. In the future, I want to be contributing, if not the release team, the SIG Release and the release management effort. But right now, I have been there for five releases. And I feel like, OK, I just need a little bit of fresh air.
And also the pandemic and the burnout has caught up, so I'm going to take a break from certain contributions. You will see me in the future. I will be around, but I might not be actively participating in the release team activities. I will be around the community. Anyone can reach out to me. They all know my Slack, so they can just reach out to me via Slack or Twitter.
**CRAIG BOX: Yes, your Twitter handle is CoffeeArtGirl. Does that mean that you'll be spending some time working on your lattes?**
SAVITHA RAGHUNATHAN: I am very bad at making lattes. The coffee art means that I used to [make art with coffee](https://twitter.com/KubernetesPod/status/1423188323347177474/photo/1). You get instant coffee powder and just mix it with water. You get the colours, very beautiful brown colours. I used to make art using that.
And I love coffee. So I just combined all the words together. And I had to come up with it in a span of one hour or so because I was joining this 'meet our contributors' panel. And Paris asked me, "do you have a Twitter handle?" I was planning to create one, but I didn't have the time.
I'm like, well, let me just think what I could just come up with real quick. So I just came up with that. So that's the story behind my Twitter handle. Everyone's interested in it. You are not the first person you have asked me or mentioned about it. So many others are like, why coffee art?
**CRAIG BOX: And you are also interested in art with perhaps other materials?**
SAVITHA RAGHUNATHAN: Yes. My interests keep changing. I used to do pebble art. It's just collecting pebbles from wherever I go, and I used to paint on them. I used to use watercolour, but I want to come back to watercolour sometime.
My recent interests are coloured pencils, which came back. When I was very young, I used to do a lot of coloured pencils. And then I switched to watercolours and oil painting. So I just go around in circles.
One of the hobbies that I picked up during a pandemic is crochet. I made a scarf for Mother's Day. My mum and my dad were here last year. They got stuck because of the pandemic, and they couldn't go back home. So they stayed with me for 10 months. That is the jackpot that I had, that I got to spend so much time with my parents after I moved to the US.
**CRAIG BOX: And they got rewarded with a scarf.**
SAVITHA RAGHUNATHAN: Yeah.
**CRAIG BOX: One to share between them.**
SAVITHA RAGHUNATHAN: I started making a blanket for my dad. And it became so heavy, I might have to just pick up some lighter yarn. I still don't know the differences between different kinds of yarns, but I'm getting better.
I started out because I wanted to make these little toys. They call them [amigurumi](https://en.wikipedia.org/wiki/Amigurumi) in the crochet world. I wanted to make them. That's why I started out. I'm trying. I made [a little cat](https://twitter.com/KubernetesPod/status/1423188323347177474/photo/2) which doesn't look like a cat, but it is a cat. I have to tell everyone that it's a cat so that they don't mock me later, but.
**CRAIG BOX: It's an artistic interpretation of a cat.**
SAVITHA RAGHUNATHAN: It definitely is!
---
_[Savitha Raghunathan](https://twitter.com/coffeeartgirl), now a Senior Software Engineer at Red Hat, served as the Kubernetes 1.22 release team lead._
_You can find the [Kubernetes Podcast from Google](http://www.kubernetespodcast.com/) at [@KubernetesPod](https://twitter.com/KubernetesPod) on Twitter, and you can [subscribe](https://kubernetespodcast.com/subscribe/) so you never miss an episode._
-1
View File
@@ -19,7 +19,6 @@ cid: community
<div class="community__navbar">
<a href="https://www.kubernetes.dev/">Contributor Community</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#values">Community Values</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#conduct">Code of conduct </a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#videos">Videos</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
@@ -43,11 +43,11 @@ The controllers inside the cloud controller manager include:
### Node controller
The node controller is responsible for updating {{< glossary_tooltip text="Node" term_id="node" >}} objects
The node controller is responsible for creating {{< glossary_tooltip text="Node" term_id="node" >}} objects
when new servers are created in your cloud infrastructure. The node controller obtains information about the
hosts running inside your tenancy with the cloud provider. The node controller performs the following functions:
1. Update a Node object with the corresponding server's unique identifier obtained from the cloud provider API.
1. Initialize a Node object for each server that the controller discovers through the cloud provider API.
2. Annotating and labelling the Node object with cloud-specific information, such as the region the node
is deployed into and the resources (CPU, memory, etc) that it has available.
3. Obtain the node's hostname and network addresses.

Some files were not shown because too many files have changed in this diff Show More