Compare commits

..

2 Commits

Author SHA1 Message Date
Kubernetes Prow Robot 48ff006ccc Merge pull request #27952 from s-kawamura-w664/patch-update-pv
[ja] Update links in ja/docs/concepts/storage/persistent-volumes.md
2021-06-04 05:07:26 -07:00
s-kawamura-w664 656c5cee89 Update links in ja/docs/concepts/storage/persistent-volumes.md 2021-05-11 11:11:50 +00:00
1964 changed files with 31005 additions and 259122 deletions
+1 -1
View File
@@ -11,7 +11,7 @@
For overall help on editing and submitting pull requests, visit:
https://kubernetes.io/docs/contribute/start/#improve-existing-content
Use the default base branch, “main”, if you're documenting existing
Use the default base branch, “master”, if you're documenting existing
features in the English localization.
If you're working on a different localization (not English), see
-3
View File
@@ -3,9 +3,6 @@
# When modifying this file, consider the security implications of
# allowing listed reviewers / approvals to modify or remove any
# configured GitHub Actions.
#
options:
no_parent_owners: true
reviewers:
- sig-docs-leads
+5 -6
View File
@@ -33,7 +33,7 @@ exhaustive, and do not form part of our licenses.
material not subject to the license. This includes other CC-
licensed material, or material used under an exception or
limitation to copyright. More considerations for licensors:
wiki.creativecommons.org/Considerations_for_licensors
wiki.creativecommons.org/Considerations_for_licensors
Considerations for the public: By using one of our public
licenses, a licensor grants the public permission to use the
@@ -48,9 +48,9 @@ exhaustive, and do not form part of our licenses.
rights in the material. A licensor may make special requests,
such as asking that all changes be marked or described.
Although not required by our licenses, you are encouraged to
respect those requests where reasonable. More considerations
for the public:
wiki.creativecommons.org/Considerations_for_licensees
respect those requests where reasonable. More_considerations
for the public:
wiki.creativecommons.org/Considerations_for_licensees
=======================================================================
@@ -378,7 +378,7 @@ Section 8 -- Interpretation.
Creative Commons is not a party to its public
licenses. Notwithstanding, Creative Commons may elect to apply one of
its public licenses to material it publishes and in those instances
will be considered the Licensor. The text of the Creative Commons
will be considered the "Licensor." The text of the Creative Commons
public licenses is dedicated to the public domain under the CC0 Public
Domain Dedication. Except for the limited purpose of indicating that
material is shared under a Creative Commons public license or as
@@ -393,4 +393,3 @@ the avoidance of doubt, this paragraph does not form part of the
public licenses.
Creative Commons may be contacted at creativecommons.org.
+3 -8
View File
@@ -6,9 +6,8 @@ NETLIFY_FUNC = $(NODE_BIN)/netlify-lambda
# but this can be overridden when calling make, e.g.
# CONTAINER_ENGINE=podman make container-image
CONTAINER_ENGINE ?= docker
IMAGE_REGISTRY ?= gcr.io/k8s-staging-sig-docs
IMAGE_VERSION=$(shell scripts/hash-files.sh Dockerfile Makefile | cut -c 1-12)
CONTAINER_IMAGE = $(IMAGE_REGISTRY)/k8s-website-hugo:v$(HUGO_VERSION)-$(IMAGE_VERSION)
CONTAINER_IMAGE = kubernetes-hugo:v$(HUGO_VERSION)-$(IMAGE_VERSION)
CONTAINER_RUN = $(CONTAINER_ENGINE) run --rm --interactive --tty --volume $(CURDIR):/src
CCRED=\033[0;31m
@@ -20,11 +19,7 @@ help: ## Show this help.
@awk 'BEGIN {FS = ":.*?## "} /^[a-zA-Z_-]+:.*?## / {sub("\\\\n",sprintf("\n%22c"," "), $$2);printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}' $(MAKEFILE_LIST)
module-check:
@git submodule status --recursive | awk '/^[+-]/ {err = 1; printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2} END { if (err != 0) print "You need to run \033[32mmake module-init\033[0m to initialize missing modules first"; exit err }' 1>&2
module-init:
@echo "Initializing submodules..." 1>&2
@git submodule update --init --recursive --depth 1
@git submodule status --recursive | awk '/^[+-]/ {printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2}' 1>&2
all: build ## Build site with production settings and put deliverables in ./public
@@ -96,4 +91,4 @@ clean-api-reference: ## Clean all directories in API reference directory, preser
api-reference: clean-api-reference ## Build the API reference pages. go needed
cd api-ref-generator/gen-resourcesdocs && \
go run cmd/main.go kwebsite --config-dir ../../api-ref-assets/config/ --file ../../api-ref-assets/api/swagger.json --output-dir ../../content/en/docs/reference/kubernetes-api --templates ../../api-ref-assets/templates
go run cmd/main.go kwebsite --config-dir config/v1.21/ --file api/v1.21/swagger.json --output-dir ../../content/en/docs/reference/kubernetes-api --templates templates
-2
View File
@@ -8,9 +8,7 @@ approvers:
emeritus_approvers:
# - chenopis, commented out to disable PR assignments
# - irvifa, commented out to disable PR assignments
# - jaredbhatti, commented out to disable PR assignments
# - kbarnard10, commented out to disable PR assignments
# - steveperry-53, commented out to disable PR assignments
- stewart-yu
# - zacharysarah, commented out to disable PR assignments
+23 -24
View File
@@ -1,8 +1,12 @@
aliases:
sig-docs-blog-owners: # Approvers for blog content
- castrojo
- kbarnard10
- onlydole
- mrbobbytables
sig-docs-blog-reviewers: # Reviewers for blog content
- castrojo
- kbarnard10
- mrbobbytables
- onlydole
- sftim
@@ -18,29 +22,31 @@ aliases:
- annajung
- bradtopol
- celestehorgan
- divya-mohan0209
- irvifa
- jimangel
- jlbutler
- kbarnard10
- kbhawkey
- onlydole
- pi-victor
- reylejano
- savitharaghunathan
- sftim
- steveperry-53
- tengqm
- zparnold
sig-docs-en-reviews: # PR reviews for English content
- bradtopol
- celestehorgan
- daminisatya
- divya-mohan0209
- jimangel
- kbarnard10
- kbhawkey
- mehabhalodiya
- onlydole
- rajeshdeshpande02
- sftim
- shannonxtreme
- steveperry-53
- tengqm
- zparnold
sig-docs-es-owners: # Admins for Spanish content
- raelga
- electrocucaracha
@@ -76,19 +82,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 +102,7 @@ aliases:
- danninov
- girikuncoro
- habibrosyad
- irvifa
- phanama
- wahyuoi
sig-docs-it-owners: # Admins for Italian content
@@ -131,15 +138,14 @@ aliases:
- ClaudiaJKang
- gochist
- ianychoi
- jihoon-seo
- jmyung
- pjhwa
- seokho-son
- yoonian
- ysyukr
- pjhwa
- yoonian
sig-docs-leads: # Website chairs and tech leads
- divya-mohan0209
- irvifa
- jimangel
- kbarnard10
- kbhawkey
- onlydole
- sftim
@@ -157,10 +163,8 @@ aliases:
# zhangxiaoyu-zidif
sig-docs-zh-reviews: # PR reviews for Chinese content
- chenrui333
- chenxuc
- howieyuen
- idealhack
- mengjiao-liu
- pigletfly
- SataQiu
- tanjunchen
@@ -168,7 +172,6 @@ aliases:
- xichengliudui
# zhangxiaoyu-zidif
sig-docs-pt-owners: # Admins for Portuguese content
- edsoncelio
- femrtnz
- jailton
- jcjesus
@@ -177,7 +180,6 @@ aliases:
- rikatz
- yagonobre
sig-docs-pt-reviews: # PR reviews for Portugese content
- edsoncelio
- femrtnz
- jailton
- jcjesus
@@ -225,20 +227,18 @@ 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
- hasheddan # SIG Technical Lead
- jeremyrickard # SIG Technical Lead
- justaugustus # SIG Chair
- LappleApple # SIG Program Manager
- puerco # SIG Technical Lead
- saschagrunert # SIG Chair
release-engineering-approvers:
- cpanato # Release Manager
@@ -250,7 +250,6 @@ aliases:
release-engineering-reviewers:
- ameukam # Release Manager Associate
- jimangel # Release Manager Associate
- markyjackson-taulia # Release Manager Associate
- mkorbi # Release Manager Associate
- palnabarun # Release Manager Associate
- onlydole # Release Manager Associate
-16
View File
@@ -37,13 +37,6 @@ Um die Kubernetes-Website lokal laufen zu lassen, empfiehlt es sich, ein speziel
> Wenn Sie die Website lieber lokal ohne Docker ausführen möchten, finden Sie weitere Informationen unter [Website lokal mit Hugo ausführen](#Die-Site-lokal-mit-Hugo-ausführen).
Das benötigte [Docsy Hugo theme](https://github.com/google/docsy#readme) muss als git submodule installiert werden:
```
#Füge das Docsy submodule hinzu
git submodule update --init --recursive --depth 1
```
Wenn Sie Docker [installiert](https://www.docker.com/get-started) haben, erstellen Sie das Docker-Image `kubernetes-hugo` lokal:
```bash
@@ -62,18 +55,9 @@ make container-serve
Hugo-Installationsanweisungen finden Sie in der [offiziellen Hugo-Dokumentation](https://gohugo.io/getting-started/installing/). Stellen Sie sicher, dass Sie die Hugo-Version installieren, die in der Umgebungsvariablen `HUGO_VERSION` in der Datei [`netlify.toml`](netlify.toml#L9) angegeben ist.
Das benötigte [Docsy Hugo theme](https://github.com/google/docsy#readme) muss als git submodule installiert werden:
```
#Füge das Docsy submodule hinzu
git submodule update --init --recursive --depth 1
```
So führen Sie die Site lokal aus, wenn Sie Hugo installiert haben:
```bash
# Installieren der JavaScript Abhängigkeiten
npm ci
make serve
```
+2 -5
View File
@@ -7,7 +7,7 @@
## डॉक्स में योगदान देना
आप अपने GitHub खाते में इस रिपॉजिटरी की एक copy बनाने के लिए स्क्रीन के ऊपरी-दाएँ क्षेत्र में **Fork** बटन पर क्लिक करें। इस copy को *Fork* कहा जाता है। अपने fork में परिवर्तन करने के बाद जब आप उनको हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं।
आप अपने GitHub खाते में इस रिपॉजिटरी की एक copy बनाने के लिए स्क्रीन के ऊपरी-दाएँ क्षेत्र में **Fork** बटन पर क्लिक करें। इस copy को *Fork* कहा जाता है। अपने fork में कोई भी परिवर्तन करना चाहते हैं, और जब आप उन परिवर्तनों को हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं।
एक बार जब आपका pull request बन जाता है, तो एक कुबरनेट्स समीक्षक स्पष्ट, कार्रवाई योग्य प्रतिक्रिया प्रदान करने की जिम्मेदारी लेगा। pull request के मालिक के रूप में, **यह आपकी जिम्मेदारी है कि आप कुबरनेट्स समीक्षक द्वारा प्रदान की गई प्रतिक्रिया को संबोधित करने के लिए अपने pull request को संशोधित करें।**
@@ -23,12 +23,9 @@
## `README.md`'s स्थानीयकरण कुबरनेट्स प्रलेखन
आप हिंदी स्थानीयकरण के मैन्टेनरों तक पहुँच सकते हैं:
आप पर हिंदी स्थानीयकरण के maintainers तक पहुँच सकते हैं:
* Anubhav Vardhan ([Slack](https://kubernetes.slack.com/archives/D0261C0A3R8), [Twitter](https://twitter.com/anubha_v_ardhan), [GitHub](https://github.com/anubha-v-ardhan))
* Divya Mohan ([Slack](https://kubernetes.slack.com/archives/D027R7BE804), [Twitter](https://twitter.com/Divya_Mohan02), [GitHub](https://github.com/divya-mohan0209))
* Yashu Mittal ([Twitter](https://twitter.com/mittalyashu77), [GitHub](https://github.com/mittalyashu))
* [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-hi)
## स्थानीय रूप से डॉकर का उपयोग करके साइट चलाना
+1 -1
View File
@@ -1,6 +1,6 @@
# Kubernetesのドキュメント
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
このリポジトリには、[KubernetesのWebサイトとドキュメント](https://kubernetes.io/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます!
+1 -1
View File
@@ -1,6 +1,6 @@
# 쿠버네티스 문서화
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
이 저장소에는 [쿠버네티스 웹사이트 및 문서](https://kubernetes.io/)를 빌드하는 데 필요한 자산이 포함되어 있습니다. 기여해주셔서 감사합니다!
+3 -5
View File
@@ -1,6 +1,6 @@
# Dokumentacja projektu Kubernetes
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
W tym repozytorium znajdziesz wszystko, czego potrzebujesz do zbudowania [strony internetowej Kubernetesa wraz z dokumentacją](https://kubernetes.io/). Bardzo nam miło, że chcesz wziąć udział w jej współtworzeniu!
@@ -18,7 +18,7 @@ Aby móc skorzystać z tego repozytorium, musisz lokalnie zainstalować:
- [npm](https://www.npmjs.com/)
- [Go](https://golang.org/)
- [Hugo (Extended version)](https://gohugo.io/)
- Środowisko obsługi kontenerów, np. [Dockera](https://www.docker.com/).
- Środowisko obsługi kontenerów, np. [Docker-a](https://www.docker.com/).
Przed rozpoczęciem zainstaluj niezbędne zależności. Sklonuj repozytorium i przejdź do odpowiedniego katalogu:
@@ -43,9 +43,7 @@ make container-image
make container-serve
```
Jeśli widzisz błędy, prawdopodobnie kontener z Hugo nie dysponuje wystarczającymi zasobami. Aby rozwiązać ten problem, zwiększ ilość dostępnych zasobów CPU i pamięci dla Dockera na Twojej maszynie ([MacOSX](https://docs.docker.com/docker-for-mac/#resources) i [Windows](https://docs.docker.com/docker-for-windows/#resources)).
Aby obejrzeć zawartość serwisu, otwórz w przeglądarce adres http://localhost:1313. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce.
Aby obejrzeć zawartość serwisu otwórz w przeglądarce adres http://localhost:1313. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce.
## Jak uruchomić lokalną kopię strony przy pomocy Hugo?
+1 -1
View File
@@ -1,6 +1,6 @@
# A documentação do Kubernetes
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
Bem-vindos! Este repositório contém todos os recursos necessários para criar o [website e documentação do Kubernetes](https://kubernetes.io/). Estamos muito satisfeitos por você querer contribuir!
+1 -1
View File
@@ -1,6 +1,6 @@
# Документация по Kubernetes
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
Данный репозиторий содержит все необходимые файлы для сборки [сайта Kubernetes и документации](https://kubernetes.io/). Мы благодарим вас за желание внести свой вклад!
+1 -1
View File
@@ -1,7 +1,7 @@
<!-- # The Kubernetes documentation -->
# Документація Kubernetes
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
<!-- This repository contains the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/). We're glad that you want to contribute! -->
Вітаємо! В цьому репозиторії міститься все необхідне для роботи над [сайтом і документацією Kubernetes](https://kubernetes.io/). Ми щасливі, що ви хочете зробити свій внесок!
+3 -3
View File
@@ -4,7 +4,7 @@
# The Kubernetes documentation
-->
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
<!--
This repository contains the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/). We're glad that you want to contribute!
@@ -174,7 +174,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)
- [Mailing List](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
-->
# 参与 SIG Docs 工作
@@ -184,7 +184,7 @@ You can also reach the maintainers of this project at:
你也可以通过以下渠道联系本项目的维护人员:
- [Slack](https://kubernetes.slack.com/messages/sig-docs) [加入Slack](https://slack.k8s.io/)
- [Slack](https://kubernetes.slack.com/messages/sig-docs)
- [邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)
<!--
+62 -55
View File
@@ -1,13 +1,13 @@
# The Kubernetes documentation
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest)
This repository contains the assets required to build the [Kubernetes website and documentation](https://kubernetes.io/). We're glad that you want to contribute!
- [Contributing to the docs](#contributing-to-the-docs)
- [Localization ReadMes](#localization-readmemds)
+ [Contributing to the docs](#contributing-to-the-docs)
+ [Localization ReadMes](#localization-readmemds)
## Using this repository
# Using this repository
You can run the website locally using Hugo (Extended version), or you can run it in a container runtime. We strongly recommend using the container runtime, as it gives deployment consistency with the live website.
@@ -22,14 +22,14 @@ To use this repository, you need the following installed locally:
Before you start, install the dependencies. Clone the repository and navigate to the directory:
```bash
```
git clone https://github.com/kubernetes/website.git
cd website
```
The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/docsy#readme). Even if you plan to run the website in a container, we strongly recommend pulling in the submodule and other development dependencies by running the following:
```bash
```
# pull in the Docsy submodule
git submodule update --init --recursive --depth 1
```
@@ -38,14 +38,14 @@ git submodule update --init --recursive --depth 1
To build the site in a container, run the following to build the container image and run it:
```bash
```
make container-image
make container-serve
```
If you see errors, it probably means that the hugo container did not have enough computing resources available. To solve it, increase the amount of allowed CPU and memory usage for Docker on your machine ([MacOSX](https://docs.docker.com/docker-for-mac/#resources) and [Windows](https://docs.docker.com/docker-for-windows/#resources)).
Open up your browser to <http://localhost:1313> to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
## Running the website locally using Hugo
@@ -59,47 +59,54 @@ npm ci
make serve
```
This will start the local Hugo server on port 1313. Open up your browser to <http://localhost:1313> to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
This will start the local Hugo server on port 1313. Open up your browser to http://localhost:1313 to view the website. As you make changes to the source files, Hugo updates the website and forces a browser refresh.
## Building the API reference pages
The API reference pages located in `content/en/docs/reference/kubernetes-api` are built from the Swagger specification, using <https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs>.
The API reference pages located in `content/en/docs/reference/kubernetes-api` are built from the Swagger specification, using https://github.com/kubernetes-sigs/reference-docs/tree/master/gen-resourcesdocs.
To update the reference pages for a new Kubernetes release (replace v1.20 in the following examples with the release to update to):
1. Pull the `kubernetes-resources-reference` submodule:
```bash
git submodule update --init --recursive --depth 1
```
2. Update the Swagger specification:
```
curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json
git submodule update --init --recursive --depth 1
```
3. In `api-ref-assets/config/`, adapt the files `toc.yaml` and `fields.yaml` to reflect the changes of the new release.
2. Create a new API revision into the submodule, and add the Swagger specification:
4. Next, build the pages:
```
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
```
```bash
make api-reference
```
3. Copy the table of contents and fields configuration for the new release from a previous one:
You can test the results locally by making and serving the site from a container image:
```
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/
```
```bash
make container-image
make container-serve
```
4. Adapt the files `toc.yaml` and `fields.yaml` to reflect the changes between the two releases
In a web browser, go to <http://localhost:1313/docs/reference/kubernetes-api/> to view the API reference.
5. Next, build the pages:
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.
```
make api-reference
```
You can test the results locally by making and serving the site from a container image:
```
make container-image
make container-serve
```
In a web browser, go to http://localhost:1313/docs/reference/kubernetes-api/ to view the API reference.
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
### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version
Hugo is shipped in two set of binaries for technical reasons. The current website runs based on the **Hugo Extended** version only. In the [release page](https://github.com/gohugoio/hugo/releases) look for archives with `extended` in the name. To confirm, run `hugo version` and look for the word `extended`.
@@ -108,7 +115,7 @@ Hugo is shipped in two set of binaries for technical reasons. The current websit
If you run `make serve` on macOS and receive the following error:
```bash
```
ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files
make: *** [serve] Error 1
```
@@ -117,7 +124,7 @@ Try checking the current limit for open files:
`launchctl limit maxfiles`
Then run the following commands (adapted from <https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c>):
Then run the following commands (adapted from https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c):
```shell
#!/bin/sh
@@ -140,49 +147,49 @@ sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist
This works for Catalina as well as Mojave macOS.
## Get involved with SIG Docs
# Get involved with SIG Docs
Learn more about SIG Docs Kubernetes community and meetings on the [community page](https://github.com/kubernetes/community/tree/master/sig-docs#meetings).
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
# Contributing to the docs
You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a _fork_. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it.
You can click the **Fork** button in the upper-right area of the screen to create a copy of this repository in your GitHub account. This copy is called a *fork*. Make any changes you want in your fork, and when you are ready to send those changes to us, go to your fork and create a new pull request to let us know about it.
Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback. As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.**
Once your pull request is created, a Kubernetes reviewer will take responsibility for providing clear, actionable feedback. As the owner of the pull request, **it is your responsibility to modify your pull request to address the feedback that has been provided to you by the Kubernetes reviewer.**
Also, note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one initially assigned to provide you feedback.
Furthermore, in some cases, one of your reviewers might ask for a technical review from a Kubernetes tech reviewer when needed. Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.
Furthermore, in some cases, one of your reviewers might ask for a technical review from a Kubernetes tech reviewer when needed. Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.
For more information about contributing to the Kubernetes documentation, see:
- [Contribute to Kubernetes docs](https://kubernetes.io/docs/contribute/)
- [Page Content Types](https://kubernetes.io/docs/contribute/style/page-content-types/)
- [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/)
- [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)
* [Contribute to Kubernetes docs](https://kubernetes.io/docs/contribute/)
* [Page Content Types](https://kubernetes.io/docs/contribute/style/page-content-types/)
* [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/)
* [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)
## Localization `README.md`'s
# Localization `README.md`'s
| Language | Language |
| -------------------------- | -------------------------- |
| [Chinese](README-zh.md) | [Korean](README-ko.md) |
| [French](README-fr.md) | [Polish](README-pl.md) |
| [German](README-de.md) | [Portuguese](README-pt.md) |
| [Hindi](README-hi.md) | [Russian](README-ru.md) |
| [Indonesian](README-id.md) | [Spanish](README-es.md) |
| [Italian](README-it.md) | [Ukrainian](README-uk.md) |
| [Japanese](README-ja.md) | [Vietnamese](README-vi.md) |
| Language | Language |
|---|---|
|[Chinese](README-zh.md)|[Korean](README-ko.md)|
|[French](README-fr.md)|[Polish](README-pl.md)|
|[German](README-de.md)|[Portuguese](README-pt.md)|
|[Hindi](README-hi.md)|[Russian](README-ru.md)|
|[Indonesian](README-id.md)|[Spanish](README-es.md)|
|[Italian](README-it.md)|[Ukrainian](README-uk.md)|
|[Japanese](README-ja.md)|[Vietnamese](README-vi.md)|
## Code of conduct
# Code of conduct
Participation in the Kubernetes community is governed by the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).
## Thank you
# Thank you!
Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation!
+3
View File
@@ -4,6 +4,8 @@
Join the [kubernetes-security-announce] group for security and vulnerability announcements.
You can also subscribe to an RSS feed of the above using [this link][kubernetes-security-announce-rss].
## Reporting a Vulnerability
Instructions for reporting a vulnerability can be found on the
@@ -15,5 +17,6 @@ Information about supported Kubernetes versions can be found on the
[Kubernetes version and version skew support policy] page on the Kubernetes website.
[kubernetes-security-announce]: https://groups.google.com/forum/#!forum/kubernetes-security-announce
[kubernetes-security-announce-rss]: https://groups.google.com/forum/feed/kubernetes-security-announce/msgs/rss_v2_0.xml?num=50
[Kubernetes version and version skew support policy]: https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions
[Kubernetes Security and Disclosure Information]: https://kubernetes.io/docs/reference/issues-security/security/#report-a-vulnerability
+4 -3
View File
@@ -1,6 +1,6 @@
# Defined below are the security contacts for this repo.
#
# They are the contact point for the Security Response Committee to reach out
# They are the contact point for the Product Security Committee to reach out
# to for triaging and handling of incoming issues.
#
# The below names agree to abide by the
@@ -10,6 +10,7 @@
# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE
# INSTRUCTIONS AT https://kubernetes.io/security/
divya-mohan0209
irvifa
jimangel
sftim
kbarnard10
sftim
File diff suppressed because it is too large Load Diff
-696
View File
@@ -1,696 +0,0 @@
- definition: io.k8s.api.core.v1.PodSpec
field_categories:
- name: Containers
fields:
- containers
- initContainers
- imagePullSecrets
- enableServiceLinks
- name: Volumes
fields:
- volumes
- name: Scheduling
fields:
- nodeSelector
- nodeName
- affinity
- tolerations
- schedulerName
- runtimeClassName
- priorityClassName
- priority
- topologySpreadConstraints
- name: Lifecycle
fields:
- restartPolicy
- terminationGracePeriodSeconds
- activeDeadlineSeconds
- readinessGates
- name: Hostname and Name resolution
fields:
- hostname
- setHostnameAsFQDN
- subdomain
- hostAliases
- dnsConfig
- dnsPolicy
- name: Hosts namespaces
fields:
- hostNetwork
- hostPID
- hostIPC
- shareProcessNamespace
- name: Service account
fields:
- serviceAccountName
- automountServiceAccountToken
- name: Security context
fields:
- securityContext
- name: Beta level
fields:
- preemptionPolicy
- overhead
- name: Alpha level
fields:
- ephemeralContainers
- name: Deprecated
fields:
- serviceAccount
- definition: io.k8s.api.core.v1.PodSecurityContext
field_categories:
- fields:
- runAsUser
- runAsNonRoot
- runAsGroup
- supplementalGroups
- fsGroup
- fsGroupChangePolicy
- seccompProfile
- seLinuxOptions
- sysctls
- windowsOptions
- definition: io.k8s.api.core.v1.Toleration
field_categories:
- fields:
- key
- operator
- value
- effect
- tolerationSeconds
- definition: io.k8s.api.core.v1.PodStatus
field_categories:
- fields:
- nominatedNodeName
- hostIP
- startTime
- phase
- message
- reason
- podIP
- podIPs
- conditions
- qosClass
- initContainerStatuses
- containerStatuses
- ephemeralContainerStatuses
- definition: io.k8s.api.core.v1.Container
field_categories:
- fields:
- name
- name: Image
fields:
- image
- imagePullPolicy
- name: Entrypoint
fields:
- command
- args
- workingDir
- name: Ports
fields:
- ports
- name: Environment variables
fields:
- env
- envFrom
- name: Volumes
fields:
- volumeMounts
- volumeDevices
- name: Resources
fields:
- resources
- name: Lifecycle
fields:
- lifecycle
- terminationMessagePath
- terminationMessagePolicy
- livenessProbe
- readinessProbe
- startupProbe
- name: Security Context
fields:
- securityContext
- name: Debugging
fields:
- stdin
- stdinOnce
- tty
- definition: io.k8s.api.core.v1.Probe
field_categories:
- fields:
- exec
- httpGet
- tcpSocket
- initialDelaySeconds
- terminationGracePeriodSeconds
- periodSeconds
- timeoutSeconds
- failureThreshold
- successThreshold
- definition: io.k8s.api.core.v1.SecurityContext
field_categories:
- fields:
- runAsUser
- runAsNonRoot
- runAsGroup
- readOnlyRootFilesystem
- procMount
- privileged
- allowPrivilegeEscalation
- capabilities
- seccompProfile
- seLinuxOptions
- windowsOptions
- definition: io.k8s.api.core.v1.ContainerStatus
field_categories:
- fields:
- name
- image
- imageID
- containerID
- state
- lastState
- ready
- restartCount
- started
- definition: io.k8s.api.core.v1.ContainerStateTerminated
field_categories:
- fields:
- containerID
- exitCode
- startedAt
- finishedAt
- message
- reason
- signal
- definition: io.k8s.api.core.v1.EphemeralContainer
field_categories:
- fields:
- name
- targetContainerName
- name: Image
fields:
- image
- imagePullPolicy
- name: Entrypoint
fields:
- command
- args
- workingDir
- name: Environment variables
fields:
- env
- envFrom
- name: Volumes
fields:
- volumeMounts
- volumeDevices
- name: Lifecycle
fields:
- terminationMessagePath
- terminationMessagePolicy
- name: Debugging
fields:
- stdin
- stdinOnce
- tty
- name: Not allowed
fields:
- ports
- resources
- lifecycle
- livenessProbe
- readinessProbe
- securityContext
- startupProbe
- definition: io.k8s.api.core.v1.ReplicationControllerSpec
field_categories:
- fields:
- selector
- template
- replicas
- minReadySeconds
- definition: io.k8s.api.core.v1.ReplicationControllerStatus
field_categories:
- fields:
- replicas
- availableReplicas
- readyReplicas
- fullyLabeledReplicas
- conditions
- observedGeneration
- definition: io.k8s.api.apps.v1.ReplicaSetSpec
field_categories:
- fields:
- selector
- template
- replicas
- minReadySeconds
- definition: io.k8s.api.apps.v1.ReplicaSetStatus
field_categories:
- fields:
- replicas
- availableReplicas
- readyReplicas
- fullyLabeledReplicas
- conditions
- observedGeneration
- definition: io.k8s.api.apps.v1.DeploymentSpec
field_categories:
- fields:
- selector
- template
- replicas
- minReadySeconds
- strategy
- revisionHistoryLimit
- progressDeadlineSeconds
- paused
- definition: io.k8s.api.apps.v1.DeploymentStatus
field_categories:
- fields:
- replicas
- availableReplicas
- readyReplicas
- unavailableReplicas
- updatedReplicas
- collisionCount
- conditions
- observedGeneration
- definition: io.k8s.api.apps.v1.DeploymentStrategy
field_categories:
- fields:
- type
- rollingUpdate
- definition: io.k8s.api.apps.v1.StatefulSetSpec
field_categories:
- fields:
- serviceName
- selector
- template
- replicas
- updateStrategy
- podManagementPolicy
- revisionHistoryLimit
- volumeClaimTemplates
- minReadySeconds
- definition: io.k8s.api.apps.v1.StatefulSetUpdateStrategy
field_categories:
- fields:
- type
- rollingUpdate
- definition: io.k8s.api.apps.v1.StatefulSetStatus
field_categories:
- fields:
- replicas
- readyReplicas
- currentReplicas
- updatedReplicas
- availableReplicas
- collisionCount
- conditions
- currentRevision
- updateRevision
- observedGeneration
- definition: io.k8s.api.apps.v1.DaemonSetSpec
field_categories:
- fields:
- selector
- template
- minReadySeconds
- updateStrategy
- revisionHistoryLimit
- definition: io.k8s.api.apps.v1.DaemonSetUpdateStrategy
field_categories:
- fields:
- type
- rollingUpdate
- definition: io.k8s.api.apps.v1.DaemonSetStatus
field_categories:
- fields:
- numberReady
- numberAvailable
- numberUnavailable
- numberMisscheduled
- desiredNumberScheduled
- currentNumberScheduled
- updatedNumberScheduled
- collisionCount
- conditions
- observedGeneration
- definition: io.k8s.api.batch.v1.JobSpec
field_categories:
- name: Replicas
fields:
- template
- parallelism
- name: Lifecycle
fields:
- completions
- completionMode
- backoffLimit
- activeDeadlineSeconds
- ttlSecondsAfterFinished
- suspend
- name: Selector
fields:
- selector
- manualSelector
- definition: io.k8s.api.batch.v1.JobStatus
field_categories:
- fields:
- startTime
- completionTime
- active
- failed
- succeeded
- completedIndexes
- conditions
- uncountedTerminatedPods
- definition: io.k8s.api.batch.v1.CronJobSpec
field_categories:
- fields:
- jobTemplate
- schedule
- concurrencyPolicy
- startingDeadlineSeconds
- suspend
- successfulJobsHistoryLimit
- failedJobsHistoryLimit
- definition: io.k8s.api.autoscaling.v2beta2.HorizontalPodAutoscalerSpec
field_categories:
- fields:
- maxReplicas
- scaleTargetRef
- minReplicas
- behavior
- metrics
- definition: io.k8s.api.autoscaling.v2beta2.HPAScalingPolicy
field_categories:
- fields:
- type
- value
- periodSeconds
- definition: io.k8s.api.core.v1.ServiceSpec
field_categories:
- fields:
- selector
- ports
- type
- ipFamilies
- ipFamilyPolicy
- clusterIP
- clusterIPs
- externalIPs
- sessionAffinity
- loadBalancerIP
- loadBalancerSourceRanges
- loadBalancerClass
- externalName
- externalTrafficPolicy
- internalTrafficPolicy
- healthCheckNodePort
- publishNotReadyAddresses
- sessionAffinityConfig
- allocateLoadBalancerNodePorts
- definition: io.k8s.api.core.v1.ServicePort
field_categories:
- fields:
- port
- targetPort
- protocol
- name
- nodePort
- appProtocol
- definition: io.k8s.api.core.v1.EndpointSubset
field_categories:
- fields:
- addresses
- notReadyAddresses
- ports
- definition: io.k8s.api.core.v1.EndpointPort
field_categories:
- fields:
- port
- protocol
- name
- appProtocol
- definition: io.k8s.api.discovery.v1.EndpointPort
field_categories:
- fields:
- port
- protocol
- name
- appProtocol
- definition: io.k8s.api.core.v1.Volume
field_categories:
- fields:
- name
- name: Exposed Persistent volumes
fields:
- persistentVolumeClaim
- name: Projections
fields:
- configMap
- secret
- downwardAPI
- projected
- name: Local / Temporary Directory
fields:
- emptyDir
- hostPath
- name: Persistent volumes
fields:
- awsElasticBlockStore
- azureDisk
- azureFile
- cephfs
- cinder
- csi
- fc
- flexVolume
- flocker
- gcePersistentDisk
- glusterfs
- iscsi
- nfs
- photonPersistentDisk
- portworxVolume
- quobyte
- rbd
- scaleIO
- storageos
- vsphereVolume
- name: Alpha level
fields:
- ephemeral
- name: Deprecated
fields:
- gitRepo
- definition: io.k8s.api.core.v1.ConfigMapVolumeSource
field_categories:
- fields:
- name
- optional
- defaultMode
- items
- definition: io.k8s.api.core.v1.SecretVolumeSource
field_categories:
- fields:
- secretName
- optional
- defaultMode
- items
- definition: io.k8s.api.core.v1.ConfigMapProjection
field_categories:
- fields:
- name
- optional
- items
- definition: io.k8s.api.core.v1.SecretProjection
field_categories:
- fields:
- name
- optional
- items
- definition: io.k8s.api.core.v1.ProjectedVolumeSource
field_categories:
- fields:
- defaultMode
- sources
- definition: io.k8s.api.core.v1.PersistentVolumeClaimSpec
field_categories:
- fields:
- accessModes
- selector
- resources
- volumeName
- storageClassName
- volumeMode
- name: Alpha level
fields:
- dataSource
- dataSourceRef
- definition: io.k8s.api.core.v1.PersistentVolumeSpec
field_categories:
- fields:
- accessModes
- capacity
- claimRef
- mountOptions
- nodeAffinity
- persistentVolumeReclaimPolicy
- storageClassName
- volumeMode
- name: Local
fields:
- hostPath
- local
- name: Persistent volumes
fields:
- awsElasticBlockStore
- azureDisk
- azureFile
- cephfs
- cinder
- csi
- fc
- flexVolume
- flocker
- gcePersistentDisk
- glusterfs
- iscsi
- nfs
- photonPersistentDisk
- portworxVolume
- quobyte
- rbd
- scaleIO
- storageos
- vsphereVolume
- definition: io.k8s.api.rbac.v1.PolicyRule
field_categories:
- fields:
- apiGroups
- resources
- verbs
- resourceNames
- nonResourceURLs
- definition: io.k8s.api.networking.v1.NetworkPolicySpec
field_categories:
- fields:
- podSelector
- policyTypes
- ingress
- egress
- definition: io.k8s.api.networking.v1.NetworkPolicyEgressRule
field_categories:
- fields:
- to
- ports
- definition: io.k8s.api.networking.v1.NetworkPolicyPort
field_categories:
- fields:
- port
- endPort
- protocol
- definition: io.k8s.api.policy.v1beta1.PodSecurityPolicySpec
field_categories:
- fields:
- runAsUser
- runAsGroup
- fsGroup
- supplementalGroups
- seLinux
- readOnlyRootFilesystem
- privileged
- allowPrivilegeEscalation
- defaultAllowPrivilegeEscalation
- allowedCSIDrivers
- allowedCapabilities
- requiredDropCapabilities
- defaultAddCapabilities
- allowedFlexVolumes
- allowedHostPaths
- allowedProcMountTypes
- allowedUnsafeSysctls
- forbiddenSysctls
- hostIPC
- hostNetwork
- hostPID
- hostPorts
- runtimeClass
- volumes
- definition: io.k8s.apimachinery.pkg.apis.meta.v1.ObjectMeta
field_categories:
- fields:
- name
- generateName
- namespace
- labels
- annotations
- name: System
fields:
- finalizers
- managedFields
- ownerReferences
- name: Read-only
fields:
- creationTimestamp
- deletionGracePeriodSeconds
- deletionTimestamp
- generation
- resourceVersion
- selfLink
- uid
- name: Ignored
fields:
- clusterName
-267
View File
@@ -1,267 +0,0 @@
# Copyright 2016 The Kubernetes Authors.
# Copyright 2020 Philippe Martin
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
parts:
- name: Workload Resources
chapters:
- name: Pod
group: ""
version: v1
otherDefinitions:
- PodSpec
- Container
- EphemeralContainer
- Handler
- NodeAffinity
- PodAffinity
- PodAntiAffinity
- Probe
- PodStatus
- PodList
- name: PodTemplate
group: ""
version: v1
- name: ReplicationController
group: ""
version: v1
- name: ReplicaSet
group: apps
version: v1
- name: Deployment
group: apps
version: v1
- name: StatefulSet
group: apps
version: v1
- name: ControllerRevision
group: apps
version: v1
- name: DaemonSet
group: apps
version: v1
- name: Job
group: batch
version: v1
- name: CronJob
group: batch
version: v1
- name: HorizontalPodAutoscaler
group: autoscaling
version: v1
- name: HorizontalPodAutoscaler
group: autoscaling
version: v2beta2
- name: PriorityClass
group: scheduling.k8s.io
version: v1
- name: Service Resources
chapters:
- name: Service
group: ""
version: v1
- name: Endpoints
group: ""
version: v1
- name: EndpointSlice
group: discovery.k8s.io
version: v1
- name: Ingress
group: networking.k8s.io
version: v1
otherDefinitions:
- IngressSpec
- IngressBackend
- IngressStatus
- IngressList
- name: IngressClass
group: networking.k8s.io
version: v1
- name: Config and Storage Resources
chapters:
- name: ConfigMap
group: ""
version: v1
- name: Secret
group: ""
version: v1
- name: Volume
key: io.k8s.api.core.v1.Volume
otherDefinitions:
- DownwardAPIVolumeFile
- KeyToPath
- name: PersistentVolumeClaim
group: ""
version: v1
- name: PersistentVolume
group: ""
version: v1
- name: StorageClass
group: storage.k8s.io
version: v1
- name: VolumeAttachment
group: storage.k8s.io
version: v1
- name: CSIDriver
group: storage.k8s.io
version: v1
- name: CSINode
group: storage.k8s.io
version: v1
- name: CSIStorageCapacity
group: storage.k8s.io
version: v1beta1
- name: Authentication Resources
chapters:
- name: ServiceAccount
group: ""
version: v1
- name: TokenRequest
group: authentication.k8s.io
version: v1
- name: TokenReview
group: authentication.k8s.io
version: v1
- name: CertificateSigningRequest
group: certificates.k8s.io
version: v1
- name: Authorization Resources
chapters:
- name: LocalSubjectAccessReview
group: authorization.k8s.io
version: v1
- name: SelfSubjectAccessReview
group: authorization.k8s.io
version: v1
- name: SelfSubjectRulesReview
group: authorization.k8s.io
version: v1
- name: SubjectAccessReview
group: authorization.k8s.io
version: v1
- name: ClusterRole
group: rbac.authorization.k8s.io
version: v1
- name: ClusterRoleBinding
group: rbac.authorization.k8s.io
version: v1
- name: Role
group: rbac.authorization.k8s.io
version: v1
- name: RoleBinding
group: rbac.authorization.k8s.io
version: v1
- name: Policy Resources
chapters:
- name: LimitRange
group: ""
version: v1
- name: ResourceQuota
group: ""
version: v1
- name: NetworkPolicy
group: networking.k8s.io
version: v1
- name: PodDisruptionBudget
group: policy
version: v1
- name: PodSecurityPolicy
group: policy
version: v1beta1
- name: Extend Resources
chapters:
- name: CustomResourceDefinition
group: apiextensions.k8s.io
version: v1
otherDefinitions:
- CustomResourceDefinitionSpec
- JSONSchemaProps
- CustomResourceDefinitionStatus
- CustomResourceDefinitionList
- name: MutatingWebhookConfiguration
group: admissionregistration.k8s.io
version: v1
- name: ValidatingWebhookConfiguration
group: admissionregistration.k8s.io
version: v1
- name: Cluster Resources
chapters:
- name: Node
group: ""
version: v1
- name: Namespace
group: ""
version: v1
- name: Event
group: events.k8s.io
version: v1
- name: APIService
group: apiregistration.k8s.io
version: v1
- name: Lease
group: coordination.k8s.io
version: v1
- name: RuntimeClass
group: node.k8s.io
version: v1
- name: FlowSchema
group: flowcontrol.apiserver.k8s.io
version: v1beta1
- name: PriorityLevelConfiguration
group: flowcontrol.apiserver.k8s.io
version: v1beta1
- name: Binding
group: ""
version: v1
- name: ComponentStatus
group: ""
version: v1
- name: Common Definitions
chapters:
- name: DeleteOptions
key: io.k8s.apimachinery.pkg.apis.meta.v1.DeleteOptions
- name: LabelSelector
key: io.k8s.apimachinery.pkg.apis.meta.v1.LabelSelector
- name: ListMeta
key: io.k8s.apimachinery.pkg.apis.meta.v1.ListMeta
- name: LocalObjectReference
key: io.k8s.api.core.v1.LocalObjectReference
- name: NodeSelectorRequirement
key: io.k8s.api.core.v1.NodeSelectorRequirement
- name: ObjectFieldSelector
key: io.k8s.api.core.v1.ObjectFieldSelector
- name: ObjectMeta
key: io.k8s.apimachinery.pkg.apis.meta.v1.ObjectMeta
- name: ObjectReference
key: io.k8s.api.core.v1.ObjectReference
- name: Patch
key: io.k8s.apimachinery.pkg.apis.meta.v1.Patch
- name: Quantity
key: "io.k8s.apimachinery.pkg.api.resource.Quantity"
- name: ResourceFieldSelector
key: io.k8s.api.core.v1.ResourceFieldSelector
- name: Status
key: io.k8s.apimachinery.pkg.apis.meta.v1.Status
- name: TypedLocalObjectReference
key: io.k8s.api.core.v1.TypedLocalObjectReference
skippedResources:
- APIGroup
- APIGroupList
- APIResourceList
- APIVersions
- Eviction
- Scale
- Status
- StorageVersion
- StorageVersionList
@@ -1,83 +0,0 @@
---
api_metadata:
apiVersion: "{{.ApiVersion}}"
import: "{{.Import}}"
kind: "{{.Kind}}"
content_type: "api_reference"
description: "{{.Metadata.Description}}"
title: "{{.Metadata.Title}}"
weight: {{.Metadata.Weight}}
auto_generated: true
---
<!--
The file is auto-generated from the Go source code of the component using a generic
[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
to generate the reference documentation, please read
[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
To update the reference content, please follow the
[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
guide. You can file document formatting bugs against the
[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
-->
{{if .ApiVersion}}`apiVersion: {{.ApiVersion}}`{{end}}
{{if .Import}}`import "{{.Import}}"`{{end}}
{{range .Sections}}
{{.Description | replace "<" "\\<" }}
<hr>
{{range .Fields}}
{{ "" | indent .Indent | indent .Indent}}- {{.Name}}{{if .Value}}: {{.Value}}{{end}}
{{if .Description}}
{{.Description | replace "<" "\\<" | indent 2 | indent .Indent | indent .Indent}}
{{- end}}
{{if .TypeDefinition}}
{{ "" | indent .Indent | indent .Indent}} <a name="{{.Type}}"></a>
{{.TypeDefinition | indent 2 | indent .Indent | indent .Indent}}
{{end}}
{{- end}}{{/* range .Fields */}}
{{range .FieldCategories}}
### {{.Name}} {#{{"-" | regexReplaceAll "[^a-zA-Z0-9]+" .Name }}}{{/* explicitly set fragment to keep capitalization */}}
{{range .Fields}}
{{ "" | indent .Indent | indent .Indent}}- {{.Name}}{{if .Value}}: {{.Value}}{{end}}
{{if .Description}}
{{.Description | replace "<" "\\<" | indent 2 | indent .Indent | indent .Indent}}
{{- end}}
{{if .TypeDefinition}}
{{ "" | indent .Indent | indent .Indent}} <a name="{{.Type}}"></a>
{{.TypeDefinition | indent 2 | indent .Indent | indent .Indent}}
{{end}}
{{- end}}{{/* range .Fields */}}
{{- end}}{{/* range .FieldCategories */}}
{{range .Operations}}
### `{{.Verb}}` {{.Title}}
#### HTTP Request
{{.RequestMethod}} {{.RequestPath}}
#### Parameters
{{range .Parameters}}
- {{.Title}}
{{.Description | indent 2}}
{{end}}{{/* range .Parameters */}}
#### Response
{{range .Responses}}
{{.Code}}{{if .Type}} ({{.Type}}){{end}}: {{.Description}}
{{end}}{{/* range .Responses */}}
{{- end}}{{/* range .Operations */}}
{{- end}}{{/* range .Sections */}}
-85
View File
@@ -1,85 +0,0 @@
---
api_metadata:
apiVersion: "{{.ApiVersion}}"
import: "{{.Import}}"
kind: "{{.Kind}}"
content_type: "api_reference"
description: "{{.Metadata.Description}}"
title: "{{.Metadata.Title}}"
weight: {{.Metadata.Weight}}
auto_generated: true
---
<!--
The file is auto-generated from the Go source code of the component using a generic
[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
to generate the reference documentation, please read
[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
To update the reference content, please follow the
[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
guide. You can file document formatting bugs against the
[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
-->
{{if .ApiVersion}}`apiVersion: {{.ApiVersion}}`{{end}}
{{if .Import}}`import "{{.Import}}"`{{end}}
{{range .Sections}}
## {{.Name}} {#{{"-" | regexReplaceAll "[^a-zA-Z0-9]+" .Name }}}{{/* explicitly set fragment to keep capitalization */}}
{{.Description | replace "<" "\\<" }}
<hr>
{{range .Fields}}
{{ "" | indent .Indent | indent .Indent}}- {{.Name}}{{if .Value}}: {{.Value}}{{end}}
{{if .Description}}
{{.Description | replace "<" "\\<" | indent 2 | indent .Indent | indent .Indent}}
{{- end}}
{{if .TypeDefinition}}
{{ "" | indent .Indent | indent .Indent}} <a name="{{.Type}}"></a>
{{.TypeDefinition | indent 2 | indent .Indent | indent .Indent}}
{{end}}
{{- end}}{{/* range .Fields */}}
{{range .FieldCategories}}
### {{.Name}}
{{range .Fields}}
{{ "" | indent .Indent | indent .Indent}}- {{.Name}}{{if .Value}}: {{.Value}}{{end}}
{{if .Description}}
{{.Description | replace "<" "\\<" | indent 2 | indent .Indent | indent .Indent}}
{{- end}}
{{if .TypeDefinition}}
{{ "" | indent .Indent | indent .Indent}} <a name="{{.Type}}"></a>
{{.TypeDefinition | indent 2 | indent .Indent | indent .Indent}}
{{end}}
{{- end}}{{/* range .Fields */}}
{{- end}}{{/* range .FieldCategories */}}
{{range .Operations}}
### `{{.Verb}}` {{.Title}}
#### HTTP Request
{{.RequestMethod}} {{.RequestPath}}
#### Parameters
{{range .Parameters}}
- {{.Title}}
{{.Description | indent 2}}
{{end}}{{/* range .Parameters */}}
#### Response
{{range .Responses}}
{{.Code}}{{if .Type}} ({{.Type}}){{end}}: {{.Description}}
{{end}}{{/* range .Responses */}}
{{- end}}{{/* range .Operations */}}
{{- end}}{{/* range .Sections */}}
-17
View File
@@ -1,17 +0,0 @@
---
title: "{{.Title}}"
weight: {{.Weight}}
auto_generated: true
---
<!--
The file is auto-generated from the Go source code of the component using a generic
[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
to generate the reference documentation, please read
[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
To update the reference content, please follow the
[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
guide. You can file document formatting bugs against the
[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
-->
-61
View File
@@ -1,61 +0,0 @@
---
layout: blog
title: "{{ replace .Name "-" " " | title }}"
date: {{ .Date }}
draft: true
slug: <seo-friendly-version-of-title-separated-by-dashes>
---
**Author:** <your name> (<your organization name>), <another author's name> (<their organization>)
<!--
Instructions:
- Replace these instructions and the following text with your content.
- Replace `<angle bracket placeholders>` with actual values. For example, you would update `date: <yyyy>-<mm>-<dd>` to look something like `date: 2021-10-21`.
- For convenience, use third-party tools to author and collaborate on your content.
- To save time and effort in reviews, check your content's spelling, grammar, and style before contributing.
- Feel free to ask for assistance in the Kubernetes Slack channel, [#sig-docs-blog](https://kubernetes.slack.com/archives/CJDHVD54J).
-->
Replace this first line of your content with one to three sentences that summarize the blog post.
## This is a section heading
To help the reader, organize your content into sections that contain about three to six paragraphs.
If you're documenting commands, separate the commands from the outputs, like this:
1. Verify that the Secret exists by running the following command:
```shell
kubectl get secrets
```
The response should be like this:
```shell
NAME TYPE DATA AGE
mysql-pass-c57bb4t7mf Opaque 1 9s
```
You're free to create any sections you like. Below are a few common patterns we see at the end of blog posts.
## Whats next?
This optional section describes the future of the thing you've just described in the post.
## How can I learn more?
This optional section provides links to more information. Please avoid promoting and over-represent your organization.
## How do I get involved?
An optional section that links to resources for readers to get involved, and acknowledgments of individual contributors, such as:
* [The name of a channel on Slack, #a-channel](https://<a-workspace>.slack.com/messages/<a-channel>)
* [A link to a "contribute" page with more information](<https://github.com/kubernetes/community/blob/master/sig-storage/README.md#contact>).
* Acknowledgements and thanks to the contributors. <person's name> ([<github id>](https://github.com/<github id>)) who did X, Y, and Z.
* Those interested in getting involved with the design and development of <project>, join the [<name of the SIG>](https://github.com/project/community/tree/master/<sig-group>). Were rapidly growing and always welcome new contributors.
+16 -4
View File
@@ -810,10 +810,11 @@ section#cncf {
}
}
// Header filler size adjustment
.header-hero.filler {
height: $hero-padding-top;
.td-search {
header > .header-filler {
height: $hero-padding-top;
background-color: black;
}
}
// Docs specific
@@ -858,6 +859,17 @@ section#cncf {
/* DOCUMENTATION */
body.td-documentation {
header > .header-filler {
height: $hero-padding-top;
background-color: black;
}
/* Special case for if an announcement is active */
header section#announcement ~ .header-filler {
display: none;
}
}
// nav-tabs and tab-content
.nav-tabs {
border-bottom: none !important;
+70 -214
View File
@@ -26,10 +26,6 @@ $announcement-size-adjustment: 8px;
}
}
.header-hero #quickstartButton.button {
margin-top: 1em;
}
section {
.main-section {
@media only screen and (min-width: 1024px) {
@@ -38,11 +34,8 @@ section {
}
}
body {
header + .td-outer {
min-height: 50vh;
height: auto;
}
.td-outer {
padding: 0 !important;
}
@@ -320,68 +313,37 @@ main {
// blockquotes and callouts
body {
.alert {
// Override Docsy styles
.td-content, body {
blockquote.callout {
padding: 0.4rem 0.4rem 0.4rem 1rem;
border-top: 1px solid #eee;
border-bottom: 1px solid #eee;
border-right: 1px solid #eee;
border-radius: 0.25em;
border-left-width: 0.5em; // fallback in case calc() is missing
border: 1px solid #eee;
border-left-width: 0.5em;
background: #fff;
color: #000;
margin-top: 0.5em;
margin-bottom: 0.5em;
}
// Set minimum width and radius for alert color
.alert {
border-left-width: calc(max(0.5em, 4px));
border-top-left-radius: calc(max(0.5em, 4px));
border-bottom-left-radius: calc(max(0.5em, 4px));
blockquote.callout {
border-radius: calc(1em/3);
}
.alert.callout.caution {
.callout.caution {
border-left-color: #f0ad4e;
}
.alert.callout.note {
.callout.note {
border-left-color: #428bca;
}
.alert.callout.warning {
.callout.warning {
border-left-color: #d9534f;
}
.alert.third-party-content {
border-left-color: #444;
}
h1:first-of-type + .alert.callout {
h1:first-of-type + blockquote.callout {
margin-top: 1.5em;
}
}
// Special color for third party content disclaimers
.alert.third-party-content { border-left-color: #222 };
// Highlight disclaimer when targeted as a fragment
#third-party-content-disclaimer {
color: #000;
background: #f8f9fa;
transition: all 0.5s ease;
}
@keyframes disclaimer-highlight {
from { background: #f8f922; color: #000; }
50% { background: #f8f944; color: #000; }
to { background: #f8f9cb; color: #000; }
}
#third-party-content-disclaimer:target {
color: #000;
animation: disclaimer-highlight 1.25s ease;
background: #f8f9cb;
}
.deprecation-warning, .pageinfo.deprecation-warning {
.deprecation-warning {
padding: 20px;
margin: 20px 0;
background-color: #faf5b6;
@@ -392,12 +354,6 @@ body.td-home .deprecation-warning, body.td-blog .deprecation-warning, body.td-do
border-radius: 3px;
}
.td-documentation .td-content > .highlight {
max-width: initial;
width: 100%;
}
body.td-home #deprecation-warning {
max-width: 1000px;
margin-top: 2.5rem;
@@ -568,6 +524,34 @@ main.content {
}
}
/* ANNOUNCEMENTS */
section#fp-announcement ~ .header-hero {
padding: $announcement-size-adjustment 0;
> div {
margin-top: $announcement-size-adjustment;
margin-bottom: $announcement-size-adjustment;
}
h1, h2, h3, h4, h5 {
margin: $announcement-size-adjustment 0;
}
}
section#announcement ~ .header-hero {
padding: #{$announcement-size-adjustment / 2} 0;
> div {
margin-top: #{$announcement-size-adjustment / 2};
margin-bottom: #{$announcement-size-adjustment / 2};
padding-bottom: #{$announcement-size-adjustment / 2};
}
h1, h2, h3, h4, h5 {
margin: #{$announcement-size-adjustment / 2} 0;
}
}
/* DOCUMENTATION */
/* Don't show lead text */
@@ -593,15 +577,15 @@ body.td-documentation {
@media print {
/* Do not print announcements */
#announcement {
#announcement, section#announcement, #fp-announcement, section#fp-announcement {
display: none;
}
}
#announcement {
#announcement, #fp-announcement {
> * {
color: inherit;
background: transparent;
background: inherit;
}
a {
@@ -615,97 +599,42 @@ body.td-documentation {
}
}
#announcement {
padding-top: 105px;
padding-bottom: 25px;
}
.header-hero {
padding-top: 40px;
}
#announcement {
.announcement-main {
margin-left: auto;
margin-right: auto;
/* Extra announcement height only for landscape viewports */
@media (min-aspect-ratio: 8/9) {
#fp-announcement {
min-height: 25vh;
}
}
#fp-announcement aside {
padding-top: 115px;
padding-bottom: 25px;
}
.announcement {
.content {
margin-bottom: 0px;
// for padding-top see _size.scss
padding-bottom: calc(max(2em, 2rem));
max-width: calc(min(1200px - 8em, 80vw));
}
/* always white */
h1, h2, h3, h4, h5, h6, p * {
color: #ffffff;
background: transparent;
img.event-logo {
display: inline-block;
max-height: calc(min(80px, 8em));
max-width: calc(min(240px, 33vw));
float: right;
> p {
.gridPage #announcement .content p,
.announcement > h4,
.announcement > h3 {
color: #ffffff;
}
}
}
#announcement + .header-hero {
padding-top: 2em;
}
// Extra padding for anything except wide viewports
@media (min-width: 992px) {
#announcement aside { // more specific
.announcement-main {
padding-top: calc(max(8em, 8rem));
}
}
}
@media (max-width: 768px) {
#announcement {
padding-top: 4rem;
padding-bottom: 4rem;
.announcement-main, aside .announcement-main {
padding-top: calc(min(2rem,2em));
}
}
}
@media (max-width: 480px) {
#announcement {
padding-bottom: 0.5em;
}
#announcement aside {
h1, h2, h3, h4, h5, h6 {
img.event-logo {
margin-left: auto;
margin-right: auto;
margin-bottom: 0.75em;
display: block;
max-height: initial;
max-width: calc(min(calc(100vw - 2em), 240px));
float: initial;
}
}
}
}
#announcement + .header-hero.filler {
display: none;
}
@media (min-width: 768px) {
#announcement + .header-hero {
display: none;
}
}
// Match Docsy-imposed max width on text body
@media (min-width: 1200px) {
body.td-blog main .td-content > figure {
max-width: 80%;
}
}
.td-content {
table code {
background-color: inherit !important;
@@ -713,76 +642,3 @@ body.td-documentation {
font-size: inherit !important;
}
}
/* Force size constraints on figures */
figure {
&.diagram-small img {
max-height: clamp(20mm,12em,80vh);
margin-left: auto;
margin-right: auto;
display: block;
}
&.diagram-medium img {
max-height: clamp(25mm,20em,80vh);
margin-left: auto;
margin-right: auto;
display: block;
}
&.diagram-large img {
max-width: clamp(0vw, 95vw, 100%);
max-height: calc(80vh - 8rem);
}
}
@media only screen and (min-width: 768px) {
figure {
&.diagram-small, &.diagram-medium {
max-width: 80%;
}
&.diagram-large {
max-width: 100%;
width: 100%;
}
&.diagram-small img {
max-width: clamp(30rem, 45ch, 100mm);
}
&.diagram-medium img {
max-width: clamp(50rem, 20ch, 160mm);
}
&.diagram-large img {
max-width: clamp(25vw, 95vw, 100%);
max-height: calc(100vh - 10rem);
}
}
}
// Indent definition lists
dl {
padding-left: 1.5em;
// Add vertical space before definitions
> *:not(dt) + dt, dt:first-child {
margin-top: 1.5em;
}
}
.release-details {
padding-left: 2em;
> :not(p) {
font-size: 1.125em;
}
.release-inline-heading, .release-inline-value {
display: inline-block
}
.release-inline-value {
padding-left: 0.25em;
}
p {
margin-top: 1em;
margin-bottom: 1em;
}
}
-8
View File
@@ -18,11 +18,3 @@ section,
line-height: $vendor-strip-height;
font-size: $vendor-strip-font-size;
}
#announcement {
min-height: $hero-padding-top;
.announcement-main {
padding-top: calc(max(8em, 8rem, #{$hero-padding-top} / 3));
}
}
-25
View File
@@ -1,25 +0,0 @@
# See https://cloud.google.com/cloud-build/docs/build-config
# this must be specified in seconds. If omitted, defaults to 600s (10 mins)
timeout: 1200s
# this prevents errors if you don't use both _GIT_TAG and _PULL_BASE_REF,
# or any new substitutions added in the future.
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"
entrypoint: make
env:
- DOCKER_CLI_EXPERIMENTAL=enabled
- TAG=$_GIT_TAG
- BASE_REF=$_PULL_BASE_REF
args:
- container-image
substitutions:
# _GIT_TAG will be filled with a git-based tag for the image, of the form vYYYYMMDD-hash, and
# can be used as a substitution
_GIT_TAG: "12345"
# _PULL_BASE_REF will contain the ref that was pushed to to trigger this build -
# a branch like 'master' or 'release-0.2', or a tag like 'v0.2'.
_PULL_BASE_REF: "master"
+28 -30
View File
@@ -123,7 +123,6 @@ id = "UA-00000000-0"
[params]
copyright_k8s = "The Kubernetes Authors"
copyright_linux = "Copyright © 2020 The Linux Foundation ®."
# privacy_policy = "https://policies.google.com/privacy"
# First one is picked as the Twitter card image if not set on page.
@@ -139,12 +138,12 @@ time_format_default = "January 02, 2006 at 3:04 PM PST"
description = "Production-Grade Container Orchestration"
showedit = true
latest = "v1.23"
latest = "v1.21"
fullversion = "v1.23.0"
version = "v1.23"
githubbranch = "main"
docsbranch = "main"
fullversion = "v1.21.0"
version = "v1.21"
githubbranch = "master"
docsbranch = "master"
deprecated = false
currentUrl = "https://kubernetes.io/docs/home/"
nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/"
@@ -179,46 +178,45 @@ js = [
]
[[params.versions]]
fullversion = "v1.23.0"
version = "v1.23"
githubbranch = "v1.23.0"
docsbranch = "main"
fullversion = "v1.21.0"
version = "v1.21"
githubbranch = "v1.21.0"
docsbranch = "master"
url = "https://kubernetes.io"
[[params.versions]]
fullversion = "v1.22.4"
version = "v1.22"
githubbranch = "v1.22.4"
docsbranch = "release-1.22"
url = "https://v1-22.docs.kubernetes.io"
[[params.versions]]
fullversion = "v1.21.7"
version = "v1.21"
githubbranch = "v1.21.7"
docsbranch = "release-1.21"
url = "https://v1-21.docs.kubernetes.io"
[[params.versions]]
fullversion = "v1.20.13"
fullversion = "v1.20.5"
version = "v1.20"
githubbranch = "v1.20.13"
githubbranch = "v1.20.5"
docsbranch = "release-1.20"
url = "https://v1-20.docs.kubernetes.io"
[[params.versions]]
fullversion = "v1.19.16"
fullversion = "v1.19.9"
version = "v1.19"
githubbranch = "v1.19.16"
githubbranch = "v1.19.9"
docsbranch = "release-1.19"
url = "https://v1-19.docs.kubernetes.io"
[[params.versions]]
fullversion = "v1.18.17"
version = "v1.18"
githubbranch = "v1.18.17"
docsbranch = "release-1.18"
url = "https://v1-18.docs.kubernetes.io"
[[params.versions]]
fullversion = "v1.17.17"
version = "v1.17"
githubbranch = "v1.17.17"
docsbranch = "release-1.17"
url = "https://v1-17.docs.kubernetes.io"
# User interface configuration
[params.ui]
# Enable to show the side bar menu in its compact state.
sidebar_menu_compact = false
# https://github.com/gohugoio/hugo/issues/8918#issuecomment-903314696
sidebar_cache_limit = 1
# Set to true to disable breadcrumb navigation.
breadcrumb_disable = false
# Set to true to hide the sidebar search box (the top nav search box will still be displayed if search is enabled)
+4 -4
View File
@@ -9,7 +9,7 @@ cid: home
{{% blocks/feature image="flower" %}}
### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen.
Es gruppiert Container, aus denen sich eine Anwendung zusammensetzt, in logische Einheiten, um die Verwaltung und Erkennung zu erleichtern. Kubernetes baut auf [15 Jahre Erfahrung in Bewältigung von Produktions-Workloads bei Google](http://queue.acm.org/detail.cfm?id=2898444), kombiniert mit Best-of-Breed-Ideen und Praktiken aus der Community.
Es gruppiert Container, aus denen sich eine Anwendung zusammensetzt, in logische Einheiten, um die Verwaltung und Erkennung zu erleichtern. Kubernetes baut auf [15 Jahre Erfahrung in Bewältigung von Produktions-Workloads bei Google] (http://queue.acm.org/detail.cfm?id=2898444), kombiniert mit Best-of-Breed-Ideen und Praktiken aus der Community.
{{% /blocks/feature %}}
{{% blocks/feature image="scalable" %}}
@@ -42,12 +42,12 @@ Kubernetes ist Open Source und bietet Dir die Freiheit, die Infrastruktur vor Or
<button id="desktopShowVideoButton" onclick="kub.showVideo()">Video ansehen</button>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Besuche die KubeCon North America vom 11. bis 15. Oktober 2021</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu20" button id="desktopKCButton">Besuche die KubeCon - 13-16 August 2020 in Amsterdam</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Besuche die KubeCon Europe vom 17. bis 20. Mai 2022</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna20" button id="desktopKCButton">Besuche die KubeCon - 17-20 November 2020 in Boston</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
@@ -57,4 +57,4 @@ Kubernetes ist Open Source und bietet Dir die Freiheit, die Infrastruktur vor Or
{{< blocks/kubernetes-features >}}
{{< blocks/case-studies >}}
{{< blocks/case-studies >}}
+51 -246
View File
@@ -4,253 +4,58 @@ layout: basic
cid: community
---
<div class="newcommunitywrapper">
<div class="banner1">
<img src="/images/community/kubernetes-community-final-02.jpg" alt="Kubernetes-Konferenz Galerie" style="width:100%;padding-left:0px" class="desktop">
<img src="/images/community/kubernetes-community-02-mobile.jpg" alt="Kubernetes-Konferenz Galerie" style="width:100%;padding-left:0px" class="mobile">
</div>
<section id="mainContent">
<main>
<div class="content">
<h3>Die Gewissheit, dass Kubernetes überall und für alle gut funktioniert.</h3>
<p>Verbinden Sie sich mit der Kubernetes-Community in unserem <a href="http://slack.k8s.io/">Slack Kanal</a>, <a href="https://discuss.kubernetes.io/">Diskussionsforum</a>, oder beteiligen Sie sich an der <a href="https://groups.google.com/g/kubernetes-dev"> Kubernetes-dev-Google-Gruppe</a>. Eine wöchentliches Community-Meeting findet per Videokonferenz statt, um den Stand der Dinge zu diskutieren, folgen Sie
<a href="https://github.com/kubernetes/community/blob/master/events/community-meeting.md">diesen Anweisungen</a> für Informationen wie Sie teilnehmen können.</p>
<p>Sie können Kubernetes auch auf der ganzen Welt über unsere
<a href="https://www.meetup.com/topics/kubernetes/">Kubernetes Meetup Community</a> und der
<a href="https://www.meetup.com/Kubernetes-Cloud-Native-Online-Meetup/">Kubernetes Cloud Native Meetup Community</a> beitreten.</p>
</div>
<div class="content">
<h3>Special Interest Groups (SIGs)</h3>
<p>Haben Sie ein besonderes Interesse daran, wie Kubernetes mit einer anderen Technologie arbeitet? Werfen Sie einen Blick auf unsere kontinuierlich wachsende
<a href="https://git.k8s.io/community/sig-list.md">Listen von SIGs</a>, von AWS und Openstack bis hin zu Big Data und Skalierbarkeit, es gibt einen Platz für Sie, an dem Sie mitwirken können, und Anweisungen zur Gründung einer neuen SIG finden, wenn Ihr besonderes Interesse (noch) nicht abgedeckt ist.
</p>
<div class="intro">
<br class="mobile">
<p>Die Kubernetes-Community - Nutzer, Mitwirkende und die Kultur, die wir gemeinsam aufgebaut haben - ist einer der Hauptgründe für den kometenhaften Aufstieg dieses Open-Source-Projekts. Unsere Kultur und unsere Werte wachsen und entwickeln sich mit dem Wachstum und der Veränderung des Projekts selbst. Wir alle arbeiten gemeinsam an der ständigen Verbesserung des Projekts und der Art und Weise, wie wir daran arbeiten.
<br><br>Wir sind die Leute, die Probleme und Pull-Requests einreichen, an SIG-Treffen (Special Interest Groups), Kubernetes-Treffen und der KubeCon teilnehmen, sich für die Einführung und Innovation von Kubernetes einsetzen, <code>kubectl get pods</code> ausführen und auf tausend andere wichtige Arten beitragen. Lies weiter, um zu erfahren, wie Du dich engagieren und Teil dieser faszinierenden Gemeinschaft werden kannst.</p>
<br class="mobile">
</div>
<p>Als Mitglied der Kubernetes-Community sind Sie herzlich eingeladen, an allen SIG-Treffen teilzunehmen, die Sie interessieren. Eine Registrierung ist nicht erforderlich.</p>
<div class="community__navbar">
</div>
<a href="#values">Gemeinschaftswerte</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#conduct">Verhaltenskodex </a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#videos">Videos</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#discuss">Diskussionen</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#events">Veranstaltungen und meetups</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#news">Neuigkeiten</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="/releases">Releases</a>
<div class="content">
<h3>Verhaltensregeln</h3>
<p>Die Kubernetes-Community schätzt Respekt und Inklusivität und setzt einen <a href="code-of-conduct/">Verhaltenskodex</a>
in allen Interaktionen durch. Wenn Sie einen Verstoß gegen den Verhaltenskodex bei einer Veranstaltung oder Sitzung,
in Slack oder in einem anderen Kommunikationsmechanismus feststellen, wenden Sie sich
bitte an das <a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct">Kubernetes Code of Conduct Committee</a> <a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>. Ihre Anonymität wird geschützt.
</p>
</div>
</main>
</section>
</div>
<br class="mobile"><br class="mobile">
<div class="imagecols">
<br class="mobile">
<div class="imagecol">
<img src="/images/community/kubernetes-community-final-03.jpg" alt="Kubernetes-Konferenz Galerie" style="width:100%" class="desktop">
</div>
<div class="imagecol">
<img src="/images/community/kubernetes-community-final-04.jpg" alt="Kubernetes-Konferenz Galerie" style="width:100%" class="desktop">
</div>
<div class="imagecol" style="margin-right:0% important">
<img src="/images/community/kubernetes-community-final-05.jpg" alt="Kubernetes-Konferenz Galerie" style="width:100%;margin-right:0% important" class="desktop">
</div>
<img src="/images/community/kubernetes-community-04-mobile.jpg" alt="Kubernetes-Konferenz Galerie" style="width:100%;margin-bottom:3%" class="mobile">
<a name="values"></a>
</div>
<div><a name="values"></a></div>
<div class="conduct">
<div class="conducttext">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<div class="conducttextnobutton" style="margin-bottom:2%"><h1>Gemeinschaftswerte</h1>
Die Werte der Kubernetes-Community sind der Grundstein für den anhaltenden Erfolg des Projekts.<br>
Diese Prinzipien leiten jeden Aspekt des Kubernetes-Projekts.
<br>
<a href="/community/values/">
<br class="mobile"><br class="mobile">
<span class="fullbutton">
MEHR ERFAHREN
</span>
</a>
</div><a name="conduct"></a>
</div>
</div>
<div class="conduct">
<div class="conducttext">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<div class="conducttextnobutton" style="margin-bottom:2%"><h1>Verhaltenskodex</h1>
Die Kubernetes-Gemeinschaft legt Wert auf Respekt und Inklusivität und setzt bei allen Interaktionen einen Verhaltenskodex durch. Wenn Du einen Verstoß gegen den Verhaltenskodex bei einer Veranstaltung oder einem Treffen, in Slack oder in einem anderen Kommunikationsmechanismus bemerkst, wende dich an das Kubernetes Code of Conduct Committee unter <a href="mailto:conduct@kubernetes.io" style="color:#0662EE;font-weight:300">conduct@kubernetes.io</a>. Alle Berichte werden vertraulich behandelt. Du kannst&nbsp;<a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct" style="color:#0662EE;font-weight:300">hier</a> mehr über den Ausschuss erfahren.
<br>
<a href="https://kubernetes.io/de/community/code-of-conduct/">
<br class="mobile"><br class="mobile">
<span class="fullbutton">
MEHR ERFAHREN
</span>
</a>
</div><a name="videos"></a>
</div>
</div>
<div class="videos">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<h1 style="margin-top:0px">Videos</h1>
<div style="margin-bottom:4%;font-weight:300;text-align:center;padding-left:10%;padding-right:10%">Wir sind auf YouTube, und zwar oft. Abonniere uns für eine Vielzahl von&nbsp;Themen.</div>
<div class="videocontainer">
<div class="video">
<iframe width="100%" height="250" src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg" title="Monatliche Bürozeiten" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg">
<div class="videocta">
Monatliche Bürozeiten ansehen&nbsp;&#9654;</div>
</a>
</div>
<div class="video">
<iframe width="100%" height="250" src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ" title="Wöchentliche Treffen der Gemeinschaft" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ">
<div class="videocta">
Wöchentliche Treffen der Gemeinschaft ansehen&nbsp;&#9654;
</div>
</a>
</div>
<div class="video">
<iframe width="100%" height="250" src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F" title="Vortrag eines Mitglieds der Gemeinschaft" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F">
<div class="videocta">
Vortrag eines Mitglieds der Gemeinschaft ansehen&nbsp;&#9654;
</div>
</a>
<a name="discuss"></a>
</div>
</div>
</div>
<div class="resources">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<h1 style="padding-top:1%">Diskussionen</h1>
<div style="font-weight:300;text-align:center">Wir reden gerne und viel. Triff uns auf einer dieser Plattformen und beteilige dich an den Diskussionen.</div>
<div class="resourcecontainer">
<div class="resourcebox">
<img src="/images/community/discuss.png" alt=Forum" style="width:80%;padding-bottom:2%">
<a href="https://discuss.kubernetes.io/" style="color:#0662EE;display:block;margin-top:1%">
forum&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
Themenbezogene technische Diskussionen, die eine Brücke zu Docs, StackOverflow und vielem mehr schlagen.
</div>
</div>
<div class="resourcebox">
<img src="/images/community/twitter.png" alt="Twitter" style="width:80%;padding-bottom:2%">
<a href="https://twitter.com/kubernetesio" style="color:#0662EE;display:block;margin-top:1%">
twitter&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">Echtzeit-Ankündigungen von Blogeinträgen, Veranstaltungen, Neuigkeiten und Ideen
</div>
</div>
<div class="resourcebox">
<img src="/images/community/github.png" alt="GitHub" style="width:80%;padding-bottom:2%">
<a href="https://github.com/kubernetes/kubernetes" style="color:#0662EE;display:block;margin-top:1%">
github&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
Die gesamte Projekt- und Problemverfolgung und natürlich der Code
</div>
</div>
<div class="resourcebox">
<img src="/images/community/stack.png" alt="Stack Overflow" style="width:80%;padding-bottom:2%">
<a href="https://stackoverflow.com/search?q=kubernetes" style="color:#0662EE;display:block;margin-top:1%">
stack overflow&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
Technische Problemlösung für jeden Anwendungsfall
<a name="events"></a>
</div>
</div>
<!--
<div class="resourcebox">
<img src="/images/community/slack.png" style="width:80%">
slack&nbsp;&#9654;
<div class="resourceboxtext" style="font-size:11px;text-transform:none !important;font-weight:200;line-height:1.4em;color:#333333;margin-top:4%">
With 170+ channels, you'll find one that fits your needs.
</div>
</div>-->
</div>
</div>
<div class="events">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<div class="eventcontainer">
<h1 style="color:white !important">Bevorstehende Veranstaltungen</h1>
{{< upcoming-events >}}
</div>
</div>
<div class="meetups">
<div class="meetupcol">
<div class="meetuptext">
<h1 style="text-align:left">Globale Gemeinschaft</h1>
Mit mehr als 150 Treffen auf der ganzen Welt, Tendenz steigend, solltest du deine lokalen Kube-Leute finden. Wenn keins in der Nähe ist, nimm die Sache in die Hand und gründe dein eigenes.
</div>
<a href="https://www.meetup.com/topics/kubernetes/">
<div class="button">
EIN MEETUP FINDEN
</div>
</a>
<a name="news"></a>
</div>
</div>
<!--
<div class="contributor">
<div class="contributortext">
<br>
<h1 style="text-align:left">
New Contributors Site
</h1>
Text about new contributors site.
<br><br>
<div class="button">
VISIT SITE
</div>
</div>
</div>
-->
<div class="news">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<h1 style="margin-bottom:2%">Aktuelle Neuigkeiten</h1>
<br>
<div class="twittercol1">
<a class="twitter-timeline" data-tweet-limit="1" href="https://twitter.com/kubernetesio?ref_src=twsrc%5Etfw">Tweets von kubernetesio</a> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
</div>
<br>
<br><br><br><br>
</div>
</div>
<section id="talkToUs">
<main>
<h3>Talk to Us!</h3>
<h4>Wir würden uns freuen, von Ihnen zu hören, wie Sie Kubernetes verwenden<br>und was wir tun können, um es besser zu machen.</h4>
<div id="bigSocial">
<div>
<a href="https://twitter.com/kubernetesio">@kubernetesio</a>
<p>Erhalten Sie die neuesten Nachrichten und Updates.</p>
</div>
<div>
<a href="https://github.com/kubernetes/kubernetes">Github Project</a>
<p>Informieren Sie sich über das Projekt und erwägen Sie, einen Beitrag zu leisten.</p>
</div>
<div>
<a href="http://slack.k8s.io/">#kubernetes-users</a>
<p>Unser Slack-Kanal ist der beste Weg, um unsere Ingenieure zu kontaktieren und Ihre Ideen mit ihnen zu teilen.</p>
</div>
<div>
<a href="http://stackoverflow.com/questions/tagged/kubernetes">Stack Overflow</a>
<p>Unser Benutzerforum ist ein großartiger Ort, um Community-Support zu erhalten.</p>
</div>
</div>
</main>
</section>
View File
@@ -26,7 +26,7 @@ Die Add-Ons in den einzelnen Kategorien sind alphabetisch sortiert - Die Reihenf
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) ermöglicht das nahtlose Verbinden von Kubernetes mit einer Reihe an CNI-Plugins wie z.B. Calico, Canal, Flannel, Romana, oder Weave.
* [Contiv](http://contiv.github.io) bietet konfigurierbares Networking (Native L3 auf BGP, Overlay mit vxlan, Klassisches L2, Cisco-SDN/ACI) für verschiedene Anwendungszwecke und auch umfangreiches Policy-Framework. Das Contiv-Projekt ist vollständig [Open Source](http://github.com/contiv). Der [installer](http://github.com/contiv/install) bietet sowohl kubeadm als auch nicht-kubeadm basierte Installationen.
* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), basierend auf [Tungsten Fabric](https://tungsten.io), ist eine Open Source, multi-Cloud Netzwerkvirtualisierungs- und Policy-Management Plattform. Contrail und Tungsten Fabric sind mit Orechstratoren wie z.B. Kubernetes, OpenShift, OpenStack und Mesos integriert und bieten Isolationsmodi für Virtuelle Maschinen, Container (bzw. Pods) und Bare Metal workloads.
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) ist ein Overlay-Network-Provider der mit Kubernetes genutzt werden kann.
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) ist ein Overlay-Network-Provider der mit Kubernetes genutzt werden kann.
* [Knitter](https://github.com/ZTE/Knitter/) ist eine Network-Lösung die Mehrfach-Network in Kubernetes ermöglicht.
* [Multus](https://github.com/Intel-Corp/multus-cni) ist ein Multi-Plugin für Mehrfachnetzwerk-Unterstützung um alle CNI-Plugins (z.B. Calico, Cilium, Contiv, Flannel), zusätzlich zu SRIOV-, DPDK-, OVS-DPDK- und VPP-Basierten Workloads in Kubernetes zu unterstützen.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) bietet eine Integration zwischen VMware NSX-T und einem Orchestator wie z.B. Kubernetes. Außerdem bietet es eine Integration zwischen NSX-T und Containerbasierten CaaS/PaaS-Plattformen wie z.B. Pivotal Container Service (PKS) und OpenShift.
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
View File
-2
View File
@@ -50,8 +50,6 @@ Bevor Sie die einzelnen Lernprogramme durchgehen, möchten Sie möglicherweise e
* [AppArmor](/docs/tutorials/clusters/apparmor/)
* [seccomp](/docs/tutorials/clusters/seccomp/)
## Services
* [Source IP verwenden](/docs/tutorials/services/source-ip/)
@@ -5,7 +5,7 @@ weight: 20
<!DOCTYPE html>
<html lang="de">
<html lang="en">
<body>
@@ -5,7 +5,7 @@ weight: 20
<!DOCTYPE html>
<html lang="de">
<html lang="en">
<body>
@@ -5,7 +5,7 @@ weight: 10
<!DOCTYPE html>
<html lang="de">
<html lang="en">
<body>
@@ -5,7 +5,7 @@ weight: 20
<!DOCTYPE html>
<html lang="de">
<html lang="en">
<body>
@@ -5,7 +5,7 @@ weight: 10
<!DOCTYPE html>
<html lang="de">
<html lang="en">
<body>
@@ -5,7 +5,7 @@ weight: 20
<!DOCTYPE html>
<html lang="de">
<html lang="en">
<body>
@@ -5,7 +5,7 @@ weight: 10
<!DOCTYPE html>
<html lang="de">
<html lang="en">
<body>
-201
View File
@@ -1,201 +0,0 @@
/* SECTIONS */
.section {
clear: both;
padding: 0px;
margin-bottom: 2em;
}
.kcsp_section {
clear: both;
padding: 0px;
margin-bottom: 2em;
}
/* COLUMN SETUP */
.col {
display: block;
float:left;
margin: 1% 0 1% 1.6%;
background-color: #f9f9f9;
}
.col:first-child { margin-left: 0; }
/* GROUPING */
.group:before,
.group:after {
content:"";
display:table;
}
.group:after {
clear:both;
}
.group {
zoom:1; /* For IE 6/7 */
}
/* GRID OF THREE */
.span_3_of_3 {
width: 35%;
background-color: #f9f9f9;
padding: 20px;
}
.span_2_of_3 {
width: 35%;
background-color: #f9f9f9;
padding: 20px;
}
.span_1_of_3 {
width: 35%;
background-color: #f9f9f9;
padding: 20px;
}
.col-container {
display: table; /* Make the container element behave like a table */
width: 100%; /* Set full-width to expand the whole page */
padding-bottom: 30px;
}
.col-nav {
display: table-cell; /* Make elements inside the container behave like table cells */
width: 18%;
background-color: #f9f9f9;
padding: 20px;
border: 5px solid white;
}
/* GO FULL WIDTH AT LESS THAN 480 PIXELS */
@media only screen and (max-width: 480px) {
.col { margin: 1% 0 1% 0%;}
.span_3_of_3, .span_2_of_3, .span_1_of_3 { width: 100%; }
}
@media only screen and (max-width: 650px) {
.col-nav {
display: block;
width: 100%;
}
}
.button{
max-width: 100%;
box-sizing: border-box;
margin: 0;
display: inline-block;
border-radius: 6px;
padding: 0 20px;
line-height: 40px;
color: #ffffff;
font-size: 16px;
background-color: #3371e3;
text-decoration: none;
}
h5 {
font-size: 16px;
line-height: 1.5em;
margin-bottom: 2em;
}
#usersGrid a {
display: inline-block;
background-color: #f9f9f9;
}
#ktpContainer, #distContainer, #kcspContainer, #isvContainer, #servContainer {
position: relative;
width: 100%;
display: flex;
justify-content: space-between;
flex-wrap: wrap;
}
#isvContainer {
margin-bottom: 80px;
}
#kcspContainer {
margin-bottom: 80px;
}
#distContainer {
margin-bottom: 80px;
}
#ktpContainer {
margin-bottom: 80px;
}
.partner-box {
position: relative;
width: 47%;
max-width: 48%;
min-width: 48%;
margin-bottom: 20px;
padding: 20px;
flex: 1;
display: flex;
justify-content: left;
align-items: flex-start;
}
.partner-box img {
background-color: #f9f9f9;
}
.partner-box > div {
margin-left: 30px;
}
.partner-box a {
color: #3576E3;
}
@media screen and (max-width: 1024px) {
.partner-box {
flex-direction: column;
justify-content: flex-start;
}
.partner-box > div {
margin: 20px 0 0;
}
}
@media screen and (max-width: 568px) {
#ktpContainer, #distContainter, #kcspContainer, #isvContainer, #servContainer {
justify-content: center;
}
.partner-box {
flex-direction: column;
justify-content: flex-start;
width: 100%;
max-width: 100%;
min-width: 100%;
}
.partner-box > div {
margin: 20px 0 0;
}
}
@media screen and (max-width: 568px) {
#ktpContainer, #distContainer, #kcspContainer, #isvContainer, #servContainer {
justify-content: center;
}
.partner-box {
flex-direction: column;
justify-content: flex-start;
width: 100%;
max-width: 100%;
min-width: 100%;
}
.partner-box > div {
margin: 20px 0 0;
}
}
+78 -40
View File
@@ -1,53 +1,91 @@
---
title: Partner
bigheader: Kubernetes Partner
abstract: Erweiterung des Kubernetes-Ökosystems.
abstract: Entwicklung des Kubernetes-Ökosystems.
class: gridPage
cid: partners
---
<section id="users">
<h5>Kubernetes arbeitet mit Partnern zusammen, um eine starke, lebendige Codebasis zu schaffen, die ein Spektrum von ergänzenden Plattformen unterstützt.</h5>
<div class="col-container">
<div class="col-nav">
<center>
<h5>
<b>Kubernetes-zertifizierte Service-Anbieter</b>
</h5>
<br>Geprüfte Dienstleister mit umfassender Erfahrung bei der erfolgreichen Einführung von Kubernetes in Unternehmen.
<br><br><br>
<button class="button landscape-trigger landscape-default" data-landscape-types="kubernetes-certified-service-provider" id="kcsp">KCSP Partner anzeigen</button>
<br><br>Interessiert daran, ein
<a href="https://www.cncf.io/certification/kcsp/">KCSP</a> zu werden?
</center>
</div>
<div class="col-nav">
<center>
<h5>
<b>Zertifizierte Kubernetes-Distributionen, gehostete Plattformen und Installationssysteme</b>
</h5>Die Softwarekonformität stellt sicher, dass die Kubernetes-Version eines jeden Anbieters die erforderlichen APIs unterstützt.
<br><br><br>
<button class="button landscape-trigger" data-landscape-types="certified-kubernetes-distribution,certified-kubernetes-hosted,certified-kubernetes-installer" id="conformance">Konforme Partner anzeigen</button>
<br><br>Interessiert daran,
<a href="https://www.cncf.io/certification/software-conformance/">Kubernetes Zertifiziert</a> zu werden?
</center>
</div>
<div class="col-nav">
<center>
<h5>
<b>Kubernetes Schulungspartner</b>
</h5>
<br>Geprüfte Schulungsanbieter mit umfassender Erfahrung in der Weiterbildung im Bereich Cloud Native Technology.
<br><br><br>
<button class="button landscape-trigger" data-landscape-types="kubernetes-training-partner" id="ktp">KTP Partner anzeigen</button>
<br><br>Interessiert daran, ein
<a href="https://www.cncf.io/certification/training/">KTP</a> zu werden?
</center>
</div>
<main>
<h5>Kubernetes arbeitet mit Partnern zusammen, um eine starke, dynamische Codebasis zu schaffen, die ein Spektrum von aufeinander abgestimmten Plattformen unterstützt.</h5>
<div class="col-container">
<div class="col-nav">
<center>
<h5>
<b>Kubernetes zertifizierte Service Provider</b>
</h5>
<br>Geprüfte Service Provider mit großer Erfahrung, die Unternehmen bei der erfolgreichen Einführung von Kubernetes unterstützen.
<br><br><br>
<button id="kcsp" class="button" onClick="updateSrc(this.id)">KCSP-Partner anzeigen</button>
<br><br>Interessiert daran, ein <a href="https://www.cncf.io/certification/kcsp/">KCSP</a> zu werden?
</center>
</div>
<div class="col-nav">
<center>
<h5>
<b>Kubernetes-Distributionen, gehostete Plattformen und zertifizierte Installateure</b>
</h5>Software-Konformität stellt sicher, dass die Kubernetes-Versionen aller Hersteller die erforderlichen APIs unterstützen.
<br><br><br>
<button id="conformance" class="button" onClick="updateSrc(this.id)">Zertifizierte Partner anzeigen</button>
<br><br>Interessiert daran, <a href="https://www.cncf.io/certification/software-conformance/">Kubernetes zertifiziert</a> zu werden?
</center>
</div>
<div class="col-nav">
<center>
<h5><b>Kubernetes Training Partner</b></h5>
<br>Geprüfte Schulungsanbieter, die über umfassende Erfahrung in Cloud Native Technologietrainings verfügen.
<br><br><br><br>
<button id="ktp" class="button" onClick="updateSrc(this.id)">KTP Partner anzeigen</button>
<br><br>Interessiert daran, ein <a href="https://www.cncf.io/certification/training/">KTP</a> zu werden?
</center>
</div>
</div>
<script src="https://code.jquery.com/jquery-3.3.1.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>
<script type="text/javascript">
var defaultLink = "https://landscape.cncf.io/category=kubernetes-certified-service-provider&format=card-mode&grouping=category&embed=yes";
var firstLink = "https://landscape.cncf.io/category=certified-kubernetes-distribution,certified-kubernetes-hosted,certified-kubernetes-installer&format=card-mode&grouping=category&embed=yes";
var secondLink = "https://landscape.cncf.io/category=kubernetes-training-partner&format=card-mode&grouping=category&embed=yes";
function updateSrc(buttonId) {
if (buttonId == "kcsp") {
$("#landscape").attr("src",defaultLink);
window.location.hash = "#kcsp";
}
if (buttonId == "conformance") {
$("#landscape").attr("src",firstLink);
window.location.hash = "#conformance";
}
if (buttonId == "ktp") {
$("#landscape").attr("src",secondLink);
window.location.hash = "#ktp";
}
}
// Automatically load the correct iframe based on the URL fragment
document.addEventListener('DOMContentLoaded', function() {
var showContent = "kcsp";
if (window.location.hash) {
console.log('hash is:', window.location.hash.substring(1));
showContent = window.location.hash.substring(1);
}
updateSrc(showContent);
});
</script>
<body>
<div id="frameHolder">
<iframe id="landscape" frameBorder="0" scrolling="no" style="width: 1px; min-width: 100%" src=""></iframe>
<script src="https://landscape.cncf.io/iframeResizer.js"></script>
</div>
{{< cncf-landscape helpers=true >}}
</body>
</main>
</section>
<style>
{{< include "partner-style.css" >}}
</style>
</style>
<script>
{{< include "partner-script.js" >}}
</script>
-137
View File
@@ -1,137 +0,0 @@
---
title: Schulungen
bigheader: Kubernetes Schulungen und Zertifizierungen
abstract: Schulungsprogramme, Zertifizierungen und Partner.
layout: basic
cid: training
class: training
---
<section class="call-to-action">
<div class="main-section">
<div class="call-to-action" id="cta-certification">
<div class="cta-text">
<h2>Gestalte deine Cloud Native Karriere</h2>
<p>Kubernetes ist das Herzstück der Cloud Native-Bewegung. Mit den Schulungen und Zertifizierungen der Linux Foundation und unserer Schulungspartner kannst Du in deine Karriere investieren, Kubernetes lernen und deine Cloud Native-Projekte zum Erfolg führen.</p>
</div>
<div class="logo-certification cta-image" id="logo-kcnf">
<img src="/images/training/kubernetes-kcnf-white.svg" />
</div>
<div class="logo-certification cta-image" id="logo-cka">
<img src="/images/training/kubernetes-cka-white.svg"/>
</div>
<div class="logo-certification cta-image" id="logo-ckad">
<img src="/images/training/kubernetes-ckad-white.svg"/>
</div>
<div class="logo-certification cta-image" id="logo-cks">
<img src="/images/training/kubernetes-cks-white.svg"/>
</div>
</div>
</div>
</section>
<section>
<div class="main-section padded">
<center>
<h2>Nimm an einen kostenlosen Kurs bei edX teil</h2>
</center>
<div class="col-container">
<div class="col-nav">
<center>
<h5>
<b>Einf&uuml;hrung in Kubernetes <br> &nbsp;</b>
</h5>
<p>M&ouml;chtest Du Kubernetes lernen? Erfahre alles über dieses leistungsstarke System zur Verwaltung von Containeranwendungen.</p>
<br>
<a href="https://www.edx.org/course/introduction-to-kubernetes" target="_blank" class="button">Zum Kurs</a>
</center>
</div>
<div class="col-nav">
<center>
<h5>
<b>Einführung in Cloud-Infrastruktur Technologien</b>
</h5>
<p>Lerne die Grundlagen für den Aufbau und die Verwaltung von Cloud-Technologien direkt von der Linux Foundation, dem Marktführer im Bereich Open Source.</p>
<br>
<a href="https://www.edx.org/course/introduction-to-cloud-infrastructure-technologies" target="_blank" class="button">Zum Kurs</a>
</center>
</div>
<div class="col-nav">
<center>
<h5>
<b>Einf&uuml;hrung in Linux</b>
</h5>
<p>Du hast nie Linux gelernt? Willst du eine Auffrischung? Erarbeite dir gute Linux-Kenntnisse über die grafische Oberfläche und die Kommandozeile der wichtigsten Linux-Distributionen.</p>
<br>
<a href="https://www.edx.org/course/introduction-to-linux" target="_blank" class="button">Zum Kurs</a>
</center>
</div>
</div>
</section>
<div class="padded lighter-gray-bg">
<div class="main-section two-thirds-centered">
<center>
<h2>Mit der Linux Foundation lernen</h2>
<p>Die Linux Foundation bietet Kurse für alle Aspekte der Entwicklung und des Betriebs von Kubernetes-Anwendungen an, die entweder von Lehrkräften geleitet werden oder zum Selbststudium geeignet sind.</p>
<br/><br/>
<a href="https://training.linuxfoundation.org/training/course-catalog/?_sft_technology=kubernetes" target="_blank" class="button">Kurse anzeigen</a>
</center>
</div>
</div>
<section id="get-certified">
<div class="main-section padded">
<h2>Werde Kubernetes zertifiziert</h2>
<div class="col-container">
<div class="col-nav">
<h5>
<b>Kubernetes and Cloud Native Associate (KCNA)</b>
</h5>
<p>Die Prüfung zum Kubernetes and Cloud Native Associate (KCNA) weist die grundlegenden Kenntnisse und Fähigkeiten eines Benutzers in Kubernetes und dem breiteren Cloud Native-Ökosystem nach.</p>
<p>Ein zertifizierter KCNA bestätigt konzeptionelles Wissen über das gesamte Cloud Native Ecosystem, mit besonderem Fokus auf Kubernetes.</p>
<br>
<a href="https://training.linuxfoundation.org/certification/kubernetes-cloud-native-associate/" target="_blank" class="button">Zur Zertifizierung</a>
</div>
<div class="col-nav">
<h5>
<b>Certified Kubernetes Application Developer (CKAD)</b>
</h5>
<p>Die Prüfung zum Certified Kubernetes Application Developer (Zertifizierter Kubernetes-Anwendungsentwickler) bescheinigt, dass Teilnehmer Cloud Native-Anwendungen für Kubernetes entwerfen, erstellen, konfigurieren und bereitstellen können.</p>
<p>Ein CKAD kann Anwendungsressourcen definieren und zentrale Elemente verwenden, um skalierbare Anwendungen und Tools in Kubernetes zu erstellen, zu überwachen und Fehler zu beheben.</p>
<br>
<a href="https://training.linuxfoundation.org/certification/certified-kubernetes-application-developer-ckad/" target="_blank" class="button">Zur Zertifizierung</a>
</div>
<div class="col-nav">
<h5>
<b>Certified Kubernetes Administrator (CKA)</b>
</h5>
<p>Das Certified Kubernetes Administrator (CKA)-Programm garantiert, dass CKAs die Fähigkeiten, das Wissen und die Kompetenz besitzen, um die Aufgaben eines Kubernetes-Administrators zu erfüllen.</p>
<p>Ein zertifizierter Kubernetes-Administrator hat nachgewiesen, dass er in der Lage ist, grundlegende Installationen durchzuführen sowie Kubernetes-Cluster in einer Produktionsumgebung zu konfigurieren und zu verwalten.</p>
<br>
<a href="https://training.linuxfoundation.org/certification/certified-kubernetes-administrator-cka/" target="_blank" class="button">Zur Zertifizierung</a>
</div>
<div class="col-nav">
<h5>
<b>Certified Kubernetes Security Specialist (CKS)</b>
</h5>
<p>Das Programm Certified Kubernetes Security Specialist (CKS) bietet die Gewissheit, dass der Zertifikatsinhaber mit einem breiten Spektrum an Best Practices vertraut ist und diese beherrscht. Die CKS-Zertifizierung umfasst Fähigkeiten zur Sicherung von Container-basierten Anwendungen und Kubernetes-Plattformen während der Erstellung, Bereitstellung und Laufzeit.</p>
<p><em>Kandidaten für den CKS müssen über eine aktuelle Zertifizierung als Certified Kubernetes Administrator (CKA) verfügen, um nachzuweisen, dass sie über ausreichende Kubernetes-Kenntnisse verfügen, bevor sie sich für den CKS anmelden.</em></p>
<br>
<a href="https://training.linuxfoundation.org/certification/certified-kubernetes-security-specialist/" target="_blank" class="button">Zur Zertifizierung</a>
</div>
</div>
</div>
</section>
<div class="padded lighter-gray-bg">
<div class="main-section two-thirds-centered">
<center>
<h2>Kubernetes Schulungspartner</h2>
<p>Unser Netzwerk von Kubernetes-Schulungspartnern bietet Schulungsangebote für Kubernetes- und Cloud Native-Projekte.</p>
</center>
</div>
<div class="main-section landscape-section">
{{< cncf-landscape helpers=false category="kubernetes-training-partner" >}}
</div>
</div>
+3 -3
View File
@@ -43,12 +43,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
<button id="desktopShowVideoButton" onclick="kub.showVideo()">Watch Video</button>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe-2022/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu22" button id="desktopKCButton">Attend KubeCon Europe on May 17-20, 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">Attend KubeCon NA virtually on November 17-20, 2020</a>
<br>
<br>
<br>
<br>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccncna21" button id="desktopKCButton">Attend KubeCon North America on October 24-28, 2022</a>
<a href="https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/?utm_source=kubernetes.io&utm_medium=nav&utm_campaign=kccnceu21" button id="desktopKCButton">Attend KubeCon EU virtually on May 4 7, 2021</a>
</div>
<div id="videoPlayer">
<iframe data-url="https://www.youtube.com/embed/H06qrNmGqyE?autoplay=1" frameborder="0" allowfullscreen></iframe>
@@ -58,4 +58,4 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise
{{< blocks/kubernetes-features >}}
{{< blocks/case-studies >}}
{{< blocks/case-studies >}}
@@ -125,7 +125,7 @@ You may wish to, but you cannot create a hierarchy of namespaces. Namespaces can
Namespaces are easy to create and use but its also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-).&nbsp;
Namespaces are easy to create and use but its also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/user-guide/kubectl/kubectl_config_set-context/).&nbsp;
@@ -5,11 +5,6 @@ slug: visualize-kubelet-performance-with-node-dashboard
url: /blog/2016/11/Visualize-Kubelet-Performance-With-Node-Dashboard
---
_Since this article was published, the Node Performance Dashboard was retired and is no longer available._
_This retirement happened in early 2019, as part of the_ `kubernetes/contrib`
_[repository deprecation](https://github.com/kubernetes-retired/contrib/issues/3007)_.
In Kubernetes 1.4, we introduced a new node performance analysis tool, called the _node performance dashboard_, to visualize and explore the behavior of the Kubelet in much richer details. This new feature will make it easy to understand and improve code performance for Kubelet developers, and lets cluster maintainer set configuration according to provided Service Level Objectives (SLOs).
**Background**
@@ -37,7 +37,7 @@ If you run your storage application on high-end hardware or extra-large instance
[ZooKeeper](https://zookeeper.apache.org/doc/current/) is an interesting use case for StatefulSet for two reasons. First, it demonstrates that StatefulSet can be used to run a distributed, strongly consistent storage application on Kubernetes. Second, it's a prerequisite for running workloads like [Apache Hadoop](http://hadoop.apache.org/) and [Apache Kakfa](https://kafka.apache.org/) on Kubernetes. An [in-depth tutorial](/docs/tutorials/stateful-application/zookeeper/) on deploying a ZooKeeper ensemble on Kubernetes is available in the Kubernetes documentation, and well outline a few of the key features below.
**Creating a ZooKeeper Ensemble**
Creating an ensemble is as simple as using [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create) to generate the objects stored in the manifest.
Creating an ensemble is as simple as using [kubectl create](/docs/user-guide/kubectl/kubectl_create/) to generate the objects stored in the manifest.
```
@@ -297,7 +297,7 @@ zk-0 0/1 Terminating 0 15m
You can use [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) to recreate the zk StatefulSet and redeploy the ensemble.
You can use [kubectl apply](/docs/user-guide/kubectl/kubectl_apply/) to recreate the zk StatefulSet and redeploy the ensemble.
@@ -95,7 +95,7 @@ The core workloads API surface is stable, but its still software, and softwar
--Kenneth Owens, Software Engineer, Google
- [Download](https://get.k8s.io/) Kubernetes
- [Download](http://get.k8s.io/) Kubernetes
- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
- Connect with the community on [Slack](http://slack.k8s.io/)
@@ -140,7 +140,7 @@ The local persistent volume beta feature is not complete by far. Some notable en
## Complementary features
[Pod priority and preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/) is another Kubernetes feature that is complementary to local persistent volumes. When your application uses local storage, it must be scheduled to the specific node where the local volume resides. You can give your local storage workload high priority so if that node ran out of room to run your workload, Kubernetes can preempt lower priority workloads to make room for it.
[Pod priority and preemption](/docs/concepts/configuration/pod-priority-preemption/) is another Kubernetes feature that is complementary to local persistent volumes. When your application uses local storage, it must be scheduled to the specific node where the local volume resides. You can give your local storage workload high priority so if that node ran out of room to run your workload, Kubernetes can preempt lower priority workloads to make room for it.
[Pod disruption budget](/docs/concepts/workloads/pods/disruptions/) is also very important for those workloads that must maintain quorum. Setting a disruption budget for your workload ensures that it does not drop below quorum due to voluntary disruption events, such as node drains during upgrade.
@@ -94,7 +94,7 @@ JOSH BERKUS: That goes into release notes. I mean, keep in mind that one of the
However, stuff happens, and we do occasionally have to do those. And so far, our main way to identify that to people actually is in the release notes. If you look at [the current release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md#no-really-you-must-do-this-before-you-upgrade), there are actually two things in there right now that are sort of breaking changes.
One of them is the bit with [priority and preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/) in that preemption being on by default now allows badly behaved users of the system to cause trouble in new ways. I'd actually have to look at the release notes to see what the second one was...
One of them is the bit with [priority and preemption](/docs/concepts/configuration/pod-priority-preemption/) in that preemption being on by default now allows badly behaved users of the system to cause trouble in new ways. I'd actually have to look at the release notes to see what the second one was...
TIM PEPPER: The [JSON capitalization case sensitivity](https://github.com/kubernetes/kubernetes/issues/64612).
@@ -104,7 +104,7 @@ Master and Worker nodes should be protected from overload and resource exhaustio
Resource consumption by the control plane will correlate with the number of pods and the pod churn rate. Very large and very small clusters will benefit from non-default [settings](/docs/reference/command-line-tools-reference/kube-apiserver/) of kube-apiserver request throttling and memory. Having these too high can lead to request limit exceeded and out of memory errors.
On worker nodes, [Node Allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/) should be configured based on a reasonable supportable workload density at each node. Namespaces can be created to subdivide the worker node cluster into multiple virtual clusters with resource CPU and memory [quotas](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/). Kubelet handling of [out of resource](/docs/concepts/scheduling-eviction/node-pressure-eviction/) conditions can be configured.
On worker nodes, [Node Allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/) should be configured based on a reasonable supportable workload density at each node. Namespaces can be created to subdivide the worker node cluster into multiple virtual clusters with resource CPU and memory [quotas](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/). Kubelet handling of [out of resource](/docs/tasks/administer-cluster/out-of-resource/) conditions can be configured.
## Security
@@ -166,7 +166,7 @@ Some critical state is held outside etcd. Certificates, container images, and ot
* Cloud provider specific account and configuration data
## Considerations for your production workloads
Anti-affinity specifications can be used to split clustered services across backing hosts, but at this time the settings are used only when the pod is scheduled. This means that Kubernetes can restart a failed node of your clustered application, but does not have a native mechanism to rebalance after a fail back. This is a topic worthy of a separate blog, but supplemental logic might be useful to achieve optimal workload placements after host or worker node recoveries or expansions. The [Pod Priority and Preemption feature](/docs/concepts/scheduling-eviction/pod-priority-preemption/) can be used to specify a preferred triage in the event of resource shortages caused by failures or bursting workloads.
Anti-affinity specifications can be used to split clustered services across backing hosts, but at this time the settings are used only when the pod is scheduled. This means that Kubernetes can restart a failed node of your clustered application, but does not have a native mechanism to rebalance after a fail back. This is a topic worthy of a separate blog, but supplemental logic might be useful to achieve optimal workload placements after host or worker node recoveries or expansions. The [Pod Priority and Preemption feature](/docs/concepts/configuration/pod-priority-preemption/) can be used to specify a preferred triage in the event of resource shortages caused by failures or bursting workloads.
For stateful services, external attached volume mounts are the standard Kubernetes recommendation for a non-clustered service (e.g., a typical SQL database). At this time Kubernetes managed snapshots of these external volumes is in the category of a [roadmap feature request](https://docs.google.com/presentation/d/1dgxfnroRAu0aF67s-_bmeWpkM1h2LCxe6lB1l1oS0EQ/edit#slide=id.g3ca07c98c2_0_47), likely to align with the Container Storage Interface (CSI) integration. Thus performing backups of such a service would involve application specific, in-pod activity that is beyond the scope of this document. While awaiting better Kubernetes support for a snapshot and backup workflow, running your database service in a VM rather than a container, and exposing it to your Kubernetes workload may be worth considering.
@@ -4,8 +4,6 @@ title: 'Health checking gRPC servers on Kubernetes'
date: 2018-10-01
---
_Built-in gRPC probes were introduced in Kubernetes 1.23. To learn more, see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)._
**Author**: [Ahmet Alp Balkan](https://twitter.com/ahmetb) (Google)
[gRPC](https://grpc.io) is on its way to becoming the lingua franca for
@@ -144,9 +144,10 @@ ways to address it.
- Specifically add an iptables rule to drop the packets that are marked as
*INVALID*, so it wont reach to client pod and cause harm.
The [fix](https://github.com/kubernetes/kubernetes/pull/74840) is available in v1.15+.
However, for the users that are affected by this bug, there is a way to mitigate the
problem by applying the following rule in your cluster.
The fix is drafted (https://github.com/kubernetes/kubernetes/pull/74840), but
unfortunately it didnt catch the v1.14 release window. However, for the users
that are affected by this bug, there is a way to mitigate the problem by applying
the following rule in your cluster.
```yaml
apiVersion: extensions/v1beta1
@@ -8,7 +8,7 @@ date: 2019-04-16
Kubernetes is well-known for running scalable workloads. It scales your workloads based on their resource usage. When a workload is scaled up, more instances of the application get created. When the application is critical for your product, you want to make sure that these new instances are scheduled even when your cluster is under resource pressure. One obvious solution to this problem is to over-provision your cluster resources to have some amount of slack resources available for scale-up situations. This approach often works, but costs more as you would have to pay for the resources that are idle most of the time.
[Pod priority and preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/) is a scheduler feature made generally available in Kubernetes 1.14 that allows you to achieve high levels of scheduling confidence for your critical workloads without overprovisioning your clusters. It also provides a way to improve resource utilization in your clusters without sacrificing the reliability of your essential workloads.
[Pod priority and preemption](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/) is a scheduler feature made generally available in Kubernetes 1.14 that allows you to achieve high levels of scheduling confidence for your critical workloads without overprovisioning your clusters. It also provides a way to improve resource utilization in your clusters without sacrificing the reliability of your essential workloads.
## Guaranteed scheduling with controlled cost
@@ -120,7 +120,7 @@ Run the following command to have Docker run the application in a container and
```
docker run -p 5001:5000 hello-python
```
Now navigate to http://localhost:5001, and you should see the “Hello from Python!” message.
Now navigate to http://localhost:5001, and you should see the “Hello form Python!” message.
### More info
* [Get started with Docker](https://docs.docker.com/get-started/)
@@ -201,7 +201,7 @@ kubectl get pods
```
<img src="/images/blog/get-started-with-kubernetes-using-python/kubectl-get-pods.png" alt="Pod listing" />
Now navigate to http://localhost:6000, and you should see the “Hello from Python!” message.
Now navigate to http://localhost:6000, and you should see the “Hello form Python!” message.
Thats it! The application is now running in Kubernetes!
@@ -55,7 +55,7 @@ The team has made progress in the last few months that is well worth celebrating
- The K8s-Infrastructure Working Group released an automated billing report that they start every meeting off by reviewing as a group.
- DNS for k8s.io and kubernetes.io are also fully [community-owned](https://groups.google.com/g/kubernetes-dev/c/LZTYJorGh7c/m/u-ydk-yNEgAJ), with community members able to [file issues](https://github.com/kubernetes/k8s.io/issues/new?assignees=&labels=wg%2Fk8s-infra&template=dns-request.md&title=DNS+REQUEST%3A+%3Cyour-dns-record%3E) to manage records.
- The container registry [k8s.gcr.io](https://github.com/kubernetes/k8s.io/tree/main/k8s.gcr.io) is also fully community-owned and available for all Kubernetes subprojects to use.
- The container registry [k8s.gcr.io](https://github.com/kubernetes/k8s.io/tree/master/k8s.gcr.io) is also fully community-owned and available for all Kubernetes subprojects to use.
- The Kubernetes [publishing-bot](https://github.com/kubernetes/publishing-bot) responsible for keeping k8s.io/kubernetes/staging repositories published to their own top-level repos (For example: [kubernetes/api](https://github.com/kubernetes/api)) runs on a community-owned cluster.
- The gcsweb.k8s.io service used to provide anonymous access to GCS buckets for kubernetes artifacts runs on a community-owned cluster.
- There is also an automated process of promoting all our container images. This includes a fully documented infrastructure, managed by the Kubernetes community, with automated processes for provisioning permissions.
@@ -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?
@@ -186,7 +186,7 @@ metadata:
### Role Oriented Design
When you put it all together, you have a single load balancing infrastructure that can be safely shared by multiple teams. The Gateway API is not only a more expressive API for advanced routing, but is also a role-oriented API, designed for multi-tenant infrastructure. Its extensibility ensures that it will evolve for future use-cases while preserving portability. Ultimately these characteristics will allow the Gateway API to adapt to different organizational models and implementations well into the future.
When you put it all together, you have a single load balancing infrastructure that can be safely shared by multiple teams. The Gateway API not only a more expressive API for advanced routing, but is also a role-oriented API, designed for multi-tenant infrastructure. Its extensibility ensures that it will evolve for future use-cases while preserving portability. Ultimately these characteristics will allow Gateway API to adapt to different organizational models and implementations well into the future.
### Try it out and get involved
@@ -194,4 +194,4 @@ There are many resources to check out to learn more.
* Check out the [user guides](https://gateway-api.sigs.k8s.io/guides/getting-started/) to see what use-cases can be addressed.
* Try out one of the [existing Gateway controllers ](https://gateway-api.sigs.k8s.io/references/implementations/)
* Or [get involved](https://gateway-api.sigs.k8s.io/contributing/community/) and help design and influence the future of Kubernetes service networking!
* Or [get involved](https://gateway-api.sigs.k8s.io/contributing/community/) and help design and influence the future of Kubernetes service networking!
@@ -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
@@ -1,467 +0,0 @@
---
layout: blog
title: "Writing a Controller for Pod Labels"
date: 2021-06-21
slug: writing-a-controller-for-pod-labels
---
**Authors**: Arthur Busser (Padok)
[Operators][what-is-an-operator] are proving to be an excellent solution to
running stateful distributed applications in Kubernetes. Open source tools like
the [Operator SDK][operator-sdk] provide ways to build reliable and maintainable
operators, making it easier to extend Kubernetes and implement custom
scheduling.
Kubernetes operators run complex software inside your cluster. The open source
community has already built [many operators][operatorhub] for distributed
applications like Prometheus, Elasticsearch, or Argo CD. Even outside of
open source, operators can help to bring new functionality to your Kubernetes
cluster.
An operator is a set of [custom resources][custom-resource-definitions] and a
set of [controllers][controllers]. A controller watches for changes to specific
resources in the Kubernetes API and reacts by creating, updating, or deleting
resources.
The Operator SDK is best suited for building fully-featured operators.
Nonetheless, you can use it to write a single controller. This post will walk
you through writing a Kubernetes controller in Go that will add a `pod-name`
label to pods that have a specific annotation.
## Why do we need a controller for this?
I recently worked on a project where we needed to create a Service that routed
traffic to a specific Pod in a ReplicaSet. The problem is that a Service can
only select pods by label, and all pods in a ReplicaSet have the same labels.
There are two ways to solve this problem:
1. Create a Service without a selector and manage the Endpoints or
EndpointSlices for that Service directly. We would need to write a custom
controller to insert our Pod's IP address into those resources.
2. Add a label to the Pod with a unique value. We could then use this label in
our Service's selector. Again, we would need to write a custom controller to
add this label.
A controller is a control loop that tracks one or more Kubernetes resource
types. The controller from option n°2 above only needs to track pods, which
makes it simpler to implement. This is the option we are going to walk through
by writing a Kubernetes controller that adds a `pod-name` label to our pods.
StatefulSets [do this natively][statefulset-pod-name-label] by adding a
`pod-name` label to each Pod in the set. But what if we don't want to or can't
use StatefulSets?
We rarely create pods directly; most often, we use a Deployment, ReplicaSet, or
another high-level resource. We can specify labels to add to each Pod in the
PodSpec, but not with dynamic values, so no way to replicate a StatefulSet's
`pod-name` label.
We tried using a [mutating admission webhook][mutating-admission-webhook]. When
anyone creates a Pod, the webhook patches the Pod with a label containing the
Pod's name. Disappointingly, this does not work: not all pods have a name before
being created. For instance, when the ReplicaSet controller creates a Pod, it
sends a `namePrefix` to the Kubernetes API server and not a `name`. The API
server generates a unique name before persisting the new Pod to etcd, but only
after calling our admission webhook. So in most cases, we can't know a Pod's
name with a mutating webhook.
Once a Pod exists in the Kubernetes API, it is mostly immutable, but we can
still add a label. We can even do so from the command line:
```bash
kubectl label my-pod my-label-key=my-label-value
```
We need to watch for changes to any pods in the Kubernetes API and add the label
we want. Rather than do this manually, we are going to write a controller that
does it for us.
## Bootstrapping a controller with the Operator SDK
A controller is a reconciliation loop that reads the desired state of a resource
from the Kubernetes API and takes action to bring the cluster's actual state
closer to the desired state.
In order to write this controller as quickly as possible, we are going to use
the Operator SDK. If you don't have it installed, follow the
[official documentation][operator-sdk-installation].
```terminal
$ operator-sdk version
operator-sdk version: "v1.4.2", commit: "4b083393be65589358b3e0416573df04f4ae8d9b", kubernetes version: "v1.19.4", go version: "go1.15.8", GOOS: "darwin", GOARCH: "amd64"
```
Let's create a new directory to write our controller in:
```bash
mkdir label-operator && cd label-operator
```
Next, let's initialize a new operator, to which we will add a single controller.
To do this, you will need to specify a domain and a repository. The domain
serves as a prefix for the group your custom Kubernetes resources will belong
to. Because we are not going to be defining custom resources, the domain does
not matter. The repository is going to be the name of the Go module we are going
to write. By convention, this is the repository where you will be storing your
code.
As an example, here is the command I ran:
```bash
# Feel free to change the domain and repo values.
operator-sdk init --domain=padok.fr --repo=github.com/busser/label-operator
```
Next, we need a create a new controller. This controller will handle pods and
not a custom resource, so no need to generate the resource code. Let's run this
command to scaffold the code we need:
```bash
operator-sdk create api --group=core --version=v1 --kind=Pod --controller=true --resource=false
```
We now have a new file: `controllers/pod_controller.go`. This file contains a
`PodReconciler` type with two methods that we need to implement. The first is
`Reconcile`, and it looks like this for now:
```go
func (r *PodReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
_ = r.Log.WithValues("pod", req.NamespacedName)
// your logic here
return ctrl.Result{}, nil
}
```
The `Reconcile` method is called whenever a Pod is created, updated, or deleted.
The name and namespace of the Pod are in the `ctrl.Request` the method receives
as a parameter.
The second method is `SetupWithManager` and for now it looks like this:
```go
func (r *PodReconciler) SetupWithManager(mgr ctrl.Manager) error {
return ctrl.NewControllerManagedBy(mgr).
// Uncomment the following line adding a pointer to an instance of the controlled resource as an argument
// For().
Complete(r)
}
```
The `SetupWithManager` method is called when the operator starts. It serves to
tell the operator framework what types our `PodReconciler` needs to watch. To
use the same `Pod` type used by Kubernetes internally, we need to import some of
its code. All of the Kubernetes source code is open source, so you can import
any part you like in your own Go code. You can find a complete list of available
packages in the Kubernetes source code or [here on pkg.go.dev][pkg-go-dev]. To
use pods, we need the `k8s.io/api/core/v1` package.
```go
package controllers
import (
// other imports...
corev1 "k8s.io/api/core/v1"
// other imports...
)
```
Lets use the `Pod` type in `SetupWithManager` to tell the operator framework we
want to watch pods:
```go
func (r *PodReconciler) SetupWithManager(mgr ctrl.Manager) error {
return ctrl.NewControllerManagedBy(mgr).
For(&corev1.Pod{}).
Complete(r)
}
```
Before moving on, we should set the RBAC permissions our controller needs. Above
the `Reconcile` method, we have some default permissions:
```go
// +kubebuilder:rbac:groups=core,resources=pods,verbs=get;list;watch;create;update;patch;delete
// +kubebuilder:rbac:groups=core,resources=pods/status,verbs=get;update;patch
// +kubebuilder:rbac:groups=core,resources=pods/finalizers,verbs=update
```
We don't need all of those. Our controller will never interact with a Pod's
status or its finalizers. It only needs to read and update pods. Lets remove the
unnecessary permissions and keep only what we need:
```go
// +kubebuilder:rbac:groups=core,resources=pods,verbs=get;list;watch;update;patch
```
We are now ready to write our controller's reconciliation logic.
## Implementing reconciliation
Here is what we want our `Reconcile` method to do:
1. Use the Pod's name and namespace from the `ctrl.Request` to fetch the Pod
from the Kubernetes API.
2. If the Pod has an `add-pod-name-label` annotation, add a `pod-name` label to
the Pod; if the annotation is missing, don't add the label.
3. Update the Pod in the Kubernetes API to persist the changes made.
Lets define some constants for the annotation and label:
```go
const (
addPodNameLabelAnnotation = "padok.fr/add-pod-name-label"
podNameLabel = "padok.fr/pod-name"
)
```
The first step in our reconciliation function is to fetch the Pod we are working
on from the Kubernetes API:
```go
// Reconcile handles a reconciliation request for a Pod.
// If the Pod has the addPodNameLabelAnnotation annotation, then Reconcile
// will make sure the podNameLabel label is present with the correct value.
// If the annotation is absent, then Reconcile will make sure the label is too.
func (r *PodReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
log := r.Log.WithValues("pod", req.NamespacedName)
/*
Step 0: Fetch the Pod from the Kubernetes API.
*/
var pod corev1.Pod
if err := r.Get(ctx, req.NamespacedName, &pod); err != nil {
log.Error(err, "unable to fetch Pod")
return ctrl.Result{}, err
}
return ctrl.Result{}, nil
}
```
Our `Reconcile` method will be called when a Pod is created, updated, or
deleted. In the deletion case, our call to `r.Get` will return a specific error.
Let's import the package that defines this error:
```go
package controllers
import (
// other imports...
apierrors "k8s.io/apimachinery/pkg/api/errors"
// other imports...
)
```
We can now handle this specific error and — since our controller does not care
about deleted pods — explicitly ignore it:
```go
/*
Step 0: Fetch the Pod from the Kubernetes API.
*/
var pod corev1.Pod
if err := r.Get(ctx, req.NamespacedName, &pod); err != nil {
if apierrors.IsNotFound(err) {
// we'll ignore not-found errors, since we can get them on deleted requests.
return ctrl.Result{}, nil
}
log.Error(err, "unable to fetch Pod")
return ctrl.Result{}, err
}
```
Next, lets edit our Pod so that our dynamic label is present if and only if our
annotation is present:
```go
/*
Step 1: Add or remove the label.
*/
labelShouldBePresent := pod.Annotations[addPodNameLabelAnnotation] == "true"
labelIsPresent := pod.Labels[podNameLabel] == pod.Name
if labelShouldBePresent == labelIsPresent {
// The desired state and actual state of the Pod are the same.
// No further action is required by the operator at this moment.
log.Info("no update required")
return ctrl.Result{}, nil
}
if labelShouldBePresent {
// If the label should be set but is not, set it.
if pod.Labels == nil {
pod.Labels = make(map[string]string)
}
pod.Labels[podNameLabel] = pod.Name
log.Info("adding label")
} else {
// If the label should not be set but is, remove it.
delete(pod.Labels, podNameLabel)
log.Info("removing label")
}
```
Finally, let's push our updated Pod to the Kubernetes API:
```go
/*
Step 2: Update the Pod in the Kubernetes API.
*/
if err := r.Update(ctx, &pod); err != nil {
log.Error(err, "unable to update Pod")
return ctrl.Result{}, err
}
```
When writing our updated Pod to the Kubernetes API, there is a risk that the Pod
has been updated or deleted since we first read it. When writing a Kubernetes
controller, we should keep in mind that we are not the only actors in the
cluster. When this happens, the best thing to do is start the reconciliation
from scratch, by requeuing the event. Lets do exactly that:
```go
/*
Step 2: Update the Pod in the Kubernetes API.
*/
if err := r.Update(ctx, &pod); err != nil {
if apierrors.IsConflict(err) {
// The Pod has been updated since we read it.
// Requeue the Pod to try to reconciliate again.
return ctrl.Result{Requeue: true}, nil
}
if apierrors.IsNotFound(err) {
// The Pod has been deleted since we read it.
// Requeue the Pod to try to reconciliate again.
return ctrl.Result{Requeue: true}, nil
}
log.Error(err, "unable to update Pod")
return ctrl.Result{}, err
}
```
Let's remember to return successfully at the end of the method:
```go
return ctrl.Result{}, nil
}
```
And that's it! We are now ready to run the controller on our cluster.
## Run the controller on your cluster
To run our controller on your cluster, we need to run the operator. For that,
all you will need is `kubectl`. If you don't have a Kubernetes cluster at hand,
I recommend you start one locally with [KinD (Kubernetes in Docker)][kind].
All it takes to run the operator from your machine is this command:
```bash
make run
```
After a few seconds, you should see the operator's logs. Notice that our
controller's `Reconcile` method was called for all pods already running in the
cluster.
Let's keep the operator running and, in another terminal, create a new Pod:
```bash
kubectl run --image=nginx my-nginx
```
The operator should quickly print some logs, indicating that it reacted to the
Pod's creation and subsequent changes in status:
```text
INFO controllers.Pod no update required {"pod": "default/my-nginx"}
INFO controllers.Pod no update required {"pod": "default/my-nginx"}
INFO controllers.Pod no update required {"pod": "default/my-nginx"}
INFO controllers.Pod no update required {"pod": "default/my-nginx"}
```
Lets check the Pod's labels:
```terminal
$ kubectl get pod my-nginx --show-labels
NAME READY STATUS RESTARTS AGE LABELS
my-nginx 1/1 Running 0 11m run=my-nginx
```
Let's add an annotation to the Pod so that our controller knows to add our
dynamic label to it:
```bash
kubectl annotate pod my-nginx padok.fr/add-pod-name-label=true
```
Notice that the controller immediately reacted and produced a new line in its
logs:
```text
INFO controllers.Pod adding label {"pod": "default/my-nginx"}
```
```terminal
$ kubectl get pod my-nginx --show-labels
NAME READY STATUS RESTARTS AGE LABELS
my-nginx 1/1 Running 0 13m padok.fr/pod-name=my-nginx,run=my-nginx
```
Bravo! You just successfully wrote a Kubernetes controller capable of adding
labels with dynamic values to resources in your cluster.
Controllers and operators, both big and small, can be an important part of your
Kubernetes journey. Writing operators is easier now than it has ever been. The
possibilities are endless.
## What next?
If you want to go further, I recommend starting by deploying your controller or
operator inside a cluster. The `Makefile` generated by the Operator SDK will do
most of the work.
When deploying an operator to production, it is always a good idea to implement
robust testing. The first step in that direction is to write unit tests.
[This documentation][operator-sdk-testing] will guide you in writing tests for
your operator. I wrote tests for the operator we just wrote; you can find all of
my code in [this GitHub repository][github-repo].
## How to learn more?
The [Operator SDK documentation][operator-sdk-docs] goes into detail on how you
can go further and implement more complex operators.
When modeling a more complex use-case, a single controller acting on built-in
Kubernetes types may not be enough. You may need to build a more complex
operator with [Custom Resource Definitions (CRDs)][custom-resource-definitions]
and multiple controllers. The Operator SDK is a great tool to help you do this.
If you want to discuss building an operator, join the [#kubernetes-operator][slack-channel]
channel in the [Kubernetes Slack workspace][slack-workspace]!
<!-- Links -->
[controllers]: https://kubernetes.io/docs/concepts/architecture/controller/
[custom-resource-definitions]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
[kind]: https://kind.sigs.k8s.io/docs/user/quick-start/#installation
[github-repo]: https://github.com/busser/label-operator
[mutating-admission-webhook]: https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook
[operator-sdk]: https://sdk.operatorframework.io/
[operator-sdk-docs]: https://sdk.operatorframework.io/docs/
[operator-sdk-installation]: https://sdk.operatorframework.io/docs/installation/
[operator-sdk-testing]: https://sdk.operatorframework.io/docs/building-operators/golang/testing/
[operatorhub]: https://operatorhub.io/
[pkg-go-dev]: https://pkg.go.dev/k8s.io/api
[slack-channel]: https://kubernetes.slack.com/messages/kubernetes-operators
[slack-workspace]: https://slack.k8s.io/
[statefulset-pod-name-label]: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#pod-name-label
[what-is-an-operator]: https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
@@ -1,49 +0,0 @@
---
layout: blog
title: "Announcing Kubernetes Community Group Annual Reports"
description: >
Introducing brand new Kubernetes Community Group Annual Reports for
Special Interest Groups and Working Groups.
date: 2021-06-28T10:00:00-08:00
slug: Announcing-Kubernetes-Community-Group-Annual-Reports
---
**Authors:** Divya Mohan
{{< figure src="k8s_annual_report_2020.svg" alt="Community annual report 2020" link="https://www.cncf.io/reports/kubernetes-community-annual-report-2020/" >}}
Given the growth and scale of the Kubernetes project, the existing reporting mechanisms were proving to be inadequate and challenging.
Kubernetes is a large open source project. With over 100000 commits just to the main k/kubernetes repository, hundreds of other code
repositories in the project, and thousands of contributors, there's a lot going on. In fact, there are 37 contributor groups at the time of
writing. We also value all forms of contribution and not just code changes.
With that context in mind, the challenge of reporting on all this activity was a call to action for exploring better options. Therefore
inspired by the Apache Software Foundations [open guide to PMC Reporting](https://www.apache.org/foundation/board/reporting) and the
[CNCF project Annual Reporting](https://www.cncf.io/cncf-annual-report-2020/), the Kubernetes project is proud to announce the
**Kubernetes Community Group Annual Reports for Special Interest Groups (SIGs) and Working Groups (WGs)**. In its flagship edition,
the [2020 Summary report](https://www.cncf.io/reports/kubernetes-community-annual-report-2020/) focuses on bettering the
Kubernetes ecosystem by assessing and promoting the healthiness of the groups within the upstream community.
Previously, the mechanisms for the Kubernetes project overall to report on groups and their activities were
[devstats](https://k8s.devstats.cncf.io/), GitHub data, issues, to measure the healthiness of a given UG/WG/SIG/Committee. As a
project spanning several diverse communities, it was essential to have something that captured the human side of things. With 50,000+
contributors, its easy to assume that the project has enough help and this report surfaces more information than /help-wanted and
/good-first-issue for end users. This is how we sustain the project. Paraphrasing one of the Steering Committee members,
[Paris Pittman](https://github.com/parispittman), “There was a requirement for tighter feedback loops - ones that involved more than just
GitHub data and issues. Given that Kubernetes, as a project, has grown in scale and number of contributors over the years, we have
outgrown the existing reporting mechanisms."
The existing communication channels between the Steering committee members and the folks leading the groups and committees were also required
to be made as open and as bi-directional as possible. Towards achieving this very purpose, every group and committee has been assigned a
liaison from among the steering committee members for kick off, help, or guidance needed throughout the process. According to
[Davanum Srinivas a.k.a. dims](https://github.com/dims), “... That was one of the main motivations behind this report. People (leading the
groups/committees) know that they can reach out to us and theres a vehicle for them to reach out to us… This is our way of setting up a
two-way feedback for them." The progress on these action items would be updated and tracked on the monthly Steering Committee meetings
ensuring that this is not a one-off activity. Quoting [Nikhita Raghunath](https://github.com/nikhita), one of the Steering Committee members,
“... Once we have a base, the liaisons will work with these groups to ensure that the problems are resolved. When we have a report next year,
well have a look at the progress made and how we could still do better. But the idea is definitely to not stop at the report.”
With this report, we hope to empower our end user communities with information that they can use to identify ways in which they can support
the project as well as a sneak peek into the roadmap for upcoming features. As a community, we thrive on feedback and would love to hear your
views about the report. You can get in touch with the [Steering Committee](https://github.com/kubernetes/steering#contact) via
[Slack](https://kubernetes.slack.com/messages/steering-committee) or via the [mailing list](steering@kubernetes.io).
File diff suppressed because one or more lines are too long

Before

Width:  |  Height:  |  Size: 1.2 MiB

@@ -1,276 +0,0 @@
---
layout: blog
title: "Kubernetes API and Feature Removals In 1.22: Heres What You Need To Know"
date: 2021-07-14
slug: upcoming-changes-in-kubernetes-1-22
---
**Authors**: Krishna Kilari (Amazon Web Services), Tim Bannister (The Scale Factory)
As the Kubernetes API evolves, APIs are periodically reorganized or upgraded.
When APIs evolve, the old APIs they replace are deprecated, and eventually removed.
See [Kubernetes API removals](#kubernetes-api-removals) to read more about Kubernetes'
policy on removing APIs.
We want to make sure you're aware of some upcoming removals. These are
beta APIs that you can use in current, supported Kubernetes versions,
and they are already deprecated. The reason for all of these removals
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.
## API removals for Kubernetes v1.22 {#api-changes}
The **v1.22** release will stop serving the API versions we've listed immediately below.
These are all beta APIs that were previously deprecated in favor of newer and more stable
API versions.
<!-- sorted by API group -->
* Beta versions of the `ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration` API (the **admissionregistration.k8s.io/v1beta1** API versions)
* The beta `CustomResourceDefinition` API (**apiextensions.k8s.io/v1beta1**)
* The beta `APIService` API (**apiregistration.k8s.io/v1beta1**)
* The beta `TokenReview` API (**authentication.k8s.io/v1beta1**)
* Beta API versions of `SubjectAccessReview`, `LocalSubjectAccessReview`, `SelfSubjectAccessReview` (API versions from **authorization.k8s.io/v1beta1**)
* The beta `CertificateSigningRequest` API (**certificates.k8s.io/v1beta1**)
* The beta `Lease` API (**coordination.k8s.io/v1beta1**)
* All beta `Ingress` APIs (the **extensions/v1beta1** and **networking.k8s.io/v1beta1** API versions)
The Kubernetes documentation covers these
[API removals for v1.22](/docs/reference/using-api/deprecation-guide/#v1-22) and explains
how each of those APIs change between beta and stable.
## What to do
We're going to run through each of the resources that are affected by these removals
and explain the steps you'll need to take.
`Ingress`
: Migrate to use the **networking.k8s.io/v1**
[Ingress](/docs/reference/kubernetes-api/service-resources/ingress-v1/) API,
[available since v1.19](/blog/2020/08/26/kubernetes-release-1.19-accentuate-the-paw-sitive/#ingress-graduates-to-general-availability).
The related API [IngressClass](/docs/reference/kubernetes-api/service-resources/ingress-class-v1/)
is designed to complement the [Ingress](/docs/concepts/services-networking/ingress/)
concept, allowing you to configure multiple kinds of Ingress within one cluster.
If you're currently using the deprecated
[`kubernetes.io/ingress.class`](https://kubernetes.io/docs/reference/labels-annotations-taints/#kubernetes-io-ingress-class-deprecated)
annotation, plan to switch to using the `.spec.ingressClassName` field instead.
On any cluster running Kubernetes v1.19 or later, you can use the v1 API to
retrieve or update existing Ingress objects, even if they were created using an
older API version.
When you convert an Ingress to the v1 API, you should review each rule in that Ingress.
Older Ingresses use the legacy `ImplementationSpecific` path type. Instead of `ImplementationSpecific`, switch [path matching](/docs/concepts/services-networking/ingress/#path-types) to either `Prefix` or `Exact`. One of the benefits of moving to these alternative path types is that it becomes easier to migrate between different Ingress classes.
**ⓘ** As well as upgrading _your_ own use of the Ingress API as a client, make sure that
every ingress controller that you use is compatible with the v1 Ingress API.
Read [Ingress Prerequisites](/docs/concepts/services-networking/ingress/#prerequisites)
for more context about Ingress and ingress controllers.
`ValidatingWebhookConfiguration` and `MutatingWebhookConfiguration`
: Migrate to use the **admissionregistration.k8s.io/v1** API versions of
[ValidatingWebhookConfiguration](/docs/reference/kubernetes-api/extend-resources/validating-webhook-configuration-v1/)
and [MutatingWebhookConfiguration](/docs/reference/kubernetes-api/extend-resources/mutating-webhook-configuration-v1/),
available since v1.16.
You can use the v1 API to retrieve or update existing objects, even if they were created using an older API version.
`CustomResourceDefinition`
: Migrate to use the [CustomResourceDefinition](/docs/reference/kubernetes-api/extend-resources/custom-resource-definition-v1/)
**apiextensions.k8s.io/v1** API, available since v1.16.
You can use the v1 API to retrieve or update existing objects, even if they were created
using an older API version. If you defined any custom resources in your cluster, those
are still served after you upgrade.
If you're using external CustomResourceDefinitions, you can use
[`kubectl convert`](#kubectl-convert) to translate existing manifests to use the newer API.
Because there are some functional differences between beta and stable CustomResourceDefinitions,
our advice is to test out each one to make sure it works how you expect after the upgrade.
`APIService`
: Migrate to use the **apiregistration.k8s.io/v1** [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/)
API, available since v1.10.
You can use the v1 API to retrieve or update existing objects, even if they were created using an older API version.
If you already have API aggregation using an APIService object, this aggregation continues
to work after you upgrade.
`TokenReview`
: Migrate to use the **authentication.k8s.io/v1** [TokenReview](/docs/reference/kubernetes-api/authentication-resources/token-review-v1/)
API, available since v1.10.
As well as serving this API via HTTP, the Kubernetes API server uses the same format to
[send](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)
TokenReviews to webhooks. The v1.22 release continues to use the v1beta1 API for TokenReviews
sent to webhooks by default. See [Looking ahead](#looking-ahead) for some specific tips about
switching to the stable API.
`SubjectAccessReview`, `SelfSubjectAccessReview` and `LocalSubjectAccessReview`
: Migrate to use the **authorization.k8s.io/v1** versions of those
[authorization APIs](/docs/reference/kubernetes-api/authorization-resources/), available since v1.6.
`CertificateSigningRequest`
: Migrate to use the **certificates.k8s.io/v1**
[CertificateSigningRequest](/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1/)
API, available since v1.19.
You can use the v1 API to retrieve or update existing objects, even if they were created
using an older API version. Existing issued certificates retain their validity when you upgrade.
`Lease`
: Migrate to use the **coordination.k8s.io/v1** [Lease](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)
API, available since v1.14.
You can use the v1 API to retrieve or update existing objects, even if they were created
using an older API version.
### `kubectl convert`
There is a plugin to `kubectl` that provides the `kubectl convert` subcommand.
It's an official plugin that you can download as part of Kubernetes.
See [Download Kubernetes](/releases/download/) for more details.
You can use `kubectl convert` to update manifest files to use a different API
version. For example, if you have a manifest in source control that uses the beta
Ingress API, you can check that definition out,
and run
`kubectl convert -f <manifest> --output-version <group>/<version>`.
You can use the `kubectl convert` command to automatically convert an
existing manifest.
For example, to convert an older Ingress definition to
`networking.k8s.io/v1`, you can run:
```bash
kubectl convert -f ./legacy-ingress.yaml --output-version networking.k8s.io/v1
```
The automatic conversion uses a similar technique to how the Kubernetes control plane
updates objects that were originally created using an older API version. Because it's
a mechanical conversion, you might need to go in and change the manifest to adjust
defaults etc.
### Rehearse for the upgrade
If you manage your cluster's API server component, you can try out these API
removals before you upgrade to Kubernetes v1.22.
To do that, add the following to the kube-apiserver command line arguments:
`--runtime-config=admissionregistration.k8s.io/v1beta1=false,apiextensions.k8s.io/v1beta1=false,apiregistration.k8s.io/v1beta1=false,authentication.k8s.io/v1beta1=false,authorization.k8s.io/v1beta1=false,certificates.k8s.io/v1beta1=false,coordination.k8s.io/v1beta1=false,extensions/v1beta1/ingresses=false,networking.k8s.io/v1beta1=false`
(as a side effect, this also turns off v1beta1 of EndpointSlice - watch out for
that when you're testing).
Once you've switched all the kube-apiservers in your cluster to use that setting,
those beta APIs are removed. You can test that API clients (`kubectl`, deployment
tools, custom controllers etc) still work how you expect, and you can revert if
you need to without having to plan a more disruptive downgrade.
### Advice for software authors
Maybe you're reading this because you're a developer of an addon or other
component that integrates with Kubernetes?
If you develop an Ingress controller, webhook authenticator, an API aggregation, or
any other tool that relies on these deprecated APIs, you should already have started
to switch your software over.
You can use the tips in
[Rehearse for the upgrade](#rehearse-for-the-upgrade) to run your own Kubernetes
cluster that only uses the new APIs, and make sure that your code works OK.
For your documentation, make sure readers are aware of any steps they should take
for the Kubernetes v1.22 upgrade.
Where possible, give your users a hand to adopt the new APIs early - perhaps in a
test environment - so they can give you feedback about any problems.
There are some [more deprecations](#looking-ahead) coming in Kubernetes v1.25,
so plan to have those covered too.
## Kubernetes API removals
Here's some background about why Kubernetes removes some APIs, and also a promise
about _stable_ APIs in Kubernetes.
Kubernetes follows a defined
[deprecation policy](/docs/reference/using-api/deprecation-policy/) for its
features, including the Kubernetes API. That policy allows for replacing stable
(“GA”) APIs from Kubernetes. Importantly, this policy means that a stable API only
be deprecated when a newer stable version of that same API is available.
That stability guarantee matters: if you're using a stable Kubernetes API, there
won't ever be a new version released that forces you to switch to an alpha or beta
feature.
Earlier stages are different. Alpha features are under test and potentially
incomplete. Almost always, alpha features are disabled by default.
Kubernetes releases can and do remove alpha features that haven't worked out.
After alpha, comes beta. These features are typically enabled by default; if the
testing works out, the feature can graduate to stable. If not, it might need
a redesign.
Last year, Kubernetes officially
[adopted](/blog/2020/08/21/moving-forward-from-beta/#avoiding-permanent-beta)
a policy for APIs that have reached their beta phase:
> For Kubernetes REST APIs, when a new feature's API reaches beta, that starts
> a countdown. The beta-quality API now has three releases &hellip;
> to either:
>
> * reach GA, and deprecate the beta, or
> * have a new beta version (and deprecate the previous beta).
_At the time of that article, three Kubernetes releases equated to roughly nine
calendar months. Later that same month, Kubernetes
adopted a new
release cadence of three releases per calendar year, so the countdown period is
now roughly twelve calendar months._
Whether an API removal is because of a beta feature graduating to stable, or
because that API hasn't proved successful, Kubernetes will continue to remove
APIs by following its deprecation policy and making sure that migration options
are documented.
### Looking ahead
There's a setting that's relevant if you use webhook authentication checks.
A future Kubernetes release will switch to sending TokenReview objects
to webhooks using the `authentication.k8s.io/v1` API by default. At the moment,
the default is to send `authentication.k8s.io/v1beta1` TokenReviews to webhooks,
and that's still the default for Kubernetes v1.22.
However, you can switch over to the stable API right now if you want:
add `--authentication-token-webhook-version=v1` to the command line options for
the kube-apiserver, and check that webhooks for authentication still work how you
expected.
Once you're happy it works OK, you can leave the `--authentication-token-webhook-version=v1`
option set across your control plane.
The **v1.25** release that's planned for next year will stop serving beta versions of
several Kubernetes APIs that are stable right now and have been for some time.
The same v1.25 release will **remove** PodSecurityPolicy, which is deprecated and won't
graduate to stable. See
[PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)
for more information.
The official [list of API removals](/docs/reference/using-api/deprecation-guide/#v1-25)
planned for Kubernetes 1.25 is:
* The beta `CronJob` API (**batch/v1beta1**)
* The beta `EndpointSlice` API (**networking.k8s.io/v1beta1**)
* The beta `PodDisruptionBudget` API (**policy/v1beta1**)
* The beta `PodSecurityPolicy` API (**policy/v1beta1**)
## Want to know more?
Deprecations are announced in the Kubernetes release notes. You can see the announcements
of pending deprecations in the release notes for
[1.19](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md#deprecations),
[1.20](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation),
and [1.21](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md#deprecation).
For information on the process of deprecation and removal, check out the official Kubernetes
[deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api)
document.
@@ -1,65 +0,0 @@
---
layout: blog
title: "Spotlight on SIG Usability"
date: 2021-07-15
slug: sig-usability-spotlight-2021
---
**Author:** Kunal Kushwaha, Civo
## Introduction
Are you interested in learning about what [SIG Usability](https://github.com/kubernetes/community/tree/master/sig-usability) does and how you can get involved? Well, you're at the right place. SIG Usability is all about making Kubernetes more accessible to new folks, and its main activity is conducting user research for the community. In this blog, we have summarized our conversation with [Gaby Moreno](https://twitter.com/morengab), who walks us through the various aspects of being a part of the SIG and shares some insights about how others can get involved.
Gaby is a co-lead for SIG Usability. She works as a Product Designer at IBM and enjoys working on the user experience of open, hybrid cloud technologies like Kubernetes, OpenShift, Terraform, and Cloud Foundry.
## A summary of our conversation
### Q. Could you tell us a little about what SIG Usability does?
A. SIG Usability at a high level started because there was no dedicated user experience team for Kubernetes. The extent of SIG Usability is focussed on the end-client ease of use of the Kubernetes project. The main activity is user research for the community, which includes speaking to Kubernetes users.
This covers points like user experience and accessibility. The objectives of the SIG are to guarantee that the Kubernetes project is maximally usable by people of a wide range of foundations and capacities, such as incorporating internationalization and ensuring the openness of documentation.
### Q. Why should new and existing contributors consider joining SIG Usability?
A. There are plenty of territories where new contributors can begin. For example:
- User research projects, where people can help understand the usability of the end-user experiences, including error messages, end-to-end tasks, etc.
- Accessibility guidelines for Kubernetes community artifacts, examples include: internationalization of documentation, color choices for people with color blindness, ensuring compatibility with screen reader technology, user interface design for core components with user interfaces, and more.
### Q. What do you do to help new contributors get started?
A. New contributors can get started by shadowing one of the user interviews, going through user interview transcripts, analyzing them, and designing surveys.
SIG Usability is also open to new project ideas. If you have an idea, well do what we can to support it. There are regular SIG Meetings where people can ask their questions live. These meetings are also recorded for those who may not be able to attend. As always, you can reach out to us on Slack as well.
### Q. What does the survey include?
A. In simple terms, the survey gathers information about how people use Kubernetes, such as trends in learning to deploy a new system, error messages they receive, and workflows.
One of our goals is to standardize the responses accordingly. The ultimate goal is to analyze survey responses for important user stories whose needs aren't being met.
### Q. Are there any particular skills youd like to recruit for? What skills are contributors to SIG Usability likely to learn?
A. Although contributing to SIG Usability does not have any pre-requisites as such, experience with user research, qualitative research, or prior experience with how to conduct an interview would be great plus points. Quantitative research, like survey design and screening, is also helpful and something that we expect contributors to learn.
### Q. What are you getting positive feedback on, and whats coming up next for SIG Usability?
A. We have had new members joining and coming to monthly meetings regularly and showing interests in becoming a contributor and helping the community. We have also had a lot of people reach out to us via Slack showcasing their interest in the SIG.
Currently, we are focused on finishing the study mentioned in our [talk](https://www.youtube.com/watch?v=Byn0N_ZstE0), also our project for this year. We are always happy to have new contributors join us.
### Q: Any closing thoughts/resources youd like to share?
A. We love meeting new contributors and assisting them in investigating different Kubernetes project spaces. We will work with and team up with other SIGs to facilitate engaging with end-users, running studies, and help them integrate accessible design practices into their development practices.
Here are some resources for you to get started:
- [GitHub](https://github.com/kubernetes/community/tree/master/sig-usability)
- [Mailing list](https://groups.google.com/g/kubernetes-sig-usability)
- [Open Community Issues/PRs](https://github.com/kubernetes/community/labels/sig%2Fusability)
- [Slack](https://slack.k8s.io/)
- [Slack channel #sig-usability](https://kubernetes.slack.com/archives/CLC5EF63T)
## Wrap Up
SIG Usability hosted a [KubeCon talk](https://www.youtube.com/watch?v=Byn0N_ZstE0) about studying Kubernetes users' experiences. The talk focuses on updates to the user study projects, understanding who is using Kubernetes, what they are trying to achieve, how the project is addressing their needs, and where we need to improve the project and the client experience. Join the SIG's update 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 usability team as a contributor!
@@ -1,83 +0,0 @@
---
layout: blog
title: "Kubernetes Release Cadence Change: Heres What You Need To Know"
date: 2021-07-20
slug: new-kubernetes-release-cadence
---
**Authors**: Celeste Horgan, Adolfo García Veytia, James Laverack, Jeremy Rickard
On April 23, 2021, the Release Team merged a Kubernetes Enhancement Proposal (KEP) changing the Kubernetes release cycle from four releases a year (once a quarter) to three releases a year.
This blog post provides a high level overview about what this means for the Kubernetes community's contributors and maintainers.
## What's changing and when
Starting with the [Kubernetes 1.22 release](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.22), a lightweight policy will drive the creation of each release schedule. This policy states:
* The first Kubernetes release of a calendar year should start at the second or third
week of January to provide people more time for contributors coming back from the
end of year holidays.
* The last Kubernetes release of a calendar year should be finished by the middle of
December.
* A Kubernetes release cycle has a length of approximately 15 weeks.
* The week of KubeCon + CloudNativeCon is not considered a 'working week' for SIG Release. The Release Team will not hold meetings or make decisions in this period.
* An explicit SIG Release break of at least two weeks between each cycle will
be enforced.
As a result, Kubernetes will follow a three releases per year cadence. Kubernetes 1.23 will be the final release of the 2021 calendar year. This new policy results in a very predictable release schedule, allowing us to forecast upcoming release dates:
*Proposed Kubernetes Release Schedule for the remainder of 2021*
| Week Number in Year | Release Number | Release Week | Note |
| -------- | -------- | -------- | -------- |
| 35 | 1.23 | 1 (August 23) | |
| 50 | 1.23 | 16 (December 07) | KubeCon + CloudNativeCon NA Break (Oct 11-15) |
*Proposed Kubernetes Release Schedule for 2022*
| Week Number in Year | Release Number | Release Week | Note |
| -------- | -------- | -------- | -------- |
| 1 | 1.24 | 1 (January 03) | |
| 15 | 1.24 | 15 (April 12) | |
| 17 | 1.25 | 1 (April 26) | KubeCon + CloudNativeCon EU likely to occur |
| 32 | 1.25 | 15 (August 09) | |
| 34 | 1.26 | 1 (August 22 | KubeCon + CloudNativeCon NA likely to occur |
| 49 | 1.26 | 14 (December 06) |
These proposed dates reflect only the start and end dates, and they are subject to change. The Release Team will select dates for enhancement freeze, code freeze, and other milestones at the start of each release. For more information on these milestones, please refer to the [release phases](https://www.k8s.dev/resources/release/#phases) documentation. Feedback from prior releases will feed into this process.
## What this means for end users
The major change end users will experience is a slower release cadence and a slower rate of enhancement graduation. Kubernetes release artifacts, release notes, and all other aspects of any given release will stay the same.
Prior to this change an enhancement could graduate from alpha to stable in 9 months. With the change in cadence, this will stretch to 12 months. Additionally, graduation of features over the last few releases has in some part been driven by release team activities.
With fewer releases, users can expect to see the rate of feature graduation slow. Users can also expect releases to contain a larger number of enhancements that they need to be aware of during upgrades. However, with fewer releases to consume per year, it's intended that end user organizations will spend less time on upgrades and gain more time on supporting their Kubernetes clusters. It also means that Kubernetes releases are in support for a slightly longer period of time, so bug fixes and security patches will be available for releases for a longer period of time.
## What this means for Kubernetes contributors
With a lower release cadence, contributors have more time for project enhancements, feature development, planning, and testing. A slower release cadence also provides more room for maintaining their mental health, preparing for events like KubeCon + CloudNativeCon or work on downstream integrations.
## Why we decided to change the release cadence
The Kubernetes 1.19 cycle was far longer than usual. SIG Release extended it to lessen the burden on both Kubernetes contributors and end users due the COVID-19 pandemic. Following this extended release, the Kubernetes 1.20 release became the third, and final, release for 2020.
As the Kubernetes project matures, the number of enhancements per cycle grows, along with the burden on contributors, the Release Engineering team. Downstream consumers and integrators also face increased challenges keeping up with [ever more feature-packed releases](https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announcement/). A wider project adoption means the complexity of supporting a rapidly evolving platform affects a bigger downstream chain of consumers.
Changing the release cadence from four to three releases per year balances a variety of factors for stakeholders: while it's not strictly an LTS policy, consumers and integrators will get longer support terms for each minor version as the extended release cycles lead to the [previous three releases being supported](https://kubernetes.io/blog/2020/08/31/kubernetes-1-19-feature-one-year-support/) for a longer period. Contributors get more time to [mature enhancements](https://www.cncf.io/blog/2021/04/12/enhancing-the-kubernetes-enhancements-process/) and [get them ready for production](https://github.com/kubernetes/community/blob/master/sig-architecture/production-readiness.md).
Finally, the management overhead for SIG Release and the Release Engineering team diminishes allowing the team to spend more time on improving the quality of the software releases and the tooling that drives them.
## How you can help
Join the [discussion](https://github.com/kubernetes/sig-release/discussions/1566) about communicating future release dates and be sure to be on the lookout for post release surveys.
## Where you can find out more
- Read the KEP [here](https://github.com/kubernetes/enhancements/tree/master/keps/sig-release/2572-release-cadence)
- Join the [kubernetes-dev](https://groups.google.com/g/kubernetes-dev) mailing list
- Join [Kubernetes Slack](https://slack.k8s.io) and follow the #announcements channel
@@ -1,71 +0,0 @@
---
layout: blog
title: 'Updating NGINX-Ingress to use the stable Ingress API'
date: 2021-07-26
slug: update-with-ingress-nginx
---
**Authors:** James Strong, Ricardo Katz
With all Kubernetes APIs, there is a process to creating, maintaining, and
ultimately deprecating them once they become GA. The networking.k8s.io API group is no
different. The upcoming Kubernetes 1.22 release will remove several deprecated APIs
that are relevant to networking:
- the `networking.k8s.io/v1beta1` API version of [IngressClass](/docs/concepts/services-networking/ingress/#ingress-class)
- all beta versions of [Ingress](/docs/concepts/services-networking/ingress/): `extensions/v1beta1` and `networking.k8s.io/v1beta1`
On a v1.22 Kubernetes cluster, you'll be able to access Ingress and IngressClass
objects through the stable (v1) APIs, but access via their beta APIs won't be possible.
This change has been in
in discussion since
[2017](https://github.com/kubernetes/kubernetes/issues/43214),
[2019](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/) with
1.16 Kubernetes API deprecations, and most recently in
KEP-1453:
[Graduate Ingress API to GA](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/1453-ingress-api#122).
During community meetings, the networking Special Interest Group has decided to continue
supporting Kubernetes versions older than 1.22 with Ingress-NGINX version 0.47.0.
Support for Ingress-NGINX will continue for six months after Kubernetes 1.22
is released. Any additional bug fixes and CVEs for Ingress-NGINX will be
addressed on a need-by-need basis.
Ingress-NGINX will have separate branches and releases of Ingress-NGINX to
support this model, mirroring the Kubernetes project process. Future
releases of the Ingress-NGINX project will track and support the latest
versions of Kubernetes.
{{< table caption="Ingress NGINX supported version with Kubernetes Versions" >}}
Kubernetes version | Ingress-NGINX version | Notes
:-------------------|:----------------------|:------------
v1.22 | v1.0.0-alpha.2 | New features, plus bug fixes.
v1.21 | v0.47.x | Bugfixes only, and just for security issues or crashes. No end-of-support date announced.
v1.20 | v0.47.x | Bugfixes only, and just for security issues or crashes. No end-of-support date announced.
v1.19 | v0.47.x | Bugfixes only, and just for security issues or crashes. Fixes only provided until 6 months after Kubernetes v1.22.0 is released.
{{< /table >}}
Because of the updates in Kubernetes 1.22, **v0.47.0** will not work with
Kubernetes 1.22.
# What you need to do
The team is currently in the process of upgrading ingress-nginx to support
the v1 migration, you can track the progress
[here](https://github.com/kubernetes/ingress-nginx/pull/7156).
We're not making feature improvements to `ingress-nginx` until after the support for
Ingress v1 is complete.
In the meantime to ensure no compatibility issues:
* Update to the latest version of Ingress-NGINX; currently
[v0.47.0](https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v0.47.0)
* After Kubernetes 1.22 is released, ensure you are using the latest version of
Ingress-NGINX that supports the stable APIs for Ingress and IngressClass.
* Test Ingress-NGINX version v1.0.0-alpha.2 with Cluster versions >= 1.19
and report any issues to the projects Github page.
The communitys feedback and support in this effort is welcome. The
Ingress-NGINX Sub-project regularly holds community meetings where we discuss
this and other issues facing the project. For more information on the sub-project,
please see [SIG Network](https://github.com/kubernetes/community/tree/master/sig-network).
@@ -1,231 +0,0 @@
---
layout: blog
title: "Roorkee robots, releases and racing: the Kubernetes 1.21 release interview"
date: 2021-07-29
---
**Author**: Craig Box (Google)
With Kubernetes 1.22 due out next week, now is a great time to look back on 1.21. The release team for that version was led by [Nabarun Pal](https://twitter.com/theonlynabarun) from VMware.
Back in April I [interviewed Nabarun](https://kubernetespodcast.com/episode/146-kubernetes-1.21/) on the weekly [Kubernetes Podcast from Google](https://kubernetespodcast.com/); the latest in a series of release lead conversations that started back with 1.11, not long after the show started back in 2018.
In these interviews we learn a little about the release, but also about the process behind it, and the story behind the person chosen to lead it. Getting to know a community member is my favourite part of the show each week, and so I encourage you to [subscribe wherever you get your podcasts](https://kubernetespodcast.com/subscribe/). With a release coming next week, you can probably guess what our next topic will be!
*This transcript has been edited and condensed for clarity.*
---
**CRAIG BOX: You have a Bachelor of Technology in Metallurgical and Materials Engineering. How are we doing at turning lead into gold?**
NABARUN PAL: Well, last I checked, we have yet to find the philosopher's stone!
**CRAIG BOX: One of the more important parts of the process?**
NABARUN PAL: We're not doing that well in terms of getting alchemists up and running. There is some improvement in nuclear technology, where you can turn lead into gold, but I would guess buying gold would be much more efficient.
**CRAIG BOX: Or Bitcoin? It depends what you want to do with the gold.**
NABARUN PAL: Yeah, seeing the increasing prices of Bitcoin, you'd probably prefer to bet on that. But, don't take this as a suggestion. I'm not a registered investment advisor, and I don't give investment advice!
**CRAIG BOX: But you are, of course, a trained materials engineer. How did you get into that line of education?**
NABARUN PAL: We had a graded and equated exam structure, where you sit a single exam, and then based on your performance in that exam, you can try any of the universities which take those scores into account. I went to the Indian Institute of Technology, Roorkee.
Materials engineering interested me a lot. I had a passion for computer science since childhood, but I also liked material science, so I wanted to explore that field. I did a lot of exploration around material science and metallurgy in my freshman and sophomore years, but then computing, since it was a passion, crept into the picture.
**CRAIG BOX: Let's dig in there a little bit. What did computing look like during your childhood?**
NABARUN PAL: It was a very interesting journey. I started exploring computers back when I was seven or eight. For my first programming language, if you call it a programming language, I explored LOGO.
You have a turtle on the screen, and you issue commands to it, like move forward or rotate or pen up or pen down. You basically draw geometric figures. I could visually see how I could draw a square and how I could draw a triangle. It was an interesting journey after that. I learned BASIC, then went to some amount of HTML, JavaScript.
**CRAIG BOX: It's interesting to me because Logo and BASIC were probably my first two programming languages, but I think there was probably quite a gap in terms of when HTML became a thing after those two! Did your love of computing always lead you down the path towards programming, or were you interested as a child in using computers for games or application software? What led you specifically into programming?**
NABARUN PAL: Programming came in late. Not just in computing, but in life, I'm curious with things. When my parents got me my first computer, I was curious. I was like, "how does this operating system work?" What even is running it? Using a television and using a computer is a different experience, but usability is kind of the same thing. The HCI device for a television is a remote, whereas with a computer, I had a keyboard and a mouse. I used to tinker with the box and reinstall operating systems.
We used to get magazines back then. They used to bundle OpenSuse or Debian, and I used to install them. It was an interesting experience, 15 years back, how Linux used to be. I have been a tinkerer all around, and that's what eventually led me to programming.
**CRAIG BOX: With an interest in both the physical and ethereal aspects of technology, you did a lot of robotics challenges during university. That's something that I am not surprised to hear from someone who has a background in Logo, to be honest. There's Mindstorms, and a lot of other technology that is based around robotics that a lot of LOGO people got into. How was that something that came about for you?**
NABARUN PAL: When I joined my university, apart from studying materials, one of the things they used to really encourage was to get involved in a lot of extracurricular activities. One which interested me was robotics. I joined [my college robotics team](https://github.com/marsiitr) and participated in a lot of challenges.
Predominantly, we used to participate in this competition called [ABU Robocon](https://en.wikipedia.org/wiki/ABU_Robocon), which is an event conducted by the Asia-Pacific Broadcasting Union. What they used to do was, every year, one of the participating countries in the contest would provide a problem statement. For example, one year, they asked us to build a badminton-playing robot. They asked us to build a rugby playing robot or a Frisbee thrower, and there are some interesting problem statements around the challenge: you can't do this. You can't do that. Weight has to be like this. Dimensions have to be like that.
I got involved in that, and most of my time at university, I used to spend there. Material science became kind of a backburner for me, and my hobby became my full time thing.
**CRAIG BOX: And you were not only involved there in terms of the project and contributions to it, but you got involved as a secretary of the team, effectively, doing a lot of the organization, which is a thread that will come up as we speak about Kubernetes.**
NABARUN PAL: Over the course of time, when I gained more knowledge into how the team works, it became very natural that I graduated up the ladder and then managed juniors. I became the joint secretary of the robotics club in our college. This was more of a broad, engaging role in evangelizing robotics at the university, to promote events, to help students to see the value in learning robotics - what you gain out of that mechanically or electronically, or how do you develop your logic by programming robots.
**CRAIG BOX: Your first job after graduation was working at a company called Algoshelf, but you were also an intern there while you were at school?**
NABARUN PAL: Algoshelf was known as Rorodata when I joined them as an intern. This was also an interesting opportunity for me in the sense that I was always interested in writing programs which people would use. One of the things that I did there was build an open source Function as a Service framework, if I may call it that - it was mostly turning Python functions into web servers without even writing any code. The interesting bit there was that it was targeted toward data scientists, and not towards programmers. We had to understand the pain of data scientists, that they had to learn a lot of programming in order to even deploy their machine learning models, and we wanted to solve that problem.
They offered me a job after my internship, and I kept on working for them after I graduated from university. There, I got introduced to Kubernetes, so we pivoted into a product structure where the very same thing I told you, the Functions as a Service thing, could be deployed in Kubernetes. I was exploring Kubernetes to use it as a scalable platform. Instead of managing pets, we wanted to manage cattle, as in, we wanted to have a very highly distributed architecture.
**CRAIG BOX: Not actual cattle. I've been to India. There are a lot of cows around.**
NABARUN PAL: Yeah, not actual cattle. That is a bit tough.
**CRAIG BOX: When Algoshelf we're looking at picking up Kubernetes, what was the evaluation process like? Were you looking at other tools at the time? Or had enough time passed that Kubernetes was clearly the platform that everyone was going to use?**
NABARUN PAL: Algoshelf was a natural evolution. Before Kubernetes, we used to deploy everything on a single big AWS server, using systemd. Everything was a systemd service, and everything was deployed using Fabric. Fabric is a Python package which essentially is like Ansible, but much leaner, as it does not have all the shims and things that Ansible has.
Then we asked "what if we need to scale out to different machines?" Kubernetes was in the hype. We hopped onto the hype train to see whether Kubernetes was worth it for us. And that's where my journey started, exploring the ecosystem, exploring the community. How can we improve the community in essence?
**CRAIG BOX: A couple of times now you've mentioned as you've grown in a role, becoming part of the organization and the arranging of the group. You've talked about working in Python. You had submitted some talks to Pycon India. And I understand you're now a tech lead for that conference. What does the tech community look like in India and how do you describe your involvement in it?**
NABARUN PAL: My involvement with the community began when I was at university. When I was working as an intern at Algoshelf, I was introduced to this-- I never knew about PyCon India, or tech conferences in general.
The person that I was working with just asked me, like hey, did you submit a talk to PyCon India? It's very useful, the library that we were making. So I [submitted a talk](https://www.nabarun.in/talk/2017/pyconindia/#1) to PyCon India in 2017. Eventually the talk got selected. That was not my first speaking opportunity, it was my second. I also spoke at PyData Delhi on a similar thing that I worked on in my internship.
It has been a journey since then. I talked about the same thing at FOSSASIA Summit in Singapore, and got really involved with the Python community because it was what I used to work on back then.
After giving all those talks at conferences, I got also introduced to this amazing group called [dgplug](https://dgplug.org/), which is an acronym for the Durgapur Linux Users Group. It is a group started in-- I don't remember the exact year, but it was around 12 to 13 years back, by someone called Kushal Das, with the ideology of [training students into being better open source contributors](https://foss.training/).
I liked the idea and got involved with in teaching last year. It is not limited to students. Professionals can also join in. It's about making anyone better at upstream contributions, making things sustainable. I started training people on Vim, on how to use text editors. so they are more efficient and productive. In general life, text editors are a really good tool.
The other thing was the shell. How do you navigate around the Linux shell and command line? That has been a fun experience.
**CRAIG BOX: It's very interesting to think about that, because my own involvement with a Linux User Group was probably around the year 2000. And back then we were teaching people how to install things-- Linux on CD was kinda new at that point in time. There was a lot more of, what is this new thing and how do we get involved? When the internet took off around that time, all of that stuff moved online - you no longer needed to go meet a group of people in a room to talk about Linux. And I haven't really given much thought to the concept of a LUG since then, but it's great to see it having turned into something that's now about contributing, rather than just about how you get things going for yourself.**
NABARUN PAL: Exactly. So as I mentioned earlier, my journey into Linux was installing SUSE from DVDs that came bundled with magazines. Back then it was a pain installing things because you did not get any instructions. There has certainly been a paradigm shift now. People are more open to reading instructions online, downloading ISOs, and then just installing them. So we really don't need to do that as part of LUGs.
We have shifted more towards enabling people to contribute to whichever project that they use. For example, if you're using Fedora, contribute to Fedora; make things better. It's just about giving back to the community in any way possible.
**CRAIG BOX: You're also involved in the [Kubernetes Bangalore meetup group](https://www.meetup.com/Bangalore-Kubernetes-Meetup/). Does that group have a similar mentality?**
NABARUN PAL: The Kubernetes Bangalore meetup group is essentially focused towards spreading the knowledge of Kubernetes and the aligned products in the ecosystem, whatever there is in the Cloud Native Landscape, in various ways. For example, to evangelize about using them in your company or how people use them in existing ways.
So a few months back in February, we did something like a [Kubernetes contributor workshop](https://www.youtube.com/watch?v=FgsXbHBRYIc). It was one of its kind in India. It was the first one if I recall correctly. We got a lot of traction and community members interested in contributing to Kubernetes and a lot of other projects. And this is becoming a really valuable thing.
I'm not much involved in the organization of the group. There are really great people already organizing it. I keep on being around and attending the meetups and trying to answer any questions if people have any.
**CRAIG BOX: One way that it is possible to contribute to the Kubernetes ecosystem is through the release process. You've [written a blog](https://blog.naba.run/posts/release-enhancements-journey/) which talks about your journey through that. It started in Kubernetes 1.17, where you took a shadow role for that release. Tell me about what it was like to first take that plunge.**
NABARUN PAL: Taking the plunge was a big step, I would say. It should not have been that way. After getting into the team, I saw that it is really encouraged that you should just apply to the team - but then write truthfully about yourself. What do you want? Write your passionate goal, why you want to be in the team.
So even right now the shadow applications are open for the next release. I wanted to give that a small shoutout. If you want to contribute to the Kubernetes release team, please do apply. The form is pretty simple. You just need to say why do you want to contribute to the release team.
**CRAIG BOX: What was your answer to that question?**
NABARUN PAL: It was a bit tricky. I have this philosophy of contributing to projects that I use in my day-to-day life. I use a lot of open source projects daily, and I started contributing to Kubernetes primarily because I was using the Kubernetes Python client. That was one of my first contributions.
When I was contributing to that, I explored the release team and it interested me a lot, particularly how interesting and varied the mechanics of releasing Kubernetes are. For most software projects, it's usually whenever you decide that you have made meaningful progress in terms of features, you release it. But Kubernetes is not like that. We follow a regular release cadence. And all those aspects really interested me. I actually applied for the first time in Kubernetes 1.16, but got rejected.
But I still applied to Kubernetes 1.17, and I got into the enhancements team. That team was led by [MrBobbyTables, Bob Killen](https://kubernetespodcast.com/episode/126-research-steering-honking/), back then, and [Jeremy Rickard](https://kubernetespodcast.com/episode/131-kubernetes-1.20/) was one of my co-shadows in the team. I shadowed enhancements again. Then I lead enhancements in 1.19. I then shadowed the lead in 1.20 and eventually led the 1.21 team. That's what my journey has been.
My suggestion to people is don't be afraid of failure. Even if you don't get selected, it's perfectly fine. You can still contribute to the release team. Just hop on the release calls, raise your hand, and introduce yourself.
**CRAIG BOX: Between the 1.20 and 1.21 releases, you moved to work on the upstream contribution team at VMware. I've noticed that VMware is hiring a lot of great upstream contributors at the moment. Is this something that [Stephen Augustus](https://kubernetespodcast.com/episode/130-kubecon-na-2020/) had his fingerprints all over? Is there something in the water?**
NABARUN PAL: A lot of people have fingerprints on this process. Stephen certainly had his fingerprints on it, I would say. We are expanding the team of upstream contributors primarily because the product that we are working for is based on Kubernetes. It helps us a lot in driving processes upstream and helping out the community as a whole, because everyone then gets enabled and benefits from what we contribute to the community.
**CRAIG BOX: I understand that the Tanzu team is being built out in India at the moment, but I guess you probably haven't been able to meet them in person yet?**
NABARUN PAL: Yes and no. I did not meet any of them after joining VMware, but I met a lot of my teammates, before I joined VMware, at KubeCons. For example, I met Nikhita, I met Dims, I met Stephen at KubeCon. I am yet to meet other members of the team and I'm really excited to catch up with them once everything comes out of lockdown and we go back to our normal lives.
**CRAIG BOX: Yes, everyone that I speak to who has changed jobs in the pandemic says it's a very odd experience, just nothing really being different. And the same perhaps for people who are working on open source moving companies as well. They're doing the same thing, perhaps just for a different employer.**
NABARUN PAL: As we say in the community, see you in another Slack in some time.
**CRAIG BOX: We now turn to the recent release of Kubernetes 1.21. First of all, congratulations on that.**
NABARUN PAL: Thank you.
**CRAIG BOX: [The announcement](https://kubernetes.io/blog/2021/04/08/kubernetes-1-21-release-announcement/) says the release consists of 51 enhancements, 13 graduating to stable, 16 moving to beta, 20 entering alpha, and then two features that have been deprecated. How would you summarize this release?**
NABARUN PAL: One of the big points for this release is that it is the largest release of all time.
**CRAIG BOX: Really?**
NABARUN PAL: Yep. 1.20 was the largest release back then, but 1.21 got more enhancements, primarily due to a lot of changes that we did to the process.
In the 1.21 release cycle, we did a few things differently compared to other release cycles-- for example, in the enhancement process. An enhancement, in the Kubernetes context, is basically a feature proposal. You will hear the terminology [Kubernetes Enhancement Proposals](https://github.com/kubernetes/enhancements/blob/master/keps/README.md), or KEP, a lot in the community. An enhancement is a broad thing encapsulated in a specific document.
**CRAIG BOX: I like to think of it as a thing that's worth having a heading in the release notes.**
NABARUN PAL: Indeed. Until the 1.20 release cycle, what we used to do was-- the release team has a vertical called enhancements. The enhancements team members used to ping each of the enhancement issues and ask whether they want to be part of the release cycle or not. The authors would decide, or talk to their SIG, and then come back with the answer, as to whether they wanted to be part of the cycle.
In this release, what we did was we eliminated that process and asked the SIGs proactively to discuss amongst themselves, what they wanted to pitch in for this release cycle. What set of features did they want to graduate this release? They may introduce things in alpha, graduate things to beta or stable, or they may also deprecate features.
What this did was promote a lot of async processes, and at the same time, give power back to the community. The community decides what they want in the release and then comes back collectively. It also reduces a lot of stress on the release team who previously had to ask people consistently what they wanted to pitch in for the release. You now have a deadline. You discuss amongst your SIG what your roadmap is and what it looks like for the near future. Maybe this release, and the next two. And you put all of those answers into a Google spreadsheet. Spreadsheets are still a thing.
**CRAIG BOX: The Kubernetes ecosystem runs entirely on Google Spreadsheets.**
NABARUN PAL: It does, and a lot of Google Docs for meeting notes! We did a lot of process improvements, which essentially led to a better release. This release cycle we had 13 enhancements graduating to stable, 16 which moved to beta, and 20 enhancements which were net new features into the ecosystem, and came in as alpha.
Along with that are features set for deprecation. One of them was PodSecurityPolicy. That has been a point of discussion in the Kubernetes user base and we also published [a blog post about it](https://kubernetes.io/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). All credit to SIG Security who have been on top of things as to find a replacement for PodSecurityPolicy even before this release cycle ended, so that they could at least have a proposal of what will happen next.
**CRAIG BOX: Let's talk about some old things and some new things. You mentioned PodSecurityPolicy there. That's a thing that's been around a long time and is being deprecated. Two things that have been around a long time and that are now being promoted to stable are CronJobs and PodDisruptionBudgets, both of which were introduced in Kubernetes 1.4, which came out in 2016. Why do you think it took so long for them both to go stable?**
NABARUN PAL: I might not have a definitive answer to your question. One of the things that I feel is they might be already so good that nobody saw that they were beta features, and just kept on using them.
One of the things that I noticed when reading for the CronJobs graduation from beta to stable was the new controller. Users might not see this, but there has been a drastic change in the CronJob controller v2. What it essentially does is goes from a poll-based method of checking what users have defined as CronJobs to a queue architecture, which is the modern method of defining controllers. That has been one of the really good improvements in the case of CronJobs. Instead of the controller working in O(N) time, you now have constant time complexity.
**CRAIG BOX: A lot of these features that have been in beta for a long time, like you say, people have an expectation that they are complete. With PodSecurityPolicy, it's being deprecated, which is allowed because it's a feature that never made it out of beta. But how do you think people will react to it going away? And does that say something about the need for the process to make sure that features don't just languish in beta forever, which has been introduced recently?**
NABARUN PAL: That's true. One of the driving factors, when contributors are thinking of graduating beta features has been the ["prevention of perma-beta" KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-architecture/1635-prevent-permabeta/README.md). Back in 1.19 we [introduced this process](https://kubernetes.io/blog/2020/08/21/moving-forward-from-beta/) where each of the beta resources were marked for deprecation and removal in a certain time frame-- three releases for deprecation and another release for removal. That's also a motivating factor for eventually rethinking as to how beta resources work for us in the community. That is also very effective, I would say.
**CRAIG BOX: Do remember that Gmail was in beta for eight years.**
NABARUN PAL: I did not know that!
**CRAIG BOX: Nothing in Kubernetes is quite that old yet, but we'll get there. Of the 20 new enhancements, do you have a favorite or any that you'd like to call out?**
NABARUN PAL: There are two specific features in 1.21 that I'm really interested in, and are coming as net new features. One of them is the [persistent volume health monitor](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1432-volume-health-monitor), which gives the users the capability to actually see whether the backing volumes, which power persistent volumes in Kubernetes, are deleted or not. For example, the volumes may get deleted due to an inadvertent event, or they may get corrupted. That information is basically surfaced out as a field so that the user can leverage it in any way.
The other feature is the proposal for [adding headers with the command name to kubectl requests](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/859-kubectl-headers). We have always set the user-agent information when doing those kind of requests, but the proposal is to add what command the user put in so that we can enable more telemetry, and cluster administrators can determine the usage patterns of how people are using the cluster. I'm really excited about these kind of features coming into play.
**CRAIG BOX: You're the first release lead from the Asia-Pacific region, or more accurately, outside of the US and Europe. Most meetings in the Kubernetes ecosystem are traditionally in the window of overlap between the US and Europe, in the morning in California and the evening here in the UK. What's it been like to work outside of the time zones that the community had previously been operating in?**
NABARUN PAL: It has been a fun and a challenging proposition, I would say. In the last two-ish years that I have been contributing to Kubernetes, the community has also transformed from a lot of early morning Pacific calls to more towards async processes. For example, we in the release team have transformed our processes so we don't do updates in the calls anymore. What we do is ask for updates ahead of time, and then in the call, we just discuss things which need to be discussed synchronously in the team.
We leverage the meetings right now more for discussions. But we also don't come to decisions in those discussions, because if any stakeholder is not present on the call, it puts them at a disadvantage. We are trying to talk more on Slack, publicly, or talk on mailing lists. That's where most of the discussion should happen, and also to gain lazy consensus. What I mean by lazy consensus is come up with a pre-decision kind of thing, but then also invite feedback from the broader community about what people would like them to see about that specific thing being discussed. This is where we as a community are also transforming a lot, but there is a lot more headroom to grow.
The release team also started to have EU/APAC burndown meetings. In addition to having one meeting focused towards the US and European time zones, we also do a meeting which is more suited towards European and Asia-Pacific time zones. One of the driving factors for those decisions was that the release team is seeing a lot of participation from a variety of time zones. To give you one metric, we had release team members this cycle from UTC+8 all through UTC-8 - 16 hours of span. It's really difficult to accommodate all of those zones in a single meeting. And it's not just those 16 hours of span - what about the other eight hours?
**CRAIG BOX: Yeah, you're missing New Zealand. You could add another 5 hours of span right there.**
NABARUN PAL: Exactly. So we will always miss people in meetings, and that's why we should also innovate more, have different kinds of meetings. But that also may not be very sustainable in the future. Will people attend duplicate meetings? Will people follow both of the meetings? More meetings is one of the solutions.
The other solution is you have threaded discussions on some medium, be it Slack or be it a mailing list. Then, people can just pitch in whenever it is work time for them. Then, at the end of the day, a 24-hour rolling period, you digest it, and then push it out as meeting notes. That's what the Contributor Experience Special Interest Group is doing - shout-out to them for moving to that process. I may be wrong here, but I think once every two weeks, they do async updates on Slack. And that is a really nice thing to have, improving variety of geographies that people can contribute from.
**CRAIG BOX: Once you've put everything together that you hope to be in your release, you create a release candidate build. How do you motivate people to test those?**
NABARUN PAL: That's a very interesting question. It is difficult for us to motivate people into trying out these candidates. It's mostly people who are passionate about Kubernetes who try out the release candidates and see for themselves what the bugs are. I remember [Dims tweeting out a call](https://twitter.com/dims/status/1377272238420934656) that if somebody tries out the release candidate and finds a good bug or caveat, they could get a callout in the KubeCon keynote. That's one of the incentives - if you want to be called out in a KubeCon keynote, please try our release candidates.
**CRAIG BOX: Or get a new pair of Kubernetes socks?**
NABARUN PAL: We would love to give out goodies to people who try out our release candidates and find bugs. For example, if you want the brand new release team logo as a sticker, just hit me up. If you find a bug in a 1.22 release candidate, I would love to be able to send you some coupon codes for the store. Don't quote me on this, but do reach out.
**CRAIG BOX: Now the release is out, is it time for you to put your feet up? What more things do you have to do, and how do you feel about the path ahead for yourself?**
NABARUN PAL: I was discussing this with the team yesterday. Even after the release, we had kind of a water-cooler conversation. I just pasted in a Zoom link to all the release team members and said, hey, do you want to chat? One of the things that I realized that I'm really missing is the daily burndowns right now. I will be around in the release team and the SIG Release meetings, helping out the new lead in transitioning. And even my job, right now, is not over. I'm working with Taylor, who is the emeritus advisor for 1.21, on figuring out some of the mechanics for the next release cycle. I'm also documenting what all we did as part of the process and as part of the process changes, and making sure the next release cycle is up and running.
**CRAIG BOX: We've done a lot of these release lead interviews now, and there's a question which we always like to ask, which is, what will you write down in the transition envelope? Savitha Raghunathan is the release lead for 1.22. What is the advice that you will pass on to her?**
NABARUN PAL: Three words-- **Do, Delegate, and Defer**. Categorize things into those three buckets as to what you should do right away, what you need to defer, and things that you can delegate to your shadows or other release team members. That's one of the mantras that works really well when leading a team. It is not just in the context of the release team, but it's in the context of managing any team.
The other bit is **over-communicate**. No amount of communication is enough. What I've realized is the community is always willing to help you. One of the big examples that I can give is the day before release was supposed to happen, we were seeing a lot of test failures, and then one of the community members had an idea-- why don't you just send an email? I was like, "that sounds good. We can send an email mentioning all the flakes and call out for help to the broader Kubernetes developer community." And eventually, once we sent out the email, lots of people came in to help us in de-flaking the tests and trying to find out the root cause as to why those tests were failing so often. Big shout out to Antonio and all the SIG Network folks who came to pitch in.
No matter how many names I mention, it will never be enough. A lot of people, even outside the release team, have helped us a lot with this release. And that's where the release theme comes in - **Power to the Community**. I'm really stoked by how this community behaves and how people are willing to help you all the time. It's not about what they're telling you to do, but it's what they're also interested in, they're passionate about.
**CRAIG BOX: One of the things you're passionate about is Formula One. Do you think Lewis Hamilton is going to take it away this year?**
NABARUN PAL: It's a fair probability that Lewis will win the title this year as well.
**CRAIG BOX: Which would take him to eight all time career wins. And thus-- [he's currently tied with Michael Schumacher](https://www.nytimes.com/2020/11/15/sports/autoracing/lewis-hamilton-schumacher-formula-one-record.html)-- would pull him ahead.**
NABARUN PAL: Yes. Michael Schumacher was my first favorite F1 driver, I would say. It feels a bit heartbreaking to see someone break Michael's record.
**CRAIG BOX: How do you feel about [Michael Schumacher's son joining the contest?](https://www.formula1.com/en/latest/article.breaking-mick-schumacher-to-race-for-haas-in-2021-as-famous-surname-returns.66XTVfSt80GrZe91lvWVwJ.html)**
NABARUN PAL: I feel good. Mick Schumacher is in the fray right now. And I wish we could see him, in a few years, in a Ferrari. The Schumacher family back to Ferrari would be really great to see. But then, my fan favorite has always been McLaren, partly because I like the chemistry of Lando and Carlos over the last two years. It was heartbreaking to see Carlos go to Ferrari. But then we have Lando and Daniel Ricciardo in the team. They're also fun people.
---
_[Nabarun Pal](https://twitter.com/theonlynabarun) is on the Tanzu team at VMware and served as the Kubernetes 1.21 release team lead._
_You can find the [Kubernetes Podcast from Google](http://www.kubernetespodcast.com/) at [@KubernetesPod](https://twitter.com/KubernetesPod) on Twitter, and you can [subscribe](https://kubernetespodcast.com/subscribe/) so you never miss an episode._
@@ -1,157 +0,0 @@
---
layout: blog
title: 'Kubernetes 1.22: Reaching New Peaks'
date: 2021-08-04
slug: kubernetes-1-22-release-announcement
---
**Authors:** [Kubernetes 1.22 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.22/release-team.md)
Were pleased to announce the release of Kubernetes 1.22, the second release of 2021!
This release consists of 53 enhancements: 13 enhancements have graduated to stable, 24 enhancements are moving to beta, and 16 enhancements are entering alpha. Also, three features have been deprecated.
In April of this year, the Kubernetes release cadence was officially changed from four to three releases yearly. This is the first longer-cycle release related to that change. As the Kubernetes project matures, the number of enhancements per cycle grows. This means more work, from version to version, for the contributor community and Release Engineering team, and it can put pressure on the end-user community to stay up-to-date with releases containing increasingly more features.
Changing the release cadence from four to three releases yearly balances many aspects of the project, both in how contributions and releases are managed, and also in the community's ability to plan for upgrades and stay up to date.
You can read more in the official blog post [Kubernetes Release Cadence Change: Heres What You Need To Know](https://kubernetes.io/blog/2021/07/20/new-kubernetes-release-cadence/).
## Major Themes
### Server-side Apply graduates to GA
[Server-side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) is a new field ownership and object merge algorithm running on the Kubernetes API server. Server-side Apply helps users and controllers manage their resources via declarative configurations. It allows them to create and/or modify their objects declaratively, simply by sending their fully specified intent. After being in beta for a couple releases, Server-side Apply is now generally available.
### External credential providers now stable
Support for Kubernetes client [credential plugins](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins) has been in beta since 1.11, and with the release of Kubernetes 1.22 now graduates to stable. The GA feature set includes improved support for plugins that provide interactive login flows, as well as a number of bug fixes. Aspiring plugin authors can look at [sample-exec-plugin](https://github.com/ankeesler/sample-exec-plugin) to get started.
### etcd moves to 3.5.0
Kubernetes' default backend storage, etcd, has a new release: 3.5.0. The new release comes with improvements to the security, performance, monitoring, and developer experience. There are numerous bug fixes and some critical new features like the migration to structured logging and built-in log rotation. The release comes with a detailed future roadmap to implement a solution to traffic overload. You can read a full and detailed list of changes in the [3.5.0 release announcement](https://etcd.io/blog/2021/announcing-etcd-3.5/).
### Quality of Service for memory resources
Originally, Kubernetes used the v1 cgroups API. With that design, the QoS class for a `Pod` only applied to CPU resources (such as `cpu_shares`). As an alpha feature, Kubernetes v1.22 can now use the cgroups v2 API to control memory allocation and isolation. This feature is designed to improve workload and node availability when there is contention for memory resources, and to improve the predictability of container lifecycle.
### Node system swap support
Every system administrator or Kubernetes user has been in the same boat regarding setting up and using Kubernetes: disable swap space. With the release of Kubernetes 1.22, alpha support is available to run nodes with swap memory. This change lets administrators opt in to configuring swap on Linux nodes, treating a portion of block storage as additional virtual memory.
### Windows enhancements and capabilities
Continuing to support the growing developer community, SIG Windows has released their [Development Environment](https://github.com/kubernetes-sigs/sig-windows-dev-tools/). These new tools support multiple CNI providers and can run on multiple platforms. There is also a new way to run bleeding-edge Windows features from scratch by compiling the Windows kubelet and kube-proxy, then using them along with daily builds of other Kubernetes components.
CSI support for Windows nodes moves to GA in the 1.22 release. In Kubernetes v1.22, Windows privileged containers are an alpha feature. To allow using CSI storage on Windows nodes, [CSIProxy](https://github.com/kubernetes-csi/csi-proxy) enables CSI node plugins to be deployed as unprivileged pods, using the proxy to perform privileged storage operations on the node.
### Default profiles for seccomp
An alpha feature for default seccomp profiles has been added to the kubelet, along with a new command line flag and configuration. When in use, this new feature provides cluster-wide seccomp defaults, using the `RuntimeDefault` seccomp profile rather than `Unconfined` by default. This enhances the default security of the Kubernetes Deployment. Security administrators will now sleep better knowing that workloads are more secure by default. To learn more about the feature, please refer to the official [seccomp tutorial](https://kubernetes.io/docs/tutorials/clusters/seccomp/#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads).
### More secure control plane with kubeadm
A new alpha feature allows running the `kubeadm` control plane components as non-root users. This is a long requested security measure in `kubeadm`. To try it you must enable the `kubeadm` specific RootlessControlPlane feature gate. When you deploy a cluster using this alpha feature, your control plane runs with lower privileges.
For `kubeadm`, Kubernetes 1.22 also brings a new [v1beta3 configuration API](/docs/reference/config-api/kubeadm-config.v1beta3/). This iteration adds some long requested features and deprecates some existing ones. The v1beta3 version is now the preferred API version; the v1beta2 API also remains available and is not yet deprecated.
## Major Changes
### Removal of several deprecated beta APIs
A number of deprecated beta APIs have been removed in 1.22 in favor of the GA version of those same APIs. All existing objects can be interacted with via stable APIs. This removal includes beta versions of the `Ingress`, `IngressClass`, `Lease`, `APIService`, `ValidatingWebhookConfiguration`, `MutatingWebhookConfiguration`, `CustomResourceDefinition`, `TokenReview`, `SubjectAccessReview`, and `CertificateSigningRequest` APIs.
For the full list, check out the [Deprecated API Migration Guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22) as well as the blog post [Kubernetes API and Feature Removals In 1.22: Heres What You Need To Know](https://blog.k8s.io/2021/07/14/upcoming-changes-in-kubernetes-1-22/).
### API changes and improvements for ephemeral containers
The API used to create [Ephemeral Containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/) changes in 1.22. The Ephemeral Containers feature is alpha and disabled by default, and the new API does not work with clients that attempt to use the old API.
For stable features, the kubectl tool follows the Kubernetes [version skew policy](https://kubernetes.io/releases/version-skew-policy/); however, kubectl v1.21 and older do not support the new API for ephemeral containers. If you plan to use `kubectl debug` to create ephemeral containers, and your cluster is running Kubernetes v1.22, you cannot do so with kubectl v1.21 or earlier. Please update kubectl to 1.22 if you wish to use `kubectl debug` with a mix of cluster versions.
## Other Updates
### Graduated to Stable
* [Bound Service Account Token Volumes](https://github.com/kubernetes/enhancements/issues/542)
* [CSI Service Account Token](https://github.com/kubernetes/enhancements/issues/2047)
* [Windows Support for CSI Plugins](https://github.com/kubernetes/enhancements/issues/1122)
* [Warning mechanism for deprecated API use](https://github.com/kubernetes/enhancements/issues/1693)
* [PodDisruptionBudget Eviction](https://github.com/kubernetes/enhancements/issues/85)
### Notable Feature Updates
* A new [PodSecurity admission](https://github.com/kubernetes/enhancements/issues/2579) alpha feature is introduced, intended as a replacement for PodSecurityPolicy
* [The Memory Manager](https://github.com/kubernetes/enhancements/issues/1769) moves to beta
* A new alpha feature to enable [API Server Tracing](https://github.com/kubernetes/enhancements/issues/647)
* A new v1beta3 version of the [kubeadm configuration](https://github.com/kubernetes/enhancements/issues/970) format
* [Generic data populators](https://github.com/kubernetes/enhancements/issues/1495) for PersistentVolumes are now available in alpha
* The Kubernetes control plane will now always use the [CronJobs v2 controller](https://github.com/kubernetes/enhancements/issues/19)
* As an alpha feature, all Kubernetes node components (including the kubelet, kube-proxy, and container runtime) can be [run as a non-root user](https://github.com/kubernetes/enhancements/issues/2033)
# Release notes
You can check out the full details of the 1.22 release in the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md).
# Availability of release
Kubernetes 1.22 is [available for download](https://kubernetes.io/releases/download/) and also [on the GitHub project](https://github.com/kubernetes/kubernetes/releases/tag/v1.22.0).
There are some great resources out there for getting started with Kubernetes. You can check out some [interactive tutorials](https://kubernetes.io/docs/tutorials/) on the main Kubernetes site, or run a local cluster on your machine using Docker containers with [kind](https://kind.sigs.k8s.io). If youd like to try building a cluster from scratch, check out the [Kubernetes the Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way) tutorial by Kelsey Hightower.
# Release Team
This release was made possible by a very dedicated group of individuals, who came together as a team to deliver technical content, documentation, code, and a host of other components that go into every Kubernetes release.
A huge thank you to the release lead Savitha Raghunathan for leading us through a successful release cycle, and to everyone else on the release team for supporting each other, and working so hard to deliver the 1.22 release for the community.
We would also like to take this opportunity to remember Peeyush Gupta, a member of our team that we lost earlier this year. Peeyush was actively involved in SIG ContribEx and the Kubernetes Release Team, most recently serving as the 1.22 Communications lead. His contributions and efforts will continue to reflect in the community he helped build. A [CNCF memorial](https://github.com/cncf/memorials/blob/main/peeyush-gupta.md) page has been created where thoughts and memories can be shared by the community.
# Release Logo
![Kubernetes 1.22 Release Logo](/images/blog/2021-08-04-kubernetes-release-1.22/kubernetes-1.22.png)
Amidst the ongoing pandemic, natural disasters, and ever-present shadow of burnout, the 1.22 release of Kubernetes includes 53 enhancements. This makes it the largest release to date. This accomplishment was only made possible due to the hard-working and passionate Release Team members and the amazing contributors of the Kubernetes ecosystem. The release logo is our reminder to keep reaching for new milestones and setting new records. And it is dedicated to all the Release Team members, hikers, and stargazers!
The logo is designed by [Boris Zotkin](https://www.instagram.com/boris.z.man/). Boris is a Mac/Linux Administrator at the MathWorks. He enjoys simple things in life and loves spending time with his family. This tech-savvy individual is always up for a challenge and happy to help a friend!
# User Highlights
- In May, the CNCF welcomed 27 new organizations across the globe as members of the diverse cloud native ecosystem. These new [members](https://www.cncf.io/announcements/2021/05/05/27-new-members-join-the-cloud-native-computing-foundation/) will participate in CNCF events, including the upcoming [KubeCon + CloudNativeCon NA in Los Angeles](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/) from October 12 15, 2021.
- The CNCF granted Spotify the [Top End User Award](https://www.cncf.io/announcements/2021/05/05/cloud-native-computing-foundation-grants-spotify-the-top-end-user-award/) during [KubeCon + CloudNativeCon EU Virtual 2021](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/).
# Project Velocity
The [CNCF K8s DevStats project](https://k8s.devstats.cncf.io/) aggregates a number of interesting data points related to the velocity of Kubernetes and various sub-projects. This includes everything from individual contributions to the number of companies that are contributing, and is an illustration of the depth and breadth of effort that goes into evolving this ecosystem.
In the v1.22 release cycle, which ran for 15 weeks (April 26 to August 4), we saw contributions from [1063 companies](https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1&var-period_name=v1.21.0%20-%20now&var-metric=contributions) and [2054 individuals](https://k8s.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=v1.21.0%20-%20now&var-metric=contributions&var-repogroup_name=Kubernetes&var-country_name=All&var-companies=All).
# Ecosystem Updates
- [KubeCon + CloudNativeCon Europe 2021](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) was held in May, the third such event to be virtual. All talks are [now available on-demand](https://www.youtube.com/playlist?list=PLj6h78yzYM2MqBm19mRz9SYLsw4kfQBrC) for anyone that would like to catch up!
- [Spring Term LFX Program](https://www.cncf.io/blog/2021/07/13/spring-term-lfx-program-largest-graduating-class-with-28-successful-cncf-interns) had the largest graduating class with 28 successful CNCF interns!
- CNCF launched [livestreaming on Twitch](https://www.cncf.io/blog/2021/06/03/cloud-native-community-goes-live-with-10-shows-on-twitch/) at the beginning of the year targeting definitive interactive media experience for anyone wanting to learn, grow, and collaborate with others in the Cloud Native community from anywhere in the world.
# Event Updates
- [KubeCon + CloudNativeCon North America 2021](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/) will take place in Los Angeles, October 12 15, 2021! You can find more information about the conference and registration on the event site.
- [Kubernetes Community Days](https://community.cncf.io/kubernetes-community-days/about-kcd/) has upcoming events scheduled in Italy, the UK, and in Washington DC.
# Upcoming release webinar
Join members of the Kubernetes 1.22 release team on October 5, 2021 to learn about the major features of this release, as well as deprecations and removals to help plan for upgrades. For more information and registration, visit the [event page](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kubernetes-122-release/) on the CNCF Online Programs site.
# Get Involved
If youre interested in contributing to the Kubernetes community, Special Interest Groups (SIGs) are a great starting point. Many of them may align with your interests! If there are things youd like to share with the community, you can join the weekly community meeting, or use any of the following channels:
* Find out more about contributing to Kubernetes at the [Kubernetes Contributors](https://www.kubernetes.dev/) website.
* Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
* Join the community discussion on [Discuss](https://discuss.kubernetes.io/)
* Join the community on [Slack](http://slack.k8s.io/)
* Share your Kubernetes [story](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
* Read more about whats happening with Kubernetes on the [blog](https://kubernetes.io/blog/)
* Learn more about the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team)
@@ -1,177 +0,0 @@
---
layout: blog
title: "Kubernetes 1.22: Server Side Apply moves to GA"
date: 2021-08-06
slug: server-side-apply-ga
---
**Authors:** Jeffrey Ying, Google & Joe Betz, Google
Server-side Apply (SSA) has been promoted to GA in the Kubernetes v1.22 release. The GA milestone means you can depend on the feature and its API, without fear of future backwards-incompatible changes. GA features are protected by the Kubernetes [deprecation policy](/docs/reference/using-api/deprecation-policy/).
## What is Server-side Apply?
Server-side Apply helps users and controllers manage their resources through declarative configurations. Server-side Apply replaces the client side apply feature implemented by “kubectl apply” with a server-side implementation, permitting use by tools/clients other than kubectl. Server-side Apply is a new merging algorithm, as well as tracking of field ownership, running on the Kubernetes api-server. Server-side Apply enables new features like conflict detection, so the system knows when two actors are trying to edit the same field. Refer to the [Server-side Apply Documentation](/docs/reference/using-api/server-side-apply/) and [Beta 2 release announcement](https://kubernetes.io/blog/2020/04/01/kubernetes-1.18-feature-server-side-apply-beta-2/) for more information.
## Whats new since Beta?
Since the [Beta 2 release](https://kubernetes.io/blog/2020/04/01/kubernetes-1.18-feature-server-side-apply-beta-2/) subresources support has been added, and both client-go and Kubebuilder have added comprehensive support for Server-side Apply. This completes the Server-side Apply functionality required to make controller development practical.
### Support for subresources
Server-side Apply now fully supports subresources like `status` and `scale`. This is particularly important for [controllers](/docs/concepts/architecture/controller/), which are often responsible for writing to subresources.
## Server-side Apply support in client-go
Previously, Server-side Apply could only be called from the client-go typed client using the `Patch` function, with `PatchType` set to `ApplyPatchType`. Now, `Apply` functions are included in the client to allow for a more direct and typesafe way of calling Server-side Apply. Each `Apply` function takes an "apply configuration" type as an argument, which is a structured representation of an Apply request. For example:
```go
import (
...
v1ac "k8s.io/client-go/applyconfigurations/autoscaling/v1"
)
hpaApplyConfig := v1ac.HorizontalPodAutoscaler(autoscalerName, ns).
WithSpec(v1ac.HorizontalPodAutoscalerSpec().
WithMinReplicas(0)
)
return hpav1client.Apply(ctx, hpaApplyConfig, metav1.ApplyOptions{FieldManager: "mycontroller", Force: true})
```
Note in this example that `HorizontalPodAutoscaler` is imported from an "applyconfigurations" package. Each "apply configuration" type represents the same Kubernetes object kind as the corresponding go struct, but where all fields are pointers to make them optional, allowing apply requests to be accurately represented. For example, when the apply configuration in the above example is marshalled to YAML, it produces:
```yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: myHPA
namespace: myNamespace
spec:
minReplicas: 0
```
To understand why this is needed, the above YAML cannot be produced by the v1.HorizontalPodAutoscaler go struct. Take for example:
```go
hpa := v1.HorizontalPodAutoscaler{
TypeMeta: metav1.TypeMeta{
APIVersion: "autoscaling/v1",
Kind: "HorizontalPodAutoscaler",
},
ObjectMeta: ObjectMeta{
Namespace: ns,
Name: autoscalerName,
},
Spec: v1.HorizontalPodAutoscalerSpec{
MinReplicas: pointer.Int32Ptr(0),
},
}
```
The above code attempts to declare the same apply configuration as shown in the previous examples, but when marshalled to YAML, produces:
```yaml
kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v1
metadata
name: myHPA
namespace: myNamespace
creationTimestamp: null
spec:
scaleTargetRef:
kind: ""
name: ""
minReplicas: 0
maxReplicas: 0
```
Which, among other things, contains `spec.maxReplicas` set to `0`. This is almost certainly not what the caller intended (the intended apply configuration says nothing about the `maxReplicas` field), and could have serious consequences on a production system: it directs the autoscaler to downscale to zero pods. The problem here originates from the fact that the go structs contain required fields that are zero valued if not set explicitly. The go structs work as intended for create and update operations, but are fundamentally incompatible with apply, which is why we have introduced the generated "apply configuration" types.
The "apply configurations" also have convenience `With<FieldName>` functions that make it easier to build apply requests. This allows developers to set fields without having to deal with the fact that all the fields in the "apply configuration" types are pointers, and are inconvenient to set using go. For example `MinReplicas: &0` is not legal go code, so without the `With` functions, developers would work around this problem by using a library, e.g. `MinReplicas: pointer.Int32Ptr(0)`, but string enumerations like `corev1.Protocol` are still a problem since they cannot be supported by a general purpose library. In addition to the convenience, the `With` functions also isolate developers from the underlying representation, which makes it safer for the underlying representation to be changed to support additional features in the future.
## Using Server-side Apply in a controller
You can use the new support for Server-side Apply no matter how you implemented your controller. However, the new client-go support makes it easier to use Server-side Apply in controllers.
When authoring new controllers to use Server-side Apply, a good approach is to have the controller recreate the apply configuration for an object each time it reconciles that object. This ensures that the controller fully reconciles all the fields that it is responsible for. Controllers typically should unconditionally set all the fields they own by setting `Force: true` in the `ApplyOptions`. Controllers must also provide a `FieldManager` name that is unique to the reconciliation loop that apply is called from.
When upgrading existing controllers to use Server-side Apply the same approach often works well--migrate the controllers to recreate the apply configuration each time it reconciles any object. Unfortunately, the controller might have multiple code paths that update different parts of an object depending on various conditions. Migrating a controller like this to Server-side Apply can be risky because if the controller forgets to include any fields in an apply configuration that is included in a previous apply request, a field can be accidently deleted. To ease this type of migration, client-go apply support provides a way to replace any controller reconciliation code that performs a "read/modify-in-place/update" (or patch) workflow with a "extract/modify-in-place/apply" workflow. Here's an example of the new workflow:
```go
fieldMgr := "my-field-manager"
deploymentClient := clientset.AppsV1().Deployments("default")
// read, could also be read from a shared informer
deployment, err := deploymentClient.Get(ctx, "example-deployment", metav1.GetOptions{})
if err != nil {
// handle error
}
// extract
deploymentApplyConfig, err := appsv1ac.ExtractDeployment(deployment, fieldMgr)
if err != nil {
// handle error
}
// modify-in-place
deploymentApplyConfig.Spec.Template.Spec.WithContainers(corev1ac.Container().
WithName("modify-slice").
WithImage("nginx:1.14.2"),
)
// apply
applied, err := deploymentClient.Apply(ctx, deploymentApplyConfig, metav1.ApplyOptions{FieldManager: fieldMgr})
```
For developers using Custom Resource Definitions (CRDs), the Kubebuilder apply support will provide the same capabilities. Documentation will be included in the Kubebuilder book when available.
## Server-side Apply and CustomResourceDefinitions
It is strongly recommended that all [Custom Resource Definitions](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) (CRDs) have a schema. CRDs without a schema are treated as unstructured data by Server-side Apply. Keys are treated as fields in a struct and lists are assumed to be atomic.
CRDs that specify a schema are able to specify additional annotations in the schema. Please refer to the documentation on the full list of available annotations.
New annotations since beta:
**Defaulting:** Values for fields that appliers do not express explicit interest in should be defaulted. This prevents an applier from unintentionally owning a defaulted field that might cause conflicts with other appliers. If unspecified, the default value is nil or the nil equivalent for the corresponding type.
- Usage: see the [CRD Defaulting](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting) documentation for more details.
- Golang: `+default=<value>`
- OpenAPI extension: `default: <value>`
Atomic for maps and structs:
**Maps:** By default maps are granular. A different manager is able to manage each map entry. They can also be configured to be atomic such that a single manager owns the entire map.
- Usage: Refer to [Merge Strategy](/docs/reference/using-api/server-side-apply/#merge-strategy) for a more detailed overview
- Golang: `+mapType=granular/atomic`
- OpenAPI extension: `x-kubernetes-map-type: granular/atomic`
**Structs:** By default structs are granular and a separate applier may own each field. For certain kinds of structs, atomicity may be desired. This is most commonly seen in small coordinate-like structs such as Field/Object/Namespace Selectors, Object References, RGB values, Endpoints (Protocol/Port pairs), etc.
- Usage: Refer to [Merge Strategy](/docs/reference/using-api/server-side-apply/#merge-strategy) for a more detailed overview
- Golang: `+structType=granular/atomic`
- OpenAPI extension: `x-kubernetes-map-type:atomic/granular`
## What's Next?
After Server Side Apply, the next focus for the API Expression working-group is around improving the expressiveness and size of the published Kubernetes API schema. To see the full list of items we are working on, please join our working group and refer to the work items document.
## How to get involved?
The working-group for apply is [wg-api-expression](https://github.com/kubernetes/community/tree/master/wg-api-expression). It is available on slack [#wg-api-expression](https://kubernetes.slack.com/archives/C0123CNN8F3), through the [mailing list](https://groups.google.com/g/kubernetes-wg-api-expression) and we also meet every other Tuesday at 9.30 PT on Zoom.
We would also like to use the opportunity to thank the hard work of all the contributors involved in making this promotion to GA possible:
- Andrea Nodari
- Antoine Pelisse
- Daniel Smith
- Jeffrey Ying
- Jenny Buckley
- Joe Betz
- Julian Modesto
- Kevin Delgado
- Kevin Wiesmüller
- Maria Ntalla
@@ -1,142 +0,0 @@
---
layout: blog
title: 'New in Kubernetes v1.22: alpha support for using swap memory'
date: 2021-08-09
slug: run-nodes-with-swap-alpha
---
**Author:** Elana Hashman (Red Hat)
The 1.22 release introduced alpha support for configuring swap memory usage for
Kubernetes workloads on a per-node basis.
In prior releases, Kubernetes did not support the use of swap memory on Linux,
as it is difficult to provide guarantees and account for pod memory utilization
when swap is involved. As part of Kubernetes' earlier design, swap support was
considered out of scope, and a kubelet would by default fail to start if swap
was detected on a node.
However, there are a number of [use cases](https://github.com/kubernetes/enhancements/blob/9d127347773ad19894ca488ee04f1cd3af5774fc/keps/sig-node/2400-node-swap/README.md#user-stories)
that would benefit from Kubernetes nodes supporting swap, including improved
node stability, better support for applications with high memory overhead but
smaller working sets, the use of memory-constrained devices, and memory
flexibility.
Hence, over the past two releases, [SIG Node](https://github.com/kubernetes/community/tree/master/sig-node#readme) has
been working to gather appropriate use cases and feedback, and propose a design
for adding swap support to nodes in a controlled, predictable manner so that
Kubernetes users can perform testing and provide data to continue building
cluster capabilities on top of swap. The alpha graduation of swap memory
support for nodes is our first milestone towards this goal!
## How does it work?
There are a number of possible ways that one could envision swap use on a node.
To keep the scope manageable for this initial implementation, when swap is
already provisioned and available on a node, [we have proposed](https://github.com/kubernetes/enhancements/blob/9d127347773ad19894ca488ee04f1cd3af5774fc/keps/sig-node/2400-node-swap/README.md#proposal)
the kubelet should be able to be configured such that:
- It can start with swap on.
- It will direct the Container Runtime Interface to allocate zero swap memory
to Kubernetes workloads by default.
- You can configure the kubelet to specify swap utilization for the entire
node.
Swap configuration on a node is exposed to a cluster admin via the
[`memorySwap` in the KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/).
As a cluster administrator, you can specify the node's behaviour in the
presence of swap memory by setting `memorySwap.swapBehavior`.
This is possible through the addition of a `memory_swap_limit_in_bytes` field
to the container runtime interface (CRI). The kubelet's config will control how
much swap memory the kubelet instructs the container runtime to allocate to
each container via the CRI. The container runtime will then write the swap
settings to the container level cgroup.
## How do I use it?
On a node where swap memory is already provisioned, Kubernetes use of swap on a
node can be enabled by enabling the `NodeSwap` feature gate on the kubelet, and
disabling the `failSwapOn` [configuration setting](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
or the `--fail-swap-on` command line flag.
You can also optionally configure `memorySwap.swapBehavior` in order to
specify how a node will use swap memory. For example,
```yaml
memorySwap:
swapBehavior: LimitedSwap
```
The available configuration options for `swapBehavior` are:
- `LimitedSwap` (default): Kubernetes workloads are limited in how much swap
they can use. Workloads on the node not managed by Kubernetes can still swap.
- `UnlimitedSwap`: Kubernetes workloads can use as much swap memory as they
request, up to the system limit.
If configuration for `memorySwap` is not specified and the feature gate is
enabled, by default the kubelet will apply the same behaviour as the
`LimitedSwap` setting.
The behaviour of the `LimitedSwap` setting depends if the node is running with
v1 or v2 of control groups (also known as "cgroups"):
- **cgroups v1:** Kubernetes workloads can use any combination of memory and
swap, up to the pod's memory limit, if set.
- **cgroups v2:** Kubernetes workloads cannot use swap memory.
### Caveats
Having swap available on a system reduces predictability. Swap's performance is
worse than regular memory, sometimes by many orders of magnitude, which can
cause unexpected performance regressions. Furthermore, swap changes a system's
behaviour under memory pressure, and applications cannot directly control what
portions of their memory usage are swapped out. Since enabling swap permits
greater memory usage for workloads in Kubernetes that cannot be predictably
accounted for, it also increases the risk of noisy neighbours and unexpected
packing configurations, as the scheduler cannot account for swap memory usage.
The performance of a node with swap memory enabled depends on the underlying
physical storage. When swap memory is in use, performance will be significantly
worse in an I/O operations per second (IOPS) constrained environment, such as a
cloud VM with I/O throttling, when compared to faster storage mediums like
solid-state drives or NVMe.
Hence, we do not recommend the use of swap for certain performance-constrained
workloads or environments. Cluster administrators and developers should
benchmark their nodes and applications before using swap in production
scenarios, and [we need your help](#how-do-i-get-involved) with that!
## Looking ahead
The Kubernetes 1.22 release introduces alpha support for swap memory on nodes,
and we will continue to work towards beta graduation in the 1.23 release. This
will include:
* Adding support for controlling swap consumption at the Pod level via cgroups.
* This will include the ability to set a system-reserved quantity of swap
from what kubelet detects on the host.
* Determining a set of metrics for node QoS in order to evaluate the
performance and stability of nodes with and without swap enabled.
* Collecting feedback from test user cases.
* We will consider introducing new configuration modes for swap, such as a
node-wide swap limit for workloads.
## How can I learn more?
You can review the current [documentation](https://kubernetes.io/docs/concepts/architecture/nodes/#swap-memory)
on the Kubernetes website.
For more information, and to assist with testing and provide feedback, please
see [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) and its
[design proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md).
## How do I get involved?
Your feedback is always welcome! SIG Node [meets regularly](https://github.com/kubernetes/community/tree/master/sig-node#meetings)
and [can be reached](https://github.com/kubernetes/community/tree/master/sig-node#contact)
via [Slack](https://slack.k8s.io/) (channel **#sig-node**), or the SIG's
[mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-node).
Feel free to reach out to me, Elana Hashman (**@ehashman** on Slack and GitHub)
if you'd like to help.

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