Compare commits
24 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 4dd537066d | |||
| 9db19fb922 | |||
| 171f7e570c | |||
| e87745da8d | |||
| b1737a87a7 | |||
| 29e8f27983 | |||
| 1e35724ca0 | |||
| 7827c02b8e | |||
| b1bacf38e2 | |||
| 1ef330fe33 | |||
| e43e7523f5 | |||
| f98830bd39 | |||
| f5229ca882 | |||
| ae43ec1bfe | |||
| 6675a04821 | |||
| 4700d78095 | |||
| df6cb680e7 | |||
| 4e9df579f1 | |||
| a39553d328 | |||
| 2c4f453203 | |||
| 5d8a406419 | |||
| 734db472e2 | |||
| 9b94f198c3 | |||
| 828a1bb210 |
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -28,14 +28,14 @@ module-init:
|
||||
|
||||
all: build ## Build site with production settings and put deliverables in ./public
|
||||
|
||||
build: module-check ## Build site with non-production settings and put deliverables in ./public
|
||||
hugo --minify --environment development
|
||||
build: module-check ## Build site with production settings and put deliverables in ./public
|
||||
hugo --minify
|
||||
|
||||
build-preview: module-check ## Build site with drafts and future posts enabled
|
||||
hugo --buildDrafts --buildFuture --environment preview
|
||||
hugo --buildDrafts --buildFuture
|
||||
|
||||
deploy-preview: ## Deploy preview site via netlify
|
||||
hugo --enableGitInfo --buildFuture --environment preview -b $(DEPLOY_PRIME_URL)
|
||||
hugo --enableGitInfo --buildFuture -b $(DEPLOY_PRIME_URL)
|
||||
|
||||
functions-build:
|
||||
$(NETLIFY_FUNC) build functions-src
|
||||
@@ -43,15 +43,13 @@ functions-build:
|
||||
check-headers-file:
|
||||
scripts/check-headers-file.sh
|
||||
|
||||
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
|
||||
production-build: build check-headers-file ## Build the production site and ensure that noindex headers aren't added
|
||||
|
||||
non-production-build: module-check ## Build the non-production site, which adds noindex headers to prevent indexing
|
||||
hugo --enableGitInfo --environment nonprod
|
||||
non-production-build: ## Build the non-production site, which adds noindex headers to prevent indexing
|
||||
hugo --enableGitInfo
|
||||
|
||||
serve: module-check ## Boot the development server.
|
||||
hugo server --buildFuture --environment development
|
||||
hugo server --buildFuture
|
||||
|
||||
docker-image:
|
||||
@echo -e "$(CCRED)**** The use of docker-image is deprecated. Use container-image instead. ****$(CCEND)"
|
||||
@@ -72,10 +70,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 --environment development"
|
||||
$(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify"
|
||||
|
||||
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 --environment development --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 --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir
|
||||
|
||||
test-examples:
|
||||
scripts/test_examples.sh install
|
||||
@@ -90,7 +88,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 --environment test
|
||||
$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --config config.toml,linkcheck-config.toml --buildFuture
|
||||
$(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
|
||||
@@ -98,4 +96,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
|
||||
|
||||
@@ -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
@@ -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
@@ -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
@@ -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
@@ -1,6 +1,6 @@
|
||||
# Документация по Kubernetes
|
||||
|
||||
[](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [](https://github.com/kubernetes/website/releases/latest)
|
||||
[](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [](https://github.com/kubernetes/website/releases/latest)
|
||||
|
||||
Данный репозиторий содержит все необходимые файлы для сборки [сайта Kubernetes и документации](https://kubernetes.io/). Мы благодарим вас за желание внести свой вклад!
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
@@ -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
@@ -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
|
||||
@@ -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 */}}
|
||||
@@ -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 */}}
|
||||
@@ -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
@@ -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
@@ -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;
|
||||
}
|
||||
}
|
||||
|
||||
@@ -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
@@ -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
|
||||
|
||||
+26
-29
@@ -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.24"
|
||||
latest = "v1.22"
|
||||
|
||||
fullversion = "v1.22.9"
|
||||
version = "v1.22"
|
||||
githubbranch = "v1.22.9"
|
||||
docsbranch = "release-1.22"
|
||||
fullversion = "v1.21.4"
|
||||
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.24.0"
|
||||
version = "v1.24"
|
||||
githubbranch = "v1.24.0"
|
||||
fullversion = "v1.22.0"
|
||||
version = "v1.22"
|
||||
githubbranch = "v1.22.0"
|
||||
docsbranch = "main"
|
||||
url = "https://kubernetes.io"
|
||||
|
||||
[[params.versions]]
|
||||
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.9"
|
||||
docsbranch = "release-1.22"
|
||||
url = "https://v1-22.docs.kubernetes.io"
|
||||
|
||||
[[params.versions]]
|
||||
fullversion = "v1.21.12"
|
||||
fullversion = "v1.21.4"
|
||||
version = "v1.21"
|
||||
githubbranch = "v1.21.12"
|
||||
githubbranch = "v1.21.4"
|
||||
docsbranch = "release-1.21"
|
||||
url = "https://v1-21.docs.kubernetes.io"
|
||||
|
||||
[[params.versions]]
|
||||
fullversion = "v1.20.15"
|
||||
fullversion = "v1.20.10"
|
||||
version = "v1.20"
|
||||
githubbranch = "v1.20.15"
|
||||
githubbranch = "v1.20.10"
|
||||
docsbranch = "release-1.20"
|
||||
url = "https://v1-20.docs.kubernetes.io"
|
||||
|
||||
[[params.versions]]
|
||||
fullversion = "v1.19.14"
|
||||
version = "v1.19"
|
||||
githubbranch = "v1.19.14"
|
||||
docsbranch = "release-1.19"
|
||||
url = "https://v1-19.docs.kubernetes.io"
|
||||
|
||||
[[params.versions]]
|
||||
fullversion = "v1.18.20"
|
||||
version = "v1.18"
|
||||
githubbranch = "v1.18.20"
|
||||
docsbranch = "release-1.18"
|
||||
url = "https://v1-18.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)
|
||||
|
||||
@@ -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 >}}
|
||||
@@ -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>
|
||||
<a href="#conduct">Verhaltenskodex </a>
|
||||
<a href="#videos">Videos</a>
|
||||
<a href="#discuss">Diskussionen</a>
|
||||
<a href="#events">Veranstaltungen und meetups</a>
|
||||
<a href="#news">Neuigkeiten</a>
|
||||
<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 <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 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 ▶</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 ▶
|
||||
</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 ▶
|
||||
</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 ▶
|
||||
</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 ▶
|
||||
</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 ▶
|
||||
</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 ▶
|
||||
</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 ▶
|
||||
|
||||
<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>
|
||||
|
||||
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
Regular → Executable
@@ -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>
|
||||
|
||||
|
||||
@@ -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;
|
||||
}
|
||||
}
|
||||
@@ -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>
|
||||
|
||||
@@ -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ührung in Kubernetes <br> </b>
|
||||
</h5>
|
||||
<p>Mö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ü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>
|
||||
@@ -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 it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-).
|
||||
Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/user-guide/kubectl/kubectl_config_set-context/).
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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**
|
||||
|
||||
+2
-2
@@ -37,7 +37,7 @@ If you run your storage application on high-end hardware or extra-large instance
|
||||
[ZooKeeper](https://zookeeper.apache.org/doc/current/) is an interesting use case for StatefulSet for two reasons. First, it demonstrates that StatefulSet can be used to run a distributed, strongly consistent storage application on Kubernetes. Second, it's a prerequisite for running workloads like [Apache Hadoop](http://hadoop.apache.org/) and [Apache Kakfa](https://kafka.apache.org/) on Kubernetes. An [in-depth tutorial](/docs/tutorials/stateful-application/zookeeper/) on deploying a ZooKeeper ensemble on Kubernetes is available in the Kubernetes documentation, and we’ll outline a few of the key features below.
|
||||
|
||||
**Creating a ZooKeeper Ensemble**
|
||||
Creating an ensemble is as simple as using [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create) to generate the objects stored in the manifest.
|
||||
Creating an ensemble is as simple as using [kubectl create](/docs/user-guide/kubectl/kubectl_create/) to generate the objects stored in the manifest.
|
||||
|
||||
|
||||
```
|
||||
@@ -297,7 +297,7 @@ zk-0 0/1 Terminating 0 15m
|
||||
|
||||
|
||||
|
||||
You can use [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) to recreate the zk StatefulSet and redeploy the ensemble.
|
||||
You can use [kubectl apply](/docs/user-guide/kubectl/kubectl_apply/) to recreate the zk StatefulSet and redeploy the ensemble.
|
||||
|
||||
|
||||
|
||||
|
||||
+4
-3
@@ -144,9 +144,10 @@ ways to address it.
|
||||
- Specifically add an iptables rule to drop the packets that are marked as
|
||||
*INVALID*, so it won’t reach to client pod and cause harm.
|
||||
|
||||
The [fix](https://github.com/kubernetes/kubernetes/pull/74840) is available in v1.15+.
|
||||
However, for the users that are affected by this bug, there is a way to mitigate the
|
||||
problem by applying the following rule in your cluster.
|
||||
The fix is drafted (https://github.com/kubernetes/kubernetes/pull/74840), but
|
||||
unfortunately it didn’t catch the v1.14 release window. However, for the users
|
||||
that are affected by this bug, there is a way to mitigate the problem by applying
|
||||
the following rule in your cluster.
|
||||
|
||||
```yaml
|
||||
apiVersion: extensions/v1beta1
|
||||
|
||||
@@ -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)
|
||||
|
||||
We’re pleased to announce the release of Kubernetes 1.22, the second release of 2021!
|
||||
|
||||
This release consists of 53 enhancements: 13 enhancements have graduated to stable, 24 enhancements are moving to beta, and 16 enhancements are entering alpha. Also, three features have been deprecated.
|
||||
|
||||
In April of this year, the Kubernetes release cadence was officially changed from four to three releases yearly. This is the first longer-cycle release related to that change. As the Kubernetes project matures, the number of enhancements per cycle grows. This means more work, from version to version, for the contributor community and Release Engineering team, and it can put pressure on the end-user community to stay up-to-date with releases containing increasingly more features.
|
||||
|
||||
Changing the release cadence from four to three releases yearly balances many aspects of the project, both in how contributions and releases are managed, and also in the community's ability to plan for upgrades and stay up to date.
|
||||
|
||||
You can read more in the official blog post [Kubernetes Release Cadence Change: Here’s What You Need To Know](https://kubernetes.io/blog/2021/07/20/new-kubernetes-release-cadence/).
|
||||
|
||||
|
||||
## Major Themes
|
||||
|
||||
### Server-side Apply graduates to GA
|
||||
|
||||
[Server-side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) is a new field ownership and object merge algorithm running on the Kubernetes API server. Server-side Apply helps users and controllers manage their resources via declarative configurations. It allows them to create and/or modify their objects declaratively, simply by sending their fully specified intent. After being in beta for a couple releases, Server-side Apply is now generally available.
|
||||
|
||||
### External credential providers now stable
|
||||
|
||||
Support for Kubernetes client [credential plugins](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins) has been in beta since 1.11, and with the release of Kubernetes 1.22 now graduates to stable. The GA feature set includes improved support for plugins that provide interactive login flows, as well as a number of bug fixes. Aspiring plugin authors can look at [sample-exec-plugin](https://github.com/ankeesler/sample-exec-plugin) to get started.
|
||||
|
||||
### etcd moves to 3.5.0
|
||||
|
||||
Kubernetes' default backend storage, etcd, has a new release: 3.5.0. The new release comes with improvements to the security, performance, monitoring, and developer experience. There are numerous bug fixes and some critical new features like the migration to structured logging and built-in log rotation. The release comes with a detailed future roadmap to implement a solution to traffic overload. You can read a full and detailed list of changes in the [3.5.0 release announcement](https://etcd.io/blog/2021/announcing-etcd-3.5/).
|
||||
|
||||
### Quality of Service for memory resources
|
||||
|
||||
Originally, Kubernetes used the v1 cgroups API. With that design, the QoS class for a `Pod` only applied to CPU resources (such as `cpu_shares`). As an alpha feature, Kubernetes v1.22 can now use the cgroups v2 API to control memory allocation and isolation. This feature is designed to improve workload and node availability when there is contention for memory resources, and to improve the predictability of container lifecycle.
|
||||
|
||||
### Node system swap support
|
||||
|
||||
Every system administrator or Kubernetes user has been in the same boat regarding setting up and using Kubernetes: disable swap space. With the release of Kubernetes 1.22, alpha support is available to run nodes with swap memory. This change lets administrators opt in to configuring swap on Linux nodes, treating a portion of block storage as additional virtual memory.
|
||||
|
||||
### Windows enhancements and capabilities
|
||||
|
||||
Continuing to support the growing developer community, SIG Windows has released their [Development Environment](https://github.com/kubernetes-sigs/sig-windows-dev-tools/). These new tools support multiple CNI providers and can run on multiple platforms. There is also a new way to run bleeding-edge Windows features from scratch by compiling the Windows kubelet and kube-proxy, then using them along with daily builds of other Kubernetes components.
|
||||
|
||||
CSI support for Windows nodes moves to GA in the 1.22 release. In Kubernetes v1.22, Windows privileged containers are an alpha feature. To allow using CSI storage on Windows nodes, [CSIProxy](https://github.com/kubernetes-csi/csi-proxy) enables CSI node plugins to be deployed as unprivileged pods, using the proxy to perform privileged storage operations on the node.
|
||||
|
||||
### Default profiles for seccomp
|
||||
|
||||
An alpha feature for default seccomp profiles has been added to the kubelet, along with a new command line flag and configuration. When in use, this new feature provides cluster-wide seccomp defaults, using the `RuntimeDefault` seccomp profile rather than `Unconfined` by default. This enhances the default security of the Kubernetes Deployment. Security administrators will now sleep better knowing that workloads are more secure by default. To learn more about the feature, please refer to the official [seccomp tutorial](https://kubernetes.io/docs/tutorials/clusters/seccomp/#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads).
|
||||
|
||||
### More secure control plane with kubeadm
|
||||
|
||||
A new alpha feature allows running the `kubeadm` control plane components as non-root users. This is a long requested security measure in `kubeadm`. To try it you must enable the `kubeadm` specific RootlessControlPlane feature gate. When you deploy a cluster using this alpha feature, your control plane runs with lower privileges.
|
||||
|
||||
For `kubeadm`, Kubernetes 1.22 also brings a new [v1beta3 configuration API](/docs/reference/config-api/kubeadm-config.v1beta3/). This iteration adds some long requested features and deprecates some existing ones. The v1beta3 version is now the preferred API version; the v1beta2 API also remains available and is not yet deprecated.
|
||||
|
||||
## Major Changes
|
||||
|
||||
### Removal of several deprecated beta APIs
|
||||
|
||||
A number of deprecated beta APIs have been removed in 1.22 in favor of the GA version of those same APIs. All existing objects can be interacted with via stable APIs. This removal includes beta versions of the `Ingress`, `IngressClass`, `Lease`, `APIService`, `ValidatingWebhookConfiguration`, `MutatingWebhookConfiguration`, `CustomResourceDefinition`, `TokenReview`, `SubjectAccessReview`, and `CertificateSigningRequest` APIs.
|
||||
|
||||
For the full list, check out the [Deprecated API Migration Guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22) as well as the blog post [Kubernetes API and Feature Removals In 1.22: Here’s What You Need To Know](https://blog.k8s.io/2021/07/14/upcoming-changes-in-kubernetes-1-22/).
|
||||
|
||||
### API changes and improvements for ephemeral containers
|
||||
|
||||
The API used to create [Ephemeral Containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/) changes in 1.22. The Ephemeral Containers feature is alpha and disabled by default, and the new API does not work with clients that attempt to use the old API.
|
||||
|
||||
For stable features, the kubectl tool follows the Kubernetes [version skew policy](https://kubernetes.io/releases/version-skew-policy/); however, kubectl v1.21 and older do not support the new API for ephemeral containers. If you plan to use `kubectl debug` to create ephemeral containers, and your cluster is running Kubernetes v1.22, you cannot do so with kubectl v1.21 or earlier. Please update kubectl to 1.22 if you wish to use `kubectl debug` with a mix of cluster versions.
|
||||
|
||||
## Other Updates
|
||||
|
||||
### Graduated to Stable
|
||||
|
||||
* [Bound Service Account Token Volumes](https://github.com/kubernetes/enhancements/issues/542)
|
||||
* [CSI Service Account Token](https://github.com/kubernetes/enhancements/issues/2047)
|
||||
* [Windows Support for CSI Plugins](https://github.com/kubernetes/enhancements/issues/1122)
|
||||
* [Warning mechanism for deprecated API use](https://github.com/kubernetes/enhancements/issues/1693)
|
||||
* [PodDisruptionBudget Eviction](https://github.com/kubernetes/enhancements/issues/85)
|
||||
|
||||
### Notable Feature Updates
|
||||
|
||||
* A new [PodSecurity admission](https://github.com/kubernetes/enhancements/issues/2579) alpha feature is introduced, intended as a replacement for PodSecurityPolicy
|
||||
* [The Memory Manager](https://github.com/kubernetes/enhancements/issues/1769) moves to beta
|
||||
* A new alpha feature to enable [API Server Tracing](https://github.com/kubernetes/enhancements/issues/647)
|
||||
* A new v1beta3 version of the [kubeadm configuration](https://github.com/kubernetes/enhancements/issues/970) format
|
||||
* [Generic data populators](https://github.com/kubernetes/enhancements/issues/1495) for PersistentVolumes are now available in alpha
|
||||
* The Kubernetes control plane will now always use the [CronJobs v2 controller](https://github.com/kubernetes/enhancements/issues/19)
|
||||
* As an alpha feature, all Kubernetes node components (including the kubelet, kube-proxy, and container runtime) can be [run as a non-root user](https://github.com/kubernetes/enhancements/issues/2033)
|
||||
|
||||
# Release notes
|
||||
|
||||
You can check out the full details of the 1.22 release in the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md).
|
||||
|
||||
# Availability of release
|
||||
|
||||
Kubernetes 1.22 is [available for download](https://kubernetes.io/releases/download/) and also [on the GitHub project](https://github.com/kubernetes/kubernetes/releases/tag/v1.22.0).
|
||||
|
||||
There are some great resources out there for getting started with Kubernetes. You can check out some [interactive tutorials](https://kubernetes.io/docs/tutorials/) on the main Kubernetes site, or run a local cluster on your machine using Docker containers with [kind](https://kind.sigs.k8s.io). If you’d like to try building a cluster from scratch, check out the [Kubernetes the Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way) tutorial by Kelsey Hightower.
|
||||
|
||||
# Release Team
|
||||
|
||||
This release was made possible by a very dedicated group of individuals, who came together as a team to deliver technical content, documentation, code, and a host of other components that go into every Kubernetes release.
|
||||
|
||||
A huge thank you to the release lead Savitha Raghunathan for leading us through a successful release cycle, and to everyone else on the release team for supporting each other, and working so hard to deliver the 1.22 release for the community.
|
||||
|
||||
We would also like to take this opportunity to remember Peeyush Gupta, a member of our team that we lost earlier this year. Peeyush was actively involved in SIG ContribEx and the Kubernetes Release Team, most recently serving as the 1.22 Communications lead. His contributions and efforts will continue to reflect in the community he helped build. A [CNCF memorial](https://github.com/cncf/memorials/blob/main/peeyush-gupta.md) page has been created where thoughts and memories can be shared by the community.
|
||||
|
||||
# Release Logo
|
||||
|
||||

|
||||
|
||||
Amidst the ongoing pandemic, natural disasters, and ever-present shadow of burnout, the 1.22 release of Kubernetes includes 53 enhancements. This makes it the largest release to date. This accomplishment was only made possible due to the hard-working and passionate Release Team members and the amazing contributors of the Kubernetes ecosystem. The release logo is our reminder to keep reaching for new milestones and setting new records. And it is dedicated to all the Release Team members, hikers, and stargazers!
|
||||
|
||||
The logo is designed by [Boris Zotkin](https://www.instagram.com/boris.z.man/). Boris is a Mac/Linux Administrator at the MathWorks. He enjoys simple things in life and loves spending time with his family. This tech-savvy individual is always up for a challenge and happy to help a friend!
|
||||
|
||||
# User Highlights
|
||||
|
||||
- In May, the CNCF welcomed 27 new organizations across the globe as members of the diverse cloud native ecosystem. These new [members](https://www.cncf.io/announcements/2021/05/05/27-new-members-join-the-cloud-native-computing-foundation/) will participate in CNCF events, including the upcoming [KubeCon + CloudNativeCon NA in Los Angeles](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/) from October 12 – 15, 2021.
|
||||
- The CNCF granted Spotify the [Top End User Award](https://www.cncf.io/announcements/2021/05/05/cloud-native-computing-foundation-grants-spotify-the-top-end-user-award/) during [KubeCon + CloudNativeCon EU – Virtual 2021](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/).
|
||||
|
||||
# Project Velocity
|
||||
|
||||
The [CNCF K8s DevStats project](https://k8s.devstats.cncf.io/) aggregates a number of interesting data points related to the velocity of Kubernetes and various sub-projects. This includes everything from individual contributions to the number of companies that are contributing, and is an illustration of the depth and breadth of effort that goes into evolving this ecosystem.
|
||||
|
||||
In the v1.22 release cycle, which ran for 15 weeks (April 26 to August 4), we saw contributions from [1063 companies](https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1&var-period_name=v1.21.0%20-%20now&var-metric=contributions) and [2054 individuals](https://k8s.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=v1.21.0%20-%20now&var-metric=contributions&var-repogroup_name=Kubernetes&var-country_name=All&var-companies=All).
|
||||
|
||||
# Ecosystem Updates
|
||||
|
||||
- [KubeCon + CloudNativeCon Europe 2021](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) was held in May, the third such event to be virtual. All talks are [now available on-demand](https://www.youtube.com/playlist?list=PLj6h78yzYM2MqBm19mRz9SYLsw4kfQBrC) for anyone that would like to catch up!
|
||||
- [Spring Term LFX Program](https://www.cncf.io/blog/2021/07/13/spring-term-lfx-program-largest-graduating-class-with-28-successful-cncf-interns) had the largest graduating class with 28 successful CNCF interns!
|
||||
- CNCF launched [livestreaming on Twitch](https://www.cncf.io/blog/2021/06/03/cloud-native-community-goes-live-with-10-shows-on-twitch/) at the beginning of the year targeting definitive interactive media experience for anyone wanting to learn, grow, and collaborate with others in the Cloud Native community from anywhere in the world.
|
||||
|
||||
# Event Updates
|
||||
|
||||
- [KubeCon + CloudNativeCon North America 2021](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/) will take place in Los Angeles, October 12 – 15, 2021! You can find more information about the conference and registration on the event site.
|
||||
- [Kubernetes Community Days](https://community.cncf.io/kubernetes-community-days/about-kcd/) has upcoming events scheduled in Italy, the UK, and in Washington DC.
|
||||
|
||||
# Upcoming release webinar
|
||||
|
||||
Join members of the Kubernetes 1.22 release team on October 5, 2021 to learn about the major features of this release, as well as deprecations and removals to help plan for upgrades. For more information and registration, visit the [event page](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kubernetes-122-release/) on the CNCF Online Programs site.
|
||||
|
||||
# Get Involved
|
||||
|
||||
If you’re interested in contributing to the Kubernetes community, Special Interest Groups (SIGs) are a great starting point. Many of them may align with your interests! If there are things you’d like to share with the community, you can join the weekly community meeting, or use any of the following channels:
|
||||
|
||||
* Find out more about contributing to Kubernetes at the [Kubernetes Contributors](https://www.kubernetes.dev/) website.
|
||||
* Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
|
||||
* Join the community discussion on [Discuss](https://discuss.kubernetes.io/)
|
||||
* Join the community on [Slack](http://slack.k8s.io/)
|
||||
* Share your Kubernetes [story](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
|
||||
* Read more about what’s happening with Kubernetes on the [blog](https://kubernetes.io/blog/)
|
||||
* Learn more about the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team)
|
||||
|
||||
|
||||
@@ -1,177 +0,0 @@
|
||||
---
|
||||
layout: blog
|
||||
title: "Kubernetes 1.22: Server Side Apply moves to GA"
|
||||
date: 2021-08-06
|
||||
slug: server-side-apply-ga
|
||||
---
|
||||
|
||||
**Authors:** Jeffrey Ying, Google & Joe Betz, Google
|
||||
|
||||
Server-side Apply (SSA) has been promoted to GA in the Kubernetes v1.22 release. The GA milestone means you can depend on the feature and its API, without fear of future backwards-incompatible changes. GA features are protected by the Kubernetes [deprecation policy](/docs/reference/using-api/deprecation-policy/).
|
||||
|
||||
## What is Server-side Apply?
|
||||
|
||||
Server-side Apply helps users and controllers manage their resources through declarative configurations. Server-side Apply replaces the client side apply feature implemented by “kubectl apply” with a server-side implementation, permitting use by tools/clients other than kubectl. Server-side Apply is a new merging algorithm, as well as tracking of field ownership, running on the Kubernetes api-server. Server-side Apply enables new features like conflict detection, so the system knows when two actors are trying to edit the same field. Refer to the [Server-side Apply Documentation](/docs/reference/using-api/server-side-apply/) and [Beta 2 release announcement](https://kubernetes.io/blog/2020/04/01/kubernetes-1.18-feature-server-side-apply-beta-2/) for more information.
|
||||
|
||||
## What’s new since Beta?
|
||||
|
||||
Since the [Beta 2 release](https://kubernetes.io/blog/2020/04/01/kubernetes-1.18-feature-server-side-apply-beta-2/) subresources support has been added, and both client-go and Kubebuilder have added comprehensive support for Server-side Apply. This completes the Server-side Apply functionality required to make controller development practical.
|
||||
|
||||
### Support for subresources
|
||||
|
||||
Server-side Apply now fully supports subresources like `status` and `scale`. This is particularly important for [controllers](/docs/concepts/architecture/controller/), which are often responsible for writing to subresources.
|
||||
|
||||
## Server-side Apply support in client-go
|
||||
|
||||
Previously, Server-side Apply could only be called from the client-go typed client using the `Patch` function, with `PatchType` set to `ApplyPatchType`. Now, `Apply` functions are included in the client to allow for a more direct and typesafe way of calling Server-side Apply. Each `Apply` function takes an "apply configuration" type as an argument, which is a structured representation of an Apply request. For example:
|
||||
|
||||
```go
|
||||
import (
|
||||
...
|
||||
v1ac "k8s.io/client-go/applyconfigurations/autoscaling/v1"
|
||||
)
|
||||
|
||||
hpaApplyConfig := v1ac.HorizontalPodAutoscaler(autoscalerName, ns).
|
||||
WithSpec(v1ac.HorizontalPodAutoscalerSpec().
|
||||
WithMinReplicas(0)
|
||||
)
|
||||
|
||||
return hpav1client.Apply(ctx, hpaApplyConfig, metav1.ApplyOptions{FieldManager: "mycontroller", Force: true})
|
||||
```
|
||||
|
||||
Note in this example that `HorizontalPodAutoscaler` is imported from an "applyconfigurations" package. Each "apply configuration" type represents the same Kubernetes object kind as the corresponding go struct, but where all fields are pointers to make them optional, allowing apply requests to be accurately represented. For example, when the apply configuration in the above example is marshalled to YAML, it produces:
|
||||
|
||||
```yaml
|
||||
apiVersion: autoscaling/v1
|
||||
kind: HorizontalPodAutoscaler
|
||||
metadata:
|
||||
name: myHPA
|
||||
namespace: myNamespace
|
||||
spec:
|
||||
minReplicas: 0
|
||||
```
|
||||
|
||||
To understand why this is needed, the above YAML cannot be produced by the v1.HorizontalPodAutoscaler go struct. Take for example:
|
||||
|
||||
```go
|
||||
hpa := v1.HorizontalPodAutoscaler{
|
||||
TypeMeta: metav1.TypeMeta{
|
||||
APIVersion: "autoscaling/v1",
|
||||
Kind: "HorizontalPodAutoscaler",
|
||||
},
|
||||
ObjectMeta: ObjectMeta{
|
||||
Namespace: ns,
|
||||
Name: autoscalerName,
|
||||
},
|
||||
Spec: v1.HorizontalPodAutoscalerSpec{
|
||||
MinReplicas: pointer.Int32Ptr(0),
|
||||
},
|
||||
}
|
||||
```
|
||||
|
||||
The above code attempts to declare the same apply configuration as shown in the previous examples, but when marshalled to YAML, produces:
|
||||
|
||||
```yaml
|
||||
kind: HorizontalPodAutoscaler
|
||||
apiVersion: autoscaling/v1
|
||||
metadata
|
||||
name: myHPA
|
||||
namespace: myNamespace
|
||||
creationTimestamp: null
|
||||
spec:
|
||||
scaleTargetRef:
|
||||
kind: ""
|
||||
name: ""
|
||||
minReplicas: 0
|
||||
maxReplicas: 0
|
||||
```
|
||||
|
||||
Which, among other things, contains `spec.maxReplicas` set to `0`. This is almost certainly not what the caller intended (the intended apply configuration says nothing about the `maxReplicas` field), and could have serious consequences on a production system: it directs the autoscaler to downscale to zero pods. The problem here originates from the fact that the go structs contain required fields that are zero valued if not set explicitly. The go structs work as intended for create and update operations, but are fundamentally incompatible with apply, which is why we have introduced the generated "apply configuration" types.
|
||||
|
||||
The "apply configurations" also have convenience `With<FieldName>` functions that make it easier to build apply requests. This allows developers to set fields without having to deal with the fact that all the fields in the "apply configuration" types are pointers, and are inconvenient to set using go. For example `MinReplicas: &0` is not legal go code, so without the `With` functions, developers would work around this problem by using a library, e.g. `MinReplicas: pointer.Int32Ptr(0)`, but string enumerations like `corev1.Protocol` are still a problem since they cannot be supported by a general purpose library. In addition to the convenience, the `With` functions also isolate developers from the underlying representation, which makes it safer for the underlying representation to be changed to support additional features in the future.
|
||||
|
||||
## Using Server-side Apply in a controller
|
||||
|
||||
You can use the new support for Server-side Apply no matter how you implemented your controller. However, the new client-go support makes it easier to use Server-side Apply in controllers.
|
||||
|
||||
When authoring new controllers to use Server-side Apply, a good approach is to have the controller recreate the apply configuration for an object each time it reconciles that object. This ensures that the controller fully reconciles all the fields that it is responsible for. Controllers typically should unconditionally set all the fields they own by setting `Force: true` in the `ApplyOptions`. Controllers must also provide a `FieldManager` name that is unique to the reconciliation loop that apply is called from.
|
||||
|
||||
When upgrading existing controllers to use Server-side Apply the same approach often works well--migrate the controllers to recreate the apply configuration each time it reconciles any object. Unfortunately, the controller might have multiple code paths that update different parts of an object depending on various conditions. Migrating a controller like this to Server-side Apply can be risky because if the controller forgets to include any fields in an apply configuration that is included in a previous apply request, a field can be accidently deleted. To ease this type of migration, client-go apply support provides a way to replace any controller reconciliation code that performs a "read/modify-in-place/update" (or patch) workflow with a "extract/modify-in-place/apply" workflow. Here's an example of the new workflow:
|
||||
|
||||
```go
|
||||
fieldMgr := "my-field-manager"
|
||||
deploymentClient := clientset.AppsV1().Deployments("default")
|
||||
|
||||
// read, could also be read from a shared informer
|
||||
deployment, err := deploymentClient.Get(ctx, "example-deployment", metav1.GetOptions{})
|
||||
if err != nil {
|
||||
// handle error
|
||||
}
|
||||
|
||||
// extract
|
||||
deploymentApplyConfig, err := appsv1ac.ExtractDeployment(deployment, fieldMgr)
|
||||
if err != nil {
|
||||
// handle error
|
||||
}
|
||||
|
||||
// modify-in-place
|
||||
deploymentApplyConfig.Spec.Template.Spec.WithContainers(corev1ac.Container().
|
||||
WithName("modify-slice").
|
||||
WithImage("nginx:1.14.2"),
|
||||
)
|
||||
|
||||
// apply
|
||||
applied, err := deploymentClient.Apply(ctx, deploymentApplyConfig, metav1.ApplyOptions{FieldManager: fieldMgr})
|
||||
```
|
||||
|
||||
For developers using Custom Resource Definitions (CRDs), the Kubebuilder apply support will provide the same capabilities. Documentation will be included in the Kubebuilder book when available.
|
||||
|
||||
## Server-side Apply and CustomResourceDefinitions
|
||||
|
||||
It is strongly recommended that all [Custom Resource Definitions](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) (CRDs) have a schema. CRDs without a schema are treated as unstructured data by Server-side Apply. Keys are treated as fields in a struct and lists are assumed to be atomic.
|
||||
|
||||
CRDs that specify a schema are able to specify additional annotations in the schema. Please refer to the documentation on the full list of available annotations.
|
||||
|
||||
New annotations since beta:
|
||||
|
||||
**Defaulting:** Values for fields that appliers do not express explicit interest in should be defaulted. This prevents an applier from unintentionally owning a defaulted field that might cause conflicts with other appliers. If unspecified, the default value is nil or the nil equivalent for the corresponding type.
|
||||
|
||||
- Usage: see the [CRD Defaulting](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting) documentation for more details.
|
||||
- Golang: `+default=<value>`
|
||||
- OpenAPI extension: `default: <value>`
|
||||
|
||||
|
||||
Atomic for maps and structs:
|
||||
|
||||
**Maps:** By default maps are granular. A different manager is able to manage each map entry. They can also be configured to be atomic such that a single manager owns the entire map.
|
||||
|
||||
- Usage: Refer to [Merge Strategy](/docs/reference/using-api/server-side-apply/#merge-strategy) for a more detailed overview
|
||||
- Golang: `+mapType=granular/atomic`
|
||||
- OpenAPI extension: `x-kubernetes-map-type: granular/atomic`
|
||||
|
||||
**Structs:** By default structs are granular and a separate applier may own each field. For certain kinds of structs, atomicity may be desired. This is most commonly seen in small coordinate-like structs such as Field/Object/Namespace Selectors, Object References, RGB values, Endpoints (Protocol/Port pairs), etc.
|
||||
|
||||
- Usage: Refer to [Merge Strategy](/docs/reference/using-api/server-side-apply/#merge-strategy) for a more detailed overview
|
||||
- Golang: `+structType=granular/atomic`
|
||||
- OpenAPI extension: `x-kubernetes-map-type:atomic/granular`
|
||||
|
||||
## What's Next?
|
||||
|
||||
After Server Side Apply, the next focus for the API Expression working-group is around improving the expressiveness and size of the published Kubernetes API schema. To see the full list of items we are working on, please join our working group and refer to the work items document.
|
||||
|
||||
## How to get involved?
|
||||
|
||||
The working-group for apply is [wg-api-expression](https://github.com/kubernetes/community/tree/master/wg-api-expression). It is available on slack [#wg-api-expression](https://kubernetes.slack.com/archives/C0123CNN8F3), through the [mailing list](https://groups.google.com/g/kubernetes-wg-api-expression) and we also meet every other Tuesday at 9.30 PT on Zoom.
|
||||
|
||||
We would also like to use the opportunity to thank the hard work of all the contributors involved in making this promotion to GA possible:
|
||||
|
||||
- Andrea Nodari
|
||||
- Antoine Pelisse
|
||||
- Daniel Smith
|
||||
- Jeffrey Ying
|
||||
- Jenny Buckley
|
||||
- Joe Betz
|
||||
- Julian Modesto
|
||||
- Kevin Delgado
|
||||
- Kevin Wiesmüller
|
||||
- Maria Ntalla
|
||||
@@ -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 reaches GA
|
||||
|
||||
The CSI Proxy development team has worked closely with storage vendors, many of whom started integrating CSI Proxy into their CSI Drivers and provided feedback as early as CSI Proxy design proposal. This cooperation uncovered use cases where additional APIs were needed, found bugs, and identified areas for documentation improvement.
|
||||
|
||||
The CSI Proxy design [KEP](https://github.com/kubernetes/enhancements/pull/2737) has been updated to reflect the current CSI Proxy architecture. Additional [development documentation](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/DEVELOPMENT.md) is included for contributors interested in helping with new features or bug fixes.
|
||||
|
||||
Before we reached GA we wanted to make sure that our API is simple and consistent. We went through an extensive API review of the v1beta API groups where we made sure that the CSI Proxy API methods and messages are consistent with the naming conventions defined in the [CSI Spec](https://github.com/container-storage-interface/spec/blob/master/spec.md). As part of this effort we're graduating the [Disk](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/disk_v1.md), [Filesystem](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/filesystem_v1.md), [SMB](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/smb_v1.md) and [Volume](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/volume_v1.md) API groups to v1.
|
||||
|
||||
Additional Windows system APIs to get information from the Windows nodes and support to mount iSCSI targets in Windows nodes, are available as alpha APIs in the [System API](https://github.com/kubernetes-csi/csi-proxy/tree/v1.0.0/client/api/system/v1alpha1) and the [iSCSI API](https://github.com/kubernetes-csi/csi-proxy/tree/v1.0.0/client/api/iscsi/v1alpha2). These APIs will continue to be improved before we graduate them to v1.
|
||||
|
||||
CSI Proxy v1 is compatible with all the previous v1betaX releases. The GA `csi-proxy.exe` binary can handle requests from v1betaX clients thanks to the autogenerated conversion layer that transforms any versioned client request to a version-agnostic request that the server can process. Several [integration tests](https://github.com/kubernetes-csi/csi-proxy/tree/v1.0.0/integrationtests) were added for all the API versions of the API groups that are graduating to v1 to ensure that CSI Proxy is backwards compatible.
|
||||
|
||||
Version drift between CSI Proxy and the CSI Drivers that interact with it was also carefully considered. A [connection fallback mechanism](https://github.com/kubernetes-csi/csi-proxy/pull/124) has been provided for CSI Drivers to handle multiple versions of CSI Proxy for a smooth upgrade to v1. This allows CSI Drivers, like the GCE PD CSI Driver, [to recognize which version of the CSI Proxy binary is running](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/pull/738) and handle multiple versions of the CSI Proxy binary deployed on the node.
|
||||
|
||||
CSI Proxy v1 is already being used by many CSI Drivers, including the [AWS EBS CSI Driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/pull/966), [Azure Disk CSI Driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver/pull/919), [GCE PD CSI Driver](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/pull/738), and [SMB CSI Driver](https://github.com/kubernetes-csi/csi-driver-smb/pull/319).
|
||||
|
||||
## Future plans
|
||||
|
||||
We're very excited for the future of CSI Proxy. With the upcoming [Windows HostProcess containers](https://github.com/kubernetes/enhancements/issues/1981), we are considering converting the CSI Proxy in to a library consumed by CSI Drivers in addition to the current client/server design. This will allow us to iterate faster on new features because the `csi-proxy.exe` binary will no longer be needed.
|
||||
|
||||
## How to get involved?
|
||||
|
||||
This project, like all of Kubernetes, is the result of hard work by many contributors from diverse backgrounds working together. Those interested in getting involved with the design and development of CSI Proxy, or any part of the Kubernetes Storage system, may join the Kubernetes Storage Special Interest Group (SIG). We’re rapidly growing and always welcome new contributors.
|
||||
|
||||
For those interested in more details about CSI support in Windows please reach out in the [#csi-windows](https://kubernetes.slack.com/messages/csi-windows) Kubernetes slack channel.
|
||||
|
||||
## Acknowledgments
|
||||
|
||||
CSI-Proxy received many contributions from members of the Kubernetes community. We thank all of the people that contributed to CSI Proxy with design reviews, bug reports, bug fixes, and for their continuous support in reaching this milestone:
|
||||
|
||||
- [Andy Zhang](https://github.com/andyzhangx)
|
||||
- [Dan Ilan](https://github.com/jmpfar)
|
||||
- [Deep Debroy](https://github.com/ddebroy)
|
||||
- [Humble Devassy Chirammal](https://github.com/humblec)
|
||||
- [Jing Xu](https://github.com/jingxu97)
|
||||
- [Jean Rougé](https://github.com/wk8)
|
||||
- [Jordan Liggitt](https://github.com/liggitt)
|
||||
- [Kalya Subramanian](https://github.com/ksubrmnn)
|
||||
- [Krishnakumar R](https://github.com/kkmsft)
|
||||
- [Manuel Tellez](https://github.com/manueltellez)
|
||||
- [Mark Rossetti](https://github.com/marosset)
|
||||
- [Mauricio Poppe](https://github.com/mauriciopoppe)
|
||||
- [Matthew Wong](https://github.com/wongma7)
|
||||
- [Michelle Au](https://github.com/msau42)
|
||||
- [Patrick Lang](https://github.com/PatrickLang)
|
||||
- [Saad Ali](https://github.com/saad-ali)
|
||||
- [Yuju Hong](https://github.com/yujuhong)
|
||||
@@ -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
|
||||
|
||||

|
||||
|
||||
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/).
|
||||
|
||||

|
||||
|
||||
## 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.
|
||||
|
||||

|
||||
|
||||
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)
|
||||
BIN
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:
|
||||
|
||||

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

|
||||
|
||||
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 – the volume can be mounted as read-write by a single node
|
||||
- ReadOnlyMany – the volume can be mounted read-only by many nodes
|
||||
- ReadWriteMany – the volume can be mounted as read-write by many nodes
|
||||
|
||||
These access modes are enforced by Kubernetes components like the `kube-controller-manager` and `kubelet` to ensure only certain pods are allowed to access a given PersistentVolume.
|
||||
|
||||
## What is this new access mode and how does it work?
|
||||
|
||||
Kubernetes v1.22 introduced a fourth access mode for PVs and PVCs, that you can use for CSI volumes:
|
||||
|
||||
- ReadWriteOncePod – the volume can be mounted as read-write by a single pod
|
||||
|
||||
If you create a pod with a PVC that uses the ReadWriteOncePod access mode, Kubernetes ensures that pod is the only pod across your whole cluster that can read that PVC or write to it.
|
||||
|
||||
If you create another pod that references the same PVC with this access mode, the pod will fail to start because the PVC is already in use by another pod.
|
||||
For example:
|
||||
|
||||
```
|
||||
Events:
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Warning FailedScheduling 1s default-scheduler 0/1 nodes are available: 1 node has pod using PersistentVolumeClaim with the same name and ReadWriteOncePod access mode.
|
||||
```
|
||||
|
||||
### How is this different than the ReadWriteOnce access mode?
|
||||
|
||||
The ReadWriteOnce access mode restricts volume access to a single *node*, which means it is possible for multiple pods on the same node to read from and write to the same volume.
|
||||
This could potentially be a major problem for some applications, especially if they require at most one writer for data safety guarantees.
|
||||
|
||||
With ReadWriteOncePod these issues go away.
|
||||
Set the access mode on your PVC, and Kubernetes guarantees that only a single pod has access.
|
||||
|
||||
## How do I use it?
|
||||
|
||||
The ReadWriteOncePod access mode is in alpha for Kubernetes v1.22 and is only supported for CSI volumes.
|
||||
As a first step you need to enable the ReadWriteOncePod [feature gate](/docs/reference/command-line-tools-reference/feature-gates) for `kube-apiserver`, `kube-scheduler`, and `kubelet`.
|
||||
You can enable the feature by setting command line arguments:
|
||||
|
||||
```
|
||||
--feature-gates="...,ReadWriteOncePod=true"
|
||||
```
|
||||
|
||||
You also need to update the following CSI sidecars to these versions or greater:
|
||||
|
||||
- [csi-provisioner:v3.0.0+](https://github.com/kubernetes-csi/external-provisioner/releases/tag/v3.0.0)
|
||||
- [csi-attacher:v3.3.0+](https://github.com/kubernetes-csi/external-attacher/releases/tag/v3.3.0)
|
||||
- [csi-resizer:v1.3.0+](https://github.com/kubernetes-csi/external-resizer/releases/tag/v1.3.0)
|
||||
|
||||
### Creating a PersistentVolumeClaim
|
||||
|
||||
In order to use the ReadWriteOncePod access mode for your PVs and PVCs, you will need to create a new PVC with the access mode:
|
||||
|
||||
```yaml
|
||||
kind: PersistentVolumeClaim
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: single-writer-only
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOncePod # Allow only a single pod to access single-writer-only.
|
||||
resources:
|
||||
requests:
|
||||
storage: 1Gi
|
||||
```
|
||||
|
||||
If your storage plugin supports [dynamic provisioning](/docs/concepts/storage/dynamic-provisioning/), new PersistentVolumes will be created with the ReadWriteOncePod access mode applied.
|
||||
|
||||
#### Migrating existing PersistentVolumes
|
||||
|
||||
If you have existing PersistentVolumes, they can be migrated to use ReadWriteOncePod.
|
||||
|
||||
In this example, we already have a "cat-pictures-pvc" PersistentVolumeClaim that is bound to a "cat-pictures-pv" PersistentVolume, and a "cat-pictures-writer" Deployment that uses this PersistentVolumeClaim.
|
||||
|
||||
As a first step, you need to edit your PersistentVolume's `spec.persistentVolumeReclaimPolicy` and set it to `Retain`.
|
||||
This ensures your PersistentVolume will not be deleted when we delete the corresponding PersistentVolumeClaim:
|
||||
|
||||
```shell
|
||||
kubectl patch pv cat-pictures-pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
|
||||
```
|
||||
|
||||
Next you need to stop any workloads that are using the PersistentVolumeClaim bound to the PersistentVolume you want to migrate, and then delete the PersistentVolumeClaim.
|
||||
|
||||
Once that is done, you need to clear your PersistentVolume's `spec.claimRef.uid` to ensure PersistentVolumeClaims can bind to it upon recreation:
|
||||
|
||||
```shell
|
||||
kubectl scale --replicas=0 deployment cat-pictures-writer
|
||||
kubectl delete pvc cat-pictures-pvc
|
||||
kubectl patch pv cat-pictures-pv -p '{"spec":{"claimRef":{"uid":""}}}'
|
||||
```
|
||||
|
||||
After that you need to replace the PersistentVolume's access modes with ReadWriteOncePod:
|
||||
|
||||
```shell
|
||||
kubectl patch pv cat-pictures-pv -p '{"spec":{"accessModes":["ReadWriteOncePod"]}}'
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
The ReadWriteOncePod access mode cannot be combined with other access modes.
|
||||
Make sure ReadWriteOncePod is the only access mode on the PersistentVolume when updating, otherwise the request will fail.
|
||||
{{< /note >}}
|
||||
|
||||
Next you need to modify your PersistentVolumeClaim to set ReadWriteOncePod as the only access mode.
|
||||
You should also set your PersistentVolumeClaim's `spec.volumeName` to the name of your PersistentVolume.
|
||||
|
||||
Once this is done, you can recreate your PersistentVolumeClaim and start up your workloads:
|
||||
|
||||
```shell
|
||||
# IMPORTANT: Make sure to edit your PVC in cat-pictures-pvc.yaml before applying. You need to:
|
||||
# - Set ReadWriteOncePod as the only access mode
|
||||
# - Set spec.volumeName to "cat-pictures-pv"
|
||||
|
||||
kubectl apply -f cat-pictures-pvc.yaml
|
||||
kubectl apply -f cat-pictures-writer-deployment.yaml
|
||||
```
|
||||
|
||||
Lastly you may edit your PersistentVolume's `spec.persistentVolumeReclaimPolicy` and set to it back to `Delete` if you previously changed it.
|
||||
|
||||
```shell
|
||||
kubectl patch pv cat-pictures-pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}'
|
||||
```
|
||||
|
||||
You can read [Configure a Pod to Use a PersistentVolume for Storage](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/) for more details on working with PersistentVolumes and PersistentVolumeClaims.
|
||||
|
||||
## What volume plugins support this?
|
||||
|
||||
The only volume plugins that support this are CSI drivers.
|
||||
SIG Storage does not plan to support this for in-tree plugins because they are being deprecated as part of [CSI migration](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#what-is-the-timeline-status).
|
||||
Support may be considered for beta for users that prefer to use the legacy in-tree volume APIs with CSI migration enabled.
|
||||
|
||||
## As a storage vendor, how do I add support for this access mode to my CSI driver?
|
||||
|
||||
The ReadWriteOncePod access mode will work out of the box without any required updates to CSI drivers, but [does require updates to CSI sidecars](#update-your-csi-sidecars).
|
||||
With that being said, if you would like to stay up to date with the latest changes to the CSI specification (v1.5.0+), read on.
|
||||
|
||||
Two new access modes were introduced to the CSI specification in order to disambiguate the legacy [`SINGLE_NODE_WRITER`](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L418-L420) access mode.
|
||||
They are [`SINGLE_NODE_SINGLE_WRITER` and `SINGLE_NODE_MULTI_WRITER`](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L437-L447).
|
||||
In order to communicate to sidecars (like the [external-provisioner](https://github.com/kubernetes-csi/external-provisioner)) that your driver understands and accepts these two new CSI access modes, your driver will also need to advertise the `SINGLE_NODE_MULTI_WRITER` capability for the [controller service](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L1073-L1081) and [node service](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L1515-L1524).
|
||||
|
||||
If you'd like to read up on the motivation for these access modes and capability bits, you can also read the [CSI Specification Changes, Volume Capabilities](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/2485-read-write-once-pod-pv-access-mode/README.md#csi-specification-changes-volume-capabilities) section of KEP-2485 (ReadWriteOncePod PersistentVolume Access Mode).
|
||||
|
||||
### Update your CSI driver to use the new interface
|
||||
|
||||
As a first step you will need to update your driver's `container-storage-interface` dependency to v1.5.0+, which contains support for these new access modes and capabilities.
|
||||
|
||||
### Accept new CSI access modes
|
||||
|
||||
If your CSI driver contains logic for validating CSI access modes for requests , it may need updating.
|
||||
If it currently accepts `SINGLE_NODE_WRITER`, it should be updated to also accept `SINGLE_NODE_SINGLE_WRITER` and `SINGLE_NODE_MULTI_WRITER`.
|
||||
|
||||
Using the [GCP PD CSI driver validation logic](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/blob/v1.2.2/pkg/gce-pd-csi-driver/utils.go#L116-L130) as an example, here is how it can be extended:
|
||||
|
||||
```diff
|
||||
diff --git a/pkg/gce-pd-csi-driver/utils.go b/pkg/gce-pd-csi-driver/utils.go
|
||||
index 281242c..b6c5229 100644
|
||||
--- a/pkg/gce-pd-csi-driver/utils.go
|
||||
+++ b/pkg/gce-pd-csi-driver/utils.go
|
||||
@@ -123,6 +123,8 @@ func validateAccessMode(am *csi.VolumeCapability_AccessMode) error {
|
||||
case csi.VolumeCapability_AccessMode_SINGLE_NODE_READER_ONLY:
|
||||
case csi.VolumeCapability_AccessMode_MULTI_NODE_READER_ONLY:
|
||||
case csi.VolumeCapability_AccessMode_MULTI_NODE_MULTI_WRITER:
|
||||
+ case csi.VolumeCapability_AccessMode_SINGLE_NODE_SINGLE_WRITER:
|
||||
+ case csi.VolumeCapability_AccessMode_SINGLE_NODE_MULTI_WRITER:
|
||||
default:
|
||||
return fmt.Errorf("%v access mode is not supported for for PD", am.GetMode())
|
||||
}
|
||||
```
|
||||
|
||||
### Advertise new CSI controller and node service capabilities
|
||||
|
||||
Your CSI driver will also need to return the new `SINGLE_NODE_MULTI_WRITER` capability as part of the `ControllerGetCapabilities` and `NodeGetCapabilities` RPCs.
|
||||
|
||||
Using the [GCP PD CSI driver capability advertisement logic](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/blob/v1.2.2/pkg/gce-pd-csi-driver/gce-pd-driver.go#L54-L77) as an example, here is how it can be extended:
|
||||
|
||||
```diff
|
||||
diff --git a/pkg/gce-pd-csi-driver/gce-pd-driver.go b/pkg/gce-pd-csi-driver/gce-pd-driver.go
|
||||
index 45903f3..0d7ea26 100644
|
||||
--- a/pkg/gce-pd-csi-driver/gce-pd-driver.go
|
||||
+++ b/pkg/gce-pd-csi-driver/gce-pd-driver.go
|
||||
@@ -56,6 +56,8 @@ func (gceDriver *GCEDriver) SetupGCEDriver(name, vendorVersion string, extraVolu
|
||||
csi.VolumeCapability_AccessMode_SINGLE_NODE_WRITER,
|
||||
csi.VolumeCapability_AccessMode_MULTI_NODE_READER_ONLY,
|
||||
csi.VolumeCapability_AccessMode_MULTI_NODE_MULTI_WRITER,
|
||||
+ csi.VolumeCapability_AccessMode_SINGLE_NODE_SINGLE_WRITER,
|
||||
+ csi.VolumeCapability_AccessMode_SINGLE_NODE_MULTI_WRITER,
|
||||
}
|
||||
gceDriver.AddVolumeCapabilityAccessModes(vcam)
|
||||
csc := []csi.ControllerServiceCapability_RPC_Type{
|
||||
@@ -67,12 +69,14 @@ func (gceDriver *GCEDriver) SetupGCEDriver(name, vendorVersion string, extraVolu
|
||||
csi.ControllerServiceCapability_RPC_EXPAND_VOLUME,
|
||||
csi.ControllerServiceCapability_RPC_LIST_VOLUMES,
|
||||
csi.ControllerServiceCapability_RPC_LIST_VOLUMES_PUBLISHED_NODES,
|
||||
+ csi.ControllerServiceCapability_RPC_SINGLE_NODE_MULTI_WRITER,
|
||||
}
|
||||
gceDriver.AddControllerServiceCapabilities(csc)
|
||||
ns := []csi.NodeServiceCapability_RPC_Type{
|
||||
csi.NodeServiceCapability_RPC_STAGE_UNSTAGE_VOLUME,
|
||||
csi.NodeServiceCapability_RPC_EXPAND_VOLUME,
|
||||
csi.NodeServiceCapability_RPC_GET_VOLUME_STATS,
|
||||
+ csi.NodeServiceCapability_RPC_SINGLE_NODE_MULTI_WRITER,
|
||||
}
|
||||
gceDriver.AddNodeServiceCapabilities(ns)
|
||||
```
|
||||
|
||||
### Implement `NodePublishVolume` behavior
|
||||
|
||||
The CSI spec outlines expected behavior for the `NodePublishVolume` RPC when called more than once for the same volume but with different arguments (like the target path).
|
||||
Please refer to [the second table in the NodePublishVolume section of the CSI spec](https://github.com/container-storage-interface/spec/blob/v1.5.0/spec.md#nodepublishvolume) for more details on expected behavior when implementing in your driver.
|
||||
|
||||
### Update your CSI sidecars
|
||||
|
||||
When deploying your CSI drivers, you must update the following CSI sidecars to versions that depend on CSI spec v1.5.0+ and the Kubernetes v1.22 API.
|
||||
The minimum required versions are:
|
||||
|
||||
- [csi-provisioner:v3.0.0+](https://github.com/kubernetes-csi/external-provisioner/releases/tag/v3.0.0)
|
||||
- [csi-attacher:v3.3.0+](https://github.com/kubernetes-csi/external-attacher/releases/tag/v3.3.0)
|
||||
- [csi-resizer:v1.3.0+](https://github.com/kubernetes-csi/external-resizer/releases/tag/v1.3.0)
|
||||
|
||||
## What’s next?
|
||||
|
||||
As part of the beta graduation for this feature, SIG Storage plans to update the Kubenetes scheduler to support pod preemption in relation to ReadWriteOncePod storage.
|
||||
This means if two pods request a PersistentVolumeClaim with ReadWriteOncePod, the pod with highest priority will gain access to the PersistentVolumeClaim and any pod with lower priority will be preempted from the node and be unable to access the PersistentVolumeClaim.
|
||||
|
||||
## How can I learn more?
|
||||
|
||||
Please see [KEP-2485](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/2485-read-write-once-pod-pv-access-mode/README.md) for more details on the ReadWriteOncePod access mode and motivations for CSI spec changes.
|
||||
|
||||
## How do I get involved?
|
||||
|
||||
The [Kubernetes #csi Slack channel](https://kubernetes.slack.com/messages/csi) and any of the [standard SIG Storage communication channels](https://github.com/kubernetes/community/blob/master/sig-storage/README.md#contact) are great mediums to reach out to the SIG Storage and the CSI teams.
|
||||
|
||||
Special thanks to the following people for their insightful reviews and design considerations:
|
||||
|
||||
* Abdullah Gharaibeh (ahg-g)
|
||||
* Aldo Culquicondor (alculquicondor)
|
||||
* Ben Swartzlander (bswartz)
|
||||
* Deep Debroy (ddebroy)
|
||||
* Hemant Kumar (gnufied)
|
||||
* Humble Devassy Chirammal (humblec)
|
||||
* James DeFelice (jdef)
|
||||
* Jan Šafránek (jsafrane)
|
||||
* Jing Xu (jingxu97)
|
||||
* Jordan Liggitt (liggitt)
|
||||
* Michelle Au (msau42)
|
||||
* Saad Ali (saad-ali)
|
||||
* Tim Hockin (thockin)
|
||||
* Xing Yang (xing-yang)
|
||||
|
||||
If you’re interested in getting involved with the design and development of CSI or any part of the Kubernetes storage system, join the [Kubernetes Storage Special Interest Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG).
|
||||
We’re rapidly growing and always welcome new contributors.
|
||||
@@ -1,72 +0,0 @@
|
||||
---
|
||||
layout: blog
|
||||
title: "Spotlight on SIG Node"
|
||||
date: 2021-09-27
|
||||
slug: sig-node-spotlight-2021
|
||||
---
|
||||
|
||||
**Author:** Dewan Ahmed, Red Hat
|
||||
|
||||
## Introduction
|
||||
|
||||
In Kubernetes, a _Node_ is a representation of a single machine in your cluster. [SIG Node](https://github.com/kubernetes/community/tree/master/sig-node) owns that very important Node component and supports various subprojects such as Kubelet, Container Runtime Interface (CRI) and more to support how the pods and host resources interact. In this blog, we have summarized our conversation with [Elana Hashman (EH)](https://twitter.com/ehashdn) & [Sergey Kanzhelev (SK)](https://twitter.com/SergeyKanzhelev), who walk us through the various aspects of being a part of the SIG and share some insights about how others can get involved.
|
||||
|
||||
## A summary of our conversation
|
||||
|
||||
### Could you tell us a little about what SIG Node does?
|
||||
|
||||
SK: SIG Node is a vertical SIG responsible for the components that support the controlled interactions between the pods and host resources. We manage the lifecycle of pods that are scheduled to a node. This SIG's focus is to enable a broad set of workload types, including workloads with hardware specific or performance sensitive requirements. All while maintaining isolation boundaries between pods on a node, as well as the pod and the host. This SIG maintains quite a few components and has many external dependencies (like container runtimes or operating system features), which makes the complexity we deal with huge. We tame the complexity and aim to continuously improve node reliability.
|
||||
|
||||
### "SIG Node is a vertical SIG" could you explain a bit more?
|
||||
|
||||
EH: There are two kinds of SIGs: horizontal and vertical. Horizontal SIGs are concerned with a particular function of every component in Kubernetes: for example, SIG Security considers security aspects of every component in Kubernetes, or SIG Instrumentation looks at the logs, metrics, traces and events of every component in Kubernetes. Such SIGs don't tend to own a lot of code.
|
||||
|
||||
Vertical SIGs, on the other hand, own a single component, and are responsible for approving and merging patches to that code base. SIG Node owns the "Node" vertical, pertaining to the kubelet and its lifecycle. This includes the code for the kubelet itself, as well as the node controller, the container runtime interface, and related subprojects like the node problem detector.
|
||||
|
||||
### How did the CI subproject start? Is this specific to SIG Node and how does it help the SIG?
|
||||
|
||||
SK: The subproject started as a follow up after one of the releases was blocked by numerous test failures of critical tests. These tests haven’t started falling all at once, rather continuous lack of attention led to slow degradation of tests quality. SIG Node was always prioritizing quality and reliability, and forming of the subproject was a way to highlight this priority.
|
||||
|
||||
### As the 3rd largest SIG in terms of number of issues and PRs, how does your SIG juggle so much work?
|
||||
|
||||
EH: It helps to be organized. When I increased my contributions to the SIG in January of 2021, I found myself overwhelmed by the volume of pull requests and issues and wasn't sure where to start. We were already tracking test-related issues and pull requests on the CI subproject board, but that was missing a lot of our bugfixes and feature work. So I began putting together a triage board for the rest of our pull requests, which allowed me to sort each one by status and what actions to take, and documented its use for other contributors. We closed or merged over 500 issues and pull requests tracked by our two boards in each of the past two releases. The Kubernetes devstats showed that we have significantly increased our velocity as a result.
|
||||
|
||||
In June, we ran our first bug scrub event to work through the backlog of issues filed against SIG Node, ensuring they were properly categorized. We closed over 130 issues over the course of this 48 hour global event, but as of writing we still have 333 open issues.
|
||||
|
||||
### Why should new and existing contributors consider joining SIG Node?
|
||||
|
||||
SK: Being a SIG Node contributor gives you skills and recognition that are rewarding and useful. Understanding under the hood of a kubelet helps architecting better apps, tune and optimize those apps, and gives leg up in issues troubleshooting. If you are a new contributor, SIG Node gives you the foundational knowledge that is key to understanding why other Kubernetes components are designed the way they are. Existing contributors may benefit as many features will require SIG Node changes one way or another. So being a SIG Node contributor helps building features in other SIGs faster.
|
||||
|
||||
SIG Node maintains numerous components, many of which have dependency on external projects or OS features. This makes the onboarding process quite lengthy and demanding. But if you are up for a challenge, there is always a place for you, and a group of people to support.
|
||||
|
||||
### What do you do to help new contributors get started?
|
||||
|
||||
EH: Getting started in SIG Node can be intimidating, since there is so much work to be done, our SIG meetings are very large, and it can be hard to find a place to start.
|
||||
|
||||
I always encourage new contributors to work on things that they have some investment in already. In SIG Node, that might mean volunteering to help fix a bug that you have personally been affected by, or helping to triage bugs you care about by priority.
|
||||
|
||||
To come up to speed on any open source code base, there are two strategies you can take: start by exploring a particular issue deeply, and follow that to expand the edges of your knowledge as needed, or briefly review as many issues and change requests as you possibly can to get a higher level picture of how the component works. Ultimately, you will need to do both if you want to become a Node reviewer or approver.
|
||||
|
||||
[Davanum Srinivas](https://twitter.com/dims) and I each ran a cohort of group mentoring to help teach new contributors the skills to become Node reviewers, and if there's interest we can work to find a mentor to run another session. I also encourage new contributors to attend our Node CI Subproject meeting: it's a smaller audience and we don't record the triage sessions, so it can be a less intimidating way to get started with the SIG.
|
||||
|
||||
### Are there any particular skills you’d like to recruit for? What skills are contributors to SIG Usability likely to learn?
|
||||
|
||||
SK: SIG Node works on many workstreams in very different areas. All of these areas are on system level. For the typical code contributions you need to have a passion for building and utilizing low level APIs and writing performant and reliable components. Being a contributor you will learn how to debug and troubleshoot, profile, and monitor these components, as well as user workload that is run by these components. Often, with the limited to no access to Nodes, as they are running production workloads.
|
||||
|
||||
The other way of contribution is to help document SIG node features. This type of contribution requires a deep understanding of features, and ability to explain them in simple terms.
|
||||
|
||||
Finally, we are always looking for feedback on how best to run your workload. Come and explain specifics of it, and what features in SIG Node components may help to run it better.
|
||||
|
||||
### What are you getting positive feedback on, and what’s coming up next for SIG Node?
|
||||
|
||||
EH: Over the past year SIG Node has adopted some new processes to help manage our feature development and Kubernetes enhancement proposals, and other SIGs have looked to us for inspiration in managing large workloads. I hope that this is an area we can continue to provide leadership in and further iterate on.
|
||||
|
||||
We have a great balance of new features and deprecations in flight right now. Deprecations of unused or difficult to maintain features help us keep technical debt and maintenance load under control, and examples include the dockershim and DynamicKubeletConfiguration deprecations. New features will unlock additional functionality in end users' clusters, and include exciting features like support for cgroups v2, swap memory, graceful node shutdowns, and device management policies.
|
||||
|
||||
### Any closing thoughts/resources you’d like to share?
|
||||
|
||||
SK/EH: It takes time and effort to get to any open source community. SIG Node may overwhelm you at first with the number of participants, volume of work, and project scope. But it is totally worth it. Join our welcoming community! [SIG Node GitHub Repo](https://github.com/kubernetes/community/tree/master/sig-node) contains many useful resources including Slack, mailing list and other contact info.
|
||||
|
||||
## Wrap Up
|
||||
|
||||
SIG Node hosted a [KubeCon + CloudNativeCon Europe 2021 talk](https://www.youtube.com/watch?v=z5aY4e2RENA) with an intro and deep dive to their awesome SIG. Join the SIG's meetings to find out about the most recent research results, what the plans are for the forthcoming year, and how to get involved in the upstream Node team as a contributor!
|
||||
@@ -1,243 +0,0 @@
|
||||
---
|
||||
layout: blog
|
||||
title: "How to Handle Data Duplication in Data-Heavy Kubernetes Environments"
|
||||
date: 2021-09-29
|
||||
slug: how-to-handle-data-duplication-in-data-heavy-kubernetes-environments
|
||||
---
|
||||
|
||||
**Authors:**
|
||||
Augustinas Stirbis (CAST AI)
|
||||
|
||||
## Why Duplicate Data?
|
||||
|
||||
It’s convenient to create a copy of your application with a copy of its state for each team.
|
||||
For example, you might want a separate database copy to test some significant schema changes
|
||||
or develop other disruptive operations like bulk insert/delete/update...
|
||||
|
||||
**Duplicating data takes a lot of time.** That’s because you need first to download
|
||||
all the data from a source block storage provider to compute and then send
|
||||
it back to a storage provider again. There’s a lot of network traffic and CPU/RAM used in this process.
|
||||
Hardware acceleration by offloading certain expensive operations to dedicated hardware is
|
||||
**always a huge performance boost**. It reduces the time required to complete an operation by orders
|
||||
of magnitude.
|
||||
|
||||
## Volume Snapshots to the rescue
|
||||
|
||||
Kubernetes introduced [VolumeSnapshots](/docs/concepts/storage/volume-snapshots/) as alpha in 1.12,
|
||||
beta in 1.17, and the Generally Available version in 1.20.
|
||||
VolumeSnapshots use specialized APIs from storage providers to duplicate volume of data.
|
||||
|
||||
Since data is already in the same storage device (array of devices), duplicating data is usually
|
||||
a metadata operation for storage providers with local snapshots (majority of on-premise storage providers).
|
||||
All you need to do is point a new disk to an immutable snapshot and only
|
||||
save deltas (or let it do a full-disk copy). As an operation that is inside the storage back-end,
|
||||
it’s much quicker and usually doesn’t involve sending traffic over the network.
|
||||
Public Clouds storage providers under the hood work a bit differently. They save snapshots
|
||||
to Object Storage and then copy back from Object storage to Block storage when "duplicating" disk.
|
||||
Technically there is a lot of Compute and network resources spent on Cloud providers side,
|
||||
but from Kubernetes user perspective VolumeSnapshots work the same way whether is it local or
|
||||
remote snapshot storage provider and no Compute and Network resources are involved in this operation.
|
||||
|
||||
## Sounds like we have our solution, right?
|
||||
|
||||
Actually, VolumeSnapshots are namespaced, and Kubernetes protects namespaced data from
|
||||
being shared between tenants (Namespaces). This Kubernetes limitation is a conscious design
|
||||
decision so that a Pod running in a different namespace can’t mount another application’s
|
||||
[PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC).
|
||||
|
||||
One way around it would be to create multiple volumes with duplicate data in one namespace.
|
||||
However, you could easily reference the wrong copy.
|
||||
|
||||
So the idea is to separate teams/initiatives by namespaces to avoid that and generally
|
||||
limit access to the production namespace.
|
||||
|
||||
## Solution? Creating a Golden Snapshot externally
|
||||
|
||||
Another way around this design limitation is to create Snapshot externally (not through Kubernetes).
|
||||
This is also called pre-provisioning a snapshot manually. Next, I will import it
|
||||
as a multi-tenant golden snapshot that can be used for many namespaces. Below illustration will be
|
||||
for AWS EBS (Elastic Block Storage) and GCE PD (Persistent Disk) services.
|
||||
|
||||
### High-level plan for preparing the Golden Snapshot
|
||||
|
||||
1. Identify Disk (EBS/Persistent Disk) that you want to clone with data in the cloud provider
|
||||
2. Make a Disk Snapshot (in cloud provider console)
|
||||
3. Get Disk Snapshot ID
|
||||
|
||||
### High-level plan for cloning data for each team
|
||||
|
||||
1. Create Namespace “sandbox01”
|
||||
2. Import Disk Snapshot (ID) as VolumeSnapshotContent to Kubernetes
|
||||
3. Create VolumeSnapshot in the Namespace "sandbox01" mapped to VolumeSnapshotContent
|
||||
4. Create the PersistentVolumeClaim from VolumeSnapshot
|
||||
5. Install Deployment or StatefulSet with PVC
|
||||
|
||||
## Step 1: Identify Disk
|
||||
|
||||
First, you need to identify your golden source. In my case, it’s a PostgreSQL database
|
||||
on PersistentVolumeClaim “postgres-pv-claim” in the “production” namespace.
|
||||
|
||||
```terminal
|
||||
kubectl -n <namespace> get pvc <pvc-name> -o jsonpath='{.spec.volumeName}'
|
||||
```
|
||||
|
||||
The output will look similar to:
|
||||
```
|
||||
pvc-3096b3ba-38b6-4fd1-a42f-ec99176ed0d90
|
||||
```
|
||||
|
||||
## Step 2: Prepare your golden source
|
||||
|
||||
You need to do this once or every time you want to refresh your golden data.
|
||||
|
||||
### Make a Disk Snapshot
|
||||
|
||||
Go to AWS EC2 or GCP Compute Engine console and search for an EBS volume
|
||||
(on AWS) or Persistent Disk (on GCP), that has a label matching the last output.
|
||||
In this case I saw: `pvc-3096b3ba-38b6-4fd1-a42f-ec99176ed0d9`.
|
||||
|
||||
Click on Create snapshot and give it a name. You can do it in Console manually,
|
||||
in AWS CloudShell / Google Cloud Shell, or in the terminal. To create a snapshot in the
|
||||
terminal you must have the AWS CLI tool (`aws`) or Google's CLI (`gcloud`)
|
||||
installed and configured.
|
||||
|
||||
Here’s the command to create snapshot on GCP:
|
||||
|
||||
```terminal
|
||||
gcloud compute disks snapshot <cloud-disk-id> --project=<gcp-project-id> --snapshot-names=<set-new-snapshot-name> --zone=<availability-zone> --storage-location=<region>
|
||||
```
|
||||
{{< figure src="/images/blog/2021-09-07-data-duplication-in-data-heavy-k8s-env/create-volume-snapshot-gcp.png" alt="Screenshot of a terminal showing volume snapshot creation on GCP" title="GCP snapshot creation" >}}
|
||||
|
||||
|
||||
GCP identifies the disk by its PVC name, so it’s direct mapping. In AWS, you need to
|
||||
find volume by the CSIVolumeName AWS tag with PVC name value first that will be used for snapshot creation.
|
||||
|
||||
{{< figure src="/images/blog/2021-09-07-data-duplication-in-data-heavy-k8s-env/identify-volume-aws.png" alt="Screenshot of AWS web console, showing EBS volume identification" title="Identify disk ID on AWS" >}}
|
||||
|
||||
Mark done Volume (volume-id) ```vol-00c7ecd873c6fb3ec``` and ether create EBS snapshot in AWS Console, or use ```aws cli```.
|
||||
|
||||
```terminal
|
||||
aws ec2 create-snapshot --volume-id '<volume-id>' --description '<set-new-snapshot-name>' --tag-specifications 'ResourceType=snapshot'
|
||||
```
|
||||
|
||||
## Step 3: Get your Disk Snapshot ID
|
||||
|
||||
In AWS, the command above will output something similar to:
|
||||
```terminal
|
||||
"SnapshotId": "snap-09ed24a70bc19bbe4"
|
||||
```
|
||||
|
||||
If you’re using the GCP cloud, you can get the snapshot ID from the gcloud command by querying for the snapshot’s given name:
|
||||
|
||||
```terminal
|
||||
gcloud compute snapshots --project=<gcp-project-id> describe <new-snapshot-name> | grep id:
|
||||
```
|
||||
You should get similar output to:
|
||||
```
|
||||
id: 6645363163809389170
|
||||
```
|
||||
|
||||
## Step 4: Create a development environment for each team
|
||||
|
||||
Now I have my Golden Snapshot, which is immutable data. Each team will get a copy
|
||||
of this data, and team members can modify it as they see fit, given that a new EBS/persistent
|
||||
disk will be created for each team.
|
||||
|
||||
Below I will define a manifest for each namespace. To save time, you can replace
|
||||
the namespace name (such as changing “sandbox01” → “sandbox42”) using tools
|
||||
such as `sed` or `yq`, with Kubernetes-aware templating tools like
|
||||
[Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/),
|
||||
or using variable substitution in a CI/CD pipeline.
|
||||
|
||||
Here's an example manifest:
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: snapshot.storage.k8s.io/v1
|
||||
kind: VolumeSnapshotContent
|
||||
metadata:
|
||||
name: postgresql-orders-db-sandbox01
|
||||
namespace: sandbox01
|
||||
spec:
|
||||
deletionPolicy: Retain
|
||||
driver: pd.csi.storage.gke.io
|
||||
source:
|
||||
snapshotHandle: 'gcp/projects/staging-eu-castai-vt5hy2/global/snapshots/6645363163809389170'
|
||||
volumeSnapshotRef:
|
||||
kind: VolumeSnapshot
|
||||
name: postgresql-orders-db-snap
|
||||
namespace: sandbox01
|
||||
---
|
||||
apiVersion: snapshot.storage.k8s.io/v1
|
||||
kind: VolumeSnapshot
|
||||
metadata:
|
||||
name: postgresql-orders-db-snap
|
||||
namespace: sandbox01
|
||||
spec:
|
||||
source:
|
||||
volumeSnapshotContentName: postgresql-orders-db-sandbox01
|
||||
```
|
||||
|
||||
In Kubernetes, VolumeSnapshotContent (VSC) objects are not namespaced.
|
||||
However, I need a separate VSC for each different namespace to use, so the
|
||||
`metadata.name` of each VSC must also be different. To make that straightfoward,
|
||||
I used the target namespace as part of the name.
|
||||
|
||||
Now it’s time to replace the driver field with the CSI (Container Storage Interface) driver
|
||||
installed in your K8s cluster. Major cloud providers have CSI driver for block storage that
|
||||
support VolumeSnapshots but quite often CSI drivers are not installed by default, consult
|
||||
with your Kubernetes provider.
|
||||
|
||||
That manifest above defines a VSC that works on GCP.
|
||||
On AWS, driver and SnashotHandle values might look like:
|
||||
|
||||
```YAML
|
||||
driver: ebs.csi.aws.com
|
||||
source:
|
||||
snapshotHandle: "snap-07ff83d328c981c98"
|
||||
```
|
||||
|
||||
At this point, I need to use the *Retain* policy, so that the CSI driver doesn’t try to
|
||||
delete my manually created EBS disk snapshot.
|
||||
|
||||
For GCP, you will have to build this string by hand - add a full project ID and snapshot ID.
|
||||
For AWS, it’s just a plain snapshot ID.
|
||||
|
||||
VSC also requires specifying which VolumeSnapshot (VS) will use it, so VSC and VS are
|
||||
referencing each other.
|
||||
|
||||
Now I can create PersistentVolumeClaim from VS above. It’s important to set this first:
|
||||
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: postgres-pv-claim
|
||||
namespace: sandbox01
|
||||
spec:
|
||||
dataSource:
|
||||
kind: VolumeSnapshot
|
||||
name: postgresql-orders-db-snap
|
||||
apiGroup: snapshot.storage.k8s.io
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 21Gi
|
||||
```
|
||||
|
||||
If default StorageClass has [WaitForFirstConsumer](https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode) policy,
|
||||
then the actual Cloud Disk will be created from the Golden Snapshot only when some Pod bounds that PVC.
|
||||
|
||||
Now I assign that PVC to my Pod (in my case, it’s Postgresql) as I would with any other PVC.
|
||||
|
||||
```terminal
|
||||
kubectl -n <namespace> get volumesnapshotContent,volumesnapshot,pvc,pod
|
||||
```
|
||||
|
||||
Both VS and VSC should be *READYTOUSE* true, PVC bound, and the Pod (from Deployment or StatefulSet) running.
|
||||
|
||||
**To keep on using data from my Golden Snapshot, I just need to repeat this for the
|
||||
next namespace and voilà! No need to waste time and compute resources on the duplication process.**
|
||||
@@ -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.
|
||||
|
||||

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

|
||||
|
||||
Here is an example:
|
||||
|
||||
```yaml
|
||||
---
|
||||
apiVersion: cluster.x-k8s.io/v1beta1
|
||||
kind: Cluster
|
||||
metadata:
|
||||
name: my-amazing-cluster
|
||||
namespace: bar
|
||||
spec:
|
||||
topology: # define a managed topology
|
||||
class: my-amazing-cluster-class # use the ClusterClass mentioned earlier
|
||||
version: v1.21.2
|
||||
controlPlane:
|
||||
replicas: 3
|
||||
workers:
|
||||
machineDeployments:
|
||||
- class: type1-workers
|
||||
name: big-pool-of-machines
|
||||
replicas: 5
|
||||
- class: type2-workers
|
||||
name: small-pool-of-machines
|
||||
replicas: 1
|
||||
```
|
||||
|
||||
But there is more than simplified cluster creation. Now the Cluster acts as a single control point for your entire topology.
|
||||
|
||||
All the power of Cluster API, extensibility, lifecycle automation, stability, all the features required for managing an enterprise grade Kubernetes cluster on the infrastructure provider of your choice are now at your fingertips: you can create your Cluster, add new machines, upgrade to the next Kubernetes version, and all from a single place.
|
||||
|
||||
It is just as simple as it looks!
|
||||
|
||||
## What’s next
|
||||
|
||||
While the amazing Cluster API community is working hard to deliver the first version of ClusterClass and managed topologies later this year, we are already looking forward to what comes next for the project and its ecosystem.
|
||||
|
||||
There are a lot of great ideas and opportunities ahead!
|
||||
|
||||
We want to make managed topologies even more powerful and flexible, allowing users to dynamically change bits of a ClusterClass according to the specific needs of a Cluster; this will ensure the same simple and intuitive UX for solving complex problems like e.g. selecting machine image for a specific Kubernetes version and for a specific region of your infrastructure provider, or injecting proxy configurations in the entire Cluster, and so on.
|
||||
|
||||
Stay tuned for what comes next, and if you have any questions, comments or suggestions:
|
||||
|
||||
* Chat with us on the Kubernetes [Slack](http://slack.k8s.io/):[#cluster-api](https://kubernetes.slack.com/archives/C8TSNPY4T)
|
||||
* Join the SIG Cluster Lifecycle [Google Group](https://groups.google.com/g/kubernetes-sig-cluster-lifecycle) to receive calendar invites and gain access to documents
|
||||
* Join our [Zoom meeting](https://zoom.us/j/861487554), every Wednesday at 10:00 Pacific Time
|
||||
* Check out the [ClusterClass 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 committee’s role in their [charter](https://github.com/kubernetes/steering/blob/master/charter.md).
|
||||
|
||||
## Results
|
||||
|
||||
Congratulations to the elected committee members whose two year terms begin immediately (listed in alphabetical order by GitHub handle):
|
||||
|
||||
* **Christoph Blecker ([@cblecker](https://github.com/cblecker)), Red Hat**
|
||||
* **Stephen Augustus ([@justaugustus](https://github.com/justaugustus)), Cisco**
|
||||
* **Paris Pittman ([@parispittman](https://github.com/parispittman)), Apple**
|
||||
* **Tim Pepper ([@tpepper](https://github.com/tpepper)), VMware**
|
||||
|
||||
They join continuing members:
|
||||
|
||||
* **Davanum Srinivas ([@dims](https://github.com/dims)), VMware**
|
||||
* **Jordan Liggitt ([@liggitt](https://github.com/liggitt)), Google**
|
||||
* **Bob Killen ([@mrbobbytables](https://github.com/mrbobbytables)), Google**
|
||||
|
||||
Paris Pittman and Christoph Blecker are returning Steering Committee Members.
|
||||
|
||||
## Big Thanks
|
||||
|
||||
Thank you and congratulations on a successful election to this round’s election officers:
|
||||
|
||||
* Alison Dowdney, ([@alisondy](https://github.com/alisondy))
|
||||
* Noah Kantrowitz ([@coderanger](https://github.com/coderanger))
|
||||
* Josh Berkus ([@jberkus](https://github.com/jberkus))
|
||||
|
||||
Special thanks to Arnaud Meukam ([@ameukam](https://github.com/ameukam)), k8s-infra liaison, who enabled our voting software on community-owned infrastructure.
|
||||
|
||||
Thanks to the Emeritus Steering Committee Members. Your prior service is appreciated by the community:
|
||||
|
||||
* Derek Carr ([@derekwaynecarr](https://github.com/derekwaynecarr))
|
||||
* Nikhita Raghunath ([@nikhita](https://github.com/nikhita))
|
||||
|
||||
And thank you to all the candidates who came forward to run for election.
|
||||
|
||||
## Get Involved with the Steering Committee
|
||||
|
||||
This governing body, like all of Kubernetes, is open to all. You can follow along with Steering Committee [backlog items](https://github.com/kubernetes/steering/projects/1) and weigh in by filing an issue or creating a PR against their [repo](https://github.com/kubernetes/steering). They have an open meeting on [the first Monday at 9:30am PT of every month](https://github.com/kubernetes/steering) and regularly attend Meet Our Contributors. They can also be contacted at their public mailing list steering@kubernetes.io.
|
||||
|
||||
You can see what the Steering Committee meetings are all about by watching past meetings on the [YouTube Playlist](https://www.youtube.com/playlist?list=PL69nYSiGNLP1yP1B_nd9-drjoxp0Q14qM).
|
||||
|
||||
---
|
||||
|
||||
_This post was written by the [Upstream Marketing Working Group](https://github.com/kubernetes/community/tree/master/communication/marketing-team#contributor-marketing). If you want to write stories about the Kubernetes community, learn more about us._
|
||||
@@ -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 won’t be terminated. That is what "compressible" means.
|
||||
|
||||
In cgroup v1, and prior to this feature, the container runtime never took into account and effectively ignored spec.containers[].resources.requests["memory"]. This is unlike CPU, in which the container runtime consider both requests and limits. Furthermore, memory actually can't be compressed in cgroup v1. Because there is no way to throttle memory usage, if a container goes past its memory limit it will be terminated by the kernel with an OOM (Out of Memory) kill.
|
||||
|
||||
Fortunately, cgroup v2 brings a new design and implementation to achieve full protection on memory. The new feature relies on cgroups v2 which most current operating system releases for Linux already provide. With this experimental feature, [quality-of-service for pods and containers](/docs/tasks/configure-pod-container/quality-service-pod/) extends to cover not just CPU time but memory as well.
|
||||
|
||||
## How does it work?
|
||||
Memory QoS uses the memory controller of cgroup v2 to guarantee memory resources in Kubernetes. Memory requests and limits of containers in pod are used to set specific interfaces `memory.min` and `memory.high` provided by the memory controller. When `memory.min` is set to memory requests, memory resources are reserved and never reclaimed by the kernel; this is how Memory QoS ensures the availability of memory for Kubernetes pods. And if memory limits are set in the container, this means that the system needs to limit container memory usage, Memory QoS uses `memory.high` to throttle workload approaching it's memory limit, ensuring that the system is not overwhelmed by instantaneous memory allocation.
|
||||
|
||||

|
||||
|
||||
The following table details the specific functions of these two parameters and how they correspond to Kubernetes container resources.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th style="text-align:center">File</th>
|
||||
<th style="text-align:center">Description</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>memory.min</td>
|
||||
<td><code>memory.min</code> specifies a minimum amount of memory the cgroup must always retain, i.e., memory that can never be reclaimed by the system. If the cgroup's memory usage reaches this low limit and can’t be increased, the system OOM killer will be invoked.
|
||||
<br>
|
||||
<br>
|
||||
<i>We map it to the container's memory request</i>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>memory.high</td>
|
||||
<td><code>memory.high</code> is the memory usage throttle limit. This is the main mechanism to control a cgroup's memory use. If a cgroup's memory use goes over the high boundary specified here, the cgroup’s processes are throttled and put under heavy reclaim pressure. The default is max, meaning there is no limit.
|
||||
<br>
|
||||
<br>
|
||||
<i>We use a formula to calculate <code>memory.high</code>, depending on container's memory limit or node allocatable memory (if container's memory limit is empty) and a throttling factor. Please refer to the KEP for more details on the formula.</i>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
When container memory requests are made, kubelet passes `memory.min` to the back-end CRI runtime (possibly containerd, cri-o) via the `Unified` field in CRI during container creation. The `memory.min` in container level cgroup will be set to:
|
||||
|
||||

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

|
||||
<sub>i: the i<sup>th</sup> container in one pod</sub>
|
||||
|
||||
`memory.min` in node level cgroup:
|
||||

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

|
||||
<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._
|
||||
@@ -19,7 +19,6 @@ cid: community
|
||||
|
||||
<div class="community__navbar">
|
||||
|
||||
<a href="https://www.kubernetes.dev/">Contributor Community</a>
|
||||
<a href="#values">Community Values</a>
|
||||
<a href="#conduct">Code of conduct </a>
|
||||
<a href="#videos">Videos</a>
|
||||
|
||||
@@ -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
Reference in New Issue
Block a user