diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 785257142d..88d163d67c 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -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, “master”, if you're documenting existing + Use the default base branch, “main”, if you're documenting existing features in the English localization. If you're working on a different localization (not English), see diff --git a/.gitignore b/.gitignore index 51e94f41b4..6a629010d0 100644 --- a/.gitignore +++ b/.gitignore @@ -33,4 +33,8 @@ resources/ # Netlify Functions build output package-lock.json functions/ -node_modules/ \ No newline at end of file +node_modules/ + +# Generated files when building with make container-build +.config/ +.npm/ diff --git a/Makefile b/Makefile index 12b6f67d5a..a103f4e58e 100644 --- a/Makefile +++ b/Makefile @@ -6,8 +6,9 @@ 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 = kubernetes-hugo:v$(HUGO_VERSION)-$(IMAGE_VERSION) +CONTAINER_IMAGE = $(IMAGE_REGISTRY)/k8s-website-hugo:v$(HUGO_VERSION)-$(IMAGE_VERSION) CONTAINER_RUN = $(CONTAINER_ENGINE) run --rm --interactive --tty --volume $(CURDIR):/src CCRED=\033[0;31m @@ -19,7 +20,11 @@ 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 '/^[+-]/ {printf "\033[31mWARNING\033[0m Submodule not initialized: \033[34m%s\033[0m\n",$$2}' 1>&2 + @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 all: build ## Build site with production settings and put deliverables in ./public @@ -68,7 +73,7 @@ container-build: module-check $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify" container-serve: module-check ## Boot the development server using container. Run `make container-image` before this. - $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir + $(CONTAINER_RUN) --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 $(CONTAINER_IMAGE) hugo server --buildFuture --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir test-examples: scripts/test_examples.sh install @@ -91,4 +96,4 @@ clean-api-reference: ## Clean all directories in API reference directory, preser api-reference: clean-api-reference ## Build the API reference pages. go needed cd api-ref-generator/gen-resourcesdocs && \ - go run cmd/main.go kwebsite --config-dir config/v1.20/ --file api/v1.20/swagger.json --output-dir ../../content/en/docs/reference/kubernetes-api --templates templates + 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 diff --git a/OWNERS b/OWNERS index f352793ec1..8e4e14f60c 100644 --- a/OWNERS +++ b/OWNERS @@ -8,10 +8,12 @@ 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 +# - zacharysarah, commented out to disable PR assignments labels: - sig/docs diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index c31b04d5b0..ce45f0e787 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -1,13 +1,8 @@ aliases: sig-docs-blog-owners: # Approvers for blog content - - castrojo - - kbarnard10 - onlydole - - zacharysarah - mrbobbytables sig-docs-blog-reviewers: # Reviewers for blog content - - castrojo - - kbarnard10 - mrbobbytables - onlydole - sftim @@ -23,38 +18,30 @@ aliases: - annajung - bradtopol - celestehorgan - - irvifa - jimangel - - kbarnard10 + - jlbutler - kbhawkey - onlydole + - pi-victor - reylejano - savitharaghunathan - sftim - - steveperry-53 - tengqm - - zacharysarah - - zparnold sig-docs-en-reviews: # PR reviews for English content - bradtopol - celestehorgan - daminisatya - jimangel - - kbarnard10 - kbhawkey - onlydole - rajeshdeshpande02 - sftim - - steveperry-53 - tengqm - - zparnold sig-docs-es-owners: # Admins for Spanish content - raelga - - alexbrand + - electrocucaracha sig-docs-es-reviews: # PR reviews for Spanish content - raelga - - alexbrand - # glo-pena - electrocucaracha sig-docs-fr-owners: # Admins for French content - remyleone @@ -85,19 +72,18 @@ aliases: - anthonydahanne - feloy sig-docs-hi-owners: # Admins for Hindi content - - avidLearnerInProgress - - daminisatya + - anubha-v-ardhan + - divya-mohan0209 - mittalyashu sig-docs-hi-reviews: # PR reviews for Hindi content - - avidLearnerInProgress - - daminisatya + - anubha-v-ardhan + - divya-mohan0209 - mittalyashu sig-docs-id-owners: # Admins for Indonesian content - ariscahyadi - danninov - girikuncoro - habibrosyad - - irvifa - phanama - wahyuoi sig-docs-id-reviews: # PR reviews for Indonesian content @@ -105,7 +91,6 @@ aliases: - danninov - girikuncoro - habibrosyad - - irvifa - phanama - wahyuoi sig-docs-it-owners: # Admins for Italian content @@ -141,14 +126,14 @@ aliases: - ClaudiaJKang - gochist - ianychoi - - seokho-son - - ysyukr + - jihoon-seo + - jmyung - pjhwa + - seokho-son - yoonian + - ysyukr sig-docs-leads: # Website chairs and tech leads - - irvifa - jimangel - - kbarnard10 - kbhawkey - onlydole - sftim @@ -166,8 +151,10 @@ aliases: # zhangxiaoyu-zidif sig-docs-zh-reviews: # PR reviews for Chinese content - chenrui333 + - chenxuc - howieyuen - idealhack + - mengjiao-liu - pigletfly - SataQiu - tanjunchen @@ -236,3 +223,30 @@ aliases: - mrbobbytables - nikhita - parispittman + # 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 + - hasheddan # subproject owner / Release Manager + - puerco # Release Manager + - saschagrunert # subproject owner / Release Manager + - justaugustus # subproject owner / Release Manager + - xmudrii # Release Manager + release-engineering-reviewers: + - ameukam # Release Manager Associate + - jimangel # Release Manager Associate + - markyjackson-taulia # Release Manager Associate + - mkorbi # Release Manager Associate + - palnabarun # Release Manager Associate + - onlydole # Release Manager Associate + - sethmccombs # Release Manager Associate + - thejoycekung # Release Manager Associate + - verolop # Release Manager Associate + - wilsonehusin # Release Manager Associate diff --git a/README-de.md b/README-de.md index b570f43671..c901fdde65 100644 --- a/README-de.md +++ b/README-de.md @@ -9,7 +9,7 @@ Herzlich willkommen! Dieses Repository enthält alle Assets, die zur Erstellung Sie können auf die Schaltfläche **Fork** im oberen rechten Bereich des Bildschirms klicken, um eine Kopie dieses Repositorys in Ihrem GitHub-Konto zu erstellen. Diese Kopie wird als *Fork* bezeichnet. Nehmen Sie die gewünschten Änderungen an Ihrem Fork vor. Wenn Sie bereit sind, diese Änderungen an uns zu senden, gehen Sie zu Ihrem Fork und erstellen Sie eine neue Pull-Anforderung, um uns darüber zu informieren. -Sobald Ihre Pull-Anfrage erstellt wurde, übernimmt ein Rezensent von Kubernetes die Verantwortung für klares, umsetzbares Feedback. Als Eigentümer des Pull-Request **liegt es in Ihrer Verantwortung Ihren Pull-Reqest enstsprechend des Feedbacks, dass Sie vom Kubernetes-Reviewer erhalten haben abzuändern.** Beachten Sie auch, dass Sie am Ende mehr als einen Rezensenten von Kubernetes erhalten, der Ihnen Feedback gibt, oder dass Sie Rückmeldungen von einem Rezensenten von Kubernetes erhalten, der sich von demjenigen unterscheidet, der ursprünglich für das Feedback zugewiesen wurde. In einigen Fällen kann es vorkommen, dass einer Ihrer Prüfer bei Bedarf eine technische Überprüfung von einem [Kubernetes Tech-Reviewer](https://github.com/kubernetes/website/wiki/tech-reviewers) anfordert. Reviewer geben ihr Bestes, um zeitnah Feedback zu geben, die Antwortzeiten können jedoch je nach den Umständen variieren. +Sobald Ihre Pull-Anfrage erstellt wurde, übernimmt ein Rezensent von Kubernetes die Verantwortung für klares, umsetzbares Feedback. Als Eigentümer des Pull-Request **liegt es in Ihrer Verantwortung Ihren Pull-Reqest entsprechend des Feedbacks, dass Sie vom Kubernetes-Reviewer erhalten haben abzuändern.** Beachten Sie auch, dass Sie am Ende mehr als einen Rezensenten von Kubernetes erhalten, der Ihnen Feedback gibt, oder dass Sie Rückmeldungen von einem Rezensenten von Kubernetes erhalten, der sich von demjenigen unterscheidet, der ursprünglich für das Feedback zugewiesen wurde. In einigen Fällen kann es vorkommen, dass einer Ihrer Prüfer bei Bedarf eine technische Überprüfung von einem [Kubernetes Tech-Reviewer](https://github.com/kubernetes/website/wiki/tech-reviewers) anfordert. Reviewer geben ihr Bestes, um zeitnah Feedback zu geben, die Antwortzeiten können jedoch je nach den Umständen variieren. Weitere Informationen zum Beitrag zur Kubernetes-Dokumentation finden Sie unter: @@ -37,6 +37,13 @@ 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 @@ -55,9 +62,18 @@ 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 ``` diff --git a/README-hi.md b/README-hi.md index 01d119a22b..1c7c0bfc1f 100644 --- a/README-hi.md +++ b/README-hi.md @@ -7,7 +7,7 @@ ## डॉक्स में योगदान देना -आप अपने GitHub खाते में इस रिपॉजिटरी की एक copy बनाने के लिए स्क्रीन के ऊपरी-दाएँ क्षेत्र में **Fork** बटन पर क्लिक करें। इस copy को *Fork* कहा जाता है। अपने fork में कोई भी परिवर्तन करना चाहते हैं, और जब आप उन परिवर्तनों को हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं। +आप अपने GitHub खाते में इस रिपॉजिटरी की एक copy बनाने के लिए स्क्रीन के ऊपरी-दाएँ क्षेत्र में **Fork** बटन पर क्लिक करें। इस copy को *Fork* कहा जाता है। अपने fork में परिवर्तन करने के बाद जब आप उनको हमारे पास भेजने के लिए तैयार हों, तो अपने fork पर जाएं और हमें इसके बारे में बताने के लिए एक नया pull request बनाएं। एक बार जब आपका pull request बन जाता है, तो एक कुबरनेट्स समीक्षक स्पष्ट, कार्रवाई योग्य प्रतिक्रिया प्रदान करने की जिम्मेदारी लेगा। pull request के मालिक के रूप में, **यह आपकी जिम्मेदारी है कि आप कुबरनेट्स समीक्षक द्वारा प्रदान की गई प्रतिक्रिया को संबोधित करने के लिए अपने pull request को संशोधित करें।** diff --git a/README-ja.md b/README-ja.md index 49d0dd1bad..91e624c610 100644 --- a/README-ja.md +++ b/README-ja.md @@ -1,6 +1,6 @@ # Kubernetesのドキュメント -[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-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-main-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/)をビルドするために必要な全アセットが格納されています。貢献に興味を持っていただきありがとうございます！ diff --git a/README-ko.md b/README-ko.md index c4038212c6..c3e1068b2e 100644 --- a/README-ko.md +++ b/README-ko.md @@ -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-master-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-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) 이 저장소에는 [쿠버네티스 웹사이트 및 문서](https://kubernetes.io/)를 빌드하는 데 필요한 자산이 포함되어 있습니다. 기여해주셔서 감사합니다! diff --git a/README-pl.md b/README-pl.md index 7d89d518cb..06bde04303 100644 --- a/README-pl.md +++ b/README-pl.md @@ -1,90 +1,154 @@ # Dokumentacja projektu Kubernetes -[![Build Status](https://api.travis-ci.org/kubernetes/website.svg?branch=master)](https://travis-ci.org/kubernetes/website) -[![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) - -Witamy! +[![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) W tym repozytorium znajdziesz wszystko, czego potrzebujesz do zbudowania [strony internetowej Kubernetesa wraz z dokumentacją](https://kubernetes.io/). Bardzo nam miło, że chcesz wziąć udział w jej współtworzeniu! -## Twój wkład w dokumentację ++ [Twój wkład w dokumentację](#twój-wkład-w-dokumentację) ++ [Informacje o wersjach językowych](#informacje-o-wersjach-językowych) -Możesz kliknąć w przycisk **Fork** w prawym górnym rogu ekranu, aby stworzyć kopię tego repozytorium na swoim koncie GitHub. Taki rodzaj kopii (odgałęzienia) nazywa się *fork*. Zmieniaj w nim, co chcesz, a kiedy będziesz już gotowy/a przesłać te zmiany do nas, przejdź do swojej kopii i stwórz nowy *pull request*, abyśmy zostali o tym poinformowani. +# Jak używać tego repozytorium -Po stworzeniu *pull request*, jeden z recenzentów projektu Kubernetes podejmie się przekazania jasnych wskazówek pozwalających podjąć następne działania. Na Tobie, jako właścicielu *pull requesta*, **spoczywa odpowiedzialność za wprowadzenie poprawek zgodnie z uwagami recenzenta.** Może też się zdarzyć, że swoje uwagi zgłosi więcej niż jeden recenzent, lub że recenzję będzie robił ktoś inny, niż ten, kto został przydzielony na początku. W niektórych przypadkach, jeśli zajdzie taka potrzeba, recenzent może poprosić dodatkowo o recenzję jednego z [recenzentów technicznych](https://github.com/kubernetes/website/wiki/Tech-reviewers). Recenzenci zrobią wszystko, aby odpowiedzieć sprawnie, ale konkretny czas odpowiedzi zależy od wielu czynników. +Możesz uruchomić serwis lokalnie poprzez Hugo (Extended version) lub ze środowiska kontenerowego. Zdecydowanie zalecamy korzystanie z kontenerów, bo dzięki temu lokalna wersja będzie spójna z tym, co jest na oficjalnej stronie. -Więcej informacji na temat współpracy przy tworzeniu dokumentacji znajdziesz na stronach: +## Wymagania wstępne -* [Jak rozpocząć współpracę](https://kubernetes.io/docs/contribute/start/) -* [Podgląd wprowadzanych zmian w dokumentacji](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally) -* [Szablony stron](https://kubernetes.io/docs/contribute/style/page-content-types/) -* [Styl pisania dokumentacji](http://kubernetes.io/docs/contribute/style/style-guide/) -* [Lokalizacja dokumentacji Kubernetes](https://kubernetes.io/docs/contribute/localization/) +Aby móc skorzystać z tego repozytorium, musisz lokalnie zainstalować: -## Różne wersje językowe `README.md` +- [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/). -| | | -|----------------------------------------|----------------------------------------| -| [README po angielsku](README.md) | [README po francusku](README-fr.md) | -| [README po koreańsku](README-ko.md) | [README po niemiecku](README-de.md) | -| [README po portugalsku](README-pt.md) | [README w hindi](README-hi.md) | -| [README po hiszpańsku](README-es.md) | [README po indonezyjsku](README-id.md) | -| [README po chińsku](README-zh.md) | [README po japońsku](README-ja.md) | -| [README po wietnamsku](README-vi.md) | [README po rosyjsku](README-ru.md) | -| [README po włosku](README-it.md) | [README po ukraińsku](README-uk.md) | -| | | +Przed rozpoczęciem zainstaluj niezbędne zależności. Sklonuj repozytorium i przejdź do odpowiedniego katalogu: -## Jak uruchomić lokalną kopię strony przy pomocy Dockera? - -Zalecaną metodą uruchomienia serwisu internetowego Kubernetesa lokalnie jest użycie specjalnego obrazu [Dockera](https://docker.com), który zawiera generator stron statycznych [Hugo](https://gohugo.io). - -> Użytkownicy Windows będą potrzebowali dodatkowych narzędzi, które mogą zainstalować przy pomocy [Chocolatey](https://chocolatey.org). - -```bash -choco install make +``` +git clone https://github.com/kubernetes/website.git +cd website ``` -> Jeśli wolisz uruchomić serwis lokalnie bez Dockera, przeczytaj [jak uruchomić serwis lokalnie przy pomocy Hugo](#jak-uruchomić-lokalną-kopię-strony-przy-pomocy-hugo) poniżej. +Strona Kubernetesa używa [Docsy Hugo theme](https://github.com/google/docsy#readme). Nawet jeśli planujesz uruchomić serwis w środowisku kontenerowym, zalecamy pobranie podmodułów i innych zależności za pomocą polecenia: -Jeśli [zainstalowałeś i uruchomiłeś](https://www.docker.com/get-started) już Dockera, zbuduj obraz `kubernetes-hugo` lokalnie: +``` +# pull in the Docsy submodule +git submodule update --init --recursive --depth 1 +``` -```bash +## Uruchomienie serwisu w kontenerze + +Aby zbudować i uruchomić serwis wewnątrz środowiska kontenerowego, wykonaj następujące polecenia: + +``` make container-image -``` - -Po zbudowaniu obrazu, możesz uruchomić serwis lokalnie: - -```bash make container-serve ``` -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. +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. ## Jak uruchomić lokalną kopię strony przy pomocy Hugo? -Zajrzyj do [oficjalnej dokumentacji Hugo](https://gohugo.io/getting-started/installing/) po instrukcję instalacji. Upewnij się, że instalujesz rozszerzoną wersję Hugo, określoną przez zmienną środowiskową `HUGO_VERSION` w pliku [`netlify.toml`](netlify.toml#L9). +Upewnij się, że zainstalowałeś odpowiednią wersję Hugo "extended", określoną przez zmienną środowiskową `HUGO_VERSION` w pliku [`netlify.toml`](netlify.toml#L10). -Aby uruchomić serwis lokalnie po instalacji Hugo, napisz: +Aby uruchomić i przetestować serwis lokalnie, wykonaj: ```bash +# install dependencies +npm ci make serve ``` Zostanie uruchomiony lokalny serwer Hugo na porcie 1313. Otwórz w przeglądarce adres http://localhost:1313, aby obejrzeć zawartość serwisu. Po każdej zmianie plików źródłowych, Hugo automatycznie aktualizuje stronę i odświeża jej widok w przeglądarce. -## Społeczność, listy dyskusyjne, uczestnictwo i wsparcie +## Budowanie dokumentacji źródłowej API -Zajrzyj na stronę [społeczności](http://kubernetes.io/community/), aby dowiedzieć się, jak możesz zaangażować się w jej działania. +Budowanie dokumentacji źródłowej API zostało opisane w [angielskiej wersji pliku README.md](README.md#building-the-api-reference-pages). + +## Rozwiązywanie problemów +### error: failed to transform resource: TOCSS: failed to transform "scss/main.scss" (text/x-scss): this feature is not available in your current Hugo version + +Z przyczyn technicznych, Hugo jest rozprowadzany w dwóch wersjach. Aktualny serwis używa tylko wersji **Hugo Extended**. Na stronie z [wydaniami](https://github.com/gohugoio/hugo/releases) poszukaj archiwum z `extended` w nazwie. Dla potwierdzenia, uruchom `hugo version` i poszukaj słowa `extended`. + +### Błąd w środowisku macOS: "too many open files" + +Jeśli po uruchomieniu `make serve` na macOS widzisz następujący błąd: + +``` +ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files +make: *** [serve] Error 1 +``` + +sprawdź aktualny limit otwartych plików: + +`launchctl limit maxfiles` + +Uruchom następujące polecenia: (na podstawie https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c): + +```shell +#!/bin/sh + +# These are the original gist links, linking to my gists now. +# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxfiles.plist +# curl -O https://gist.githubusercontent.com/a2ikm/761c2ab02b7b3935679e55af5d81786a/raw/ab644cb92f216c019a2f032bbf25e258b01d87f9/limit.maxproc.plist + +curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxfiles.plist +curl -O https://gist.githubusercontent.com/tombigel/d503800a282fcadbee14b537735d202c/raw/ed73cacf82906fdde59976a0c8248cce8b44f906/limit.maxproc.plist + +sudo mv limit.maxfiles.plist /Library/LaunchDaemons +sudo mv limit.maxproc.plist /Library/LaunchDaemons + +sudo chown root:wheel /Library/LaunchDaemons/limit.maxfiles.plist +sudo chown root:wheel /Library/LaunchDaemons/limit.maxproc.plist + +sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist +``` + +Przedstawiony sposób powinien działać dla MacOS w wersji Catalina i Mojave. + + +# Zaangażowanie w prace SIG Docs + +O społeczności SIG Docs i terminach spotkań dowiesz z [jej strony](https://github.com/kubernetes/community/tree/master/sig-docs#meetings). Możesz kontaktować się z gospodarzami projektu za pomocą: -* [Komunikatora Slack](https://kubernetes.slack.com/messages/sig-docs) -* [List dyskusyjnych](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) +- [Komunikatora Slack](https://kubernetes.slack.com/messages/sig-docs) [Tutaj możesz dostać zaproszenie do tej grupy Slack-a](https://slack.k8s.io/) +- [List dyskusyjnych](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) -### Zasady postępowania +# Twój wkład w dokumentację -Udział w działaniach społeczności Kubernetes jest regulowany przez [Kodeks postępowania](code-of-conduct.md). +Możesz kliknąć w przycisk **Fork** w prawym górnym rogu ekranu, aby stworzyć kopię tego repozytorium na swoim koncie GitHub. Taki rodzaj kopii (odgałęzienia) nazywa się *fork*. Zmieniaj w nim, co chcesz, a kiedy będziesz już gotowy/a przesłać te zmiany do nas, przejdź do swojej kopii i stwórz nowy *pull request*, abyśmy zostali o tym poinformowani. -## Dziękujemy! +Po stworzeniu *pull request*, jeden z recenzentów projektu Kubernetes podejmie się przekazania jasnych wskazówek pozwalających podjąć następne działania. Na Tobie, jako właścicielu *pull requesta*, **spoczywa odpowiedzialność za wprowadzenie poprawek zgodnie z uwagami recenzenta.** + +Może też się zdarzyć, że swoje uwagi zgłosi więcej niż jeden recenzent, lub że recenzję będzie robił ktoś inny, niż ten, kto został przydzielony na początku. + +W niektórych przypadkach, jeśli zajdzie taka potrzeba, recenzent może poprosić dodatkowo o recenzję jednego z [recenzentów technicznych](https://github.com/kubernetes/website/wiki/Tech-reviewers). Recenzenci zrobią wszystko, aby odpowiedzieć sprawnie, ale konkretny czas odpowiedzi zależy od wielu czynników. + +Więcej informacji na temat współpracy przy tworzeniu dokumentacji znajdziesz na stronach: + +* [Udział w rozwijaniu dokumentacji](https://kubernetes.io/docs/contribute/) +* [Rodzaje stron](https://kubernetes.io/docs/contribute/style/page-content-types/) +* [Styl pisania dokumentacji](http://kubernetes.io/docs/contribute/style/style-guide/) +* [Lokalizacja dokumentacji Kubernetes](https://kubernetes.io/docs/contribute/localization/) + +# Różne wersje językowe `README.md` + +| Język | Język | +|---|---| +| [angielski](README.md) | [francuski](README-fr.md) | +| [koreański](README-ko.md) | [niemiecki](README-de.md) | +| [portugalski](README-pt.md) | [hindi](README-hi.md) | +| [hiszpański](README-es.md) | [indonezyjski](README-id.md) | +| [chiński](README-zh.md) | [japoński](README-ja.md) | +| [wietnamski](README-vi.md) | [rosyjski](README-ru.md) | +| [włoski](README-it.md) | [ukraiński](README-uk.md) | + +# Zasady postępowania + +Udział w działaniach społeczności Kubernetesa jest regulowany przez [Kodeks postępowania CNCF](https://github.com/cncf/foundation/blob/master/code-of-conduct-languages/pl.md). + +# Dziękujemy! Kubernetes rozkwita dzięki zaangażowaniu społeczności — doceniamy twój wkład w tworzenie naszego serwisu i dokumentacji! diff --git a/README-pt.md b/README-pt.md index e27bf544d1..d856bf7b42 100644 --- a/README-pt.md +++ b/README-pt.md @@ -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-master-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-main-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! diff --git a/README-ru.md b/README-ru.md index 348f92a82e..82eb96689d 100644 --- a/README-ru.md +++ b/README-ru.md @@ -1,6 +1,6 @@ # Документация по Kubernetes -[![Netlify Status](https://api.netlify.com/api/v1/badges/be93b718-a6df-402a-b4a4-855ba186c97d/deploy-status)](https://app.netlify.com/sites/kubernetes-io-master-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-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) Данный репозиторий содержит все необходимые файлы для сборки [сайта Kubernetes и документации](https://kubernetes.io/). Мы благодарим вас за желание внести свой вклад! diff --git a/README-uk.md b/README-uk.md index 2872b406d1..c1605b0c85 100644 --- a/README-uk.md +++ b/README-uk.md @@ -1,7 +1,7 @@ # Документація Kubernetes -[![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) +[![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) Вітаємо! В цьому репозиторії міститься все необхідне для роботи над [сайтом і документацією Kubernetes](https://kubernetes.io/). Ми щасливі, що ви хочете зробити свій внесок! diff --git a/README-zh.md b/README-zh.md index 4dd4de269f..6c594b3934 100644 --- a/README-zh.md +++ b/README-zh.md @@ -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-master-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-main-staging/deploys) [![GitHub release](https://img.shields.io/github/release/kubernetes/website.svg)](https://github.com/kubernetes/website/releases/latest) # 参与 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://kubernetes.slack.com/messages/sig-docs) [加入Slack](https://slack.k8s.io/) - [邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) + +{{if .ApiVersion}}`apiVersion: {{.ApiVersion}}`{{end}} + +{{if .Import}}`import "{{.Import}}"`{{end}} + +{{range .Sections}} +{{.Description | replace "<" "\\<" }} + +
+{{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}} +{{.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}} +{{.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 */}} diff --git a/api-ref-assets/templates/chapter.tmpl b/api-ref-assets/templates/chapter.tmpl new file mode 100644 index 0000000000..9fb80e2209 --- /dev/null +++ b/api-ref-assets/templates/chapter.tmpl @@ -0,0 +1,85 @@ +--- +api_metadata: + apiVersion: "{{.ApiVersion}}" + import: "{{.Import}}" + kind: "{{.Kind}}" +content_type: "api_reference" +description: "{{.Metadata.Description}}" +title: "{{.Metadata.Title}}" +weight: {{.Metadata.Weight}} +auto_generated: true +--- + + + +{{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 "<" "\\<" }} + +
+{{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}} +{{.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}} +{{.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 */}} diff --git a/api-ref-assets/templates/part-index.tmpl b/api-ref-assets/templates/part-index.tmpl new file mode 100644 index 0000000000..36833ee9bb --- /dev/null +++ b/api-ref-assets/templates/part-index.tmpl @@ -0,0 +1,17 @@ +--- +title: "{{.Title}}" +weight: {{.Weight}} +auto_generated: true +--- + + + diff --git a/api-ref-generator b/api-ref-generator index ce97454e55..55bce68622 160000 --- a/api-ref-generator +++ b/api-ref-generator @@ -1 +1 @@ -Subproject commit ce97454e557b2b164f77326cb06ef619ab623599 +Subproject commit 55bce686224caba37f93e1e1eb53c0c9fc104ed4 diff --git a/archetypes/blog-post.md b/archetypes/blog-post.md new file mode 100644 index 0000000000..acad021c68 --- /dev/null +++ b/archetypes/blog-post.md @@ -0,0 +1,61 @@ +--- +layout: blog +title: "{{ replace .Name "-" " " | title }}" +date: {{ .Date }} +draft: true +slug: +--- + +**Author:** (), () + + + +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. + +## What’s 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://.slack.com/messages/) + +* [A link to a "contribute" page with more information](). + +* Acknowledgements and thanks to the contributors. ([](https://github.com/)) who did X, Y, and Z. + +* Those interested in getting involved with the design and development of , join the [](https://github.com/project/community/tree/master/). We’re rapidly growing and always welcome new contributors. diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss index 568a258a1c..7d6aa6784f 100644 --- a/assets/scss/_custom.scss +++ b/assets/scss/_custom.scss @@ -444,7 +444,7 @@ body.cid-community > #deprecation-warning > .deprecation-warning > * { .td-sidebar__inner { form.td-sidebar__search { - button.td-sidebar__toggle { + .td-sidebar__toggle { &:hover { color: #000000; } @@ -482,10 +482,6 @@ main.content { .td-blog { - .td-sidebar-nav { - max-height: calc(100vh - 8rem); - } - .widget-link { margin-bottom: 1rem; @@ -639,3 +635,17 @@ body.td-documentation { } } +// 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; + color: inherit !important; + font-size: inherit !important; + } +} diff --git a/assets/scss/_tablet.scss b/assets/scss/_tablet.scss index b368d54494..58149a7dc2 100644 --- a/assets/scss/_tablet.scss +++ b/assets/scss/_tablet.scss @@ -77,7 +77,6 @@ $feature-box-div-width: 45%; position: relative; clear: both; display: table; - height: 160px; .content { display: table-cell; @@ -124,6 +123,7 @@ $feature-box-div-width: 45%; position: relative; display: block; float: none; + text-align: center; max-width: 100%; transform: none; } diff --git a/cloudbuild.yaml b/cloudbuild.yaml new file mode 100644 index 0000000000..5039818482 --- /dev/null +++ b/cloudbuild.yaml @@ -0,0 +1,25 @@ +# 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" diff --git a/config.toml b/config.toml index 04329284d8..eba5852abb 100644 --- a/config.toml +++ b/config.toml @@ -138,12 +138,12 @@ time_format_default = "January 02, 2006 at 3:04 PM PST" description = "Production-Grade Container Orchestration" showedit = true -latest = "v1.20" +latest = "v1.22" -fullversion = "v1.20.0" -version = "v1.20" -githubbranch = "master" -docsbranch = "master" +fullversion = "v1.22.0" +version = "v1.22" +githubbranch = "main" +docsbranch = "main" deprecated = false currentUrl = "https://kubernetes.io/docs/home/" nextUrl = "https://kubernetes-io-vnext-staging.netlify.com/" @@ -178,45 +178,46 @@ js = [ ] [[params.versions]] -fullversion = "v1.20.0" -version = "v1.20" -githubbranch = "v1.20.0" -docsbranch = "master" +fullversion = "v1.22.0" +version = "v1.22" +githubbranch = "v1.22.0" +docsbranch = "main" url = "https://kubernetes.io" [[params.versions]] -fullversion = "v1.19.4" +fullversion = "v1.21.4" +version = "v1.21" +githubbranch = "v1.21.4" +docsbranch = "release-1.21" +url = "https://v1-21.docs.kubernetes.io" + +[[params.versions]] +fullversion = "v1.20.10" +version = "v1.20" +githubbranch = "v1.20.10" +docsbranch = "release-1.20" +url = "https://v1-20.docs.kubernetes.io" + +[[params.versions]] +fullversion = "v1.19.14" version = "v1.19" -githubbranch = "v1.19.4" +githubbranch = "v1.19.14" docsbranch = "release-1.19" url = "https://v1-19.docs.kubernetes.io" [[params.versions]] -fullversion = "v1.18.12" +fullversion = "v1.18.20" version = "v1.18" -githubbranch = "v1.18.12" +githubbranch = "v1.18.20" docsbranch = "release-1.18" url = "https://v1-18.docs.kubernetes.io" -[[params.versions]] -fullversion = "v1.17.14" -version = "v1.17" -githubbranch = "v1.17.14" -docsbranch = "release-1.17" -url = "https://v1-17.docs.kubernetes.io" - -[[params.versions]] -fullversion = "v1.16.15" -version = "v1.16" -githubbranch = "v1.16.15" -docsbranch = "release-1.16" -url = "https://v1-16.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) @@ -399,15 +400,15 @@ time_format_blog = "02.01.2006" # A list of language codes to look for untranslated content, ordered from left to right. language_alternatives = ["en"] -[languages.pt] +[languages.pt-br] title = "Kubernetes" description = "Orquestração de contêineres em nível de produção" languageName ="Português" weight = 9 -contentDir = "content/pt" +contentDir = "content/pt-br" languagedirection = "ltr" -[languages.pt.params] +[languages.pt-br.params] time_format_blog = "02.01.2006" # A list of language codes to look for untranslated content, ordered from left to right. language_alternatives = ["en"] diff --git a/content/de/_index.html b/content/de/_index.html index 838552b5c4..78d3b5e003 100644 --- a/content/de/_index.html +++ b/content/de/_index.html @@ -9,7 +9,7 @@ cid: home {{% blocks/feature image="flower" %}} ### [Kubernetes (K8s)]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}}) ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen. -Es gruppiert Container, aus denen sich eine Anwendung zusammensetzt, in logische Einheiten, um die Verwaltung und Erkennung zu erleichtern. Kubernetes baut auf [15 Jahre Erfahrung in Bewältigung von Produktions-Workloads bei Google] (http://queue.acm.org/detail.cfm?id=2898444), kombiniert mit Best-of-Breed-Ideen und Praktiken aus der Community. +Es gruppiert Container, aus denen sich eine Anwendung zusammensetzt, in logische Einheiten, um die Verwaltung und Erkennung zu erleichtern. Kubernetes baut auf [15 Jahre Erfahrung in Bewältigung von Produktions-Workloads bei Google](http://queue.acm.org/detail.cfm?id=2898444), kombiniert mit Best-of-Breed-Ideen und Praktiken aus der Community. {{% /blocks/feature %}} {{% blocks/feature image="scalable" %}} @@ -57,4 +57,4 @@ Kubernetes ist Open Source und bietet Dir die Freiheit, die Infrastruktur vor Or {{< blocks/kubernetes-features >}} -{{< blocks/case-studies >}} \ No newline at end of file +{{< blocks/case-studies >}} diff --git a/content/de/docs/concepts/architecture/nodes.md b/content/de/docs/concepts/architecture/nodes.md index b790e68035..933346a4d5 100644 --- a/content/de/docs/concepts/architecture/nodes.md +++ b/content/de/docs/concepts/architecture/nodes.md @@ -147,7 +147,8 @@ Die zweite ist, die interne Node-Liste des Node Controllers mit der Liste der ve Wenn ein Node in einer Cloud-Umgebung ausgeführt wird und sich in einem schlechten Zustand befindet, fragt der Node Controller den Cloud-Anbieter, ob die virtuelle Maschine für diesen Node noch verfügbar ist. Wenn nicht, löscht der Node Controller den Node aus seiner Node-Liste. Der dritte ist die Überwachung des Zustands der Nodes. Der Node Controller ist dafür verantwortlich, -die NodeReady-Bedingung von NodeStatus auf ConditionUnknown zu aktualisieren, wenn ein wenn ein Node unerreichbar wird (der Node Controller empfängt aus irgendeinem Grund keine Herzschläge mehr, z.B. weil der Node heruntergefahren ist) und später alle Pods aus dem Node zu entfernen (und diese ordnungsgemäss zu beenden), wenn der Node weiterhin unzugänglich ist. (Die Standard-Timeouts sind 40s, um ConditionUnknown zu melden und 5 Minuten, um mit der Evakuierung der Pods zu beginnen). +die NodeReady-Bedingung von NodeStatus auf ConditionUnknown zu aktualisieren, wenn ein Node unerreichbar wird (der Node Controller empfängt aus irgendeinem Grund keine Herzschläge mehr, z.B. weil der Node heruntergefahren ist) und später alle Pods aus dem Node zu entfernen (und diese ordnungsgemäss zu beenden), wenn der Node weiterhin unzugänglich ist. (Die Standard-Timeouts sind 40s, um ConditionUnknown zu melden und 5 Minuten, um mit der Evakuierung der Pods zu beginnen). + Der Node Controller überprüft den Zustand jedes Nodes alle `--node-monitor-period` Sekunden. diff --git a/content/de/docs/concepts/cluster-administration/addons.md b/content/de/docs/concepts/cluster-administration/addons.md index f5eedeb59b..abf15e453f 100644 --- a/content/de/docs/concepts/cluster-administration/addons.md +++ b/content/de/docs/concepts/cluster-administration/addons.md @@ -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/coreos/flannel/blob/master/Documentation/kubernetes.md) ist ein Overlay-Network-Provider der mit Kubernetes genutzt werden kann. +* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) ist ein Overlay-Network-Provider der mit Kubernetes genutzt werden kann. * [Knitter](https://github.com/ZTE/Knitter/) ist eine Network-Lösung die Mehrfach-Network in Kubernetes ermöglicht. * [Multus](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. diff --git a/content/de/docs/concepts/workloads/pods/_index.md b/content/de/docs/concepts/workloads/pods/_index.md new file mode 100644 index 0000000000..956190e6c7 --- /dev/null +++ b/content/de/docs/concepts/workloads/pods/_index.md @@ -0,0 +1,369 @@ +--- +title: Pods +content_type: concept +weight: 10 +no_list: true +card: + name: concepts + weight: 60 +--- + + + +_Pods_ sind die kleinsten einsetzbaren Einheiten, die in Kubernetes +erstellt und verwaltet werden können. + +Ein _Pod_ (übersetzt Gruppe/Schote, wie z. B. eine Gruppe von Walen oder eine +Erbsenschote) ist eine Gruppe von einem oder mehreren +{{< glossary_tooltip text="Containern" term_id="container" >}} mit gemeinsam +genutzten Speicher- und Netzwerkressourcen und einer Spezifikation für die +Ausführung der Container. Die Ressourcen eines Pods befinden sich immer auf dem +gleichen (virtuellen) Server, werden gemeinsam geplant und in einem +gemeinsamen Kontext ausgeführt. Ein Pod modelliert einen anwendungsspezifischen +"logischen Server": Er enthält eine oder mehrere containerisierte Anwendungen, +die relativ stark voneinander abhängen. +In Nicht-Cloud-Kontexten sind Anwendungen, die auf +demselben physischen oder virtuellen Server ausgeführt werden, vergleichbar zu +Cloud-Anwendungen, die auf demselben logischen Server ausgeführt werden. + +Ein Pod kann neben Anwendungs-Containern auch sogenannte +[Initialisierungs-Container](/docs/concepts/workloads/pods/init-containers/) +enthalten, die beim Starten des Pods ausgeführt werden. +Es können auch +kurzlebige/[ephemere Container](/docs/concepts/workloads/pods/ephemeral-containers/) +zum Debuggen gestartet werden, wenn dies der Cluster anbietet. + + + +## Was ist ein Pod? + +{{< note >}} +Obwohl Kubernetes abgesehen von [Docker](https://www.docker.com/) auch andere +{{}} unterstützt, ist Docker am bekanntesten und + es ist hilfreich, Pods mit der Terminologie von Docker zu beschreiben. +{{< /note >}} + +Der gemeinsame Kontext eines Pods besteht aus einer Reihe von Linux-Namespaces, +Cgroups und möglicherweise anderen Aspekten der Isolation, also die gleichen +Dinge, die einen Dockercontainer isolieren. Innerhalb des Kontexts eines Pods +können die einzelnen Anwendungen weitere Unterisolierungen haben. + +Im Sinne von Docker-Konzepten ähnelt ein Pod einer Gruppe von Docker-Containern, +die gemeinsame Namespaces und Dateisystem-Volumes nutzen. + +## Pods verwenden + +Normalerweise müssen keine Pods erzeugt werden, auch keine Singleton-Pods. +Stattdessen werden sie mit Workload-Ressourcen wie {{}} oder {{}} erzeugt. Für Pods, die von einem Systemzustand +abhängen, ist die Nutzung von {{}}-Ressourcen zu erwägen. + +Pods in einem Kubernetes-Cluster werden hauptsächlich auf zwei Arten verwendet: + +* **Pods, die einen einzelnen Container ausführen**. Das +"Ein-Container-per-Pod"-Modell ist der häufigste Kubernetes-Anwendungsfall. In +diesem Fall kannst du dir einen einen Pod als einen Behälter vorstellen, der einen +einzelnen Container enthält; Kubernetes verwaltet die Pods anstatt die +Container direkt zu verwalten. +* **Pods, in denen mehrere Container ausgeführt werden, die zusammenarbeiten +müssen**. Wenn eine Softwareanwendung aus co-lokaliserten Containern besteht, +die sich gemeinsame Ressourcen teilen und stark voneinander abhängen, kann ein +Pod die Container verkapseln. +Diese Container bilden eine einzelne zusammenhängende +Serviceeinheit, z. B. ein Container, der Daten in einem gemeinsam genutzten +Volume öffentlich verfügbar macht, während ein separater _Sidecar_-Container +die Daten aktualisiert. Der Pod fasst die Container, die Speicherressourcen +und eine kurzlebiges Netzwerk-Identität als eine Einheit zusammen. + +{{< note >}} +Das Gruppieren mehrerer gemeinsam lokalisierter und gemeinsam verwalteter +Container in einem einzigen Pod ist ein relativ fortgeschrittener +Anwendungsfall. Du solltest diese Architektur nur in bestimmten Fällen +verwenden, wenn deine Container stark voneinander abhängen. +{{< /note >}} + +Jeder Pod sollte eine einzelne Instanz einer gegebenen Anwendung ausführen. Wenn +du deine Anwendung horizontal skalieren willst (um mehr Instanzen auszuführen +und dadurch mehr Gesamtressourcen bereitstellen), solltest du mehrere Pods +verwenden, einen für jede Instanz. +In Kubernetes wird dies typischerweise als Replikation bezeichnet. +Replizierte Pods werden normalerweise als eine Gruppe durch eine +Workload-Ressource und deren +{{}} erstellt +und verwaltet. + +Der Abschnitt [Pods und Controller](#pods-und-controller) beschreibt, wie +Kubernetes Workload-Ressourcen und deren Controller verwendet, um Anwendungen +zu skalieren und zu heilen. + +### Wie Pods mehrere Container verwalten + +Pods unterstützen mehrere kooperierende Prozesse (als Container), die eine +zusammenhängende Serviceeinheit bilden. Kubernetes plant und stellt automatisch +sicher, dass sich die Container in einem Pod auf demselben physischen oder +virtuellen Server im Cluster befinden. Die Container können Ressourcen und +Abhängigkeiten gemeinsam nutzen, miteinander kommunizieren und +ferner koordinieren wann und wie sie beendet werden. + +Zum Beispiel könntest du einen Container haben, der als Webserver für Dateien in +einem gemeinsamen Volume arbeitet. Und ein separater "Sidecar" -Container +aktualisiert die Daten von einer externen Datenquelle, siehe folgenden +Abbildung: + +{{< figure src="/images/docs/pod.svg" alt="Pod-Beispieldiagramm" width="50%" >}} + +Einige Pods haben sowohl {{}} als auch {{}}. +Initialisierungs-Container werden gestartet und beendet bevor die +Anwendungs-Container gestartet werden. + +Pods stellen standardmäßig zwei Arten von gemeinsam Ressourcen für die +enthaltenen Container bereit: +[Netzwerk](#pod-netzwerk) und [Speicher](#datenspeicherung-in-pods). + + +## Mit Pods arbeiten + +Du wirst selten einzelne Pods direkt in Kubernetes erstellen, selbst +Singleton-Pods. Das liegt daran, dass Pods als relativ kurzlebige +Einweg-Einheiten konzipiert sind. Wann Ein Pod erstellt wird (entweder direkt +von Ihnen oder indirekt von einem +{{}}), wird die +Ausführung auf einem {{}} in Ihrem Cluster +geplant. Der Pod bleibt auf diesem (virtuellen) Server, bis entweder der Pod die +Ausführung beendet hat, das Pod-Objekt gelöscht wird, der Pod aufgrund +mangelnder Ressourcen *evakuiert* wird oder oder der Node ausfällt. + +{{< note >}} +Das Neustarten eines Containers in einem Pod sollte nicht mit dem Neustarten +eines Pods verwechselt werden. Ein Pod ist kein Prozess, sondern eine Umgebung +zur Ausführung von Containern. Ein Pod bleibt bestehen bis er gelöscht wird. +{{< /note >}} + +Stelle beim Erstellen des Manifests für ein Pod-Objekt sicher, dass der +angegebene Name ein gültiger +[DNS-Subdomain-Name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) +ist. + +### Pods und Controller + +Mit Workload-Ressourcen kannst du mehrere Pods erstellen und verwalten. Ein +Controller für die Ressource kümmert sich um Replikation, Roll-Out sowie +automatische Wiederherstellung im Fall von versagenden Pods. Wenn beispielsweise ein Node +ausfällt, bemerkt ein Controller, dass die Pods auf dem Node nicht mehr laufen +und plant die Ausführung eines Ersatzpods auf einem funktionierenden Node. +Hier sind einige Beispiele für Workload-Ressourcen, die einen oder mehrere Pods +verwalten: + +* {{< glossary_tooltip text="Deployment" term_id="deployment" >}} +* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} +* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} + +### Pod Vorlagen + +Controller für +{{}}-Ressourcen +erstellen Pods von einer _Pod Vorlage_ und verwalten diese Pods für dich. + +Pod Vorlagen sind Spezifikationen zum Erstellen von Pods und sind in +Workload-Ressourcen enthalten wie z. B. +[Deployments](/docs/concepts/workloads/controllers/deployment/), +[Jobs](/docs/concepts/workloads/controllers/job/), and +[DaemonSets](/docs/concepts/workloads/controllers/daemonset/). + +Jeder Controller für eine Workload-Ressource verwendet die Pod Vorlage innerhalb +des Workload-Objektes, um Pods zu erzeugen. Die Pod Vorlage ist Teil des +gewünschten Zustands der Workload-Ressource, mit der du deine Anwendung +ausgeführt hast. + +Das folgende Beispiel ist ein Manifest für einen einfachen Job mit einer +`Vorlage`, die einen Container startet. Der Container in diesem Pod druckt +eine Nachricht und pausiert dann. + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: hello +spec: + template: + # Dies is the Pod Vorlage + spec: + containers: + - name: hello + image: busybox + command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] + restartPolicy: OnFailure + # Die Pod Vorlage endet hier +``` +Das Ändern der Pod Vorlage oder der Wechsel zu einer neuen Pod Vorlage hat keine +direkten Auswirkungen auf bereits existierende Pods. Wenn du die Pod Vorlage für +eine Workload-Ressource änderst, dann muss diese Ressource die Ersatz-Pods +erstellen, welche die aktualisierte Vorlage verwenden. + +Beispielsweise stellt der StatefulSet-Controller sicher, dass für jedes +StatefulSet-Objekt die ausgeführten Pods mit der aktueller Pod Vorlage +übereinstimmen. Wenn du das StatefulSet bearbeitest und die Vorlage änderst, +beginnt das StatefulSet mit der Erstellung neuer Pods basierend auf der +aktualisierten Vorlage. Schließlich werden alle alten Pods durch neue Pods +ersetzt, und das Update ist abgeschlossen. + +Jede Workload-Ressource implementiert eigenen Regeln für die Umsetzung von +Änderungen der Pod Vorlage. Wenn du mehr über StatefulSet erfahren möchtest, +dann lese die Seite +[Update-Strategien](/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets) +im Tutorial StatefulSet Basics. + + +Auf Nodes beobachtet oder verwaltet das +{{< glossary_tooltip term_id="kubelet" text="Kubelet" >}} +nicht direkt die Details zu Pod Vorlagen und Updates. Diese Details sind +abstrahiert. Die Abstraktion und Trennung von Aufgaben vereinfacht die +Systemsemantik und ermöglicht so das Verhalten des Clusters zu ändern ohne +vorhandenen Code zu ändern. + +## Pod Update und Austausch + +Wie im vorherigen Abschnitt erwähnt, erstellt der Controller neue Pods basierend +auf der aktualisierten Vorlage, wenn die Pod Vorlage für eine Workload-Ressource +geändert wird anstatt die vorhandenen Pods zu aktualisieren oder zu patchen. + +Kubernetes hindert dich nicht daran, Pods direkt zu verwalten. Es ist möglich, +einige Felder eines laufenden Pods zu aktualisieren. Allerdings haben +Pod-Aktualisierungsvorgänge wie zum Beispiel +[`patch`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#patch-pod-v1-core), +und +[`replace`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replace-pod-v1-core) +einige Einschränkungen: + +- Die meisten Metadaten zu einem Pod können nicht verändert werden. Zum Beispiel kannst + du nicht die Felder `namespace`, `name`, `uid`, oder `creationTimestamp` + ändern. Das `generation`-Feld muss eindeutig sein. Es werden nur Aktualisierungen + akzeptiert, die den Wert des Feldes inkrementieren. +- Wenn das Feld `metadata.deletionTimestamp` gesetzt ist, kann kein neuer + Eintrag zur Liste `metadata.finalizers` hinzugefügt werden. +- Pod-Updates dürfen keine Felder ändern, die Ausnahmen sind + `spec.containers[*].image`, + `spec.initContainers[*].image`,` spec.activeDeadlineSeconds` oder + `spec.tolerations`. Für `spec.tolerations` kannnst du nur neue Einträge + hinzufügen. +- Für `spec.activeDeadlineSeconds` sind nur zwei Änderungen erlaubt: + + 1. ungesetztes Feld in eine positive Zahl + 1. positive Zahl in eine kleinere positive Zahl, die nicht negativ ist + +## Gemeinsame Nutzung von Ressourcen und Kommunikation + +Pods ermöglichen den Datenaustausch und die Kommunikation zwischen den +Containern, die im Pod enthalten sind. + +### Datenspeicherung in Pods + +Ein Pod kann eine Reihe von gemeinsam genutzten Speicher- +{{}} spezifizieren. Alle +Container im Pod können auf die gemeinsamen Volumes zugreifen und dadurch Daten +austauschen. Volumes ermöglichen auch, dass Daten ohne Verlust gespeichert +werden, falls einer der Container neu gestartet werden muss. +Im Kapitel [Datenspeicherung](/docs/concepts/storage/) findest du weitere +Informationen, wie Kubernetes gemeinsam genutzten Speicher implementiert und +Pods zur Verfügung stellt. + +### Pod-Netzwerk + +Jedem Pod wird für jede Adressenfamilie eine eindeutige IP-Adresse zugewiesen. +Jeder Container in einem Pod nutzt den gemeinsamen Netzwerk-Namespace, +einschließlich der IP-Adresse und der Ports. In einem Pod (und **nur** dann) +können die Container, die zum Pod gehören, über `localhost` miteinander +kommunizieren. Wenn Container in einem Pod mit Entitäten *außerhalb des Pods* +kommunizieren, müssen sie koordinieren, wie die gemeinsam genutzten +Netzwerkressourcen (z. B. Ports) verwenden werden. Innerhalb eines Pods teilen +sich Container eine IP-Adresse und eine Reihe von Ports und können sich +gegenseitig über `localhost` finden. Die Container in einem Pod können auch die +üblichen Kommunikationsverfahren zwischen Prozessen nutzen, wie z. B. +SystemV-Semaphoren oder "POSIX Shared Memory". Container in verschiedenen Pods +haben unterschiedliche IP-Adressen und können nicht per IPC ohne +[spezielle Konfiguration](/docs/concepts/policy/pod-security-policy/) +kommunizieren. Container, die mit einem Container in einem anderen Pod +interagieren möchten, müssen IP Netzwerke verwenden. + +Für die Container innerhalb eines Pods stimmt der "hostname" mit dem +konfigurierten `Namen` des Pods überein. Mehr dazu im Kapitel +[Netzwerke](/docs/concepts/cluster-administration/networking/). + +## Privilegierter Modus für Container + +Jeder Container in einem Pod kann den privilegierten Modus aktivieren, indem +das Flag `privileged` im +[Sicherheitskontext](/docs/tasks/configure-pod-container/security-context/) +der Container-Spezifikation verwendet wird. +Dies ist nützlich für Container, die Verwaltungsfunktionen des Betriebssystems +verwenden möchten, z. B. das Manipulieren des Netzwerk-Stacks oder den Zugriff +auf Hardware. Prozesse innerhalb eines privilegierten Containers erhalten fast +die gleichen Rechte wie sie Prozessen außerhalb eines Containers zur Verfügung +stehen. + +{{< note >}} +Ihre +{{}} +muss das Konzept eines privilegierten Containers unterstützen, damit diese +Einstellung relevant ist. +{{< /note >}} + + +## Statische Pods + +_Statische Pods_ werden direkt vom Kubelet-Daemon auf einem bestimmten Node +verwaltet ohne dass sie vom +{{}} überwacht +werden. + +Die meisten Pods werden von der Kontrollebene verwaltet (z. B. +{{< glossary_tooltip text="Deployment" term_id="deployment" >}}). Aber für +statische Pods überwacht das Kubelet jeden statischen Pod direkt (und startet +ihn neu, wenn er ausfällt). + +Statische Pods sind immer an ein {{}} auf +einem bestimmten Node gebunden. Der Hauptanwendungsfall für statische Pods +besteht darin, eine selbst gehostete Steuerebene auszuführen. Mit anderen +Worten: Das Kubelet dient zur Überwachung der einzelnen +[Komponenten der Kontrollebene](/docs/concepts/overview/components/#control-plane-components). + +Das Kubelet versucht automatisch auf dem Kubernetes API-Server für jeden +statischen Pod einen spiegelbildlichen Pod +(im Englischen: {{}}) +zu erstellen. +Das bedeutet, dass die auf einem Node ausgeführten Pods auf dem API-Server +sichtbar sind jedoch von dort nicht gesteuert werden können. + +## {{% heading "whatsnext" %}} + +* Verstehe den + [Lebenszyklus eines Pods](/docs/concepts/workloads/pods/pod-lifecycle/). +* Erfahre mehr über [RuntimeClass](/docs/concepts/containers/runtime-class/) + und wie du damit verschiedene Pods mit unterschiedlichen + Container-Laufzeitumgebungen konfigurieren kannst. +* Mehr zum Thema + [Restriktionen für die Verteilung von Pods](/docs/concepts/workloads/pods/pod-topology-spread-constraints/). +* Lese + [Pod-Disruption-Budget](/docs/concepts/workloads/pods/disruptions/) + und wie du es verwenden kannst, um die Verfügbarkeit von Anwendungen bei + Störungen zu verwalten. Die + [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) + -Objektdefinition beschreibt das Objekt im Detail. +* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) + erläutert allgemeine Layouts für Pods mit mehr als einem Container. + +Um den Hintergrund zu verstehen, warum Kubernetes eine gemeinsame Pod-API in +andere Ressourcen, wie z. B. +{{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} +oder {{< glossary_tooltip text="Deployments" term_id="deployment" >}} einbindet, +kannst du Artikel zu früheren Technologien lesen, unter anderem: + * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema) + * [Borg](https://research.google.com/pubs/pub43438.html) + * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html) + * [Omega](https://research.google/pubs/pub41684/) + * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/). \ No newline at end of file diff --git a/content/de/docs/tutorials/_index.md b/content/de/docs/tutorials/_index.md index e00382c893..3ab69b6073 100644 --- a/content/de/docs/tutorials/_index.md +++ b/content/de/docs/tutorials/_index.md @@ -50,6 +50,8 @@ 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/) diff --git a/content/de/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/de/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index 7a5fe0ce4f..4b7d5ddaae 100644 --- a/content/de/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/de/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/de/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/de/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 8c74aafd78..b8eae305f3 100644 --- a/content/de/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/de/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/de/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/de/docs/tutorials/kubernetes-basics/explore/explore-intro.html index f220ff5eb7..5e64134a44 100644 --- a/content/de/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/de/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/de/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/de/docs/tutorials/kubernetes-basics/expose/expose-interactive.html index ab5b880397..5b4c1a4ae8 100644 --- a/content/de/docs/tutorials/kubernetes-basics/expose/expose-interactive.html +++ b/content/de/docs/tutorials/kubernetes-basics/expose/expose-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/de/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/de/docs/tutorials/kubernetes-basics/expose/expose-intro.html index 07e76654a4..ce0f9caaae 100644 --- a/content/de/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/de/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/de/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/de/docs/tutorials/kubernetes-basics/update/update-interactive.html index 448ddc81b9..086b90d6b7 100644 --- a/content/de/docs/tutorials/kubernetes-basics/update/update-interactive.html +++ b/content/de/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/de/docs/tutorials/kubernetes-basics/update/update-intro.html b/content/de/docs/tutorials/kubernetes-basics/update/update-intro.html index 61ee05d662..74e3e40982 100644 --- a/content/de/docs/tutorials/kubernetes-basics/update/update-intro.html +++ b/content/de/docs/tutorials/kubernetes-basics/update/update-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/en/_index.html b/content/en/_index.html index 13a3c069be..db4c966102 100644 --- a/content/en/_index.html +++ b/content/en/_index.html @@ -43,12 +43,12 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise

- Attend KubeCon NA virtually on November 17-20, 2020 + Attend KubeCon North America on October 11-15, 2021



- Attend KubeCon EU virtually on May 4 – 7, 2021 + Attend KubeCon Europe on May 17-20, 2022
@@ -58,4 +58,4 @@ Kubernetes is open source giving you the freedom to take advantage of on-premise {{< blocks/kubernetes-features >}} -{{< blocks/case-studies >}} \ No newline at end of file +{{< blocks/case-studies >}} diff --git a/content/en/blog/_posts/2016-08-00-Kubernetes-Namespaces-Use-Cases-Insights.md b/content/en/blog/_posts/2016-08-00-Kubernetes-Namespaces-Use-Cases-Insights.md index 7b05c1f74c..896f2c5f84 100644 --- a/content/en/blog/_posts/2016-08-00-Kubernetes-Namespaces-Use-Cases-Insights.md +++ b/content/en/blog/_posts/2016-08-00-Kubernetes-Namespaces-Use-Cases-Insights.md @@ -125,7 +125,7 @@ You may wish to, but you cannot create a hierarchy of namespaces. Namespaces can -Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/user-guide/kubectl/kubectl_config_set-context/).  +Namespaces are easy to create and use but it’s also easy to deploy code inadvertently into the wrong namespace. Good DevOps hygiene suggests documenting and automating processes where possible and this will help. The other way to avoid using the wrong namespace is to set a [kubectl context](/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-).  diff --git a/content/en/blog/_posts/2016-11-00-Visualize-Kubelet-Performance-With-Node-Dashboard.md b/content/en/blog/_posts/2016-11-00-Visualize-Kubelet-Performance-With-Node-Dashboard.md index bdb43b49b9..548c91e7b7 100644 --- a/content/en/blog/_posts/2016-11-00-Visualize-Kubelet-Performance-With-Node-Dashboard.md +++ b/content/en/blog/_posts/2016-11-00-Visualize-Kubelet-Performance-With-Node-Dashboard.md @@ -5,6 +5,11 @@ 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** diff --git a/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md b/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md index 515a3aa195..6ce3bf0044 100644 --- a/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md +++ b/content/en/blog/_posts/2016-12-00-Statefulset-Run-Scale-Stateful-Applications-In-Kubernetes.md @@ -37,7 +37,7 @@ If you run your storage application on high-end hardware or extra-large instance [ZooKeeper](https://zookeeper.apache.org/doc/current/) is an interesting use case for StatefulSet for two reasons. First, it demonstrates that StatefulSet can be used to run a distributed, strongly consistent storage application on Kubernetes. Second, it's a prerequisite for running workloads like [Apache Hadoop](http://hadoop.apache.org/) and [Apache Kakfa](https://kafka.apache.org/) on Kubernetes. An [in-depth tutorial](/docs/tutorials/stateful-application/zookeeper/) on deploying a ZooKeeper ensemble on Kubernetes is available in the Kubernetes documentation, and we’ll outline a few of the key features below. **Creating a ZooKeeper Ensemble** -Creating an ensemble is as simple as using [kubectl create](/docs/user-guide/kubectl/kubectl_create/) to generate the objects stored in the manifest. +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. ``` @@ -297,7 +297,7 @@ zk-0 0/1 Terminating 0 15m -You can use [kubectl apply](/docs/user-guide/kubectl/kubectl_apply/) to recreate the zk StatefulSet and redeploy the ensemble. +You can use [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) to recreate the zk StatefulSet and redeploy the ensemble. diff --git a/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md b/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md index 385e6a814a..cf7cc12c92 100644 --- a/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md +++ b/content/en/blog/_posts/2018-01-00-Core-Workloads-Api-Ga.md @@ -95,7 +95,7 @@ The core workloads API surface is stable, but it’s still software, and softwar --Kenneth Owens, Software Engineer, Google -- [Download](http://get.k8s.io/) Kubernetes +- [Download](https://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/) diff --git a/content/en/blog/_posts/2018-04-13-local-persistent-volumes-beta.md b/content/en/blog/_posts/2018-04-13-local-persistent-volumes-beta.md index 71a0fa26d9..a7cabde710 100644 --- a/content/en/blog/_posts/2018-04-13-local-persistent-volumes-beta.md +++ b/content/en/blog/_posts/2018-04-13-local-persistent-volumes-beta.md @@ -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/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 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 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. diff --git a/content/en/blog/_posts/2018-07-16-kubernetes-1-11-release-interview.md b/content/en/blog/_posts/2018-07-16-kubernetes-1-11-release-interview.md index 4326924029..25758bc213 100644 --- a/content/en/blog/_posts/2018-07-16-kubernetes-1-11-release-interview.md +++ b/content/en/blog/_posts/2018-07-16-kubernetes-1-11-release-interview.md @@ -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/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... +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... TIM PEPPER: The [JSON capitalization case sensitivity](https://github.com/kubernetes/kubernetes/issues/64612). diff --git a/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md b/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md index a28196d568..329b2c4de7 100644 --- a/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md +++ b/content/en/blog/_posts/2018-08-03-make-kubernetes-production-grade-anywhere.md @@ -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/tasks/administer-cluster/out-of-resource/) 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/concepts/scheduling-eviction/node-pressure-eviction/) 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/configuration/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/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. 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. diff --git a/content/en/blog/_posts/2019-04-16-pod-priority-and-preemption-in-kubernetes.md b/content/en/blog/_posts/2019-04-16-pod-priority-and-preemption-in-kubernetes.md index 49516da96a..88907e3e4d 100644 --- a/content/en/blog/_posts/2019-04-16-pod-priority-and-preemption-in-kubernetes.md +++ b/content/en/blog/_posts/2019-04-16-pod-priority-and-preemption-in-kubernetes.md @@ -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](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. +[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. ## Guaranteed scheduling with controlled cost diff --git a/content/en/blog/_posts/2019-07-23-get-started-with-kubernetes-using-python.md b/content/en/blog/_posts/2019-07-23-get-started-with-kubernetes-using-python.md index 5f8d40618a..7d2e3d6ec2 100644 --- a/content/en/blog/_posts/2019-07-23-get-started-with-kubernetes-using-python.md +++ b/content/en/blog/_posts/2019-07-23-get-started-with-kubernetes-using-python.md @@ -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 form Python!” message. +Now navigate to http://localhost:5001, and you should see the “Hello from Python!” message. ### More info * [Get started with Docker](https://docs.docker.com/get-started/) @@ -201,7 +201,7 @@ kubectl get pods ``` Pod listing -Now navigate to http://localhost:6000, and you should see the “Hello form Python!” message. +Now navigate to http://localhost:6000, and you should see the “Hello from Python!” message. That’s it! The application is now running in Kubernetes! diff --git a/content/en/blog/_posts/2019-11-26-cloud-native-java-controller-sdk.md b/content/en/blog/_posts/2019-11-26-cloud-native-java-controller-sdk.md index 2474d07a95..80926b6bc4 100644 --- a/content/en/blog/_posts/2019-11-26-cloud-native-java-controller-sdk.md +++ b/content/en/blog/_posts/2019-11-26-cloud-native-java-controller-sdk.md @@ -58,7 +58,7 @@ Take maven project as example, adding the following dependencies into your depen Then we can make use of the provided builder libraries to write your own controller. For example, the following one is a simple controller prints out node information -on watch notification, see complete example [here](https://github.com/kubernetes-client/java/blob/master/examples/src/main/java/io/kubernetes/client/examples/ControllerExample.java): +on watch notification, see complete example [here](https://github.com/kubernetes-client/java/blob/master/examples/examples-release-13/src/main/java/io/kubernetes/client/examples/ControllerExample.java): ```java ... diff --git a/content/en/blog/_posts/2019-12-09-kubernetes-1.17-release-announcement.md b/content/en/blog/_posts/2019-12-09-kubernetes-1.17-release-announcement.md index f5c6761eab..983d7ba31e 100644 --- a/content/en/blog/_posts/2019-12-09-kubernetes-1.17-release-announcement.md +++ b/content/en/blog/_posts/2019-12-09-kubernetes-1.17-release-announcement.md @@ -31,9 +31,9 @@ Standard labels are used by Kubernetes components to support some features. For The labels are reaching general availability in this release. Kubernetes components have been updated to populate the GA and beta labels and to react to both. However, if you are using the beta labels in your pod specs for features such as node affinity, or in your custom controllers, we recommend that you start migrating them to the new GA labels. You can find the documentation for the new labels here: -- [node.kubernetes.io/instance-type](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type) -- [topology.kubernetes.io/region](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesioregion) -- [topology.kubernetes.io/zone](https://kubernetes.io/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) +- [node.kubernetes.io/instance-type](/docs/reference/labels-annotations-taints/#nodekubernetesioinstance-type) +- [topology.kubernetes.io/region](/docs/reference/labels-annotations-taints/#topologykubernetesioregion) +- [topology.kubernetes.io/zone](/docs/reference/labels-annotations-taints/#topologykubernetesiozone) ## Volume Snapshot Moves to Beta diff --git a/content/en/blog/_posts/2020-05-27-An-Introduction-to-the-K8s-Infrastructure-Working-Group.md b/content/en/blog/_posts/2020-05-27-An-Introduction-to-the-K8s-Infrastructure-Working-Group.md index f2a74914d8..efd5e196f7 100644 --- a/content/en/blog/_posts/2020-05-27-An-Introduction-to-the-K8s-Infrastructure-Working-Group.md +++ b/content/en/blog/_posts/2020-05-27-An-Introduction-to-the-K8s-Infrastructure-Working-Group.md @@ -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/master/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/main/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. diff --git a/content/en/blog/_posts/2020-09-03-warnings/index.md b/content/en/blog/_posts/2020-09-03-warnings/index.md index d88dd8328d..50576c0329 100644 --- a/content/en/blog/_posts/2020-09-03-warnings/index.md +++ b/content/en/blog/_posts/2020-09-03-warnings/index.md @@ -325,7 +325,7 @@ Now that we have a way to communicate helpful information to users in context, we're already considering other ways we can use this to improve people's experience with Kubernetes. A couple areas we're looking at next are warning about [known problematic values](http://issue.k8s.io/64841#issuecomment-395141013) we cannot reject outright for compatibility reasons, and warning about use of deprecated fields or field values -(like selectors using beta os/arch node labels, [deprecated in v1.14](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-arch-deprecated)). +(like selectors using beta os/arch node labels, [deprecated in v1.14](/docs/reference/labels-annotations-taints/#beta-kubernetes-io-arch-deprecated)). I'm excited to see progress in this area, continuing to make it easier to use Kubernetes. --- diff --git a/content/en/blog/_posts/2020-12-02-dockershim-faq.md b/content/en/blog/_posts/2020-12-02-dockershim-faq.md index 918a969e51..70e6c9b114 100644 --- a/content/en/blog/_posts/2020-12-02-dockershim-faq.md +++ b/content/en/blog/_posts/2020-12-02-dockershim-faq.md @@ -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/1985-remove-dockershim +[drkep]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim ### Can I still use Docker in Kubernetes 1.20? @@ -42,9 +42,20 @@ 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. 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. +_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. + + +### Can I still use dockershim after it is removed from Kubernetes? + +Update: +Mirantis and Docker have [committed][mirantis] to maintaining the dockershim after +it is removed from Kubernetes. + +[mirantis]: https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/ ### Will my existing Docker images still work? @@ -178,4 +189,3 @@ discussion of the changes. Always and whenever you want! 🤗🤗 - diff --git a/content/en/blog/_posts/2020-12-08-kubernetes-release-1.20.md b/content/en/blog/_posts/2020-12-08-kubernetes-release-1.20.md index e0fef7ab90..deb459c4be 100644 --- a/content/en/blog/_posts/2020-12-08-kubernetes-release-1.20.md +++ b/content/en/blog/_posts/2020-12-08-kubernetes-release-1.20.md @@ -64,7 +64,7 @@ The Kubernetes community has written a [detailed blog post about deprecation](ht A longstanding bug regarding exec probe timeouts that may impact existing pod definitions has been fixed. Prior to this fix, the field `timeoutSeconds` was not respected for exec probes. Instead, probes would run indefinitely, even past their configured deadline, until a result was returned. With this change, the default value of `1 second` will be applied if a value is not specified and existing pod definitions may no longer be sufficient if a probe takes longer than one second. A feature gate, called `ExecProbeTimeout`, has been added with this fix that enables cluster operators to revert to the previous behavior, but this will be locked and removed in subsequent releases. In order to revert to the previous behavior, cluster operators should set this feature gate to `false`. -Please review the updated documentation regarding [configuring probes](docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes) for more details. +Please review the updated documentation regarding [configuring probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes) for more details. ## Other Updates diff --git a/content/en/blog/_posts/2021-04-06-PodSecurityPolicy-Past-Present-and-Future.md b/content/en/blog/_posts/2021-04-06-PodSecurityPolicy-Past-Present-and-Future.md new file mode 100644 index 0000000000..c65069460a --- /dev/null +++ b/content/en/blog/_posts/2021-04-06-PodSecurityPolicy-Past-Present-and-Future.md @@ -0,0 +1,74 @@ +--- +layout: blog +title: "PodSecurityPolicy Deprecation: Past, Present, and Future" +date: 2021-04-06 +slug: podsecuritypolicy-deprecation-past-present-and-future +--- + +**Author:** Tabitha Sable (Kubernetes SIG Security) + +PodSecurityPolicy (PSP) is being deprecated in Kubernetes 1.21, to be released later this week. This starts the countdown to its removal, but doesn’t change anything else. PodSecurityPolicy will continue to be fully functional for several more releases before being removed completely. In the meantime, we are developing a replacement for PSP that covers key use cases more easily and sustainably. + +What are Pod Security Policies? Why did we need them? Why are they going away, and what’s next? How does this affect you? These key questions come to mind as we prepare to say goodbye to PSP, so let’s walk through them together. We’ll start with an overview of how features get removed from Kubernetes. + +## What does deprecation mean in Kubernetes? + +Whenever a Kubernetes feature is set to go away, our [deprecation policy](/docs/reference/using-api/deprecation-policy/) is our guide. First the feature is marked as deprecated, then after enough time has passed, it can finally be removed. + +Kubernetes 1.21 starts the deprecation process for PodSecurityPolicy. As with all feature deprecations, PodSecurityPolicy will continue to be fully functional for several more releases. The current plan is to remove PSP from Kubernetes in the 1.25 release. + +Until then, PSP is still PSP. There will be at least a year during which the newest Kubernetes releases will still support PSP, and nearly two years until PSP will pass fully out of all supported Kubernetes versions. + +## What is PodSecurityPolicy? + +[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) is a built-in [admission controller](/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/) that allows a cluster administrator to control security-sensitive aspects of the Pod specification. + +First, one or more PodSecurityPolicy resources are created in a cluster to define the requirements Pods must meet. Then, RBAC rules are created to control which PodSecurityPolicy applies to a given pod. If a pod meets the requirements of its PSP, it will be admitted to the cluster as usual. In some cases, PSP can also modify Pod fields, effectively creating new defaults for those fields. If a Pod does not meet the PSP requirements, it is rejected, and cannot run. + +One more important thing to know about PodSecurityPolicy: it’s not the same as [PodSecurityContext](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context). + +A part of the Pod specification, PodSecurityContext (and its per-container counterpart `SecurityContext`) is the collection of fields that specify many of the security-relevant settings for a Pod. The security context dictates to the kubelet and container runtime how the Pod should actually be run. In contrast, the PodSecurityPolicy only constrains (or defaults) the values that may be set on the security context. + +The deprecation of PSP does not affect PodSecurityContext in any way. + +## Why did we need PodSecurityPolicy? + +In Kubernetes, we define resources such as Deployments, StatefulSets, and Services that represent the building blocks of software applications. The various controllers inside a Kubernetes cluster react to these resources, creating further Kubernetes resources or configuring some software or hardware to accomplish our goals. + +In most Kubernetes clusters, RBAC (Role-Based Access Control) [rules](/docs/reference/access-authn-authz/rbac/#role-and-clusterrole) control access to these resources. `list`, `get`, `create`, `edit`, and `delete` are the sorts of API operations that RBAC cares about, but _RBAC does not consider what settings are being put into the resources it controls_. For example, a Pod can be almost anything from a simple webserver to a privileged command prompt offering full access to the underlying server node and all the data. It’s all the same to RBAC: a Pod is a Pod is a Pod. + +To control what sorts of settings are allowed in the resources defined in your cluster, you need Admission Control in addition to RBAC. Since Kubernetes 1.3, PodSecurityPolicy has been the built-in way to do that for security-related Pod fields. Using PodSecurityPolicy, you can prevent “create Pod” from automatically meaning “root on every cluster node,” without needing to deploy additional external admission controllers. + +## Why is PodSecurityPolicy going away? + +In the years since PodSecurityPolicy was first introduced, we have realized that PSP has some serious usability problems that can’t be addressed without making breaking changes. + +The way PSPs are applied to Pods has proven confusing to nearly everyone that has attempted to use them. It is easy to accidentally grant broader permissions than intended, and difficult to inspect which PSP(s) apply in a given situation. The “changing Pod defaults” feature can be handy, but is only supported for certain Pod settings and it’s not obvious when they will or will not apply to your Pod. Without a “dry run” or audit mode, it’s impractical to retrofit PSP to existing clusters safely, and it’s impossible for PSP to ever be enabled by default. + +For more information about these and other PSP difficulties, check out SIG Auth’s KubeCon NA 2019 Maintainer Track session video: {{< youtube "SFtHRmPuhEw?start=953" youtube-quote-sm >}} + +Today, you’re not limited only to deploying PSP or writing your own custom admission controller. Several external admission controllers are available that incorporate lessons learned from PSP to provide a better user experience. [K-Rail](https://github.com/cruise-automation/k-rail), [Kyverno](https://github.com/kyverno/kyverno/), and [OPA/Gatekeeper](https://github.com/open-policy-agent/gatekeeper/) are all well-known, and each has its fans. + +Although there are other good options available now, we believe there is still value in having a built-in admission controller available as a choice for users. With this in mind, we turn toward building what’s next, inspired by the lessons learned from PSP. + +## What’s next? + +Kubernetes SIG Security, SIG Auth, and a diverse collection of other community members have been working together for months to ensure that what’s coming next is going to be awesome. We have developed a Kubernetes Enhancement Proposal ([KEP 2579](https://github.com/kubernetes/enhancements/issues/2579)) and a prototype for a new feature, currently being called by the temporary name "PSP Replacement Policy." We are targeting an Alpha release in Kubernetes 1.22. + +PSP Replacement Policy starts with the realization that since there is a robust ecosystem of external admission controllers already available, PSP’s replacement doesn’t need to be all things to all people. Simplicity of deployment and adoption is the key advantage a built-in admission controller has compared to an external webhook, so we have focused on how to best utilize that advantage. + +PSP Replacement Policy is designed to be as simple as practically possible while providing enough flexibility to really be useful in production at scale. It has soft rollout features to enable retrofitting it to existing clusters, and is configurable enough that it can eventually be active by default. It can be deactivated partially or entirely, to coexist with external admission controllers for advanced use cases. + +## What does this mean for you? + +What this all means for you depends on your current PSP situation. If you’re already using PSP, there’s plenty of time to plan your next move. Please review the PSP Replacement Policy KEP and think about how well it will suit your use case. + +If you’re making extensive use of the flexibility of PSP with numerous PSPs and complex binding rules, you will likely find the simplicity of PSP Replacement Policy too limiting. Use the next year to evaluate the other admission controller choices in the ecosystem. There are resources available to ease this transition, such as the [Gatekeeper Policy Library](https://github.com/open-policy-agent/gatekeeper-library). + +If your use of PSP is relatively simple, with a few policies and straightforward binding to service accounts in each namespace, you will likely find PSP Replacement Policy to be a good match for your needs. Evaluate your PSPs compared to the Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-standards/) to get a feel for where you’ll be able to use the Restricted, Baseline, and Privileged policies. Please follow along with or contribute to the KEP and subsequent development, and try out the Alpha release of PSP Replacement Policy when it becomes available. + +If you’re just beginning your PSP journey, you will save time and effort by keeping it simple. You can approximate the functionality of PSP Replacement Policy today by using the Pod Security Standards’ PSPs. If you set the cluster default by binding a Baseline or Restricted policy to the `system:serviceaccounts` group, and then make a more-permissive policy available as needed in certain Namespaces [using ServiceAccount bindings](/docs/concepts/policy/pod-security-policy/#run-another-pod), you will avoid many of the PSP pitfalls and have an easy migration to PSP Replacement Policy. If your needs are much more complex than this, your effort is probably better spent adopting one of the more fully-featured external admission controllers mentioned above. + +We’re dedicated to making Kubernetes the best container orchestration tool we can, and sometimes that means we need to remove longstanding features to make space for better things to come. When that happens, the Kubernetes deprecation policy ensures you have plenty of time to plan your next move. In the case of PodSecurityPolicy, several options are available to suit a range of needs and use cases. Start planning ahead now for PSP’s eventual removal, and please consider contributing to its replacement! Happy securing! + +**Acknowledgment:** It takes a wonderful group to make wonderful software. Thanks are due to everyone who has contributed to the PSP replacement effort, especially (in alphabetical order) Tim Allclair, Ian Coldwater, and Jordan Liggitt. It’s been a joy to work with y’all on this. diff --git a/content/en/blog/_posts/2021-04-08-cronjob-reaches-ga/controller-flowchart.svg b/content/en/blog/_posts/2021-04-08-cronjob-reaches-ga/controller-flowchart.svg new file mode 100644 index 0000000000..9357c89d40 --- /dev/null +++ b/content/en/blog/_posts/2021-04-08-cronjob-reaches-ga/controller-flowchart.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/content/en/blog/_posts/2021-04-08-cronjob-reaches-ga/index.md b/content/en/blog/_posts/2021-04-08-cronjob-reaches-ga/index.md new file mode 100644 index 0000000000..bb9214b027 --- /dev/null +++ b/content/en/blog/_posts/2021-04-08-cronjob-reaches-ga/index.md @@ -0,0 +1,105 @@ +--- +layout: blog +title: 'Kubernetes 1.21: CronJob Reaches GA' +date: 2021-04-09 +slug: kubernetes-release-1.21-cronjob-ga +--- + + **Authors:** Alay Patel (Red Hat), and Maciej Szulik (Red Hat) + +In Kubernetes v1.21, the +[CronJob](/docs/concepts/workloads/controllers/cron-jobs/) resource +reached general availability (GA). We've also substantially improved the +performance of CronJobs since Kubernetes v1.19, by implementing a new +controller. + +In Kubernetes v1.20 we launched a revised v2 controller for CronJobs, +initially as an alpha feature. Kubernetes 1.21 uses the newer controller by +default, and the CronJob resource itself is now GA (group version: `batch/v1`). + +In this article, we'll take you through the driving forces behind this new +development, give you a brief description of controller design for core +Kubernetes, and we'll outline what you will gain from this improved controller. + +The driving force behind promoting the API was Kubernetes' policy choice to +[ensure APIs move beyond beta](/blog/2020/08/21/moving-forward-from-beta/). +That policy aims to prevent APIs from being stuck in a “permanent beta” state. +Over the years the old CronJob controller implementation had received healthy +feedback from the community, with reports of several widely recognized +[issues](https://github.com/kubernetes/kubernetes/issues/82659). + +If the beta API for CronJob was to be supported as GA, the existing controller +code would need substantial rework. Instead, the SIG Apps community decided +to introduce a new controller and gradually replace the old one. + +## How do controllers work? + +Kubernetes [controllers](/docs/concepts/architecture/controller/) are control +loops that watch the state of resource(s) in your cluster, then make or +request changes where needed. Each controller tries to move part of the +current cluster state closer to the desired state. + +The v1 CronJob controller works by performing a periodic poll and sweep of all +the CronJob objects in your cluster, in order to act on them. It is a single +worker implementation that gets all CronJobs every 10 seconds, iterates over +each one of them, and syncs them to their desired state. This was the default +way of doing things almost 5 years ago when the controller was initially +written. In hindsight, we can certainly say that such an approach can +overload the API server at scale. + +These days, every core controller in kubernetes must follow the guidelines +described in [Writing Controllers](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-api-machinery/controllers.md#readme). +Among many details, that document prescribes using +[shared informers](https://www.cncf.io/blog/2019/10/15/extend-kubernetes-via-a-shared-informer/) +to “receive notifications of adds, updates, and deletes for a particular +resource”. Upon any such events, the related object(s) is placed in a queue. +Workers pull items from the queue and process them one at a time. This +approach ensures consistency and scalability. + +The picture below shows the flow of information from kubernetes API server, +through shared informers and queue, to the main part of a controller - a +reconciliation loop which is responsible for performing the core functionality. + +![Controller flowchart](controller-flowchart.svg) + +The CronJob controller V2 uses a queue that implements the DelayingInterface to +handle the scheduling aspect. This queue allows processing an element after a +specific time interval. Every time there is a change in a CronJob or its related +Jobs, the key that represents the CronJob is pushed to the queue. The main +handler pops the key, processes the CronJob, and after completion +pushes the key back into the queue for the next scheduled time interval. This is +immediately a more performant implementation, as it no longer requires a linear +scan of all the CronJobs. On top of that, this controller can be scaled by +increasing the number of workers processing the CronJobs in parallel. + +## Performance impact of the new controller {#performance-impact} + +In order to test the performance difference of the two controllers a VM instance +with 128 GiB RAM and 64 vCPUs was used to set up a single node Kubernetes cluster. +Initially, a sample workload was created with 20 CronJob instances with a schedule +to run every minute, and 2100 CronJobs running every 20 hours. Additionally, +over the next few minutes we added 1000 CronJobs with a schedule to run every +20 hours, until we reached a total of 5120 CronJobs. + +![Visualization of performance](performance-impact-graph.svg) + +We observed that for every 1000 CronJobs added, the old controller used +around 90 to 120 seconds more wall-clock time to schedule 20 Jobs every cycle. +That is, at 5120 CronJobs, the old controller took approximately 9 minutes +to create 20 Jobs. Hence, during each cycle, about 8 schedules were missed. +The new controller, implemented with architectural change explained above, +created 20 Jobs without any delay, even when we created an additional batch +of 1000 CronJobs reaching a total of 6120. + +As a closing remark, the new controller exposes a histogram metric +`cronjob_controller_cronjob_job_creation_skew_duration_seconds` which helps +monitor the time difference between when a CronJob is meant to run and when +the actual Job is created. + +Hopefully the above description is a sufficient argument to follow the +guidelines and standards set in the Kubernetes project, even for your own +controllers. As mentioned before, the new controller is on by default starting +from Kubernetes v1.21; if you want to check it out in the previous release (1.20), +you can enable the `CronJobControllerV2` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +for the kube-controller-manager: `--feature-gate="CronJobControllerV2=true"`. diff --git a/content/en/blog/_posts/2021-04-08-cronjob-reaches-ga/performance-impact-graph.svg b/content/en/blog/_posts/2021-04-08-cronjob-reaches-ga/performance-impact-graph.svg new file mode 100644 index 0000000000..976b428d91 --- /dev/null +++ b/content/en/blog/_posts/2021-04-08-cronjob-reaches-ga/performance-impact-graph.svg @@ -0,0 +1 @@ + \ No newline at end of file diff --git a/content/en/blog/_posts/2021-04-08-kubernetes-release-1.21.md b/content/en/blog/_posts/2021-04-08-kubernetes-release-1.21.md new file mode 100644 index 0000000000..ed0da32f25 --- /dev/null +++ b/content/en/blog/_posts/2021-04-08-kubernetes-release-1.21.md @@ -0,0 +1,128 @@ +--- +layout: blog +title: 'Kubernetes 1.21: Power to the Community' +date: 2021-04-08 +slug: kubernetes-1-21-release-announcement +--- + +**Authors:** [Kubernetes 1.21 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.21/release-team.md) + +We’re pleased to announce the release of Kubernetes 1.21, our first release of 2021! This release consists of 51 enhancements: 13 enhancements have graduated to stable, 16 enhancements are moving to beta, 20 enhancements are entering alpha, and 2 features have been deprecated. + +This release cycle, we saw a major shift in ownership of processes around the release team. We moved from a synchronous mode of communication, where we periodically asked the community for inputs, to a mode where the community opts-in to contribute features and/or blogs to the release. These changes have resulted in an increase in collaboration and teamwork across the community. The result of all that is reflected in Kubernetes 1.21 having the most number of features in the recent times. + +## Major Themes + +### CronJobs Graduate to Stable! +[CronJobs](/docs/concepts/workloads/controllers/cron-jobs/) (previously ScheduledJobs) has been a beta feature since Kubernetes 1.8! With 1.21 we get to finally see this widely used API graduate to stable. + +CronJobs are meant for performing regular scheduled actions such as backups, report generation, and so on. Each of those tasks should be configured to recur indefinitely (for example: once a day / week / month); you can define the point in time within that interval when the job should start. + +### Immutable Secrets and ConfigMaps +[Immutable Secrets](/docs/concepts/configuration/secret/#secret-immutable) and [ConfigMaps](/docs/concepts/configuration/configmap/#configmap-immutable) add a new field to those resource types that will reject changes to those objects if set. Secrets and ConfigMaps by default are mutable which is beneficial for pods that are able to consume changes. Mutating Secrets and ConfigMaps can also cause problems if a bad configuration is pushed for pods that use them. + +By marking Secrets and ConfigMaps as immutable you can be sure your application configuration won't change. If you want to make changes you'll need to create a new, uniquly named Secret or ConfigMap and deploy a new pod to consume that resource. Immutable resources also have scaling benefits because controllers do not need to poll the API server to watch for changes. + +This feature has graduated to stable in Kubernetes 1.21. + +### IPv4/IPv6 dual-stack support +IP addresses are a consumable resource that cluster operators and administrators need to make sure are not exhausted. In particular, public IPv4 addresses are now scarce. Having dual-stack support enables native IPv6 routing to pods and services, whilst still allowing your cluster to talk IPv4 where needed. Dual-stack cluster networking also improves a possible scaling limitation for workloads. + +Dual-stack support in Kubernetes means that pods, services, and nodes can get IPv4 addresses and IPv6 addresses. In Kubernetes 1.21 [dual-stack networking](/docs/concepts/services-networking/dual-stack/) has graduated from alpha to beta, and is now enabled by default. + +### Graceful Node Shutdown +[Graceful Node shutdown](/docs/concepts/architecture/nodes/#graceful-node-shutdown) also graduated to beta with this release (and will now be available to a much larger group of users)! This is a hugely beneficial feature that allows the kubelet to be aware of node shutdown, and gracefully terminate pods that are scheduled to that node. + +Currently, when a node shuts down, pods do not follow the expected termination lifecycle and are not shut down gracefully. This can introduce problems with a lot of different workloads. Going forward, the kubelet will be able to detect imminent system shutdown through systemd, then inform running pods so they can terminate as gracefully as possible. + +### PersistentVolume Health Monitor +Persistent Volumes (PV) are commonly used in applications to get local, file-based storage. They can be used in many different ways and help users migrate applications without needing to re-write storage backends. + +Kubernetes 1.21 has a new alpha feature which allows PVs to be monitored for health of the volume and marked accordingly if the volume becomes unhealthy. Workloads will be able to react to the health state to protect data from being written or read from a volume that is unhealthy. + +### Reducing Kubernetes Build Maintenance +Previously Kubernetes has maintained multiple build systems. This has often been a source of friction and complexity for new and current contributors. + +Over the last release cycle, a lot of work has been put in to simplify the build process, and standardize on the native Golang build tools. This should empower broader community maintenance, and lower the barrier to entry for new contributors. + +## Major Changes + +### PodSecurityPolicy Deprecation +In Kubernetes 1.21, PodSecurityPolicy is deprecated. As with all Kubernetes feature deprecations, PodSecurityPolicy will continue to be available and fully-functional for several more releases. PodSecurityPolicy, previously in the beta stage, is planned for removal in Kubernetes 1.25. + +What's next? We're developing a new built-in mechanism to help limit Pod privileges, with a working title of “PSP Replacement Policy.” Our plan is for this new mechanism to cover the key PodSecurityPolicy use cases, with greatly improved ergonomics and maintainability. To learn more, read [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future). + +### TopologyKeys Deprecation +The Service field `topologyKeys` is now deprecated; all the component features that used this field were previously alpha, and are now also deprecated. +We've replaced `topologyKeys` with a way to implement topology-aware routing, called topology-aware hints. Topology-aware hints are an alpha feature in Kubernetes 1.21. You can read more details about the replacement feature in [Topology Aware Hints](/docs/concepts/services-networking/service-topology/); the related [KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/2433-topology-aware-hints/README.md) explains the context for why we switched. + +## Other Updates + +### Graduated to Stable + +* [EndpointSlice](https://github.com/kubernetes/enhancements/issues/752) +* [Add sysctl support](https://github.com/kubernetes/enhancements/issues/34) +* [PodDisruptionBudgets](https://github.com/kubernetes/enhancements/issues/85) + +### Notable Feature Updates + +* [External client-go credential providers](https://github.com/kubernetes/enhancements/issues/541) - beta in 1.21 +* [Structured logging](https://github.com/kubernetes/enhancements/issues/1602) - graduating to beta in 1.22 +* [TTL after finish cleanup for Jobs and Pods](https://github.com/kubernetes/enhancements/issues/592) - graduated to beta + +# Release notes + +You can check out the full details of the 1.21 release in the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md). + +# Availability of release + +Kubernetes 1.21 is available for [download on GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.21.0). There are some great resources out there for getting started with Kubernetes. You can check out some [interactive tutorials](https://kubernetes.io/docs/tutorials/) on the main Kubernetes site, or run a local cluster on your machine using Docker containers with [kind](https://kind.sigs.k8s.io). If you’d like to try building a cluster from scratch, check out the [Kubernetes the Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way) tutorial by Kelsey Hightower. + +# Release Team + +This release was made possible by a very dedicated group of individuals, who came together as a team in the midst of a lot of things happening out in the world. A huge thank you to the release lead Nabarun Pal, and to everyone else on the release team for supporting each other, and working so hard to deliver the 1.21 release for the community. + +# Release Logo + +![Kubernetes 1.21 Release Logo](/images/blog/2021-04-08-kubernetes-release-1.21/globe_250px.png) + +The Kubernetes 1.21 Release Logo portrays the global nature of the Release Team, with release team members residing in timezones from UTC+8 all the way to UTC-8. The diversity of the release team brought in a lot of challenges, but the team tackled them all by adopting more asynchronous communication practices. The heptagonal globe in the release logo signifies the sheer determination of the community to overcome the challenges as they come. It celebrates the amazing teamwork of the release team over the last 3 months to bring in a fun packed Kubernetes release! + +The logo is designed by [Aravind Sekar](https://www.behance.net/noblebatman), an independent designer based out of India. Aravind helps open source communities like PyCon India in their design efforts. + +# User Highlights + +- CNCF welcomes 47 new organizations across the globe as members to advance Cloud Native technology further at the start of 2021! These [new members](https://www.cncf.io/announcements/2021/02/24/cloud-native-computing-foundation-welcomes-47-new-members-at-the-start-of-2021/) will join CNCF at the upcoming 2021 KubeCon + CloudNativeCon events, including [KubeCon + CloudNativeCom EU – Virtual](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) from May 4 – 7, 2021, and [KubeCon + CloudNativeCon NA in Los Angeles](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/) from October 12 – 15, 2021. + +# 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 a neat illustration of the depth and breadth of effort that goes into evolving this ecosystem. + +In the v1.21 release cycle, which ran for 12 weeks (January 11 to April 8), we saw contributions from [999 companies](https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1&var-period_name=v1.20.0%20-%20now&var-metric=contributions) and [1279 individuals](https://k8s.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=v1.20.0%20-%20now&var-metric=contributions&var-repogroup_name=Kubernetes&var-country_name=All&var-companies=All). + +# Ecosystem Updates + +- In the wake of rising racism & attacks on global Asian communities, read the statement from CNCF General Priyanka Sharma on the [CNCF blog](https://www.cncf.io/blog/2021/03/18/statement-from-cncf-general-manager-priyanka-sharma-on-the-unacceptable-attacks-against-aapi-and-asian-communities/) reinstating the community's commitment towards inclusive values & diversity-powered resilience. +- We now have a process in place for migration of the default branch from master → main. Learn more about the guidelines [here](k8s.dev/rename) +- CNCF and the Linux Foundation have announced the availability of their new training course, [LFS260 – Kubernetes Security Essentials](https://training.linuxfoundation.org/training/kubernetes-security-essentials-lfs260/). In addition to providing skills and knowledge on a broad range of best practices for securing container-based applications and Kubernetes platforms, the course is also a great way to prepare for the recently launched [Certified Kubernetes Security Specialist](https://training.linuxfoundation.org/certification/certified-kubernetes-security-specialist/) certification exam. + +# Event Updates + +- KubeCon + CloudNativeCon Europe 2021 will take place May 4 - 7, 2021! You can find more information about the conference [here](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/). +- [Kubernetes Community Days](https://kubernetescommunitydays.org/) are being relaunched! Q2 2021 will start with Africa and Bengaluru. + +# Upcoming release webinar + +Join the members of the Kubernetes 1.21 release team on May 13th, 2021 to learn about the major features in this release including IPv4/IPv6 dual-stack support, PersistentVolume Health Monitor, Immutable Secrets and ConfigMaps, and many more. Register here: [https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kubernetes-121-release/](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kubernetes-121-release/) + +# Get Involved + +If you’re interested in contributing to the Kubernetes community, Special Interest Groups (SIGs) are a great starting point. Many of them may align with your interests! If there are things you’d like to share with the community, you can join the weekly community meeting, or use any of the following channels: + +* Find out more about contributing to Kubernetes at the [Kubernetes Contributor website](https://www.kubernetes.dev/) +* 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://github.com/cncf/foundation/blob/master/case-study-guidelines.md) +* Read more about what’s happening with Kubernetes on the [blog](https://kubernetes.io/blog/) +* Learn more about the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team) diff --git a/content/en/blog/_posts/2021-04-12-introducing-suspended-jobs.md b/content/en/blog/_posts/2021-04-12-introducing-suspended-jobs.md new file mode 100644 index 0000000000..d03c9d0c25 --- /dev/null +++ b/content/en/blog/_posts/2021-04-12-introducing-suspended-jobs.md @@ -0,0 +1,110 @@ +--- +title: "Introducing Suspended Jobs" +date: 2021-04-12 +slug: introducing-suspended-jobs +layout: blog +--- + +**Author:** Adhityaa Chandrasekar (Google) + +[Jobs](/docs/concepts/workloads/controllers/job/) are a crucial part of +Kubernetes' API. While other kinds of workloads such as [Deployments](/docs/concepts/workloads/controllers/deployment/), +[ReplicaSets](/docs/concepts/workloads/controllers/replicaset/), +[StatefulSets](/docs/concepts/workloads/controllers/statefulset/), and +[DaemonSets](/docs/concepts/workloads/controllers/daemonset/) +solve use-cases that require Pods to run forever, Jobs are useful when Pods need +to run to completion. Commonly used in parallel batch processing, Jobs can be +used in a variety of applications ranging from video rendering and database +maintenance to sending bulk emails and scientific computing. + +While the amount of parallelism and the conditions for Job completion are +configurable, the Kubernetes API lacked the ability to suspend and resume Jobs. +This is often desired when cluster resources are limited and a higher priority +Job needs to execute in the place of another Job. Deleting the lower priority +Job is a poor workaround as Pod completion history and other metrics associated +with the Job will be lost. + +With the recent Kubernetes 1.21 release, you will be able to suspend a Job by +updating its spec. The feature is currently in **alpha** and requires you to +enable the `SuspendJob` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/) +and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) +in order to use it. + +## API changes + +We introduced a new boolean field `suspend` into the `.spec` of Jobs. Let's say +I create the following Job: + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: my-job +spec: + suspend: true + parallelism: 2 + completions: 10 + template: + spec: + containers: + - name: my-container + image: busybox + command: ["sleep", "5"] + restartPolicy: Never +``` + +Jobs are not suspended by default, so I'm explicitly setting the `suspend` field +to _true_ in the `.spec` of the above Job manifest. In the above example, the +Job controller will refrain from creating Pods until I'm ready to start the Job, +which I can do by updating `suspend` to false. + +As another example, consider a Job that was created with the `suspend` field +omitted. The Job controller will happily create Pods to work towards Job +completion. However, before the Job completes, if I explicitly set the field to +true with a Job update, the Job controller will terminate all active Pods that +are running and will wait indefinitely for the flag to be flipped back to false. +Typically, Pod termination is done by sending a SIGTERM signal to all container +processes in the Pod; the [graceful termination period](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) +defined in the Pod spec will be honoured. Pods terminated this way will not be +counted as failures by the Job controller. + +It is important to understand that succeeded and failed Pods from the past will +continue to exist after you suspend a Job. That is, that they will count towards +Job completion once you resume it. You can verify this by looking at Job's +status before and after suspension. + +Read the [documentation](/docs/concepts/workloads/controllers/job#suspending-a-job) +for a full overview of this new feature. + +## Where is this useful? + +Let's say I'm the operator of a large cluster. I have many users submitting Jobs +to the cluster, but not all Jobs are created equal — some Jobs are more +important than others. Cluster resources aren't infinite either, so all users +must share resources. If all Jobs were created in the suspended state and placed +in a pending queue, I can achieve priority-based Job scheduling by resuming Jobs +in the right order. + +As another motivational use-case, consider a cloud provider where compute +resources are cheaper at night than in the morning. If I have a long-running Job +that takes multiple days to complete, being able to suspend the Job in the +morning and then resume it in the evening every day can reduce costs. + +Since this field is a part of the Job spec, [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/) +automatically get this feature for free too. + +## References and next steps + +If you're interested in a deeper dive into the rationale behind this feature and +the decisions we have taken, consider reading the [enhancement proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/2232-suspend-jobs). +There's more detail on suspending and resuming jobs in the documentation for [Job](/docs/concepts/workloads/controllers/job#suspending-a-job). + +As previously mentioned, this feature is currently in alpha and is available +only if you explicitly opt-in through the `SuspendJob` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/). +If this is a feature you're interested in, please consider testing suspended +Jobs in your cluster and providing feedback. You can discuss this enhancement [on GitHub](https://github.com/kubernetes/enhancements/issues/2232). +The SIG Apps community also [meets regularly](https://github.com/kubernetes/community/tree/master/sig-apps#meetings) +and can be reached through [Slack or the mailing list](https://github.com/kubernetes/community/tree/master/sig-apps#contact). +Barring any unexpected changes to the API, we intend to graduate the feature to +beta in Kubernetes 1.22, so that the feature becomes available by default. diff --git a/content/en/blog/_posts/2021-04-13-kube-state-metrics-goes-v-2-0.md b/content/en/blog/_posts/2021-04-13-kube-state-metrics-goes-v-2-0.md new file mode 100644 index 0000000000..822880547d --- /dev/null +++ b/content/en/blog/_posts/2021-04-13-kube-state-metrics-goes-v-2-0.md @@ -0,0 +1,45 @@ +--- +layout: blog +title: "kube-state-metrics goes v2.0" +date: 2021-04-13 +slug: kube-state-metrics-v-2-0 +--- + +**Authors:** Lili Cosic (Red Hat), Frederic Branczyk (Polar Signals), Manuel Rüger (Sony Interactive Entertainment), Tariq Ibrahim (Salesforce) + +## What? + +[kube-state-metrics](https://github.com/kubernetes/kube-state-metrics), a project under the Kubernetes organization, generates Prometheus format metrics based on the current state of the Kubernetes native resources. It does this by listening to the Kubernetes API and gathering information about resources and objects, e.g. Deployments, Pods, Services, and StatefulSets. A full list of resources is available in the [documentation](https://github.com/kubernetes/kube-state-metrics/tree/master/docs) of kube-state-metrics. + +## Why? + +There are numerous useful metrics and insights provided by `kube-state-metrics` right out of the box! These metrics can be used to serve as an insight into your cluster: Either through metrics alone, in the form of dashboards, or through an alerting pipeline. To provide a few examples: + +* `kube_pod_container_status_restarts_total` can be used to alert on a crashing pod. +* `kube_deployment_status_replicas` which together with `kube_deployment_status_replicas_available` can be used to alert on whether a deployment is rolled out successfully or stuck. +* `kube_pod_container_resource_requests` and `kube_pod_container_resource_limits` can be used in capacity planning dashboards. + +And there are many more metrics available! To learn more about the other metrics and their details, please check out the [documentation](https://github.com/kubernetes/kube-state-metrics/tree/master/docs#readme). + +## What is new in v2.0? + +So now that we know what kube-state-metrics is, we are excited to announce the next release: kube-state-metrics v2.0! This release was long-awaited and started with an alpha release in September 2020. To ease maintenance we removed tech debt and also adjusted some confusing wording around user-facing flags and APIs. We also removed some metrics that caused unnecessarily high cardinality in Prometheus! For the 2.0 release, we took the time to set up scale and performance testing. This allows us to better understand if we hit any issues in large clusters and also to document resource request recommendations for your clusters. In this release (and v1.9.8) container builds providing support for multiple architectures were introduced allowing you to run kube-state-metrics on ARM, ARM64, PPC64 and S390x as well! + +So without further ado, here is the list of more noteworthy user-facing breaking changes. A full list of changes, features and bug fixes is available in the changelog at the end of this post. + +* Flag `--namespace` was renamed to `--namespaces`. If you are using the former, please make sure to update the flag before deploying the latest release. +* Flag `--collectors` was renamed to `--resources`. +* Flags `--metric-blacklist` and `--metric-whitelist` were renamed to `--metric-denylist` and `--metric-allowlist`. +* Flag `--metric-labels-allowlist` allows you to specify a list of Kubernetes labels that get turned into the dimensions of the `kube__labels` metrics. By default, the metric contains only name and namespace labels. +* All metrics with a prefix of `kube_hpa_*` were renamed to `kube_horizontalpodautoscaler_*`. +* Metric labels that relate to Kubernetes were converted to snake_case. +* If you are importing kube-state-metrics as a library, we have updated our go module path to `k8s.io/kube-state-metrics/v2` +* All deprecated stable metrics were removed as per the [notice in the v1.9 release](https://github.com/kubernetes/kube-state-metrics/tree/release-1.9/docs#metrics-deprecation). +* `quay.io/coreos/kube-state-metrics` images will no longer be updated. `k8s.gcr.io/kube-state-metrics/kube-state-metrics` is the new canonical location. +* The helm chart that is part of the kubernetes/kube-state-metrics repository is deprecated. https://github.com/prometheus-community/helm-charts will be its new location. + +For the full list of v2.0 release changes includes features, bug fixes and other breaking changes see the full [CHANGELOG](https://github.com/kubernetes/kube-state-metrics/blob/master/CHANGELOG.md). + +## Found a problem? + +Thanks to all our users for testing so far and thank you to all our contributors for your issue reports as well as code and documentation changes! If you find any problems, we the [maintainers](https://github.com/kubernetes/kube-state-metrics/blob/master/OWNERS) are more than happy to look into them, so please report them by opening a [GitHub issue](https://github.com/kubernetes/kube-state-metrics/issues/new/choose). diff --git a/content/en/blog/_posts/2021-04-14-local-storage-features-go-beta.md b/content/en/blog/_posts/2021-04-14-local-storage-features-go-beta.md new file mode 100644 index 0000000000..457e9238f3 --- /dev/null +++ b/content/en/blog/_posts/2021-04-14-local-storage-features-go-beta.md @@ -0,0 +1,216 @@ +--- +layout: blog +title: "Local Storage: Storage Capacity Tracking, Distributed Provisioning and Generic Ephemeral Volumes hit Beta" +date: 2021-04-14 +slug: local-storage-features-go-beta +--- + + **Authors:** Patrick Ohly (Intel) + +The ["generic ephemeral +volumes"](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes) +and ["storage capacity +tracking"](/docs/concepts/storage/storage-capacity/) +features in Kubernetes are getting promoted to beta in Kubernetes +1.21. Together with the [distributed provisioning +support](https://github.com/kubernetes-csi/external-provisioner#deployment-on-each-node) +in the CSI external-provisioner, development and deployment of +Container Storage Interface (CSI) drivers which manage storage locally +on a node become a lot easier. + +This blog post explains how such drivers worked before and how these +features can be used to make drivers simpler. + +## Problems we are solving + +There are drivers for local storage, like +[TopoLVM](https://github.com/cybozu-go/topolvm) for traditional disks +and [PMEM-CSI](https://intel.github.io/pmem-csi/latest/README.html) +for [persistent memory](https://pmem.io/). They work and are ready for +usage today also on older Kubernetes releases, but making that possible +was not trivial. + +### Central component required + +The first problem is volume provisioning: it is handled through the +Kubernetes control plane. Some component must react to +[PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) +(PVCs) +and create volumes. Usually, that is handled by a central deployment +of the [CSI +external-provisioner](https://kubernetes-csi.github.io/docs/external-provisioner.html) +and a CSI driver component that then connects to the storage +backplane. But for local storage, there is no such backplane. + +TopoLVM solved this by having its different components communicate +with each other through the Kubernetes API server by creating and +reacting to custom resources. So although TopoLVM is based on CSI, a +standard that is independent of a particular container orchestrator, +TopoLVM only works on Kubernetes. + +PMEM-CSI created its own storage backplane with communication through +gRPC calls. Securing that communication depends on TLS certificates, +which made driver deployment more complicated. + +### Informing Pod scheduler about capacity + +The next problem is scheduling. When volumes get created independently +of pods ("immediate binding"), the CSI driver must pick a node without +knowing anything about the pod(s) that are going to use it. Topology +information then forces those pods to run on the node where the volume +was created. If other resources like RAM or CPU are exhausted there, +the pod cannot start. This can be avoided by configuring in the +StorageClass that volume creation is meant to wait for the first pod +that uses a volume (`volumeBinding: WaitForFirstConsumer`). In that +mode, the Kubernetes scheduler tentatively picks a node based on other +constraints and then the external-provisioner is asked to create a +volume such that it is usable there. If local storage is exhausted, +the provisioner [can +ask](https://github.com/kubernetes-csi/external-provisioner/blob/master/doc/design.md) +for another scheduling round. But without information about available +capacity, the scheduler might always pick the same unsuitable node. + +Both TopoLVM and PMEM-CSI solved this with scheduler extenders. This +works, but it is hard to configure when deploying the driver because +communication between kube-scheduler and the driver is very dependent +on how the cluster was set up. + +### Rescheduling + +A common use case for local storage is scratch space. A better fit for +that use case than persistent volumes are ephemeral volumes that get +created for a pod and destroyed together with it. The initial API for +supporting ephemeral volumes with CSI drivers (hence called ["*CSI* +ephemeral +volumes"](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes)) +was [designed for light-weight +volumes](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20190122-csi-inline-volumes.md) +where volume creation is unlikely to fail. Volume creation happens +after pods have been permanently scheduled onto a node, in contrast to +the traditional provisioning where volume creation is tried before +scheduling a pod onto a node. CSI drivers must be modified to support +"CSI ephemeral volumes", which was done for TopoLVM and PMEM-CSI. But +due to the design of the feature in Kubernetes, pods can get stuck +permanently if storage capacity runs out on a node. The scheduler +extenders try to avoid that, but cannot be 100% reliable. + +## Enhancements in Kubernetes 1.21 + +### Distributed provisioning + +Starting with [external-provisioner +v2.1.0](https://github.com/kubernetes-csi/external-provisioner/releases/tag/v2.1.0), +released for Kubernetes 1.20, provisioning can be handled by +external-provisioner instances that get [deployed together with the +CSI driver on each +node](https://github.com/kubernetes-csi/external-provisioner#deployment-on-each-node) +and then cooperate to provision volumes ("distributed +provisioning"). There is no need any more to have a central component +and thus no need for communication between nodes, at least not for +provisioning. + +### Storage capacity tracking + +A scheduler extender still needs some way to find out about capacity +on each node. When PMEM-CSI switched to distributed provisioning in +v0.9.0, this was done by querying the metrics data exposed by the +local driver containers. But it is better also for users to eliminate +the need for a scheduler extender completely because the driver +deployment becomes simpler. [Storage capacity +tracking](/docs/concepts/storage/storage-capacity/), [introduced in +1.19](/blog/2020/09/01/ephemeral-volumes-with-storage-capacity-tracking/) +and promoted to beta in Kubernetes 1.21, achieves that. It works by +publishing information about capacity in `CSIStorageCapacity` +objects. The scheduler itself then uses that information to filter out +unsuitable nodes. Because information might be not quite up-to-date, +pods may still get assigned to nodes with insufficient storage, it's +just less likely and the next scheduling attempt for a pod should work +better once the information got refreshed. + +### Generic ephemeral volumes + +So CSI drivers still need the ability to recover from a bad scheduling +decision, something that turned out to be impossible to implement for +"CSI ephemeral volumes". ["*Generic* ephemeral +volumes"](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes), +another feature that got promoted to beta in 1.21, don't have that +limitation. This feature adds a controller that will create and manage +PVCs with the lifetime of the Pod and therefore the normal recovery +mechanism also works for them. Existing storage drivers will be able +to process these PVCs without any new logic to handle this new +scenario. + +## Known limitations + +Both generic ephemeral volumes and storage capacity tracking increase +the load on the API server. Whether that is a problem depends a lot on +the kind of workload, in particular how many pods have volumes and how +often those need to be created and destroyed. + +No attempt was made to model how scheduling decisions affect storage +capacity. That's because the effect can vary considerably depending on +how the storage system handles storage. The effect is that multiple +pods with unbound volumes might get assigned to the same node even +though there is only sufficient capacity for one pod. Scheduling +should recover, but it would be more efficient if the scheduler knew +more about storage. + +Because storage capacity gets published by a running CSI driver and +the cluster autoscaler needs information about a node that hasn't been +created yet, it will currently not scale up a cluster for pods that +need volumes. There is an [idea how to provide that +information](https://github.com/kubernetes/autoscaler/pull/3887), but +more work is needed in that area. + +Distributed snapshotting and resizing are not currently supported. It +should be doable to adapt the respective sidecar and there are +tracking issues for external-snapshotter and external-resizer open +already, they just need some volunteer. + +The recovery from a bad scheduling decising can fail for pods with +multiple volumes, in particular when those volumes are local to nodes: +if one volume can be created and then storage is insufficient for +another volume, the first volume continues to exist and forces the +scheduler to put the pod onto the node of that volume. There is an +idea how do deal with this, [rolling back the provision of the +volume](https://github.com/kubernetes/enhancements/pull/1703), but +this is only in the very early stages of brainstorming and not even a +merged KEP yet. For now it is better to avoid creating pods with more +than one persistent volume. + +## Enabling the new features and next steps + +With the feature entering beta in the 1.21 release, no additional actions are needed to enable it. Generic +ephemeral volumes also work without changes in CSI drivers. For more +information, see the +[documentation](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes) +and the [previous blog +post](/blog/2020/09/01/ephemeral-volumes-with-storage-capacity-tracking/) +about it. The API has not changed at all between alpha and beta. + +For the other two features, the external-provisioner documentation +explains how CSI driver developers must change how their driver gets +deployed to support [storage capacity +tracking](https://github.com/kubernetes-csi/external-provisioner#capacity-support) +and [distributed +provisioning](https://github.com/kubernetes-csi/external-provisioner#deployment-on-each-node). +These two features are independent, therefore it is okay to enable +only one of them. + +[SIG +Storage](https://github.com/kubernetes/community/tree/master/sig-storage) +would like to hear from you if you are using these new features. We +can be reached through +[email](https://groups.google.com/forum/#!forum/kubernetes-sig-storage), +[Slack](https://slack.k8s.io/) (channel [`#sig-storage`](https://kubernetes.slack.com/messages/sig-storage)) and in the +[regular SIG +meeting](https://github.com/kubernetes/community/tree/master/sig-storage#meeting). +A description of your workload would be very useful to validate design +decisions, set up performance tests and eventually promote these +features to GA. + +## Acknowledgements + +Thanks a lot to the members of the community who have contributed to these +features or given feedback including members of SIG Scheduling, SIG Auth, +and of course SIG Storage! diff --git a/content/en/blog/_posts/2021-04-15-Three-Tenancy-Models-for-Kubernetes.md b/content/en/blog/_posts/2021-04-15-Three-Tenancy-Models-for-Kubernetes.md new file mode 100644 index 0000000000..a3687cf5fd --- /dev/null +++ b/content/en/blog/_posts/2021-04-15-Three-Tenancy-Models-for-Kubernetes.md @@ -0,0 +1,80 @@ +--- +layout: blog +title: 'Three Tenancy Models For Kubernetes' +date: 2021-04-15 +slug: three-tenancy-models-for-kubernetes +--- + +**Authors:** Ryan Bezdicek (Medtronic), Jim Bugwadia (Nirmata), Tasha Drew (VMware), Fei Guo (Alibaba), Adrian Ludwin (Google) + +Kubernetes clusters are typically used by several teams in an organization. In other cases, Kubernetes may be used to deliver applications to end users requiring segmentation and isolation of resources across users from different organizations. Secure sharing of Kubernetes control plane and worker node resources allows maximizing productivity and saving costs in both cases. + +The Kubernetes Multi-Tenancy Working Group is chartered with defining tenancy models for Kubernetes and making it easier to operationalize tenancy related use cases. This blog post, from the working group members, describes three common tenancy models and introduces related working group projects. + +We will also be presenting on this content and discussing different use cases at our Kubecon EU 2021 panel session, [Multi-tenancy vs. Multi-cluster: When Should you Use What?](https://sched.co/iE66). + +## Namespaces as a Service + +With the *namespaces-as-a-service* model, tenants share a cluster and tenant workloads are restricted to a set of Namespaces assigned to the tenant. The cluster control plane resources like the API server and scheduler, and worker node resources like CPU, memory, etc. are available for use across all tenants. + +To isolate tenant workloads, each namespace must also contain: +* **[role bindings](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding):** for controlling access to the namespace +* **[network policies](/docs/concepts/services-networking/network-policies/):** to prevent network traffic across tenants +* **[resource quotas](/docs/concepts/policy/resource-quotas/):** to limit usage and ensure fairness across tenants + +With this model, tenants share cluster-wide resources like ClusterRoles and CustomResourceDefinitions (CRDs) and hence cannot create or update these cluster-wide resources. + +The [Hierarchical Namespace Controller (HNC)](/blog/2020/08/14/introducing-hierarchical-namespaces/) project makes it easier to manage namespace based tenancy by allowing users to create additional namespaces under a namespace, and propagating resources within the namespace hierarchy. This allows self-service namespaces for tenants, without requiring cluster-wide permissions. + +The [Multi-Tenancy Benchmarks (MTB)](https://github.com/kubernetes-sigs/multi-tenancy/tree/master/benchmarks) project provides benchmarks and a command-line tool that performs several configuration and runtime checks to report if tenant namespaces are properly isolated and the necessary security controls are implemented. + +## Clusters as a Service + +With the *clusters-as-a-service* usage model, each tenant gets their own cluster. This model allows tenants to have different versions of cluster-wide resources such as CRDs, and provides full isolation of the Kubernetes control plane. + +The tenant clusters may be provisioned using projects like [Cluster API (CAPI)](https://cluster-api.sigs.k8s.io/) where a management cluster is used to provision multiple workload clusters. A workload cluster is assigned to a tenant and tenants have full control over cluster resources. Note that in most enterprises a central platform team may be responsible for managing required add-on services such as security and monitoring services, and for providing cluster lifecycle management services such as patching and upgrades. A tenant administrator may be restricted from modifying the centrally managed services and other critical cluster information. + +## Control planes as a Service + +In a variation of the *clusters-as-a-service* model, the tenant cluster may be a **virtual cluster** where each tenant gets their own dedicated Kubernetes control plane but share worker node resources. As with other forms of virtualization, users of a virtual cluster see no significant differences between a virtual cluster and other Kubernetes clusters. This is sometimes referred to as `Control Planes as a Service` (CPaaS). + +A virtual cluster of this type shares worker node resources and workload state independent control plane components, like the scheduler. Other workload aware control-plane components, like the API server, are created on a per-tenant basis to allow overlaps, and additional components are used to synchronize and manage state across the per-tenant control plane and the underlying shared cluster resources. With this model users can manage their own cluster-wide resources. + +The [Virtual Cluster](https://github.com/kubernetes-sigs/multi-tenancy/tree/master/incubator/virtualcluster) project implements this model, where a `supercluster` is shared by multiple `virtual clusters`. The [Cluster API Nested](https://github.com/kubernetes-sigs/cluster-api-provider-nested) project is extending this work to conform to the CAPI model, allowing use of familiar API resources to provision and manage virtual clusters. + +## Security considerations + +Cloud native security involves different system layers and lifecycle phases as described in the [Cloud Native Security Whitepaper](/blog/2020/11/18/cloud-native-security-for-your-clusters) from CNCF SIG Security. Without proper security measures implemented across all layers and phases, Kubernetes tenant isolation can be compromised and a security breach with one tenant can threaten other tenants. + +It is important for any new user to Kubernetes to realize that the default installation of a new upstream Kubernetes cluster is not secure, and you are going to need to invest in hardening it in order to avoid security issues. + +At a minimum, the following security measures are required: +* image scanning: container image vulnerabilities can be exploited to execute commands and access additional resources. +* [RBAC](/docs/reference/access-authn-authz/rbac/): for *namespaces-as-a-service* user roles and permissions must be properly configured at a per-namespace level; for other models tenants may need to be restricted from accessing centrally managed add-on services and other cluster-wide resources. +* [network policies](/docs/concepts/services-networking/network-policies/): for *namespaces-as-a-service* default network policies that deny all ingress and egress traffic are recommended to prevent cross-tenant network traffic and may also be used as a best practice for other tenancy models. +* [Kubernetes Pod Security Standards](/docs/concepts/security/pod-security-standards/): to enforce Pod hardening best practices the `Restricted` policy is recommended as the default for tenant workloads with exclusions configured only as needed. +* [CIS Benchmarks for Kubernetes](https://www.cisecurity.org/benchmark/kubernetes/): the CIS Benchmarks for Kubernetes guidelines should be used to properly configure Kubernetes control-plane and worker node components. + +Additional recommendations include using: +* policy engines: for configuration security best practices, such as only allowing trusted registries. +* runtime scanners: to detect and report runtime security events. +* VM-based container sandboxing: for stronger data plane isolation. + +While proper security is required independently of tenancy models, not having essential security controls like [pod security](/docs/concepts/security/pod-security-standards/) in a shared cluster provides attackers with means to compromise tenancy models and possibly access sensitive information across tenants increasing the overall risk profile. + +## Summary + +A 2020 CNCF survey showed that production Kubernetes usage has increased by over 300% since 2016. As an increasing number of Kubernetes workloads move to production, organizations are looking for ways to share Kubernetes resources across teams for agility and cost savings. + +The **namespaces as a service** tenancy model allows sharing clusters and hence enables resource efficiencies. However, it requires proper security configurations and has limitations as all tenants share the same cluster-wide resources. + +The **clusters as a service** tenancy model addresses these limitations, but with higher management and resource overhead. + +The **control planes as a service** model provides a way to share resources of a single Kubernetes cluster and also let tenants manage their own cluster-wide resources. Sharing worker node resources increases resource effeciencies, but also exposes cross tenant security and isolation concerns that exist for shared clusters. + + In many cases, organizations will use multiple tenancy models to address different use cases and as different product and development teams will have varying needs. Following security and management best practices, such as applying [Pod Security Standards](/docs/concepts/security/pod-security-standards/) and not using the `default` namespace, makes it easer to switch from one model to another. + +The [Kubernetes Multi-Tenancy Working Group](https://github.com/kubernetes-sigs/multi-tenancy) has created several projects like [Hierarchical Namespaces Controller](https://github.com/kubernetes-sigs/multi-tenancy/tree/master/incubator/hnc), [Virtual Cluster](https://github.com/kubernetes-sigs/multi-tenancy/tree/master/incubator/virtualcluster) / [CAPI Nested](https://github.com/kubernetes-sigs/cluster-api-provider-nested), and [Multi-Tenancy Benchmarks](https://github.com/kubernetes-sigs/multi-tenancy/tree/master/benchmarks) to make it easier to provision and manage multi-tenancy models. + +If you are interested in multi-tenancy topics, or would like to share your use cases, please join us in an upcoming [community meeting](https://github.com/kubernetes/community/blob/master/wg-multitenancy/README.md) or reach out on the *wg-multitenancy channel* on the [Kubernetes slack](https://slack.k8s.io/). + diff --git a/content/en/blog/_posts/2021-04-16-volume-health-monitoring-alpha.md b/content/en/blog/_posts/2021-04-16-volume-health-monitoring-alpha.md new file mode 100644 index 0000000000..99b2fd65b2 --- /dev/null +++ b/content/en/blog/_posts/2021-04-16-volume-health-monitoring-alpha.md @@ -0,0 +1,95 @@ +--- +layout: blog +title: "Volume Health Monitoring Alpha Update" +date: 2021-04-16 +slug: volume-health-monitoring-alpha-update +--- + +**Author:** Xing Yang (VMware) + +The CSI Volume Health Monitoring feature, originally introduced in 1.19 has undergone a large update for the 1.21 release. + +## Why add Volume Health Monitoring to Kubernetes? + +Without Volume Health Monitoring, Kubernetes has no knowledge of the state of the underlying volumes of a storage system after a PVC is provisioned and used by a Pod. Many things could happen to the underlying storage system after a volume is provisioned in Kubernetes. For example, the volume could be deleted by accident outside of Kubernetes, the disk that the volume resides on could fail, it could be out of capacity, the disk may be degraded which affects its performance, and so on. Even when the volume is mounted on a pod and used by an application, there could be problems later on such as read/write I/O errors, file system corruption, accidental unmounting of the volume outside of Kubernetes, etc. It is very hard to debug and detect root causes when something happened like this. + +Volume health monitoring can be very beneficial to Kubernetes users. It can communicate with the CSI driver to retrieve errors detected by the underlying storage system. PVC events can be reported up to the user to take action. For example, if the volume is out of capacity, they could request a volume expansion to get more space. + +## What is Volume Health Monitoring? + +CSI Volume Health Monitoring allows CSI Drivers to detect abnormal volume conditions from the underlying storage systems and report them as events on PVCs or Pods. + +The Kubernetes components that monitor the volumes and report events with volume health information include the following: + +* Kubelet, in addition to gathering the existing volume stats will watch the volume health of the PVCs on that node. If a PVC has an abnormal health condition, an event will be reported on the pod object using the PVC. If multiple pods are using the same PVC, events will be reported on all pods using that PVC. +* An [External Volume Health Monitor Controller](https://github.com/kubernetes-csi/external-health-monitor) watches volume health of the PVCs and reports events on the PVCs. + +Note that the node side volume health monitoring logic was an external agent when this feature was first introduced in the Kubernetes 1.19 release. In Kubernetes 1.21, the node side volume health monitoring logic was moved from the external agent into the Kubelet, to avoid making duplicate CSI function calls. With this change in 1.21, a new alpha [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `CSIVolumeHealth` was introduced for the volume health monitoring logic in Kubelet. + +Currently the Volume Health Monitoring feature is informational only as it only reports abnormal volume health events on PVCs or Pods. Users will need to check these events and manually fix the problems. This feature serves as a stepping stone towards programmatic detection and resolution of volume health issues by Kubernetes in the future. + +## How do I use Volume Health on my Kubernetes Cluster? + +To use the Volume Health feature, first make sure the CSI driver you are using supports this feature. Refer to this [CSI drivers doc](https://kubernetes-csi.github.io/docs/drivers.html) to find out which CSI drivers support this feature. + +To enable Volume Health Monitoring from the node side, the alpha feature gate `CSIVolumeHealth` needs to be enabled. + +If a CSI driver supports the Volume Health Monitoring feature from the controller side, events regarding abnormal volume conditions will be recorded on PVCs. + +If a CSI driver supports the Volume Health Monitoring feature from the controller side, user can also get events regarding node failures if the `enable-node-watcher` flag is set to true when deploying the External Health Monitor Controller. When a node failure event is detected, an event will be reported on the PVC to indicate that pods using this PVC are on a failed node. + +If a CSI driver supports the Volume Health Monitoring feature from the node side, events regarding abnormal volume conditions will be recorded on pods using the PVCs. + +## As a storage vendor, how do I add support for volume health to my CSI driver? + +Volume Health Monitoring includes two parts: +* An External Volume Health Monitoring Controller monitors volume health from the controller side. +* Kubelet monitors volume health from the node side. + +For details, see the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md) and the [Kubernetes-CSI Driver Developer Guide](https://kubernetes-csi.github.io/docs/volume-health-monitor.html). + +There is a sample implementation for volume health in [CSI host path driver](https://github.com/kubernetes-csi/csi-driver-host-path). + +### Controller Side Volume Health Monitoring + +To learn how to deploy the External Volume Health Monitoring controller, see [CSI external-health-monitor-controller](https://kubernetes-csi.github.io/docs/external-health-monitor-controller.html) in the CSI documentation. + +The External Health Monitor Controller calls either `ListVolumes` or `ControllerGetVolume` CSI RPC and reports VolumeConditionAbnormal events with messages on PVCs if abnormal volume conditions are detected. Only CSI drivers with `LIST_VOLUMES` and `VOLUME_CONDITION` controller capability or `GET_VOLUME` and `VOLUME_CONDITION` controller capability support Volume Health Monitoring in the external controller. + +To implement the volume health feature from the controller side, a CSI driver **must** add support for the new controller capabilities. + +If a CSI driver supports `LIST_VOLUMES` and `VOLUME_CONDITION` controller capabilities, it **must** implement controller RPC `ListVolumes` and report the volume condition in the response. + +If a CSI driver supports `GET_VOLUME` and `VOLUME_CONDITION` controller capability, it **must** implement controller PRC `ControllerGetVolume` and report the volume condition in the response. + +If a CSI driver supports `LIST_VOLUMES`, `GET_VOLUME`, and `VOLUME_CONDITION` controller capabilities, only `ListVolumes` CSI RPC will be invoked by the External Health Monitor Controller. + +### Node Side Volume Health Monitoring + +Kubelet calls `NodeGetVolumeStats` CSI RPC and reports VolumeConditionAbnormal events with messages on Pods if abnormal volume conditions are detected. Only CSI drivers with `VOLUME_CONDITION` node capability support Volume Health Monitoring in Kubelet. + +To implement the volume health feature from the node side, a CSI driver **must** add support for the new node capabilities. + +If a CSI driver supports `VOLUME_CONDITION` node capability, it **must** report the volume condition in node RPC `NodeGetVoumeStats`. + +## What’s next? + +Depending on feedback and adoption, the Kubernetes team plans to push the CSI volume health implementation to beta in either 1.22 or 1.23. + +We are also exploring how to use volume health information for programmatic detection and automatic reconcile in Kubernetes. + +## How can I learn more? + +To learn the design details for Volume Health Monitoring, read the [Volume Health Monitor](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1432-volume-health-monitor) enhancement proposal. + +The Volume Health Monitor controller source code is at [https://github.com/kubernetes-csi/external-health-monitor](https://github.com/kubernetes-csi/external-health-monitor). + +There are also more details about volume health checks in the [Container Storage Interface Documentation](https://kubernetes-csi.github.io/docs/). + +## How do I get involved? + +The [Kubernetes Slack channel #csi](https://kubernetes.slack.com/messages/csi) and any of the [standard SIG Storage communication channels](https://github.com/kubernetes/community/blob/master/sig-storage/README.md#contact) are great mediums to reach out to the SIG Storage and the CSI team. + +We offer a huge thank you to the contributors who helped release this feature in 1.21. We want to thank Yuquan Ren ([NickrenREN](https://github.com/nickrenren)) who implemented the initial volume health monitor controller and agent in the external health monitor repo, thank Ran Xu ([fengzixu](https://github.com/fengzixu)) who moved the volume health monitoring logic from the external agent to Kubelet in 1.21, and we offer special thanks to the following people for their insightful reviews: David Ashpole ([dashpole](https://github.com/dashpole)), Michelle Au ([msau42](https://github.com/msau42)), David Eads ([deads2k](https://github.com/deads2k)), Elana Hashman ([ehashman](https://github.com/ehashman)), Seth Jennings ([sjenning](https://github.com/sjenning)), and Jiawei Wang ([Jiawei0227](https://github.com/Jiawei0227)). + +Those interested in getting involved with the design and development of CSI or any part of the Kubernetes Storage system, join the [Kubernetes Storage Special Interest Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG). We’re rapidly growing and always welcome new contributors. diff --git a/content/en/blog/_posts/2021-04-19-introducing-indexed-jobs.md b/content/en/blog/_posts/2021-04-19-introducing-indexed-jobs.md new file mode 100644 index 0000000000..990dd6308b --- /dev/null +++ b/content/en/blog/_posts/2021-04-19-introducing-indexed-jobs.md @@ -0,0 +1,95 @@ +--- +title: "Introducing Indexed Jobs" +date: 2021-04-19 +slug: introducing-indexed-jobs +--- + +**Author:** Aldo Culquicondor (Google) + +Once you have containerized a non-parallel [Job](/docs/concepts/workloads/controllers/job/), +it is quite easy to get it up and running on Kubernetes without modifications to +the binary. In most cases, when running parallel distributed Jobs, you had +to set a separate system to partition the work among the workers. For +example, you could set up a task queue to [assign one work item to each +Pod](/docs/tasks/job/coarse-parallel-processing-work-queue/) or [multiple items +to each Pod until the queue is emptied](/docs/tasks/job/fine-parallel-processing-work-queue/). + +The Kubernetes 1.21 release introduces a new field to control Job _completion mode_, +a configuration option that allows you to control how Pod completions affect the +overall progress of a Job, with two possible options (for now): + +- `NonIndexed` (default): the Job is considered complete when there has been + a number of successfully completed Pods equal to the specified number in + `.spec.completions`. In other words, each Pod completion is homologous to + each other. Any Job you might have created before the introduction of + completion modes is implicitly NonIndexed. +- `Indexed`: the Job is considered complete when there is one successfully + completed Pod associated with each index from 0 to `.spec.completions-1`. The + index is exposed to each Pod in the `batch.kubernetes.io/job-completion-index` + annotation and the `JOB_COMPLETION_INDEX` environment variable. + +You can start using Jobs with Indexed completion mode, or Indexed Jobs, for +short, to easily start parallel Jobs. Then, each worker Pod can have a statically +assigned partition of the data based on the index. This saves you from having to +set up a queuing system or even having to modify your binary! + +## Creating an Indexed Job + +To create an Indexed Job, you just have to add `completionMode: Indexed` to the +Job spec and make use of the `JOB_COMPLETION_INDEX` environment variable. + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: 'sample-job' +spec: + completions: 3 + parallelism: 3 + completionMode: Indexed + template: + spec: + restartPolicy: Never + containers: + - command: + - 'bash' + - '-c' + - 'echo "My partition: ${JOB_COMPLETION_INDEX}"' + image: 'docker.io/library/bash' + name: 'sample-load' +``` + +Note that completion mode is an alpha feature in the 1.21 release. To be able to +use it in your cluster, make sure to enable the `IndexedJob` [feature +gate](/docs/reference/command-line-tools-reference/feature-gates/) on the +[API server](docs/reference/command-line-tools-reference/kube-apiserver/) and +the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/). + +When you run the example, you will see that each of the three created Pods gets a +different completion index. For the user's convenience, the control plane sets the +`JOB_COMPLETION_INDEX` environment variable, but you can choose to [set your +own](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) +or [expose the index as a file](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/). + +See [Indexed Job for parallel processing with static work +assignment](/docs/tasks/job/indexed-parallel-processing-static/) for a +step-by-step guide, and a few more examples. + +## Future plans + +SIG Apps envisions that there might be more completion modes that enable more +use cases for the Job API. We welcome you to open issues in +[kubernetes/kubernetes](https://github.com/kubernetes/kubernetes) with your +suggestions. + +In particular, we are considering an `IndexedAndUnique` mode where the indexes +are not just available as annotation, but they are part of the Pod names, +similar to {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}. +This should facilitate inter-Pod communication for tightly coupled Pods. +You can join the discussion in the [open issue](https://github.com/kubernetes/kubernetes/issues/99497). + +## Wrap-up + +Indexed Jobs allows you to statically partition work among the workers of your +parallel Jobs. SIG Apps hopes that this feature facilitates the migration of +more batch workloads to Kubernetes. \ No newline at end of file diff --git a/content/en/blog/_posts/2021-04-20-Defining-NetworkPolicy-Conformance-For-CNIs.md b/content/en/blog/_posts/2021-04-20-Defining-NetworkPolicy-Conformance-For-CNIs.md new file mode 100644 index 0000000000..86c005eed1 --- /dev/null +++ b/content/en/blog/_posts/2021-04-20-Defining-NetworkPolicy-Conformance-For-CNIs.md @@ -0,0 +1,479 @@ +--- +layout: blog +title: "Defining Network Policy Conformance for Container Network Interface (CNI) providers" +date: 2021-04-20 +slug: defining-networkpolicy-conformance-cni-providers +--- + +Authors: Matt Fenwick (Synopsys), Jay Vyas (VMWare), Ricardo Katz, Amim Knabben (Loadsmart), Douglas Schilling Landgraf (Red Hat), Christopher Tomkins (Tigera) + +Special thanks to Tim Hockin and Bowie Du (Google), Dan Winship and Antonio Ojea (Red Hat), +Casey Davenport and Shaun Crampton (Tigera), and Abhishek Raut and Antonin Bas (VMware) for +being supportive of this work, and working with us to resolve issues in different Container Network Interfaces (CNIs) over time. + +A brief conversation around "node local" Network Policies in April of 2020 inspired the creation of a NetworkPolicy subproject from SIG Network. It became clear that as a community, +we need a rock-solid story around how to do pod network security on Kubernetes, and this story needed a community around it, so as to grow the cultural adoption of enterprise security patterns in K8s. + +In this post we'll discuss: + +- Why we created a subproject for [Network Policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) +- How we changed the Kubernetes e2e framework to `visualize` NetworkPolicy implementation of your CNI provider +- The initial results of our comprehensive NetworkPolicy conformance validator, _Cyclonus_, built around these principles +- Improvements subproject contributors have made to the NetworkPolicy user experience + +## Why we created a subproject for NetworkPolicies + +In April of 2020 it was becoming clear that many CNIs were emerging, and many vendors +implement these CNIs in subtly different ways. Users were beginning to express a little bit +of confusion around how to implement policies for different scenarios, and asking for new features. +It was clear that we needed to begin unifying the way we think about Network Policies +in Kubernetes, to avoid API fragmentation and unnecessary complexity. + +For example: +- In order to be flexible to the user’s environment, Calico as a CNI provider can be run using IPIP or VXLAN mode, or without encapsulation overhead. CNIs such as Antrea + and Cilium offer similar configuration options as well. +- Some CNI plugins offer iptables for NetworkPolicies amongst other options, whereas other CNIs use a completely + different technology stack (for example, the Antrea project uses Open vSwitch rules). +- Some CNI plugins only implement a subset of the Kubernetes NetworkPolicy API, and some a superset. For example, certain plugins don't support the + ability to target a named port; others don't work with certain IP address types, and there are diverging semantics for similar policy types. +- Some CNI plugins combine with OTHER CNI plugins in order to implement NetworkPolicies (canal), some CNI's might mix implementations (multus), and some clouds do routing separately from NetworkPolicy implementation. + +Although this complexity is to some extent necessary to support different environments, end-users find that they need to follow a multistep process to implement Network Policies to secure their applications: +- Confirm that their network plugin supports NetworkPolicies (some don't, such as Flannel) +- Confirm that their cluster's network plugin supports the specific NetworkPolicy features that they are interested in (again, the named port or port range examples come to mind here) +- Confirm that their application's Network Policy definitions are doing the right thing +- Find out the nuances of a vendor's implementation of policy, and check whether or not that implementation has a CNI neutral implementation (which is sometimes adequate for users) + +The NetworkPolicy project in upstream Kubernetes aims at providing a community where +people can learn about, and contribute to, the Kubernetes NetworkPolicy API and the surrounding ecosystem. + +## The First step: A validation framework for NetworkPolicies that was intuitive to use and understand + +The Kubernetes end to end suite has always had NetworkPolicy tests, but these weren't +run in CI, and the way they were implemented didn't provide holistic, easily consumable +information about how a policy was working in a cluster. +This is because the original tests didn't provide any kind of visual summary of connectivity +across a cluster. We thus initially set out to make it easy to confirm CNI support for NetworkPolicies by +making the end to end tests (which are often used by administrators or users to diagnose cluster conformance) easy to interpret. + +To solve the problem of confirming that CNIs support the basic features most users care about +for a policy, we built a new NetworkPolicy validation tool into the Kubernetes e2e +framework which allows for visual inspection of policies and their effect on a standard set of pods in a cluster. +For example, take the following test output. We found a bug in +[OVN Kubernetes](https://github.com/ovn-org/ovn-kubernetes/issues/1782). This bug has now been resolved. With this tool the bug was really +easy to characterize, wherein certain policies caused a state-modification that, +later on, caused traffic to incorrectly be blocked (even after all Network Policies were deleted from the cluster). + +This is the network policy for the test in question: +```yaml +metadata: + creationTimestamp: null + name: allow-ingress-port-80 +spec: + ingress: + - ports: + - port: serve-80-tcp + podSelector: {} +``` + +These are the expected connectivity results. The test setup is 9 pods (3 namespaces: x, y, and z; +and 3 pods in each namespace: a, b, and c); each pod runs a server on the same port and protocol +that can be reached through HTTP calls in the absence of network policies. Connectivity is verified +by using the [agnhost](https://github.com/kubernetes/kubernetes/tree/master/test/images/agnhost) network utility to issue HTTP calls on a port and protocol that other pods are +expected to be serving. A test scenario first +runs a connectivity check to ensure that each pod can reach each other pod, for 81 (= 9 x 9) data +points. This is the "control". Then perturbations are applied, depending on the test scenario: +policies are created, updated, and deleted; labels are added and removed from pods and namespaces, +and so on. After each change, the connectivity matrix is recollected and compared to the expected +connectivity. + +These results give a visual indication of connectivity in a simple matrix. Going down the leftmost column is the "source" +pod, or the pod issuing the request; going across the topmost row is the "destination" pod, or the pod +receiving the request. A `.` means that the connection was allowed; an `X` means the connection was +blocked. For example: + +``` +Nov 4 16:58:43.449: INFO: expected: + +- x/a x/b x/c y/a y/b y/c z/a z/b z/c +x/a . . . . . . . . . +x/b . . . . . . . . . +x/c . . . . . . . . . +y/a . . . . . . . . . +y/b . . . . . . . . . +y/c . . . . . . . . . +z/a . . . . . . . . . +z/b . . . . . . . . . +z/c . . . . . . . . . +``` + +Below are the observed connectivity results in the case of the OVN Kubernetes bug. Notice how the top three rows indicate that +all requests from namespace x regardless of pod and destination were blocked. Since these +experimental results do not match the expected results, a failure will be reported. Note +how the specific pattern of failure provides clear insight into the nature of the problem -- +since all requests from a specific namespace fail, we have a clear clue to start our +investigation. + +``` +Nov 4 16:58:43.449: INFO: observed: + +- x/a x/b x/c y/a y/b y/c z/a z/b z/c +x/a X X X X X X X X X +x/b X X X X X X X X X +x/c X X X X X X X X X +y/a . . . . . . . . . +y/b . . . . . . . . . +y/c . . . . . . . . . +z/a . . . . . . . . . +z/b . . . . . . . . . +z/c . . . . . . . . . +``` + +This was one of our earliest wins in the Network Policy group, as we were able to +identify and work with the OVN Kubernetes group to fix a bug in egress policy processing. + +However, even though this tool has made it easy to validate roughly 30 common scenarios, +it doesn't validate *all* Network Policy scenarios - because there are an enormous number of possible +permutations that one might create (technically, we might say this number is +infinite given that there's an infinite number of possible namespace/pod/port/protocol variations one can create). + +Once these tests were in play, we worked with the Upstream SIG Network and SIG Testing communities +(thanks to Antonio Ojea and Ben Elder) to put a testgrid Network Policy job in place. This job +continuously runs the entire suite of Network Policy tests against +[GCE with Calico as a Network Policy provider](https://testgrid.k8s.io/sig-network-gce#presubmit-network-policies,%20google-gce). + +Part of our role as a subproject is to help make sure that, when these tests break, we can help triage them effectively. + +## Cyclonus: The next step towards Network Policy conformance {#cyclonus} + +Around the time that we were finishing the validation work, it became clear from the community that, +in general, we needed to solve the overall problem of testing ALL possible Network Policy implementations. +For example, a KEP was recently written which introduced the concept of micro versioning to +Network Policies to accommodate [describing this at the API level](https://github.com/kubernetes/enhancements/pull/2137/files), by Dan Winship. + +In response to this increasingly obvious need to comprehensively evaluate Network +Policy implementations from all vendors, Matt Fenwick decided to evolve our approach to Network Policy validation again by creating Cyclonus. + +Cyclonus is a comprehensive Network Policy fuzzing tool which verifies a CNI provider +against hundreds of different Network Policy scenarios, by defining similar truth table/policy +combinations as demonstrated in the end to end tests, while also providing a hierarchical +representation of policy "categories". We've found some interesting nuances and issues +in almost every CNI we've tested so far, and have even contributed some fixes back. + +To perform a Cyclonus validation run, you create a Job manifest similar to: + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: cyclonus +spec: + template: + spec: + restartPolicy: Never + containers: + - command: + - ./cyclonus + - generate + - --perturbation-wait-seconds=15 + - --server-protocol=tcp,udp + name: cyclonus + imagePullPolicy: IfNotPresent + image: mfenwick100/cyclonus:latest + serviceAccount: cyclonus +``` + +Cyclonus outputs a report of all the test cases it will run: +``` +test cases to run by tag: +- target: 6 +- peer-ipblock: 4 +- udp: 16 +- delete-pod: 1 +- conflict: 16 +- multi-port/protocol: 14 +- ingress: 51 +- all-pods: 14 +- egress: 51 +- all-namespaces: 10 +- sctp: 10 +- port: 56 +- miscellaneous: 22 +- direction: 100 +- multi-peer: 0 +- any-port-protocol: 2 +- set-namespace-labels: 1 +- upstream-e2e: 0 +- allow-all: 6 +- namespaces-by-label: 6 +- deny-all: 10 +- pathological: 6 +- action: 6 +- rule: 30 +- policy-namespace: 4 +- example: 0 +- tcp: 16 +- target-namespace: 3 +- named-port: 24 +- update-policy: 1 +- any-peer: 2 +- target-pod-selector: 3 +- IP-block-with-except: 2 +- pods-by-label: 6 +- numbered-port: 28 +- protocol: 42 +- peer-pods: 20 +- create-policy: 2 +- policy-stack: 0 +- any-port: 14 +- delete-namespace: 1 +- delete-policy: 1 +- create-pod: 1 +- IP-block-no-except: 2 +- create-namespace: 1 +- set-pod-labels: 1 +testing 112 cases +``` + +Note that Cyclonus tags its tests based on the type of policy being created, because +the policies themselves are auto-generated, and thus have no meaningful names to be recognized by. + +For each test, Cyclonus outputs a truth table, which is again similar to that of the +E2E tests, along with the policy being validated: + +``` +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + creationTimestamp: null + name: base + namespace: x +spec: + egress: + - ports: + - port: 81 + to: + - namespaceSelector: + matchExpressions: + - key: ns + operator: In + values: + - "y" + - z + podSelector: + matchExpressions: + - key: pod + operator: In + values: + - a + - b + - ports: + - port: 53 + protocol: UDP + ingress: + - from: + - namespaceSelector: + matchExpressions: + - key: ns + operator: In + values: + - x + - "y" + podSelector: + matchExpressions: + - key: pod + operator: In + values: + - b + - c + ports: + - port: 80 + protocol: TCP + podSelector: + matchLabels: + pod: a + policyTypes: + - Ingress + - Egress + +0 wrong, 0 ignored, 81 correct ++--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +| TCP/80 | X/A | X/B | X/C | Y/A | Y/B | Y/C | Z/A | Z/B | Z/C | +| TCP/81 | | | | | | | | | | +| UDP/80 | | | | | | | | | | +| UDP/81 | | | | | | | | | | ++--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +| x/a | X | X | X | X | X | X | X | X | X | +| | X | X | X | . | . | X | . | . | X | +| | X | X | X | X | X | X | X | X | X | +| | X | X | X | X | X | X | X | X | X | ++--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +| x/b | . | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | ++--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +| x/c | . | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | ++--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +| y/a | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | ++--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +| y/b | . | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | ++--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +| y/c | . | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | ++--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +| z/a | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | ++--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +| z/b | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | ++--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +| z/c | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | +| | X | . | . | . | . | . | . | . | . | ++--------+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +``` + +Both Cyclonus and the e2e tests use the same strategy to validate a Network Policy - probing pods over TCP or UDP, with +SCTP support available as well for CNIs that support it (such as Calico). + +As examples of how we use Cyclonus to help make CNI implementations better from a Network Policy perspective, you can see the following issues: + +- [Antrea: NetworkPolicy: unable to allow ingress by CIDR](https://github.com/vmware-tanzu/antrea/issues/1764) +- [Calico: default missing protocol to TCP; don't let single port overwrite all ports](https://github.com/projectcalico/libcalico-go/pull/1373) +- [Cilium: Egress Network Policy allows traffic that should be denied](https://github.com/cilium/cilium/issues/14678) + +The good news is that Antrea and Calico have already merged fixes for all the issues found and other CNI providers are working on it, +with the support of SIG Network and the Network Policy subproject. + +Are you interested in verifying NetworkPolicy functionality on your cluster? +(if you care about security or offer multi-tenant SaaS, you should be) +If so, you can run the upstream end to end tests, or Cyclonus, or both. +- If you're just getting started with NetworkPolicies and want to simply + verify the "common" NetworkPolicy cases that most CNIs should be + implementing correctly, in a way that is quick to diagnose, then you're + better off running the e2e tests only. +- If you are deeply curious about your CNI provider's NetworkPolicy + implementation, and want to verify it: use Cyclonus. +- If you want to test *hundreds* of policies, and evaluate your CNI plugin + for comprehensive functionality, for deep discovery of potential security + holes: use Cyclonus, and also consider running end-to-end cluster tests. +- If you're thinking of getting involved with the upstream NetworkPolicy efforts: + use Cyclonus, and read at least an outline of which e2e tests are relevant. + +## Where to start with NetworkPolicy testing? + +- Cyclonus is easy to run on your cluster, check out the [instructions on github](https://github.com/mattfenwick/cyclonus#run-as-a-kubernetes-job), + and determine whether *your* specific CNI configuration is fully conformant to the hundreds of different + Kubernetes Network Policy API constructs. +- Alternatively, you can use a tool like [sonobuoy](https://github.com/vmware-tanzu/sonobuoy) + to run the existing E2E tests in Kubernetes, with the `--ginkgo.focus=NetworkPolicy` flag. + Make sure that you use the K8s conformance image for K8s 1.21 or above (for example, by using the `--kube-conformance-image-version v1.21.0` flag), + as older images will not have the *new* Network Policy tests in them. + +## Improvements to the NetworkPolicy API and user experience + +In addition to cleaning up the validation story for CNI plugins that implement NetworkPolicies, +subproject contributors have also spent some time improving the Kubernetes NetworkPolicy API for a few commonly requested features. +After months of deliberation, we eventually settled on a few core areas for improvement: + +- Port Range policies: We now allow you to specify a *range* of ports for a policy. + This allows users interested in scenarios like FTP or virtualization to enable advanced policies. + The port range option for network policies will be available to use in Kubernetes 1.21. + Read more in [targeting a range of ports](/docs/concepts/services-networking/network-policies/#targeting-a-range-of-ports). +- Namespace as name policies: Allowing users in Kubernetes >= 1.21 to target namespaces using names, + when building Network Policy objects. This was done in collaboration with Jordan Liggitt and Tim Hockin on the API Machinery side. + This change allowed us to improve the Network Policy user experience without actually + changing the API! For more details, you can read + [Automatic labelling](/docs/concepts/overview/working-with-objects/namespaces/#automatic-labelling) in the page about Namespaces. + The TL,DR; is that for Kubernetes 1.21 and later, **all namespaces** have the following label added by default: + + ``` + kubernetes.io/metadata.name: + ``` + +This means you can write a namespace policy against this namespace, even if you can't edit its labels. +For example, this policy, will 'just work', without needing to run a command such as `kubectl edit namespace`. +In fact, it will even work if you can't edit or view this namespace's data at all, because of the magic of API server defaulting. + +```yaml +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: test-network-policy + namespace: default +spec: + podSelector: + matchLabels: + role: db + policyTypes: + - Ingress + # Allow inbound traffic to Pods labelled role=db, in the namespace 'default' + # provided that the source is a Pod in the namespace 'my-namespace' + ingress: + - from: + - namespaceSelector: + matchLabels: + kubernetes.io/metadata.name: my-namespace +``` + +## Results + +In our tests, we found that: + +- Antrea and Calico are at a point where they support all of cyclonus's scenarios, modulo a few very minor tweaks which we've made. +- Cilium also conformed to the majority of the policies, outside known features that aren't fully supported (for example, related to the way Cilium deals with pod CIDR policies). + +If you are a CNI provider and interested in helping us to do a better job curating large tests of network policies, please reach out! We are continuing to curate the Network Policy conformance results from Cyclonus [here](https://raw.githubusercontent.com/K8sbykeshed/cyclonus-artifacts/), but +we are not capable of maintaining all of the subtleties in NetworkPolicy testing data on our own. For now, we use github actions and Kind to test in CI. + +## The Future + +We're also working on some improvements for the future of Network Policies, including: + +- Fully qualified Domain policies: The Google Cloud team created a prototype (which + we are really excited about) of [FQDN policies](https://github.com/GoogleCloudPlatform/gke-fqdnnetworkpolicies-golang). + This tool uses the Network Policy API to enforce policies against L7 URLs, by finding + their IPs and blocking them proactively when requests are made. +- Cluster Administrative policies: We're working hard at enabling *administrative* or + *cluster scoped* Network Policies for the future. These are being presented iteratively to the NetworkPolicy subproject. + You can read about them here in [Cluster Scoped Network Policy](https://docs.google.com/presentation/d/1Jk86jtS3TcGAugVSM_I4Yds5ukXFJ4F1ZCvxN5v2BaY/). + +The Network Policy subproject meets on mondays at 4PM EST. For details, check out the +[SIG Network community repo](https://github.com/kubernetes/community/tree/master/sig-network). We'd love +to hang out with you, hack on stuff, and help you adopt K8s Network Policies for your cluster wherever possible. + +### A quick note on User Feedback + +We've gotten a lot of ideas and feedback from users on Network Policies. A lot of people have interesting ideas about Network Policies, +but we've found that as a subproject, very few people were deeply interested in implementing these ideas to the full extent. + +Almost every change to the NetworkPolicy API includes weeks or months of discussion to cover different cases, and ensure no CVEs are being introduced. Thus, long term ownership +is the biggest impediment in improving the NetworkPolicy user experience for us, over time. + +- We've documented a lot of the history of the Network Policy dialogue [here](https://github.com/jayunit100/network-policy-subproject/blob/master/history.md). +- We've also taken a poll of users, for what they'd like to see in the Network Policy API [here](https://github.com/jayunit100/network-policy-subproject/blob/master/p0_user_stories.md). + +We encourage anyone to provide us with feedback, but our most pressing issues right now +involve finding *long term owners to help us drive changes*. + +This doesn't require a lot of technical knowledge, but rather, just a long term commitment to helping us stay organized, do paperwork, +and iterate through the many stages of the K8s feature process. If you want to help us and get involved, please reach out on the SIG Network mailing list, or in the SIG Network room in the k8s.io slack channel! + +Anyone can put an oar in the water and help make NetworkPolices better! diff --git a/content/en/blog/_posts/2021-04-20-annotating-k8s-for-humans.md b/content/en/blog/_posts/2021-04-20-annotating-k8s-for-humans.md new file mode 100644 index 0000000000..155ff5a3b3 --- /dev/null +++ b/content/en/blog/_posts/2021-04-20-annotating-k8s-for-humans.md @@ -0,0 +1,100 @@ +--- +layout: blog +title: 'Annotating Kubernetes Services for Humans' +date: 2021-04-20 +slug: annotating-k8s-for-humans +--- + +**Author:** Richard Li, Ambassador Labs + +Have you ever been asked to troubleshoot a failing Kubernetes service and struggled to find basic information about the service such as the source repository and owner? + +One of the problems as Kubernetes applications grow is the proliferation of services. As the number of services grows, developers start to specialize working with specific services. When it comes to troubleshooting, however, developers need to be able to find the source, understand the service and dependencies, and chat with the owning team for any service. + +## Human service discovery + +Troubleshooting always begins with information gathering. While much attention has been paid to centralizing machine data (e.g., logs, metrics), much less attention has been given to the human aspect of service discovery. Who owns a particular service? What Slack channel does the team work on? Where is the source for the service? What issues are currently known and being tracked? + +## Kubernetes annotations + +Kubernetes annotations are designed to solve exactly this problem. Oft-overlooked, Kubernetes annotations are designed to add metadata to Kubernetes objects. The Kubernetes documentation says annotations can “attach arbitrary non-identifying metadata to objects.” This means that annotations should be used for attaching metadata that is external to Kubernetes (i.e., metadata that Kubernetes won’t use to identify objects. As such, annotations can contain any type of data. This is a contrast to labels, which are designed for uses internal to Kubernetes. As such, label structure and values are [constrained](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set) so they can be efficiently used by Kubernetes. + + +## Kubernetes annotations in action + +Here is an example. Imagine you have a Kubernetes service for quoting, called the quote service. You can do the following: + +``` +kubectl annotate service quote a8r.io/owner=”@sally” +``` + +In this example, we've just added an annotation called `a8r.io/owner` with the value of @sally. Now, we can use `kubectl describe` to get the information. + +``` +Name: quote +Namespace: default +Labels: +Annotations: a8r.io/owner: @sally +Selector: app=quote +Type: ClusterIP +IP: 10.109.142.131 +Port: http 80/TCP +TargetPort: 8080/TCP +Endpoints: +Session Affinity: None +Events: +``` + +If you’re practicing GitOps (and you should be!) you’ll want to code these values directly into your Kubernetes manifest, e.g., + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: quote + annotations: + a8r.io/owner: “@sally” +spec: + ports: + - name: http + port: 80 + targetPort: 8080 + selector: + app: quote +``` + +## A Convention for Annotations + +Adopting a common convention for annotations ensures consistency and understandability. Typically, you’ll want to attach the annotation to the service object, as services are the high-level resource that maps most clearly to a team’s responsibility. Namespacing your annotations is also very important. Here is one set of conventions, documented at [a8r.io](https://a8r.io), and reproduced below: + +{{< table caption="Annotation convention for human-readable services">}} +| Annotation | Description | +| ------------------------------------------ | ------------------------------------------- | +| `a8r.io/description` | Unstructured text description of the service for humans. | +| `a8r.io/owner` | SSO username (GitHub), email address (linked to GitHub account), or unstructured owner description. | +| `a8r.io/chat` | Slack channel, or link to external chat system. | +| `a8r.io/bugs` | Link to external bug tracker. | +| `a8r.io/logs` | Link to external log viewer. | +| `a8r.io/documentation` | Link to external project documentation. | +| `a8r.io/repository` | Link to external VCS repository. | +| `a8r.io/support` | Link to external support center. | +| `a8r.io/runbook` | Link to external project runbook. | +| `a8r.io/incidents` | Link to external incident dashboard. | +| `a8r.io/uptime` | Link to external uptime dashboard. | +| `a8r.io/performance` | Link to external performance dashboard. | +| `a8r.io/dependencies` | Unstructured text describing the service dependencies for humans. | + + +## Visualizing annotations: Service Catalogs + +As the number of microservices and annotations proliferate, running `kubectl describe` can get tedious. Moreover, using `kubectl describe` requires every developer to have some direct access to the Kubernetes cluster. Over the past few years, service catalogs have gained greater visibility in the Kubernetes ecosystem. Popularized by tools such as [Shopify's ServicesDB](https://shopify.engineering/scaling-mobile-development-by-treating-apps-as-services) and [Spotify's System Z](https://dzone.com/articles/modeling-microservices-at-spotify-with-petter-mari), service catalogs are internally-facing developer portals that present critical information about microservices. + +Note that these service catalogs should not be confused with the [Kubernetes Service Catalog project](https://svc-cat.io/). Built on the Open Service Broker API, the Kubernetes Service Catalog enables Kubernetes operators to plug in different services (e.g., databases) to their cluster. + +## Annotate your services now and thank yourself later + +Much like implementing observability within microservice systems, you often don’t realize that you need human service discovery until it’s too late. Don't wait until something is on fire in production to start wishing you had implemented better metrics and also documented how to get in touch with the part of your organization that looks after it. + +There's enormous benefits to building an effective “version 0” service: a [_dancing skeleton_](https://containerjournal.com/topics/container-management/dancing-skeleton-apis-and-microservices/) application with a thin slice of complete functionality that can be deployed to production with a minimal yet effective continuous delivery pipeline. + +Adding service annotations should be an essential part of your “version 0” for all of your services. Add them now, and you’ll thank yourself later. diff --git a/content/en/blog/_posts/2021-04-21-Graceful-Node-Shutdown-Beta.md b/content/en/blog/_posts/2021-04-21-Graceful-Node-Shutdown-Beta.md new file mode 100644 index 0000000000..2c16967472 --- /dev/null +++ b/content/en/blog/_posts/2021-04-21-Graceful-Node-Shutdown-Beta.md @@ -0,0 +1,80 @@ +--- +layout: blog +title: 'Graceful Node Shutdown Goes Beta' +date: 2021-04-21 +slug: graceful-node-shutdown-beta +--- + +**Authors:** David Porter (Google), Mrunal Patel (Red Hat), and Tim Bannister (The Scale Factory) + +Graceful node shutdown, beta in 1.21, enables kubelet to gracefully evict pods during a node shutdown. + +Kubernetes is a distributed system and as such we need to be prepared for inevitable failures — nodes will fail, containers might crash or be restarted, and - ideally - your workloads will be able to withstand these catastrophic events. + +One of the common classes of issues are workload failures on node shutdown or restart. The best practice prior to bringing your node down is to [safely drain and cordon your node](/docs/tasks/administer-cluster/safely-drain-node/). This will ensure that all pods running on this node can safely be evicted. An eviction will ensure your pods can follow the expected [pod termination lifecycle](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) meaning receiving a SIGTERM in your container and/or running `preStopHooks`. + +Prior to Kubernetes 1.20 (when graceful node shutdown was introduced as an alpha feature), safe node draining was not easy: it required users to manually take action and drain the node beforehand. If someone or something shut down your node without draining it first, most likely your pods would not be safely evicted from your node and shutdown abruptly. Other services talking to those pods might see errors due to the pods exiting abruptly. Some examples of this situation may be caused by a reboot due to security patches or preemption of short lived cloud compute instances. + +Kubernetes 1.21 brings graceful node shutdown to beta. Graceful node shutdown gives you more control over some of those unexpected shutdown situations. With graceful node shutdown, the kubelet is aware of underlying system shutdown events and can propagate these events to pods, ensuring containers can shut down as gracefully as possible. This gives the containers a chance to checkpoint their state or release back any resources they are holding. + +Note, that for the best availability, even with graceful node shutdown, you should still design your deployments to be resilient to node failures. + +## How does it work? +On Linux, your system can shut down in many different situations. For example: +* A user or script running `shutdown -h now` or `systemctl poweroff` or `systemctl reboot`. +* Physically pressing a power button on the machine. +* Stopping a VM instance on a cloud provider, e.g. `gcloud compute instances stop` on GCP. +* A Preemptible VM or Spot Instance that your cloud provider can terminate unexpectedly, but with a brief warning. + + +Many of these situations can be unexpected and there is no guarantee that a cluster administrator drained the node prior to these events. With the graceful node shutdown feature, kubelet uses a systemd mechanism called ["Inhibitor Locks"](https://www.freedesktop.org/wiki/Software/systemd/inhibit) to allow draining in most cases. Using Inhibitor Locks, kubelet instructs systemd to postpone system shutdown for a specified duration, giving a chance for the node to drain and evict pods on the system. + +Kubelet makes use of this mechanism to ensure your pods will be terminated cleanly. When the kubelet starts, it acquires a systemd delay-type inhibitor lock. When the system is about to shut down, the kubelet can delay that shutdown for a configurable, short duration utilizing the delay-type inhibitor lock it acquired earlier. This gives your pods extra time to terminate. As a result, even during unexpected shutdowns, your application will receive a SIGTERM, [preStop hooks](/docs/concepts/containers/container-lifecycle-hooks/#container-hooks) will execute, and kubelet will properly update `Ready` node condition and respective pod statuses to the api-server. + +For example, on a node with graceful node shutdown enabled, you can see that the inhibitor lock is taken by the kubelet: + +``` +kubelet-node ~ # systemd-inhibit --list + Who: kubelet (UID 0/root, PID 1515/kubelet) + What: shutdown + Why: Kubelet needs time to handle node shutdown + Mode: delay + +1 inhibitors listed. +``` + +One important consideration we took when designing this feature is that not all pods are created equal. For example, some of the pods running on a node such as a logging related daemonset should stay running as long as possible to capture important logs during the shutdown itself. As a result, pods are split into two categories: "regular" and "critical". [Critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) are those that have `priorityClassName` set to `system-cluster-critical` or `system-node-critical`; all other pods are considered regular. + +In our example, the logging DaemonSet would run as a critical pod. During the graceful node shutdown, regular pods are terminated first, followed by critical pods. As an example, this would allow a critical pod associated with a logging daemonset to continue functioning, and collecting logs during the termination of regular pods. + +We will evaluate during the beta phase if we need more flexibility for different pod priority classes and add support if needed, please let us know if you have some scenarios in mind. + + +## How do I use it? + +Graceful node shutdown is controlled with the `GracefulNodeShutdown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates) and is enabled by default in Kubernetes 1.21. + +You can configure the graceful node shutdown behavior using two kubelet configuration options: `ShutdownGracePeriod` and `ShutdownGracePeriodCriticalPods`. To configure these options, you edit the kubelet configuration file that is passed to kubelet via the `--config` flag; for more details, refer to [Set kubelet parameters via a configuration file](/docs/tasks/administer-cluster/kubelet-config-file/). + + +During a shutdown, kubelet terminates pods in two phases. You can configure how long each of these phases lasts. +1. Terminate regular pods running on the node. +2. Terminate critical pods running on the node. + +The settings that control the duration of shutdown are: +* `ShutdownGracePeriod` + * Specifies the total duration that the node should delay the shutdown by. This is the total grace period for pod termination for both regular and critical pods. +* `ShutdownGracePeriodCriticalPods` + * Specifies the duration used to terminate critical pods during a node shutdown. This should be less than `ShutdownGracePeriod`. + +For example, if `ShutdownGracePeriod=30s`, and `ShutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by 30 seconds. During this time, the first 20 seconds (30-10) would be reserved for gracefully terminating normal pods, and the last 10 seconds would be reserved for terminating critical pods. + +Note that by default, both configuration options described above, `ShutdownGracePeriod` and `ShutdownGracePeriodCriticalPods` are set to zero, so you will need to configure them as appropriate for your environment to activate graceful node shutdown functionality. + +## How can I learn more? +* Read the [documentation](/docs/concepts/architecture/nodes/#graceful-node-shutdown) +* Read the enhancement proposal, [KEP 2000](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2000-graceful-node-shutdown) +* View the [code](https://github.com/kubernetes/kubernetes/tree/release-1.21/pkg/kubelet/nodeshutdown) + +## How do I get involved? +Your feedback is always welcome! SIG Node meets regularly and can be reached via [Slack](https://slack.k8s.io) (channel `#sig-node`), or the SIG's [mailing list](https://github.com/kubernetes/community/tree/master/sig-node#contact) diff --git a/content/en/blog/_posts/2021-04-22-gateway-api/gateway-api-resources.png b/content/en/blog/_posts/2021-04-22-gateway-api/gateway-api-resources.png new file mode 100644 index 0000000000..ef589bc914 Binary files /dev/null and b/content/en/blog/_posts/2021-04-22-gateway-api/gateway-api-resources.png differ diff --git a/content/en/blog/_posts/2021-04-22-gateway-api/httproute.png b/content/en/blog/_posts/2021-04-22-gateway-api/httproute.png new file mode 100644 index 0000000000..4dc0cb9457 Binary files /dev/null and b/content/en/blog/_posts/2021-04-22-gateway-api/httproute.png differ diff --git a/content/en/blog/_posts/2021-04-22-gateway-api/index.md b/content/en/blog/_posts/2021-04-22-gateway-api/index.md new file mode 100644 index 0000000000..d9c798a5b1 --- /dev/null +++ b/content/en/blog/_posts/2021-04-22-gateway-api/index.md @@ -0,0 +1,197 @@ + +--- +layout: blog +title: 'Evolving Kubernetes networking with the Gateway API' +date: 2021-04-22 +slug: evolving-kubernetes-networking-with-the-gateway-api +--- + +**Authors:** Mark Church (Google), Harry Bagdi (Kong), Daneyon Hanson (Red Hat), Nick Young (VMware), Manuel Zapf (Traefik Labs) + +The Ingress resource is one of the many Kubernetes success stories. It created a [diverse ecosystem of Ingress controllers](/docs/concepts/services-networking/ingress-controllers/) which were used across hundreds of thousands of clusters in a standardized and consistent way. This standardization helped users adopt Kubernetes. However, five years after the creation of Ingress, there are signs of fragmentation into different but [strikingly similar CRDs](https://dave.cheney.net/paste/ingress-is-dead-long-live-ingressroute.pdf) and [overloaded annotations](https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/). The same portability that made Ingress pervasive also limited its future. + +It was at Kubecon 2019 San Diego when a passionate group of contributors gathered to discuss the [evolution of Ingress](https://static.sched.com/hosted_files/kccncna19/a5/Kubecon%20San%20Diego%202019%20-%20Evolving%20the%20Kubernetes%20Ingress%20APIs%20to%20GA%20and%20Beyond%20%5BPUBLIC%5D.pdf). The discussion overflowed to the hotel lobby across the street and what came out of it would later be known as the [Gateway API](https://gateway-api.sigs.k8s.io). This discussion was based on a few key assumptions: + +1. The API standards underlying route matching, traffic management, and service exposure are commoditized and provide little value to their implementers and users as custom APIs +2. It’s possible to represent L4/L7 routing and traffic management through common core API resources +3. It’s possible to provide extensibility for more complex capabilities in a way that does not sacrifice the user experience of the core API + + +## Introducing the Gateway API + +This led to design principles that allow the Gateway API to improve upon Ingress: + +- **Expressiveness** - In addition to HTTP host/path matching and TLS, Gateway API can express capabilities like HTTP header manipulation, traffic weighting & mirroring, TCP/UDP routing, and other capabilities that were only possible in Ingress through custom annotations. +- **Role-oriented design** - The API resource model reflects the separation of responsibilities that is common in routing and Kubernetes service networking. +- **Extensibility** - The resources allow arbitrary configuration attachment at various layers within the API. This makes granular customization possible at the most appropriate places. +- **Flexible conformance** - The Gateway API defines varying conformance levels - core (mandatory support), extended (portable if supported), and custom (no portability guarantee), known together as [flexible conformance](https://gateway-api.sigs.k8s.io/concepts/guidelines/#conformance). This promotes a highly portable core API (like Ingress) that still gives flexibility for Gateway controller implementers. + +### What does the Gateway API look like? + +The Gateway API introduces a few new resource types: + +- **[GatewayClasses](https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.GatewayClass)** are cluster-scoped resources that act as templates to explicitly define behavior for Gateways derived from them. This is similar in concept to StorageClasses, but for networking data-planes. +- **[Gateways](https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.Gateway)** are the deployed instances of GatewayClasses. They are the logical representation of the data-plane which performs routing, which may be in-cluster proxies, hardware LBs, or cloud LBs. +- **Routes** are not a single resource, but represent many different protocol-specific Route resources. The [HTTPRoute](https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRoute) has matching, filtering, and routing rules that get applied to Gateways that can process HTTP and HTTPS traffic. Similarly, there are [TCPRoutes](https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.TCPRoute), [UDPRoutes](https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.UDPRoute), and [TLSRoutes](https://gateway-api.sigs.k8s.io/references/spec/#networking.x-k8s.io/v1alpha1.TLSRoute) which also have protocol-specific semantics. This model also allows the Gateway API to incrementally expand its protocol support in the future. + +![The resources of the Gateway API](gateway-api-resources.png) + +### Gateway Controller Implementations + +The good news is that although Gateway is in [Alpha](https://github.com/kubernetes-sigs/gateway-api/releases), there are already several [Gateway controller implementations](https://gateway-api.sigs.k8s.io/references/implementations/) that you can run. Since it’s a standardized spec, the following example could be run on any of them and should function the exact same way. Check out [getting started](https://gateway-api.sigs.k8s.io/guides/getting-started/) to see how to install and use one of these Gateway controllers. + +## Getting Hands-on with the Gateway API + +In the following example, we’ll demonstrate the relationships between the different API Resources and walk you through a common use case: + +* Team foo has their app deployed in the foo Namespace. They need to control the routing logic for the different pages of their app. +* Team bar is running in the bar Namespace. They want to be able to do blue-green rollouts of their application to reduce risk. +* The platform team is responsible for managing the load balancer and network security of all the apps in the Kubernetes cluster. + +The following foo-route does path matching to various Services in the foo Namespace and also has a default route to a 404 server. This exposes foo-auth and foo-home Services via `foo.example.com/login` and `foo.example.com/home` respectively.: + + +```yaml +kind: HTTPRoute +apiVersion: networking.x-k8s.io/v1alpha1 +metadata: + name: foo-route + namespace: foo + labels: + gateway: external-https-prod +spec: + hostnames: + - "foo.example.com" + rules: + - matches: + - path: + type: Prefix + value: /login + forwardTo: + - serviceName: foo-auth + port: 8080 + - matches: + - path: + type: Prefix + value: /home + forwardTo: + - serviceName: foo-home + port: 8080 + - matches: + - path: + type: Prefix + value: / + forwardTo: + - serviceName: foo-404 + port: 8080 +``` + + +The bar team, operating in the bar Namespace of the same Kubernetes cluster, also wishes to expose their application to the internet, but they also want to control their own canary and blue-green rollouts. The following HTTPRoute is configured for the following behavior: + +* For traffic to `bar.example.com`: + * Send 90% of the traffic to bar-v1 + * Send 10% of the traffic to bar-v2 +* For traffic to `bar.example.com` with the HTTP header `env: canary`: + + * Send all the traffic to bar-v2 + +![The routing rules configured for the bar-v1 and bar-v2 Services](httproute.png) + + + +```yaml +kind: HTTPRoute +apiVersion: networking.x-k8s.io/v1alpha1 +metadata: + name: bar-route + namespace: bar + labels: + gateway: external-https-prod +spec: + hostnames: + - "bar.example.com" + rules: + - forwardTo: + - serviceName: bar-v1 + port: 8080 + weight: 90 + - serviceName: bar-v2 + port: 8080 + weight: 10 + - matches: + - headers: + values: + env: canary + forwardTo: + - serviceName: bar-v2 + port: 8080 +``` + + + +### Route and Gateway Binding + +So we have two HTTPRoutes matching and routing traffic to different Services. You might be wondering, where are these Services accessible? Through which networks or IPs are they exposed? + +How Routes are exposed to clients is governed by [Route binding](https://gateway-api.sigs.k8s.io/concepts/api-overview/#route-binding), which describes how Routes and Gateways create a bidirectional relationship between each other. When Routes are bound to a Gateway it means their collective routing rules are configured on the underlying load balancers or proxies and the Routes are accessible through the Gateway. Thus, a Gateway is a logical representation of a networking data plane that can be configured through Routes. + + +![How Routes bind with Gateways](route-binding.png ) + +### Administrative Delegation + +The split between Gateway and Route resources allows the cluster administrator to delegate some of the routing configuration to individual teams while still retaining centralized control. The following Gateway resource exposes HTTPS on port 443 and terminates all traffic on the port with a certificate controlled by the cluster administrator. + + +```yaml +kind: Gateway +apiVersion: networking.x-k8s.io/v1alpha1 +metadata: + name: prod-web +spec: + gatewayClassName: acme-lb + listeners: + - protocol: HTTPS + port: 443 + routes: + kind: HTTPRoute + selector: + matchLabels: + gateway: external-https-prod + namespaces: + from: All + tls: + certificateRef: + name: admin-controlled-cert +``` + + +The following HTTPRoute shows how the Route can ensure it matches the Gateway's selector via it’s `kind` (HTTPRoute) and resource labels (`gateway=external-https-prod`). + + +```yaml +# Matches the required kind selector on the Gateway +kind: HTTPRoute +apiVersion: networking.x-k8s.io/v1alpha1 +metadata: + name: foo-route + namespace: foo-ns + labels: + + # Matches the required label selector on the Gateway + gateway: external-https-prod +... +``` + +### 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. + +### Try it out and get involved + +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! diff --git a/content/en/blog/_posts/2021-04-22-gateway-api/route-binding.png b/content/en/blog/_posts/2021-04-22-gateway-api/route-binding.png new file mode 100644 index 0000000000..4e42643316 Binary files /dev/null and b/content/en/blog/_posts/2021-04-22-gateway-api/route-binding.png differ diff --git a/content/en/blog/_posts/2021-04-23-metrics-stability-ga/index.md b/content/en/blog/_posts/2021-04-23-metrics-stability-ga/index.md new file mode 100644 index 0000000000..686016e3c5 --- /dev/null +++ b/content/en/blog/_posts/2021-04-23-metrics-stability-ga/index.md @@ -0,0 +1,80 @@ +--- +layout: blog +title: 'Kubernetes 1.21: Metrics Stability hits GA' +date: 2021-04-23 +slug: kubernetes-release-1.21-metrics-stability-ga +--- + +**Authors**: Han Kang (Google), Elana Hashman (Red Hat) + +Kubernetes 1.21 marks the graduation of the metrics stability framework and along with it, the first officially supported stable metrics. Not only do stable metrics come with supportability guarantees, the metrics stability framework brings escape hatches that you can use if you encounter problematic metrics. + +See the list of [stable Kubernetes metrics here](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) + +### What are stable metrics and why do we need them? +A stable metric is one which, from a consumption point of view, can be reliably consumed across a number of Kubernetes versions without risk of ingestion failure. + +Metrics stability is an ongoing community concern. Cluster monitoring infrastructure often assumes the stability of some control plane metrics, so we have introduced a mechanism for versioning metrics as a proper API, with stability guarantees around a formal metrics deprecation process. + +### What are the stability levels for metrics? + +Metrics can currently have one of two stability levels: alpha or stable. + +_Alpha metrics_ have no stability guarantees; as such they can be modified or deleted at any time. At this time, all Kubernetes metrics implicitly fall into this category. + +_Stable metrics_ can be guaranteed to not change, except that the metric may become marked deprecated for a future Kubernetes version. By not change, we mean three things: + +1. the metric itself will not be deleted or renamed +2. the type of metric will not be modified +3. no labels can be added or removed from this metric + +From an ingestion point of view, it is backwards-compatible to add or remove possible values for labels which already do exist, but not labels themselves. Therefore, adding or removing values from an existing label is permitted. Stable metrics can also be marked as deprecated for a future Kubernetes version, since this is tracked in a metadata field and does not actually change the metric itself. + +Removing or adding labels from stable metrics is not permitted. In order to add or remove a label from an existing stable metric, one would have to introduce a new metric and deprecate the stable one; otherwise this would violate compatibility agreements. + + +#### How are metrics deprecated? + +While deprecation policies only affect stability guarantees for stable metrics (and not alpha ones), deprecation information may be optionally provided on alpha metrics to help component owners inform users of future intent and assist with transition plans. + +A stable metric undergoing the deprecation process signals that the metric will eventually be deleted. The metrics deprecation lifecycle looks roughly like this (with each stage representing a Kubernetes release): + +![Stable metric → Deprecated metric → Hidden metric → Deletion](lifecycle-metric.png) + +_Deprecated metrics_ have the same stability guarantees of their stable counterparts. If a stable metric is deprecated, then a deprecated stable metric is guaranteed to not change. When deprecating a stable metric, a future Kubernetes release is specified as the point from which the metric will be considered deprecated. + +Deprecated metrics will have their description text prefixed with a deprecation notice string “(Deprecated from x.y)” and a warning log will be emitted during metric registration, in the spirit of the official Kubernetes deprecation policy. + +Like their stable metric counterparts, deprecated metrics will be automatically registered to the metrics endpoint. On a subsequent release (when the metric's deprecatedVersion is equal to _current\_kubernetes\_version - 4_)), a deprecated metric will become a _hidden_ metric. _Hidden metrics_ are not automatically registered, and hence are hidden by default from end users. These hidden metrics can be explicitly re-enabled for one release after they reach the hidden state, to provide a migration path for cluster operators. + + +#### As an owner of a Kubernetes component, how do I add stable metrics? + +During metric instantiation, stability can be specified by setting the metadata field, StabilityLevel, to “Stable”. When a StabilityLevel is not explicitly set, metrics default to “Alpha” stability. Note that metrics which have fields determined at runtime cannot be marked as Stable. Stable metrics will be detected during static analysis during the pre-commit phase, and must be reviewed by sig-instrumentation. + +```golang +var metricDefinition = kubemetrics.CounterOpts{ + Name: "some_metric", + Help: "some description", + StabilityLevel: kubemetrics.STABLE, +} +``` +For more examples of setting metrics stability and deprecation, see the [Metrics Stability KEP](http://bit.ly/metrics-stability). + + +### How do I get involved? + +This project, like all of Kubernetes, is the result of hard work by many contributors from diverse backgrounds working together. +We offer a huge thank you to all the contributors in Kubernetes community who helped review the design and implementation of the project, including but not limited to the following: + +- Han Kang (logicalhan) +- Frederic Branczyk (brancz) +- Marek Siarkowicz (serathius) +- Elana Hashman (ehashman) +- Solly Ross (DirectXMan12) +- Stefan Schimanski (sttts) +- David Ashpole (dashpole) +- Yuchen Zhou (yoyinzyc) +- Yu Yi (erain) + +If you’re interested in getting involved with the design and development of instrumentation or any part of the Kubernetes metrics system, join the [Kubernetes Instrumentation Special Interest Group (SIG)](https://github.com/kubernetes/community/tree/master/sig-instrumentation). We’re rapidly growing and always welcome new contributors. diff --git a/content/en/blog/_posts/2021-04-23-metrics-stability-ga/lifecycle-metric.png b/content/en/blog/_posts/2021-04-23-metrics-stability-ga/lifecycle-metric.png new file mode 100644 index 0000000000..7618a98c5c Binary files /dev/null and b/content/en/blog/_posts/2021-04-23-metrics-stability-ga/lifecycle-metric.png differ diff --git a/content/en/blog/_posts/2021-05-14-using-finalizers-to-control-deletion.md b/content/en/blog/_posts/2021-05-14-using-finalizers-to-control-deletion.md new file mode 100644 index 0000000000..19d79d3f44 --- /dev/null +++ b/content/en/blog/_posts/2021-05-14-using-finalizers-to-control-deletion.md @@ -0,0 +1,268 @@ +--- +layout: blog +title: 'Using Finalizers to Control Deletion' +date: 2021-05-14 +slug: using-finalizers-to-control-deletion +--- + +**Authors:** Aaron Alpar (Kasten) + +Deleting objects in Kubernetes can be challenging. You may think you’ve deleted something, only to find it still persists. While issuing a `kubectl delete` command and hoping for the best might work for day-to-day operations, understanding how Kubernetes `delete` commands operate will help you understand why some objects linger after deletion. + +In this post, I’ll look at: + +- What properties of a resource govern deletion +- How finalizers and owner references impact object deletion +- How the propagation policy can be used to change the order of deletions +- How deletion works, with examples + +For simplicity, all examples will use ConfigMaps and basic shell commands to demonstrate the process. We’ll explore how the commands work and discuss repercussions and results from using them in practice. + +## The basic `delete` + +Kubernetes has several different commands you can use that allow you to create, read, update, and delete objects. For the purpose of this blog post, we’ll focus on four `kubectl` commands: `create`, `get`, `patch`, and `delete`. + +Here are examples of the basic `kubectl delete` command: + +``` +kubectl create configmap mymap +configmap/mymap created +``` + +``` +kubectl get configmap/mymap +NAME DATA AGE +mymap 0 12s +``` + +``` +kubectl delete configmap/mymap +configmap "mymap" deleted +``` + +``` +kubectl get configmap/mymap +Error from server (NotFound): configmaps "mymap" not found +``` + +Shell commands preceded by `$` are followed by their output. You can see that we begin with a `kubectl create configmap mymap`, which will create the empty configmap `mymap`. Next, we need to `get` the configmap to prove it exists. We can then delete that configmap. Attempting to `get` it again produces an HTTP 404 error, which means the configmap is not found. + +The state diagram for the basic `delete` command is very simple: + + +{{
}} + +Although this operation is straightforward, other factors may interfere with the deletion, including finalizers and owner references. + +## Understanding Finalizers + +When it comes to understanding resource deletion in Kubernetes, knowledge of how finalizers work is helpful and can help you understand why some objects don’t get deleted. + +Finalizers are keys on resources that signal pre-delete operations. They control the garbage collection on resources, and are designed to alert controllers what cleanup operations to perform prior to removing a resource. However, they don’t necessarily name code that should be executed; finalizers on resources are basically just lists of keys much like annotations. Like annotations, they can be manipulated. + +Some common finalizers you’ve likely encountered are: + +- `kubernetes.io/pv-protection` +- `kubernetes.io/pvc-protection` + +The finalizers above are used on volumes to prevent accidental deletion. Similarly, some finalizers can be used to prevent deletion of any resource but are not managed by any controller. + +Below with a custom configmap, which has no properties but contains a finalizer: + +``` +cat <}} + +So, if you attempt to delete an object that has a finalizer on it, it will remain in finalization until the controller has removed the finalizer keys or the finalizers are removed using Kubectl. Once that finalizer list is empty, the object can actually be reclaimed by Kubernetes and put into a queue to be deleted from the registry. + +## Owner References + +Owner references describe how groups of objects are related. They are properties on resources that specify the relationship to one another, so entire trees of resources can be deleted. + +Finalizer rules are processed when there are owner references. An owner reference consists of a name and a UID. Owner references link resources within the same namespace, and it also needs a UID for that reference to work. Pods typically have owner references to the owning replica set. So, when deployments or stateful sets are deleted, then the child replica sets and pods are deleted in the process. + +Here are some examples of owner references and how they work. In the first example, we create a parent object first, then the child. The result is a very simple configmap that contains an owner reference to its parent: + +``` +cat <}} diff --git a/content/en/blog/_posts/2021-06-21-writing-a-controller-for-pod-labels.md b/content/en/blog/_posts/2021-06-21-writing-a-controller-for-pod-labels.md new file mode 100644 index 0000000000..ec3934ad7d --- /dev/null +++ b/content/en/blog/_posts/2021-06-21-writing-a-controller-for-pod-labels.md @@ -0,0 +1,467 @@ +--- +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]! + + + +[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/ diff --git a/content/en/blog/_posts/2021-06-28-announcing-kubernetes-community-group-annual-reports/index.md b/content/en/blog/_posts/2021-06-28-announcing-kubernetes-community-group-annual-reports/index.md new file mode 100644 index 0000000000..e31484abdf --- /dev/null +++ b/content/en/blog/_posts/2021-06-28-announcing-kubernetes-community-group-annual-reports/index.md @@ -0,0 +1,49 @@ +--- +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 Foundation’s [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, it’s 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 there’s 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, +we’ll 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). diff --git a/content/en/blog/_posts/2021-06-28-announcing-kubernetes-community-group-annual-reports/k8s_annual_report_2020.svg b/content/en/blog/_posts/2021-06-28-announcing-kubernetes-community-group-annual-reports/k8s_annual_report_2020.svg new file mode 100644 index 0000000000..179201d13b --- /dev/null +++ b/content/en/blog/_posts/2021-06-28-announcing-kubernetes-community-group-annual-reports/k8s_annual_report_2020.svg @@ -0,0 +1,16130 @@ + + + + diff --git a/content/en/blog/_posts/2021-07-14-upcoming-changes-in-kubernetes-1-22/index.md b/content/en/blog/_posts/2021-07-14-upcoming-changes-in-kubernetes-1-22/index.md new file mode 100644 index 0000000000..6759bf4975 --- /dev/null +++ b/content/en/blog/_posts/2021-07-14-upcoming-changes-in-kubernetes-1-22/index.md @@ -0,0 +1,276 @@ +--- +layout: blog +title: "Kubernetes API and Feature Removals In 1.22: Here’s 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. + + +* 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 --output-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 … +> 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. diff --git a/content/en/blog/_posts/2021-07-15-SIG-Usability-Spotlight.md b/content/en/blog/_posts/2021-07-15-SIG-Usability-Spotlight.md new file mode 100644 index 0000000000..43488fc11f --- /dev/null +++ b/content/en/blog/_posts/2021-07-15-SIG-Usability-Spotlight.md @@ -0,0 +1,65 @@ +--- +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, we’ll 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 you’d 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 what’s 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 you’d 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! diff --git a/content/en/blog/_posts/2021-07-20-Kubernetes-Release-Cadence/index.md b/content/en/blog/_posts/2021-07-20-Kubernetes-Release-Cadence/index.md new file mode 100644 index 0000000000..444b99a934 --- /dev/null +++ b/content/en/blog/_posts/2021-07-20-Kubernetes-Release-Cadence/index.md @@ -0,0 +1,83 @@ +--- +layout: blog +title: "Kubernetes Release Cadence Change: Here’s 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 diff --git a/content/en/blog/_posts/2021-07-26-update-with-ingress-nginx.md b/content/en/blog/_posts/2021-07-26-update-with-ingress-nginx.md new file mode 100644 index 0000000000..761b0b0575 --- /dev/null +++ b/content/en/blog/_posts/2021-07-26-update-with-ingress-nginx.md @@ -0,0 +1,71 @@ +--- +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 community’s 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). diff --git a/content/en/blog/_posts/2021-07-29-kubernetes-1-21-release-interview.md b/content/en/blog/_posts/2021-07-29-kubernetes-1-21-release-interview.md new file mode 100644 index 0000000000..25de412b81 --- /dev/null +++ b/content/en/blog/_posts/2021-07-29-kubernetes-1-21-release-interview.md @@ -0,0 +1,231 @@ +--- +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._ diff --git a/content/en/blog/_posts/2021-08-04-kubernetes-release-1.22.md b/content/en/blog/_posts/2021-08-04-kubernetes-release-1.22.md new file mode 100644 index 0000000000..9a196f7fba --- /dev/null +++ b/content/en/blog/_posts/2021-08-04-kubernetes-release-1.22.md @@ -0,0 +1,157 @@ +--- +layout: blog +title: 'Kubernetes 1.22: Reaching New Peaks' +date: 2021-08-04 +slug: kubernetes-1-22-release-announcement +--- + +**Authors:** [Kubernetes 1.22 Release Team](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.22/release-team.md) + +We’re pleased to announce the release of Kubernetes 1.22, the second release of 2021! + +This release consists of 53 enhancements: 13 enhancements have graduated to stable, 24 enhancements are moving to beta, and 16 enhancements are entering alpha. Also, three features have been deprecated. + +In April of this year, the Kubernetes release cadence was officially changed from four to three releases yearly. This is the first longer-cycle release related to that change. As the Kubernetes project matures, the number of enhancements per cycle grows. This means more work, from version to version, for the contributor community and Release Engineering team, and it can put pressure on the end-user community to stay up-to-date with releases containing increasingly more features. + +Changing the release cadence from four to three releases yearly balances many aspects of the project, both in how contributions and releases are managed, and also in the community's ability to plan for upgrades and stay up to date. + +You can read more in the official blog post [Kubernetes Release Cadence Change: Here’s What You Need To Know](https://kubernetes.io/blog/2021/07/20/new-kubernetes-release-cadence/). + + +## Major Themes + +### Server-side Apply graduates to GA + +[Server-side Apply](https://kubernetes.io/docs/reference/using-api/server-side-apply/) is a new field ownership and object merge algorithm running on the Kubernetes API server. Server-side Apply helps users and controllers manage their resources via declarative configurations. It allows them to create and/or modify their objects declaratively, simply by sending their fully specified intent. After being in beta for a couple releases, Server-side Apply is now generally available. + +### External credential providers now stable + +Support for Kubernetes client [credential plugins](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins) has been in beta since 1.11, and with the release of Kubernetes 1.22 now graduates to stable. The GA feature set includes improved support for plugins that provide interactive login flows, as well as a number of bug fixes. Aspiring plugin authors can look at [sample-exec-plugin](https://github.com/ankeesler/sample-exec-plugin) to get started. + +### etcd moves to 3.5.0 + +Kubernetes' default backend storage, etcd, has a new release: 3.5.0. The new release comes with improvements to the security, performance, monitoring, and developer experience. There are numerous bug fixes and some critical new features like the migration to structured logging and built-in log rotation. The release comes with a detailed future roadmap to implement a solution to traffic overload. You can read a full and detailed list of changes in the [3.5.0 release announcement](https://etcd.io/blog/2021/announcing-etcd-3.5/). + +### Quality of Service for memory resources + +Originally, Kubernetes used the v1 cgroups API. With that design, the QoS class for a `Pod` only applied to CPU resources (such as `cpu_shares`). As an alpha feature, Kubernetes v1.22 can now use the cgroups v2 API to control memory allocation and isolation. This feature is designed to improve workload and node availability when there is contention for memory resources, and to improve the predictability of container lifecycle. + +### Node system swap support + +Every system administrator or Kubernetes user has been in the same boat regarding setting up and using Kubernetes: disable swap space. With the release of Kubernetes 1.22, alpha support is available to run nodes with swap memory. This change lets administrators opt in to configuring swap on Linux nodes, treating a portion of block storage as additional virtual memory. + +### Windows enhancements and capabilities + +Continuing to support the growing developer community, SIG Windows has released their [Development Environment](https://github.com/kubernetes-sigs/sig-windows-dev-tools/). These new tools support multiple CNI providers and can run on multiple platforms. There is also a new way to run bleeding-edge Windows features from scratch by compiling the Windows kubelet and kube-proxy, then using them along with daily builds of other Kubernetes components. + +CSI support for Windows nodes moves to GA in the 1.22 release. In Kubernetes v1.22, Windows privileged containers are an alpha feature. To allow using CSI storage on Windows nodes, [CSIProxy](https://github.com/kubernetes-csi/csi-proxy) enables CSI node plugins to be deployed as unprivileged pods, using the proxy to perform privileged storage operations on the node. + +### Default profiles for seccomp + +An alpha feature for default seccomp profiles has been added to the kubelet, along with a new command line flag and configuration. When in use, this new feature provides cluster-wide seccomp defaults, using the `RuntimeDefault` seccomp profile rather than `Unconfined` by default. This enhances the default security of the Kubernetes Deployment. Security administrators will now sleep better knowing that workloads are more secure by default. To learn more about the feature, please refer to the official [seccomp tutorial](https://kubernetes.io/docs/tutorials/clusters/seccomp/#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads). + +### More secure control plane with kubeadm + +A new alpha feature allows running the `kubeadm` control plane components as non-root users. This is a long requested security measure in `kubeadm`. To try it you must enable the `kubeadm` specific RootlessControlPlane feature gate. When you deploy a cluster using this alpha feature, your control plane runs with lower privileges. + +For `kubeadm`, Kubernetes 1.22 also brings a new [v1beta3 configuration API](/docs/reference/config-api/kubeadm-config.v1beta3/). This iteration adds some long requested features and deprecates some existing ones. The v1beta3 version is now the preferred API version; the v1beta2 API also remains available and is not yet deprecated. + +## Major Changes + +### Removal of several deprecated beta APIs + +A number of deprecated beta APIs have been removed in 1.22 in favor of the GA version of those same APIs. All existing objects can be interacted with via stable APIs. This removal includes beta versions of the `Ingress`, `IngressClass`, `Lease`, `APIService`, `ValidatingWebhookConfiguration`, `MutatingWebhookConfiguration`, `CustomResourceDefinition`, `TokenReview`, `SubjectAccessReview`, and `CertificateSigningRequest` APIs. + +For the full list, check out the [Deprecated API Migration Guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22) as well as the blog post [Kubernetes API and Feature Removals In 1.22: Here’s What You Need To Know](https://blog.k8s.io/2021/07/14/upcoming-changes-in-kubernetes-1-22/). + +### API changes and improvements for ephemeral containers + +The API used to create [Ephemeral Containers](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/) changes in 1.22. The Ephemeral Containers feature is alpha and disabled by default, and the new API does not work with clients that attempt to use the old API. + +For stable features, the kubectl tool follows the Kubernetes [version skew policy](https://kubernetes.io/releases/version-skew-policy/); however, kubectl v1.21 and older do not support the new API for ephemeral containers. If you plan to use `kubectl debug` to create ephemeral containers, and your cluster is running Kubernetes v1.22, you cannot do so with kubectl v1.21 or earlier. Please update kubectl to 1.22 if you wish to use `kubectl debug` with a mix of cluster versions. + +## Other Updates + +### Graduated to Stable + +* [Bound Service Account Token Volumes](https://github.com/kubernetes/enhancements/issues/542) +* [CSI Service Account Token](https://github.com/kubernetes/enhancements/issues/2047) +* [Windows Support for CSI Plugins](https://github.com/kubernetes/enhancements/issues/1122) +* [Warning mechanism for deprecated API use](https://github.com/kubernetes/enhancements/issues/1693) +* [PodDisruptionBudget Eviction](https://github.com/kubernetes/enhancements/issues/85) + +### Notable Feature Updates + +* A new [PodSecurity admission](https://github.com/kubernetes/enhancements/issues/2579) alpha feature is introduced, intended as a replacement for PodSecurityPolicy +* [The Memory Manager](https://github.com/kubernetes/enhancements/issues/1769) moves to beta +* A new alpha feature to enable [API Server Tracing](https://github.com/kubernetes/enhancements/issues/647) +* A new v1beta3 version of the [kubeadm configuration](https://github.com/kubernetes/enhancements/issues/970) format +* [Generic data populators](https://github.com/kubernetes/enhancements/issues/1495) for PersistentVolumes are now available in alpha +* The Kubernetes control plane will now always use the [CronJobs v2 controller](https://github.com/kubernetes/enhancements/issues/19) +* As an alpha feature, all Kubernetes node components (including the kubelet, kube-proxy, and container runtime) can be [run as a non-root user](https://github.com/kubernetes/enhancements/issues/2033) + +# Release notes + +You can check out the full details of the 1.22 release in the [release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md). + +# Availability of release + +Kubernetes 1.22 is [available for download](https://kubernetes.io/releases/download/) and also [on the GitHub project](https://github.com/kubernetes/kubernetes/releases/tag/v1.22.0). + +There are some great resources out there for getting started with Kubernetes. You can check out some [interactive tutorials](https://kubernetes.io/docs/tutorials/) on the main Kubernetes site, or run a local cluster on your machine using Docker containers with [kind](https://kind.sigs.k8s.io). If you’d like to try building a cluster from scratch, check out the [Kubernetes the Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way) tutorial by Kelsey Hightower. + +# Release Team + +This release was made possible by a very dedicated group of individuals, who came together as a team to deliver technical content, documentation, code, and a host of other components that go into every Kubernetes release. + +A huge thank you to the release lead Savitha Raghunathan for leading us through a successful release cycle, and to everyone else on the release team for supporting each other, and working so hard to deliver the 1.22 release for the community. + +We would also like to take this opportunity to remember Peeyush Gupta, a member of our team that we lost earlier this year. Peeyush was actively involved in SIG ContribEx and the Kubernetes Release Team, most recently serving as the 1.22 Communications lead. His contributions and efforts will continue to reflect in the community he helped build. A [CNCF memorial](https://github.com/cncf/memorials/blob/main/peeyush-gupta.md) page has been created where thoughts and memories can be shared by the community. + +# Release Logo + +![Kubernetes 1.22 Release Logo](/images/blog/2021-08-04-kubernetes-release-1.22/kubernetes-1.22.png) + +Amidst the ongoing pandemic, natural disasters, and ever-present shadow of burnout, the 1.22 release of Kubernetes includes 53 enhancements. This makes it the largest release to date. This accomplishment was only made possible due to the hard-working and passionate Release Team members and the amazing contributors of the Kubernetes ecosystem. The release logo is our reminder to keep reaching for new milestones and setting new records. And it is dedicated to all the Release Team members, hikers, and stargazers! + +The logo is designed by [Boris Zotkin](https://www.instagram.com/boris.z.man/). Boris is a Mac/Linux Administrator at the MathWorks. He enjoys simple things in life and loves spending time with his family. This tech-savvy individual is always up for a challenge and happy to help a friend! + +# User Highlights + +- In May, the CNCF welcomed 27 new organizations across the globe as members of the diverse cloud native ecosystem. These new [members](https://www.cncf.io/announcements/2021/05/05/27-new-members-join-the-cloud-native-computing-foundation/) will participate in CNCF events, including the upcoming [KubeCon + CloudNativeCon NA in Los Angeles](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/) from October 12 – 15, 2021. +- The CNCF granted Spotify the [Top End User Award](https://www.cncf.io/announcements/2021/05/05/cloud-native-computing-foundation-grants-spotify-the-top-end-user-award/) during [KubeCon + CloudNativeCon EU – Virtual 2021](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/). + +# Project Velocity + +The [CNCF K8s DevStats project](https://k8s.devstats.cncf.io/) aggregates a number of interesting data points related to the velocity of Kubernetes and various sub-projects. This includes everything from individual contributions to the number of companies that are contributing, and is an illustration of the depth and breadth of effort that goes into evolving this ecosystem. + +In the v1.22 release cycle, which ran for 15 weeks (April 26 to August 4), we saw contributions from [1063 companies](https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1&var-period_name=v1.21.0%20-%20now&var-metric=contributions) and [2054 individuals](https://k8s.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=v1.21.0%20-%20now&var-metric=contributions&var-repogroup_name=Kubernetes&var-country_name=All&var-companies=All). + +# Ecosystem Updates + +- [KubeCon + CloudNativeCon Europe 2021](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/) was held in May, the third such event to be virtual. All talks are [now available on-demand](https://www.youtube.com/playlist?list=PLj6h78yzYM2MqBm19mRz9SYLsw4kfQBrC) for anyone that would like to catch up! +- [Spring Term LFX Program](https://www.cncf.io/blog/2021/07/13/spring-term-lfx-program-largest-graduating-class-with-28-successful-cncf-interns) had the largest graduating class with 28 successful CNCF interns! +- CNCF launched [livestreaming on Twitch](https://www.cncf.io/blog/2021/06/03/cloud-native-community-goes-live-with-10-shows-on-twitch/) at the beginning of the year targeting definitive interactive media experience for anyone wanting to learn, grow, and collaborate with others in the Cloud Native community from anywhere in the world. + +# Event Updates + +- [KubeCon + CloudNativeCon North America 2021](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/) will take place in Los Angeles, October 12 – 15, 2021! You can find more information about the conference and registration on the event site. +- [Kubernetes Community Days](https://community.cncf.io/kubernetes-community-days/about-kcd/) has upcoming events scheduled in Italy, the UK, and in Washington DC. + +# Upcoming release webinar + +Join members of the Kubernetes 1.22 release team on October 5, 2021 to learn about the major features of this release, as well as deprecations and removals to help plan for upgrades. For more information and registration, visit the [event page](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kubernetes-122-release/) on the CNCF Online Programs site. + +# Get Involved + +If you’re interested in contributing to the Kubernetes community, Special Interest Groups (SIGs) are a great starting point. Many of them may align with your interests! If there are things you’d like to share with the community, you can join the weekly community meeting, or use any of the following channels: + +* Find out more about contributing to Kubernetes at the [Kubernetes Contributors](https://www.kubernetes.dev/) website. +* Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates +* Join the community discussion on [Discuss](https://discuss.kubernetes.io/) +* Join the community on [Slack](http://slack.k8s.io/) +* Share your Kubernetes [story](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform) +* Read more about what’s happening with Kubernetes on the [blog](https://kubernetes.io/blog/) +* Learn more about the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team) + + diff --git a/content/en/blog/_posts/2021-08-06-server-side-apply-ga.md b/content/en/blog/_posts/2021-08-06-server-side-apply-ga.md new file mode 100644 index 0000000000..eca57a561e --- /dev/null +++ b/content/en/blog/_posts/2021-08-06-server-side-apply-ga.md @@ -0,0 +1,177 @@ +--- +layout: blog +title: "Kubernetes 1.22: Server Side Apply moves to GA" +date: 2021-08-06 +slug: server-side-apply-ga +--- + +**Authors:** Jeffrey Ying, Google & Joe Betz, Google + +Server-side Apply (SSA) has been promoted to GA in the Kubernetes v1.22 release. The GA milestone means you can depend on the feature and its API, without fear of future backwards-incompatible changes. GA features are protected by the Kubernetes [deprecation policy](/docs/reference/using-api/deprecation-policy/). + +## What is Server-side Apply? + +Server-side Apply helps users and controllers manage their resources through declarative configurations. Server-side Apply replaces the client side apply feature implemented by “kubectl apply” with a server-side implementation, permitting use by tools/clients other than kubectl. Server-side Apply is a new merging algorithm, as well as tracking of field ownership, running on the Kubernetes api-server. Server-side Apply enables new features like conflict detection, so the system knows when two actors are trying to edit the same field. Refer to the [Server-side Apply Documentation](/docs/reference/using-api/server-side-apply/) and [Beta 2 release announcement](https://kubernetes.io/blog/2020/04/01/kubernetes-1.18-feature-server-side-apply-beta-2/) for more information. + +## What’s new since Beta? + +Since the [Beta 2 release](https://kubernetes.io/blog/2020/04/01/kubernetes-1.18-feature-server-side-apply-beta-2/) subresources support has been added, and both client-go and Kubebuilder have added comprehensive support for Server-side Apply. This completes the Server-side Apply functionality required to make controller development practical. + +### Support for subresources + +Server-side Apply now fully supports subresources like `status` and `scale`. This is particularly important for [controllers](/docs/concepts/architecture/controller/), which are often responsible for writing to subresources. + +## Server-side Apply support in client-go + +Previously, Server-side Apply could only be called from the client-go typed client using the `Patch` function, with `PatchType` set to `ApplyPatchType`. Now, `Apply` functions are included in the client to allow for a more direct and typesafe way of calling Server-side Apply. Each `Apply` function takes an "apply configuration" type as an argument, which is a structured representation of an Apply request. For example: + +```go +import ( + ... + v1ac "k8s.io/client-go/applyconfigurations/autoscaling/v1" +) + +hpaApplyConfig := v1ac.HorizontalPodAutoscaler(autoscalerName, ns). + WithSpec(v1ac.HorizontalPodAutoscalerSpec(). + WithMinReplicas(0) + ) + +return hpav1client.Apply(ctx, hpaApplyConfig, metav1.ApplyOptions{FieldManager: "mycontroller", Force: true}) +``` + +Note in this example that `HorizontalPodAutoscaler` is imported from an "applyconfigurations" package. Each "apply configuration" type represents the same Kubernetes object kind as the corresponding go struct, but where all fields are pointers to make them optional, allowing apply requests to be accurately represented. For example, when the apply configuration in the above example is marshalled to YAML, it produces: + +```yaml +apiVersion: autoscaling/v1 +kind: HorizontalPodAutoscaler +metadata: + name: myHPA + namespace: myNamespace +spec: + minReplicas: 0 +``` + +To understand why this is needed, the above YAML cannot be produced by the v1.HorizontalPodAutoscaler go struct. Take for example: + +```go +hpa := v1.HorizontalPodAutoscaler{ + TypeMeta: metav1.TypeMeta{ + APIVersion: "autoscaling/v1", + Kind: "HorizontalPodAutoscaler", + }, + ObjectMeta: ObjectMeta{ + Namespace: ns, + Name: autoscalerName, + }, + Spec: v1.HorizontalPodAutoscalerSpec{ + MinReplicas: pointer.Int32Ptr(0), + }, +} +``` + +The above code attempts to declare the same apply configuration as shown in the previous examples, but when marshalled to YAML, produces: + +```yaml +kind: HorizontalPodAutoscaler +apiVersion: autoscaling/v1 +metadata + name: myHPA + namespace: myNamespace + creationTimestamp: null +spec: + scaleTargetRef: + kind: "" + name: "" + minReplicas: 0 + maxReplicas: 0 +``` + +Which, among other things, contains `spec.maxReplicas` set to `0`. This is almost certainly not what the caller intended (the intended apply configuration says nothing about the `maxReplicas` field), and could have serious consequences on a production system: it directs the autoscaler to downscale to zero pods. The problem here originates from the fact that the go structs contain required fields that are zero valued if not set explicitly. The go structs work as intended for create and update operations, but are fundamentally incompatible with apply, which is why we have introduced the generated "apply configuration" types. + +The "apply configurations" also have convenience `With` 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, extractedDeployment, 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=` +- OpenAPI extension: `default: ` + + +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 diff --git a/content/en/blog/_posts/2021-08-09-alpha-swap-support.md b/content/en/blog/_posts/2021-08-09-alpha-swap-support.md new file mode 100644 index 0000000000..2d7f562c27 --- /dev/null +++ b/content/en/blog/_posts/2021-08-09-alpha-swap-support.md @@ -0,0 +1,142 @@ +--- +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. diff --git a/content/en/blog/_posts/2021-08-09-csi-windows-support-with-csi-proxy-reaches-ga.md b/content/en/blog/_posts/2021-08-09-csi-windows-support-with-csi-proxy-reaches-ga.md new file mode 100644 index 0000000000..23d1c983ff --- /dev/null +++ b/content/en/blog/_posts/2021-08-09-csi-windows-support-with-csi-proxy-reaches-ga.md @@ -0,0 +1,76 @@ +--- +layout: blog +title: 'Kubernetes 1.22: CSI Windows Support (with CSI Proxy) reaches GA' +date: 2021-08-09 +slug: csi-windows-support-with-csi-proxy-reaches-ga +--- + +**Authors:** Mauricio Poppe (Google), Jing Xu (Google), and Deep Debroy (Apple) + +*The stable version of CSI Proxy for Windows has been released alongside Kubernetes 1.22. CSI Proxy enables CSI Drivers running on Windows nodes to perform privileged storage operations.* + +## Background + +Container Storage Interface (CSI) for Kubernetes went GA in the Kubernetes 1.13 release. CSI has become the standard for exposing block and file storage to containerized workloads on Container Orchestration systems (COs) like Kubernetes. It enables third-party storage providers to write and deploy plugins without the need to alter the core Kubernetes codebase. Legacy in-tree drivers are deprecated and new storage features are introduced in CSI, therefore it is important to get CSI Drivers to work on Windows. + +A CSI Driver in Kubernetes has two main components: a controller plugin which runs in the control plane and a node plugin which runs on every node. + +- The controller plugin generally does not need direct access to the host and can perform all its operations through the Kubernetes API and external control plane services. + +- The node plugin, however, requires direct access to the host for making block devices and/or file systems available to the Kubernetes kubelet. Due to the missing capability of running privileged operations from containers on Windows nodes [CSI Proxy was introduced as alpha in Kubernetes 1.18](https://kubernetes.io/blog/2020/04/03/kubernetes-1-18-feature-windows-csi-support-alpha/) as a way to enable containers to perform privileged storage operations. This enables containerized CSI Drivers to run on Windows nodes. + +## What's CSI Proxy and how do CSI drivers interact with it? + +When a workload that uses persistent volumes is scheduled, it'll go through a sequence of steps defined in the [CSI Spec](https://github.com/container-storage-interface/spec/blob/master/spec.md). First, the workload will be scheduled to run on a node. Then the controller component of a CSI Driver will attach the persistent volume to the node. Finally the node component of a CSI Driver will mount the persistent volume on the node. + +The node component of a CSI Driver needs to run on Windows nodes to support Windows workloads. Various privileged operations like scanning of disk devices, mounting of file systems, etc. cannot be done from a containerized application running on Windows nodes yet ([Windows HostProcess containers](https://github.com/kubernetes/enhancements/issues/1981) introduced in Kubernetes 1.22 as alpha enable functionalities that require host access like the operations mentioned before). However, we can perform these operations through a binary (CSI Proxy) that's pre-installed on the Window nodes. CSI Proxy has a client-server architecture and allows CSI drivers to issue privileged storage operations through a gRPC interface exposed over named pipes created during the startup of CSI Proxy. + +![CSI Proxy Architecture](/images/blog/2021-08-09-csi-windows-support-with-csi-proxy-reaches-ga/csi-proxy.png) + +## CSI Proxy reaches GA + +The CSI Proxy development team has worked closely with storage vendors, many of whom started integrating CSI Proxy into their CSI Drivers and provided feedback as early as CSI Proxy design proposal. This cooperation uncovered use cases where additional APIs were needed, found bugs, and identified areas for documentation improvement. + +The CSI Proxy design [KEP](https://github.com/kubernetes/enhancements/pull/2737) has been updated to reflect the current CSI Proxy architecture. Additional [development documentation](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/DEVELOPMENT.md) is included for contributors interested in helping with new features or bug fixes. + +Before we reached GA we wanted to make sure that our API is simple and consistent. We went through an extensive API review of the v1beta API groups where we made sure that the CSI Proxy API methods and messages are consistent with the naming conventions defined in the [CSI Spec](https://github.com/container-storage-interface/spec/blob/master/spec.md). As part of this effort we're graduating the [Disk](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/disk_v1.md), [Filesystem](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/filesystem_v1.md), [SMB](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/smb_v1.md) and [Volume](https://github.com/kubernetes-csi/csi-proxy/blob/master/docs/apis/volume_v1.md) API groups to v1. + +Additional Windows system APIs to get information from the Windows nodes and support to mount iSCSI targets in Windows nodes, are available as alpha APIs in the [System API](https://github.com/kubernetes-csi/csi-proxy/tree/v1.0.0/client/api/system/v1alpha1) and the [iSCSI API](https://github.com/kubernetes-csi/csi-proxy/tree/v1.0.0/client/api/iscsi/v1alpha2). These APIs will continue to be improved before we graduate them to v1. + +CSI Proxy v1 is compatible with all the previous v1betaX releases. The GA `csi-proxy.exe` binary can handle requests from v1betaX clients thanks to the autogenerated conversion layer that transforms any versioned client request to a version-agnostic request that the server can process. Several [integration tests](https://github.com/kubernetes-csi/csi-proxy/tree/v1.0.0/integrationtests) were added for all the API versions of the API groups that are graduating to v1 to ensure that CSI Proxy is backwards compatible. + +Version drift between CSI Proxy and the CSI Drivers that interact with it was also carefully considered. A [connection fallback mechanism](https://github.com/kubernetes-csi/csi-proxy/pull/124) has been provided for CSI Drivers to handle multiple versions of CSI Proxy for a smooth upgrade to v1. This allows CSI Drivers, like the GCE PD CSI Driver, [to recognize which version of the CSI Proxy binary is running](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/pull/738) and handle multiple versions of the CSI Proxy binary deployed on the node. + +CSI Proxy v1 is already being used by many CSI Drivers, including the [AWS EBS CSI Driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/pull/966), [Azure Disk CSI Driver](https://github.com/kubernetes-sigs/azuredisk-csi-driver/pull/919), [GCE PD CSI Driver](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/pull/738), and [SMB CSI Driver](https://github.com/kubernetes-csi/csi-driver-smb/pull/319). + +## Future plans + +We're very excited for the future of CSI Proxy. With the upcoming [Windows HostProcess containers](https://github.com/kubernetes/enhancements/issues/1981), we are considering converting the CSI Proxy in to a library consumed by CSI Drivers in addition to the current client/server design. This will allow us to iterate faster on new features because the `csi-proxy.exe` binary will no longer be needed. + +## How to get involved? + +This project, like all of Kubernetes, is the result of hard work by many contributors from diverse backgrounds working together. Those interested in getting involved with the design and development of CSI Proxy, or any part of the Kubernetes Storage system, may join the Kubernetes Storage Special Interest Group (SIG). We’re rapidly growing and always welcome new contributors. + +For those interested in more details about CSI support in Windows please reach out in the [#csi-windows](https://kubernetes.slack.com/messages/csi-windows) Kubernetes slack channel. + +## Acknowledgments + +CSI-Proxy received many contributions from members of the Kubernetes community. We thank all of the people that contributed to CSI Proxy with design reviews, bug reports, bug fixes, and for their continuous support in reaching this milestone: + +- [Andy Zhang](https://github.com/andyzhangx) +- [Dan Ilan](https://github.com/jmpfar) +- [Deep Debroy](https://github.com/ddebroy) +- [Humble Devassy Chirammal](https://github.com/humblec) +- [Jing Xu](https://github.com/jingxu97) +- [Jean Rougé](https://github.com/wk8) +- [Jordan Liggitt](https://github.com/liggitt) +- [Kalya Subramanian](https://github.com/ksubrmnn) +- [Krishnakumar R](https://github.com/kkmsft) +- [Manuel Tellez](https://github.com/manueltellez) +- [Mark Rossetti](https://github.com/marosset) +- [Mauricio Poppe](https://github.com/mauriciopoppe) +- [Matthew Wong](https://github.com/wongma7) +- [Michelle Au](https://github.com/msau42) +- [Patrick Lang](https://github.com/PatrickLang) +- [Saad Ali](https://github.com/saad-ali) +- [Yuju Hong](https://github.com/yujuhong) \ No newline at end of file diff --git a/content/en/blog/_posts/2021-08-11-memory-manager-moves-to-beta.md b/content/en/blog/_posts/2021-08-11-memory-manager-moves-to-beta.md new file mode 100644 index 0000000000..0eeb8bde83 --- /dev/null +++ b/content/en/blog/_posts/2021-08-11-memory-manager-moves-to-beta.md @@ -0,0 +1,144 @@ +--- +layout: blog +title: "Kubernetes Memory Manager moves to beta" +date: 2021-08-11 +slug: kubernetes-1-22-feature-memory-manager-moves-to-beta +--- + +**Authors:** Artyom Lukianov (Red Hat), Cezary Zukowski (Samsung) + +The blog post explains some of the internals of the _Memory manager_, a beta feature +of Kubernetes 1.22. In Kubernetes, the Memory Manager is a +[kubelet](https://kubernetes.io/docs/concepts/overview/components/#kubelet) subcomponent. +The memory manage provides guaranteed memory (and hugepages) +allocation for pods in the `Guaranteed` [QoS class](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/#qos-classes). + +This blog post covers: + +1. [Why do you need it?](#Why-do-you-need-it?) +2. [The internal details of how the **MemoryManager** works](#How-does-it-work?) +3. [Current limitations of the **MemoryManager**](#Current-limitations) +4. [Future work for the **MemoryManager**](#Future-work-for-the-Memory-Manager) + +## Why do you need it? + +Some Kubernetes workloads run on nodes with +[non-uniform memory access](https://en.wikipedia.org/wiki/Non-uniform_memory_access) (NUMA). +Suppose you have NUMA nodes in your cluster. In that case, you'll know about the potential for extra latency when +compute resources need to access memory on the different NUMA locality. + +To get the best performance and latency for your workload, container CPUs, +peripheral devices, and memory should all be aligned to the same NUMA +locality. +Before Kubernetes v1.22, the kubelet already provided a set of managers to +align CPUs and PCI devices, but you did not have a way to align memory. +The Linux kernel was able to make best-effort attempts to allocate +memory for tasks from the same NUMA node where the container is +executing are placed, but without any guarantee about that placement. + +## How does it work? + +The memory manager is doing two main things: +- provides the topology hint to the Topology Manager +- allocates the memory for containers and updates the state + +The overall sequence of the Memory Manager under the Kubelet + +![MemoryManagerDiagram](/images/blog/2021-08-11-memory-manager-moves-to-beta/MemoryManagerDiagram.svg "MemoryManagerDiagram") + +During the Admission phase: + +1. When first handling a new pod, the kubelet calls the TopologyManager's `Admit()` method. +2. The Topology Manager is calling `GetTopologyHints()` for every hint provider including the Memory Manager. +3. The Memory Manager calculates all possible NUMA nodes combinations for every container inside the pod and returns hints to the Topology Manager. +4. The Topology Manager calls to `Allocate()` for every hint provider including the Memory Manager. +5. The Memory Manager allocates the memory under the state according to the hint that the Topology Manager chose. + +During Pod creation: + +1. The kubelet calls `PreCreateContainer()`. +2. For each container, the Memory Manager looks the NUMA nodes where it allocated the + memory for the container and then returns that information to the kubelet. +3. The kubelet creates the container, via CRI, using a container specification + that incorporates information from the Memory Manager information. + +### Let's talk about the configuration + +By default, the Memory Manager runs with the `None` policy, meaning it will just +relax and not do anything. To make use of the Memory Manager, you should set +two command line options for the kubelet: + +- `--memory-manager-policy=Static` +- `--reserved-memory=":="` + +The value for `--memory-manager-policy` is straightforward: `Static`. Deciding what to specify for `--reserved-memory` takes more thought. To configure it correctly, you should follow two main rules: + +- The amount of reserved memory for the `memory` resource must be greater than zero. +- The amount of reserved memory for the resource type must be equal + to [NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) + (`kube-reserved + system-reserved + eviction-hard`) for the resource. + You can read more about memory reservations in [Reserve Compute Resources for System Daemons](/docs/tasks/administer-cluster/reserve-compute-resources/). + +![Reserved memory](/images/blog/2021-08-11-memory-manager-moves-to-beta/ReservedMemory.svg) + +## Current limitations + +The 1.22 release and promotion to beta brings along enhancements and fixes, but the Memory Manager still has several limitations. + +### Single vs Cross NUMA node allocation + +The NUMA node can not have both single and cross NUMA node allocations. When the container memory is pinned to two or more NUMA nodes, we can not know from which NUMA node the container will consume the memory. + +![Single vs Cross NUMA allocation](/images/blog/2021-08-11-memory-manager-moves-to-beta/SingleCrossNUMAAllocation.svg "SingleCrossNUMAAllocation") + +1. The `container1` started on the NUMA node 0 and requests *5Gi* of the memory but currently is consuming only *3Gi* of the memory. +2. For container2 the memory request is 10Gi, and no single NUMA node can satisfy it. +3. The `container2` consumes *3.5Gi* of the memory from the NUMA node 0, but once the `container1` will require more memory, it will not have it, and the kernel will kill one of the containers with the *OOM* error. + +To prevent such issues, the Memory Manager will fail the admission of the `container2` until the machine has two NUMA nodes without a single NUMA node allocation. + +### Works only for Guaranteed pods + +The Memory Manager can not guarantee memory allocation for Burstable pods, +also when the Burstable pod has specified equal memory limit and request. + +Let's assume you have two Burstable pods: `pod1` has containers with +equal memory request and limits, and `pod2` has containers only with a +memory request set. You want to guarantee memory allocation for the `pod1`. +To the Linux kernel, processes in either pod have the same *OOM score*, +once the kernel finds that it does not have enough memory, it can kill +processes that belong to pod `pod1`. + +### Memory fragmentation + +The sequence of Pods and containers that start and stop can fragment the memory on NUMA nodes. +The alpha implementation of the Memory Manager does not have any mechanism to balance pods and defragment memory back. + +## Future work for the Memory Manager + +We do not want to stop with the current state of the Memory Manager and are looking to +make improvements, including in the following areas. + +### Make the Memory Manager allocation algorithm smarter + +The current algorithm ignores distances between NUMA nodes during the +calculation of the allocation. If same-node placement isn't available, we can still +provide better performance compared to the current implementation, by changing the +Memory Manager to prefer the closest NUMA nodes for cross-node allocation. + +### Reduce the number of admission errors + +The default Kubernetes scheduler is not aware of the node's NUMA topology, and it can be a reason for many admission errors during the pod start. +We're hoping to add a KEP (Kubernetes Enhancement Proposal) to cover improvements in this area. +Follow [Topology aware scheduler plugin in kube-scheduler](https://github.com/kubernetes/enhancements/issues/2044) to see how this idea progresses. + + +## Conclusion +With the promotion of the Memory Manager to beta in 1.22, we encourage everyone to give it a try and look forward to any feedback you may have. While there are still several limitations, we have a set of enhancements planned to address them and look forward to providing you with many new features in upcoming releases. +If you have ideas for additional enhancements or a desire for certain features, please let us know. The team is always open to suggestions to enhance and improve the Memory Manager. +We hope you have found this blog informative and helpful! Let us know if you have any questions or comments. + +You can contact us via: +- The Kubernetes [#sig-node ](https://kubernetes.slack.com/messages/sig-node) + channel in Slack (visit https://slack.k8s.io/ for an invitation if you need one) +- The SIG Node mailing list, [kubernetes-sig-node@googlegroups.com](https://groups.google.com/g/kubernetes-sig-node) diff --git a/content/en/blog/_posts/2021-08-16-support-for-hostprocess-containers/hostprocess-architecture.png b/content/en/blog/_posts/2021-08-16-support-for-hostprocess-containers/hostprocess-architecture.png new file mode 100755 index 0000000000..b28bfcf808 Binary files /dev/null and b/content/en/blog/_posts/2021-08-16-support-for-hostprocess-containers/hostprocess-architecture.png differ diff --git a/content/en/blog/_posts/2021-08-16-support-for-hostprocess-containers/index.md b/content/en/blog/_posts/2021-08-16-support-for-hostprocess-containers/index.md new file mode 100644 index 0000000000..5475640e3b --- /dev/null +++ b/content/en/blog/_posts/2021-08-16-support-for-hostprocess-containers/index.md @@ -0,0 +1,79 @@ +--- +layout: blog +title: 'Alpha in v1.22: Windows HostProcess Containers' +date: 2021-08-16 +slug: windows-hostprocess-containers +--- + +**Authors:** Brandon Smith (Microsoft) + +Kubernetes v1.22 introduced a new alpha feature for clusters that +include Windows nodes: HostProcess containers. + +HostProcess containers aim to extend the Windows container model to enable a wider +range of Kubernetes cluster management scenarios. HostProcess containers run +directly on the host and maintain behavior and access similar to that of a regular +process. With HostProcess containers, users can package and distribute management +operations and functionalities that require host access while retaining versioning +and deployment methods provided by containers. This allows Windows containers to +be used for a variety of device plugin, storage, and networking management scenarios +in Kubernetes. With this comes the enablement of host network mode—allowing +HostProcess containers to be created within the host's network namespace instead of +their own. HostProcess containers can also be built on top of existing Windows server +2019 (or later) base images, managed through the Windows container runtime, and run +as any user that is available on or in the domain of the host machine. + +Linux privileged containers are currently used for a variety of key scenarios in +Kubernetes, including kube-proxy (via kubeadm), storage, and networking scenarios. +Support for these scenarios in Windows previously required workarounds via proxies +or other implementations. Using HostProcess containers, cluster operators no longer +need to log onto and individually configure each Windows node for administrative +tasks and management of Windows services. Operators can now utilize the container +model to deploy management logic to as many clusters as needed with ease. + +## How does it work? + +Windows HostProcess containers are implemented with Windows _Job Objects_, a break from the +previous container model using server silos. Job objects are components of the Windows OS which offer the ability to +manage a group of processes as a group (a.k.a. _jobs_) and assign resource constraints to the +group as a whole. Job objects are specific to the Windows OS and are not associated with the Kubernetes [Job API](https://kubernetes.io/docs/concepts/workloads/controllers/job/). They have no process or file system isolation, +enabling the privileged payload to view and edit the host file system with the +correct permissions, among other host resources. The init process, and any processes +it launches or that are explicitly launched by the user, are all assigned to the +job object of that container. When the init process exits or is signaled to exit, +all the processes in the job will be signaled to exit, the job handle will be +closed and the storage will be unmounted. + +HostProcess and Linux privileged containers enable similar scenarios but differ +greatly in their implementation (hence the naming difference). HostProcess containers +have their own pod security policies. Those used to configure Linux privileged +containers **do not** apply. Enabling privileged access to a Windows host is a +fundamentally different process than with Linux so the configuration and +capabilities of each differ significantly. Below is a diagram detailing the +overall architecture of Windows HostProcess containers: + +{{< figure src="hostprocess-architecture.png" alt="HostProcess Architecture" >}} + +## How do I use it? + +HostProcess containers can be run from within a +[HostProcess Pod](/docs/tasks/configure-pod-container/create-hostprocess-pod). +With the feature enabled on Kubernetes version 1.22, a containerd container runtime of +1.5.4 or higher, and the latest version of hcsshim, deploying a pod spec with the +[correct HostProcess configuration](/docs/tasks/configure-pod-container/create-hostprocess-pod/#before-you-begin) +will enable you to run HostProcess containers. To get started with running +Windows containers see the general guidance for [Windows in Kubernetes](/docs/setup/production-environment/windows/) + +## How can I learn more? + +- Work through [Create a Windows HostProcess Pod](/docs/tasks/configure-pod-container/create-hostprocess-pod/) + +- Read about Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-standards/) + +- Read the enhancement proposal [Windows Privileged Containers and Host Networking Mode](https://github.com/kubernetes/enhancements/tree/master/keps/sig-windows/1981-windows-privileged-container-support) (KEP-1981) + +## How do I get involved? + +HostProcess containers are in active development. SIG Windows welcomes suggestions from the community. +Get involved with [SIG Windows](https://github.com/kubernetes/community/tree/master/sig-windows) +to contribute! diff --git a/content/en/blog/_posts/2021-08-25-seccomp-default.md b/content/en/blog/_posts/2021-08-25-seccomp-default.md new file mode 100644 index 0000000000..c38b7fdee1 --- /dev/null +++ b/content/en/blog/_posts/2021-08-25-seccomp-default.md @@ -0,0 +1,267 @@ +--- +layout: blog +title: "Enable seccomp for all workloads with a new v1.22 alpha feature" +date: 2021-08-25 +slug: seccomp-default +--- + +**Author:** Sascha Grunert, Red Hat + +This blog post is about a new Kubernetes feature introduced in v1.22, which adds +an additional security layer on top of the existing seccomp support. Seccomp is +a security mechanism for Linux processes to filter system calls (syscalls) based +on a set of defined rules. Applying seccomp profiles to containerized workloads +is one of the key tasks when it comes to enhancing the security of the +application deployment. Developers, site reliability engineers and +infrastructure administrators have to work hand in hand to create, distribute +and maintain the profiles over the applications life-cycle. + +You can use the [`securityContext`][seccontext] field of Pods and their +containers can be used to adjust security related configurations of the +workload. Kubernetes introduced dedicated [seccomp related API +fields][seccontext] in this `SecurityContext` with the [graduation of seccomp to +General Availability (GA)][ga] in v1.19.0. This enhancement allowed an easier +way to specify if the whole pod or a specific container should run as: + +[seccontext]: /docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1 +[ga]: https://kubernetes.io/blog/2020/08/26/kubernetes-release-1.19-accentuate-the-paw-sitive/#graduated-to-stable + +- `Unconfined`: seccomp will not be enabled +- `RuntimeDefault`: the container runtimes default profile will be used +- `Localhost`: a node local profile will be applied, which is being referenced + by a relative path to the seccomp profile root (`/seccomp`) + of the kubelet + +With the graduation of seccomp, nothing has changed from an overall security +perspective, because `Unconfined` is still the default. This is totally fine if +you consider this from the upgrade path and backwards compatibility perspective of +Kubernetes releases. But it also means that it is more likely that a workload +runs without seccomp at all, which should be fixed in the long term. + +## `SeccompDefault` to the rescue + +Kubernetes v1.22.0 introduces a new kubelet [feature gate][gate] +`SeccompDefault`, which has been added in `alpha` state as every other new +feature. This means that it is disabled by default and can be enabled manually +for every single Kubernetes node. + +[gate]: /docs/reference/command-line-tools-reference/feature-gates + +What does the feature do? Well, it just changes the default seccomp profile from +`Unconfined` to `RuntimeDefault`. If not specified differently in the pod +manifest, then the feature will add a higher set of security constraints by +using the default profile of the container runtime. These profiles may differ +between runtimes like [CRI-O][crio] or [containerd][ctrd]. They also differ for +its used hardware architectures. But generally speaking, those default profiles +allow a common amount of syscalls while blocking the more dangerous ones, which +are unlikely or unsafe to be used in a containerized application. + +[crio]: https://github.com/cri-o/cri-o/blob/fe30d62/vendor/github.com/containers/common/pkg/seccomp/default_linux.go#L45 +[ctrd]: https://github.com/containerd/containerd/blob/e1445df/contrib/seccomp/seccomp_default.go#L51 + +### Enabling the feature + +Two kubelet configuration changes have to be made to enable the feature: + +1. **Enable the feature** gate by setting the `SeccompDefault=true` via the command + line (`--feature-gates`) or the [kubelet configuration][kubelet] file. +2. **Turn on the feature** by enabling the feature by adding the + `--seccomp-default` command line flag or via the [kubelet + configuration][kubelet] file (`seccompDefault: true`). + +[kubelet]: /docs/tasks/administer-cluster/kubelet-config-file + +The kubelet will error on startup if only one of the above steps have been done. + +### Trying it out + +If the feature is enabled on a node, then you can create a new workload like +this: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pod +spec: + containers: + - name: test-container + image: nginx:1.21 +``` + +Now it is possible to inspect the used seccomp profile by using +[`crictl`][crictl] while investigating the containers [runtime +specification][rspec]: + +[crictl]: https://github.com/kubernetes-sigs/cri-tools +[rspec]: https://github.com/opencontainers/runtime-spec/blob/0c021c1/config-linux.md#seccomp + +```bash +CONTAINER_ID=$(sudo crictl ps -q --name=test-container) +sudo crictl inspect $CONTAINER_ID | jq .info.runtimeSpec.linux.seccomp +``` + +```yaml +{ + "defaultAction": "SCMP_ACT_ERRNO", + "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_X32"], + "syscalls": [ + { + "names": ["_llseek", "_newselect", "accept", …, "write", "writev"], + "action": "SCMP_ACT_ALLOW" + }, + … + ] +} +``` + +You can see that the lower level container runtime ([CRI-O][crio-home] and +[runc][runc] in our case), successfully applied the default seccomp profile. +This profile denies all syscalls per default, while allowing commonly used ones +like [`accept`][accept] or [`write`][write]. + +[crio-home]: https://github.com/cri-o/cri-o +[runc]: https://github.com/opencontainers/runc +[accept]: https://man7.org/linux/man-pages/man2/accept.2.html +[write]: https://man7.org/linux/man-pages/man2/write.2.html + +Please note that the feature will not influence any Kubernetes API for now. +Therefore, it is not possible to retrieve the used seccomp profile via `kubectl` +`get` or `describe` if the [`SeccompProfile`][api] field is unset within the +`SecurityContext`. + +[api]: https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context-1 + +The feature also works when using multiple containers within a pod, for example +if you create a pod like this: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pod +spec: + containers: + - name: test-container-nginx + image: nginx:1.21 + securityContext: + seccompProfile: + type: Unconfined + - name: test-container-redis + image: redis:6.2 +``` + +then you should see that the `test-container-nginx` runs without a seccomp profile: + +```bash +sudo crictl inspect $(sudo crictl ps -q --name=test-container-nginx) | + jq '.info.runtimeSpec.linux.seccomp == null' +true +``` + +Whereas the container `test-container-redis` runs with `RuntimeDefault`: + +```bash +sudo crictl inspect $(sudo crictl ps -q --name=test-container-redis) | + jq '.info.runtimeSpec.linux.seccomp != null' +true +``` + +The same applies to the pod itself, which also runs with the default profile: + +```bash +sudo crictl inspectp (sudo crictl pods -q --name test-pod) | + jq '.info.runtimeSpec.linux.seccomp != null' +true +``` + +### Upgrade strategy + +It is recommended to enable the feature in multiple steps, whereas different +risks and mitigations exist for each one. + +#### Feature gate enabling + +Enabling the feature gate at the kubelet level will not turn on the feature, but +will make it possible by using the `SeccompDefault` kubelet configuration or the +`--seccomp-default` CLI flag. This can be done by an administrator for the whole +cluster or only a set of nodes. + +#### Testing the Application + +If you're trying this within a dedicated test environment, you have to ensure +that the application code does not trigger syscalls blocked by the +`RuntimeDefault` profile before enabling the feature on a node. This can be done +by: + +- _Recommended_: Analyzing the code (manually or by running the application with + [strace][strace]) for any executed syscalls which may be blocked by the + default profiles. If that's the case, then you can override the default by + explicitly setting the pod or container to run as `Unconfined`. Alternatively, + you can create a custom seccomp profile (see optional step below). + profile based on the default by adding the additional syscalls to the + `"action": "SCMP_ACT_ALLOW"` section. + +- _Recommended_: Manually set the profile to the target workload and use a + rolling upgrade to deploy into production. Rollback the deployment if the + application does not work as intended. + +- _Optional_: Run the application against an end-to-end test suite to trigger + all relevant code paths with `RuntimeDefault` enabled. If a test fails, use + the same mitigation as mentioned above. + +- _Optional_: Create a custom seccomp profile based on the default and change + its default action from `SCMP_ACT_ERRNO` to `SCMP_ACT_LOG`. This means that + the seccomp filter for unknown syscalls will have no effect on the application + at all, but the system logs will now indicate which syscalls may be blocked. + This requires at least a Kernel version 4.14 as well as a recent [runc][runc] + release. Monitor the application hosts audit logs (defaults to + `/var/log/audit/audit.log`) or syslog entries (defaults to `/var/log/syslog`) + for syscalls via `type=SECCOMP` (for audit) or `type=1326` (for syslog). + Compare the syscall ID with those [listed in the Linux Kernel + sources][syscalls] and add them to the custom profile. Be aware that custom + audit policies may lead into missing syscalls, depending on the configuration + of auditd. + +- _Optional_: Use cluster additions like the [Security Profiles Operator][spo] + for profiling the application via its [log enrichment][logs] capabilities or + recording a profile by using its [recording feature][rec]. This makes the + above mentioned manual log investigation obsolete. + +[syscalls]: https://github.com/torvalds/linux/blob/7bb7f2a/arch/x86/entry/syscalls/syscall_64.tbl +[spo]: https://github.com/kubernetes-sigs/security-profiles-operator +[logs]: https://github.com/kubernetes-sigs/security-profiles-operator/blob/c90ef3a/installation-usage.md#record-profiles-from-workloads-with-profilerecordings +[rec]: https://github.com/kubernetes-sigs/security-profiles-operator/blob/c90ef3a/installation-usage.md#using-the-log-enricher +[strace]: https://man7.org/linux/man-pages/man1/strace.1.html + +#### Deploying the modified application + +Based on the outcome of the application tests, it may be required to change the +application deployment by either specifying `Unconfined` or a custom seccomp +profile. This is not the case if the application works as intended with +`RuntimeDefault`. + +#### Enable the kubelet configuration + +If everything went well, then the feature is ready to be enabled by the kubelet +configuration or its corresponding CLI flag. This should be done on a per-node +basis to reduce the overall risk of missing a syscall during the investigations +when running the application tests. If it's possible to monitor audit logs +within the cluster, then it's recommended to do this for eventually missed +seccomp events. If the application works as intended then the feature can be +enabled for further nodes within the cluster. + +## Conclusion + +Thank you for reading this blog post! I hope you enjoyed to see how the usage of +seccomp profiles has been evolved in Kubernetes over the past releases as much +as I do. On your own cluster, change the default seccomp profile to +`RuntimeDefault` (using this new feature) and see the security benefits, and, of +course, feel free to reach out any time for feedback or questions. + +--- + +_Editor's note: If you have any questions or feedback about this blog post, feel +free to reach out via the [Kubernetes slack in #sig-node][slack]._ + +[slack]: https://kubernetes.slack.com/messages/sig-node diff --git a/content/en/blog/_posts/2021-08-27-minreadysecond-statefulsets.md b/content/en/blog/_posts/2021-08-27-minreadysecond-statefulsets.md new file mode 100644 index 0000000000..390665950e --- /dev/null +++ b/content/en/blog/_posts/2021-08-27-minreadysecond-statefulsets.md @@ -0,0 +1,48 @@ +--- +layout: blog +title: 'Minimum Ready Seconds for StatefulSets' +date: 2021-08-27 +slug: minreadyseconds-statefulsets +--- + +**Authors:** Ravi Gudimetla (Red Hat), Maciej Szulik (Red Hat) + +This blog describes the notion of Availability for `StatefulSet` workloads, and a new alpha feature in Kubernetes 1.22 which adds `minReadySeconds` configuration for `StatefulSets`. + +## What problems does this solve? + +Prior to Kubernetes 1.22 release, once a `StatefulSet` `Pod` is in the `Ready` state it is considered `Available` to receive traffic. For some of the `StatefulSet` workloads, it may not be the case. For example, a workload like Prometheus with multiple instances of Alertmanager, it should be considered `Available` only when Alertmanager's state transfer is complete, not when the `Pod` is in `Ready` state. Since `minReadySeconds` adds buffer, the state transfer may be complete before the `Pod` becomes `Available`. While this is not a fool proof way of identifying if the state transfer is complete or not, it gives a way to the end user to express their intention of waiting for sometime before the `Pod` is considered `Available` and it is ready to serve requests. + +Another case, where `minReadySeconds` helps is when using `LoadBalancer` `Services` with cloud providers. Since `minReadySeconds` adds latency after a `Pod` is `Ready`, it provides buffer time to prevent killing pods in rotation before new pods show up. Imagine a load balancer in unhappy path taking 10-15s to propagate. If you have 2 replicas then, you'd kill the second replica only after the first one is up but in reality, first replica cannot be seen because it is not yet ready to serve requests. + +So, in general, the notion of `Availability` in `StatefulSets` is pretty useful and this feature helps in solving the above problems. This is a feature that already exists for `Deployments` and `DaemonSets` and we now have them for `StatefulSets` too to give users consistent workload experience. + + +## How does it work? + +The statefulSet controller watches for both `StatefulSets` and the `Pods` associated with them. When the feature gate associated with this feature is enabled, the statefulSet controller identifies how long a particular `Pod` associated with a `StatefulSet` has been in the `Running` state. + +If this value is greater than or equal to the time specified by the end user in `.spec.minReadySeconds` field, the statefulSet controller updates a field called `availableReplicas` in the `StatefulSet`'s status subresource to include this `Pod`. The `status.availableReplicas` in `StatefulSet`'s status is an integer field which tracks the number of pods that are `Available`. + +## How do I use it? + +You are required to prepare the following things in order to try out the feature: + + - Download and install a kubectl greater than v1.22.0 version + - Switch on the feature gate with the command line flag `--feature-gates=StatefulSetMinReadySeconds=true` on `kube-apiserver` and `kube-controller-manager` + +After successfully starting `kube-apiserver` and `kube-controller-manager`, you will see `AvailableReplicas` in the status and `minReadySeconds` of spec (with a default value of 0). + +Specify a value for `minReadySeconds` for any StatefulSet and you can check if `Pods` are available or not by checking `AvailableReplicas` field using: +`kubectl get statefulset/ -o yaml` + +## How can I learn more? + +- Read the KEP: [minReadySeconds for StatefulSets](https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/2599-minreadyseconds-for-statefulsets#readme) +- Read the documentation: [Minimum ready seconds](/docs/concepts/workloads/controllers/statefulset/#minimum-ready-seconds) for StatefulSet +- Review the [API definition](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/) for StatefulSet + +## How do I get involved? + +Please reach out to us in the [#sig-apps](https://kubernetes.slack.com/archives/C18NZM5K9) channel on Slack (visit https://slack.k8s.io/ for an invitation if you need one), or on the SIG Apps mailing list: kubernetes-sig-apps@googlegroups.com + diff --git a/content/en/blog/_posts/2021-08-30-volume-populators-alpha.md b/content/en/blog/_posts/2021-08-30-volume-populators-alpha.md new file mode 100644 index 0000000000..4f3a408584 --- /dev/null +++ b/content/en/blog/_posts/2021-08-30-volume-populators-alpha.md @@ -0,0 +1,219 @@ +--- +layout: blog +title: "Kubernetes 1.22: A New Design for Volume Populators" +date: 2021-08-30 +slug: volume-populators-redesigned +--- + +**Authors:** +Ben Swartzlander (NetApp) + +Kubernetes v1.22, released earlier this month, introduced a redesigned approach for volume +populators. Originally implemented +in v1.18, the API suffered from backwards compatibility issues. Kubernetes v1.22 includes a new API +field called `dataSourceRef` that fixes these problems. + +## Data sources + +Earlier Kubernetes releases already added a `dataSource` field into the +[PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) API, +used for cloning volumes and creating volumes from snapshots. You could use the `dataSource` field when +creating a new PVC, referencing either an existing PVC or a VolumeSnapshot in the same namespace. +That also modified the normal provisioning process so that instead of yielding an empty volume, the +new PVC contained the same data as either the cloned PVC or the cloned VolumeSnapshot. + +Volume populators embrace the same design idea, but extend it to any type of object, as long +as there exists a [custom resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +to define the data source, and a populator controller to implement the logic. Initially, +the `dataSource` field was directly extended to allow arbitrary objects, if the `AnyVolumeDataSource` +feature gate was enabled on a cluster. That change unfortunately caused backwards compatibility +problems, and so the new `dataSourceRef` field was born. + +In v1.22 if the `AnyVolumeDataSource` feature gate is enabled, the `dataSourceRef` field is +added, which behaves similarly to the `dataSource` field except that it allows arbitrary +objects to be specified. The API server ensures that the two fields always have the same +contents, and neither of them are mutable. The differences is that at creation time +`dataSource` allows only PVCs or VolumeSnapshots, and ignores all other values, while +`dataSourceRef` allows most types of objects, and in the few cases it doesn't allow an +object (core objects other than PVCs) a validation error occurs. + +When this API change graduates to stable, we would deprecate using `dataSource` and recommend +using `dataSourceRef` field for all use cases. +In the v1.22 release, `dataSourceRef` is available (as an alpha feature) specifically for cases +where you want to use for custom volume populators. + +## Using populators + +Every volume populator must have one or more CRDs that it supports. Administrators may +install the CRD and the populator controller and then PVCs with a `dataSourceRef` specifies +a CR of the type that the populator supports will be handled by the populator controller +instead of the CSI driver directly. + +Underneath the covers, the CSI driver is still invoked to create an empty volume, which +the populator controller fills with the appropriate data. The PVC doesn't bind to the PV +until it's fully populated, so it's safe to define a whole application manifest including +pod and PVC specs and the pods won't begin running until everything is ready, just as if +the PVC was a clone of another PVC or VolumeSnapshot. + +## How it works + +PVCs with data sources are still noticed by the external-provisioner sidecar for the +related storage class (assuming a CSI provisioner is used), but because the sidecar +doesn't understand the data source kind, it doesn't do anything. The populator controller +is also watching for PVCs with data sources of a kind that it understands and when it +sees one, it creates a temporary PVC of the same size, volume mode, storage class, +and even on the same topology (if topology is used) as the original PVC. The populator +controller creates a worker pod that attaches to the volume and writes the necessary +data to it, then detaches from the volume and the populator controller rebinds the PV +from the temporary PVC to the orignal PVC. + +## Trying it out + +The following things are required to use volume populators: +* Enable the `AnyVolumeDataSource` feature gate +* Install a CRD for the specific data source / populator +* Install the populator controller itself + +Populator controllers may use the [lib-volume-populator](https://github.com/kubernetes-csi/lib-volume-populator) +library to do most of the Kubernetes API level work. Individual populators only need to +provide logic for actually writing data into the volume based on a particular CR +instance. This library provides a sample populator implementation. + +These optional components improve user experience: +* Install the VolumePopulator CRD +* Create a VolumePopulator custom respource for each specific data source +* Install the [volume data source validator](https://github.com/kubernetes-csi/volume-data-source-validator) + controller (alpha) + +The purpose of these components is to generate warning events on PVCs with data sources +for which there is no populator. + +## Putting it all together + +To see how this works, you can install the sample "hello" populator and try it +out. + +First install the volume-data-source-validator controller. + +```terminal +kubectl apply -f https://github.com/kubernetes-csi/volume-data-source-validator/blob/master/deploy/kubernetes/rbac-data-source-validator.yaml +kubectl apply -f https://github.com/kubernetes-csi/volume-data-source-validator/blob/master/deploy/kubernetes/setup-data-source-validator.yaml +``` + +Next install the example populator. + +```terminal +kubectl apply -f https://github.com/kubernetes-csi/lib-volume-populator/blob/master/example/hello-populator/crd.yaml +kubectl apply -f https://github.com/kubernetes-csi/lib-volume-populator/blob/master/example/hello-populator/deploy.yaml +``` + +Create an instance of the `Hello` CR, with some text. + +```yaml +apiVersion: hello.k8s.io/v1alpha1 +kind: Hello +metadata: + name: example-hello +spec: + fileName: example.txt + fileContents: Hello, world! +``` + +Create a PVC that refers to that CR as its data source. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: example-pvc +spec: + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Mi + dataSourceRef: + apiGroup: hello.k8s.io + kind: Hello + name: example-hello + volumeMode: Filesystem +``` + +Next, run a job that reads the file in the PVC. + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: example-job +spec: + template: + spec: + containers: + - name: example-container + image: busybox:latest + command: + - cat + - /mnt/example.txt + volumeMounts: + - name: vol + mountPath: /mnt + restartPolicy: Never + volumes: + - name: vol + persistentVolumeClaim: + claimName: example-pvc +``` + +Wait for the job to complete (including all of its dependencies). + +```terminal +kubectl wait --for=condition=Complete job/example-job +``` + +And last examine the log from the job. + +```terminal +kubectl logs job/example-job +Hello, world! +``` + +Note that the volume already contained a text file with the string contents from +the CR. This is only the simplest example. Actual populators can set up the volume +to contain arbitrary contents. + +## How to write your own volume populator + +Developers interested in writing new poplators are encouraged to use the +[lib-volume-populator](https://github.com/kubernetes-csi/lib-volume-populator) library +and to only supply a small controller wrapper around the library, and a pod image +capable of attaching to volumes and writing the appropriate data to the volume. + +Individual populators can be extremely generic such that they work with every type +of PVC, or they can do vendor specific things to rapidly fill a volume with data +if the volume was provisioned by a specific CSI driver from the same vendor, for +example, by communicating directly with the storage for that volume. + +## The future + +As this feature is still in alpha, we expect to update the out of tree controllers +with more tests and documentation. The community plans to eventually re-implement +the populator library as a sidecar, for ease of operations. + +We hope to see some official community-supported populators for some widely-shared +use cases. Also, we expect that volume populators will be used by backup vendors +as a way to "restore" backups to volumes, and possibly a standardized API to do +this will evolve. + +## How can I learn more? + +The enhancement proposal, +[Volume Populators](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1495-volume-populators), includes lots of detail about the history and technical implementation +of this feature. + +[Volume populators and data sources](/docs/concepts/storage/persistent-volumes/#volume-populators-and-data-sources), within the documentation topic about persistent volumes, +explains how to use this feature in your cluster. + +Please get involved by joining the Kubernetes storage SIG to help us enhance this +feature. There are a lot of good ideas already and we'd be thrilled to have more! + diff --git a/content/en/blog/_posts/2021-09-03-api-server-tracing.md b/content/en/blog/_posts/2021-09-03-api-server-tracing.md new file mode 100644 index 0000000000..fc98a68d23 --- /dev/null +++ b/content/en/blog/_posts/2021-09-03-api-server-tracing.md @@ -0,0 +1,67 @@ +--- +layout: blog +title: 'Alpha in Kubernetes v1.22: API Server Tracing' +date: 2021-09-03 +slug: api-server-tracing +--- + +**Authors:** David Ashpole (Google) + +In distributed systems, it can be hard to figure out where problems are. You grep through one component's logs just to discover that the source of your problem is in another component. You search there only to discover that you need to enable debug logs to figure out what really went wrong... And it goes on. The more complex the path your request takes, the harder it is to answer questions about where it went. I've personally spent many hours doing this dance with a variety of Kubernetes components. Distributed tracing is a tool which is designed to help in these situations, and the Kubernetes API Server is, perhaps, the most important Kubernetes component to be able to debug. At Kubernetes' Sig Instrumentation, our mission is to make it easier to understand what's going on in your cluster, and we are happy to announce that distributed tracing in the Kubernetes API Server reached alpha in 1.22. + +## What is Tracing? + +Distributed tracing links together a bunch of super-detailed information from multiple different sources, and structures that telemetry into a single tree for that request. Unlike logging, which limits the quantity of data ingested by using log levels, tracing collects all of the details and uses sampling to collect only a small percentage of requests. This means that once you have a trace which demonstrates an issue, you should have all the information you need to root-cause the problem--no grepping for object UID required! My favorite aspect, though, is how useful the visualizations of traces are. Even if you don't understand the inner workings of the API Server, or don't have a clue what an etcd "Transaction" is, I'd wager you (yes, you!) could tell me roughly what the order of events was, and which components were involved in the request. If some step takes a long time, it is easy to tell where the problem is. + +## Why OpenTelemetry? + +It's important that Kubernetes works well for everyone, regardless of who manages your infrastructure, or which vendors you choose to integrate with. That is particularly true for Kubernetes' integrations with telemetry solutions. OpenTelemetry, being a CNCF project, shares these core values, and is creating exactly what we need in Kubernetes: A set of open standards for Tracing client library APIs and a standard trace format. By using OpenTelemetry, we can ensure users have the freedom to choose their backend, and ensure vendors have a level playing field. The timing couldn't be better: the OpenTelemetry golang API and SDK are very close to their 1.0 release, and will soon offer backwards-compatibility for these open standards. + +## Why instrument the API Server? + +The Kubernetes API Server is a great candidate for tracing for a few reasons: + +* It follows the standard "RPC" model (serve a request by making requests to downstream components), which makes it easy to instrument. +* Users are latency-sensitive: If a request takes more than 10 seconds to complete, many clients will time-out. +* It has a complex service topology: A single request could require consulting a dozen webhooks, or involve multiple requests to etcd. + +## Trying out APIServer Tracing with a webhook + +### Enabling API Server Tracing + +1. Enable the APIServerTracing [feature-gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/). + +2. Set our configuration for tracing by pointing the `--tracing-config-file` flag on the kube-apiserver at our config file, which contains: + +```yaml +apiVersion: apiserver.config.k8s.io/v1alpha1 +kind: TracingConfiguration +# 1% sampling rate +samplingRatePerMillion: 10000 +``` + +### Enabling Etcd Tracing + +Add `--experimental-enable-distributed-tracing`, `--experimental-distributed-tracing-address=0.0.0.0:4317`, `--experimental-distributed-tracing-service-name=etcd` flags to etcd to enable tracing. Note that this traces every request, so it will probably generate a lot of traces if you enable it. + +### Example Trace: List Nodes + +I could've used any trace backend, but decided to use Jaeger, since it is one of the most popular open-source tracing projects. I deployed [the Jaeger All-in-one container](https://hub.docker.com/r/jaegertracing/all-in-one) in my cluster, deployed [the OpenTelemetry collector](https://github.com/open-telemetry/opentelemetry-collector) on my control-plane node ([example](https://github.com/dashpole/dashpole_demos/tree/master/otel/controlplane)), and captured traces like this one: + +![Jaeger screenshot showing API server and etcd trace](/images/blog/2021-09-03-api-server-tracing/example-trace-1.png "Jaeger screenshot showing API server and etcd trace") + +The teal lines are from the API Server, and includes it serving a request to `/api/v1/nodes`, and issuing a grpc `Range` RPC to ETCD. The yellow-ish line is from ETCD handling the `Range` RPC. + +### Example Trace: Create Pod with Mutating Webhook + +I instrumented the [example webhook](https://github.com/kubernetes-sigs/controller-runtime/tree/master/examples/builtins) with OpenTelemetry (I had to [patch](https://github.com/dashpole/controller-runtime/commit/85fdda7ba03dd2c22ef62c1a3dbdf5aa651f90da) controller-runtime, but it makes a neat demo), and routed traces to Jaeger as well. I collected traces like this one: + +![Jaeger screenshot showing API server, admission webhook, and etcd trace](/images/blog/2021-09-03-api-server-tracing/example-trace-2.png "Jaeger screenshot showing API server, admission webhook, and etcd trace") + +Compared with the previous trace, there are two new spans: A teal span from the API Server making a request to the admission webhook, and a brown span from the admission webhook serving the request. Even if you didn't instrument your webhook, you would still get the span from the API Server making the request to the webhook. + +## Get involved! + +As this is our first attempt at adding distributed tracing to a Kubernetes component, there is probably a lot we can improve! If my struggles resonated with you, or if you just want to try out the latest Kubernetes has to offer, please give the feature a try and open issues with any problem you encountered and ways you think the feature could be improved. + +This is just the very beginning of what we can do with distributed tracing in Kubernetes. If there are other components you think would benefit from distributed tracing, or want to help bring API Server Tracing to GA, join sig-instrumentation at our [regular meetings](https://github.com/kubernetes/community/tree/master/sig-instrumentation#instrumentation-special-interest-group) and get involved! diff --git a/content/en/blog/_posts/2021-09-13-read-write-once-pod-access-mode-alpha.md b/content/en/blog/_posts/2021-09-13-read-write-once-pod-access-mode-alpha.md new file mode 100644 index 0000000000..c04df56284 --- /dev/null +++ b/content/en/blog/_posts/2021-09-13-read-write-once-pod-access-mode-alpha.md @@ -0,0 +1,287 @@ +--- +layout: blog +title: "Introducing Single Pod Access Mode for PersistentVolumes" +date: 2021-09-13 +slug: read-write-once-pod-access-mode-alpha +--- + +**Author:** Chris Henzie (Google) + +Last month's release of Kubernetes v1.22 introduced a new ReadWriteOncePod access mode for [PersistentVolumes](/docs/concepts/storage/persistent-volumes/#persistent-volumes) and [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims). +With this alpha feature, Kubernetes allows you to restrict volume access to a single pod in the cluster. + +## What are access modes and why are they important? + +When using storage, there are different ways to model how that storage is consumed. + +For example, a storage system like a network file share can have many users all reading and writing data simultaneously. +In other cases maybe everyone is allowed to read data but not write it. +For highly sensitive data, maybe only one user is allowed to read and write data but nobody else. + +In the world of Kubernetes, [access modes](/docs/concepts/storage/persistent-volumes/#access-modes) are the way you can define how durable storage is consumed. +These access modes are a part of the spec for PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs). + +```yaml +kind: PersistentVolumeClaim +apiVersion: v1 +metadata: + name: shared-cache +spec: + accessModes: + - ReadWriteMany # Allow many pods to access shared-cache simultaneously. + resources: + requests: + storage: 1Gi +``` + +Before v1.22, Kubernetes offered three access modes for PVs and PVCs: + +- ReadWriteOnce – the volume can be mounted as read-write by a single node +- ReadOnlyMany – the volume can be mounted read-only by many nodes +- ReadWriteMany – the volume can be mounted as read-write by many nodes + +These access modes are enforced by Kubernetes components like the `kube-controller-manager` and `kubelet` to ensure only certain pods are allowed to access a given PersistentVolume. + +## What is this new access mode and how does it work? + +Kubernetes v1.22 introduced a fourth access mode for PVs and PVCs, that you can use for CSI volumes: + +- ReadWriteOncePod – the volume can be mounted as read-write by a single pod + +If you create a pod with a PVC that uses the ReadWriteOncePod access mode, Kubernetes ensures that pod is the only pod across your whole cluster that can read that PVC or write to it. + +If you create another pod that references the same PVC with this access mode, the pod will fail to start because the PVC is already in use by another pod. +For example: + +``` +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Warning FailedScheduling 1s default-scheduler 0/1 nodes are available: 1 node has pod using PersistentVolumeClaim with the same name and ReadWriteOncePod access mode. +``` + +### How is this different than the ReadWriteOnce access mode? + +The ReadWriteOnce access mode restricts volume access to a single *node*, which means it is possible for multiple pods on the same node to read from and write to the same volume. +This could potentially be a major problem for some applications, especially if they require at most one writer for data safety guarantees. + +With ReadWriteOncePod these issues go away. +Set the access mode on your PVC, and Kubernetes guarantees that only a single pod has access. + +## How do I use it? + +The ReadWriteOncePod access mode is in alpha for Kubernetes v1.22 and is only supported for CSI volumes. +As a first step you need to enable the ReadWriteOncePod [feature gate](/docs/reference/command-line-tools-reference/feature-gates) for `kube-apiserver`, `kube-scheduler`, and `kubelet`. +You can enable the feature by setting command line arguments: + +``` +--feature-gates="...,ReadWriteOncePod=true" +``` + +You also need to update the following CSI sidecars to these versions or greater: + +- [csi-provisioner:v3.0.0+](https://github.com/kubernetes-csi/external-provisioner/releases/tag/v3.0.0) +- [csi-attacher:v3.3.0+](https://github.com/kubernetes-csi/external-attacher/releases/tag/v3.3.0) +- [csi-resizer:v1.3.0+](https://github.com/kubernetes-csi/external-resizer/releases/tag/v1.3.0) + +### Creating a PersistentVolumeClaim + +In order to use the ReadWriteOncePod access mode for your PVs and PVCs, you will need to create a new PVC with the access mode: + +```yaml +kind: PersistentVolumeClaim +apiVersion: v1 +metadata: + name: single-writer-only +spec: + accessModes: + - ReadWriteOncePod # Allow only a single pod to access single-writer-only. + resources: + requests: + storage: 1Gi +``` + +If your storage plugin supports [dynamic provisioning](/docs/concepts/storage/dynamic-provisioning/), new PersistentVolumes will be created with the ReadWriteOncePod access mode applied. + +#### Migrating existing PersistentVolumes + +If you have existing PersistentVolumes, they can be migrated to use ReadWriteOncePod. + +In this example, we already have a "cat-pictures-pvc" PersistentVolumeClaim that is bound to a "cat-pictures-pv" PersistentVolume, and a "cat-pictures-writer" Deployment that uses this PersistentVolumeClaim. + +As a first step, you need to edit your PersistentVolume's `spec.persistentVolumeReclaimPolicy` and set it to `Retain`. +This ensures your PersistentVolume will not be deleted when we delete the corresponding PersistentVolumeClaim: + +```shell +kubectl patch pv cat-pictures-pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}' +``` + +Next you need to stop any workloads that are using the PersistentVolumeClaim bound to the PersistentVolume you want to migrate, and then delete the PersistentVolumeClaim. + +Once that is done, you need to clear your PersistentVolume's `spec.claimRef.uid` to ensure PersistentVolumeClaims can bind to it upon recreation: + +```shell +kubectl scale --replicas=0 deployment cat-pictures-writer +kubectl delete pvc cat-pictures-pvc +kubectl patch pv cat-pictures-pv -p '{"spec":{"claimRef":{"uid":""}}}' +``` + +After that you need to replace the PersistentVolume's access modes with ReadWriteOncePod: + +```shell +kubectl patch pv cat-pictures-pv -p '{"spec":{"accessModes":["ReadWriteOncePod"]}}' +``` + +{{< note >}} +The ReadWriteOncePod access mode cannot be combined with other access modes. +Make sure ReadWriteOncePod is the only access mode on the PersistentVolume when updating, otherwise the request will fail. +{{< /note >}} + +Next you need to modify your PersistentVolumeClaim to set ReadWriteOncePod as the only access mode. +You should also set your PersistentVolumeClaim's `spec.volumeName` to the name of your PersistentVolume. + +Once this is done, you can recreate your PersistentVolumeClaim and start up your workloads: + +```shell +# IMPORTANT: Make sure to edit your PVC in cat-pictures-pvc.yaml before applying. You need to: +# - Set ReadWriteOncePod as the only access mode +# - Set spec.volumeName to "cat-pictures-pv" + +kubectl apply -f cat-pictures-pvc.yaml +kubectl apply -f cat-pictures-writer-deployment.yaml +``` + +Lastly you may edit your PersistentVolume's `spec.persistentVolumeReclaimPolicy` and set to it back to `Delete` if you previously changed it. + +```shell +kubectl patch pv cat-pictures-pv -p '{"spec":{"persistentVolumeReclaimPolicy":"Delete"}}' +``` + +You can read [Configure a Pod to Use a PersistentVolume for Storage](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/) for more details on working with PersistentVolumes and PersistentVolumeClaims. + +## What volume plugins support this? + +The only volume plugins that support this are CSI drivers. +SIG Storage does not plan to support this for in-tree plugins because they are being deprecated as part of [CSI migration](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#what-is-the-timeline-status). +Support may be considered for beta for users that prefer to use the legacy in-tree volume APIs with CSI migration enabled. + +## As a storage vendor, how do I add support for this access mode to my CSI driver? + +The ReadWriteOncePod access mode will work out of the box without any required updates to CSI drivers, but [does require updates to CSI sidecars](#update-your-csi-sidecars). +With that being said, if you would like to stay up to date with the latest changes to the CSI specification (v1.5.0+), read on. + +Two new access modes were introduced to the CSI specification in order to disambiguate the legacy [`SINGLE_NODE_WRITER`](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L418-L420) access mode. +They are [`SINGLE_NODE_SINGLE_WRITER` and `SINGLE_NODE_MULTI_WRITER`](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L437-L447). +In order to communicate to sidecars (like the [external-provisioner](https://github.com/kubernetes-csi/external-provisioner)) that your driver understands and accepts these two new CSI access modes, your driver will also need to advertise the `SINGLE_NODE_MULTI_WRITER` capability for the [controller service](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L1073-L1081) and [node service](https://github.com/container-storage-interface/spec/blob/v1.5.0/csi.proto#L1515-L1524). + +If you'd like to read up on the motivation for these access modes and capability bits, you can also read the [CSI Specification Changes, Volume Capabilities](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/2485-read-write-once-pod-pv-access-mode/README.md#csi-specification-changes-volume-capabilities) section of KEP-2485 (ReadWriteOncePod PersistentVolume Access Mode). + +### Update your CSI driver to use the new interface + +As a first step you will need to update your driver's `container-storage-interface` dependency to v1.5.0+, which contains support for these new access modes and capabilities. + +### Accept new CSI access modes + +If your CSI driver contains logic for validating CSI access modes for requests , it may need updating. +If it currently accepts `SINGLE_NODE_WRITER`, it should be updated to also accept `SINGLE_NODE_SINGLE_WRITER` and `SINGLE_NODE_MULTI_WRITER`. + +Using the [GCP PD CSI driver validation logic](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/blob/v1.2.2/pkg/gce-pd-csi-driver/utils.go#L116-L130) as an example, here is how it can be extended: + +```diff +diff --git a/pkg/gce-pd-csi-driver/utils.go b/pkg/gce-pd-csi-driver/utils.go +index 281242c..b6c5229 100644 +--- a/pkg/gce-pd-csi-driver/utils.go ++++ b/pkg/gce-pd-csi-driver/utils.go +@@ -123,6 +123,8 @@ func validateAccessMode(am *csi.VolumeCapability_AccessMode) error { + case csi.VolumeCapability_AccessMode_SINGLE_NODE_READER_ONLY: + case csi.VolumeCapability_AccessMode_MULTI_NODE_READER_ONLY: + case csi.VolumeCapability_AccessMode_MULTI_NODE_MULTI_WRITER: ++ case csi.VolumeCapability_AccessMode_SINGLE_NODE_SINGLE_WRITER: ++ case csi.VolumeCapability_AccessMode_SINGLE_NODE_MULTI_WRITER: + default: + return fmt.Errorf("%v access mode is not supported for for PD", am.GetMode()) + } +``` + +### Advertise new CSI controller and node service capabilities + +Your CSI driver will also need to return the new `SINGLE_NODE_MULTI_WRITER` capability as part of the `ControllerGetCapabilities` and `NodeGetCapabilities` RPCs. + +Using the [GCP PD CSI driver capability advertisement logic](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver/blob/v1.2.2/pkg/gce-pd-csi-driver/gce-pd-driver.go#L54-L77) as an example, here is how it can be extended: + +```diff +diff --git a/pkg/gce-pd-csi-driver/gce-pd-driver.go b/pkg/gce-pd-csi-driver/gce-pd-driver.go +index 45903f3..0d7ea26 100644 +--- a/pkg/gce-pd-csi-driver/gce-pd-driver.go ++++ b/pkg/gce-pd-csi-driver/gce-pd-driver.go +@@ -56,6 +56,8 @@ func (gceDriver *GCEDriver) SetupGCEDriver(name, vendorVersion string, extraVolu + csi.VolumeCapability_AccessMode_SINGLE_NODE_WRITER, + csi.VolumeCapability_AccessMode_MULTI_NODE_READER_ONLY, + csi.VolumeCapability_AccessMode_MULTI_NODE_MULTI_WRITER, ++ csi.VolumeCapability_AccessMode_SINGLE_NODE_SINGLE_WRITER, ++ csi.VolumeCapability_AccessMode_SINGLE_NODE_MULTI_WRITER, + } + gceDriver.AddVolumeCapabilityAccessModes(vcam) + csc := []csi.ControllerServiceCapability_RPC_Type{ +@@ -67,12 +69,14 @@ func (gceDriver *GCEDriver) SetupGCEDriver(name, vendorVersion string, extraVolu + csi.ControllerServiceCapability_RPC_EXPAND_VOLUME, + csi.ControllerServiceCapability_RPC_LIST_VOLUMES, + csi.ControllerServiceCapability_RPC_LIST_VOLUMES_PUBLISHED_NODES, ++ csi.ControllerServiceCapability_RPC_SINGLE_NODE_MULTI_WRITER, + } + gceDriver.AddControllerServiceCapabilities(csc) + ns := []csi.NodeServiceCapability_RPC_Type{ + csi.NodeServiceCapability_RPC_STAGE_UNSTAGE_VOLUME, + csi.NodeServiceCapability_RPC_EXPAND_VOLUME, + csi.NodeServiceCapability_RPC_GET_VOLUME_STATS, ++ csi.NodeServiceCapability_RPC_SINGLE_NODE_MULTI_WRITER, + } + gceDriver.AddNodeServiceCapabilities(ns) +``` + +### Implement `NodePublishVolume` behavior + +The CSI spec outlines expected behavior for the `NodePublishVolume` RPC when called more than once for the same volume but with different arguments (like the target path). +Please refer to [the second table in the NodePublishVolume section of the CSI spec](https://github.com/container-storage-interface/spec/blob/v1.5.0/spec.md#nodepublishvolume) for more details on expected behavior when implementing in your driver. + +### Update your CSI sidecars + +When deploying your CSI drivers, you must update the following CSI sidecars to versions that depend on CSI spec v1.5.0+ and the Kubernetes v1.22 API. +The minimum required versions are: + +- [csi-provisioner:v3.0.0+](https://github.com/kubernetes-csi/external-provisioner/releases/tag/v3.0.0) +- [csi-attacher:v3.3.0+](https://github.com/kubernetes-csi/external-attacher/releases/tag/v3.3.0) +- [csi-resizer:v1.3.0+](https://github.com/kubernetes-csi/external-resizer/releases/tag/v1.3.0) + +## What’s next? + +As part of the beta graduation for this feature, SIG Storage plans to update the Kubenetes scheduler to support pod preemption in relation to ReadWriteOncePod storage. +This means if two pods request a PersistentVolumeClaim with ReadWriteOncePod, the pod with highest priority will gain access to the PersistentVolumeClaim and any pod with lower priority will be preempted from the node and be unable to access the PersistentVolumeClaim. + +## How can I learn more? + +Please see [KEP-2485](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/2485-read-write-once-pod-pv-access-mode/README.md) for more details on the ReadWriteOncePod access mode and motivations for CSI spec changes. + +## How do I get involved? + +The [Kubernetes #csi Slack channel](https://kubernetes.slack.com/messages/csi) and any of the [standard SIG Storage communication channels](https://github.com/kubernetes/community/blob/master/sig-storage/README.md#contact) are great mediums to reach out to the SIG Storage and the CSI teams. + +Special thanks to the following people for their insightful reviews and design considerations: + +* Abdullah Gharaibeh (ahg-g) +* Aldo Culquicondor (alculquicondor) +* Ben Swartzlander (bswartz) +* Deep Debroy (ddebroy) +* Hemant Kumar (gnufied) +* Humble Devassy Chirammal (humblec) +* James DeFelice (jdef) +* Jan Šafránek (jsafrane) +* Jing Xu (jingxu97) +* Jordan Liggitt (liggitt) +* Michelle Au (msau42) +* Saad Ali (saad-ali) +* Tim Hockin (thockin) +* Xing Yang (xing-yang) + +If you’re interested in getting involved with the design and development of CSI or any part of the Kubernetes storage system, join the [Kubernetes Storage Special Interest Group](https://github.com/kubernetes/community/tree/master/sig-storage) (SIG). +We’re rapidly growing and always welcome new contributors. diff --git a/content/en/blog/_posts/2021-09-27-SIG-Node-Spotlight/index.md b/content/en/blog/_posts/2021-09-27-SIG-Node-Spotlight/index.md new file mode 100644 index 0000000000..88c9fc890b --- /dev/null +++ b/content/en/blog/_posts/2021-09-27-SIG-Node-Spotlight/index.md @@ -0,0 +1,72 @@ +--- +layout: blog +title: "Spotlight on SIG Node" +date: 2021-09-27 +slug: sig-node-spotlight-2021 +--- + +**Author:** Dewan Ahmed, Red Hat + +## Introduction + +In Kubernetes, a _Node_ is a representation of a single machine in your cluster. [SIG Node](https://github.com/kubernetes/community/tree/master/sig-node) owns that very important Node component and supports various subprojects such as Kubelet, Container Runtime Interface (CRI) and more to support how the pods and host resources interact. In this blog, we have summarized our conversation with [Elana Hashman (EH)](https://twitter.com/ehashdn) & [Sergey Kanzhelev (SK)](https://twitter.com/SergeyKanzhelev), who walk us through the various aspects of being a part of the SIG and share some insights about how others can get involved. + +## A summary of our conversation + +### Could you tell us a little about what SIG Node does? + +SK: SIG Node is a vertical SIG responsible for the components that support the controlled interactions between the pods and host resources. We manage the lifecycle of pods that are scheduled to a node. This SIG's focus is to enable a broad set of workload types, including workloads with hardware specific or performance sensitive requirements. All while maintaining isolation boundaries between pods on a node, as well as the pod and the host. This SIG maintains quite a few components and has many external dependencies (like container runtimes or operating system features), which makes the complexity we deal with huge. We tame the complexity and aim to continuously improve node reliability. + +### "SIG Node is a vertical SIG" could you explain a bit more? + +EH: There are two kinds of SIGs: horizontal and vertical. Horizontal SIGs are concerned with a particular function of every component in Kubernetes: for example, SIG Security considers security aspects of every component in Kubernetes, or SIG Instrumentation looks at the logs, metrics, traces and events of every component in Kubernetes. Such SIGs don't tend to own a lot of code. + +Vertical SIGs, on the other hand, own a single component, and are responsible for approving and merging patches to that code base. SIG Node owns the "Node" vertical, pertaining to the kubelet and its lifecycle. This includes the code for the kubelet itself, as well as the node controller, the container runtime interface, and related subprojects like the node problem detector. + +### How did the CI subproject start? Is this specific to SIG Node and how does it help the SIG? + +SK: The subproject started as a follow up after one of the releases was blocked by numerous test failures of critical tests. These tests haven’t started falling all at once, rather continuous lack of attention led to slow degradation of tests quality. SIG Node was always prioritizing quality and reliability, and forming of the subproject was a way to highlight this priority. + +### As the 3rd largest SIG in terms of number of issues and PRs, how does your SIG juggle so much work? + +EH: It helps to be organized. When I increased my contributions to the SIG in January of 2021, I found myself overwhelmed by the volume of pull requests and issues and wasn't sure where to start. We were already tracking test-related issues and pull requests on the CI subproject board, but that was missing a lot of our bugfixes and feature work. So I began putting together a triage board for the rest of our pull requests, which allowed me to sort each one by status and what actions to take, and documented its use for other contributors. We closed or merged over 500 issues and pull requests tracked by our two boards in each of the past two releases. The Kubernetes devstats showed that we have significantly increased our velocity as a result. + +In June, we ran our first bug scrub event to work through the backlog of issues filed against SIG Node, ensuring they were properly categorized. We closed over 130 issues over the course of this 48 hour global event, but as of writing we still have 333 open issues. + +### Why should new and existing contributors consider joining SIG Node? + +SK: Being a SIG Node contributor gives you skills and recognition that are rewarding and useful. Understanding under the hood of a kubelet helps architecting better apps, tune and optimize those apps, and gives leg up in issues troubleshooting. If you are a new contributor, SIG Node gives you the foundational knowledge that is key to understanding why other Kubernetes components are designed the way they are. Existing contributors may benefit as many features will require SIG Node changes one way or another. So being a SIG Node contributor helps building features in other SIGs faster. + +SIG Node maintains numerous components, many of which have dependency on external projects or OS features. This makes the onboarding process quite lengthy and demanding. But if you are up for a challenge, there is always a place for you, and a group of people to support. + +### What do you do to help new contributors get started? + +EH: Getting started in SIG Node can be intimidating, since there is so much work to be done, our SIG meetings are very large, and it can be hard to find a place to start. + +I always encourage new contributors to work on things that they have some investment in already. In SIG Node, that might mean volunteering to help fix a bug that you have personally been affected by, or helping to triage bugs you care about by priority. + +To come up to speed on any open source code base, there are two strategies you can take: start by exploring a particular issue deeply, and follow that to expand the edges of your knowledge as needed, or briefly review as many issues and change requests as you possibly can to get a higher level picture of how the component works. Ultimately, you will need to do both if you want to become a Node reviewer or approver. + +[Davanum Srinivas](https://twitter.com/dims) and I each ran a cohort of group mentoring to help teach new contributors the skills to become Node reviewers, and if there's interest we can work to find a mentor to run another session. I also encourage new contributors to attend our Node CI Subproject meeting: it's a smaller audience and we don't record the triage sessions, so it can be a less intimidating way to get started with the SIG. + +### Are there any particular skills you’d like to recruit for? What skills are contributors to SIG Usability likely to learn? + +SK: SIG Node works on many workstreams in very different areas. All of these areas are on system level. For the typical code contributions you need to have a passion for building and utilizing low level APIs and writing performant and reliable components. Being a contributor you will learn how to debug and troubleshoot, profile, and monitor these components, as well as user workload that is run by these components. Often, with the limited to no access to Nodes, as they are running production workloads. + +The other way of contribution is to help document SIG node features. This type of contribution requires a deep understanding of features, and ability to explain them in simple terms. + +Finally, we are always looking for feedback on how best to run your workload. Come and explain specifics of it, and what features in SIG Node components may help to run it better. + +### What are you getting positive feedback on, and what’s coming up next for SIG Node? + +EH: Over the past year SIG Node has adopted some new processes to help manage our feature development and Kubernetes enhancement proposals, and other SIGs have looked to us for inspiration in managing large workloads. I hope that this is an area we can continue to provide leadership in and further iterate on. + +We have a great balance of new features and deprecations in flight right now. Deprecations of unused or difficult to maintain features help us keep technical debt and maintenance load under control, and examples include the dockershim and DynamicKubeletConfiguration deprecations. New features will unlock additional functionality in end users' clusters, and include exciting features like support for cgroups v2, swap memory, graceful node shutdowns, and device management policies. + +### Any closing thoughts/resources you’d like to share? + +SK/EH: It takes time and effort to get to any open source community. SIG Node may overwhelm you at first with the number of participants, volume of work, and project scope. But it is totally worth it. Join our welcoming community! [SIG Node GitHub Repo](https://github.com/kubernetes/community/tree/master/sig-node) contains many useful resources including Slack, mailing list and other contact info. + +## Wrap Up + +SIG Node hosted a [KubeCon + CloudNativeCon Europe 2021 talk](https://www.youtube.com/watch?v=z5aY4e2RENA) with an intro and deep dive to their awesome SIG. Join the SIG's meetings to find out about the most recent research results, what the plans are for the forthcoming year, and how to get involved in the upstream Node team as a contributor! \ No newline at end of file diff --git a/content/en/blog/_posts/2021-09-29-data-duplication-in-data-heavy-k8s-env.md b/content/en/blog/_posts/2021-09-29-data-duplication-in-data-heavy-k8s-env.md new file mode 100644 index 0000000000..42e9186692 --- /dev/null +++ b/content/en/blog/_posts/2021-09-29-data-duplication-in-data-heavy-k8s-env.md @@ -0,0 +1,243 @@ +--- +layout: blog +title: "How to Handle Data Duplication in Data-Heavy Kubernetes Environments" +date: 2021-09-29 +slug: how-to-handle-data-duplication-in-data-heavy-kubernetes-environments +--- + +**Authors:** +Augustinas Stirbis (CAST AI) + +## Why Duplicate Data? + +It’s convenient to create a copy of your application with a copy of its state for each team. +For example, you might want a separate database copy to test some significant schema changes +or develop other disruptive operations like bulk insert/delete/update... + +**Duplicating data takes a lot of time.** That’s because you need first to download +all the data from a source block storage provider to compute and then send +it back to a storage provider again. There’s a lot of network traffic and CPU/RAM used in this process. +Hardware acceleration by offloading certain expensive operations to dedicated hardware is +**always a huge performance boost**. It reduces the time required to complete an operation by orders +of magnitude. + +## Volume Snapshots to the rescue + +Kubernetes introduced [VolumeSnapshots](/docs/concepts/storage/volume-snapshots/) as alpha in 1.12, +beta in 1.17, and the Generally Available version in 1.20. +VolumeSnapshots use specialized APIs from storage providers to duplicate volume of data. + +Since data is already in the same storage device (array of devices), duplicating data is usually +a metadata operation for storage providers with local snapshots (majority of on-premise storage providers). +All you need to do is point a new disk to an immutable snapshot and only +save deltas (or let it do a full-disk copy). As an operation that is inside the storage back-end, +it’s much quicker and usually doesn’t involve sending traffic over the network. +Public Clouds storage providers under the hood work a bit differently. They save snapshots +to Object Storage and then copy back from Object storage to Block storage when "duplicating" disk. +Technically there is a lot of Compute and network resources spent on Cloud providers side, +but from Kubernetes user perspective VolumeSnapshots work the same way whether is it local or +remote snapshot storage provider and no Compute and Network resources are involved in this operation. + +## Sounds like we have our solution, right? + +Actually, VolumeSnapshots are namespaced, and Kubernetes protects namespaced data from +being shared between tenants (Namespaces). This Kubernetes limitation is a conscious design +decision so that a Pod running in a different namespace can’t mount another application’s +[PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC). + +One way around it would be to create multiple volumes with duplicate data in one namespace. +However, you could easily reference the wrong copy. + +So the idea is to separate teams/initiatives by namespaces to avoid that and generally +limit access to the production namespace. + +## Solution? Creating a Golden Snapshot externally + +Another way around this design limitation is to create Snapshot externally (not through Kubernetes). +This is also called pre-provisioning a snapshot manually. Next, I will import it +as a multi-tenant golden snapshot that can be used for many namespaces. Below illustration will be +for AWS EBS (Elastic Block Storage) and GCE PD (Persistent Disk) services. + +### High-level plan for preparing the Golden Snapshot + +1. Identify Disk (EBS/Persistent Disk) that you want to clone with data in the cloud provider +2. Make a Disk Snapshot (in cloud provider console) +3. Get Disk Snapshot ID + +### High-level plan for cloning data for each team + +1. Create Namespace “sandbox01” +2. Import Disk Snapshot (ID) as VolumeSnapshotContent to Kubernetes +3. Create VolumeSnapshot in the Namespace "sandbox01" mapped to VolumeSnapshotContent +4. Create the PersistentVolumeClaim from VolumeSnapshot +5. Install Deployment or StatefulSet with PVC + +## Step 1: Identify Disk + +First, you need to identify your golden source. In my case, it’s a PostgreSQL database +on PersistentVolumeClaim “postgres-pv-claim” in the “production” namespace. + +```terminal +kubectl -n get pvc -o jsonpath='{.spec.volumeName}' +``` + +The output will look similar to: +``` +pvc-3096b3ba-38b6-4fd1-a42f-ec99176ed0d90 +``` + +## Step 2: Prepare your golden source + +You need to do this once or every time you want to refresh your golden data. + +### Make a Disk Snapshot + +Go to AWS EC2 or GCP Compute Engine console and search for an EBS volume +(on AWS) or Persistent Disk (on GCP), that has a label matching the last output. +In this case I saw: `pvc-3096b3ba-38b6-4fd1-a42f-ec99176ed0d9`. + +Click on Create snapshot and give it a name. You can do it in Console manually, +in AWS CloudShell / Google Cloud Shell, or in the terminal. To create a snapshot in the +terminal you must have the AWS CLI tool (`aws`) or Google's CLI (`gcloud`) +installed and configured. + +Here’s the command to create snapshot on GCP: + +```terminal +gcloud compute disks snapshot --project= --snapshot-names= --zone= --storage-location= +``` +{{< figure src="/images/blog/2021-09-07-data-duplication-in-data-heavy-k8s-env/create-volume-snapshot-gcp.png" alt="Screenshot of a terminal showing volume snapshot creation on GCP" title="GCP snapshot creation" >}} + + +GCP identifies the disk by its PVC name, so it’s direct mapping. In AWS, you need to +find volume by the CSIVolumeName AWS tag with PVC name value first that will be used for snapshot creation. + +{{< figure src="/images/blog/2021-09-07-data-duplication-in-data-heavy-k8s-env/identify-volume-aws.png" alt="Screenshot of AWS web console, showing EBS volume identification" title="Identify disk ID on AWS" >}} + +Mark done Volume (volume-id) ```vol-00c7ecd873c6fb3ec``` and ether create EBS snapshot in AWS Console, or use ```aws cli```. + +```terminal +aws ec2 create-snapshot --volume-id '' --description '' --tag-specifications 'ResourceType=snapshot' +``` + +## Step 3: Get your Disk Snapshot ID + +In AWS, the command above will output something similar to: +```terminal +"SnapshotId": "snap-09ed24a70bc19bbe4" +``` + +If you’re using the GCP cloud, you can get the snapshot ID from the gcloud command by querying for the snapshot’s given name: + +```terminal +gcloud compute snapshots --project= describe | grep id: +``` +You should get similar output to: +``` +id: 6645363163809389170 +``` + +## Step 4: Create a development environment for each team + +Now I have my Golden Snapshot, which is immutable data. Each team will get a copy +of this data, and team members can modify it as they see fit, given that a new EBS/persistent +disk will be created for each team. + +Below I will define a manifest for each namespace. To save time, you can replace +the namespace name (such as changing “sandbox01” → “sandbox42”) using tools +such as `sed` or `yq`, with Kubernetes-aware templating tools like +[Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/), +or using variable substitution in a CI/CD pipeline. + +Here's an example manifest: + +```yaml +--- +apiVersion: snapshot.storage.k8s.io/v1 +kind: VolumeSnapshotContent +metadata: + name: postgresql-orders-db-sandbox01 + namespace: sandbox01 +spec: + deletionPolicy: Retain + driver: pd.csi.storage.gke.io + source: + snapshotHandle: 'gcp/projects/staging-eu-castai-vt5hy2/global/snapshots/6645363163809389170' + volumeSnapshotRef: + kind: VolumeSnapshot + name: postgresql-orders-db-snap + namespace: sandbox01 +--- +apiVersion: snapshot.storage.k8s.io/v1 +kind: VolumeSnapshot +metadata: + name: postgresql-orders-db-snap + namespace: sandbox01 +spec: + source: + volumeSnapshotContentName: postgresql-orders-db-sandbox01 +``` + +In Kubernetes, VolumeSnapshotContent (VSC) objects are not namespaced. +However, I need a separate VSC for each different namespace to use, so the +`metadata.name` of each VSC must also be different. To make that straightfoward, +I used the target namespace as part of the name. + +Now it’s time to replace the driver field with the CSI (Container Storage Interface) driver +installed in your K8s cluster. Major cloud providers have CSI driver for block storage that +support VolumeSnapshots but quite often CSI drivers are not installed by default, consult +with your Kubernetes provider. + +That manifest above defines a VSC that works on GCP. +On AWS, driver and SnashotHandle values might look like: + +```YAML + driver: ebs.csi.aws.com + source: + snapshotHandle: "snap-07ff83d328c981c98" +``` + +At this point, I need to use the *Retain* policy, so that the CSI driver doesn’t try to +delete my manually created EBS disk snapshot. + +For GCP, you will have to build this string by hand - add a full project ID and snapshot ID. +For AWS, it’s just a plain snapshot ID. + +VSC also requires specifying which VolumeSnapshot (VS) will use it, so VSC and VS are +referencing each other. + +Now I can create PersistentVolumeClaim from VS above. It’s important to set this first: + + +```yaml +--- +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: postgres-pv-claim + namespace: sandbox01 +spec: + dataSource: + kind: VolumeSnapshot + name: postgresql-orders-db-snap + apiGroup: snapshot.storage.k8s.io + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 21Gi +``` + +If default StorageClass has [WaitForFirstConsumer](https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode) policy, +then the actual Cloud Disk will be created from the Golden Snapshot only when some Pod bounds that PVC. + +Now I assign that PVC to my Pod (in my case, it’s Postgresql) as I would with any other PVC. + +```terminal +kubectl -n get volumesnapshotContent,volumesnapshot,pvc,pod +``` + +Both VS and VSC should be *READYTOUSE* true, PVC bound, and the Pod (from Deployment or StatefulSet) running. + +**To keep on using data from my Golden Snapshot, I just need to repeat this for the +next namespace and voilà! No need to waste time and compute resources on the duplication process.** diff --git a/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md b/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md new file mode 100644 index 0000000000..af6349ecb8 --- /dev/null +++ b/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md @@ -0,0 +1,143 @@ +--- +layout: blog +title: "Introducing ClusterClass and Managed Topologies in Cluster API" +date: 2021-10-08 +slug: capi-clusterclass-and-managed-topologies +--- + +**Author:** Fabrizio Pandini (VMware) + +The [Cluster API community](https://cluster-api.sigs.k8s.io/) is happy to announce the implementation of *ClusterClass and Managed Topologies*, a new feature that will greatly simplify how you can provision, upgrade, and operate multiple Kubernetes clusters in a declarative way. + +## A little bit of context… + +Before getting into the details, let's take a step back and look at the history of Cluster API. + +The [Cluster API project](https://github.com/kubernetes-sigs/cluster-api/) started three years ago, and the first releases focused on extensibility and implementing a declarative API that allows a seamless experience across infrastructure providers. This was a success with many cloud providers: AWS, Azure, Digital Ocean, GCP, Metal3, vSphere and still counting. + +With extensibility addressed, the focus shifted to features, like automatic control plane and etcd management, health-based machine remediation, machine rollout strategies and more. + +Fast forwarding to 2021, with lots of companies using Cluster API to manage fleets of Kubernetes clusters running workloads in production, the community focused its effort on stabilization of both code, APIs, documentation, and on extensive test signals which inform Kubernetes releases. + +With solid foundations in place, and a vibrant and welcoming community that still continues to grow, it was time to plan another iteration on our UX for both new and advanced users. + +Enter ClusterClass and Managed Topologies, tada! + +## ClusterClass + +As the name suggests, ClusterClass and managed topologies are built in two parts. + +The idea behind ClusterClass is simple: define the shape of your cluster once, and reuse it many times, abstracting the complexities and the internals of a Kubernetes cluster away. + +![Defining a ClusterClass](/images/blog/2021-10-08-clusterclass-and-managed-topologies/clusterclass.svg) + +ClusterClass, at its heart, is a collection of Cluster and Machine templates. You can use it as a “stamp” that can be leveraged to create many clusters of a similar shape. + +```yaml +--- +apiVersion: cluster.x-k8s.io/v1beta1 + kind: ClusterClass + metadata: + name: my-amazing-cluster-class + namespace: bar + spec: + controlPlane: + ref: + apiVersion: controlplane.cluster.x-k8s.io/v1beta1 + kind: KubeadmControlPlaneTemplate + name: high-availability-kcp + machineInfrastructure: + ref: + apiVersion: infrastructure.cluster.x-k8s.io/v1alpha4 + kind: VSphereMachineTemplate + name: controlplane-vsphere-machinetemplate + workers: + deployments: + - class: linux-worker + template: + bootstrap: + ref: + apiVersion: bootstrap.cluster.x-k8s.io/v1beta1 + kind: KubeadmConfigTemplate + name: linux-bootstrap + infrastructure: + ref: + apiVersion: infrastructure.cluster.x-k8s.io/v1alpha4 + kind: VSphereMachineTemplate + name: linux-vsphere-template + - class: windows-worker + template: + bootstrap: + ref: + apiVersion: bootstrap.cluster.x-k8s.io/v1beta1 + kind: KubeadmConfigTemplate + name: windows-bootstrap + infrastructure: + ref: + apiVersion: infrastructure.cluster.x-k8s.io/v1alpha4 + kind: VSphereMachineTemplate + name: windows-vsphere-template + infrastructure: + ref: + apiVersion: infrastructure.cluster.x-k8s.io/v1alpha4 + kind: VSphereClusterTemplate + name: vsphere-cluster +``` + +The possibilities are endless; you can get a default ClusterClass from the community, “off-the-shelf” classes from your vendor of choice, “certified” classes from the platform admin in your company, or even create custom ones for advanced scenarios. + +## Managed Topologies + +Managed Topologies let you put the power of ClusterClass into action. + +Given a ClusterClass, you can create many Clusters of a similar shape by providing a single resource, the Cluster. + +![Create a Cluster with ClusterClass](/images/blog/2021-10-08-clusterclass-and-managed-topologies/create-cluster.svg) + +Here is an example: + +```yaml +--- +apiVersion: cluster.x-k8s.io/v1beta1 + kind: Cluster + metadata: + name: my-amazing-cluster + namespace: bar + spec: + topology: # define a managed topology + class: my-amazing-cluster-class # use the ClusterClass mentioned earlier + version: v1.21.2 + controlPlane: + replicas: 3 + workers: + machineDeployments: + - class: linux-worker + name: big-pool-of-linux-machines-1 + replicas: 5 + - class: linux-worker + name: small-pool-of-linux-machines-1 + replicas: 1 + - class: windows-worker + name: pool-of-windows-machines + replicas: 3 +``` + +But there is more than simplified cluster creation. Now the Cluster acts as a single control point for your entire topology. + +All the power of Cluster API, extensibility, lifecycle automation, stability, all the features required for managing an enterprise grade Kubernetes cluster on the infrastructure provider of your choice are now at your fingertips: you can create your Cluster, add new machines, upgrade to the next Kubernetes version, and all from a single place. + +It is just as simple as it looks! + +## What’s next + +While the amazing Cluster API community is working hard to deliver the first version of ClusterClass and managed topologies later this year, we are already looking forward to what comes next for the project and its ecosystem. + +There are a lot of great ideas and opportunities ahead! + +We want to make managed topologies even more powerful and flexible, allowing users to dynamically change bits of a ClusterClass according to the specific needs of a Cluster; this will ensure the same simple and intuitive UX for solving complex problems like e.g. selecting machine image for a specific Kubernetes version and for a specific region of your infrastructure provider, or injecting proxy configurations in the entire Cluster, and so on. + +Stay tuned for what comes next, and if you have any questions, comments or suggestions: + +* Chat with us on the Kubernetes [Slack](http://slack.k8s.io/):[#cluster-api](https://kubernetes.slack.com/archives/C8TSNPY4T) +* Join the SIG Cluster Lifecycle [Google Group](https://groups.google.com/g/kubernetes-sig-cluster-lifecycle) to receive calendar invites and gain access to documents +* Join our [Zoom meeting](https://zoom.us/j/861487554), every Wednesday at 10:00 Pacific Time diff --git a/content/en/blog/_posts/image01.png b/content/en/blog/_posts/image01.png deleted file mode 100644 index 91e8856139..0000000000 Binary files a/content/en/blog/_posts/image01.png and /dev/null differ diff --git a/content/en/blog/_posts/image02.png b/content/en/blog/_posts/image02.png deleted file mode 100644 index dfd14d7cdc..0000000000 Binary files a/content/en/blog/_posts/image02.png and /dev/null differ diff --git a/content/en/blog/_posts/image03.png b/content/en/blog/_posts/image03.png deleted file mode 100644 index 443a6f2d67..0000000000 Binary files a/content/en/blog/_posts/image03.png and /dev/null differ diff --git a/content/en/blog/_posts/image04.png b/content/en/blog/_posts/image04.png deleted file mode 100644 index e107adc88b..0000000000 Binary files a/content/en/blog/_posts/image04.png and /dev/null differ diff --git a/content/en/blog/_posts/image05.png b/content/en/blog/_posts/image05.png deleted file mode 100644 index 6d80447d09..0000000000 Binary files a/content/en/blog/_posts/image05.png and /dev/null differ diff --git a/content/en/blog/_posts/image06.png b/content/en/blog/_posts/image06.png deleted file mode 100644 index d40b2eb0b6..0000000000 Binary files a/content/en/blog/_posts/image06.png and /dev/null differ diff --git a/content/en/blog/_posts/image07.png b/content/en/blog/_posts/image07.png deleted file mode 100644 index fc3976040f..0000000000 Binary files a/content/en/blog/_posts/image07.png and /dev/null differ diff --git a/content/en/case-studies/adform/adform_featured_logo.svg b/content/en/case-studies/adform/adform_featured_logo.svg index ce058af82e..b31ef3235a 100644 --- a/content/en/case-studies/adform/adform_featured_logo.svg +++ b/content/en/case-studies/adform/adform_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/adidas/adidas-featured.svg b/content/en/case-studies/adidas/adidas-featured.svg index 07e595356a..a53d467552 100644 --- a/content/en/case-studies/adidas/adidas-featured.svg +++ b/content/en/case-studies/adidas/adidas-featured.svg @@ -1 +1 @@ -kubernetes.io-54664 \ No newline at end of file +kubernetes.io-54664 \ No newline at end of file diff --git a/content/en/case-studies/amadeus/amadeus_featured.svg b/content/en/case-studies/amadeus/amadeus_featured.svg index 6b711f9bae..9d0c40b8e1 100644 --- a/content/en/case-studies/amadeus/amadeus_featured.svg +++ b/content/en/case-studies/amadeus/amadeus_featured.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/ancestry/ancestry_featured.svg b/content/en/case-studies/ancestry/ancestry_featured.svg index 301e6fec92..9a3e80186b 100644 --- a/content/en/case-studies/ancestry/ancestry_featured.svg +++ b/content/en/case-studies/ancestry/ancestry_featured.svg @@ -1 +1 @@ -kubernetes.io-logos-ancestry \ No newline at end of file +kubernetes.io-logos-ancestry \ No newline at end of file diff --git a/content/en/case-studies/ant-financial/ant-financial_featured_logo.svg b/content/en/case-studies/ant-financial/ant-financial_featured_logo.svg index 1d20786a5d..4eb8a51127 100644 --- a/content/en/case-studies/ant-financial/ant-financial_featured_logo.svg +++ b/content/en/case-studies/ant-financial/ant-financial_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/appdirect/appdirect_featured_logo.svg b/content/en/case-studies/appdirect/appdirect_featured_logo.svg index d655c7f2fa..36fcba1abb 100644 --- a/content/en/case-studies/appdirect/appdirect_featured_logo.svg +++ b/content/en/case-studies/appdirect/appdirect_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/babylon/babylon_featured_logo.svg b/content/en/case-studies/babylon/babylon_featured_logo.svg index 8bea0b8fc3..e84da19268 100644 --- a/content/en/case-studies/babylon/babylon_featured_logo.svg +++ b/content/en/case-studies/babylon/babylon_featured_logo.svg @@ -1 +1 @@ -babylon_featured_logo \ No newline at end of file +babylon_featured_logo \ No newline at end of file diff --git a/content/en/case-studies/blablacar/blablacar_featured.svg b/content/en/case-studies/blablacar/blablacar_featured.svg index f66f6ca954..5b887f24a8 100644 --- a/content/en/case-studies/blablacar/blablacar_featured.svg +++ b/content/en/case-studies/blablacar/blablacar_featured.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/blackrock/blackrock_featured.svg b/content/en/case-studies/blackrock/blackrock_featured.svg index d70c169bc8..f98ea323d7 100644 --- a/content/en/case-studies/blackrock/blackrock_featured.svg +++ b/content/en/case-studies/blackrock/blackrock_featured.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/booking-com/booking.com_featured_logo.svg b/content/en/case-studies/booking-com/booking.com_featured_logo.svg index 298c77c773..0b245c2700 100644 --- a/content/en/case-studies/booking-com/booking.com_featured_logo.svg +++ b/content/en/case-studies/booking-com/booking.com_featured_logo.svg @@ -1 +1 @@ -booking.com_featured_logo \ No newline at end of file +booking.com_featured_logo \ No newline at end of file diff --git a/content/en/case-studies/booz-allen/booz-allen-featured-logo.svg b/content/en/case-studies/booz-allen/booz-allen-featured-logo.svg index b844d99846..3ce58c68f7 100644 --- a/content/en/case-studies/booz-allen/booz-allen-featured-logo.svg +++ b/content/en/case-studies/booz-allen/booz-allen-featured-logo.svg @@ -1 +1 @@ -booz-allen-featured \ No newline at end of file +booz-allen-featured \ No newline at end of file diff --git a/content/en/case-studies/bose/bose_featured_logo.svg b/content/en/case-studies/bose/bose_featured_logo.svg index 13f1ff2616..58b2add614 100644 --- a/content/en/case-studies/bose/bose_featured_logo.svg +++ b/content/en/case-studies/bose/bose_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/box/box_featured.svg b/content/en/case-studies/box/box_featured.svg index c4ebadaffe..2b4fb6552b 100644 --- a/content/en/case-studies/box/box_featured.svg +++ b/content/en/case-studies/box/box_featured.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/buffer/buffer_featured.svg b/content/en/case-studies/buffer/buffer_featured.svg index 6527f94f4d..b8e321f31d 100644 --- a/content/en/case-studies/buffer/buffer_featured.svg +++ b/content/en/case-studies/buffer/buffer_featured.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/capital-one/capitalone_featured_logo.svg b/content/en/case-studies/capital-one/capitalone_featured_logo.svg index 28552e569c..124adae9af 100644 --- a/content/en/case-studies/capital-one/capitalone_featured_logo.svg +++ b/content/en/case-studies/capital-one/capitalone_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/chinaunicom/chinaunicom_featured_logo.svg b/content/en/case-studies/chinaunicom/chinaunicom_featured_logo.svg index a1b39cc109..aae1978cf2 100644 --- a/content/en/case-studies/chinaunicom/chinaunicom_featured_logo.svg +++ b/content/en/case-studies/chinaunicom/chinaunicom_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/city-of-montreal/city-of-montreal_featured_logo.svg b/content/en/case-studies/city-of-montreal/city-of-montreal_featured_logo.svg index 1d90a6536f..44ac9b0b1d 100644 --- a/content/en/case-studies/city-of-montreal/city-of-montreal_featured_logo.svg +++ b/content/en/case-studies/city-of-montreal/city-of-montreal_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/crowdfire/crowdfire_featured_logo.svg b/content/en/case-studies/crowdfire/crowdfire_featured_logo.svg index 3c7a565f11..a4f020161a 100644 --- a/content/en/case-studies/crowdfire/crowdfire_featured_logo.svg +++ b/content/en/case-studies/crowdfire/crowdfire_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/denso/denso_featured_logo.svg b/content/en/case-studies/denso/denso_featured_logo.svg index 375d9cefbc..e2b26b2c8c 100644 --- a/content/en/case-studies/denso/denso_featured_logo.svg +++ b/content/en/case-studies/denso/denso_featured_logo.svg @@ -1 +1 @@ - \ No newline at end of file + \ No newline at end of file diff --git a/content/en/case-studies/golfnow/golfnow_featured.svg b/content/en/case-studies/golfnow/golfnow_featured.svg index 761782a756..b5b42d6fcd 100644 --- a/content/en/case-studies/golfnow/golfnow_featured.svg +++ b/content/en/case-studies/golfnow/golfnow_featured.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/haufegroup/haufegroup_featured.svg b/content/en/case-studies/haufegroup/haufegroup_featured.svg index b552d11773..a61b577ab8 100644 --- a/content/en/case-studies/haufegroup/haufegroup_featured.svg +++ b/content/en/case-studies/haufegroup/haufegroup_featured.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/huawei/huawei_featured.svg b/content/en/case-studies/huawei/huawei_featured.svg index 860f62dd4e..a8a8f22c8f 100644 --- a/content/en/case-studies/huawei/huawei_featured.svg +++ b/content/en/case-studies/huawei/huawei_featured.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/ibm/ibm_featured_logo.svg b/content/en/case-studies/ibm/ibm_featured_logo.svg index 577d8e97d9..f79fd7847b 100644 --- a/content/en/case-studies/ibm/ibm_featured_logo.svg +++ b/content/en/case-studies/ibm/ibm_featured_logo.svg @@ -1 +1 @@ -ibm_featured_logo \ No newline at end of file +ibm_featured_logo \ No newline at end of file diff --git a/content/en/case-studies/ing/ing_featured_logo.svg b/content/en/case-studies/ing/ing_featured_logo.svg index 20418a0dbf..5a2df497c7 100644 --- a/content/en/case-studies/ing/ing_featured_logo.svg +++ b/content/en/case-studies/ing/ing_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/naic/naic_featured_logo.svg b/content/en/case-studies/naic/naic_featured_logo.svg index 100d158b9b..b4af63931d 100644 --- a/content/en/case-studies/naic/naic_featured_logo.svg +++ b/content/en/case-studies/naic/naic_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/nav/nav_featured_logo.svg b/content/en/case-studies/nav/nav_featured_logo.svg index 79ae438459..42b4ffa967 100644 --- a/content/en/case-studies/nav/nav_featured_logo.svg +++ b/content/en/case-studies/nav/nav_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/nerdalize/nerdalize_featured_logo.svg b/content/en/case-studies/nerdalize/nerdalize_featured_logo.svg index 43a001461d..aa2661e503 100644 --- a/content/en/case-studies/nerdalize/nerdalize_featured_logo.svg +++ b/content/en/case-studies/nerdalize/nerdalize_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/netease/netease_featured_logo.svg b/content/en/case-studies/netease/netease_featured_logo.svg index 7ddb664f1a..0ea176812d 100644 --- a/content/en/case-studies/netease/netease_featured_logo.svg +++ b/content/en/case-studies/netease/netease_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/newyorktimes/newyorktimes_featured.svg b/content/en/case-studies/newyorktimes/newyorktimes_featured.svg index f006841112..e386c15806 100644 --- a/content/en/case-studies/newyorktimes/newyorktimes_featured.svg +++ b/content/en/case-studies/newyorktimes/newyorktimes_featured.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/nokia/nokia_featured_logo.svg b/content/en/case-studies/nokia/nokia_featured_logo.svg index bbf2920f7a..1e3cce4956 100644 --- a/content/en/case-studies/nokia/nokia_featured_logo.svg +++ b/content/en/case-studies/nokia/nokia_featured_logo.svg @@ -1 +1 @@ -nokia \ No newline at end of file +nokia \ No newline at end of file diff --git a/content/en/case-studies/nordstrom/nordstrom_featured_logo.svg b/content/en/case-studies/nordstrom/nordstrom_featured_logo.svg index 19051f4b21..a162e93f03 100644 --- a/content/en/case-studies/nordstrom/nordstrom_featured_logo.svg +++ b/content/en/case-studies/nordstrom/nordstrom_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/northwestern-mutual/northwestern_featured_logo.svg b/content/en/case-studies/northwestern-mutual/northwestern_featured_logo.svg index c907eb6e22..7a2f09de54 100644 --- a/content/en/case-studies/northwestern-mutual/northwestern_featured_logo.svg +++ b/content/en/case-studies/northwestern-mutual/northwestern_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/ocado/ocado_featured_logo.svg b/content/en/case-studies/ocado/ocado_featured_logo.svg index 8f30890dfc..d9e2886e36 100644 --- a/content/en/case-studies/ocado/ocado_featured_logo.svg +++ b/content/en/case-studies/ocado/ocado_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/openAI/openai_featured.svg b/content/en/case-studies/openAI/openai_featured.svg index 97cf4dab57..cf9b79721e 100644 --- a/content/en/case-studies/openAI/openai_featured.svg +++ b/content/en/case-studies/openAI/openai_featured.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/peardeck/peardeck_featured.svg b/content/en/case-studies/peardeck/peardeck_featured.svg index dcaa62f71e..1c42e71920 100644 --- a/content/en/case-studies/peardeck/peardeck_featured.svg +++ b/content/en/case-studies/peardeck/peardeck_featured.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/pingcap/pingcap_featured_logo.svg b/content/en/case-studies/pingcap/pingcap_featured_logo.svg index 6beb710c04..46d2d2543d 100644 --- a/content/en/case-studies/pingcap/pingcap_featured_logo.svg +++ b/content/en/case-studies/pingcap/pingcap_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/pinterest/pinterest_feature.svg b/content/en/case-studies/pinterest/pinterest_feature.svg index 32d0c5d60f..96cd6ded97 100644 --- a/content/en/case-studies/pinterest/pinterest_feature.svg +++ b/content/en/case-studies/pinterest/pinterest_feature.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/prowise/prowise_featured_logo.svg b/content/en/case-studies/prowise/prowise_featured_logo.svg index ae03646afc..1f2d5ce41a 100644 --- a/content/en/case-studies/prowise/prowise_featured_logo.svg +++ b/content/en/case-studies/prowise/prowise_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/ricardo-ch/ricardo.ch_featured_logo.svg b/content/en/case-studies/ricardo-ch/ricardo.ch_featured_logo.svg index 60b79ca30c..caefc4b96f 100644 --- a/content/en/case-studies/ricardo-ch/ricardo.ch_featured_logo.svg +++ b/content/en/case-studies/ricardo-ch/ricardo.ch_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/slamtec/slamtec_featured_logo.svg b/content/en/case-studies/slamtec/slamtec_featured_logo.svg index 2a8fde7017..7b4f6d6af1 100644 --- a/content/en/case-studies/slamtec/slamtec_featured_logo.svg +++ b/content/en/case-studies/slamtec/slamtec_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/slingtv/slingtv_featured_logo.svg b/content/en/case-studies/slingtv/slingtv_featured_logo.svg index 36077bc1ac..764f8ddd88 100644 --- a/content/en/case-studies/slingtv/slingtv_featured_logo.svg +++ b/content/en/case-studies/slingtv/slingtv_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/spotify/spotify-featured.svg b/content/en/case-studies/spotify/spotify-featured.svg index fb7d8e750d..d1cc3418de 100644 --- a/content/en/case-studies/spotify/spotify-featured.svg +++ b/content/en/case-studies/spotify/spotify-featured.svg @@ -1 +1 @@ -kubernetes.io-logos \ No newline at end of file +kubernetes.io-logos \ No newline at end of file diff --git a/content/en/case-studies/squarespace/squarespace_featured_logo.svg b/content/en/case-studies/squarespace/squarespace_featured_logo.svg index 4ffcbf078e..a69d7ea5c8 100644 --- a/content/en/case-studies/squarespace/squarespace_featured_logo.svg +++ b/content/en/case-studies/squarespace/squarespace_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/thredup/thredup_featured_logo.svg b/content/en/case-studies/thredup/thredup_featured_logo.svg index 48841f9878..987e1a55c1 100644 --- a/content/en/case-studies/thredup/thredup_featured_logo.svg +++ b/content/en/case-studies/thredup/thredup_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/vsco/vsco_featured_logo.svg b/content/en/case-studies/vsco/vsco_featured_logo.svg index e1181f8a95..e65dad8c52 100644 --- a/content/en/case-studies/vsco/vsco_featured_logo.svg +++ b/content/en/case-studies/vsco/vsco_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/wikimedia/wikimedia_featured.svg b/content/en/case-studies/wikimedia/wikimedia_featured.svg index b3e654dd64..5fa786aaa5 100644 --- a/content/en/case-studies/wikimedia/wikimedia_featured.svg +++ b/content/en/case-studies/wikimedia/wikimedia_featured.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/wink/wink_featured.svg b/content/en/case-studies/wink/wink_featured.svg index 3e27cac771..8168ac2b43 100644 --- a/content/en/case-studies/wink/wink_featured.svg +++ b/content/en/case-studies/wink/wink_featured.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/woorank/woorank_featured_logo.svg b/content/en/case-studies/woorank/woorank_featured_logo.svg index a5e3736ee1..50b64e9a9c 100644 --- a/content/en/case-studies/woorank/woorank_featured_logo.svg +++ b/content/en/case-studies/woorank/woorank_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/workiva/workiva_featured_logo.svg b/content/en/case-studies/workiva/workiva_featured_logo.svg index 76de3f217c..0cde714f23 100644 --- a/content/en/case-studies/workiva/workiva_featured_logo.svg +++ b/content/en/case-studies/workiva/workiva_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/yahoo-japan/yahoojapan_featured.svg b/content/en/case-studies/yahoo-japan/yahoojapan_featured.svg index 3efabbfde4..b0baa4a49e 100644 --- a/content/en/case-studies/yahoo-japan/yahoojapan_featured.svg +++ b/content/en/case-studies/yahoo-japan/yahoojapan_featured.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/ygrene/ygrene_featured_logo.svg b/content/en/case-studies/ygrene/ygrene_featured_logo.svg index f8806fa33d..0b0ab458fa 100644 --- a/content/en/case-studies/ygrene/ygrene_featured_logo.svg +++ b/content/en/case-studies/ygrene/ygrene_featured_logo.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/case-studies/zalando/zalando_feature_logo.svg b/content/en/case-studies/zalando/zalando_feature_logo.svg index 7560bc54fe..875d10c030 100644 --- a/content/en/case-studies/zalando/zalando_feature_logo.svg +++ b/content/en/case-studies/zalando/zalando_feature_logo.svg @@ -1 +1 @@ -kubernetes.io-logos2 \ No newline at end of file +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/en/community/_index.html b/content/en/community/_index.html index ad9cab5d94..b41323c69e 100644 --- a/content/en/community/_index.html +++ b/content/en/community/_index.html @@ -13,7 +13,7 @@ cid: community

The Kubernetes community -- users, contributors, and the culture we've built together -- is one of the biggest reasons for the meteoric rise of this open source project. Our culture and values continue to grow and change as the project itself grows and changes. We all work together toward constant improvement of the project and the ways we work on it. -

We are the people who file issues and pull requests, attend SIG meetings, Kubernetes meetups, and KubeCon, advocate for it's adoption and innovation, run kubectl get pods, and contribute in a thousand other vital ways. Read on to learn how you can get involved and become part of this amazing community.

+

We are the people who file issues and pull requests, attend SIG meetings, Kubernetes meetups, and KubeCon, advocate for its adoption and innovation, run kubectl get pods, and contribute in a thousand other vital ways. Read on to learn how you can get involved and become part of this amazing community.


@@ -24,7 +24,8 @@ cid: community Videos      Discussions      Events and meetups      -News +News      +Releases


diff --git a/content/en/docs/concepts/architecture/_index.md b/content/en/docs/concepts/architecture/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/concepts/architecture/cloud-controller.md b/content/en/docs/concepts/architecture/cloud-controller.md index d97fc94a4c..229cc489f9 100644 --- a/content/en/docs/concepts/architecture/cloud-controller.md +++ b/content/en/docs/concepts/architecture/cloud-controller.md @@ -206,9 +206,11 @@ rules: [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) has instructions on running and managing the cloud controller manager. +To upgrade a HA control plane to use the cloud controller manager, see [Migrate Replicated Control Plane To Use Cloud Controller Manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/). + Want to know how to implement your own cloud controller manager, or extend an existing project? -The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the `CloudProvider` interface defined in [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62) from [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider). +The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the `CloudProvider` interface defined in [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69) from [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider). The implementation of the shared controllers highlighted in this document (Node, Route, and Service), and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core. Implementations specific to cloud providers are outside the core of Kubernetes and implement the `CloudProvider` interface. diff --git a/content/en/docs/concepts/architecture/controller.md b/content/en/docs/concepts/architecture/controller.md index 711cf38363..9912c53bf8 100644 --- a/content/en/docs/concepts/architecture/controller.md +++ b/content/en/docs/concepts/architecture/controller.md @@ -159,11 +159,12 @@ You can run your own controller as a set of Pods, or externally to Kubernetes. What fits best will depend on what that particular controller does. - - ## {{% heading "whatsnext" %}} * Read about the [Kubernetes control plane](/docs/concepts/overview/components/#control-plane-components) * Discover some of the basic [Kubernetes objects](/docs/concepts/overview/working-with-objects/kubernetes-objects/) * Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/) -* If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes. +* If you want to write your own controller, see + [Extension Patterns](/docs/concepts/extend-kubernetes/#extension-patterns) + in Extending Kubernetes. + diff --git a/content/en/docs/concepts/architecture/garbage-collection.md b/content/en/docs/concepts/architecture/garbage-collection.md new file mode 100644 index 0000000000..7c70675fff --- /dev/null +++ b/content/en/docs/concepts/architecture/garbage-collection.md @@ -0,0 +1,182 @@ +--- +title: Garbage Collection +content_type: concept +weight: 50 +--- + + +{{}} This +allows the clean up of resources like the following: + + * [Failed pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) + * [Completed Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/) + * [Objects without owner references](#owners-dependents) + * [Unused containers and container images](#containers-images) + * [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](/docs/concepts/storage/persistent-volumes/#delete) + * [Stale or expired CertificateSigningRequests (CSRs)](/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) + * {{}} deleted in the following scenarios: + * On a cloud when the cluster uses a [cloud controller manager](/docs/concepts/architecture/cloud-controller/) + * On-premises when the cluster uses an addon similar to a cloud controller + manager + * [Node Lease objects](/docs/concepts/architecture/nodes/#heartbeats) + +## Owners and dependents {#owners-dependents} + +Many objects in Kubernetes link to each other through [*owner references*](/docs/concepts/overview/working-with-objects/owners-dependents/). +Owner references tell the control plane which objects are dependent on others. +Kubernetes uses owner references to give the control plane, and other API +clients, the opportunity to clean up related resources before deleting an +object. In most cases, Kubernetes manages owner references automatically. + +Ownership is different from the [labels and selectors](/docs/concepts/overview/working-with-objects/labels/) +mechanism that some resources also use. For example, consider a +{{}} that creates +`EndpointSlice` objects. The Service uses *labels* to allow the control plane to +determine which `EndpointSlice` objects are used for that Service. In addition +to the labels, each `EndpointSlice` that is managed on behalf of a Service has +an owner reference. Owner references help different parts of Kubernetes avoid +interfering with objects they don’t control. + +{{< note >}} +Cross-namespace owner references are disallowed by design. +Namespaced dependents can specify cluster-scoped or namespaced owners. +A namespaced owner **must** exist in the same namespace as the dependent. +If it does not, the owner reference is treated as absent, and the dependent +is subject to deletion once all owners are verified absent. + +Cluster-scoped dependents can only specify cluster-scoped owners. +In v1.20+, if a cluster-scoped dependent specifies a namespaced kind as an owner, +it is treated as having an unresolvable owner reference, and is not able to be garbage collected. + +In v1.20+, if the garbage collector detects an invalid cross-namespace `ownerReference`, +or a cluster-scoped dependent with an `ownerReference` referencing a namespaced kind, a warning Event +with a reason of `OwnerRefInvalidNamespace` and an `involvedObject` of the invalid dependent is reported. +You can check for that kind of Event by running +`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`. +{{< /note >}} + +## Cascading deletion {#cascading-deletion} + +Kubernetes checks for and deletes objects that no longer have owner +references, like the pods left behind when you delete a ReplicaSet. When you +delete an object, you can control whether Kubernetes deletes the object's +dependents automatically, in a process called *cascading deletion*. There are +two types of cascading deletion, as follows: + + * Foreground cascading deletion + * Background cascading deletion + +You can also control how and when garbage collection deletes resources that have +owner references using Kubernetes {{}}. + +### Foreground cascading deletion {#foreground-deletion} + +In foreground cascading deletion, the owner object you're deleting first enters +a *deletion in progress* state. In this state, the following happens to the +owner object: + + * The Kubernetes API server sets the object's `metadata.deletionTimestamp` + field to the time the object was marked for deletion. + * The Kubernetes API server also sets the `metadata.finalizers` field to + `foregroundDeletion`. + * The object remains visible through the Kubernetes API until the deletion + process is complete. + +After the owner object enters the deletion in progress state, the controller +deletes the dependents. After deleting all the dependent objects, the controller +deletes the owner object. At this point, the object is no longer visible in the +Kubernetes API. + +During foreground cascading deletion, the only dependents that block owner +deletion are those that have the `ownerReference.blockOwnerDeletion=true` field. +See [Use foreground cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion) +to learn more. + +### Background cascading deletion {#background-deletion} + +In background cascading deletion, the Kubernetes API server deletes the owner +object immediately and the controller cleans up the dependent objects in +the background. By default, Kubernetes uses background cascading deletion unless +you manually use foreground deletion or choose to orphan the dependent objects. + +See [Use background cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion) +to learn more. + +### Orphaned dependents + +When Kubernetes deletes an owner object, the dependents left behind are called +*orphan* objects. By default, Kubernetes deletes dependent objects. To learn how +to override this behaviour, see [Delete owner objects and orphan dependents](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy). + +## Garbage collection of unused containers and images {#containers-images} + +The {{}} performs garbage +collection on unused images every five minutes and on unused containers every +minute. You should avoid using external garbage collection tools, as these can +break the kubelet behavior and remove containers that should exist. + +To configure options for unused container and image garbage collection, tune the +kubelet using a [configuration file](/docs/tasks/administer-cluster/kubelet-config-file/) +and change the parameters related to garbage collection using the +[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) +resource type. + +### Container image lifecycle + +Kubernetes manages the lifecycle of all images through its *image manager*, +which is part of the kubelet, with the cooperation of cadvisor. The kubelet +considers the following disk usage limits when making garbage collection +decisions: + + * `HighThresholdPercent` + * `LowThresholdPercent` + +Disk usage above the configured `HighThresholdPercent` value triggers garbage +collection, which deletes images in order based on the last time they were used, +starting with the oldest first. The kubelet deletes images +until disk usage reaches the `LowThresholdPercent` value. + +### Container image garbage collection {#container-image-garbage-collection} + +The kubelet garbage collects unused containers based on the following variables, +which you can define: + + * `MinAge`: the minimum age at which the kubelet can garbage collect a + container. Disable by setting to `0`. + * `MaxPerPodContainer`: the maximum number of dead containers each Pod pair + can have. Disable by setting to less than `0`. + * `MaxContainers`: the maximum number of dead containers the cluster can have. + Disable by setting to less than `0`. + +In addition to these variables, the kubelet garbage collects unidentified and +deleted containers, typically starting with the oldest first. + +`MaxPerPodContainer` and `MaxContainer` may potentially conflict with each other +in situations where retaining the maximum number of containers per Pod +(`MaxPerPodContainer`) would go outside the allowable total of global dead +containers (`MaxContainers`). In this situation, the kubelet adjusts +`MaxPodPerContainer` to address the conflict. A worst-case scenario would be to +downgrade `MaxPerPodContainer` to `1` and evict the oldest containers. +Additionally, containers owned by pods that have been deleted are removed once +they are older than `MinAge`. + +{{}} +The kubelet only garbage collects the containers it manages. +{{}} + +## Configuring garbage collection {#configuring-gc} + +You can tune garbage collection of resources by configuring options specific to +the controllers managing those resources. The following pages show you how to +configure garbage collection: + + * [Configuring cascading deletion of Kubernetes objects](/docs/tasks/administer-cluster/use-cascading-deletion/) + * [Configuring cleanup of finished Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/) + + + +## {{% heading "whatsnext" %}} + +* Learn more about [ownership of Kubernetes objects](/docs/concepts/overview/working-with-objects/owners-dependents/). +* Learn more about Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/). +* Learn about the [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) that cleans up finished Jobs. \ No newline at end of file diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 57414a415f..1d4f6455b7 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -14,7 +14,7 @@ A node may be a virtual or physical machine, depending on the cluster. Each node is managed by the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} and contains the services necessary to run -{{< glossary_tooltip text="Pods" term_id="pod" >}} +{{< glossary_tooltip text="Pods" term_id="pod" >}}. Typically you have several nodes in a cluster; in a learning or resource-limited environment, you might have only one node. @@ -122,6 +122,9 @@ To mark a Node unschedulable, run: kubectl cordon $NODENAME ``` +See [Safely Drain a Node](/docs/tasks/administer-cluster/safely-drain-node/) +for more details. + {{< note >}} Pods that are part of a {{< glossary_tooltip term_id="daemonset" >}} tolerate being run on an unschedulable Node. DaemonSets typically provide node-local services @@ -162,8 +165,8 @@ The `conditions` field describes the status of all `Running` nodes. Examples of | Node Condition | Description | |----------------------|-------------| | `Ready` | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last `node-monitor-grace-period` (default is 40 seconds) | -| `DiskPressure` | `True` if pressure exists on the disk size--that is, if the disk capacity is low; otherwise `False` | -| `MemoryPressure` | `True` if pressure exists on the node memory--that is, if the node memory is low; otherwise `False` | +| `DiskPressure` | `True` if pressure exists on the disk size—that is, if the disk capacity is low; otherwise `False` | +| `MemoryPressure` | `True` if pressure exists on the node memory—that is, if the node memory is low; otherwise `False` | | `PIDPressure` | `True` if pressure exists on the processes—that is, if there are too many processes on the node; otherwise `False` | | `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` | {{< /table >}} @@ -174,7 +177,8 @@ If you use command-line tools to print details of a cordoned Node, the Condition cordoned nodes are marked Unschedulable in their spec. {{< /note >}} -The node condition is represented as a JSON object. For example, the following structure describes a healthy node: +In the Kubernetes API, a node's condition is represented as part of the `.status` +of the Node resource. For example, the following JSON structure describes a healthy node: ```json "conditions": [ @@ -189,7 +193,17 @@ The node condition is represented as a JSON object. For example, the following s ] ``` -If the Status of the Ready condition remains `Unknown` or `False` for longer than the `pod-eviction-timeout` (an argument passed to the {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}), then all the Pods on the node are scheduled for deletion by the node controller. The default eviction timeout duration is **five minutes**. In some cases when the node is unreachable, the API server is unable to communicate with the kubelet on the node. The decision to delete the pods cannot be communicated to the kubelet until communication with the API server is re-established. In the meantime, the pods that are scheduled for deletion may continue to run on the partitioned node. +If the `status` of the Ready condition remains `Unknown` or `False` for longer +than the `pod-eviction-timeout` (an argument passed to the +{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" +>}}), then the [node controller](#node-controller) triggers +{{< glossary_tooltip text="API-initiated eviction" term_id="api-eviction" >}} +for all Pods assigned to that node. The default eviction timeout duration is +**five minutes**. +In some cases when the node is unreachable, the API server is unable to communicate +with the kubelet on the node. The decision to delete the pods cannot be communicated to +the kubelet until communication with the API server is re-established. In the meantime, +the pods that are scheduled for deletion may continue to run on the partitioned node. The node controller does not force delete pods until it is confirmed that they have stopped running in the cluster. You can see the pods that might be running on an unreachable node as @@ -199,10 +213,12 @@ may need to delete the node object by hand. Deleting the node object from Kubern all the Pod objects running on the node to be deleted from the API server and frees up their names. -The node lifecycle controller automatically creates -[taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) that represent conditions. +When problems occur on nodes, the Kubernetes control plane automatically creates +[taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) that match the conditions +affecting the node. The scheduler takes the Node's taints into consideration when assigning a Pod to a Node. -Pods can also have tolerations which let them tolerate a Node's taints. +Pods can also have {{< glossary_tooltip text="tolerations" term_id="toleration" >}} that let +them run on a Node even though it has a specific taint. See [Taint Nodes by Condition](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition) for more details. @@ -222,10 +238,43 @@ on a Node. ### Info -Describes general information about the node, such as kernel version, Kubernetes version (kubelet and kube-proxy version), Docker version (if used), and OS name. -This information is gathered by Kubelet from the node. +Describes general information about the node, such as kernel version, Kubernetes +version (kubelet and kube-proxy version), container runtime details, and which +operating system the node uses. +The kubelet gathers this information from the node and publishes it into +the Kubernetes API. -### Node controller +## Heartbeats + +Heartbeats, sent by Kubernetes nodes, help your cluster determine the +availability of each node, and to take action when failures are detected. + +For nodes there are two forms of heartbeats: + +* updates to the `.status` of a Node +* [Lease](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) objects + within the `kube-node-lease` + {{< glossary_tooltip term_id="namespace" text="namespace">}}. + Each Node has an associated Lease object. + +Compared to updates to `.status` of a Node, a Lease is a lightweight resource. +Using Leases for heartbeats reduces the performance impact of these updates +for large clusters. + +The kubelet is responsible for creating and updating the `.status` of Nodes, +and for updating their related Leases. + +- The kubelet updates the node's `.status` either when there is change in status + or if there has been no update for a configured interval. The default interval + for `.status` updates to Nodes is 5 minutes, which is much longer than the 40 + second default timeout for unreachable nodes. +- The kubelet creates and then updates its Lease object every 10 seconds + (the default update interval). Lease updates occur independently from + updates to the Node's `.status`. If the Lease update fails, the kubelet retries, + using exponential backoff that starts at 200 milliseconds and capped at 7 seconds. + + +## Node controller The node {{< glossary_tooltip text="controller" term_id="controller" >}} is a Kubernetes control plane component that manages various aspects of nodes. @@ -241,39 +290,18 @@ controller deletes the node from its list of nodes. The third is monitoring the nodes' health. The node controller is responsible for: -- Updating the NodeReady condition of NodeStatus to ConditionUnknown when a node - becomes unreachable, as the node controller stops receiving heartbeats for some - reason such as the node being down. -- Evicting all the pods from the node using graceful termination if - the node continues to be unreachable. The default timeouts are 40s to start - reporting ConditionUnknown and 5m after that to start evicting pods. +- In the case that a node becomes unreachable, updating the NodeReady condition + of within the Node's `.status`. In this case the node controller sets the + NodeReady condition to `ConditionUnknown`. +- If a node remains unreachable: triggering + [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/) + for all of the Pods on the unreachable node. By default, the node controller + waits 5 minutes between marking the node as `ConditionUnknown` and submitting + the first eviction request. The node controller checks the state of each node every `--node-monitor-period` seconds. -#### Heartbeats - -Heartbeats, sent by Kubernetes nodes, help determine the availability of a node. - -There are two forms of heartbeats: updates of `NodeStatus` and the -[Lease object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#lease-v1-coordination-k8s-io). -Each Node has an associated Lease object in the `kube-node-lease` -{{< glossary_tooltip term_id="namespace" text="namespace">}}. -Lease is a lightweight resource, which improves the performance -of the node heartbeats as the cluster scales. - -The kubelet is responsible for creating and updating the `NodeStatus` and -a Lease object. - -- The kubelet updates the `NodeStatus` either when there is change in status - or if there has been no update for a configured interval. The default interval - for `NodeStatus` updates is 5 minutes, which is much longer than the 40 second default - timeout for unreachable nodes. -- The kubelet creates and then updates its Lease object every 10 seconds - (the default update interval). Lease updates occur independently from the - `NodeStatus` updates. If the Lease update fails, the kubelet retries with - exponential backoff starting at 200 milliseconds and capped at 7 seconds. - -#### Reliability +### Rate limits on eviction In most cases, the node controller limits the eviction rate to `--node-eviction-rate` (default 0.1) per second, meaning it won't evict pods @@ -281,9 +309,9 @@ from more than 1 node per 10 seconds. The node eviction behavior changes when a node in a given availability zone becomes unhealthy. The node controller checks what percentage of nodes in the zone -are unhealthy (NodeReady condition is ConditionUnknown or ConditionFalse) at +are unhealthy (NodeReady condition is `ConditionUnknown` or `ConditionFalse`) at the same time: -- If the fraction of unhealthy nodes is at least `--unhealthy-zone-threshold` +- If the fraction of unhealthy nodes is at least `--unhealthy-zone-threshold` (default 0.55), then the eviction rate is reduced. - If the cluster is small (i.e. has less than or equal to `--large-cluster-size-threshold` nodes - default 50), then evictions are stopped. @@ -293,15 +321,17 @@ the same time: The reason these policies are implemented per availability zone is because one availability zone might become partitioned from the master while the others remain connected. If your cluster does not span multiple cloud provider availability zones, -then there is only one availability zone (i.e. the whole cluster). +then the eviction mechanism does not take per-zone unavailability into account. A key reason for spreading your nodes across availability zones is so that the workload can be shifted to healthy zones when one entire zone goes down. Therefore, if all nodes in a zone are unhealthy, then the node controller evicts at the normal rate of `--node-eviction-rate`. The corner case is when all zones are -completely unhealthy (i.e. there are no healthy nodes in the cluster). In such a -case, the node controller assumes that there is some problem with master -connectivity and stops all evictions until some connectivity is restored. +completely unhealthy (none of the nodes in the cluster are healthy). In such a +case, the node controller assumes that there is some problem with connectivity +between the control plane and the nodes, and doesn't perform any evictions. +(If there has been an outage and some nodes reappear, the node controller does +evict pods from the remaining nodes that are unhealthy or unreachable). The node controller is also responsible for evicting pods running on nodes with `NoExecute` taints, unless those pods tolerate that taint. @@ -309,14 +339,7 @@ The node controller also adds {{< glossary_tooltip text="taints" term_id="taint" corresponding to node problems like node unreachable or not ready. This means that the scheduler won't place Pods onto unhealthy nodes. - -{{< caution >}} -`kubectl cordon` marks a node as 'unschedulable', which has the side effect of the service -controller removing the node from any LoadBalancer node target lists it was previously -eligible for, effectively removing incoming load balancer traffic from the cordoned node(s). -{{< /caution >}} - -### Node capacity +## Resource capacity tracking {#node-capacity} Node objects track information about the Node's resource capacity: for example, the amount of memory available and the number of CPUs. @@ -346,26 +369,101 @@ the kubelet can use topology hints when making resource assignment decisions. See [Control Topology Management Policies on a Node](/docs/tasks/administer-cluster/topology-manager/) for more information. -## Graceful Node Shutdown {#graceful-node-shutdown} +## Graceful node shutdown {#graceful-node-shutdown} -{{< feature-state state="alpha" for_k8s_version="v1.20" >}} +{{< feature-state state="beta" for_k8s_version="v1.21" >}} + +The kubelet attempts to detect node system shutdown and terminates pods running on the node. -If you have enabled the `GracefulNodeShutdown` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/), then the kubelet attempts to detect the node system shutdown and terminates pods running on the node. Kubelet ensures that pods follow the normal [pod termination process](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) during the node shutdown. -When the `GracefulNodeShutdown` feature gate is enabled, kubelet uses [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to delay the node shutdown with a given duration. During a shutdown, kubelet terminates pods in two phases: +The Graceful node shutdown feature depends on systemd since it takes advantage of +[systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/) to +delay the node shutdown with a given duration. + +Graceful node shutdown is controlled with the `GracefulNodeShutdown` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) which is +enabled by default in 1.21. + +Note that by default, both configuration options described below, +`ShutdownGracePeriod` and `ShutdownGracePeriodCriticalPods` are set to zero, +thus not activating Graceful node shutdown functionality. +To activate the feature, the two kubelet config settings should be configured appropriately and set to non-zero values. + +During a graceful shutdown, kubelet terminates pods in two phases: 1. Terminate regular pods running on the node. 2. Terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) running on the node. -Graceful Node Shutdown feature is configured with two [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options: +Graceful node shutdown feature is configured with two [`KubeletConfiguration`](/docs/tasks/administer-cluster/kubelet-config-file/) options: * `ShutdownGracePeriod`: * Specifies the total duration that the node should delay the shutdown by. This is the total grace period for pod termination for both regular and [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical). * `ShutdownGracePeriodCriticalPods`: - * Specifies the duration used to terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) during a node shutdown. This should be less than `ShutdownGracePeriod`. + * Specifies the duration used to terminate [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) during a node shutdown. This value should be less than `ShutdownGracePeriod`. -For example, if `ShutdownGracePeriod=30s`, and `ShutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by 30 seconds. During the shutdown, the first 20 (30-10) seconds would be reserved for gracefully terminating normal pods, and the last 10 seconds would be reserved for terminating [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical). +For example, if `ShutdownGracePeriod=30s`, and +`ShutdownGracePeriodCriticalPods=10s`, kubelet will delay the node shutdown by +30 seconds. During the shutdown, the first 20 (30-10) seconds would be reserved +for gracefully terminating normal pods, and the last 10 seconds would be +reserved for terminating [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical). +{{< note >}} +When pods were evicted during the graceful node shutdown, they are marked as failed. +Running `kubectl get pods` shows the status of the the evicted pods as `Shutdown`. +And `kubectl describe pod` indicates that the pod was evicted because of node shutdown: + +``` +Status: Failed +Reason: Shutdown +Message: Node is shutting, evicting pods +``` + +Failed pod objects will be preserved until explicitly deleted or [cleaned up by the GC](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection). +This is a change of behavior compared to abrupt node termination. +{{< /note >}} + +## Swap memory management {#swap-memory} + +{{< feature-state state="alpha" for_k8s_version="v1.22" >}} + +Prior to Kubernetes 1.22, nodes did not support the use of swap memory, and a +kubelet would by default fail to start if swap was detected on a node. In 1.22 +onwards, swap memory support can be enabled on a per-node basis. + +To enable swap on a node, the `NodeSwap` feature gate must be enabled on +the kubelet, and the `--fail-swap-on` command line flag or `failSwapOn` +[configuration setting](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) +must be set to false. + +A user 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`: 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"): + +- **cgroupsv1:** Kubernetes workloads can use any combination of memory and + swap, up to the pod's memory limit, if set. +- **cgroupsv2:** Kubernetes workloads cannot use swap memory. + +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). ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/concepts/cluster-administration/addons.md b/content/en/docs/concepts/cluster-administration/addons.md index 726a714151..5ed93ad20b 100644 --- a/content/en/docs/concepts/cluster-administration/addons.md +++ b/content/en/docs/concepts/cluster-administration/addons.md @@ -23,7 +23,7 @@ This page lists some of the available add-ons and links to their respective inst * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave. * [Contiv](https://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options. * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads. -* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) is an overlay network provider that can be used with Kubernetes. +* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) is an overlay network provider that can be used with Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod. * [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) is a networking provider for Kubernetes based on [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), a virtual networking implementation that came out of the Open vSwitch (OVS) project. OVN-Kubernetes provides an overlay based networking implementation for Kubernetes, including an OVS based implementation of load balancing and network policy. diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index 3e94277d93..46f0a1eadc 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -33,8 +33,6 @@ the `--max-requests-inflight` flag without the API Priority and Fairness feature enabled. {{< /caution >}} - - ## Enabling/Disabling API Priority and Fairness @@ -65,6 +63,7 @@ The command-line flag `--enable-priority-and-fairness=false` will disable the API Priority and Fairness feature, even if other flags have enabled it. ## Concepts + There are several distinct features involved in the API Priority and Fairness feature. Incoming requests are classified by attributes of the request using _FlowSchemas_, and assigned to priority levels. Priority levels add a degree of @@ -75,12 +74,13 @@ each other, and allows for requests to be queued to prevent bursty traffic from causing failed requests when the average load is acceptably low. ### Priority Levels -Without APF enabled, overall concurrency in -the API server is limited by the `kube-apiserver` flags -`--max-requests-inflight` and `--max-mutating-requests-inflight`. With APF -enabled, the concurrency limits defined by these flags are summed and then the sum is divided up -among a configurable set of _priority levels_. Each incoming request is assigned -to a single priority level, and each priority level will only dispatch as many + +Without APF enabled, overall concurrency in the API server is limited by the +`kube-apiserver` flags `--max-requests-inflight` and +`--max-mutating-requests-inflight`. With APF enabled, the concurrency limits +defined by these flags are summed and then the sum is divided up among a +configurable set of _priority levels_. Each incoming request is assigned to a +single priority level, and each priority level will only dispatch as many concurrent requests as its configuration allows. The default configuration, for example, includes separate priority levels for @@ -90,6 +90,7 @@ requests cannot prevent leader election or actions by the built-in controllers from succeeding. ### Queuing + Even within a priority level there may be a large number of distinct sources of traffic. In an overload situation, it is valuable to prevent one stream of requests from starving others (in particular, in the relatively common case of a @@ -114,15 +115,18 @@ independent flows will all make progress when total traffic exceeds capacity), tolerance for bursty traffic, and the added latency induced by queuing. ### Exempt requests + Some requests are considered sufficiently important that they are not subject to any of the limitations imposed by this feature. These exemptions prevent an improperly-configured flow control configuration from totally disabling an API server. ## Defaults + The Priority and Fairness feature ships with a suggested configuration that should suffice for experimentation; if your cluster is likely to -experience heavy load then you should consider what configuration will work best. The suggested configuration groups requests into five priority +experience heavy load then you should consider what configuration will work +best. The suggested configuration groups requests into five priority classes: * The `system` priority level is for requests from the `system:nodes` group, @@ -180,19 +184,18 @@ If you add the following additional FlowSchema, this exempts those requests from rate limiting. {{< caution >}} - Making this change also allows any hostile party to then send health-check requests that match this FlowSchema, at any volume they like. If you have a web traffic filter or similar external security mechanism to protect your cluster's API server from general internet traffic, you can configure rules to block any health check requests that originate from outside your cluster. - {{< /caution >}} {{< codenew file="priority-and-fairness/health-for-strangers.yaml" >}} ## Resources + The flow control API involves two kinds of resources. [PriorityLevelConfigurations](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#prioritylevelconfiguration-v1beta1-flowcontrol-apiserver-k8s-io) define the available isolation classes, the share of the available concurrency @@ -204,6 +207,7 @@ of the same API group, and it has the same Kinds with the same syntax and semantics. ### PriorityLevelConfiguration + A PriorityLevelConfiguration represents a single isolation class. Each PriorityLevelConfiguration has an independent limit on the number of outstanding requests, and limitations on the number of queued requests. @@ -217,6 +221,7 @@ server by restarting `kube-apiserver` with a different value for `--max-requests-inflight` (or `--max-mutating-requests-inflight`), and all PriorityLevelConfigurations will see their maximum allowed concurrency go up (or down) by the same fraction. + {{< caution >}} With the Priority and Fairness feature enabled, the total concurrency limit for the server is set to the sum of `--max-requests-inflight` and @@ -235,8 +240,8 @@ above the threshold will be queued, with the shuffle sharding and fair queuing t to balance progress between request flows. The queuing configuration allows tuning the fair queuing algorithm for a -priority level. Details of the algorithm can be read in the [enhancement -proposal](#whats-next), but in short: +priority level. Details of the algorithm can be read in the +[enhancement proposal](#whats-next), but in short: * Increasing `queues` reduces the rate of collisions between different flows, at the cost of increased memory usage. A value of 1 here effectively disables the @@ -249,15 +254,15 @@ proposal](#whats-next), but in short: * Changing `handSize` allows you to adjust the probability of collisions between different flows and the overall concurrency available to a single flow in an overload situation. - {{< note >}} - A larger `handSize` makes it less likely for two individual flows to collide - (and therefore for one to be able to starve the other), but more likely that - a small number of flows can dominate the apiserver. A larger `handSize` also - potentially increases the amount of latency that a single high-traffic flow - can cause. The maximum number of queued requests possible from a - single flow is `handSize * queueLengthLimit`. - {{< /note >}} + {{< note >}} + A larger `handSize` makes it less likely for two individual flows to collide + (and therefore for one to be able to starve the other), but more likely that + a small number of flows can dominate the apiserver. A larger `handSize` also + potentially increases the amount of latency that a single high-traffic flow + can cause. The maximum number of queued requests possible from a + single flow is `handSize * queueLengthLimit`. + {{< /note >}} Following is a table showing an interesting collection of shuffle sharding configurations, showing for each the probability that a @@ -319,6 +324,7 @@ considered part of a single flow. The correct choice for a given FlowSchema depends on the resource and your particular environment. ## Diagnostics + Every HTTP response from an API server with the priority and fairness feature enabled has two extra headers: `X-Kubernetes-PF-FlowSchema-UID` and `X-Kubernetes-PF-PriorityLevel-UID`, noting the flow schema that matched the request @@ -356,13 +362,14 @@ poorly-behaved workloads that may be harming system health. matched the request), `priority_level` (indicating the one to which the request was assigned), and `reason`. The `reason` label will be have one of the following values: - * `queue-full`, indicating that too many requests were already - queued, - * `concurrency-limit`, indicating that the - PriorityLevelConfiguration is configured to reject rather than - queue excess requests, or - * `time-out`, indicating that the request was still in the queue - when its queuing time limit expired. + + * `queue-full`, indicating that too many requests were already + queued, + * `concurrency-limit`, indicating that the + PriorityLevelConfiguration is configured to reject rather than + queue excess requests, or + * `time-out`, indicating that the request was still in the queue + when its queuing time limit expired. * `apiserver_flowcontrol_dispatched_requests_total` is a counter vector (cumulative since server start) of requests that began @@ -405,6 +412,10 @@ poorly-behaved workloads that may be harming system health. queue) requests, broken down by the labels `priority_level` and `flow_schema`. +* `apiserver_flowcontrol_request_concurrency_in_use` is a gauge vector + holding the instantaneous number of occupied seats, broken down by + the labels `priority_level` and `flow_schema`. + * `apiserver_flowcontrol_priority_level_request_count_samples` is a histogram vector of observations of the then-current number of requests broken down by the labels `phase` (which takes on the @@ -430,14 +441,15 @@ poorly-behaved workloads that may be harming system health. sample to its histogram, reporting the length of the queue immediately after the request was added. Note that this produces different statistics than an unbiased survey would. - {{< note >}} - An outlier value in a histogram here means it is likely that a single flow - (i.e., requests by one user or for one namespace, depending on - configuration) is flooding the API server, and being throttled. By contrast, - if one priority level's histogram shows that all queues for that priority - level are longer than those for other priority levels, it may be appropriate - to increase that PriorityLevelConfiguration's concurrency shares. - {{< /note >}} + + {{< note >}} + An outlier value in a histogram here means it is likely that a single flow + (i.e., requests by one user or for one namespace, depending on + configuration) is flooding the API server, and being throttled. By contrast, + if one priority level's histogram shows that all queues for that priority + level are longer than those for other priority levels, it may be appropriate + to increase that PriorityLevelConfiguration's concurrency shares. + {{< /note >}} * `apiserver_flowcontrol_request_concurrency_limit` is a gauge vector holding the computed concurrency limit (based on the API server's @@ -450,12 +462,13 @@ poorly-behaved workloads that may be harming system health. `priority_level` (indicating the one to which the request was assigned), and `execute` (indicating whether the request started executing). - {{< note >}} - Since each FlowSchema always assigns requests to a single - PriorityLevelConfiguration, you can add the histograms for all the - FlowSchemas for one priority level to get the effective histogram for - requests assigned to that priority level. - {{< /note >}} + + {{< note >}} + Since each FlowSchema always assigns requests to a single + PriorityLevelConfiguration, you can add the histograms for all the + FlowSchemas for one priority level to get the effective histogram for + requests assigned to that priority level. + {{< /note >}} * `apiserver_flowcontrol_request_execution_seconds` is a histogram vector of how long requests took to actually execute, broken down by @@ -465,14 +478,19 @@ poorly-behaved workloads that may be harming system health. ### Debug endpoints -When you enable the API Priority and Fairness feature, the kube-apiserver serves the following additional paths at its HTTP[S] ports. +When you enable the API Priority and Fairness feature, the `kube-apiserver` +serves the following additional paths at its HTTP[S] ports. + +- `/debug/api_priority_and_fairness/dump_priority_levels` - a listing of + all the priority levels and the current state of each. You can fetch like this: -- `/debug/api_priority_and_fairness/dump_priority_levels` - a listing of all the priority levels and the current state of each. You can fetch like this: ```shell kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels ``` + The output is similar to this: - ``` + + ```none PriorityLevelName, ActiveQueues, IsIdle, IsQuiescing, WaitingRequests, ExecutingRequests, workload-low, 0, true, false, 0, 0, global-default, 0, true, false, 0, 0, @@ -483,12 +501,16 @@ When you enable the API Priority and Fairness feature, the kube-apiserver serves workload-high, 0, true, false, 0, 0, ``` -- `/debug/api_priority_and_fairness/dump_queues` - a listing of all the queues and their current state. You can fetch like this: +- `/debug/api_priority_and_fairness/dump_queues` - a listing of all the + queues and their current state. You can fetch like this: + ```shell kubectl get --raw /debug/api_priority_and_fairness/dump_queues ``` + The output is similar to this: - ``` + + ```none PriorityLevelName, Index, PendingRequests, ExecutingRequests, VirtualStart, workload-high, 0, 0, 0, 0.0000, workload-high, 1, 0, 0, 0.0000, @@ -498,25 +520,33 @@ When you enable the API Priority and Fairness feature, the kube-apiserver serves leader-election, 15, 0, 0, 0.0000, ``` -- `/debug/api_priority_and_fairness/dump_requests` - a listing of all the requests that are currently waiting in a queue. You can fetch like this: +- `/debug/api_priority_and_fairness/dump_requests` - a listing of all the requests + that are currently waiting in a queue. You can fetch like this: + ```shell kubectl get --raw /debug/api_priority_and_fairness/dump_requests ``` + The output is similar to this: - ``` + + ```none PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, exempt, , , , , , system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:26:57.179170694Z, ``` - In addition to the queued requests, the output includes one phantom line for each priority level that is exempt from limitation. + In addition to the queued requests, the output includes one phantom line + for each priority level that is exempt from limitation. You can get a more detailed listing with a command like this: + ```shell kubectl get --raw '/debug/api_priority_and_fairness/dump_requests?includeRequestDetails=1' ``` + The output is similar to this: - ``` + + ```none PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, UserName, Verb, APIPath, Namespace, Name, APIVersion, Resource, SubResource, system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:31:03.583823404Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps, system, system-nodes, 12, 1, system:node:127.0.0.1, 2020-07-23T15:31:03.594555947Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps, @@ -526,6 +556,6 @@ When you enable the API Priority and Fairness feature, the kube-apiserver serves For background information on design details for API priority and fairness, see -the [enhancement proposal](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md). +the [enhancement proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1040-priority-and-fairness). You can make suggestions and feature requests via [SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery) -or the feature's [slack channel](http://kubernetes.slack.com/messages/api-priority-and-fairness). +or the feature's [slack channel](https://kubernetes.slack.com/messages/api-priority-and-fairness). diff --git a/content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md deleted file mode 100644 index ea51a566ac..0000000000 --- a/content/en/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -reviewers: -title: Garbage collection for container images -content_type: concept -weight: 70 ---- - - - -Garbage collection is a helpful function of kubelet that will clean up unused [images](/docs/concepts/containers/#container-images) and unused [containers](/docs/concepts/containers/). Kubelet will perform garbage collection for containers every minute and garbage collection for images every five minutes. - -External garbage collection tools are not recommended as these tools can potentially break the behavior of kubelet by removing containers expected to exist. - - - - - - -## Image Collection - -Kubernetes manages lifecycle of all images through imageManager, with the cooperation -of cadvisor. - -The policy for garbage collecting images takes two factors into consideration: -`HighThresholdPercent` and `LowThresholdPercent`. Disk usage above the high threshold -will trigger garbage collection. The garbage collection will delete least recently used images until the low -threshold has been met. - -## Container Collection - -The policy for garbage collecting containers considers three user-defined variables. `MinAge` is the minimum age at which a container can be garbage collected. `MaxPerPodContainer` is the maximum number of dead containers every single -pod (UID, container name) pair is allowed to have. `MaxContainers` is the maximum number of total dead containers. These variables can be individually disabled by setting `MinAge` to zero and setting `MaxPerPodContainer` and `MaxContainers` respectively to less than zero. - -Kubelet will act on containers that are unidentified, deleted, or outside of the boundaries set by the previously mentioned flags. The oldest containers will generally be removed first. `MaxPerPodContainer` and `MaxContainer` may potentially conflict with each other in situations where retaining the maximum number of containers per pod (`MaxPerPodContainer`) would go outside the allowable range of global dead containers (`MaxContainers`). `MaxPerPodContainer` would be adjusted in this situation: A worst case scenario would be to downgrade `MaxPerPodContainer` to 1 and evict the oldest containers. Additionally, containers owned by pods that have been deleted are removed once they are older than `MinAge`. - -Containers that are not managed by kubelet are not subject to container garbage collection. - -## User Configuration - -You can adjust the following thresholds to tune image garbage collection with the following kubelet flags : - -1. `image-gc-high-threshold`, the percent of disk usage which triggers image garbage collection. -Default is 85%. -2. `image-gc-low-threshold`, the percent of disk usage to which image garbage collection attempts -to free. Default is 80%. - -You can customize the garbage collection policy through the following kubelet flags: - -1. `minimum-container-ttl-duration`, minimum age for a finished container before it is -garbage collected. Default is 0 minute, which means every finished container will be garbage collected. -2. `maximum-dead-containers-per-container`, maximum number of old instances to be retained -per container. Default is 1. -3. `maximum-dead-containers`, maximum number of old instances of containers to retain globally. -Default is -1, which means there is no global limit. - -Containers can potentially be garbage collected before their usefulness has expired. These containers -can contain logs and other data that can be useful for troubleshooting. A sufficiently large value for -`maximum-dead-containers-per-container` is highly recommended to allow at least 1 dead container to be -retained per expected container. A larger value for `maximum-dead-containers` is also recommended for a -similar reason. -See [this issue](https://github.com/kubernetes/kubernetes/issues/13287) for more details. - - -## Deprecation - -Some kubelet Garbage Collection features in this doc will be replaced by kubelet eviction in the future. - -Including: - -| Existing Flag | New Flag | Rationale | -| ------------- | -------- | --------- | -| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection | -| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior | -| `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context | -| `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context | -| `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context | -| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | eviction generalizes disk thresholds to other resources | -| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | eviction generalizes disk pressure transition to other resources | - - - -## {{% heading "whatsnext" %}} - - -See [Configuring Out Of Resource Handling](/docs/tasks/administer-cluster/out-of-resource/) for more details. - diff --git a/content/en/docs/concepts/cluster-administration/logging.md b/content/en/docs/concepts/cluster-administration/logging.md index d8c0a0615c..1bf057f23e 100644 --- a/content/en/docs/concepts/cluster-administration/logging.md +++ b/content/en/docs/concepts/cluster-administration/logging.md @@ -81,14 +81,20 @@ rotate an application's logs automatically. As an example, you can find detailed information about how `kube-up.sh` sets up logging for COS image on GCP in the corresponding -[`configure-helper` script](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh). +[`configure-helper` script](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh). + +When using a **CRI container runtime**, the kubelet is responsible for rotating the logs and managing the logging directory structure. +The kubelet sends this information to the CRI container runtime and the runtime writes the container logs to the given location. +The two kubelet parameters [`containerLogMaxSize` and `containerLogMaxFiles`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) +in [kubelet config file](/docs/tasks/administer-cluster/kubelet-config-file/) +can be used to configure the maximum size for each log file and the maximum number of files allowed for each container respectively. When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) as in the basic logging example, the kubelet on the node handles the request and reads directly from the log file. The kubelet returns the content of the log file. {{< note >}} -If an external system has performed the rotation, +If an external system has performed the rotation or a CRI container runtime is used, only the contents of the latest log file will be available through `kubectl logs`. For example, if there's a 10MB file, `logrotate` performs the rotation and there are two files: one file that is 10MB in size and a second file that is empty. diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md index f51911116d..4d98cf820c 100644 --- a/content/en/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/en/docs/concepts/cluster-administration/manage-deployment.md @@ -50,7 +50,7 @@ It is a recommended practice to put resources related to the same microservice o A URL can also be specified as a configuration source, which is handy for deploying directly from configuration files checked into GitHub: ```shell -kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/application/nginx/nginx-deployment.yaml ``` ```shell @@ -160,7 +160,7 @@ If you're interested in learning more about `kubectl`, go ahead and read [kubect The examples we've used so far apply at most a single label to any resource. There are many scenarios where multiple labels should be used to distinguish sets from one another. -For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels: +For instance, different applications would use different values for the `app` label, but a multi-tier application, such as the [guestbook example](https://github.com/kubernetes/examples/tree/master/guestbook/), would additionally need to distinguish each tier. The frontend could carry the following labels: ```yaml labels: diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index c517b13175..9929b75d14 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -91,18 +91,6 @@ imply any preferential status. Project [Antrea](https://github.com/vmware-tanzu/antrea) is an opensource Kubernetes networking solution intended to be Kubernetes native. It leverages Open vSwitch as the networking data plane. Open vSwitch is a high-performance programmable virtual switch that supports both Linux and Windows. Open vSwitch enables Antrea to implement Kubernetes Network Policies in a high-performance and efficient manner. Thanks to the "programmable" characteristic of Open vSwitch, Antrea is able to implement an extensive set of networking and security features and services on top of Open vSwitch. -### AOS from Apstra - -[AOS](https://www.apstra.com/products/aos/) is an Intent-Based Networking system that creates and manages complex datacenter environments from a simple integrated platform. AOS leverages a highly scalable distributed design to eliminate network outages while minimizing costs. - -The AOS Reference Design currently supports Layer-3 connected hosts that eliminate legacy Layer-2 switching problems. These Layer-3 hosts can be Linux servers (Debian, Ubuntu, CentOS) that create BGP neighbor relationships directly with the top of rack switches (TORs). AOS automates the routing adjacencies and then provides fine grained control over the route health injections (RHI) that are common in a Kubernetes deployment. - -AOS has a rich set of REST API endpoints that enable Kubernetes to quickly change the network policy based on application requirements. Further enhancements will integrate the AOS Graph model used for the network design with the workload provisioning, enabling an end to end management system for both private and public clouds. - -AOS supports the use of common vendor equipment from manufacturers including Cisco, Arista, Dell, Mellanox, HPE, and a large number of white-box systems and open network operating systems like Microsoft SONiC, Dell OPX, and Cumulus Linux. - -Details on how the AOS system works can be accessed here: https://www.apstra.com/products/how-it-works/ - ### AWS VPC CNI for Kubernetes The [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) offers integrated AWS Virtual Private Cloud (VPC) networking for Kubernetes clusters. This CNI plugin offers high throughput and availability, low latency, and minimal network jitter. Additionally, users can apply existing AWS VPC networking and security best practices for building Kubernetes clusters. This includes the ability to use VPC flow logs, VPC routing policies, and security groups for network traffic isolation. @@ -116,15 +104,6 @@ Additionally, the CNI can be run alongside [Calico for network policy enforcemen Azure CNI is available natively in the [Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni). - -### Big Cloud Fabric from Big Switch Networks - -[Big Cloud Fabric](https://www.bigswitch.com/container-network-automation) is a cloud native networking architecture, designed to run Kubernetes in private cloud/on-premises environments. Using unified physical & virtual SDN, Big Cloud Fabric tackles inherent container networking problems such as load balancing, visibility, troubleshooting, security policies & container traffic monitoring. - -With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, container orchestration systems such as Kubernetes, RedHat OpenShift, Mesosphere DC/OS & Docker Swarm will be natively integrated alongside with VM orchestration systems such as VMware, OpenStack & Nutanix. Customers will be able to securely inter-connect any number of these clusters and enable inter-tenant communication between them if needed. - -BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/). - ### Calico [Calico](https://docs.projectcalico.org/) is an open source networking and network security solution for containers, virtual machines, and native host-based workloads. Calico supports multiple data planes including: a pure Linux eBPF dataplane, a standard Linux networking dataplane, and a Windows HNS dataplane. Calico provides a full networking stack but can also be used in conjunction with [cloud provider CNIs](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) to provide network policy enforcement. @@ -269,7 +248,7 @@ Lars Kellogg-Stedman. [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi CNI plugin to support the Multi Networking feature in Kubernetes using CRD based network objects in Kubernetes. -Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) that implement the CNI specification and 3rd party plugins (eg. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). In addition to it, Multus supports [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes. +Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [Flannel](https://github.com/containernetworking/cni.dev/blob/main/content/plugins/v0.9/meta/flannel.md), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) that implement the CNI specification and 3rd party plugins (eg. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). In addition to it, Multus supports [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes. ### OVN4NFV-K8s-Plugin (OVN based CNI controller & plugin) diff --git a/content/en/docs/concepts/cluster-administration/system-metrics.md b/content/en/docs/concepts/cluster-administration/system-metrics.md index 3c7e137ded..bfcfec9ecb 100644 --- a/content/en/docs/concepts/cluster-administration/system-metrics.md +++ b/content/en/docs/concepts/cluster-administration/system-metrics.md @@ -134,7 +134,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} ### kube-scheduler metrics -{{< feature-state for_k8s_version="v1.20" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} The scheduler exposes optional metrics that reports the requested resources and the desired limits of all running pods. These metrics can be used to build capacity planning dashboards, assess current or historical scheduling limits, quickly identify workloads that cannot schedule due to lack of resources, and compare actual usage to the pod's request. @@ -152,8 +152,27 @@ Once a pod reaches completion (has a `restartPolicy` of `Never` or `OnFailure` a The metrics are exposed at the HTTP endpoint `/metrics/resources` and require the same authorization as the `/metrics` endpoint on the scheduler. You must use the `--show-hidden-metrics-for-version=1.20` flag to expose these alpha stability metrics. +## Disabling metrics + +You can explicitly turn off metrics via command line flag `--disabled-metrics`. This may be desired if, for example, a metric is causing a performance problem. The input is a list of disabled metrics (i.e. `--disabled-metrics=metric1,metric2`). + +## Metric cardinality enforcement + +Metrics with unbounded dimensions could cause memory issues in the components they instrument. To limit resource use, you can use the `--allow-label-value` command line option to dynamically configure an allow-list of label values for a metric. + +In alpha stage, the flag can only take in a series of mappings as metric label allow-list. +Each mapping is of the format `,=` where +`` is a comma-separated list of acceptable label names. + +The overall format looks like: +`--allow-label-value ,=', ...', ,=', ...', ...`. + +Here is an example: +`--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday'` + ## {{% heading "whatsnext" %}} * Read about the [Prometheus text format](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) for metrics +* See the list of [stable Kubernetes metrics](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) * Read about the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) diff --git a/content/en/docs/concepts/cluster-administration/system-traces.md b/content/en/docs/concepts/cluster-administration/system-traces.md new file mode 100644 index 0000000000..f324604b16 --- /dev/null +++ b/content/en/docs/concepts/cluster-administration/system-traces.md @@ -0,0 +1,89 @@ +--- +title: Traces For Kubernetes System Components +reviewers: +- logicalhan +- lilic +content_type: concept +weight: 60 +--- + + + +{{< feature-state for_k8s_version="v1.22" state="alpha" >}} + +System component traces record the latency of and relationships between operations in the cluster. + +Kubernetes components emit traces using the +[OpenTelemetry Protocol](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#opentelemetry-protocol-specification) +with the gRPC exporter and can be collected and routed to tracing backends using an +[OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector#-opentelemetry-collector). + + + +## Trace Collection + +For a complete guide to collecting traces and using the collector, see +[Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/). +However, there are a few things to note that are specific to Kubernetes components. + +By default, Kubernetes components export traces using the grpc exporter for OTLP on the +[IANA OpenTelemetry port](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=opentelemetry), 4317. +As an example, if the collector is running as a sidecar to a Kubernetes component, +the following receiver configuration will collect spans and log them to standard output: + +```yaml +receivers: + otlp: + protocols: + grpc: +exporters: + # Replace this exporter with the exporter for your backend + logging: + logLevel: debug +service: + pipelines: + traces: + receivers: [otlp] + exporters: [logging] +``` + +## Component traces + +### kube-apiserver traces + +The kube-apiserver generates spans for incoming HTTP requests, and for outgoing requests +to webhooks, etcd, and re-entrant requests. It propagates the +[W3C Trace Context](https://www.w3.org/TR/trace-context/) with outgoing requests +but does not make use of the trace context attached to incoming requests, +as the kube-apiserver is often a public endpoint. + +#### Enabling tracing in the kube-apiserver + +To enable tracing, enable the `APIServerTracing` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +on the kube-apiserver. Also, provide the kube-apiserver with a tracing configration file +with `--tracing-config-file=`. This is an example config that records +spans for 1 in 10000 requests, and uses the default OpenTelemetry endpoint: + +```yaml +apiVersion: apiserver.config.k8s.io/v1alpha1 +kind: TracingConfiguration +# default value +#endpoint: localhost:4317 +samplingRatePerMillion: 100 +``` + +For more information about the `TracingConfiguration` struct, see +[API server config API (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration). + +## Stability + +Tracing instrumentation is still under active development, and may change +in a variety of ways. This includes span names, attached attributes, +instrumented endpoints, etc. Until this feature graduates to stable, +there are no guarantees of backwards compatibility for tracing instrumentation. + +## {{% heading "whatsnext" %}} + +* Read about [Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/) + diff --git a/content/en/docs/concepts/configuration/_index.md b/content/en/docs/concepts/configuration/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/concepts/configuration/configmap.md b/content/en/docs/concepts/configuration/configmap.md index b5f5bd8d28..47ecaedba6 100644 --- a/content/en/docs/concepts/configuration/configmap.md +++ b/content/en/docs/concepts/configuration/configmap.md @@ -61,6 +61,11 @@ You can write a Pod `spec` that refers to a ConfigMap and configures the contain in that Pod based on the data in the ConfigMap. The Pod and the ConfigMap must be in the same {{< glossary_tooltip text="namespace" term_id="namespace" >}}. +{{< note >}} +The `spec` of a {{< glossary_tooltip text="static Pod" term_id="static-pod" >}} cannot refer to a ConfigMap +or any other API objects. +{{< /note >}} + Here's an example ConfigMap that has some keys with single values, and other keys where the value looks like a fragment of a configuration format. @@ -224,7 +229,7 @@ When a ConfigMap currently consumed in a volume is updated, projected keys are e The kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, the kubelet uses its local cache for getting the current value of the ConfigMap. The type of the cache is configurable using the `ConfigMapAndSecretChangeDetectionStrategy` field in -the [KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/)). +the [KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/). A ConfigMap can be either propagated by watch (default), ttl-based, or by redirecting all requests directly to the API server. As a result, the total delay from the moment when the ConfigMap is updated to the moment @@ -236,9 +241,9 @@ ConfigMaps consumed as environment variables are not updated automatically and r ## Immutable ConfigMaps {#configmap-immutable} -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} -The Kubernetes beta feature _Immutable Secrets and ConfigMaps_ provides an option to set +The Kubernetes feature _Immutable Secrets and ConfigMaps_ provides an option to set individual Secrets and ConfigMaps as immutable. For clusters that extensively use ConfigMaps (at least tens of thousands of unique ConfigMap to Pod mounts), preventing changes to their data has the following advantages: diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md index ee4669641c..cbcfff67ef 100644 --- a/content/en/docs/concepts/configuration/manage-resources-containers.md +++ b/content/en/docs/concepts/configuration/manage-resources-containers.md @@ -115,7 +115,7 @@ CPU is always requested as an absolute quantity, never as a relative quantity; Limits and requests for `memory` are measured in bytes. You can express memory as a plain integer or as a fixed-point number using one of these suffixes: -E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, +E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi, Mi, Ki. For example, the following represent roughly the same value: ```shell @@ -181,8 +181,9 @@ When using Docker: flag in the `docker run` command. - The `spec.containers[].resources.limits.cpu` is converted to its millicore value and - multiplied by 100. The resulting value is the total amount of CPU time that a container can use - every 100ms. A container cannot use more than its share of CPU time during this interval. + multiplied by 100. The resulting value is the total amount of CPU time in microseconds + that a container can use every 100ms. A container cannot use more than its share of + CPU time during this interval. {{< note >}} The default quota period is 100ms. The minimum resolution of CPU quota is 1ms. @@ -337,6 +338,9 @@ spec: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi" + volumeMounts: + - name: ephemeral + mountPath: "/tmp" - name: log-aggregator image: images.my-company.example/log-aggregator:v6 resources: @@ -344,6 +348,12 @@ spec: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi" + volumeMounts: + - name: ephemeral + mountPath: "/tmp" + volumes: + - name: ephemeral + emptyDir: {} ``` ### How Pods with ephemeral-storage requests are scheduled diff --git a/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index df767bbc3e..b27fcdee61 100644 --- a/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -17,6 +17,11 @@ a *kubeconfig file*. This is a generic way of referring to configuration files. It does not mean that there is a file named `kubeconfig`. {{< /note >}} +{{< warning >}} +Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure. +If you must use an untrusted kubeconfig file, inspect it carefully first, much as you would a shell script. +{{< /warning>}} + By default, `kubectl` looks for a file named `config` in the `$HOME/.kube` directory. You can specify other kubeconfig files by setting the `KUBECONFIG` environment variable or by setting the @@ -154,4 +159,3 @@ are stored absolutely. - diff --git a/content/en/docs/concepts/configuration/overview.md b/content/en/docs/concepts/configuration/overview.md index 25cfb2e7f1..36eebe3abc 100644 --- a/content/en/docs/concepts/configuration/overview.md +++ b/content/en/docs/concepts/configuration/overview.md @@ -21,7 +21,7 @@ This is a living document. If you think of something that is not on this list bu - Write your configuration files using YAML rather than JSON. Though these formats can be used interchangeably in almost all scenarios, YAML tends to be more user-friendly. -- Group related objects into a single file whenever it makes sense. One file is often easier to manage than several. See the [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) file as an example of this syntax. +- Group related objects into a single file whenever it makes sense. One file is often easier to manage than several. See the [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) file as an example of this syntax. - Note also that many `kubectl` commands can be called on a directory. For example, you can call `kubectl apply` on a directory of config files. @@ -63,7 +63,7 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN ## Using Labels -- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) app for examples of this approach. +- Define and use [labels](/docs/concepts/overview/working-with-objects/labels/) that identify __semantic attributes__ of your application or Deployment, such as `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. You can use these labels to select the appropriate Pods for other resources; for example, a Service that selects all `tier: frontend` Pods, or all `phase: test` components of `app: myapp`. See the [guestbook](https://github.com/kubernetes/examples/tree/master/guestbook/) app for examples of this approach. A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. When you need to update a running service without downtime, use a [Deployment](/docs/concepts/workloads/controllers/deployment/). @@ -73,32 +73,6 @@ A desired state of an object is described by a Deployment, and if changes to tha - You can manipulate labels for debugging. Because Kubernetes controllers (such as ReplicaSet) and Services match to Pods using selector labels, removing the relevant labels from a Pod will stop it from being considered by a controller or from being served traffic by a Service. If you remove the labels of an existing Pod, its controller will create a new Pod to take its place. This is a useful way to debug a previously "live" Pod in a "quarantine" environment. To interactively remove or add labels, use [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label). -## Container Images - -The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the tag of the image affect when the [kubelet](/docs/reference/command-line-tools-reference/kubelet/) attempts to pull the specified image. - -- `imagePullPolicy: IfNotPresent`: the image is pulled only if it is not already present locally. - -- `imagePullPolicy: Always`: every time the kubelet launches a container, the kubelet queries the container image registry to resolve the name to an image digest. If the kubelet has a container image with that exact digest cached locally, the kubelet uses its cached image; otherwise, the kubelet downloads (pulls) the image with the resolved digest, and uses that image to launch the container. - -- `imagePullPolicy` is omitted and either the image tag is `:latest` or it is omitted: `imagePullPolicy` is automatically set to `Always`. Note that this will _not_ be updated to `IfNotPresent` if the tag changes value. - -- `imagePullPolicy` is omitted and the image tag is present but not `:latest`: `imagePullPolicy` is automatically set to `IfNotPresent`. Note that this will _not_ be updated to `Always` if the tag is later removed or changed to `:latest`. - -- `imagePullPolicy: Never`: the image is assumed to exist locally. No attempt is made to pull the image. - -{{< note >}} -To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier); replace `:` with `@` (for example, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). The digest uniquely identifies a specific version of the image, so it is never updated by Kubernetes unless you change the digest value. -{{< /note >}} - -{{< note >}} -You should avoid using the `:latest` tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly. -{{< /note >}} - -{{< note >}} -The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient, as long as the registry is reliably accessible. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed. -{{< /note >}} - ## Using kubectl - Use `kubectl apply -f `. This looks for Kubernetes configuration in all `.yaml`, `.yml`, and `.json` files in `` and passes it to `apply`. diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index d41c7eacf9..e1c7dfb79b 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -12,26 +12,33 @@ weight: 30 -Kubernetes Secrets let you store and manage sensitive information, such -as passwords, OAuth tokens, and ssh keys. Storing confidential information in a Secret -is safer and more flexible than putting it verbatim in a -{{< glossary_tooltip term_id="pod" >}} definition or in a -{{< glossary_tooltip text="container image" term_id="image" >}}. -See [Secrets design document](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) for more information. - A Secret is an object that contains a small amount of sensitive data such as a password, a token, or a key. Such information might otherwise be put in a -Pod specification or in an image. Users can create Secrets and the system -also creates some Secrets. +{{< glossary_tooltip term_id="pod" >}} specification or in a +{{< glossary_tooltip text="container image" term_id="image" >}}. Using a +Secret means that you don't need to include confidential data in your +application code. + +Because Secrets can be created independently of the Pods that use them, there +is less risk of the Secret (and its data) being exposed during the workflow of +creating, viewing, and editing Pods. Kubernetes, and applications that run in +your cluster, can also take additional precautions with Secrets, such as +avoiding writing confidential data to nonvolatile storage. + +Secrets are similar to {{< glossary_tooltip text="ConfigMaps" term_id="configmap" >}} +but are specifically intended to hold confidential data. {{< caution >}} -Kubernetes Secrets are, by default, stored as unencrypted base64-encoded -strings. By default they can be retrieved - as plain text - by anyone with API -access, or anyone with access to Kubernetes' underlying data store, etcd. In -order to safely use Secrets, it is recommended you (at a minimum): +Kubernetes Secrets are, by default, stored unencrypted in the API server's underlying data store (etcd). Anyone with API access can retrieve or modify a Secret, and so can anyone with access to etcd. +Additionally, anyone who is authorized to create a Pod in a namespace can use that access to read any Secret in that namespace; this includes indirect access such as the ability to create a Deployment. + +In order to safely use Secrets, take at least the following steps: 1. [Enable Encryption at Rest](/docs/tasks/administer-cluster/encrypt-data/) for Secrets. -2. [Enable or configure RBAC rules](/docs/reference/access-authn-authz/authorization/) that restrict reading and writing the Secret. Be aware that secrets can be obtained implicitly by anyone with the permission to create a Pod. +2. Enable or configure [RBAC rules](/docs/reference/access-authn-authz/authorization/) that + restrict reading data in Secrets (including via indirect means). +3. Where appropriate, also use mechanisms such as RBAC to limit which principals are allowed to create new Secrets or replace existing ones. + {{< /caution >}} @@ -47,6 +54,10 @@ A Secret can be used with a Pod in three ways: - As [container environment variable](#using-secrets-as-environment-variables). - By the [kubelet when pulling images](#using-imagepullsecrets) for the Pod. +The Kubernetes control plane also uses Secrets; for example, +[bootstrap token Secrets](#bootstrap-token-secrets) are a mechanism to +help automate node registration. + The name of a Secret object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). You can specify the `data` and/or the `stringData` field when creating a @@ -64,9 +75,9 @@ precedence. ## Types of Secret {#secret-types} When creating a Secret, you can specify its type using the `type` field of -the [`Secret`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) -resource, or certain equivalent `kubectl` command line flags (if available). -The Secret type is used to facilitate programmatic handling of the Secret data. +a Secret resource, or certain equivalent `kubectl` command line flags (if available). +The `type` of a Secret is used to facilitate programmatic handling of different +kinds of confidential data. Kubernetes provides several builtin types for some common usage scenarios. These types vary in terms of the validations performed and the constraints @@ -328,13 +339,13 @@ kubectl create secret tls my-tls-secret \ --key=path/to/key/file ``` -The public/private key pair must exist before hand. The public key certificate +The public/private key pair must exist beforehand. The public key certificate for `--cert` must be .PEM encoded (Base64-encoded DER format), and match the given private key for `--key`. The private key must be in what is commonly called PEM private key format, unencrypted. In both cases, the initial and the last lines from PEM (for example, `--------BEGIN CERTIFICATE-----` and `-------END CERTIFICATE----` for -a cetificate) are *not* included. +a certificate) are *not* included. ### Bootstrap token Secrets @@ -749,9 +760,9 @@ There are third party solutions for triggering restarts when secrets change. ## Immutable Secrets {#secret-immutable} -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} -The Kubernetes beta feature _Immutable Secrets and ConfigMaps_ provides an option to set +The Kubernetes feature _Immutable Secrets and ConfigMaps_ provides an option to set individual Secrets and ConfigMaps as immutable. For clusters that extensively use Secrets (at least tens of thousands of unique Secret to Pod mounts), preventing changes to their data has the following advantages: @@ -822,7 +833,10 @@ are obtained from the API server. This includes any Pods created using `kubectl`, or indirectly via a replication controller. It does not include Pods created as a result of the kubelet `--manifest-url` flag, its `--config` flag, or its REST API (these are -not common ways to create Pods.) +not common ways to create Pods). +The `spec` of a {{< glossary_tooltip text="static Pod" term_id="static-pod" >}} cannot refer to a Secret +or any other API objects. + Secrets must be created before they are consumed in Pods as environment variables unless they are marked as optional. References to secrets that do @@ -1164,7 +1178,7 @@ limit access using [authorization policies]( Secrets often hold values that span a spectrum of importance, many of which can cause escalations within Kubernetes (e.g. service account tokens) and to external systems. Even if an individual app can reason about the power of the -secrets it expects to interact with, other apps within the same namespace can +Secrets it expects to interact with, other apps within the same namespace can render those assumptions invalid. For these reasons `watch` and `list` requests for secrets within a namespace are @@ -1235,15 +1249,10 @@ for secret data, so that the secrets are not stored in the clear into {{< glossa - A user who can create a Pod that uses a secret can also see the value of that secret. Even if the API server policy does not allow that user to read the Secret, the user could run a Pod which exposes the secret. - - Currently, anyone with root permission on any node can read _any_ secret from the API server, - by impersonating the kubelet. It is a planned feature to only send secrets to - nodes that actually require them, to restrict the impact of a root exploit on a - single node. - ## {{% heading "whatsnext" %}} - Learn how to [manage Secret using `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) - Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/) - Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) - +- Read the [API reference](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/) for `Secret` diff --git a/content/en/docs/concepts/containers/container-environment.md b/content/en/docs/concepts/containers/container-environment.md index a1eba4d96d..3c4c153927 100644 --- a/content/en/docs/concepts/containers/container-environment.md +++ b/content/en/docs/concepts/containers/container-environment.md @@ -52,7 +52,7 @@ FOO_SERVICE_PORT= ``` Services have dedicated IP addresses and are available to the Container via DNS, -if [DNS addon](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) is enabled.  +if [DNS addon](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/) is enabled.  diff --git a/content/en/docs/concepts/containers/container-lifecycle-hooks.md b/content/en/docs/concepts/containers/container-lifecycle-hooks.md index 49cc25ffbd..96569f9518 100644 --- a/content/en/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/en/docs/concepts/containers/container-lifecycle-hooks.md @@ -50,11 +50,10 @@ A more detailed description of the termination behavior can be found in ### Hook handler implementations Containers can access a hook by implementing and registering a handler for that hook. -There are three types of hook handlers that can be implemented for Containers: +There are two types of hook handlers that can be implemented for Containers: * Exec - Executes a specific command, such as `pre-stop.sh`, inside the cgroups and namespaces of the Container. Resources consumed by the command are counted against the Container. -* TCP - Opens a TCP connecton against a specific port on the Container. * HTTP - Executes an HTTP request against a specific endpoint on the Container. ### Hook handler execution diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md index 6d0db16fe8..5dfd349f80 100644 --- a/content/en/docs/concepts/containers/images.md +++ b/content/en/docs/concepts/containers/images.md @@ -25,7 +25,7 @@ This page provides an outline of the container image concept. Container images are usually given a name such as `pause`, `example/mycontainer`, or `kube-apiserver`. Images can also include a registry hostname; for example: `fictional.registry.example/imagename`, -and possible a port number as well; for example: `fictional.registry.example:10443/imagename`. +and possibly a port number as well; for example: `fictional.registry.example:10443/imagename`. If you don't specify a registry hostname, Kubernetes assumes that you mean the Docker public registry. @@ -39,14 +39,6 @@ There are additional rules about where you can place the separator characters (`_`, `-`, and `.`) inside an image tag. If you don't specify a tag, Kubernetes assumes you mean the tag `latest`. -{{< caution >}} -You should avoid using the `latest` tag when deploying containers in production, -as it is harder to track which version of the image is running and more difficult -to roll back to a working version. - -Instead, specify a meaningful tag such as `v1.42.0`. -{{< /caution >}} - ## Updating images When you first create a {{< glossary_tooltip text="Deployment" term_id="deployment" >}}, @@ -57,13 +49,68 @@ specified. This policy causes the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} to skip pulling an image if it already exists. -If you would like to always force a pull, you can do one of the following: +### Image pull policy -- set the `imagePullPolicy` of the container to `Always`. -- omit the `imagePullPolicy` and use `:latest` as the tag for the image to use; - Kubernetes will set the policy to `Always`. -- omit the `imagePullPolicy` and the tag for the image to use. -- enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller. +The `imagePullPolicy` for a container and the tag of the image affect when the +[kubelet](/docs/reference/command-line-tools-reference/kubelet/) attempts to pull (download) the specified image. + +Here's a list of the values you can set for `imagePullPolicy` and the effects +these values have: + +`IfNotPresent` +: the image is pulled only if it is not already present locally. + +`Always` +: every time the kubelet launches a container, the kubelet queries the container + image registry to resolve the name to an image + [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier). If the kubelet has a + container image with that exact digest cached locally, the kubelet uses its cached + image; otherwise, the kubelet pulls the image with the resolved digest, + and uses that image to launch the container. + +`Never` +: the kubelet does not try fetching the image. If the image is somehow already present + locally, the kubelet attempts to start the container; otherwise, startup fails. + See [pre-pulled images](#pre-pulled-images) for more details. + +The caching semantics of the underlying image provider make even +`imagePullPolicy: Always` efficient, as long as the registry is reliably accessible. +Your container runtime can notice that the image layers already exist on the node +so that they don't need to be downloaded again. + +{{< note >}} +You should avoid using the `:latest` tag when deploying containers in production as +it is harder to track which version of the image is running and more difficult to +roll back properly. + +Instead, specify a meaningful tag such as `v1.42.0`. +{{< /note >}} + +To make sure the Pod always uses the same version of a container image, you can specify +the image's digest; +replace `:` with `@` +(for example, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). + +When using image tags, if the image registry were to change the code that the tag on that image represents, you might end up with a mix of Pods running the old and new code. An image digest uniquely identifies a specific version of the image, so Kubernetes runs the same code every time it starts a container with that image name and digest specified. Specifying an image fixes the code that you run so that a change at the registry cannot lead to that mix of versions. + +There are third-party [admission controllers](/docs/reference/access-authn-authz/admission-controllers/) +that mutate Pods (and pod templates) when they are created, so that the +running workload is defined based on an image digest rather than a tag. +That might be useful if you want to make sure that all your workload is +running the same code no matter what tag changes happen at the registry. + +#### Default image pull policy {#imagepullpolicy-defaulting} + +When you (or a controller) submit a new Pod to the API server, your cluster sets the +`imagePullPolicy` field when specific conditions are met: + +- if you omit the `imagePullPolicy` field, and the tag for the container image is + `:latest`, `imagePullPolicy` is automatically set to `Always`; +- if you omit the `imagePullPolicy` field, and you don't specify the tag for the + container image, `imagePullPolicy` is automatically set to `Always`; +- if you omit the `imagePullPolicy` field, and you specify the tag for the + container image that isn't `:latest`, the `imagePullPolicy` is automatically set to + `IfNotPresent`. {{< note >}} The value of `imagePullPolicy` of the container is always set when the object is @@ -75,7 +122,31 @@ For example, if you create a Deployment with an image whose tag is _not_ the pull policy of any object after its initial creation. {{< /note >}} -When `imagePullPolicy` is defined without a specific value, it is also set to `Always`. +#### Required image pull + +If you would like to always force a pull, you can do one of the following: + +- Set the `imagePullPolicy` of the container to `Always`. +- Omit the `imagePullPolicy` and use `:latest` as the tag for the image to use; + Kubernetes will set the policy to `Always` when you submit the Pod. +- Omit the `imagePullPolicy` and the tag for the image to use; + Kubernetes will set the policy to `Always` when you submit the Pod. +- Enable the [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) admission controller. + + +### ImagePullBackOff + +When a kubelet starts creating containers for a Pod using a container runtime, +it might be possible the container is in [Waiting](/docs/concepts/workloads/pods/pod-lifecycle/#container-state-waiting) +state because of `ImagePullBackOff`. + +The status `ImagePullBackOff` means that a container could not start because Kubernetes +could not pull a container image (for reasons such as invalid image name, or pulling +from a private registry without `imagePullSecret`). The `BackOff` part indicates +that Kubernetes will keep trying to pull the image, with an increasing back-off delay. + +Kubernetes raises the delay between each attempt until it reaches a compiled-in limit, +which is 300 seconds (5 minutes). ## Multi-architecture images with image indexes @@ -314,6 +385,8 @@ common use cases and suggested solutions. If you need access to multiple registries, you can create one secret for each registry. Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config.json` + ## {{% heading "whatsnext" %}} -* Read the [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md) +* Read the [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md). +* Learn about [container image garbage collection](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection). diff --git a/content/en/docs/concepts/containers/runtime-class.md b/content/en/docs/concepts/containers/runtime-class.md index abfec1ef6c..96858d32af 100644 --- a/content/en/docs/concepts/containers/runtime-class.md +++ b/content/en/docs/concepts/containers/runtime-class.md @@ -51,7 +51,7 @@ heterogeneous node configurations, see [Scheduling](#scheduling) below. {{< /note >}} The configurations have a corresponding `handler` name, referenced by the RuntimeClass. The -handler must be a valid DNS 1123 label (alpha-numeric + `-` characters). +handler must be a valid [DNS label name](/docs/concepts/overview/working-with-objects/names/#dns-label-names). ### 2. Create the corresponding RuntimeClass resources @@ -109,7 +109,8 @@ For more details on setting up CRI runtimes, see [CRI installation](/docs/setup/ #### dockershim -Kubernetes built-in dockershim CRI does not support runtime handlers. +RuntimeClasses with dockershim must set the runtime handler to `docker`. Dockershim does not support +custom configurable runtime handlers. #### {{< glossary_tooltip term_id="containerd" >}} @@ -117,7 +118,7 @@ Runtime handlers are configured through containerd's configuration at `/etc/containerd/config.toml`. Valid handlers are configured under the runtimes section: ``` -[plugins.cri.containerd.runtimes.${HANDLER_NAME}] +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] ``` See containerd's config documentation for more details: @@ -134,7 +135,7 @@ table](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntim runtime_path = "${PATH_TO_BINARY}" ``` -See CRI-O's [config documentation](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md) for more details. +See CRI-O's [config documentation](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md) for more details. ## Scheduling @@ -163,7 +164,7 @@ Nodes](/docs/concepts/scheduling-eviction/assign-pod-node/). {{< feature-state for_k8s_version="v1.18" state="beta" >}} You can specify _overhead_ resources that are associated with running a Pod. Declaring overhead allows -the cluster (including the scheduler) to account for it when making decisions about Pods and resources. +the cluster (including the scheduler) to account for it when making decisions about Pods and resources. To use Pod overhead, you must have the PodOverhead [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) enabled (it is on by default). @@ -178,4 +179,4 @@ are accounted for in Kubernetes. - [RuntimeClass Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md) - [RuntimeClass Scheduling Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling) - Read about the [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/) concept -- [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) +- [PodOverhead Feature Design](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) diff --git a/content/en/docs/concepts/extend-kubernetes/_index.md b/content/en/docs/concepts/extend-kubernetes/_index.md index cc5ba809ec..083dca6964 100644 --- a/content/en/docs/concepts/extend-kubernetes/_index.md +++ b/content/en/docs/concepts/extend-kubernetes/_index.md @@ -7,6 +7,10 @@ reviewers: - lavalamp - cheftako - chenopis +feature: + title: Designed for extensibility + description: > + Add features to your Kubernetes cluster without changing upstream source code. content_type: concept no_list: true --- @@ -80,18 +84,15 @@ and by kubectl. Below is a diagram showing how the extension points interact with the Kubernetes control plane. - - - +![Extension Points and the Control Plane](/docs/concepts/extend-kubernetes/control-plane.png) ## Extension Points This diagram shows the extension points in a Kubernetes system. - - +![Extension Points](/docs/concepts/extend-kubernetes/extension-points.png) 1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies. 2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](#api-access-extensions) section. @@ -103,12 +104,11 @@ This diagram shows the extension points in a Kubernetes system. If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions. - - - +![Flowchart for Extension](/docs/concepts/extend-kubernetes/flowchart.png) ## API Extensions + ### User-Defined Types Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`. @@ -157,7 +157,6 @@ After a request is authorized, if it is a write operation, it also goes through ## Infrastructure Extensions - ### Storage Plugins [Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index d9fe184f85..f6bb478d73 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/en/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -1,5 +1,5 @@ --- -title: Extending the Kubernetes API with the aggregation layer +title: Kubernetes API Aggregation Layer reviewers: - lavalamp - cheftako @@ -11,7 +11,7 @@ weight: 20 The aggregation layer allows Kubernetes to be extended with additional APIs, beyond what is offered by the core Kubernetes APIs. -The additional APIs can either be ready-made solutions such as [service-catalog](/docs/concepts/extend-kubernetes/service-catalog/), or APIs that you develop yourself. +The additional APIs can either be ready-made solutions such as a [metrics server](https://github.com/kubernetes-sigs/metrics-server), or APIs that you develop yourself. The aggregation layer is different from [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/), which are a way to make the {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} recognise new kinds of object. @@ -34,7 +34,7 @@ If your extension API server cannot achieve that latency requirement, consider m * To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/). * Then, [setup an extension api-server](/docs/tasks/extend-kubernetes/setup-extension-api-server/) to work with the aggregation layer. -* Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). -* Read the specification for [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io) +* Read about [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/) in the API reference +Alternatively: learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index f37a71f278..b3fa73e5f0 100644 --- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -35,11 +35,11 @@ On their own, custom resources let you store and retrieve structured data. When you combine a custom resource with a *custom controller*, custom resources provide a true _declarative API_. -A [declarative API](/docs/concepts/overview/kubernetes-api/) -allows you to _declare_ or specify the desired state of your resource and tries to -keep the current state of Kubernetes objects in sync with the desired state. -The controller interprets the structured data as a record of the user's -desired state, and continually maintains this state. +The Kubernetes [declarative API](/docs/concepts/overview/kubernetes-api/) +enforces a separation of responsibilities. You declare the desired state of +your resource. The Kubernetes controller keeps the current state of Kubernetes +objects in sync with your declared desired state. This is in contrast to an +imperative API, where you *instruct* a server what to do. You can deploy and update a custom controller on a running cluster, independently of the cluster's lifecycle. Custom controllers can work with any kind of resource, @@ -167,7 +167,7 @@ CRDs are easier to create than Aggregated APIs. | CRDs | Aggregated API | | --------------------------- | -------------- | -| Do not require programming. Users can choose any language for a CRD controller. | Requires programming in Go and building binary and image. | +| Do not require programming. Users can choose any language for a CRD controller. | Requires programming and building binary and image. | | No additional service to run; CRDs are handled by API server. | An additional service to create and that could fail. | | No ongoing support once the CRD is created. Any bug fixes are picked up as part of normal Kubernetes Master upgrades. | May need to periodically pickup bug fixes from upstream and rebuild and update the Aggregated API server. | | No need to handle multiple versions of your API; for example, when you control the client for this resource, you can upgrade it in sync with the API. | You need to handle multiple versions of your API; for example, when developing an extension to share with the world. | diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 8b1747b857..868d8d56e8 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -193,9 +193,78 @@ for these devices: // node resources consumed by pods and containers on the node service PodResourcesLister { rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {} + rpc GetAllocatableResources(AllocatableResourcesRequest) returns (AllocatableResourcesResponse) {} } ``` +The `List` endpoint provides information on resources of running pods, with details such as the +id of exclusively allocated CPUs, device id as it was reported by device plugins and id of +the NUMA node where these devices are allocated. Also, for NUMA-based machines, it contains the information about memory and hugepages reserved for a container. + +```gRPC +// ListPodResourcesResponse is the response returned by List function +message ListPodResourcesResponse { + repeated PodResources pod_resources = 1; +} + +// PodResources contains information about the node resources assigned to a pod +message PodResources { + string name = 1; + string namespace = 2; + repeated ContainerResources containers = 3; +} + +// ContainerResources contains information about the resources assigned to a container +message ContainerResources { + string name = 1; + repeated ContainerDevices devices = 2; + repeated int64 cpu_ids = 3; + repeated ContainerMemory memory = 4; +} + +// ContainerMemory contains information about memory and hugepages assigned to a container +message ContainerMemory { + string memory_type = 1; + uint64 size = 2; + TopologyInfo topology = 3; +} + +// Topology describes hardware topology of the resource +message TopologyInfo { + repeated NUMANode nodes = 1; +} + +// NUMA representation of NUMA node +message NUMANode { + int64 ID = 1; +} + +// ContainerDevices contains information about the devices assigned to a container +message ContainerDevices { + string resource_name = 1; + repeated string device_ids = 2; + TopologyInfo topology = 3; +} +``` + +GetAllocatableResources provides information on resources initially available on the worker node. +It provides more information than kubelet exports to APIServer. + +```gRPC +// AllocatableResourcesResponses contains informations about all the devices known by the kubelet +message AllocatableResourcesResponse { + repeated ContainerDevices devices = 1; + repeated int64 cpu_ids = 2; + repeated ContainerMemory memory = 3; +} + +``` + +`ContainerDevices` do expose the topology information declaring to which NUMA cells the device is affine. +The NUMA cells are identified using a opaque integer ID, which value is consistent to what device +plugins report [when they register themselves to the kubelet](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager). + + The gRPC service is served over a unix socket at `/var/lib/kubelet/pod-resources/kubelet.sock`. Monitoring agents for device plugin resources can be deployed as a daemon, or as a DaemonSet. The canonical directory `/var/lib/kubelet/pod-resources` requires privileged access, so monitoring @@ -204,7 +273,7 @@ DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a {{< glossary_tooltip term_id="volume" >}} in the device monitoring agent's [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core). -Support for the "PodResources service" requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled. +Support for the `PodResourcesLister service` requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled. It is enabled by default starting with Kubernetes 1.15 and is v1 since Kubernetes 1.20. ## Device Plugin integration with the Topology Manager @@ -256,5 +325,3 @@ Here are some examples of device plugin implementations: * Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node * Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes * Learn about the [Topology Manager](/docs/tasks/administer-cluster/topology-manager/) - - diff --git a/content/en/docs/concepts/extend-kubernetes/control-plane.png b/content/en/docs/concepts/extend-kubernetes/control-plane.png new file mode 100644 index 0000000000..fa61599e94 Binary files /dev/null and b/content/en/docs/concepts/extend-kubernetes/control-plane.png differ diff --git a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md deleted file mode 100644 index 2bdc74e7e9..0000000000 --- a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md +++ /dev/null @@ -1,207 +0,0 @@ ---- -title: Extending your Kubernetes Cluster -reviewers: -- erictune -- lavalamp -- cheftako -- chenopis -content_type: concept -weight: 10 ---- - - - -Kubernetes is highly configurable and extensible. As a result, -there is rarely a need to fork or submit patches to the Kubernetes -project code. - -This guide describes the options for customizing a Kubernetes cluster. It is -aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} -who want to understand how to adapt their -Kubernetes cluster to the needs of their work environment. Developers who are prospective -{{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} -or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} -will also find it useful as an introduction to what extension points and -patterns exist, and their trade-offs and limitations. - - - - -## Overview - -Customization approaches can be broadly divided into *configuration*, which only involves changing flags, local configuration files, or API resources; and *extensions*, which involve running additional programs or services. This document is primarily about extensions. - -## Configuration - -*Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary: - -* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) -* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) -* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) -* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). - -Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options. - -*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable. - -## Extensions - -Extensions are software components that extend and deeply integrate with Kubernetes. -They adapt it to support new types and new kinds of hardware. - -Most cluster administrators will use a hosted or distribution -instance of Kubernetes. As a result, most Kubernetes users will not need to -install extensions and fewer will need to author new ones. - -## Extension Patterns - -Kubernetes is designed to be automated by writing client programs. Any -program that reads and/or writes to the Kubernetes API can provide useful -automation. *Automation* can run on the cluster or off it. By following -the guidance in this doc you can write highly available and robust automation. -Automation generally works with any Kubernetes cluster, including hosted -clusters and managed installations. - -There is a specific pattern for writing client programs that work well with -Kubernetes called the *Controller* pattern. Controllers typically read an -object's `.spec`, possibly do things, and then update the object's `.status`. - -A controller is a client of Kubernetes. When Kubernetes is the client and -calls out to a remote service, it is called a *Webhook*. The remote service -is called a *Webhook Backend*. Like Controllers, Webhooks do add a point of -failure. - -In the webhook model, Kubernetes makes a network request to a remote service. -In the *Binary Plugin* model, Kubernetes executes a binary (program). -Binary plugins are used by the kubelet (e.g. -[Flex Volume Plugins](/docs/concepts/storage/volumes/#flexvolume) -and [Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)) -and by kubectl. - -Below is a diagram showing how the extension points interact with the -Kubernetes control plane. - - - - - - -## Extension Points - -This diagram shows the extension points in a Kubernetes system. - - - - - -1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies. -2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/extend-kubernetes/#api-access-extensions) section. -3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/extend-kubernetes/#user-defined-types) section. Custom Resources are often used with API Access Extensions. -4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/extend-kubernetes/#scheduler-extensions) section. -5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources. -6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/extend-kubernetes/#network-plugins) allow for different implementations of pod networking. -7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/extend-kubernetes/#storage-plugins). - -If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions. - - - - - - -## API Extensions -### User-Defined Types - -Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`. - -Do not use a Custom Resource as data storage for application, user, or monitoring data. - -For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). - - -### Combining New APIs with Automation - -The combination of a custom resource API and a control loop is called the [Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage specific, usually stateful, applications. These custom APIs and control loops can also be used to control other resources, such as storage or policies. - -### Changing Built-in Resources - -When you extend the Kubernetes API by adding custom resources, the added resources always fall into a new API Groups. You cannot replace or change existing API groups. -Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API Access Extensions do. - - -### API Access Extensions - -When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/) for more on this flow. - -Each of these steps offers extension points. - -Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/). - -### Authentication - -[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates in all requests to a username for the client making the request. - -Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs. - - -### Authorization - -[Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision. - - -### Dynamic Admission Control - -After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. In addition to the built-in steps, there are several extensions: - -* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers. -* To make arbitrary admission control decisions, a general [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates. - -## Infrastructure Extensions - - -### Storage Plugins - -[Flex Volumes](/docs/concepts/storage/volumes/#flexvolume) -allow users to mount volume types without built-in support by having the -Kubelet call a Binary Plugin to mount the volume. - - -### Device Plugins - -Device plugins allow a node to discover new Node resources (in addition to the -builtin ones like cpu and memory) via a -[Device Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/). - -### Network Plugins - -Different networking fabrics can be supported via node-level -[Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). - -### Scheduler Extensions - -The scheduler is a special type of controller that watches pods, and assigns -pods to nodes. The default scheduler can be replaced entirely, while -continuing to use other Kubernetes components, or -[multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) -can run at the same time. - -This is a significant undertaking, and almost all Kubernetes users find they -do not need to modify the scheduler. - -The scheduler also supports a -[webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md) -that permits a webhook backend (scheduler extension) to filter and prioritize -the nodes chosen for a pod. - - -## {{% heading "whatsnext" %}} - -* Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) -* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/) -* Learn more about Infrastructure extensions - * [Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) - * [Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) -* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) -* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/) - - diff --git a/content/en/docs/concepts/extend-kubernetes/extension-points.png b/content/en/docs/concepts/extend-kubernetes/extension-points.png new file mode 100644 index 0000000000..01fb689e7b Binary files /dev/null and b/content/en/docs/concepts/extend-kubernetes/extension-points.png differ diff --git a/content/en/docs/concepts/extend-kubernetes/flowchart.png b/content/en/docs/concepts/extend-kubernetes/flowchart.png new file mode 100644 index 0000000000..e75802c048 Binary files /dev/null and b/content/en/docs/concepts/extend-kubernetes/flowchart.png differ diff --git a/content/en/docs/concepts/extend-kubernetes/operator.md b/content/en/docs/concepts/extend-kubernetes/operator.md index 323200ec3a..72fe12f1e7 100644 --- a/content/en/docs/concepts/extend-kubernetes/operator.md +++ b/content/en/docs/concepts/extend-kubernetes/operator.md @@ -51,8 +51,7 @@ Some of the things that you can use an operator to automate include: * choosing a leader for a distributed application without an internal member election process -What might an Operator look like in more detail? Here's an example in more -detail: +What might an Operator look like in more detail? Here's an example: 1. A custom resource named SampleDB, that you can configure into the cluster. 2. A Deployment that makes sure a Pod is running that contains the @@ -113,15 +112,19 @@ Operator. {{% thirdparty-content %}} +* [Charmed Operator Framework](https://juju.is/) * [kubebuilder](https://book.kubebuilder.io/) +* [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET operator SDK) * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) -* [Metacontroller](https://metacontroller.app/) along with WebHooks that +* [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html) along with WebHooks that you implement yourself * [Operator Framework](https://operatorframework.io) +* [shell-operator](https://github.com/flant/shell-operator) ## {{% heading "whatsnext" %}} +* Read the {{< glossary_tooltip text="CNCF" term_id="cncf" >}} [Operator White Paper](https://github.com/cncf/tag-app-delivery/blob/eece8f7307f2970f46f100f51932db106db46968/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md). * Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * Find ready-made operators on [OperatorHub.io](https://operatorhub.io/) to suit your use case * [Publish](https://operatorhub.io/) your operator for other people to use diff --git a/content/en/docs/concepts/extend-kubernetes/service-catalog.md b/content/en/docs/concepts/extend-kubernetes/service-catalog.md index af0271d9ab..26517de9c6 100644 --- a/content/en/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/en/docs/concepts/extend-kubernetes/service-catalog.md @@ -32,7 +32,7 @@ The application can access the message queue as a service. Service Catalog uses the [Open service broker API](https://github.com/openservicebrokerapi/servicebroker) to communicate with service brokers, acting as an intermediary for the Kubernetes API Server to negotiate the initial provisioning and retrieve the credentials necessary for the application to use a managed service. -It is implemented as an extension API server and a controller, using etcd for storage. It also uses the [aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) available in Kubernetes 1.7+ to present its API. +It is implemented using a [CRDs-based](/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources) architecture.
diff --git a/content/en/docs/concepts/overview/_index.md b/content/en/docs/concepts/overview/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md index 61cd2b0d30..6c5c0eefa1 100644 --- a/content/en/docs/concepts/overview/components.md +++ b/content/en/docs/concepts/overview/components.md @@ -16,7 +16,7 @@ card: When you deploy Kubernetes, you get a cluster. {{< glossary_definition term_id="cluster" length="all" prepend="A Kubernetes cluster consists of">}} -This document outlines the various components you need to have +This document outlines the various components you need to have for a complete and working Kubernetes cluster. Here's the diagram of a Kubernetes cluster with all the components tied together. diff --git a/content/en/docs/concepts/overview/what-is-kubernetes.md b/content/en/docs/concepts/overview/what-is-kubernetes.md index b19c4155ce..d72f1beb48 100644 --- a/content/en/docs/concepts/overview/what-is-kubernetes.md +++ b/content/en/docs/concepts/overview/what-is-kubernetes.md @@ -21,7 +21,7 @@ This page is an overview of Kubernetes. Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available. -The name Kubernetes originates from Greek, meaning helmsman or pilot. Google open-sourced the Kubernetes project in 2014. Kubernetes combines [over 15 years of Google's experience](/blog/2015/04/borg-predecessor-to-kubernetes/) running production workloads at scale with best-of-breed ideas and practices from the community. +The name Kubernetes originates from Greek, meaning helmsman or pilot. K8s as an abbreviation results from counting the eight letters between the "K" and the "s". Google open-sourced the Kubernetes project in 2014. Kubernetes combines [over 15 years of Google's experience](/blog/2015/04/borg-predecessor-to-kubernetes/) running production workloads at scale with best-of-breed ideas and practices from the community. ## Going back in time @@ -45,7 +45,7 @@ Containers have become popular because they provide extra benefits, such as: * Agile application creation and deployment: increased ease and efficiency of container image creation compared to VM image use. * Continuous development, integration, and deployment: provides for reliable and frequent container image build and deployment with quick and efficient rollbacks (due to image immutability). * Dev and Ops separation of concerns: create application container images at build/release time rather than deployment time, thereby decoupling applications from infrastructure. -* Observability not only surfaces OS-level information and metrics, but also application health and other signals. +* Observability: not only surfaces OS-level information and metrics, but also application health and other signals. * Environmental consistency across development, testing, and production: Runs the same on a laptop as it does in the cloud. * Cloud and OS distribution portability: Runs on Ubuntu, RHEL, CoreOS, on-premises, on major public clouds, and anywhere else. * Application-centric management: Raises the level of abstraction from running an OS on virtual hardware to running an application on an OS using logical resources. diff --git a/content/en/docs/concepts/overview/working-with-objects/_index.md b/content/en/docs/concepts/overview/working-with-objects/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/concepts/overview/working-with-objects/annotations.md b/content/en/docs/concepts/overview/working-with-objects/annotations.md index fe31841612..f09820bc32 100644 --- a/content/en/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/en/docs/concepts/overview/working-with-objects/annotations.md @@ -30,6 +30,11 @@ Annotations, like labels, are key/value maps: } ``` +{{}} +The keys and the values in the map must be strings. In other words, you cannot use +numeric, boolean, list or other types for either the keys or the values. +{{}} + Here are some examples of information that could be recorded in annotations: * Fields managed by a declarative configuration layer. Attaching these fields diff --git a/content/en/docs/concepts/overview/working-with-objects/common-labels.md b/content/en/docs/concepts/overview/working-with-objects/common-labels.md index 29af899b4e..3053544cd2 100644 --- a/content/en/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/en/docs/concepts/overview/working-with-objects/common-labels.md @@ -39,7 +39,8 @@ on every resource object. | `app.kubernetes.io/version` | The current version of the application (e.g., a semantic version, revision hash, etc.) | `5.7.21` | string | | `app.kubernetes.io/component` | The component within the architecture | `database` | string | | `app.kubernetes.io/part-of` | The name of a higher level application this one is part of | `wordpress` | string | -| `app.kubernetes.io/managed-by` | The tool being used to manage the operation of an application | `helm` | string | +| `app.kubernetes.io/managed-by` | The tool being used to manage the operation of an application | `helm` | string | +| `app.kubernetes.io/created-by` | The controller/user who created this resource | `controller-manager` | string | To illustrate these labels in action, consider the following StatefulSet object: @@ -54,6 +55,7 @@ metadata: app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress app.kubernetes.io/managed-by: helm + app.kubernetes.io/created-by: controller-manager ``` ## Applications And Instances Of Applications @@ -170,4 +172,3 @@ metadata: With the MySQL `StatefulSet` and `Service` you'll notice information about both MySQL and WordPress, the broader application, are included. - diff --git a/content/en/docs/concepts/overview/working-with-objects/field-selectors.md b/content/en/docs/concepts/overview/working-with-objects/field-selectors.md index 45a81e9035..a65cb54798 100644 --- a/content/en/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/en/docs/concepts/overview/working-with-objects/field-selectors.md @@ -48,7 +48,7 @@ kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Alway ## Multiple resource types -You use field selectors across multiple resource types. This `kubectl` command selects all Statefulsets and Services that are not in the `default` namespace: +You can use field selectors across multiple resource types. This `kubectl` command selects all Statefulsets and Services that are not in the `default` namespace: ```shell kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default diff --git a/content/en/docs/concepts/overview/working-with-objects/finalizers.md b/content/en/docs/concepts/overview/working-with-objects/finalizers.md new file mode 100644 index 0000000000..9516b935c9 --- /dev/null +++ b/content/en/docs/concepts/overview/working-with-objects/finalizers.md @@ -0,0 +1,80 @@ +--- +title: Finalizers +content_type: concept +weight: 60 +--- + + + +{{}} + +You can use finalizers to control {{}} +of resources by alerting {{}} to perform specific cleanup tasks before +deleting the target resource. + +Finalizers don't usually specify the code to execute. Instead, they are +typically lists of keys on a specific resource similar to annotations. +Kubernetes specifies some finalizers automatically, but you can also specify +your own. + +## How finalizers work + +When you create a resource using a manifest file, you can specify finalizers in +the `metadata.finalizers` field. When you attempt to delete the resource, the +controller that manages it notices the values in the `finalizers` field and does +the following: + + * Modifies the object to add a `metadata.deletionTimestamp` field with the + time you started the deletion. + * Marks the object as read-only until its `metadata.finalizers` field is empty. + +The controller then attempts to satisfy the requirements of the finalizers +specified for that resource. Each time a finalizer condition is satisfied, the +controller removes that key from the resource's `finalizers` field. When the +field is empty, garbage collection continues. You can also use finalizers to +prevent deletion of unmanaged resources. + +A common example of a finalizer is `kubernetes.io/pv-protection`, which prevents +accidental deletion of `PersistentVolume` objects. When a `PersistentVolume` +object is in use by a Pod, Kubernetes adds the `pv-protection` finalizer. If you +try to delete the `PersistentVolume`, it enters a `Terminating` status, but the +controller can't delete it because the finalizer exists. When the Pod stops +using the `PersistentVolume`, Kubernetes clears the `pv-protection` finalizer, +and the controller deletes the volume. + +## Owner references, labels, and finalizers {#owners-labels-finalizers} + +Like {{}}, [owner references](/concepts/overview/working-with-objects/owners-dependents/) +describe the relationships between objects in Kubernetes, but are used for a +different purpose. When a +{{}} manages objects +like Pods, it uses labels to track changes to groups of related objects. For +example, when a {{}} creates one or +more Pods, the Job controller applies labels to those pods and tracks changes to +any Pods in the cluster with the same label. + +The Job controller also adds *owner references* to those Pods, pointing at the +Job that created the Pods. If you delete the Job while these Pods are running, +Kubernetes uses the owner references (not labels) to determine which Pods in the +cluster need cleanup. + +Kubernetes also processes finalizers when it identifies owner references on a +resource targeted for deletion. + +In some situations, finalizers can block the deletion of dependent objects, +which can cause the targeted owner object to remain in a read-only state for +longer than expected without being fully deleted. In these situations, you +should check finalizers and owner references on the target owner and dependent +objects to troubleshoot the cause. + +{{}} +In cases where objects are stuck in a deleting state, try to avoid manually +removing finalizers to allow deletion to continue. Finalizers are usually added +to resources for a reason, so forcefully removing them can lead to issues in +your cluster. +{{}} + +## {{% heading "whatsnext" %}} + +* Read [Using Finalizers to Control Deletion](/blog/2021/05/14/using-finalizers-to-control-deletion/) + on the Kubernetes blog. diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 716955ca06..c763b40e05 100644 --- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -81,12 +81,11 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to * `metadata` - Data that helps uniquely identify the object, including a `name` string, `UID`, and optional `namespace` * `spec` - What state you desire for the object -The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) can help you find the spec format for all of the objects you can create using Kubernetes. -For example, the `spec` format for a Pod can be found in -[PodSpec v1 core](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core), -and the `spec` format for a Deployment can be found in -[DeploymentSpec v1 apps](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps). +The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](https://kubernetes.io/docs/reference/kubernetes-api/) can help you find the spec format for all of the objects you can create using Kubernetes. +For example, the reference for Pod details the [`spec` field](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) +for a Pod in the API, and the reference for Deployment details the [`spec` field](/docs/reference/kubernetes-api/workload-resources/deployment-v1/#DeploymentSpec) for Deployments. +In those API reference pages you'll see mention of PodSpec and DeploymentSpec. These names are implementation details of the Golang code that Kubernetes uses to implement its API. ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/concepts/overview/working-with-objects/labels.md b/content/en/docs/concepts/overview/working-with-objects/labels.md index 811d9fb3f7..fe590402ae 100644 --- a/content/en/docs/concepts/overview/working-with-objects/labels.md +++ b/content/en/docs/concepts/overview/working-with-objects/labels.md @@ -42,7 +42,7 @@ Example labels: * `"partition" : "customerA"`, `"partition" : "customerB"` * `"track" : "daily"`, `"track" : "weekly"` -These are examples of commonly used labels; you are free to develop your own conventions. Keep in mind that label Key must be unique for a given object. +These are examples of [commonly used labels](/docs/concepts/overview/working-with-objects/common-labels/); you are free to develop your own conventions. Keep in mind that label Key must be unique for a given object. ## Syntax and character set @@ -50,11 +50,11 @@ _Labels_ are key/value pairs. Valid label keys have two segments: an optional pr If the prefix is omitted, the label Key is presumed to be private to the user. Automated system components (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, or other third-party automation) which add labels to end-user objects must specify a prefix. -The `kubernetes.io/` and `k8s.io/` prefixes are reserved for Kubernetes core components. +The `kubernetes.io/` and `k8s.io/` prefixes are [reserved](/docs/reference/labels-annotations-taints/) for Kubernetes core components. Valid label value: -* must be 63 characters or less (cannot be empty), -* must begin and end with an alphanumeric character (`[a-z0-9A-Z]`), +* must be 63 characters or less (can be empty), +* unless empty, must begin and end with an alphanumeric character (`[a-z0-9A-Z]`), * could contain dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between. For example, here's the configuration file for a Pod that has two labels `environment: production` and `app: nginx` : @@ -237,4 +237,3 @@ selector: One use case for selecting over labels is to constrain the set of nodes onto which a pod can schedule. See the documentation on [node selection](/docs/concepts/scheduling-eviction/assign-pod-node/) for more information. - diff --git a/content/en/docs/concepts/overview/working-with-objects/names.md b/content/en/docs/concepts/overview/working-with-objects/names.md index 8e74eb5c0b..9bafb1584c 100644 --- a/content/en/docs/concepts/overview/working-with-objects/names.md +++ b/content/en/docs/concepts/overview/working-with-objects/names.md @@ -28,7 +28,7 @@ For non-unique user-provided attributes, Kubernetes provides [labels](/docs/conc In cases when objects represent a physical entity, like a Node representing a physical host, when the host is re-created under the same name without deleting and re-creating the Node, Kubernetes treats the new host as the old one, which may lead to inconsistencies. {{< /note >}} -Below are three types of commonly used name constraints for resources. +Below are four types of commonly used name constraints for resources. ### DNS Subdomain Names @@ -41,7 +41,7 @@ This means the name must: - start with an alphanumeric character - end with an alphanumeric character -### DNS Label Names +### RFC 1123 Label Names {#dns-label-names} Some resource types require their names to follow the DNS label standard as defined in [RFC 1123](https://tools.ietf.org/html/rfc1123). @@ -52,6 +52,17 @@ This means the name must: - start with an alphanumeric character - end with an alphanumeric character +### RFC 1035 Label Names + +Some resource types require their names to follow the DNS +label standard as defined in [RFC 1035](https://tools.ietf.org/html/rfc1035). +This means the name must: + +- contain at most 63 characters +- contain only lowercase alphanumeric characters or '-' +- start with an alphabetic character +- end with an alphanumeric character + ### Path Segment Names Some resource types require their names to be able to be safely encoded as a diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md index b7ae176d7c..6664a2ad4c 100644 --- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md @@ -30,7 +30,7 @@ Namespaces are a way to divide cluster resources between multiple users (via [re It is not necessary to use multiple namespaces to separate slightly different resources, such as different versions of the same software: use -[labels](/docs/concepts/overview/working-with-objects/labels) to distinguish +{{< glossary_tooltip text="labels" term_id="label" >}} to distinguish resources within the same namespace. ## Working with Namespaces @@ -39,7 +39,7 @@ Creation and deletion of namespaces are described in the [Admin Guide documentation for namespaces](/docs/tasks/administer-cluster/namespaces). {{< note >}} - Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces. + Avoid creating namespaces with the prefix `kube-`, since it is reserved for Kubernetes system namespaces. {{< /note >}} ### Viewing namespaces @@ -62,7 +62,10 @@ Kubernetes starts with four initial namespaces: * `default` The default namespace for objects with no other namespace * `kube-system` The namespace for objects created by the Kubernetes system * `kube-public` This namespace is created automatically and is readable by all users (including those not authenticated). This namespace is mostly reserved for cluster usage, in case that some resources should be visible and readable publicly throughout the whole cluster. The public aspect of this namespace is only a convention, not a requirement. - * `kube-node-lease` This namespace for the lease objects associated with each node which improves the performance of the node heartbeats as the cluster scales. + * `kube-node-lease` This namespace holds [Lease](/docs/reference/kubernetes-api/cluster-resources/lease-v1/) + objects associated with each node. Node leases allow the kubelet to send + [heartbeats](/docs/concepts/architecture/nodes/#heartbeats) so that the control plane + can detect node failure. ### Setting the namespace for a request @@ -114,6 +117,16 @@ kubectl api-resources --namespaced=true kubectl api-resources --namespaced=false ``` +## Automatic labelling + +{{< feature-state state="beta" for_k8s_version="1.21" >}} + +The Kubernetes control plane sets an immutable {{< glossary_tooltip text="label" term_id="label" >}} +`kubernetes.io/metadata.name` on all namespaces, provided that the `NamespaceDefaultLabelName` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled. +The value of the label is the namespace name. + + ## {{% heading "whatsnext" %}} * Learn more about [creating a new namespace](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace). diff --git a/content/en/docs/concepts/overview/working-with-objects/owners-dependents.md b/content/en/docs/concepts/overview/working-with-objects/owners-dependents.md new file mode 100644 index 0000000000..ea40c3b3a3 --- /dev/null +++ b/content/en/docs/concepts/overview/working-with-objects/owners-dependents.md @@ -0,0 +1,89 @@ +--- +title: Owners and Dependents +content_type: concept +weight: 60 +--- + + + +In Kubernetes, some objects are *owners* of other objects. For example, a +{{}} is the owner of a set of Pods. These owned objects are *dependents* +of their owner. + +Ownership is different from the [labels and selectors](/docs/concepts/overview/working-with-objects/labels/) +mechanism that some resources also use. For example, consider a Service that +creates `EndpointSlice` objects. The Service uses labels to allow the control plane to +determine which `EndpointSlice` objects are used for that Service. In addition +to the labels, each `EndpointSlice` that is managed on behalf of a Service has +an owner reference. Owner references help different parts of Kubernetes avoid +interfering with objects they don’t control. + +## Owner references in object specifications + +Dependent objects have a `metadata.ownerReferences` field that references their +owner object. A valid owner reference consists of the object name and a UID +within the same namespace as the dependent object. Kubernetes sets the value of +this field automatically for objects that are dependents of other objects like +ReplicaSets, DaemonSets, Deployments, Jobs and CronJobs, and ReplicationControllers. +You can also configure these relationships manually by changing the value of +this field. However, you usually don't need to and can allow Kubernetes to +automatically manage the relationships. + +Dependent objects also have an `ownerReferences.blockOwnerDeletion` field that +takes a boolean value and controls whether specific dependents can block garbage +collection from deleting their owner object. Kubernetes automatically sets this +field to `true` if a {{}} +(for example, the Deployment controller) sets the value of the +`metadata.ownerReferences` field. You can also set the value of the +`blockOwnerDeletion` field manually to control which dependents block garbage +collection. + +A Kubernetes admission controller controls user access to change this field for +dependent resources, based on the delete permissions of the owner. This control +prevents unauthorized users from delaying owner object deletion. + +{{< note >}} +Cross-namespace owner references are disallowed by design. +Namespaced dependents can specify cluster-scoped or namespaced owners. +A namespaced owner **must** exist in the same namespace as the dependent. +If it does not, the owner reference is treated as absent, and the dependent +is subject to deletion once all owners are verified absent. + +Cluster-scoped dependents can only specify cluster-scoped owners. +In v1.20+, if a cluster-scoped dependent specifies a namespaced kind as an owner, +it is treated as having an unresolvable owner reference, and is not able to be garbage collected. + +In v1.20+, if the garbage collector detects an invalid cross-namespace `ownerReference`, +or a cluster-scoped dependent with an `ownerReference` referencing a namespaced kind, a warning Event +with a reason of `OwnerRefInvalidNamespace` and an `involvedObject` of the invalid dependent is reported. +You can check for that kind of Event by running +`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`. +{{< /note >}} + +## Ownership and finalizers + +When you tell Kubernetes to delete a resource, the API server allows the +managing controller to process any [finalizer rules](/docs/concepts/overview/working-with-objects/finalizers/) +for the resource. {{}} +prevent accidental deletion of resources your cluster may still need to function +correctly. For example, if you try to delete a `PersistentVolume` that is still +in use by a Pod, the deletion does not happen immediately because the +`PersistentVolume` has the `kubernetes.io/pv-protection` finalizer on it. +Instead, the volume remains in the `Terminating` status until Kubernetes clears +the finalizer, which only happens after the `PersistentVolume` is no longer +bound to a Pod. + +Kubernetes also adds finalizers to an owner resource when you use either +[foreground or orphan cascading deletion](/docs/concepts/architecture/garbage-collection/#cascading-deletion). +In foreground deletion, it adds the `foreground` finalizer so that the +controller must delete dependent resources that also have +`ownerReferences.blockOwnerDeletion=true` before it deletes the owner. If you +specify an orphan deletion policy, Kubernetes adds the `orphan` finalizer so +that the controller ignores dependent resources after it deletes the owner +object. + +## {{% heading "whatsnext" %}} + +* Learn more about [Kubernetes finalizers](/docs/concepts/overview/working-with-objects/finalizers/). +* Learn about [garbage collection](/docs/concepts/architecture/garbage-collection). +* Read the API reference for [object metadata](/docs/reference/kubernetes-api/common-definitions/object-meta/#System). \ No newline at end of file diff --git a/content/en/docs/concepts/policy/_index.md b/content/en/docs/concepts/policy/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/concepts/policy/node-resource-managers.md b/content/en/docs/concepts/policy/node-resource-managers.md new file mode 100644 index 0000000000..719e8b1151 --- /dev/null +++ b/content/en/docs/concepts/policy/node-resource-managers.md @@ -0,0 +1,22 @@ +--- +reviewers: +- derekwaynecarr +- klueska +title: Node Resource Managers +content_type: concept +weight: 50 +--- + + + +In order to support latency-critical and high-throughput workloads, Kubernetes offers a suite of Resource Managers. The managers aim to co-ordinate and optimise node's resources alignment for pods configured with a specific requirement for CPUs, devices, and memory (hugepages) resources. + + + +The main manager, the Topology Manager, is a Kubelet component that co-ordinates the overall resource management process through its [policy](/docs/tasks/administer-cluster/topology-manager/). + +The configuration of individual managers is elaborated in dedicated documents: + +- [CPU Manager Policies](/docs/tasks/administer-cluster/cpu-management-policies/) +- [Device Manager](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) +- [Memory Manager Policies](/docs/tasks/administer-cluster/memory-manager/) diff --git a/content/en/docs/concepts/policy/pid-limiting.md b/content/en/docs/concepts/policy/pid-limiting.md index 6d173bc845..1e03ccf375 100644 --- a/content/en/docs/concepts/policy/pid-limiting.md +++ b/content/en/docs/concepts/policy/pid-limiting.md @@ -10,7 +10,8 @@ weight: 40 {{< feature-state for_k8s_version="v1.20" state="stable" >}} -Kubernetes allow you to limit the number of process IDs (PIDs) that a {{< glossary_tooltip term_id="Pod" text="Pod" >}} can use. +Kubernetes allow you to limit the number of process IDs (PIDs) that a +{{< glossary_tooltip term_id="Pod" text="Pod" >}} can use. You can also reserve a number of allocatable PIDs for each {{< glossary_tooltip term_id="node" text="node" >}} for use by the operating system and daemons (rather than by Pods). @@ -84,7 +85,9 @@ gate](/docs/reference/command-line-tools-reference/feature-gates/) Kubernetes allows you to limit the number of processes running in a Pod. You specify this limit at the node level, rather than configuring it as a resource limit for a particular Pod. Each Node can have a different PID limit. -To configure the limit, you can specify the command line parameter `--pod-max-pids` to the kubelet, or set `PodPidsLimit` in the kubelet [configuration file](/docs/tasks/administer-cluster/kubelet-config-file/). +To configure the limit, you can specify the command line parameter `--pod-max-pids` +to the kubelet, or set `PodPidsLimit` in the kubelet +[configuration file](/docs/tasks/administer-cluster/kubelet-config-file/). {{< note >}} Before Kubernetes version 1.20, PID resource limiting for Pods required enabling @@ -95,9 +98,12 @@ the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) ## PID based eviction You can configure kubelet to start terminating a Pod when it is misbehaving and consuming abnormal amount of resources. -This feature is called eviction. You can [Configure Out of Resource Handling](/docs/tasks/administer-cluster/out-of-resource) for various eviction signals. +This feature is called eviction. You can +[Configure Out of Resource Handling](/docs/concepts/scheduling-eviction/node-pressure-eviction/) +for various eviction signals. Use `pid.available` eviction signal to configure the threshold for number of PIDs used by Pod. -You can set soft and hard eviction policies. However, even with the hard eviction policy, if the number of PIDs growing very fast, +You can set soft and hard eviction policies. +However, even with the hard eviction policy, if the number of PIDs growing very fast, node can still get into unstable state by hitting the node PIDs limit. Eviction signal value is calculated periodically and does NOT enforce the limit. @@ -112,6 +118,7 @@ when one Pod is misbehaving. ## {{% heading "whatsnext" %}} - Refer to the [PID Limiting enhancement document](https://github.com/kubernetes/enhancements/blob/097b4d8276bc9564e56adf72505d43ce9bc5e9e8/keps/sig-node/20190129-pid-limiting.md) for more information. -- For historical context, read [Process ID Limiting for Stability Improvements in Kubernetes 1.14](/blog/2019/04/15/process-id-limiting-for-stability-improvements-in-kubernetes-1.14/). +- For historical context, read + [Process ID Limiting for Stability Improvements in Kubernetes 1.14](/blog/2019/04/15/process-id-limiting-for-stability-improvements-in-kubernetes-1.14/). - Read [Managing Resources for Containers](/docs/concepts/configuration/manage-resources-containers/). -- Learn how to [Configure Out of Resource Handling](/docs/tasks/administer-cluster/out-of-resource). +- Learn how to [Configure Out of Resource Handling](/docs/concepts/scheduling-eviction/node-pressure-eviction/). diff --git a/content/en/docs/concepts/policy/pod-security-policy.md b/content/en/docs/concepts/policy/pod-security-policy.md index f355a8f539..36172faba5 100644 --- a/content/en/docs/concepts/policy/pod-security-policy.md +++ b/content/en/docs/concepts/policy/pod-security-policy.md @@ -9,7 +9,10 @@ weight: 30 -{{< feature-state state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} + +PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25. For more information on the deprecation, +see [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). Pod Security Policies enable fine-grained authorization of pod creation and updates. @@ -46,13 +49,12 @@ administrator to control the following: ## Enabling Pod Security Policies -Pod security policy control is implemented as an optional (but recommended) -[admission -controller](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy). PodSecurityPolicies -are enforced by [enabling the admission +Pod security policy control is implemented as an optional [admission +controller](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy). +PodSecurityPolicies are enforced by [enabling the admission controller](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in), -but doing so without authorizing any policies **will prevent any pods from being -created** in the cluster. +but doing so without authorizing any policies **will prevent any pods from being created** in the +cluster. Since the pod security policy API (`policy/v1beta1/podsecuritypolicy`) is enabled independently of the admission controller, for existing clusters it is @@ -108,7 +110,11 @@ roleRef: name: apiGroup: rbac.authorization.k8s.io subjects: -# Authorize specific service accounts: +# Authorize all service accounts in a namespace (recommended): +- kind: Group + apiGroup: rbac.authorization.k8s.io + name: system:serviceaccounts: +# Authorize specific service accounts (not recommended): - kind: ServiceAccount name: namespace: @@ -137,6 +143,40 @@ Examples](/docs/reference/access-authn-authz/rbac#role-binding-examples). For a complete example of authorizing a PodSecurityPolicy, see [below](#example). +### Recommended Practice + +PodSecurityPolicy is being replaced by a new, simplified `PodSecurity` {{< glossary_tooltip +text="admission controller" term_id="admission-controller" >}}. For more details on this change, see +[PodSecurityPolicy Deprecation: Past, Present, and +Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). Follow these +guidelines to simplify migration from PodSecurityPolicy to the new admission controller: + +1. Limit your PodSecurityPolicies to the policies defined by the [Pod Security Standards](/docs/concepts/security/pod-security-standards): + - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}} + - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}} + - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}} + +2. Only bind PSPs to entire namespaces, by using the `system:serviceaccounts:` group + (where `` is the target namespace). For example: + + ```yaml + apiVersion: rbac.authorization.k8s.io/v1 + # This cluster role binding allows all pods in the "development" namespace to use the baseline PSP. + kind: ClusterRoleBinding + metadata: + name: psp-baseline-namespaces + roleRef: + kind: ClusterRole + name: psp-baseline + apiGroup: rbac.authorization.k8s.io + subjects: + - kind: Group + name: system:serviceaccounts:development + apiGroup: rbac.authorization.k8s.io + - kind: Group + name: system:serviceaccounts:canary + apiGroup: rbac.authorization.k8s.io + ``` ### Troubleshooting @@ -462,12 +502,12 @@ allowed prefix, and a `readOnly` field indicating it must be mounted read-only. For example: ```yaml -allowedHostPaths: - # This allows "/foo", "/foo/", "/foo/bar" etc., but - # disallows "/fool", "/etc/foo" etc. - # "/foo/../" is never valid. - - pathPrefix: "/foo" - readOnly: true # only allow read-only mounts + allowedHostPaths: + # This allows "/foo", "/foo/", "/foo/bar" etc., but + # disallows "/fool", "/etc/foo" etc. + # "/foo/../" is never valid. + - pathPrefix: "/foo" + readOnly: true # only allow read-only mounts ``` {{< warning >}}There are many ways a container with unrestricted access to the host @@ -659,8 +699,10 @@ Refer to the [Sysctl documentation]( ## {{% heading "whatsnext" %}} +- See [PodSecurityPolicy Deprecation: Past, Present, and + Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/) to learn about + the future of pod security policy. + - See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) for policy recommendations. - Refer to [Pod Security Policy Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) for the api details. - - diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md index bc5eca8754..d31efd09bc 100644 --- a/content/en/docs/concepts/policy/resource-quotas.md +++ b/content/en/docs/concepts/policy/resource-quotas.md @@ -57,8 +57,9 @@ Neither contention nor changes to quota will affect already created resources. ## Enabling Resource Quota -Resource Quota support is enabled by default for many Kubernetes distributions. It is -enabled when the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} `--enable-admission-plugins=` flag has `ResourceQuota` as +Resource Quota support is enabled by default for many Kubernetes distributions. It is +enabled when the {{< glossary_tooltip text="API server" term_id="kube-apiserver" >}} +`--enable-admission-plugins=` flag has `ResourceQuota` as one of its arguments. A resource quota is enforced in a particular namespace when there is a @@ -66,7 +67,9 @@ ResourceQuota in that namespace. ## Compute Resource Quota -You can limit the total sum of [compute resources](/docs/concepts/configuration/manage-resources-containers/) that can be requested in a given namespace. +You can limit the total sum of +[compute resources](/docs/concepts/configuration/manage-resources-containers/) +that can be requested in a given namespace. The following resource types are supported: @@ -124,6 +127,12 @@ In release 1.8, quota support for local ephemeral storage is added as an alpha f | `limits.ephemeral-storage` | Across all pods in the namespace, the sum of local ephemeral storage limits cannot exceed this value. | | `ephemeral-storage` | Same as `requests.ephemeral-storage`. | +{{< note >}} +When using a CRI container runtime, container logs will count against the ephemeral storage quota. +This can result in the unexpected eviction of pods that have exhausted their storage quotas. +Refer to [Logging Architecture](/docs/concepts/cluster-administration/logging/) for details. +{{< /note >}} + ## Object Count Quota You can set quota for the total number of certain resources of all standard, @@ -188,7 +197,8 @@ Resources specified on the quota outside of the allowed set results in a validat | `NotTerminating` | Match pods where `.spec.activeDeadlineSeconds is nil` | | `BestEffort` | Match pods that have best effort quality of service. | | `NotBestEffort` | Match pods that do not have best effort quality of service. | -| `PriorityClass` | Match pods that references the specified [priority class](/docs/concepts/configuration/pod-priority-preemption). | +| `PriorityClass` | Match pods that references the specified [priority class](/docs/concepts/scheduling-eviction/pod-priority-preemption). | +| `CrossNamespacePodAffinity` | Match pods that have cross-namespace pod [(anti)affinity terms](/docs/concepts/scheduling-eviction/assign-pod-node). | The `BestEffort` scope restricts a quota to tracking the following resource: @@ -243,13 +253,14 @@ specified. {{< feature-state for_k8s_version="v1.17" state="stable" >}} -Pods can be created at a specific [priority](/docs/concepts/configuration/pod-priority-preemption/#pod-priority). +Pods can be created at a specific [priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority). You can control a pod's consumption of system resources based on a pod's priority, by using the `scopeSelector` field in the quota spec. A quota is matched and consumed only if `scopeSelector` in the quota spec selects the pod. -When quota is scoped for priority class using `scopeSelector` field, quota object is restricted to track only following resources: +When quota is scoped for priority class using `scopeSelector` field, quota object +is restricted to track only following resources: * `pods` * `cpu` @@ -429,6 +440,63 @@ memory 0 20Gi pods 0 10 ``` +### Cross-namespace Pod Affinity Quota + +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +Operators can use `CrossNamespacePodAffinity` quota scope to limit which namespaces are allowed to +have pods with affinity terms that cross namespaces. Specifically, it controls which pods are allowed +to set `namespaces` or `namespaceSelector` fields in pod affinity terms. + +Preventing users from using cross-namespace affinity terms might be desired since a pod +with anti-affinity constraints can block pods from all other namespaces +from getting scheduled in a failure domain. + +Using this scope operators can prevent certain namespaces (`foo-ns` in the example below) +from having pods that use cross-namespace pod affinity by creating a resource quota object in +that namespace with `CrossNamespaceAffinity` scope and hard limit of 0: + +```yaml +apiVersion: v1 +kind: ResourceQuota +metadata: + name: disable-cross-namespace-affinity + namespace: foo-ns +spec: + hard: + pods: "0" + scopeSelector: + matchExpressions: + - scopeName: CrossNamespaceAffinity +``` + +If operators want to disallow using `namespaces` and `namespaceSelector` by default, and +only allow it for specific namespaces, they could configure `CrossNamespaceAffinity` +as a limited resource by setting the kube-apiserver flag --admission-control-config-file +to the path of the following configuration file: + +```yaml +apiVersion: apiserver.config.k8s.io/v1 +kind: AdmissionConfiguration +plugins: +- name: "ResourceQuota" + configuration: + apiVersion: apiserver.config.k8s.io/v1 + kind: ResourceQuotaConfiguration + limitedResources: + - resource: pods + matchScopes: + - scopeName: CrossNamespaceAffinity +``` + +With the above configuration, pods can use `namespaces` and `namespaceSelector` in pod affinity only +if the namespace where they are created have a resource quota object with +`CrossNamespaceAffinity` scope and a hard limit greater than or equal to the number of pods using those fields. + +This feature is beta and enabled by default. You can disable it using the +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +`PodAffinityNamespaceSelector` in both kube-apiserver and kube-scheduler. + ## Requests compared to Limits {#requests-vs-limits} When allocating compute resources, each container may specify a request and a limit value for either CPU or memory. @@ -492,7 +560,7 @@ kubectl create -f ./object-counts.yaml --namespace=myspace kubectl get quota --namespace=myspace ``` -``` +```none NAME AGE compute-resources 30s object-counts 32s @@ -502,7 +570,7 @@ object-counts 32s kubectl describe quota compute-resources --namespace=myspace ``` -``` +```none Name: compute-resources Namespace: myspace Resource Used Hard @@ -518,7 +586,7 @@ requests.nvidia.com/gpu 0 4 kubectl describe quota object-counts --namespace=myspace ``` -``` +```none Name: object-counts Namespace: myspace Resource Used Hard @@ -615,10 +683,10 @@ Then, create a resource quota object in the `kube-system` namespace: {{< codenew file="policy/priority-class-resourcequota.yaml" >}} ```shell -$ kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system +kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system ``` -``` +```none resourcequota/pods-cluster-services created ``` diff --git a/content/en/docs/concepts/scheduling-eviction/_index.md b/content/en/docs/concepts/scheduling-eviction/_index.md index 3a2bf9359f..21e9371f03 100644 --- a/content/en/docs/concepts/scheduling-eviction/_index.md +++ b/content/en/docs/concepts/scheduling-eviction/_index.md @@ -1,8 +1,37 @@ --- -title: "Scheduling and Eviction" +title: "Scheduling, Preemption and Eviction" weight: 90 +content_type: concept description: > - In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes so that the kubelet can run them. - Eviction is the process of proactively failing one or more Pods on resource-starved Nodes. + In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes + so that the kubelet can run them. Preemption is the process of terminating + Pods with lower Priority so that Pods with higher Priority can schedule on + Nodes. Eviction is the process of proactively terminating one or more Pods on + resource-starved Nodes. +no_list: true --- +In Kubernetes, scheduling refers to making sure that {{}} +are matched to {{}} so that the +{{}} can run them. Preemption +is the process of terminating Pods with lower {{}} +so that Pods with higher Priority can schedule on Nodes. Eviction is the process +of terminating one or more Pods on Nodes. + +## Scheduling + +* [Kubernetes Scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/) +* [Assigning Pods to Nodes](/docs/concepts/scheduling-eviction/assign-pod-node/) +* [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/) +* [Taints and Tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) +* [Scheduling Framework](/docs/concepts/scheduling-eviction/scheduling-framework) +* [Scheduler Performance Tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) +* [Resource Bin Packing for Extended Resources](/docs/concepts/scheduling-eviction/resource-bin-packing/) + +## Pod Disruption + +{{}} + +* [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) +* [API-initiated Eviction](/docs/concepts/scheduling-eviction/api-eviction/) diff --git a/content/en/docs/concepts/scheduling-eviction/api-eviction.md b/content/en/docs/concepts/scheduling-eviction/api-eviction.md new file mode 100644 index 0000000000..e7f1942df2 --- /dev/null +++ b/content/en/docs/concepts/scheduling-eviction/api-eviction.md @@ -0,0 +1,19 @@ +--- +title: API-initiated Eviction +content_type: concept +weight: 70 +--- + +{{< glossary_definition term_id="api-eviction" length="short" >}}
+ +You can request eviction by directly calling the Eviction API +using a client of the kube-apiserver, like the `kubectl drain` command. +This creates an `Eviction` object, which causes the API server to terminate the Pod. + +API-initiated evictions respect your configured [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) +and [`terminationGracePeriodSeconds`](/docs/concepts/workloads/pods/pod-lifecycle#pod-termination). + +## {{% heading "whatsnext" %}} + +* Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) +* Learn about [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/) diff --git a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md index c2c332afb0..9216ec2ff9 100644 --- a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -72,7 +72,7 @@ verify that it worked by running `kubectl get pods -o wide` and looking at the ## Interlude: built-in node labels {#built-in-node-labels} In addition to labels you [attach](#step-one-attach-label-to-the-node), nodes come pre-populated -with a standard set of labels. See [Well-Known Labels, Annotations and Taints](/docs/reference/kubernetes-api/labels-annotations-taints/) for a list of these. +with a standard set of labels. See [Well-Known Labels, Annotations and Taints](/docs/reference/labels-annotations-taints/) for a list of these. {{< note >}} The value of these labels is cloud provider specific and is not guaranteed to be reliable. @@ -270,6 +270,18 @@ If omitted or empty, it defaults to the namespace of the pod where the affinity/ All `matchExpressions` associated with `requiredDuringSchedulingIgnoredDuringExecution` affinity and anti-affinity must be satisfied for the pod to be scheduled onto a node. +#### Namespace selector +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +Users can also select matching namespaces using `namespaceSelector`, which is a label query over the set of namespaces. +The affinity term is applied to the union of the namespaces selected by `namespaceSelector` and the ones listed in the `namespaces` field. +Note that an empty `namespaceSelector` ({}) matches all namespaces, while a null or empty `namespaces` list and +null `namespaceSelector` means "this pod's namespace". + +This feature is beta and enabled by default. You can disable it via the +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +`PodAffinityNamespaceSelector` in both kube-apiserver and kube-scheduler. + #### More Practical Use-cases Interpod Affinity and AntiAffinity can be even more useful when they are used with higher diff --git a/content/en/docs/concepts/scheduling-eviction/eviction-policy.md b/content/en/docs/concepts/scheduling-eviction/eviction-policy.md deleted file mode 100644 index b63c729696..0000000000 --- a/content/en/docs/concepts/scheduling-eviction/eviction-policy.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Eviction Policy -content_type: concept -weight: 60 ---- - - - -This page is an overview of Kubernetes' policy for eviction. - - - -## Eviction Policy - -The {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} proactively monitors for -and prevents total starvation of a compute resource. In those cases, the `kubelet` can reclaim -the starved resource by failing one or more Pods. When the `kubelet` fails -a Pod, it terminates all of its containers and transitions its `PodPhase` to `Failed`. -If the evicted Pod is managed by a Deployment, the Deployment creates another Pod -to be scheduled by Kubernetes. - -## {{% heading "whatsnext" %}} - -- Learn how to [configure out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) with eviction signals and thresholds. diff --git a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md index 0944ecc768..916f050513 100644 --- a/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/en/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -47,7 +47,7 @@ functions to score the feasible Nodes and picks a Node with the highest score among the feasible ones to run the Pod. The scheduler then notifies the API server about this decision in a process called _binding_. -Factors that need taken into account for scheduling decisions include +Factors that need to be taken into account for scheduling decisions include individual and collective resource requirements, hardware / software / policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, and so on. @@ -77,17 +77,15 @@ one of these at random. There are two supported ways to configure the filtering and scoring behavior of the scheduler: - 1. [Scheduling Policies](/docs/reference/scheduling/policies) allow you to configure _Predicates_ for filtering and _Priorities_ for scoring. 1. [Scheduling Profiles](/docs/reference/scheduling/config/#profiles) allow you to configure Plugins that implement different scheduling stages, including: `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit`, and others. You can also configure the kube-scheduler to run different profiles. - ## {{% heading "whatsnext" %}} * Read about [scheduler performance tuning](/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) * Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/) * Read the [reference documentation](/docs/reference/command-line-tools-reference/kube-scheduler/) for kube-scheduler -* Read the [kube-scheduler config (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) reference +* Read the [kube-scheduler config (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) reference * Learn about [configuring multiple schedulers](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) * Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/) * Learn about [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/) diff --git a/content/en/docs/concepts/scheduling-eviction/node-pressure-eviction.md b/content/en/docs/concepts/scheduling-eviction/node-pressure-eviction.md new file mode 100644 index 0000000000..e832d1d48c --- /dev/null +++ b/content/en/docs/concepts/scheduling-eviction/node-pressure-eviction.md @@ -0,0 +1,411 @@ +--- +title: Node-pressure Eviction +content_type: concept +weight: 60 +--- + +{{}}
+ +The {{}} monitors resources +like CPU, memory, disk space, and filesystem inodes on your cluster's nodes. +When one or more of these resources reach specific consumption levels, the +kubelet can proactively fail one or more pods on the node to reclaim resources +and prevent starvation. + +During a node-pressure eviction, the kubelet sets the `PodPhase` for the +selected pods to `Failed`. This terminates the pods. + +Node-pressure eviction is not the same as +[API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/). + +The kubelet does not respect your configured `PodDisruptionBudget` or the pod's +`terminationGracePeriodSeconds`. If you use [soft eviction thresholds](#soft-eviction-thresholds), +the kubelet respects your configured `eviction-max-pod-grace-period`. If you use +[hard eviction thresholds](#hard-eviction-thresholds), it uses a `0s` grace period for termination. + +If the pods are managed by a {{< glossary_tooltip text="workload" term_id="workload" >}} +resource (such as {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} +or {{< glossary_tooltip text="Deployment" term_id="deployment" >}}) that +replaces failed pods, the control plane or `kube-controller-manager` creates new +pods in place of the evicted pods. + +{{}} +The kubelet attempts to [reclaim node-level resources](#reclaim-node-resources) +before it terminates end-user pods. For example, it removes unused container +images when disk resources are starved. +{{}} + +The kubelet uses various parameters to make eviction decisions, like the following: + + * Eviction signals + * Eviction thresholds + * Monitoring intervals + +### Eviction signals {#eviction-signals} + +Eviction signals are the current state of a particular resource at a specific +point in time. Kubelet uses eviction signals to make eviction decisions by +comparing the signals to eviction thresholds, which are the minimum amount of +the resource that should be available on the node. + +Kubelet uses the following eviction signals: + +| Eviction Signal | Description | +|----------------------|---------------------------------------------------------------------------------------| +| `memory.available` | `memory.available` := `node.status.capacity[memory]` - `node.stats.memory.workingSet` | +| `nodefs.available` | `nodefs.available` := `node.stats.fs.available` | +| `nodefs.inodesFree` | `nodefs.inodesFree` := `node.stats.fs.inodesFree` | +| `imagefs.available` | `imagefs.available` := `node.stats.runtime.imagefs.available` | +| `imagefs.inodesFree` | `imagefs.inodesFree` := `node.stats.runtime.imagefs.inodesFree` | +| `pid.available` | `pid.available` := `node.stats.rlimit.maxpid` - `node.stats.rlimit.curproc` | + +In this table, the `Description` column shows how kubelet gets the value of the +signal. Each signal supports either a percentage or a literal value. Kubelet +calculates the percentage value relative to the total capacity associated with +the signal. + +The value for `memory.available` is derived from the cgroupfs instead of tools +like `free -m`. This is important because `free -m` does not work in a +container, and if users use the [node +allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) feature, out of resource decisions +are made local to the end user Pod part of the cgroup hierarchy as well as the +root node. This [script](/examples/admin/resource/memory-available.sh) +reproduces the same set of steps that the kubelet performs to calculate +`memory.available`. The kubelet excludes inactive_file (i.e. # of bytes of +file-backed memory on inactive LRU list) from its calculation as it assumes that +memory is reclaimable under pressure. + +The kubelet supports the following filesystem partitions: + +1. `nodefs`: The node's main filesystem, used for local disk volumes, emptyDir, + log storage, and more. For example, `nodefs` contains `/var/lib/kubelet/`. +1. `imagefs`: An optional filesystem that container runtimes use to store container + images and container writable layers. + +Kubelet auto-discovers these filesystems and ignores other filesystems. Kubelet +does not support other configurations. + +{{}} +Some kubelet garbage collection features are deprecated in favor of eviction. +For a list of the deprecated features, see [kubelet garbage collection deprecation](/docs/concepts/cluster-administration/kubelet-garbage-collection/#deprecation). +{{}} + +### Eviction thresholds + +You can specify custom eviction thresholds for the kubelet to use when it makes +eviction decisions. + +Eviction thresholds have the form `[eviction-signal][operator][quantity]`, where: + +* `eviction-signal` is the [eviction signal](#eviction-signals) to use. +* `operator` is the [relational operator](https://en.wikipedia.org/wiki/Relational_operator#Standard_relational_operators) + you want, such as `<` (less than). +* `quantity` is the eviction threshold amount, such as `1Gi`. The value of `quantity` + must match the quantity representation used by Kubernetes. You can use either + literal values or percentages (`%`). + +For example, if a node has `10Gi` of total memory and you want trigger eviction if +the available memory falls below `1Gi`, you can define the eviction threshold as +either `memory.available<10%` or `memory.available<1Gi`. You cannot use both. + +You can configure soft and hard eviction thresholds. + +#### Soft eviction thresholds {#soft-eviction-thresholds} + +A soft eviction threshold pairs an eviction threshold with a required +administrator-specified grace period. The kubelet does not evict pods until the +grace period is exceeded. The kubelet returns an error on startup if there is no +specified grace period. + +You can specify both a soft eviction threshold grace period and a maximum +allowed pod termination grace period for kubelet to use during evictions. If you +specify a maximum allowed grace period and the soft eviction threshold is met, +the kubelet uses the lesser of the two grace periods. If you do not specify a +maximum allowed grace period, the kubelet kills evicted pods immediately without +graceful termination. + +You can use the following flags to configure soft eviction thresholds: + +* `eviction-soft`: A set of eviction thresholds like `memory.available<1.5Gi` + that can trigger pod eviction if held over the specified grace period. +* `eviction-soft-grace-period`: A set of eviction grace periods like `memory.available=1m30s` + that define how long a soft eviction threshold must hold before triggering a Pod eviction. +* `eviction-max-pod-grace-period`: The maximum allowed grace period (in seconds) + to use when terminating pods in response to a soft eviction threshold being met. + +#### Hard eviction thresholds {#hard-eviction-thresholds} + +A hard eviction threshold has no grace period. When a hard eviction threshold is +met, the kubelet kills pods immediately without graceful termination to reclaim +the starved resource. + +You can use the `eviction-hard` flag to configure a set of hard eviction +thresholds like `memory.available<1Gi`. + +The kubelet has the following default hard eviction thresholds: + +* `memory.available<100Mi` +* `nodefs.available<10%` +* `imagefs.available<15%` +* `nodefs.inodesFree<5%` (Linux nodes) + +### Eviction monitoring interval + +The kubelet evaluates eviction thresholds based on its configured `housekeeping-interval` +which defaults to `10s`. + +### Node conditions {#node-conditions} + +The kubelet reports node conditions to reflect that the node is under pressure +because hard or soft eviction threshold is met, independent of configured grace +periods. + +The kubelet maps eviction signals to node conditions as follows: + +| Node Condition | Eviction Signal | Description | +|-------------------|---------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------| +| `MemoryPressure` | `memory.available` | Available memory on the node has satisfied an eviction threshold | +| `DiskPressure` | `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, or `imagefs.inodesFree` | Available disk space and inodes on either the node's root filesystem or image filesystem has satisfied an eviction threshold | +| `PIDPressure` | `pid.available` | Available processes identifiers on the (Linux) node has fallen below an eviction threshold | + +The kubelet updates the node conditions based on the configured +`--node-status-update-frequency`, which defaults to `10s`. + +#### Node condition oscillation + +In some cases, nodes oscillate above and below soft eviction thresholds without +holding for the defined grace periods. This causes the reported node condition +to constantly switch between `true` and `false`, leading to bad eviction decisions. + +To protect against oscillation, you can use the `eviction-pressure-transition-period` +flag, which controls how long the kubelet must wait before transitioning a node +condition to a different state. The transition period has a default value of `5m`. + +### Reclaiming node level resources {#reclaim-node-resources} + +The kubelet tries to reclaim node-level resources before it evicts end-user pods. + +When a `DiskPressure` node condition is reported, the kubelet reclaims node-level +resources based on the filesystems on the node. + +#### With `imagefs` + +If the node has a dedicated `imagefs` filesystem for container runtimes to use, +the kubelet does the following: + + * If the `nodefs` filesystem meets the eviction thresholds, the kubelet garbage collects + dead pods and containers. + * If the `imagefs` filesystem meets the eviction thresholds, the kubelet + deletes all unused images. + +#### Without `imagefs` + +If the node only has a `nodefs` filesystem that meets eviction thresholds, +the kubelet frees up disk space in the following order: + +1. Garbage collect dead pods and containers +1. Delete unused images + +### Pod selection for kubelet eviction + +If the kubelet's attempts to reclaim node-level resources don't bring the eviction +signal below the threshold, the kubelet begins to evict end-user pods. + +The kubelet uses the following parameters to determine pod eviction order: + +1. Whether the pod's resource usage exceeds requests +1. [Pod Priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/) +1. The pod's resource usage relative to requests + +As a result, kubelet ranks and evicts pods in the following order: + +1. `BestEffort` or `Burstable` pods where the usage exceeds requests. These pods + are evicted based on their Priority and then by how much their usage level + exceeds the request. +1. `Guaranteed` pods and `Burstable` pods where the usage is less than requests + are evicted last, based on their Priority. + +{{}} +The kubelet does not use the pod's QoS class to determine the eviction order. +You can use the QoS class to estimate the most likely pod eviction order when +reclaiming resources like memory. QoS does not apply to EphemeralStorage requests, +so the above scenario will not apply if the node is, for example, under `DiskPressure`. +{{}} + +`Guaranteed` pods are guaranteed only when requests and limits are specified for +all the containers and they are equal. These pods will never be evicted because +of another pod's resource consumption. If a system daemon (such as `kubelet`, +`docker`, and `journald`) is consuming more resources than were reserved via +`system-reserved` or `kube-reserved` allocations, and the node only has +`Guaranteed` or `Burstable` pods using less resources than requests left on it, +then the kubelet must choose to evict one of these pods to preserve node stability +and to limit the impact of resource starvation on other pods. In this case, it +will choose to evict pods of lowest Priority first. + +When the kubelet evicts pods in response to `inode` or `PID` starvation, it uses +the Priority to determine the eviction order, because `inodes` and `PIDs` have no +requests. + +The kubelet sorts pods differently based on whether the node has a dedicated +`imagefs` filesystem: + +#### With `imagefs` + +If `nodefs` is triggering evictions, the kubelet sorts pods based on `nodefs` +usage (`local volumes + logs of all containers`). + +If `imagefs` is triggering evictions, the kubelet sorts pods based on the +writable layer usage of all containers. + +#### Without `imagefs` + +If `nodefs` is triggering evictions, the kubelet sorts pods based on their total +disk usage (`local volumes + logs & writable layer of all containers`) + +### Minimum eviction reclaim + +In some cases, pod eviction only reclaims a small amount of the starved resource. +This can lead to the kubelet repeatedly hitting the configured eviction thresholds +and triggering multiple evictions. + +You can use the `--eviction-minimum-reclaim` flag or a [kubelet config file](/docs/tasks/administer-cluster/kubelet-config-file/) +to configure a minimum reclaim amount for each resource. When the kubelet notices +that a resource is starved, it continues to reclaim that resource until it +reclaims the quantity you specify. + +For example, the following configuration sets minimum reclaim amounts: + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +evictionHard: + memory.available: "500Mi" + nodefs.available: "1Gi" + imagefs.available: "100Gi" +evictionMinimumReclaim: + memory.available: "0Mi" + nodefs.available: "500Mi" + imagefs.available: "2Gi" +``` + +In this example, if the `nodefs.available` signal meets the eviction threshold, +the kubelet reclaims the resource until the signal reaches the threshold of `1Gi`, +and then continues to reclaim the minimum amount of `500Mi` it until the signal +reaches `1.5Gi`. + +Similarly, the kubelet reclaims the `imagefs` resource until the `imagefs.available` +signal reaches `102Gi`. + +The default `eviction-minimum-reclaim` is `0` for all resources. + +### Node out of memory behavior + +If the node experiences an out of memory (OOM) event prior to the kubelet +being able to reclaim memory, the node depends on the [oom_killer](https://lwn.net/Articles/391222/) +to respond. + +The kubelet sets an `oom_score_adj` value for each container based on the QoS for the pod. + +| Quality of Service | oom_score_adj | +|--------------------|-----------------------------------------------------------------------------------| +| `Guaranteed` | -997 | +| `BestEffort` | 1000 | +| `Burstable` | min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) | + +{{}} +The kubelet also sets an `oom_score_adj` value of `-997` for containers in Pods that have +`system-node-critical` {{}} +{{}} + +If the kubelet can't reclaim memory before a node experiences OOM, the +`oom_killer` calculates an `oom_score` based on the percentage of memory it's +using on the node, and then adds the `oom_score_adj` to get an effective `oom_score` +for each container. It then kills the container with the highest score. + +This means that containers in low QoS pods that consume a large amount of memory +relative to their scheduling requests are killed first. + +Unlike pod eviction, if a container is OOM killed, the `kubelet` can restart it +based on its `RestartPolicy`. + +### Best practices {#node-pressure-eviction-good-practices} + +The following sections describe best practices for eviction configuration. + +#### Schedulable resources and eviction policies + +When you configure the kubelet with an eviction policy, you should make sure that +the scheduler will not schedule pods if they will trigger eviction because they +immediately induce memory pressure. + +Consider the following scenario: + +* Node memory capacity: `10Gi` +* Operator wants to reserve 10% of memory capacity for system daemons (kernel, `kubelet`, etc.) +* Operator wants to evict Pods at 95% memory utilization to reduce incidence of system OOM. + +For this to work, the kubelet is launched as follows: + +``` +--eviction-hard=memory.available<500Mi +--system-reserved=memory=1.5Gi +``` + +In this configuration, the `--system-reserved` flag reserves `1.5Gi` of memory +for the system, which is `10% of the total memory + the eviction threshold amount`. + +The node can reach the eviction threshold if a pod is using more than its request, +or if the system is using more than `1Gi` of memory, which makes the `memory.available` +signal fall below `500Mi` and triggers the threshold. + +#### DaemonSet + +Pod Priority is a major factor in making eviction decisions. If you do not want +the kubelet to evict pods that belong to a `DaemonSet`, give those pods a high +enough `priorityClass` in the pod spec. You can also use a lower `priorityClass` +or the default to only allow `DaemonSet` pods to run when there are enough +resources. + +### Known issues + +The following sections describe known issues related to out of resource handling. + +#### kubelet may not observe memory pressure right away + +By default, the kubelet polls `cAdvisor` to collect memory usage stats at a +regular interval. If memory usage increases within that window rapidly, the +kubelet may not observe `MemoryPressure` fast enough, and the `OOMKiller` +will still be invoked. + +You can use the `--kernel-memcg-notification` flag to enable the `memcg` +notification API on the kubelet to get notified immediately when a threshold +is crossed. + +If you are not trying to achieve extreme utilization, but a sensible measure of +overcommit, a viable workaround for this issue is to use the `--kube-reserved` +and `--system-reserved` flags to allocate memory for the system. + +#### active_file memory is not considered as available memory + +On Linux, the kernel tracks the number of bytes of file-backed memory on active +LRU list as the `active_file` statistic. The kubelet treats `active_file` memory +areas as not reclaimable. For workloads that make intensive use of block-backed +local storage, including ephemeral local storage, kernel-level caches of file +and block data means that many recently accessed cache pages are likely to be +counted as `active_file`. If enough of these kernel block buffers are on the +active LRU list, the kubelet is liable to observe this as high resource use and +taint the node as experiencing memory pressure - triggering pod eviction. + +For more more details, see [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916) + +You can work around that behavior by setting the memory limit and memory request +the same for containers likely to perform intensive I/O activity. You will need +to estimate or measure an optimal memory limit value for that container. + +## {{% heading "whatsnext" %}} + +* Learn about [API-initiated Eviction](/docs/concepts/scheduling-eviction/api-eviction/) +* Learn about [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* Learn about [PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) +* Learn about [Quality of Service](/docs/tasks/configure-pod-container/quality-service-pod/) (QoS) +* Check out the [Eviction API](/docs/reference/generated/kubernetes-api/{{}}/#create-eviction-pod-v1-core) diff --git a/content/en/docs/concepts/scheduling-eviction/pod-overhead.md b/content/en/docs/concepts/scheduling-eviction/pod-overhead.md index 15992126f9..eebc235084 100644 --- a/content/en/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/en/docs/concepts/scheduling-eviction/pod-overhead.md @@ -5,7 +5,7 @@ reviewers: - tallclair title: Pod Overhead content_type: concept -weight: 50 +weight: 30 --- diff --git a/content/en/docs/concepts/configuration/pod-priority-preemption.md b/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md similarity index 91% rename from content/en/docs/concepts/configuration/pod-priority-preemption.md rename to content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md index d6acc80a71..fff925b6c5 100644 --- a/content/en/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -4,7 +4,7 @@ reviewers: - wojtek-t title: Pod Priority and Preemption content_type: concept -weight: 70 +weight: 50 --- @@ -252,12 +252,12 @@ Even so, the answer to the preceding question must be yes. If the answer is no, the Node is not considered for preemption. {{< /note >}} -If a pending Pod has inter-pod affinity to one or more of the lower-priority -Pods on the Node, the inter-Pod affinity rule cannot be satisfied in the absence -of those lower-priority Pods. In this case, the scheduler does not preempt any -Pods on the Node. Instead, it looks for another Node. The scheduler might find a -suitable Node or it might not. There is no guarantee that the pending Pod can be -scheduled. +If a pending Pod has inter-pod {{< glossary_tooltip text="affinity" term_id="affinity" >}} +to one or more of the lower-priority Pods on the Node, the inter-Pod affinity +rule cannot be satisfied in the absence of those lower-priority Pods. In this case, +the scheduler does not preempt any Pods on the Node. Instead, it looks for another +Node. The scheduler might find a suitable Node or it might not. There is no +guarantee that the pending Pod can be scheduled. Our recommended solution for this problem is to create inter-Pod affinity only towards equal or higher priority Pods. @@ -353,22 +353,25 @@ the removal of the lowest priority Pods is not sufficient to allow the scheduler to schedule the preemptor Pod, or if the lowest priority Pods are protected by `PodDisruptionBudget`. -The only component that considers both QoS and Pod priority is -[kubelet out-of-resource eviction](/docs/tasks/administer-cluster/out-of-resource/). -The kubelet ranks Pods for eviction first by whether or not their usage of the -starved resource exceeds requests, then by Priority, and then by the consumption -of the starved compute resource relative to the Pods' scheduling requests. -See -[evicting end-user pods](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods) +The kubelet uses Priority to determine pod order for [node-pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/). +You can use the QoS class to estimate the order in which pods are most likely +to get evicted. The kubelet ranks pods for eviction based on the following factors: + + 1. Whether the starved resource usage exceeds requests + 1. Pod Priority + 1. Amount of resource usage relative to requests + +See [Pod selection for kubelet eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction) for more details. -kubelet out-of-resource eviction does not evict Pods when their +kubelet node-pressure eviction does not evict Pods when their usage does not exceed their requests. If a Pod with lower priority is not exceeding its requests, it won't be evicted. Another Pod with higher priority that exceeds its requests may be evicted. - ## {{% heading "whatsnext" %}} * Read about using ResourceQuotas in connection with PriorityClasses: [limit Priority Class consumption by default](/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) - +* Learn about [Pod Disruption](/docs/concepts/workloads/pods/disruptions/) +* Learn about [API-initiated Eviction](/docs/concepts/scheduling-eviction/api-eviction/) +* Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) diff --git a/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md index 94bfaa1280..17a426e35b 100644 --- a/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -5,7 +5,7 @@ reviewers: - ahg-g title: Resource Bin Packing for Extended Resources content_type: concept -weight: 30 +weight: 80 --- @@ -26,40 +26,41 @@ each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters and improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function -can be controlled by a configuration option called -`requestedToCapacityRatioArguments`. This argument consists of two parameters -`shape` and `resources`. The `shape` parameter allows the user to tune the -function as least requested or most requested based on `utilization` and -`score` values. The `resources` parameter consists of `name` of the resource -to be considered during scoring and `weight` specify the weight of each -resource. +can be controlled by a configuration option called `RequestedToCapacityRatioArgs`. +This argument consists of two parameters `shape` and `resources`. The `shape` +parameter allows the user to tune the function as least requested or most +requested based on `utilization` and `score` values. The `resources` parameter +consists of `name` of the resource to be considered during scoring and `weight` +specify the weight of each resource. Below is an example configuration that sets `requestedToCapacityRatioArguments` to bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar`. ```yaml -apiVersion: v1 -kind: Policy +apiVersion: kubescheduler.config.k8s.io/v1beta1 +kind: KubeSchedulerConfiguration +profiles: # ... -priorities: - # ... - - name: RequestedToCapacityRatioPriority - weight: 2 - argument: - requestedToCapacityRatioArguments: - shape: - - utilization: 0 - score: 0 - - utilization: 100 - score: 10 - resources: - - name: intel.com/foo - weight: 3 - - name: intel.com/bar - weight: 5 + pluginConfig: + - name: RequestedToCapacityRatio + args: + shape: + - utilization: 0 + score: 10 + - utilization: 100 + score: 0 + resources: + - name: intel.com/foo + weight: 3 + - name: intel.com/bar + weight: 5 ``` +Referencing the `KubeSchedulerConfiguration` file with the kube-scheduler +flag `--config=/path/to/config/file` will pass the configuration to the +scheduler. + **This feature is disabled by default** ### Tuning the Priority Function @@ -91,9 +92,9 @@ shape: ``` yaml resources: - - name: CPU + - name: cpu weight: 1 - - name: Memory + - name: memory weight: 1 ``` @@ -103,9 +104,9 @@ It can be used to add extended resources as follows: resources: - name: intel.com/foo weight: 5 - - name: CPU + - name: cpu weight: 3 - - name: Memory + - name: memory weight: 1 ``` @@ -122,16 +123,16 @@ Requested resources: ``` intel.com/foo : 2 -Memory: 256MB -CPU: 2 +memory: 256MB +cpu: 2 ``` Resource weights: ``` intel.com/foo : 5 -Memory: 1 -CPU: 3 +memory: 1 +cpu: 3 ``` FunctionShapePoint {{0, 0}, {100, 10}} @@ -141,13 +142,13 @@ Node 1 spec: ``` Available: intel.com/foo: 4 - Memory: 1 GB - CPU: 8 + memory: 1 GB + cpu: 8 Used: intel.com/foo: 1 - Memory: 256MB - CPU: 1 + memory: 256MB + cpu: 1 ``` Node score: @@ -160,13 +161,13 @@ intel.com/foo = resourceScoringFunction((2+1),4) = rawScoringFunction(75) = 7 # floor(75/10) -Memory = resourceScoringFunction((256+256),1024) +memory = resourceScoringFunction((256+256),1024) = (100 -((1024-512)*100/1024)) = 50 # requested + used = 50% * available = rawScoringFunction(50) = 5 # floor(50/10) -CPU = resourceScoringFunction((2+1),8) +cpu = resourceScoringFunction((2+1),8) = (100 -((8-3)*100/8)) = 37.5 # requested + used = 37.5% * available = rawScoringFunction(37.5) @@ -181,12 +182,12 @@ Node 2 spec: ``` Available: intel.com/foo: 8 - Memory: 1GB - CPU: 8 + memory: 1GB + cpu: 8 Used: intel.com/foo: 2 - Memory: 512MB - CPU: 6 + memory: 512MB + cpu: 6 ``` Node score: @@ -199,13 +200,13 @@ intel.com/foo = resourceScoringFunction((2+2),8) = rawScoringFunction(50) = 5 -Memory = resourceScoringFunction((256+512),1024) +memory = resourceScoringFunction((256+512),1024) = (100 -((1024-768)*100/1024)) = 75 = rawScoringFunction(75) = 7 -CPU = resourceScoringFunction((2+6),8) +cpu = resourceScoringFunction((2+6),8) = (100 -((8-8)*100/8)) = 100 = rawScoringFunction(100) diff --git a/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 24283f2efa..5894398c9b 100644 --- a/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -3,7 +3,7 @@ reviewers: - bsalamat title: Scheduler Performance Tuning content_type: concept -weight: 80 +weight: 100 --- @@ -43,7 +43,7 @@ If you set `percentageOfNodesToScore` above 100, kube-scheduler acts as if you had set a value of 100. To change the value, edit the -[kube-scheduler configuration file](/docs/reference/config-api/kube-scheduler-config.v1beta1/) +[kube-scheduler configuration file](/docs/reference/config-api/kube-scheduler-config.v1beta2/) and then restart the scheduler. In many cases, the configuration file can be found at `/etc/kubernetes/config/kube-scheduler.yaml`. @@ -161,5 +161,5 @@ After going over all the Nodes, it goes back to Node 1. ## {{% heading "whatsnext" %}} -* Check the [kube-scheduler configuration reference (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) +* Check the [kube-scheduler configuration reference (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) diff --git a/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md index 06ed901c2a..e08052c017 100644 --- a/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -3,12 +3,12 @@ reviewers: - ahg-g title: Scheduling Framework content_type: concept -weight: 70 +weight: 90 --- -{{< feature-state for_k8s_version="v1.15" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="stable" >}} The scheduling framework is a pluggable architecture for the Kubernetes scheduler. It adds a new set of "plugin" APIs to the existing scheduler. Plugins are compiled into the scheduler. The APIs allow most scheduling features to be implemented as plugins, while keeping the diff --git a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md index 079024c9d6..030f28e7d1 100644 --- a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -10,7 +10,7 @@ weight: 40 -[_Node affinity_](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity), +[_Node affinity_](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attracts* them to a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a hard requirement). _Taints_ are the opposite -- they allow a node to repel a set of pods. @@ -210,9 +210,9 @@ are true. The following taints are built in: the NodeCondition `Ready` being "`False`". * `node.kubernetes.io/unreachable`: Node is unreachable from the node controller. This corresponds to the NodeCondition `Ready` being "`Unknown`". - * `node.kubernetes.io/out-of-disk`: Node becomes out of disk. * `node.kubernetes.io/memory-pressure`: Node has memory pressure. * `node.kubernetes.io/disk-pressure`: Node has disk pressure. + * `node.kubernetes.io/pid-pressure`: Node has PID pressure. * `node.kubernetes.io/network-unavailable`: Node's network is unavailable. * `node.kubernetes.io/unschedulable`: Node is unschedulable. * `node.cloudprovider.kubernetes.io/uninitialized`: When the kubelet is started @@ -266,26 +266,39 @@ This ensures that DaemonSet pods are never evicted due to these problems. ## Taint Nodes by Condition -The node lifecycle controller automatically creates taints corresponding to -Node conditions with `NoSchedule` effect. -Similarly the scheduler does not check Node conditions; instead the scheduler checks taints. This assures that Node conditions don't affect what's scheduled onto the Node. The user can choose to ignore some of the Node's problems (represented as Node conditions) by adding appropriate Pod tolerations. +The control plane, using the node {{}}, +automatically creates taints with a `NoSchedule` effect for [node conditions](/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions). + +The scheduler checks taints, not node conditions, when it makes scheduling +decisions. This ensures that node conditions don't directly affect scheduling. +For example, if the `DiskPressure` node condition is active, the control plane +adds the `node.kubernetes.io/disk-pressure` taint and does not schedule new pods +onto the affected node. If the `MemoryPressure` node condition is active, the +control plane adds the `node.kubernetes.io/memory-pressure` taint. + +You can ignore node conditions for newly created pods by adding the corresponding +Pod tolerations. The control plane also adds the `node.kubernetes.io/memory-pressure` +toleration on pods that have a {{< glossary_tooltip text="QoS class" term_id="qos-class" >}} +other than `BestEffort`. This is because Kubernetes treats pods in the `Guaranteed` +or `Burstable` QoS classes (even pods with no memory request set) as if they are +able to cope with memory pressure, while new `BestEffort` pods are not scheduled +onto the affected node. The DaemonSet controller automatically adds the following `NoSchedule` tolerations to all daemons, to prevent DaemonSets from breaking. * `node.kubernetes.io/memory-pressure` * `node.kubernetes.io/disk-pressure` - * `node.kubernetes.io/out-of-disk` (*only for critical pods*) + * `node.kubernetes.io/pid-pressure` (1.14 or later) * `node.kubernetes.io/unschedulable` (1.10 or later) * `node.kubernetes.io/network-unavailable` (*host network only*) Adding these tolerations ensures backward compatibility. You can also add arbitrary tolerations to DaemonSets. - ## {{% heading "whatsnext" %}} -* Read about [out of resource handling](/docs/tasks/administer-cluster/out-of-resource/) and how you can configure it -* Read about [pod priority](/docs/concepts/configuration/pod-priority-preemption/) +* Read about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) and how you can configure it +* Read about [Pod Priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/) diff --git a/content/en/docs/concepts/security/controlling-access.md b/content/en/docs/concepts/security/controlling-access.md index 9d6c2b9617..1a0c93d8cf 100644 --- a/content/en/docs/concepts/security/controlling-access.md +++ b/content/en/docs/concepts/security/controlling-access.md @@ -142,7 +142,7 @@ By default, the Kubernetes API server serves HTTP on 2 ports: - is intended for testing and bootstrap, and for other components of the master node (scheduler, controller-manager) to talk to the API - no TLS - - default is port 8080, change with `--insecure-port` flag. + - default is port 8080 - default IP is localhost, change with `--insecure-bind-address` flag. - request **bypasses** authentication and authorization modules. - request handled by admission control module(s). diff --git a/content/en/docs/concepts/security/overview.md b/content/en/docs/concepts/security/overview.md index b23a07c79a..0506fbbab0 100644 --- a/content/en/docs/concepts/security/overview.md +++ b/content/en/docs/concepts/security/overview.md @@ -2,8 +2,10 @@ reviewers: - zparnold title: Overview of Cloud Native Security +description: > + A model for thinking about Kubernetes security in the context of Cloud Native security. content_type: concept -weight: 10 +weight: 1 --- @@ -58,6 +60,7 @@ Amazon Web Services | https://aws.amazon.com/security/ | Google Cloud Platform | https://cloud.google.com/security/ | IBM Cloud | https://www.ibm.com/cloud/security | Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security | +Oracle Cloud Infrastructure | https://www.oracle.com/security/ | VMWare VSphere | https://www.vmware.com/security/hardening-guides.html | {{< /table >}} diff --git a/content/en/docs/concepts/security/pod-security-admission.md b/content/en/docs/concepts/security/pod-security-admission.md new file mode 100644 index 0000000000..a1c87767c9 --- /dev/null +++ b/content/en/docs/concepts/security/pod-security-admission.md @@ -0,0 +1,145 @@ +--- +reviewers: +- tallclair +- liggitt +title: Pod Security Admission +description: > + An overview of the Pod Security Admission Controller, which can enforce the Pod Security + Standards. +content_type: concept +weight: 20 +min-kubernetes-server-version: v1.22 +--- + + + +{{< feature-state for_k8s_version="v1.22" state="alpha" >}} + +The Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-standards/) define +different isolation levels for Pods. These standards let you define how you want to restrict the +behavior of pods in a clear, consistent fashion. + +As an Alpha feature, Kubernetes offers a built-in _Pod Security_ {{< glossary_tooltip +text="admission controller" term_id="admission-controller" >}}, the successor +to [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/). Pod security restrictions +are applied at the {{< glossary_tooltip text="namespace" term_id="namespace" >}} level when pods +are created. + +{{< note >}} +The PodSecurityPolicy API is deprecated and will be +[removed](/docs/reference/using-api/deprecation-guide/#v1-25) from Kubernetes in v1.25. +{{< /note >}} + + + +## Enabling the Alpha feature + +Setting pod security controls by namespace is an alpha feature. You must enable the `PodSecurity` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) in order to use it. + +```shell +--feature-gates="...,PodSecurity=true" +``` + +## Pod Security levels + +Pod Security admission places requirements on a Pod's [Security +Context](/docs/tasks/configure-pod-container/security-context/) and other related fields according +to the three levels defined by the [Pod Security +Standards](/docs/concepts/security/pod-security-standards): `privileged`, `baseline`, and +`restricted`. Refer to the [Pod Security Standards](/docs/concepts/security/pod-security-standards) +page for an in-depth look at those requirements. + +## Pod Security Admission labels for namespaces + +Provided that you have enabled this feature, you can configure namespaces to define the admission +control mode you want to use for pod security in each namespace. Kubernetes defines a set of +{{< glossary_tooltip term_id="label" text="labels" >}} that you can set to define which of the +predefined Pod Security Standard levels you want to use for a namespace. The label you select +defines what action the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} +takes if a potential violation is detected: + +{{< table caption="Pod Security Admission modes" >}} +Mode | Description +:---------|:------------ +**enforce** | Policy violations will cause the pod to be rejected. +**audit** | Policy violations will trigger the addition of an audit annotation to the event recorded in the [audit log](/docs/tasks/debug-application-cluster/audit/), but are otherwise allowed. +**warn** | Policy violations will trigger a user-facing warning, but are otherwise allowed. +{{< /table >}} + +A namespace can configure any or all modes, or even set a different level for different modes. + +For each mode, there are two labels that determine the policy used: + +```yaml +# The per-mode level label indicates which policy level to apply for the mode. +# +# MODE must be one of `enforce`, `audit`, or `warn`. +# LEVEL must be one of `privileged`, `baseline`, or `restricted`. +pod-security.kubernetes.io/: + +# Optional: per-mode version label that can be used to pin the policy to the +# version that shipped with a given Kubernetes minor version (for example v{{< skew latestVersion >}}). +# +# MODE must be one of `enforce`, `audit`, or `warn`. +# VERSION must be a valid Kubernetes minor version, or `latest`. +pod-security.kubernetes.io/-version: +``` + +Check out [Enforce Pod Security Standards with Namespace Labels](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels) to see example usage. + +## Workload resources and Pod templates + +Pods are often created indirectly, by creating a [workload +object](/docs/concepts/workloads/controllers/) such as a {{< glossary_tooltip +term_id="deployment" >}} or {{< glossary_tooltip term_id="job">}}. The workload object defines a +_Pod template_ and a {{< glossary_tooltip term_id="controller" text="controller" >}} for the +workload resource creates Pods based on that template. To help catch violations early, both the +audit and warning modes are applied to the workload resources. However, enforce mode is **not** +applied to workload resources, only to the resulting pod objects. + +## Exemptions + +You can define _exemptions_ from pod security enforcement in order allow the creation of pods that +would have otherwise been prohibited due to the policy associated with a given namespace. +Exemptions can be statically configured in the +[Admission Controller configuration](/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller). + +Exemptions must be explicitly enumerated. Requests meeting exemption criteria are _ignored_ by the +Admission Controller (all `enforce`, `audit` and `warn` behaviors are skipped). Exemption dimensions include: + +- **Usernames:** requests from users with an exempt authenticated (or impersonated) username are + ignored. +- **RuntimeClassNames:** pods and [workload resources](#workload-resources-and-pod-templates) specifying an exempt runtime class name are + ignored. +- **Namespaces:** pods and [workload resources](#workload-resources-and-pod-templates) in an exempt namespace are ignored. + +{{< caution >}} + +Most pods are created by a controller in response to a [workload +resource](#workload-resources-and-pod-templates), meaning that exempting an end user will only +exempt them from enforcement when creating pods directly, but not when creating a workload resource. +Controller service accounts (such as `system:serviceaccount:kube-system:replicaset-controller`) +should generally not be exempted, as doing so would implicitly exempt any user that can create the +corresponding workload resource. + +{{< /caution >}} + +Updates to the following pod fields are exempt from policy checks, meaning that if a pod update +request only changes these fields, it will not be denied even if the pod is in violation of the +current policy level: + +- Any metadata updates **except** changes to the seccomp or AppArmor annotations: + - `seccomp.security.alpha.kubernetes.io/pod` (deprecated) + - `container.seccomp.security.alpha.kubernetes.io/*` (deprecated) + - `container.apparmor.security.beta.kubernetes.io/*` +- Valid updates to `.spec.activeDeadlineSeconds` +- Valid updates to `.spec.tolerations` + +## {{% heading "whatsnext" %}} + +- [Pod Security Standards](/docs/concepts/security/pod-security-standards) +- [Enforcing Pod Security Standards](/docs/setup/best-practices/enforcing-pod-security-standards) +- [Enforce Pod Security Standards by Configuring the Built-in Admission Controller](/docs/tasks/configure-pod-container/enforce-standards-admission-controller) +- [Enforce Pod Security Standards with Namespace Labels](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels) +- [Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller](/docs/tasks/configure-pod-container/migrate-from-psp) diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md index a3c9ee138e..f3b43344bf 100644 --- a/content/en/docs/concepts/security/pod-security-standards.md +++ b/content/en/docs/concepts/security/pod-security-standards.md @@ -2,59 +2,52 @@ reviewers: - tallclair title: Pod Security Standards +description: > + A detailed look at the different policy levels defined in the Pod Security Standards. content_type: concept weight: 10 --- -Security settings for Pods are typically applied by using [security -contexts](/docs/tasks/configure-pod-container/security-context/). Security Contexts allow for the -definition of privilege and access controls on a per-Pod basis. - -The enforcement and policy-based definition of cluster requirements of security contexts has -previously been achieved using [Pod Security Policy](/docs/concepts/policy/pod-security-policy/). A -_Pod Security Policy_ is a cluster-level resource that controls security sensitive aspects of the -Pod specification. - -However, numerous means of policy enforcement have arisen that augment or replace the use of -PodSecurityPolicy. The intent of this page is to detail recommended Pod security profiles, decoupled -from any specific instantiation. - +The Pod Security Standards define three different _policies_ to broadly cover the security +spectrum. These policies are _cumulative_ and range from highly-permissive to highly-restrictive. +This guide outlines the requirements of each policy. +| Profile | Description | +| ------ | ----------- | +| Privileged | Unrestricted policy, providing the widest possible level of permissions. This policy allows for known privilege escalations. | +| Baseline | Minimally restrictive policy which prevents known privilege escalations. Allows the default (minimally specified) Pod configuration. | +| Restricted | Heavily restricted policy, following current Pod hardening best practices. | -## Policy Types - -There is an immediate need for base policy definitions to broadly cover the security spectrum. These -should range from highly restricted to highly flexible: - -- **_Privileged_** - Unrestricted policy, providing the widest possible level of permissions. This - policy allows for known privilege escalations. -- **_Baseline_** - Minimally restrictive policy while preventing known privilege - escalations. Allows the default (minimally specified) Pod configuration. -- **_Restricted_** - Heavily restricted policy, following current Pod hardening best practices. - -## Policies +## Profile Details ### Privileged -The Privileged policy is purposely-open, and entirely unrestricted. This type of policy is typically -aimed at system- and infrastructure-level workloads managed by privileged, trusted users. +**The _Privileged_ policy is purposely-open, and entirely unrestricted.** This type of policy is +typically aimed at system- and infrastructure-level workloads managed by privileged, trusted users. -The privileged policy is defined by an absence of restrictions. For allow-by-default enforcement -mechanisms (such as gatekeeper), the privileged profile may be an absence of applied constraints -rather than an instantiated policy. In contrast, for a deny-by-default mechanism (such as Pod -Security Policy) the privileged policy should enable all controls (disable all restrictions). +The Privileged policy is defined by an absence of restrictions. For allow-by-default enforcement +mechanisms (such as gatekeeper), the Privileged policy may be an absence of applied constraints +rather than an instantiated profile. In contrast, for a deny-by-default mechanism (such as Pod +Security Policy) the Privileged policy should enable all controls (disable all restrictions). ### Baseline -The Baseline policy is aimed at ease of adoption for common containerized workloads while -preventing known privilege escalations. This policy is targeted at application operators and +**The _Baseline_ policy is aimed at ease of adoption for common containerized workloads while +preventing known privilege escalations.** This policy is targeted at application operators and developers of non-critical applications. The following listed controls should be enforced/disallowed: +{{< note >}} +In this table, wildcards (`*`) indicate all elements in a list. For example, +`spec.containers[*].securityContext` refers to the Security Context object for _all defined +containers_. If any of the listed containers fails to meet the requirements, the entire pod will +fail validation. +{{< /note >}} + @@ -63,100 +56,223 @@ enforced/disallowed: - + - + - + - + - + - + - + - + - + + + + + + + + + @@ -164,10 +280,17 @@ enforced/disallowed: ### Restricted -The Restricted policy is aimed at enforcing current Pod hardening best practices, at the expense of -some compatibility. It is targeted at operators and developers of security-critical applications, as -well as lower-trust users.The following listed controls should be enforced/disallowed: +**The _Restricted_ policy is aimed at enforcing current Pod hardening best practices, at the +expense of some compatibility.** It is targeted at operators and developers of security-critical +applications, as well as lower-trust users. The following listed controls should be +enforced/disallowed: +{{< note >}} +In this table, wildcards (`*`) indicate all elements in a list. For example, +`spec.containers[*].securityContext` refers to the Security Context object for _all defined +containers_. If any of the listed containers fails to meet the requirements, the entire pod will +fail validation. +{{< /note >}}
Baseline policy specification
Policy
Host NamespacesHostProcess - Sharing the host namespaces must be disallowed.
-
Restricted Fields:
- spec.hostNetwork
- spec.hostPID
- spec.hostIPC
-
Allowed Values: false
+

Windows pods offer the ability to run HostProcess containers which enables privileged access to the Windows node. Privileged access to the host is disallowed in the baseline policy. HostProcess pods are an alpha feature as of Kubernetes v1.22.

+

Restricted Fields

+
    +
  • spec.securityContext.windowsOptions.hostProcess
    • +
  • spec.containers[*].securityContext.windowsOptions.hostProcess
    • +
  • spec.initContainers[*].securityContext.windowsOptions.hostProcess
    • +
  • spec.ephemeralContainers[*].securityContext.windowsOptions.hostProcess
    • +
+

Allowed Values

+
    +
  • Undefined/nil
    • +
  • false
    • +
Privileged ContainersHost Namespaces - Privileged Pods disable most security mechanisms and must be disallowed.
-
Restricted Fields:
- spec.containers[*].securityContext.privileged
- spec.initContainers[*].securityContext.privileged
-
Allowed Values: false, undefined/nil
+

Sharing the host namespaces must be disallowed.

+

Restricted Fields

+
    +
  • spec.hostNetwork
    • +
  • spec.hostPID
    • +
  • spec.hostIPC
    • +
+

Allowed Values

+
    +
  • Undefined/nil
    • +
  • false
    • +
CapabilitiesPrivileged Containers - Adding additional capabilities beyond the default set must be disallowed.
-
Restricted Fields:
- spec.containers[*].securityContext.capabilities.add
- spec.initContainers[*].securityContext.capabilities.add
-
Allowed Values: empty (or restricted to a known list)
+

Privileged Pods disable most security mechanisms and must be disallowed.

+

Restricted Fields

+
    +
  • spec.containers[*].securityContext.privileged
    • +
  • spec.initContainers[*].securityContext.privileged
    • +
  • spec.ephemeralContainers[*].securityContext.privileged
    • +
+

Allowed Values

+
    +
  • Undefined/nil
    • +
  • false
    • +
HostPath VolumesCapabilities - HostPath volumes must be forbidden.
-
Restricted Fields:
- spec.volumes[*].hostPath
-
Allowed Values: undefined/nil
+

Adding additional capabilities beyond those listed below must be disallowed.

+

Restricted Fields

+
    +
  • spec.containers[*].securityContext.capabilities.add
    • +
  • spec.initContainers[*].securityContext.capabilities.add
    • +
  • spec.ephemeralContainers[*].securityContext.capabilities.add
    • +
+

Allowed Values

+
    +
  • Undefined/nil
    • +
  • AUDIT_WRITE
    • +
  • CHOWN
    • +
  • DAC_OVERRIDE
    • +
  • FOWNER
    • +
  • FSETID
    • +
  • KILL
    • +
  • MKNOD
    • +
  • NET_BIND_SERVICE
    • +
  • SETFCAP
    • +
  • SETGID
    • +
  • SETPCAP
    • +
  • SETUID
    • +
  • SYS_CHROOT
    • +
Host PortsHostPath Volumes - HostPorts should be disallowed, or at minimum restricted to a known list.
-
Restricted Fields:
- spec.containers[*].ports[*].hostPort
- spec.initContainers[*].ports[*].hostPort
-
Allowed Values: 0, undefined (or restricted to a known list)
+

HostPath volumes must be forbidden.

+

Restricted Fields

+
    +
  • spec.volumes[*].hostPath
    • +
+

Allowed Values

+
    +
  • Undefined/nil
    • +
AppArmor (optional)Host Ports - On supported hosts, the 'runtime/default' AppArmor profile is applied by default. - The baseline policy should prevent overriding or disabling the default AppArmor - profile, or restrict overrides to an allowed set of profiles.
-
Restricted Fields:
- metadata.annotations['container.apparmor.security.beta.kubernetes.io/*']
-
Allowed Values: 'runtime/default', undefined
+

HostPorts should be disallowed, or at minimum restricted to a known list.

+

Restricted Fields

+
    +
  • spec.containers[*].ports[*].hostPort
    • +
  • spec.initContainers[*].ports[*].hostPort
    • +
  • spec.ephemeralContainers[*].ports[*].hostPort
    • +
+

Allowed Values

+
    +
  • Undefined/nil
    • +
  • Known list
    • +
  • 0
    • +
SELinux (optional)AppArmor - Setting custom SELinux options should be disallowed.
-
Restricted Fields:
- spec.securityContext.seLinuxOptions
- spec.containers[*].securityContext.seLinuxOptions
- spec.initContainers[*].securityContext.seLinuxOptions
-
Allowed Values: undefined/nil
+

On supported hosts, the runtime/default AppArmor profile is applied by default. The baseline policy should prevent overriding or disabling the default AppArmor profile, or restrict overrides to an allowed set of profiles.

+

Restricted Fields

+
    +
  • metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]
    • +
+

Allowed Values

+
    +
  • Undefined/nil
    • +
  • runtime/default
    • +
  • localhost/*
    • +
/proc Mount TypeSELinux - The default /proc masks are set up to reduce attack surface, and should be required.
-
Restricted Fields:
- spec.containers[*].securityContext.procMount
- spec.initContainers[*].securityContext.procMount
-
Allowed Values: undefined/nil, 'Default'
+

Setting the SELinux type is restricted, and setting a custom SELinux user or role option is forbidden.

+

Restricted Fields

+
    +
  • spec.securityContext.seLinuxOptions.type
    • +
  • spec.containers[*].securityContext.seLinuxOptions.type
    • +
  • spec.initContainers[*].securityContext.seLinuxOptions.type
    • +
  • spec.ephemeralContainers[*].securityContext.seLinuxOptions.type
    • +
+

Allowed Values

+
    +
  • Undefined/""
    • +
  • container_t
    • +
  • container_init_t
    • +
  • container_kvm_t
    • +
+
+

Restricted Fields

+
    +
  • spec.securityContext.seLinuxOptions.user
    • +
  • spec.containers[*].securityContext.seLinuxOptions.user
    • +
  • spec.initContainers[*].securityContext.seLinuxOptions.user
    • +
  • spec.ephemeralContainers[*].securityContext.seLinuxOptions.user
    • +
  • spec.securityContext.seLinuxOptions.role
    • +
  • spec.containers[*].securityContext.seLinuxOptions.role
    • +
  • spec.initContainers[*].securityContext.seLinuxOptions.role
    • +
  • spec.ephemeralContainers[*].securityContext.seLinuxOptions.role
    • +
+

Allowed Values

+
    +
  • Undefined/""
    • +
Sysctls/proc Mount Type - Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed "safe" subset. - A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node.
-
Restricted Fields:
- spec.securityContext.sysctls
-
Allowed Values:
- kernel.shm_rmid_forced
- net.ipv4.ip_local_port_range
- net.ipv4.tcp_syncookies
- net.ipv4.ping_group_range
- undefined/empty
+

The default /proc masks are set up to reduce attack surface, and should be required.

+

Restricted Fields

+
    +
  • spec.containers[*].securityContext.procMount
    • +
  • spec.initContainers[*].securityContext.procMount
    • +
  • spec.ephemeralContainers[*].securityContext.procMount
    • +
+

Allowed Values

+
    +
  • Undefined/nil
    • +
  • Default
    • +
+
Seccomp +

Seccomp profile must not be explicitly set to Unconfined.

+

Restricted Fields

+
    +
  • spec.securityContext.seccompProfile.type
    • +
  • spec.containers[*].securityContext.seccompProfile.type
    • +
  • spec.initContainers[*].securityContext.seccompProfile.type
    • +
  • spec.ephemeralContainers[*].securityContext.seccompProfile.type
    • +
+

Allowed Values

+
    +
  • Undefined/nil
    • +
  • RuntimeDefault
    • +
  • Localhost
    • +
+
Sysctls +

Sysctls can disable security mechanisms or affect all containers on a host, and should be disallowed except for an allowed "safe" subset. A sysctl is considered safe if it is namespaced in the container or the Pod, and it is isolated from other Pods or processes on the same Node.

+

Restricted Fields

+
    +
  • spec.securityContext.sysctls[*].name
    • +
+

Allowed Values

+
    +
  • Undefined/nil
    • +
  • kernel.shm_rmid_forced
    • +
  • net.ipv4.ip_local_port_range
    • +
  • net.ipv4.ip_unprivileged_port_start
    • +
  • net.ipv4.tcp_syncookies
    • +
  • net.ipv4.ping_group_range
    • +
@@ -180,81 +303,149 @@ well as lower-trust users.The following listed controls should be enforced/disal - + - + - + - + - + + + + + @@ -269,11 +460,17 @@ mechanism. As mechanisms mature, they will be defined below on a per-policy basis. The methods of enforcement of individual policies are not defined here. -[**PodSecurityPolicy**](/docs/concepts/policy/pod-security-policy/) +[**Pod Security Admission Controller**](/docs/concepts/security/pod-security-admission/) -- [Privileged](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/privileged-psp.yaml) -- [Baseline](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/baseline-psp.yaml) -- [Restricted](https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/policy/restricted-psp.yaml) +- {{< example file="security/podsecurity-privileged.yaml" >}}Privileged namespace{{< /example >}} +- {{< example file="security/podsecurity-baseline.yaml" >}}Baseline namespace{{< /example >}} +- {{< example file="security/podsecurity-restricted.yaml" >}}Restricted namespace{{< /example >}} + +[**PodSecurityPolicy**](/docs/concepts/profile/pod-security-profile/) (Deprecated) + +- {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}} +- {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}} +- {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}} ## FAQ @@ -287,26 +484,40 @@ policies in this space need to be defined on a case-by-case basis. SIG Auth may reconsider this position in the future, should a clear need for other profiles arise. -### What's the difference between a security policy and a security context? +### What's the difference between a security profile and a security context? [Security Contexts](/docs/tasks/configure-pod-container/security-context/) configure Pods and Containers at runtime. Security contexts are defined as part of the Pod and container specifications in the Pod manifest, and represent parameters to the container runtime. -Security policies are control plane mechanisms to enforce specific settings in the Security Context, -as well as other parameters outside the Security Context. As of February 2020, the current native -solution for enforcing these security policies is [Pod Security -Policy](/docs/concepts/policy/pod-security-policy/) - a mechanism for centrally enforcing security -policy on Pods across a cluster. Other alternatives for enforcing security policy are being -developed in the Kubernetes ecosystem, such as [OPA -Gatekeeper](https://github.com/open-policy-agent/gatekeeper). +Security profiles are control plane mechanisms to enforce specific settings in the Security Context, +as well as other related parameters outside the Security Context. As of July 2021, +[Pod Security Policies](/docs/concepts/profile/pod-security-profile/) are deprecated in favor of the +built-in [Pod Security Admission Controller](/docs/concepts/security/pod-security-admission/). + +{{% thirdparty-content %}} + +Other alternatives for enforcing security profiles are being developed in the Kubernetes +ecosystem, such as: +- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper). +- [Kubewarden](https://github.com/kubewarden). +- [Kyverno](https://kyverno.io/policies/pod-security/). ### What profiles should I apply to my Windows Pods? Windows in Kubernetes has some limitations and differentiators from standard Linux-based -workloads. Specifically, the Pod SecurityContext fields [have no effect on +workloads. Specifically, many of the Pod SecurityContext fields [have no effect on Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#v1-podsecuritycontext). As -such, no standardized Pod Security profiles currently exists. +such, no standardized Pod Security profiles currently exist. + +If you apply the restricted profile for a Windows pod, this **may** have an impact on the pod +at runtime. The restricted profile requires enforcing Linux-specific restrictions (such as seccomp +profile, and disallowing privilege escalation). If the kubelet and / or its container runtime ignore +these Linux-specific values, then the Windows pod should still work normally within the restricted +profile. However, the lack of enforcement means that there is no additional restriction, for Pods +that use Windows containers, compared to the baseline profile. + +The use of the HostProcess flag to create a HostProcess pod should only be done in alignment with the privileged policy. Creation of a Windows HostProcess pod is blocked under the baseline and restricted policies, so any HostProcess pod should be considered privileged. ### What about sandboxed Pods? @@ -319,6 +530,4 @@ restrict privileged permissions is lessened when the workload is isolated from t kernel. This allows for workloads requiring heightened permissions to still be isolated. Additionally, the protection of sandboxed workloads is highly dependent on the method of -sandboxing. As such, no single recommended policy is recommended for all sandboxed workloads. - - +sandboxing. As such, no single recommended profile is recommended for all sandboxed workloads. diff --git a/content/en/docs/concepts/services-networking/_index.md b/content/en/docs/concepts/services-networking/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/concepts/services-networking/connect-applications-service.md b/content/en/docs/concepts/services-networking/connect-applications-service.md index 14bc98101f..89d2daddb2 100644 --- a/content/en/docs/concepts/services-networking/connect-applications-service.md +++ b/content/en/docs/concepts/services-networking/connect-applications-service.md @@ -133,7 +133,7 @@ about the [service proxy](/docs/concepts/services-networking/service/#virtual-ip Kubernetes supports 2 primary modes of finding a Service - environment variables and DNS. The former works out of the box while the latter requires the -[CoreDNS cluster addon](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns). +[CoreDNS cluster addon](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/coredns). {{< note >}} If the service environment variables are not desired (because possible clashing with expected program ones, too many variables to process, only using DNS, etc) you can disable this mode by setting the `enableServiceLinks` @@ -231,7 +231,7 @@ Till now we have only accessed the nginx server from within the cluster. Before * An nginx server configured to use the certificates * A [secret](/docs/concepts/configuration/secret/) that makes the certificates accessible to pods -You can acquire all these from the [nginx https example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/). This requires having go and make tools installed. If you don't want to install those, then follow the manual steps later. In short: +You can acquire all these from the [nginx https example](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/). This requires having go and make tools installed. If you don't want to install those, then follow the manual steps later. In short: ```shell make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt @@ -303,7 +303,7 @@ Now modify your nginx replicas to start an https server using the certificate in Noteworthy points about the nginx-secure-app manifest: - It contains both Deployment and Service specification in the same file. -- The [nginx server](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf) +- The [nginx server](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/default.conf) serves HTTP traffic on port 80 and HTTPS traffic on 443, and nginx Service exposes both ports. - Each container has access to the keys through a volume mounted at `/etc/nginx/ssl`. diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md index 2888064c2e..f43eeff22b 100644 --- a/content/en/docs/concepts/services-networking/dns-pod-service.md +++ b/content/en/docs/concepts/services-networking/dns-pod-service.md @@ -7,6 +7,7 @@ content_type: concept weight: 20 --- + Kubernetes creates DNS records for services and pods. You can contact services with consistent DNS names instead of IP addresses. @@ -49,7 +50,7 @@ options ndots:5 ``` In summary, a pod in the _test_ namespace can successfully resolve either -`data.prod` or `data.prod.cluster.local`. +`data.prod` or `data.prod.svc.cluster.local`. ### DNS Records @@ -196,7 +197,7 @@ record unless `publishNotReadyAddresses=True` is set on the Service. ### Pod's setHostnameAsFQDN field {#pod-sethostnameasfqdn-field} -{{< feature-state for_k8s_version="v1.20" state="beta" >}} +{{< feature-state for_k8s_version="v1.22" state="stable" >}} When a Pod is configured to have fully qualified domain name (FQDN), its hostname is the short hostname. For example, if you have a Pod with the fully qualified domain name `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`, then by default the `hostname` command inside that Pod returns `busybox-1` and the `hostname --fqdn` command returns the FQDN. @@ -261,6 +262,8 @@ spec: ### Pod's DNS Config {#pod-dns-config} +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + Pod's DNS Config allows users more control on the DNS settings for a Pod. The `dnsConfig` field is optional and it can work with any `dnsPolicy` settings. @@ -310,6 +313,17 @@ search default.svc.cluster-domain.example svc.cluster-domain.example cluster-dom options ndots:5 ``` +#### Expanded DNS Configuration + +{{< feature-state for_k8s_version="1.22" state="alpha" >}} + +By default, for Pod's DNS Config, Kubernetes allows at most 6 search domains and +a list of search domains of up to 256 characters. + +If the feature gate `ExpandedDNSConfig` is enabled for the kube-apiserver and +the kubelet, it is allowed for Kubernetes to have at most 32 search domains and +a list of search domains of up to 2048 characters. + ### Feature availability The availability of Pod DNS Config and DNS Policy "`None`" is shown as below. @@ -321,7 +335,6 @@ The availability of Pod DNS Config and DNS Policy "`None`" is shown as below. | 1.9 | Alpha | - ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/concepts/services-networking/dual-stack.md b/content/en/docs/concepts/services-networking/dual-stack.md index 20cbcb5f33..a85226beed 100644 --- a/content/en/docs/concepts/services-networking/dual-stack.md +++ b/content/en/docs/concepts/services-networking/dual-stack.md @@ -16,11 +16,11 @@ weight: 70 -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} - IPv4/IPv6 dual-stack enables the allocation of both IPv4 and IPv6 addresses to {{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}. +IPv4/IPv6 dual-stack networking enables the allocation of both IPv4 and IPv6 addresses to {{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}. -If you enable IPv4/IPv6 dual-stack networking for your Kubernetes cluster, the cluster will support the simultaneous assignment of both IPv4 and IPv6 addresses. +IPv4/IPv6 dual-stack networking is enabled by default for your Kubernetes cluster starting in 1.21, allowing the simultaneous assignment of both IPv4 and IPv6 addresses. @@ -28,7 +28,7 @@ If you enable IPv4/IPv6 dual-stack networking for your Kubernetes cluster, the c ## Supported Features -Enabling IPv4/IPv6 dual-stack on your Kubernetes cluster provides the following features: +IPv4/IPv6 dual-stack on your Kubernetes cluster provides the following features: * Dual-stack Pod networking (a single IPv4 and IPv6 address assignment per Pod) * IPv4 and IPv6 enabled Services @@ -45,34 +45,34 @@ The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack * Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces) * A network plugin that supports dual-stack (such as Kubenet or Calico) -## Enable IPv4/IPv6 dual-stack +## Configure IPv4/IPv6 dual-stack -To enable IPv4/IPv6 dual-stack, enable the `IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the relevant components of your cluster, and set dual-stack cluster network assignments: +To use IPv4/IPv6 dual-stack, ensure the `IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled for the relevant components of your cluster. (Starting in 1.21, IPv4/IPv6 dual-stack defaults to enabled.) + +To configure IPv4/IPv6 dual-stack, set dual-stack cluster network assignments: * kube-apiserver: - * `--feature-gates="IPv6DualStack=true"` * `--service-cluster-ip-range=,` * kube-controller-manager: - * `--feature-gates="IPv6DualStack=true"` * `--cluster-cidr=,` * `--service-cluster-ip-range=,` * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` defaults to /24 for IPv4 and /64 for IPv6 - * kubelet: - * `--feature-gates="IPv6DualStack=true"` * kube-proxy: * `--cluster-cidr=,` - * `--feature-gates="IPv6DualStack=true"` {{< note >}} An example of an IPv4 CIDR: `10.244.0.0/16` (though you would supply your own address range) An example of an IPv6 CIDR: `fdXY:IJKL:MNOP:15::/64` (this shows the format but is not a valid address - see [RFC 4193](https://tools.ietf.org/html/rfc4193)) +Starting in 1.21, IPv4/IPv6 dual-stack defaults to enabled. +You can disable it when necessary by specifying `--feature-gates="IPv6DualStack=false"` +on the kube-apiserver, kube-controller-manager, kubelet, and kube-proxy command line. {{< /note >}} ## Services -If your cluster has dual-stack enabled, you can create {{< glossary_tooltip text="Services" term_id="service" >}} which can use IPv4, IPv6, or both. +You can create {{< glossary_tooltip text="Services" term_id="service" >}} which can use IPv4, IPv6, or both. The address family of a Service defaults to the address family of the first service cluster IP range (configured via the `--service-cluster-ip-range` flag to the kube-apiserver). @@ -81,11 +81,9 @@ set the `.spec.ipFamilyPolicy` field to one of the following values: * `SingleStack`: Single-stack service. The control plane allocates a cluster IP for the Service, using the first configured service cluster IP range. * `PreferDualStack`: - * Only used if the cluster has dual-stack enabled. Allocates IPv4 and IPv6 cluster IPs for the Service - * If the cluster does not have dual-stack enabled, this setting follows the same behavior as `SingleStack`. + * Allocates IPv4 and IPv6 cluster IPs for the Service. (If the cluster has `--feature-gates="IPv6DualStack=false"`, this setting follows the same behavior as `SingleStack`.) * `RequireDualStack`: Allocates Service `.spec.ClusterIPs` from both IPv4 and IPv6 address ranges. * Selects the `.spec.ClusterIP` from the list of `.spec.ClusterIPs` based on the address family of the first element in the `.spec.ipFamilies` array. - * The cluster must have dual-stack networking configured. If you would like to define which IP family to use for single stack or define the order of IP families for dual-stack, you can choose the address families by setting an optional field, `.spec.ipFamilies`, on the Service. @@ -126,7 +124,7 @@ These examples demonstrate the behavior of various dual-stack Service configurat #### Dual-stack defaults on existing Services -These examples demonstrate the default behavior when dual-stack is newly enabled on a cluster where Services already exist. +These examples demonstrate the default behavior when dual-stack is newly enabled on a cluster where Services already exist. (Upgrading an existing cluster to 1.21 will enable dual-stack unless `--feature-gates="IPv6DualStack=false"` is set.) 1. When dual-stack is enabled on a cluster, existing Services (whether `IPv4` or `IPv6`) are configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set `.spec.ipFamilies` to the address family of the existing Service. The existing Service cluster IP will be stored in `.spec.ClusterIPs`. @@ -242,3 +240,5 @@ Ensure your {{< glossary_tooltip text="CNI" term_id="cni" >}} provider supports * [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking +* [Enable dual-stack networking using kubeadm +](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/) diff --git a/content/en/docs/concepts/services-networking/endpoint-slices.md b/content/en/docs/concepts/services-networking/endpoint-slices.md index 6abf1f6ed1..da8d09d9d5 100644 --- a/content/en/docs/concepts/services-networking/endpoint-slices.md +++ b/content/en/docs/concepts/services-networking/endpoint-slices.md @@ -3,13 +3,13 @@ reviewers: - freehan title: EndpointSlices content_type: concept -weight: 35 +weight: 45 --- -{{< feature-state for_k8s_version="v1.17" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} _EndpointSlices_ provide a simple way to track network endpoints within a Kubernetes cluster. They offer a more scalable and extensible alternative to @@ -52,7 +52,7 @@ As an example, here's a sample EndpointSlice resource for the `example` Kubernetes Service. ```yaml -apiVersion: discovery.k8s.io/v1beta1 +apiVersion: discovery.k8s.io/v1 kind: EndpointSlice metadata: name: example-abc @@ -69,9 +69,8 @@ endpoints: conditions: ready: true hostname: pod-1 - topology: - kubernetes.io/hostname: node-1 - topology.kubernetes.io/zone: us-west2-a + nodeName: node-1 + zone: us-west2-a ``` By default, the control plane creates and manages EndpointSlices to have no @@ -135,30 +134,26 @@ For pods, this is any pod that has a deletion timestamp set. ### Topology information {#topology} -{{< feature-state for_k8s_version="v1.20" state="deprecated" >}} +Each endpoint within an EndpointSlice can contain relevant topology information. +The topology information includes the location of the endpoint and information +about the corresponding Node and zone. These are available in the following +per endpoint fields on EndpointSlices: + +* `nodeName` - The name of the Node this endpoint is on. +* `zone` - The zone this endpoint is in. {{< note >}} -The topology field in EndpointSlices has been deprecated and will be removed in -a future release. A new `nodeName` field will be used instead of setting -`kubernetes.io/hostname` in topology. It was determined that other topology -fields covering zone and region would be better represented as EndpointSlice -labels that would apply to all endpoints within the EndpointSlice. +In the v1 API, the per endpoint `topology` was effectively removed in favor of +the dedicated fields `nodeName` and `zone`. + +Setting arbitrary topology fields on the `endpoint` field of an `EndpointSlice` +resource has been deprecated and is not be supported in the v1 API. Instead, +the v1 API supports setting individual `nodeName` and `zone` fields. These +fields are automatically translated between API versions. For example, the +value of the `"topology.kubernetes.io/zone"` key in the `topology` field in +the v1beta1 API is accessible as the `zone` field in the v1 API. {{< /note >}} -Each endpoint within an EndpointSlice can contain relevant topology information. -This is used to indicate where an endpoint is, containing information about the -corresponding Node, zone, and region. When the values are available, the -control plane sets the following Topology labels for EndpointSlices: - -* `kubernetes.io/hostname` - The name of the Node this endpoint is on. -* `topology.kubernetes.io/zone` - The zone this endpoint is in. -* `topology.kubernetes.io/region` - The region this endpoint is in. - -The values of these labels are derived from resources associated with each -endpoint in a slice. The hostname label represents the value of the NodeName -field on the corresponding Pod. The zone and region labels represent the value -of the labels with the same names on the corresponding Node. - ### Management Most often, the control plane (specifically, the endpoint slice @@ -254,5 +249,4 @@ implementation in `kube-proxy`. ## {{% heading "whatsnext" %}} -* Learn about [Enabling EndpointSlices](/docs/tasks/administer-cluster/enabling-endpointslices) * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/en/docs/concepts/services-networking/ingress-controllers.md b/content/en/docs/concepts/services-networking/ingress-controllers.md index d0405a060d..0ee1d53ef9 100644 --- a/content/en/docs/concepts/services-networking/ingress-controllers.md +++ b/content/en/docs/concepts/services-networking/ingress-controllers.md @@ -32,6 +32,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet Citrix Application Delivery Controller. * [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller. * [EnRoute](https://getenroute.io/) is an [Envoy](https://www.envoyproxy.io) based API gateway that can run as an ingress controller. +* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/ingresscontroller.md) is an [Easegress](https://megaease.com/easegress/) based API gateway that can run as an ingress controller. * F5 BIG-IP [Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/) lets you use an Ingress to configure F5 BIG-IP virtual servers. * [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io), diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index b6be91cb9a..6879b998db 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -220,7 +220,24 @@ of the controller that should implement the class. {{< codenew file="service/networking/external-lb.yaml" >}} IngressClass resources contain an optional parameters field. This can be used to -reference additional configuration for this class. +reference additional implementation-specific configuration for this class. + +#### Namespace-scoped parameters + +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +`Parameters` field has a `scope` and `namespace` field that can be used to +reference a namespace-specific resource for configuration of an Ingress class. +`Scope` field defaults to `Cluster`, meaning, the default is cluster-scoped +resource. Setting `Scope` to `Namespace` and setting the `Namespace` field +will reference a parameters resource in a specific namespace: + +Namespace-scoped parameters avoid the need for a cluster-scoped CustomResourceDefinition +for a parameters resource. This further avoids RBAC-related resources +that would otherwise be required to grant permissions to cluster-scoped +resources. + +{{< codenew file="service/networking/namespaced-params.yaml" >}} ### Deprecated annotation diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md index 2000d838b4..e3f3a203b7 100644 --- a/content/en/docs/concepts/services-networking/network-policies.md +++ b/content/en/docs/concepts/services-networking/network-policies.md @@ -154,6 +154,7 @@ contains two elements in the `from` array, and allows connections from Pods in t When in doubt, use `kubectl describe` to see how Kubernetes has interpreted the policy. + __ipBlock__: This selects particular IP CIDR ranges to allow as ingress sources or egress destinations. These should be cluster-external IPs, since Pod IPs are ephemeral and unpredictable. Cluster ingress and egress mechanisms often require rewriting the source or destination IP @@ -212,27 +213,89 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will ## SCTP support -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.20" state="stable" >}} -As a beta feature, this is enabled by default. To disable SCTP at a cluster level, you (or your cluster administrator) will need to disable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=false,…`. +As a stable feature, this is enabled by default. To disable SCTP at a cluster level, you (or your cluster administrator) will need to disable the `SCTPSupport` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the API server with `--feature-gates=SCTPSupport=false,…`. When the feature gate is enabled, you can set the `protocol` field of a NetworkPolicy to `SCTP`. {{< note >}} You must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that supports SCTP protocol NetworkPolicies. {{< /note >}} +## Targeting a range of Ports + +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +When writing a NetworkPolicy, you can target a range of ports instead of a single port. + +This is achievable with the usage of the `endPort` field, as the following example: + +```yaml +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: multi-port-egress + namespace: default +spec: + podSelector: + matchLabels: + role: db + policyTypes: + - Egress + egress: + - to: + - ipBlock: + cidr: 10.0.0.0/24 + ports: + - protocol: TCP + port: 32000 + endPort: 32768 +``` + +The above rule allows any Pod with label `role=db` on the namespace `default` to communicate +with any IP within the range `10.0.0.0/24` over TCP, provided that the target +port is between the range 32000 and 32768. + +The following restrictions apply when using this field: +* As a beta feature, this is enabled by default. To disable the `endPort` field +at a cluster level, you (or your cluster administrator) need to disable the +`NetworkPolicyEndPort` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +for the API server with `--feature-gates=NetworkPolicyEndPort=false,…`. +* The `endPort` field must be equal than or greater to the `port` field. +* `endPort` can only be defined if `port` is also defined. +* Both ports must be numeric. + +{{< note >}} +Your cluster must be using a {{< glossary_tooltip text="CNI" term_id="cni" >}} plugin that +supports the `endPort` field in NetworkPolicy specifications. +If your [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +does not support the `endPort` field and you specify a NetworkPolicy with that, +the policy will be applied only for the single `port` field. +{{< /note >}} + +## Targeting a Namespace by its name + +{{< feature-state state="beta" for_k8s_version="1.21" >}} + +The Kubernetes control plane sets an immutable label `kubernetes.io/metadata.name` on all +namespaces, provided that the `NamespaceDefaultLabelName` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled. +The value of the label is the namespace name. + +While NetworkPolicy cannot target a namespace by its name with some object field, you can use the +standardized label to target a specific namespace. + ## What you can't do with network policies (at least, not yet) -As of Kubernetes 1.20, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers. In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API. Some (but not all) of these user stories are actively being discussed for future releases of the NetworkPolicy API. +As of Kubernetes {{< skew latestVersion >}}, the following functionality does not exist in the NetworkPolicy API, but you might be able to implement workarounds using Operating System components (such as SELinux, OpenVSwitch, IPTables, and so on) or Layer 7 technologies (Ingress controllers, Service Mesh implementations) or admission controllers. In case you are new to network security in Kubernetes, its worth noting that the following User Stories cannot (yet) be implemented using the NetworkPolicy API. - Forcing internal cluster traffic to go through a common gateway (this might be best served with a service mesh or other proxy). - Anything TLS related (use a service mesh or ingress controller for this). - Node specific policies (you can use CIDR notation for these, but you cannot target nodes by their Kubernetes identities specifically). -- Targeting of namespaces or services by name (you can, however, target pods or namespaces by their {{< glossary_tooltip text="labels" term_id="label" >}}, which is often a viable workaround). +- Targeting of services by name (you can, however, target pods or namespaces by their {{< glossary_tooltip text="labels" term_id="label" >}}, which is often a viable workaround). - Creation or management of "Policy requests" that are fulfilled by a third party. - Default policies which are applied to all namespaces or pods (there are some third party Kubernetes distributions and projects which can do this). - Advanced policy querying and reachability tooling. -- The ability to target ranges of Ports in a single policy declaration. - The ability to log network security events (for example connections that are blocked or accepted). - The ability to explicitly deny policies (currently the model for NetworkPolicies are deny by default, with only the ability to add allow rules). - The ability to prevent loopback or incoming host traffic (Pods cannot currently block localhost access, nor do they have the ability to block access from their resident node). diff --git a/content/en/docs/concepts/services-networking/service-topology.md b/content/en/docs/concepts/services-networking/service-topology.md index 66976b23fb..e906dff81d 100644 --- a/content/en/docs/concepts/services-networking/service-topology.md +++ b/content/en/docs/concepts/services-networking/service-topology.md @@ -2,12 +2,7 @@ reviewers: - johnbelamaric - imroc -title: Service Topology -feature: - title: Service Topology - description: > - Routing of service traffic based upon cluster topology. - +title: Topology-aware traffic routing with topology keys content_type: concept weight: 10 --- @@ -15,7 +10,16 @@ weight: 10 -{{< feature-state for_k8s_version="v1.17" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} + +{{< note >}} + +This feature, specifically the alpha `topologyKeys` API, is deprecated since +Kubernetes v1.21. +[Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints/), +introduced in Kubernetes v1.21, provide similar functionality. + +{{}} _Service Topology_ enables a service to route traffic based upon the Node topology of the cluster. For example, a service can specify that traffic be @@ -23,33 +27,32 @@ preferentially routed to endpoints that are on the same Node as the client, or in the same availability zone. - -## Introduction +## Topology-aware traffic routing By default, traffic sent to a `ClusterIP` or `NodePort` Service may be routed to -any backend address for the Service. Since Kubernetes 1.7 it has been possible -to route "external" traffic to the Pods running on the Node that received the -traffic, but this is not supported for `ClusterIP` Services, and more complex -topologies — such as routing zonally — have not been possible. The -_Service Topology_ feature resolves this by allowing the Service creator to -define a policy for routing traffic based upon the Node labels for the -originating and destination Nodes. - -By using Node label matching between the source and destination, the operator -may designate groups of Nodes that are "closer" and "farther" from one another, -using whatever metric makes sense for that operator's requirements. For many -operators in public clouds, for example, there is a preference to keep service -traffic within the same zone, because interzonal traffic has a cost associated -with it, while intrazonal traffic does not. Other common needs include being able -to route traffic to a local Pod managed by a DaemonSet, or keeping traffic to -Nodes connected to the same top-of-rack switch for the lowest latency. +any backend address for the Service. Kubernetes 1.7 made it possible to +route "external" traffic to the Pods running on the same Node that received the +traffic. For `ClusterIP` Services, the equivalent same-node preference for +routing wasn't possible; nor could you configure your cluster to favor routing +to endpoints within the same zone. +By setting `topologyKeys` on a Service, you're able to define a policy for routing +traffic based upon the Node labels for the originating and destination Nodes. +The label matching between the source and destination lets you, as a cluster +operator, designate sets of Nodes that are "closer" and "farther" from one another. +You can define labels to represent whatever metric makes sense for your own +requirements. +In public clouds, for example, you might prefer to keep network traffic within the +same zone, because interzonal traffic has a cost associated with it (and intrazonal +traffic typically does not). Other common needs include being able to route traffic +to a local Pod managed by a DaemonSet, or directing traffic to Nodes connected to the +same top-of-rack switch for the lowest latency. ## Using Service Topology -If your cluster has Service Topology enabled, you can control Service traffic +If your cluster has the `ServiceTopology` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) enabled, you can control Service traffic routing by specifying the `topologyKeys` field on the Service spec. This field is a preference-order list of Node labels which will be used to sort endpoints when accessing this Service. Traffic will be directed to a Node whose value for @@ -200,4 +203,3 @@ spec: * Read about [enabling Service Topology](/docs/tasks/administer-cluster/enabling-service-topology) * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) - diff --git a/content/en/docs/concepts/services-networking/service-traffic-policy.md b/content/en/docs/concepts/services-networking/service-traffic-policy.md new file mode 100644 index 0000000000..fb55a3d833 --- /dev/null +++ b/content/en/docs/concepts/services-networking/service-traffic-policy.md @@ -0,0 +1,73 @@ +--- +reviewers: +- maplain +title: Service Internal Traffic Policy +content_type: concept +weight: 45 +--- + + + + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +_Service Internal Traffic Policy_ enables internal traffic restrictions to only route +internal traffic to endpoints within the node the traffic originated from. The +"internal" traffic here refers to traffic originated from Pods in the current +cluster. This can help to reduce costs and improve performance. + + + +## Using Service Internal Traffic Policy + +Once you have enabled the `ServiceInternalTrafficPolicy` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/), +you can enable an internal-only traffic policy for a +{{< glossary_tooltip text="Services" term_id="service" >}}, by setting its +`.spec.internalTrafficPolicy` to `Local`. +This tells kube-proxy to only use node local endpoints for cluster internal traffic. + +{{< note >}} +For pods on nodes with no endpoints for a given Service, the Service +behaves as if it has zero endpoints (for Pods on this node) even if the service +does have endpoints on other nodes. +{{< /note >}} + +The following example shows what a Service looks like when you set +`.spec.internalTrafficPolicy` to `Local`: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + internalTrafficPolicy: Local +``` + +## How it works + +The kube-proxy filters the endpoints it routes to based on the +`spec.internalTrafficPolicy` setting. When it's set to `Local`, only node local +endpoints are considered. When it's `Cluster` or missing, all endpoints are +considered. +When the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +`ServiceInternalTrafficPolicy` is enabled, `spec.internalTrafficPolicy` defaults to "Cluster". + +## Constraints + +* Service Internal Traffic Policy is not used when `externalTrafficPolicy` is set + to `Local` on a Service. It is possible to use both features in the same cluster + on different Services, just not on the same Service. + +## {{% heading "whatsnext" %}} + +* Read about [enabling Topology Aware Hints](/docs/tasks/administer-cluster/enabling-topology-aware-hints) +* Read about [Service External Traffic Policy](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip) +* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index d6f451bc85..db28918c98 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -72,7 +72,7 @@ A Service in Kubernetes is a REST object, similar to a Pod. Like all of the REST objects, you can `POST` a Service definition to the API server to create a new instance. The name of a Service object must be a valid -[DNS label name](/docs/concepts/overview/working-with-objects/names#dns-label-names). +[RFC 1035 label name](/docs/concepts/overview/working-with-objects/names#rfc-1035-label-names). For example, suppose you have a set of Pods where each listens on TCP port 9376 and contains a label `app=MyApp`: @@ -187,9 +187,15 @@ An ExternalName Service is a special case of Service that does not have selectors and uses DNS names instead. For more information, see the [ExternalName](#externalname) section later in this document. +### Over Capacity Endpoints +If an Endpoints resource has more than 1000 endpoints then a Kubernetes v1.22 (or later) +cluster annotates that Endpoints with `endpoints.kubernetes.io/over-capacity: truncated`. +This annotation indicates that the affected Endpoints object is over capacity and that +the endpoints controller has truncated the number of endpoints to 1000. + ### EndpointSlices -{{< feature-state for_k8s_version="v1.17" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} EndpointSlices are an API resource that can provide a more scalable alternative to Endpoints. Although conceptually quite similar to Endpoints, EndpointSlices @@ -210,7 +216,7 @@ each Service port. The value of this field is mirrored by the corresponding Endpoints and EndpointSlice objects. This field follows standard Kubernetes label syntax. Values should either be -[IANA standard service names](http://www.iana.org/assignments/service-names) or +[IANA standard service names](https://www.iana.org/assignments/service-names) or domain prefixed names such as `mycompany.com/my-custom-protocol`. ## Virtual IPs and service proxies @@ -236,9 +242,25 @@ There are a few reasons for using proxying for Services: on the DNS records could impose a high load on DNS that then becomes difficult to manage. +Later in this page you can read about various kube-proxy implementations work. Overall, +you should note that, when running `kube-proxy`, kernel level rules may be +modified (for example, iptables rules might get created), which won't get cleaned up, +in some cases until you reboot. Thus, running kube-proxy is something that should +only be done by an administrator which understands the consequences of having a +low level, privileged network proxying service on a computer. Although the `kube-proxy` +executable supports a `cleanup` function, this function is not an official feature and +thus is only available to use as-is. + +### Configuration + +Note that the kube-proxy starts up in different modes, which are determined by its configuration. +- The kube-proxy's configuration is done via a ConfigMap, and the ConfigMap for kube-proxy effectively deprecates the behaviour for almost all of the flags for the kube-proxy. +- The ConfigMap for the kube-proxy does not support live reloading of configuration. +- The ConfigMap parameters for the kube-proxy cannot all be validated and verified on startup. For example, if your operating system doesn't allow you to run iptables commands, the standard kernel kube-proxy implementation will not work. Likewise, if you have an operating system which doesn't support `netsh`, it will not run in Windows userspace mode. + ### User space proxy mode {#proxy-mode-userspace} -In this mode, kube-proxy watches the Kubernetes control plane for the addition and +In this (legacy) mode, kube-proxy watches the Kubernetes control plane for the addition and removal of Service and Endpoint objects. For each Service it opens a port (randomly chosen) on the local node. Any connections to this "proxy port" are proxied to one of the Service's backend Pods (as reported via @@ -379,6 +401,40 @@ The IP address that you choose must be a valid IPv4 or IPv6 address from within If you try to create a Service with an invalid clusterIP address value, the API server will return a 422 HTTP status code to indicate that there's a problem. +## Traffic policies + +### External traffic policy + +You can set the `spec.externalTrafficPolicy` field to control how traffic from external sources is routed. +Valid values are `Cluster` and `Local`. Set the field to `Cluster` to route external traffic to all ready endpoints +and `Local` to only route to ready node-local endpoints. If the traffic policy is `Local` and there are are no node-local +endpoints, the kube-proxy does not forward any traffic for the relevant Service. + +{{< note >}} +{{< feature-state for_k8s_version="v1.22" state="alpha" >}} +If you enable the `ProxyTerminatingEndpoints` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +`ProxyTerminatingEndpoints` for the kube-proxy, the kube-proxy checks if the node +has local endpoints and whether or not all the local endpoints are marked as terminating. +If there are local endpoints and **all** of those are terminating, then the kube-proxy ignores +any external traffic policy of `Local`. Instead, whilst the node-local endpoints remain as all +terminating, the kube-proxy forwards traffic for that Service to healthy endpoints elsewhere, +as if the external traffic policy were set to `Cluster`. +This forwarding behavior for terminating endpoints exists to allow external load balancers to +gracefully drain connections that are backed by `NodePort` Services, even when the health check +node port starts to fail. Otherwise, traffic can be lost between the time a node is still in the node pool of a load +balancer and traffic is being dropped during the termination period of a pod. +{{< /note >}} + +### Internal traffic policy + +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +You can set the `spec.internalTrafficPolicy` field to control how traffic from internal sources is routed. +Valid values are `Cluster` and `Local`. Set the field to `Cluster` to route internal traffic to all ready endpoints +and `Local` to only route to ready node-local endpoints. If the traffic policy is `Local` and there are no node-local +endpoints, traffic is dropped by kube-proxy. + ## Discovering services Kubernetes supports 2 primary modes of finding a Service - environment @@ -388,8 +444,7 @@ variables and DNS. When a Pod is run on a Node, the kubelet adds a set of environment variables for each active Service. It supports both [Docker links -compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see -[makeLinkVariables](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49)) +compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see [makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72)) and simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables, where the Service name is upper-cased and dashes are converted to underscores. @@ -635,6 +690,24 @@ is set to `false` on an existing Service with allocated node ports, those node p You must explicitly remove the `nodePorts` entry in every Service port to de-allocate those node ports. You must enable the `ServiceLBNodePortControl` feature gate to use this field. +#### Specifying class of load balancer implementation {#load-balancer-class} + +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +`spec.loadBalancerClass` enables you to use a load balancer implementation other than the cloud provider default. This feature is available from v1.21, you must enable the `ServiceLoadBalancerClass` feature gate to use this field in v1.21, and the feature gate is enabled by default from v1.22 onwards. +By default, `spec.loadBalancerClass` is `nil` and a `LoadBalancer` type of Service uses +the cloud provider's default load balancer implementation if the cluster is configured with +a cloud provider using the `--cloud-provider` component flag. +If `spec.loadBalancerClass` is specified, it is assumed that a load balancer +implementation that matches the specified class is watching for Services. +Any default load balancer implementation (for example, the one provided by +the cloud provider) will ignore Services that have this field set. +`spec.loadBalancerClass` can be set on a Service of type `LoadBalancer` only. +Once set, it cannot be changed. +The value of `spec.loadBalancerClass` must be a label-style identifier, +with an optional prefix such as "`internal-vip`" or "`example.com/internal-vip`". +Unprefixed names are reserved for end-users. + #### Internal load balancer In a mixed environment it is sometimes necessary to route traffic from Services inside the same @@ -912,11 +985,18 @@ There are other annotations to manage Classic Elastic Load Balancers that are de # value. Defaults to 5, must be between 2 and 60 service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f" - # A list of existing security groups to be added to ELB created. Unlike the annotation - # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups, this replaces all other security groups previously assigned to the ELB. + # A list of existing security groups to be configured on the ELB created. Unlike the annotation + # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups, this replaces all other security groups previously assigned to the ELB and also overrides the creation + # of a uniquely generated security group for this ELB. + # The first security group ID on this list is used as a source to permit incoming traffic to target worker nodes (service traffic and health checks). + # If multiple ELBs are configured with the same security group ID, only a single permit line will be added to the worker node security groups, that means if you delete any + # of those ELBs it will remove the single permit line and block access for all ELBs that shared the same security group ID. + # This can cause a cross-service outage if not used properly service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e" - # A list of additional security groups to be added to the ELB + # A list of additional security groups to be added to the created ELB, this leaves the uniquely generated security group in place, this ensures that every ELB + # has a unique security group ID and a matching permit line to allow traffic to the target worker nodes (service traffic and health checks). + # Security groups defined here can be shared between services. service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api" # A comma separated list of key-value pairs which are used @@ -965,7 +1045,6 @@ groups are modified with the following IP rules: | Rule | Protocol | Port(s) | IpRange(s) | IpRange Description | |------|----------|---------|------------|---------------------| | Health Check | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | Subnet CIDR | kubernetes.io/rule/nlb/health=\ | - | Client Traffic | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\ | | MTU Discovery | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\ | diff --git a/content/en/docs/concepts/services-networking/topology-aware-hints.md b/content/en/docs/concepts/services-networking/topology-aware-hints.md new file mode 100644 index 0000000000..f471caff6b --- /dev/null +++ b/content/en/docs/concepts/services-networking/topology-aware-hints.md @@ -0,0 +1,160 @@ +--- +reviewers: +- robscott +title: Topology Aware Hints +content_type: concept +weight: 45 +--- + + + + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +_Topology Aware Hints_ enable topology aware routing by including suggestions +for how clients should consume endpoints. This approach adds metadata to enable +consumers of EndpointSlice and / or Endpoints objects, so that traffic to +those network endpoints can be routed closer to where it originated. + +For example, you can route traffic within a locality to reduce +costs, or to improve network performance. + + + +## Motivation + +Kubernetes clusters are increasingly deployed in multi-zone environments. +_Topology Aware Hints_ provides a mechanism to help keep traffic within the zone +it originated from. This concept is commonly referred to as "Topology Aware +Routing". When calculating the endpoints for a {{< glossary_tooltip term_id="Service" >}}, +the EndpointSlice controller considers the topology (region and zone) of each endpoint +and populates the hints field to allocate it to a zone. +Cluster components such as the {{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}} +can then consume those hints, and use them to influence how traffic to is routed +(favoring topologically closer endpoints). + +## Using Topology Aware Hints + +If you have [enabled](/docs/tasks/administer-cluster/enabling-topology-aware-hints) the +overall feature, you can activate Topology Aware Hints for a Service by setting the +`service.kubernetes.io/topology-aware-hints` annotation to `auto`. This tells +the EndpointSlice controller to set topology hints if it is deemed safe. +Importantly, this does not guarantee that hints will always be set. + +## How it works {#implementation} + +The functionality enabling this feature is split into two components: The +EndpointSlice controller and the kube-proxy. This section provides a high level overview +of how each component implements this feature. + +### EndpointSlice controller {#implementation-control-plane} + +The EndpointSlice controller is responsible for setting hints on EndpointSlices +when this feature is enabled. The controller allocates a proportional amount of +endpoints to each zone. This proportion is based on the +[allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +CPU cores for nodes running in that zone. For example, if one zone had 2 CPU +cores and another zone only had 1 CPU core, the controller would allocated twice +as many endpoints to the zone with 2 CPU cores. + +The following example shows what an EndpointSlice looks like when hints have +been populated: + +```yaml +apiVersion: discovery.k8s.io/v1 +kind: EndpointSlice +metadata: + name: example-hints + labels: + kubernetes.io/service-name: example-svc +addressType: IPv4 +ports: + - name: http + protocol: TCP + port: 80 +endpoints: + - addresses: + - "10.1.2.3" + conditions: + ready: true + hostname: pod-1 + zone: zone-a + hints: + forZones: + - name: "zone-a" +``` + +### kube-proxy {#implementation-kube-proxy} + +The kube-proxy component filters the endpoints it routes to based on the hints set by +the EndpointSlice controller. In most cases, this means that the kube-proxy is able +to route traffic to endpoints in the same zone. Sometimes the controller allocates endpoints +from a different zone to ensure more even distribution of endpoints between zones. +This would result in some traffic being routed to other zones. + +## Safeguards + +The Kubernetes control plane and the kube-proxy on each node apply some +safeguard rules before using Topology Aware Hints. If these don't check out, +the kube-proxy selects endpoints from anywhere in your cluster, regardless of the +zone. + +1. **Insufficient number of endpoints:** If there are less endpoints than zones + in a cluster, the controller will not assign any hints. + +2. **Impossible to achieve balanced allocation:** In some cases, it will be + impossible to achieve a balanced allocation of endpoints among zones. For + example, if zone-a is twice as large as zone-b, but there are only 2 + endpoints, an endpoint allocated to zone-a may receive twice as much traffic + as zone-b. The controller does not assign hints if it can't get this "expected + overload" value below an acceptable threshold for each zone. Importantly this + is not based on real-time feedback. It is still possible for individual + endpoints to become overloaded. + +3. **One or more Nodes has insufficient information:** If any node does not have + a `topology.kubernetes.io/zone` label or is not reporting a value for + allocatable CPU, the control plane does not set any topology-aware endpoint + hints and so kube-proxy does not filter endpoints by zone. + +4. **One or more endpoints does not have a zone hint:** When this happens, + the kube-proxy assumes that a transition from or to Topology Aware Hints is + underway. Filtering endpoints for a Service in this state would be dangerous + so the kube-proxy falls back to using all endpoints. + +5. **A zone is not represented in hints:** If the kube-proxy is unable to find + at least one endpoint with a hint targeting the zone it is running in, it falls + to using endpoints from all zones. This is most likely to happen as you add + a new zone into your existing cluster. + +## Constraints + +* Topology Aware Hints are not used when either `externalTrafficPolicy` or + `internalTrafficPolicy` is set to `Local` on a Service. It is possible to use + both features in the same cluster on different Services, just not on the same + Service. + +* This approach will not work well for Services that have a large proportion of + traffic originating from a subset of zones. Instead this assumes that incoming + traffic will be roughly proportional to the capacity of the Nodes in each + zone. + +* The EndpointSlice controller ignores unready nodes as it calculates the + proportions of each zone. This could have unintended consequences if a large + portion of nodes are unready. + +* The EndpointSlice controller does not take into account {{< glossary_tooltip + text="tolerations" term_id="toleration" >}} when deploying calculating the + proportions of each zone. If the Pods backing a Service are limited to a + subset of Nodes in the cluster, this will not be taken into account. + +* This may not work well with autoscaling. For example, if a lot of traffic is + originating from a single zone, only the endpoints allocated to that zone will + be handling that traffic. That could result in {{< glossary_tooltip + text="Horizontal Pod Autoscaler" term_id="horizontal-pod-autoscaler" >}} + either not picking up on this event, or newly added pods starting in a + different zone. + +## {{% heading "whatsnext" %}} + +* Read about [enabling Topology Aware Hints](/docs/tasks/administer-cluster/enabling-topology-aware-hints/) +* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/en/docs/concepts/storage/_index.md b/content/en/docs/concepts/storage/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/concepts/storage/ephemeral-volumes.md b/content/en/docs/concepts/storage/ephemeral-volumes.md index bc391a3f36..e76f76f492 100644 --- a/content/en/docs/concepts/storage/ephemeral-volumes.md +++ b/content/en/docs/concepts/storage/ephemeral-volumes.md @@ -130,13 +130,15 @@ As a cluster administrator, you can use a [PodSecurityPolicy](/docs/concepts/pol ### Generic ephemeral volumes -{{< feature-state for_k8s_version="v1.19" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} This feature requires the `GenericEphemeralVolume` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be -enabled. Because this is an alpha feature, it is disabled by default. +enabled. Because this is a beta feature, it is enabled by default. -Generic ephemeral volumes are similar to `emptyDir` volumes, except more -flexible: +Generic ephemeral volumes are similar to `emptyDir` volumes in the +sense that they provide a per-pod directory for scratch data that is +usually empty after provisioning. But they may also have additional +features: - Storage can be local or network-attached. - Volumes can have a fixed size that Pods are not able to exceed. @@ -243,14 +245,16 @@ PVCs indirectly if they can create Pods, even if they do not have permission to create PVCs directly. Cluster administrators must be aware of this. If this does not fit their security model, they have two choices: -- Explicitly disable the feature through the feature gate, to avoid - being surprised when some future Kubernetes version enables it - by default. +- Explicitly disable the feature through the feature gate. - Use a [Pod Security Policy](/docs/concepts/policy/pod-security-policy/) where the - `volumes` list does not contain the `ephemeral` volume type. + `volumes` list does not contain the `ephemeral` volume type + (deprecated in Kubernetes 1.21). +- Use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/) + which rejects objects like Pods that have a generic ephemeral + volume. -The normal namespace quota for PVCs in a namespace still applies, so +The normal [namespace quota for PVCs](/docs/concepts/policy/resource-quotas/#storage-resource-quota) still applies, so even if users are allowed to use this new mechanism, they cannot use it to circumvent other policies. diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 54e42bae9e..f2093073df 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -131,7 +131,9 @@ The `Retain` reclaim policy allows for manual reclamation of the resource. When 1. Delete the PersistentVolume. The associated storage asset in external infrastructure (such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume) still exists after the PV is deleted. 1. Manually clean up the data on the associated storage asset accordingly. -1. Manually delete the associated storage asset, or if you want to reuse the same storage asset, create a new PersistentVolume with the storage asset definition. +1. Manually delete the associated storage asset. + +If you want to reuse the same storage asset, create a new PersistentVolume with the same storage asset definition. #### Delete @@ -314,12 +316,9 @@ PersistentVolume types are implemented as plugins. Kubernetes currently supports * [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk) - Azure Disk * [`azureFile`](/docs/concepts/storage/volumes/#azurefile) - Azure File * [`cephfs`](/docs/concepts/storage/volumes/#cephfs) - CephFS volume -* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage) - (**deprecated**) * [`csi`](/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI) * [`fc`](/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage * [`flexVolume`](/docs/concepts/storage/volumes/#flexVolume) - FlexVolume -* [`flocker`](/docs/concepts/storage/volumes/#flocker) - Flocker storage * [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk * [`glusterfs`](/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume * [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume @@ -329,17 +328,28 @@ PersistentVolume types are implemented as plugins. Kubernetes currently supports * [`local`](/docs/concepts/storage/volumes/#local) - local storage devices mounted on nodes. * [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage -* `photonPersistentDisk` - Photon controller persistent disk. - (This volume type no longer works since the removal of the corresponding - cloud provider.) * [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Portworx volume -* [`quobyte`](/docs/concepts/storage/volumes/#quobyte) - Quobyte volume * [`rbd`](/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) volume -* [`scaleIO`](/docs/concepts/storage/volumes/#scaleio) - ScaleIO volume - (**deprecated**) -* [`storageos`](/docs/concepts/storage/volumes/#storageos) - StorageOS volume * [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK volume +The following types of PersistentVolume are deprecated. This means that support is still available but will be removed in a future Kubernetes release. + +* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage) + (**deprecated** in v1.18) +* [`flocker`](/docs/concepts/storage/volumes/#flocker) - Flocker storage + (**deprecated** in v1.22) +* [`quobyte`](/docs/concepts/storage/volumes/#quobyte) - Quobyte volume + (**deprecated** in v1.22) +* [`storageos`](/docs/concepts/storage/volumes/#storageos) - StorageOS volume + (**deprecated** in v1.22) + +Older versions of Kubernetes also supported the following in-tree PersistentVolume types: + +* `photonPersistentDisk` - Photon controller persistent disk. + (**not available** after v1.15) +* [`scaleIO`](/docs/concepts/storage/volumes/#scaleio) - ScaleIO volume + (**not available** after v1.21) + ## Persistent Volumes Each PV contains a spec and status, which is the specification and status of the volume. @@ -387,7 +397,7 @@ Kubernetes supports two `volumeModes` of PersistentVolumes: `Filesystem` and `Bl `Filesystem` is the default mode used when `volumeMode` parameter is omitted. A volume with `volumeMode: Filesystem` is *mounted* into Pods into a directory. If the volume -is backed by a block device and the device is empty, Kuberneretes creates a filesystem +is backed by a block device and the device is empty, Kubernetes creates a filesystem on the device before mounting it for the first time. You can set the value of `volumeMode` to `Block` to use a volume as a raw block device. @@ -404,41 +414,54 @@ A PersistentVolume can be mounted on a host in any way supported by the resource The access modes are: -* ReadWriteOnce -- the volume can be mounted as read-write by a single node -* ReadOnlyMany -- the volume can be mounted read-only by many nodes -* ReadWriteMany -- the volume can be mounted as read-write by many nodes +`ReadWriteOnce` +: the volume can be mounted as read-write by a single node. ReadWriteOnce access mode still can allow multiple pods to access the volume when the pods are running on the same node. + +`ReadOnlyMany` +: the volume can be mounted as read-only by many nodes. + +`ReadWriteMany` +: the volume can be mounted as read-write by many nodes. + + `ReadWriteOncePod` +: the volume can be mounted as read-write by a single Pod. Use ReadWriteOncePod access mode if you want to ensure that only one pod across whole cluster can read that PVC or write to it. This is only supported for CSI volumes and Kubernetes version 1.22+. + + + +The blog article [Introducing Single Pod Access Mode for PersistentVolumes](/blog/2021/09/13/read-write-once-pod-access-mode-alpha/) covers this in more detail. + In the CLI, the access modes are abbreviated to: * RWO - ReadWriteOnce * ROX - ReadOnlyMany * RWX - ReadWriteMany +* RWOP - ReadWriteOncePod > __Important!__ A volume can only be mounted using one access mode at a time, even if it supports many. For example, a GCEPersistentDisk can be mounted as ReadWriteOnce by a single node or ReadOnlyMany by many nodes, but not at the same time. -| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany| -| :--- | :---: | :---: | :---: | -| AWSElasticBlockStore | ✓ | - | - | -| AzureFile | ✓ | ✓ | ✓ | -| AzureDisk | ✓ | - | - | -| CephFS | ✓ | ✓ | ✓ | -| Cinder | ✓ | - | - | -| CSI | depends on the driver | depends on the driver | depends on the driver | -| FC | ✓ | ✓ | - | -| FlexVolume | ✓ | ✓ | depends on the driver | -| Flocker | ✓ | - | - | -| GCEPersistentDisk | ✓ | ✓ | - | -| Glusterfs | ✓ | ✓ | ✓ | -| HostPath | ✓ | - | - | -| iSCSI | ✓ | ✓ | - | -| Quobyte | ✓ | ✓ | ✓ | -| NFS | ✓ | ✓ | ✓ | -| RBD | ✓ | ✓ | - | -| VsphereVolume | ✓ | - | - (works when Pods are collocated) | -| PortworxVolume | ✓ | - | ✓ | -| ScaleIO | ✓ | ✓ | - | -| StorageOS | ✓ | - | - | +| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany | ReadWriteOncePod | +| :--- | :---: | :---: | :---: | - | +| AWSElasticBlockStore | ✓ | - | - | - | +| AzureFile | ✓ | ✓ | ✓ | - | +| AzureDisk | ✓ | - | - | - | +| CephFS | ✓ | ✓ | ✓ | - | +| Cinder | ✓ | - | - | - | +| CSI | depends on the driver | depends on the driver | depends on the driver | depends on the driver | +| FC | ✓ | ✓ | - | - | +| FlexVolume | ✓ | ✓ | depends on the driver | - | +| Flocker | ✓ | - | - | - | +| GCEPersistentDisk | ✓ | ✓ | - | - | +| Glusterfs | ✓ | ✓ | ✓ | - | +| HostPath | ✓ | - | - | - | +| iSCSI | ✓ | ✓ | - | - | +| Quobyte | ✓ | ✓ | ✓ | - | +| NFS | ✓ | ✓ | ✓ | - | +| RBD | ✓ | ✓ | - | - | +| VsphereVolume | ✓ | - | - (works when Pods are collocated) | - | +| PortworxVolume | ✓ | - | ✓ | - | - | +| StorageOS | ✓ | - | - | - | ### Class @@ -499,7 +522,7 @@ it will become fully deprecated in a future Kubernetes release. For most volume types, you do not need to set this field. It is automatically populated for [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) and [Azure Disk](/docs/concepts/storage/volumes/#azuredisk) volume block types. You need to explicitly set this for [local](/docs/concepts/storage/volumes/#local) volumes. {{< /note >}} -A PV can specify [node affinity](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) to define constraints that limit what nodes this volume can be accessed from. Pods that use a PV will only be scheduled to nodes that are selected by the node affinity. +A PV can specify node affinity to define constraints that limit what nodes this volume can be accessed from. Pods that use a PV will only be scheduled to nodes that are selected by the node affinity. To specify node affinity, set `nodeAffinity` in the `.spec` of a PV. The [PersistentVolume](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec) API reference has more details on this field. ### Phase @@ -540,11 +563,11 @@ spec: ### Access Modes -Claims use the same conventions as volumes when requesting storage with specific access modes. +Claims use [the same conventions as volumes](#access-modes) when requesting storage with specific access modes. ### Volume Modes -Claims use the same convention as volumes to indicate the consumption of the volume as either a filesystem or block device. +Claims use [the same convention as volumes](#volume-mode) to indicate the consumption of the volume as either a filesystem or block device. ### Resources @@ -785,6 +808,82 @@ spec: storage: 10Gi ``` +## Volume populators and data sources + +{{< feature-state for_k8s_version="v1.22" state="alpha" >}} + +{{< note >}} +Kubernetes supports custom volume populators; this alpha feature was introduced +in Kubernetes 1.18. Kubernetes 1.22 reimplemented the mechanism with a redesigned API. +Check that you are reading the version of the Kubernetes documentation that matches your +cluster. {{% version-check %}} +To use custom volume populators, you must enable the `AnyVolumeDataSource` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for +the kube-apiserver and kube-controller-manager. +{{< /note >}} + +Volume populators take advantage of a PVC spec field called `dataSourceRef`. Unlike the +`dataSource` field, which can only contain either a reference to another PersistentVolumeClaim +or to a VolumeSnapshot, the `dataSourceRef` field can contain a reference to any object in the +same namespace, except for core objects other than PVCs. For clusters that have the feature +gate enabled, use of the `dataSourceRef` is preferred over `dataSource`. + +## Data source references + +The `dataSourceRef` field behaves almost the same as the `dataSource` field. If either one is +specified while the other is not, the API server will give both fields the same value. Neither +field can be changed after creation, and attempting to specify different values for the two +fields will result in a validation error. Therefore the two fields will always have the same +contents. + +There are two differences between the `dataSourceRef` field and the `dataSource` field that +users should be aware of: +* The `dataSource` field ignores invalid values (as if the field was blank) while the + `dataSourceRef` field never ignores values and will cause an error if an invalid value is + used. Invalid values are any core object (objects with no apiGroup) except for PVCs. +* The `dataSourceRef` field may contain different types of objects, while the `dataSource` field + only allows PVCs and VolumeSnapshots. + +Users should always use `dataSourceRef` on clusters that have the feature gate enabled, and +fall back to `dataSource` on clusters that do not. It is not necessary to look at both fields +under any circumstance. The duplicated values with slightly different semantics exist only for +backwards compatibility. In particular, a mixture of older and newer controllers are able to +interoperate because the fields are the same. + +### Using volume populators + +Volume populators are {{< glossary_tooltip text="controllers" term_id="controller" >}} that can +create non-empty volumes, where the contents of the volume are determined by a Custom Resource. +Users create a populated volume by referring to a Custom Resource using the `dataSourceRef` field: + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: populated-pvc +spec: + dataSourceRef: + name: example-name + kind: ExampleDataSource + apiGroup: example.storage.k8s.io + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +Because volume populators are external components, attempts to create a PVC that uses one +can fail if not all the correct components are installed. External controllers should generate +events on the PVC to provide feedback on the status of the creation, including warnings if +the PVC cannot be created due to some missing component. + +You can install the alpha [volume data source validator](https://github.com/kubernetes-csi/volume-data-source-validator) +controller into your cluster. That controller generates warning Events on a PVC in the case that no populator +is registered to handle that kind of data source. When a suitable populator is installed for a PVC, it's the +responsibility of that populator controller to report Events that relate to volume creation and issues during +the process. + ## Writing Portable Configuration If you're writing configuration templates or examples that run on a wide range of clusters @@ -811,16 +910,15 @@ and need persistent storage, it is recommended that you use the following patter or the cluster has no storage system (in which case the user cannot deploy config requiring PVCs). - ## {{% heading "whatsnext" %}} - +## {{% heading "whatsnext" %}} * Learn more about [Creating a PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). * Learn more about [Creating a PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim). * Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). -### Reference +### API references {#reference} -* [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) -* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) -* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) -* [PersistentVolumeClaimSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaimspec-v1-core) +Read about the APIs described in this page: + +* [`PersistentVolume`](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/) +* [`PersistentVolumeClaim`](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1/) diff --git a/content/en/docs/concepts/storage/storage-capacity.md b/content/en/docs/concepts/storage/storage-capacity.md index d5993d4f59..13ae8ab722 100644 --- a/content/en/docs/concepts/storage/storage-capacity.md +++ b/content/en/docs/concepts/storage/storage-capacity.md @@ -17,6 +17,7 @@ which a pod runs: network-attached storage might not be accessible by all nodes, or storage is local to a node to begin with. {{< feature-state for_k8s_version="v1.19" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} This page describes how Kubernetes keeps track of storage capacity and how the scheduler uses that information to schedule Pods onto nodes @@ -103,34 +104,10 @@ to handle this automatically. ## Enabling storage capacity tracking -Storage capacity tracking is an *alpha feature* and only enabled when -the `CSIStorageCapacity` [feature -gate](/docs/reference/command-line-tools-reference/feature-gates/) and -the `storage.k8s.io/v1alpha1` {{< glossary_tooltip text="API group" term_id="api-group" >}} are enabled. For details on -that, see the `--feature-gates` and `--runtime-config` [kube-apiserver -parameters](/docs/reference/command-line-tools-reference/kube-apiserver/). - -A quick check -whether a Kubernetes cluster supports the feature is to list -CSIStorageCapacity objects with: -```shell -kubectl get csistoragecapacities --all-namespaces -``` - -If your cluster supports CSIStorageCapacity, the response is either a list of CSIStorageCapacity objects or: -``` -No resources found -``` - -If not supported, this error is printed instead: -``` -error: the server doesn't have a resource type "csistoragecapacities" -``` - -In addition to enabling the feature in the cluster, a CSI -driver also has to -support it. Please refer to the driver's documentation for -details. +Storage capacity tracking is a beta feature and enabled by default in +a Kubernetes cluster since Kubernetes 1.21. In addition to having the +feature enabled in the cluster, a CSI driver also has to support +it. Please refer to the driver's documentation for details. ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index 0abdf6b545..36615098c6 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -76,7 +76,7 @@ for provisioning PVs. This field must be specified. | Glusterfs | ✓ | [Glusterfs](#glusterfs) | | iSCSI | - | - | | Quobyte | ✓ | [Quobyte](#quobyte) | -| NFS | - | - | +| NFS | - | [NFS](#nfs) | | RBD | ✓ | [Ceph RBD](#ceph-rbd) | | VsphereVolume | ✓ | [vSphere](#vsphere) | | PortworxVolume | ✓ | [Portworx Volume](#portworx-volume) | @@ -154,9 +154,9 @@ the class or PV. If a mount option is invalid, the PV mount fails. ### Volume Binding Mode The `volumeBindingMode` field controls when [volume binding and dynamic -provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur. +provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur. When unset, "Immediate" mode is used by default. -By default, the `Immediate` mode indicates that volume binding and dynamic +The `Immediate` mode indicates that volume binding and dynamic provisioning occurs once the PersistentVolumeClaim is created. For storage backends that are topology-constrained and not globally accessible from all Nodes in the cluster, PersistentVolumes will be bound or provisioned without knowledge of the Pod's scheduling @@ -188,6 +188,36 @@ The following plugins support `WaitForFirstConsumer` with pre-created Persistent and pre-created PVs, but you'll need to look at the documentation for a specific CSI driver to see its supported topology keys and examples. +{{< note >}} + If you choose to use `WaitForFirstConsumer`, do not use `nodeName` in the Pod spec + to specify node affinity. If `nodeName` is used in this case, the scheduler will be bypassed and PVC will remain in `pending` state. + + Instead, you can use node selector for hostname in this case as shown below. +{{< /note >}} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: task-pv-pod +spec: + nodeSelector: + kubernetes.io/hostname: kube-01 + volumes: + - name: task-pv-storage + persistentVolumeClaim: + claimName: task-pv-claim + containers: + - name: task-pv-container + image: nginx + ports: + - containerPort: 80 + name: "http-server" + volumeMounts: + - mountPath: "/usr/share/nginx/html" + name: task-pv-storage +``` + ### Allowed Topologies When a cluster operator specifies the `WaitForFirstConsumer` volume binding mode, it is no longer necessary @@ -393,6 +423,29 @@ parameters: `gluster-dynamic-`. The dynamic endpoint and service are automatically deleted when the persistent volume claim is deleted. +### NFS + +```yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: example-nfs +provisioner: example.com/external-nfs +parameters: + server: nfs-server.example.com + path: /share + readOnly: false +``` + +* `server`: Server is the hostname or IP address of the NFS server. +* `path`: Path that is exported by the NFS server. +* `readOnly`: A flag indicating whether the storage will be mounted as read only (default false). + +Kubernetes doesn't include an internal NFS provisioner. You need to use an external provisioner to create a StorageClass for NFS. +Here are some examples: +* [NFS Ganesha server and external provisioner](https://github.com/kubernetes-sigs/nfs-ganesha-server-and-external-provisioner) +* [NFS subdir external provisioner](https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner) + ### OpenStack Cinder ```yaml @@ -548,6 +601,12 @@ parameters: ### Quobyte +{{< feature-state for_k8s_version="v1.22" state="deprecated" >}} + +The Quobyte in-tree storage plugin is deprecated, an +[example](https://github.com/quobyte/quobyte-csi/blob/master/example/StorageClass.yaml) +`StorageClass` for the out-of-tree Quobyte plugin can be found at the Quobyte CSI repository. + ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass @@ -628,11 +687,11 @@ metadata: provisioner: kubernetes.io/azure-disk parameters: storageaccounttype: Standard_LRS - kind: Shared + kind: managed ``` * `storageaccounttype`: Azure storage account Sku tier. Default is empty. -* `kind`: Possible values are `shared` (default), `dedicated`, and `managed`. +* `kind`: Possible values are `shared`, `dedicated`, and `managed` (default). When `kind` is `shared`, all unmanaged disks are created in a few shared storage accounts in the same resource group as the cluster. When `kind` is `dedicated`, a new dedicated storage account will be created for the new diff --git a/content/en/docs/concepts/storage/volume-health-monitoring.md b/content/en/docs/concepts/storage/volume-health-monitoring.md new file mode 100644 index 0000000000..c5fb9c1929 --- /dev/null +++ b/content/en/docs/concepts/storage/volume-health-monitoring.md @@ -0,0 +1,35 @@ +--- +reviewers: +- jsafrane +- saad-ali +- msau42 +- xing-yang +title: Volume Health Monitoring +content_type: concept +--- + + + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +{{< glossary_tooltip text="CSI" term_id="csi" >}} volume health monitoring allows CSI Drivers to detect abnormal volume conditions from the underlying storage systems and report them as events on {{< glossary_tooltip text="PVCs" term_id="persistent-volume-claim" >}} or {{< glossary_tooltip text="Pods" term_id="pod" >}}. + + + +## Volume health monitoring + +Kubernetes _volume health monitoring_ is part of how Kubernetes implements the Container Storage Interface (CSI). Volume health monitoring feature is implemented in two components: an External Health Monitor controller, and the {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}. + +If a CSI Driver supports Volume Health Monitoring feature from the controller side, an event will be reported on the related {{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} (PVC) when an abnormal volume condition is detected on a CSI volume. + +The External Health Monitor {{< glossary_tooltip text="controller" term_id="controller" >}} also watches for node failure events. You can enable node failure monitoring by setting the `enable-node-watcher` flag to true. When the external health monitor detects a node failure event, the controller reports an Event will be reported on the PVC to indicate that pods using this PVC are on a failed node. + +If a CSI Driver supports Volume Health Monitoring feature from the node side, an Event will be reported on every Pod using the PVC when an abnormal volume condition is detected on a CSI volume. + +{{< note >}} +You need to enable the `CSIVolumeHealth` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to use this feature from the node side. +{{< /note >}} + +## {{% heading "whatsnext" %}} + +See the [CSI driver documentation](https://kubernetes-csi.github.io/docs/drivers.html) to find out which CSI drivers have implemented this feature. diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index 9743ec34f8..56694dee66 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -33,10 +33,9 @@ drivers, but the functionality is somewhat limited. Kubernetes supports many types of volumes. A {{< glossary_tooltip term_id="pod" text="Pod" >}} can use any number of volume types simultaneously. Ephemeral volume types have a lifetime of a pod, but persistent volumes exist beyond -the lifetime of a pod. Consequently, a volume outlives any containers -that run within the pod, and data is preserved across container restarts. When a pod -ceases to exist, Kubernetes destroys ephemeral volumes; however, Kubernetes does not -destroy persistent volumes. +the lifetime of a pod. When a pod ceases to exist, Kubernetes destroys ephemeral volumes; +however, Kubernetes does not destroy persistent volumes. +For any kind of volume in a given pod, data is preserved across container restarts. At its core, a volume is a directory, possibly with some data in it, which is accessible to the containers in a pod. How that directory comes to be, the @@ -125,13 +124,13 @@ beta features must be enabled. {{< feature-state for_k8s_version="v1.17" state="alpha" >}} To disable the `awsElasticBlockStore` storage plugin from being loaded by the controller manager -and the kubelet, set the `CSIMigrationAWSComplete` flag to `true`. This feature requires the `ebs.csi.aws.com` Container Storage Interface (CSI) driver installed on all worker nodes. +and the kubelet, set the `InTreePluginAWSUnregister` flag to `true`. ### azureDisk {#azuredisk} The `azureDisk` volume type mounts a Microsoft Azure [Data Disk](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers) into a pod. -For more details, see the [`azureDisk` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md). +For more details, see the [`azureDisk` volume plugin](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_disk/README.md). #### azureDisk CSI migration @@ -149,18 +148,20 @@ features must be enabled. The `azureFile` volume type mounts a Microsoft Azure File volume (SMB 2.1 and 3.0) into a pod. -For more details, see the [`azureFile` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md). +For more details, see the [`azureFile` volume plugin](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_file/README.md). #### azureFile CSI migration -{{< feature-state for_k8s_version="v1.15" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} The `CSIMigration` feature for `azureFile`, when enabled, redirects all plugin operations from the existing in-tree plugin to the `file.csi.azure.com` Container Storage Interface (CSI) Driver. In order to use this feature, the [Azure File CSI Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) must be installed on the cluster and the `CSIMigration` and `CSIMigrationAzureFile` -alpha features must be enabled. +[feature gates](/docs/reference/command-line-tools-reference/feature-gates/) must be enabled. + +Azure File CSI driver does not support using same volume with different fsgroups, if Azurefile CSI migration is enabled, using same volume with different fsgroups won't be supported at all. ### cephfs @@ -175,7 +176,7 @@ writers simultaneously. You must have your own Ceph server running with the share exported before you can use it. {{< /note >}} -See the [CephFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/) for more details. +See the [CephFS example](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/) for more details. ### cinder @@ -209,14 +210,17 @@ spec: #### OpenStack CSI migration -{{< feature-state for_k8s_version="v1.18" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} -The `CSIMigration` feature for Cinder, when enabled, redirects all plugin operations -from the existing in-tree plugin to the `cinder.csi.openstack.org` Container -Storage Interface (CSI) Driver. In order to use this feature, the [OpenStack Cinder CSI -Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md) -must be installed on the cluster and the `CSIMigration` and `CSIMigrationOpenStack` -beta features must be enabled. +The `CSIMigration` feature for Cinder is enabled by default in Kubernetes 1.21. +It redirects all plugin operations from the existing in-tree plugin to the +`cinder.csi.openstack.org` Container Storage Interface (CSI) Driver. +[OpenStack Cinder CSI Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md) +must be installed on the cluster. +You can disable Cinder CSI migration for your cluster by setting the `CSIMigrationOpenStack` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to `false`. +If you disable the `CSIMigrationOpenStack` feature, the in-tree Cinder volume plugin takes responsibility +for all aspects of Cinder volume storage management. ### configMap @@ -343,7 +347,7 @@ You must configure FC SAN Zoning to allocate and mask those LUNs (volumes) to th beforehand so that Kubernetes hosts can access them. {{< /note >}} -See the [fibre channel example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) for more details. +See the [fibre channel example](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel) for more details. ### flocker (deprecated) {#flocker} @@ -361,7 +365,7 @@ can be shared between pods as required. You must have your own Flocker installation running before you can use it. {{< /note >}} -See the [Flocker example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker) for more details. +See the [Flocker example](https://github.com/kubernetes/examples/tree/master/staging/volumes/flocker) for more details. ### gcePersistentDisk @@ -458,7 +462,8 @@ spec: required: nodeSelectorTerms: - matchExpressions: - - key: failure-domain.beta.kubernetes.io/zone + # failure-domain.beta.kubernetes.io/zone should be used prior to 1.21 + - key: topology.kubernetes.io/zone operator: In values: - us-central1-a @@ -476,6 +481,13 @@ Driver](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-drive must be installed on the cluster and the `CSIMigration` and `CSIMigrationGCE` beta features must be enabled. +#### GCE CSI migration complete + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +To disable the `gcePersistentDisk` storage plugin from being loaded by the controller manager +and the kubelet, set the `InTreePluginGCEUnregister` flag to `true`. + ### gitRepo (deprecated) {#gitrepo} {{< warning >}} @@ -521,10 +533,19 @@ simultaneously. You must have your own GlusterFS installation running before you can use it. {{< /note >}} -See the [GlusterFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs) for more details. +See the [GlusterFS example](https://github.com/kubernetes/examples/tree/master/volumes/glusterfs) for more details. ### hostPath {#hostpath} +{{< warning >}} +HostPath volumes present many security risks, and it is a best practice to avoid the use of +HostPaths when possible. When a HostPath volume must be used, it should be scoped to only the +required file or directory, and mounted as ReadOnly. + +If restricting HostPath access to specific directories through AdmissionPolicy, `volumeMounts` MUST +be required to use `readOnly` mounts for the policy to be effective. +{{< /warning >}} + A `hostPath` volume mounts a file or directory from the host node's filesystem into your Pod. This is not something that most Pods will need, but it offers a powerful escape hatch for some applications. @@ -554,6 +575,9 @@ The supported values for field `type` are: Watch out when using this type of volume, because: +* HostPaths can expose privileged system credentials (such as for the Kubelet) or privileged APIs + (such as container runtime socket), which can be used for container escape or to attack other + parts of the cluster. * Pods with identical configuration (such as created from a PodTemplate) may behave differently on different nodes due to different files on the nodes * The files or directories created on the underlying hosts are only writable by root. You @@ -637,7 +661,7 @@ and then serve it in parallel from as many Pods as you need. Unfortunately, iSCSI volumes can only be mounted by a single consumer in read-write mode. Simultaneous writers are not allowed. -See the [iSCSI example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi) for more details. +See the [iSCSI example](https://github.com/kubernetes/examples/tree/master/volumes/iscsi) for more details. ### local @@ -725,7 +749,7 @@ writers simultaneously. You must have your own NFS server running with the share exported before you can use it. {{< /note >}} -See the [NFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs) for more details. +See the [NFS example](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs) for more details. ### persistentVolumeClaim {#persistentvolumeclaim} @@ -773,7 +797,7 @@ Make sure you have an existing PortworxVolume with name `pxvol` before using it in the Pod. {{< /note >}} -For more details, see the [Portworx volume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md) examples. +For more details, see the [Portworx volume](https://github.com/kubernetes/examples/tree/master/staging/volumes/portworx/README.md) examples. ### projected @@ -787,7 +811,7 @@ Currently, the following types of volume sources can be projected: * `serviceAccountToken` All sources are required to be in the same namespace as the Pod. For more details, -see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md). +see the [all-in-one volume design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md). #### Example configuration with a secret, a downwardAPI, and a configMap {#example-configuration-secret-downwardapi-configmap} @@ -915,7 +939,7 @@ A container using a projected volume source as a [`subPath`](#using-subpath) vol receive updates for those volume sources. {{< /note >}} -### quobyte +### quobyte (deprecated) {#quobyte} A `quobyte` volume allows an existing [Quobyte](https://www.quobyte.com) volume to be mounted into your Pod. @@ -948,52 +972,9 @@ and then serve it in parallel from as many pods as you need. Unfortunately, RBD volumes can only be mounted by a single consumer in read-write mode. Simultaneous writers are not allowed. -See the [RBD example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd) +See the [RBD example](https://github.com/kubernetes/examples/tree/master/volumes/rbd) for more details. -### scaleIO (deprecated) {#scaleio} - -ScaleIO is a software-based storage platform that uses existing hardware to -create clusters of scalable shared block networked storage. The `scaleIO` volume -plugin allows deployed pods to access existing ScaleIO -volumes. For information about dynamically provisioning new volumes for -persistent volume claims, see -[ScaleIO persistent volumes](/docs/concepts/storage/persistent-volumes/#scaleio). - -{{< note >}} -You must have an existing ScaleIO cluster already setup and -running with the volumes created before you can use them. -{{< /note >}} - -The following example is a Pod configuration with ScaleIO: - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: pod-0 -spec: - containers: - - image: k8s.gcr.io/test-webserver - name: pod-0 - volumeMounts: - - mountPath: /test-pd - name: vol-0 - volumes: - - name: vol-0 - scaleIO: - gateway: https://localhost:443/api - system: scaleio - protectionDomain: sd0 - storagePool: sp1 - volumeName: vol-0 - secretRef: - name: sio-secret - fsType: xfs -``` - -For further details, see the [ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio) examples. - ### secret A `secret` volume is used to pass sensitive information, such as passwords, to @@ -1013,7 +994,7 @@ receive Secret updates. For more details, see [Configuring Secrets](/docs/concepts/configuration/secret/). -### storageOS {#storageos} +### storageOS (deprecated) {#storageos} A `storageos` volume allows an existing [StorageOS](https://www.storageos.com) volume to mount into your Pod. @@ -1161,7 +1142,7 @@ but new volumes created by the vSphere CSI driver will not be honoring these par {{< feature-state for_k8s_version="v1.19" state="beta" >}} -To turn off the `vsphereVolume` plugin from being loaded by the controller manager and the kubelet, you need to set this feature flag to `true`. You must install a `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} driver on all worker nodes. +To turn off the `vsphereVolume` plugin from being loaded by the controller manager and the kubelet, you need to set `InTreePluginvSphereUnregister` feature flag to `true`. You must install a `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} driver on all worker nodes. ## Using subPath {#using-subpath} diff --git a/content/en/docs/concepts/workloads/controllers/_index.md b/content/en/docs/concepts/workloads/controllers/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/concepts/workloads/controllers/cron-jobs.md b/content/en/docs/concepts/workloads/controllers/cron-jobs.md index 3624135a20..60c91f7303 100644 --- a/content/en/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/en/docs/concepts/workloads/controllers/cron-jobs.md @@ -10,13 +10,15 @@ weight: 80 -{{< feature-state for_k8s_version="v1.8" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} A _CronJob_ creates {{< glossary_tooltip term_id="job" text="Jobs" >}} on a repeating schedule. One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format. +In addition, the CronJob schedule supports timezone handling, you can specify the timezone by adding "CRON_TZ= +This role does not allow write access to resource quota or to the namespace itself. +This role also does not allow write access to Endpoints in clusters created +using Kubernetes v1.22+. More information is available in the +["Write Access for Endpoints" section](#write-access-for-endpoints). @@ -695,7 +701,9 @@ This role does not allow write access to resource quota or to the namespace itse This role does not allow viewing or modifying roles or role bindings. However, this role allows accessing Secrets and running Pods as any ServiceAccount in the namespace, so it can be used to gain the API access levels of any ServiceAccount in -the namespace. +the namespace. This role also does not allow write access to Endpoints in +clusters created using Kubernetes v1.22+. More information is available in the +["Write Access for Endpoints" section](#write-access-for-endpoints). @@ -1185,6 +1193,24 @@ In order from most secure to least secure, the approaches are: --group=system:serviceaccounts ``` +## Write access for Endpoints + +Kubernetes clusters created before Kubernetes v1.22 include write access to +Endpoints in the aggregated "edit" and "admin" roles. As a mitigation for +[CVE-2021-25740](https://github.com/kubernetes/kubernetes/issues/103675), this +access is not part of the aggregated roles in clusters that you create using +Kubernetes v1.22 or later. + +Existing clusters that have been upgraded to Kubernetes v1.22 will not be +subject to this change. The [CVE +announcement](https://github.com/kubernetes/kubernetes/issues/103675) includes +guidance for restricting this access in existing clusters. + +If you want new clusters to retain this level of access in the aggregated roles, +you can create the following ClusterRole: + +{{< codenew file="access/endpoints-aggregated.yaml" >}} + ## Upgrading from ABAC Clusters that originally ran older Kubernetes versions often used diff --git a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md index dd13dfeecc..820b9b6cca 100644 --- a/content/en/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/en/docs/reference/access-authn-authz/service-accounts-admin.md @@ -1,23 +1,24 @@ --- reviewers: -- bprashanth -- davidopp -- lavalamp -- liggitt + - bprashanth + - davidopp + - lavalamp + - liggitt title: Managing Service Accounts content_type: concept weight: 50 --- + This is a Cluster Administrator guide to service accounts. You should be familiar with [configuring Kubernetes service accounts](/docs/tasks/configure-pod-container/configure-service-account/). -Support for authorization and user accounts is planned but incomplete. Sometimes +Support for authorization and user accounts is planned but incomplete. Sometimes incomplete features are referred to in order to better describe service accounts. - + ## User accounts versus service accounts Kubernetes distinguishes between the concept of a user account and a service account @@ -53,37 +54,46 @@ It is part of the API server. It acts synchronously to modify pods as they are created or updated. When this plugin is active (and it is by default on most distributions), then it does the following when a pod is created or modified: - 1. If the pod does not have a `ServiceAccount` set, it sets the `ServiceAccount` to `default`. - 1. It ensures that the `ServiceAccount` referenced by the pod exists, and otherwise rejects it. - 1. If the pod does not contain any `ImagePullSecrets`, then `ImagePullSecrets` of the `ServiceAccount` are added to the pod. - 1. It adds a `volume` to the pod which contains a token for API access. - 1. It adds a `volumeSource` to each container of the pod mounted at `/var/run/secrets/kubernetes.io/serviceaccount`. +1. If the pod does not have a `ServiceAccount` set, it sets the `ServiceAccount` to `default`. +1. It ensures that the `ServiceAccount` referenced by the pod exists, and otherwise rejects it. +1. It adds a `volume` to the pod which contains a token for API access if neither the ServiceAccount `automountServiceAccountToken` nor the Pod's `automountServiceAccountToken` is set to `false`. +1. It adds a `volumeSource` to each container of the pod mounted at `/var/run/secrets/kubernetes.io/serviceaccount`, if the previous step has created a volume for ServiceAccount token. +1. If the pod does not contain any `imagePullSecrets`, then `imagePullSecrets` of the `ServiceAccount` are added to the pod. #### Bound Service Account Token Volume -{{< feature-state for_k8s_version="v1.13" state="alpha" >}} -When the `BoundServiceAccountTokenVolume` feature gate is enabled, the service account admission controller will -add a projected service account token volume instead of a secret volume. The service account token will expire after 1 hour by default or the pod is deleted. See more details about [projected volume](/docs/tasks/configure-pod-container/configure-projected-volume-storage/). +{{< feature-state for_k8s_version="v1.22" state="stable" >}} -This feature depends on the `RootCAConfigMap` feature gate enabled which publish a "kube-root-ca.crt" ConfigMap to every namespace. This ConfigMap contains a CA bundle used for verifying connections to the kube-apiserver. -1. If the pod does not have a `serviceAccountName` set, it sets the - `serviceAccountName` to `default`. -1. It ensures that the `serviceAccountName` referenced by the pod exists, and - otherwise rejects it. -1. If the pod does not contain any `imagePullSecrets`, then `imagePullSecrets` - of the ServiceAccount referenced by `serviceAccountName` are added to the pod. -1. It adds a `volume` to the pod which contains a token for API access - if neither the ServiceAccount `automountServiceAccountToken` nor the Pod's - `automountServiceAccountToken` is set to `false`. -1. It adds a `volumeSource` to each container of the pod mounted at - `/var/run/secrets/kubernetes.io/serviceaccount`, if the previous step has - created a volume for ServiceAccount token. +The ServiceAccount admission controller will add the following projected volume instead of a Secret-based volume for the non-expiring service account token created by Token Controller. -You can migrate a service account volume to a projected volume when -the `BoundServiceAccountTokenVolume` feature gate is enabled. -The service account token will expire after 1 hour or the pod is deleted. See -more details about -[projected volume](/docs/tasks/configure-pod-container/configure-projected-volume-storage/). +```yaml +- name: kube-api-access- + projected: + defaultMode: 420 # 0644 + sources: + - serviceAccountToken: + expirationSeconds: 3607 + path: token + - configMap: + items: + - key: ca.crt + path: ca.crt + name: kube-root-ca.crt + - downwardAPI: + items: + - fieldRef: + apiVersion: v1 + fieldPath: metadata.namespace + path: namespace +``` + +This projected volume consists of three sources: + +1. A ServiceAccountToken acquired from kube-apiserver via TokenRequest API. It will expire after 1 hour by default or when the pod is deleted. It is bound to the pod and has kube-apiserver as the audience. +1. A ConfigMap containing a CA bundle used for verifying connections to the kube-apiserver. This feature depends on the `RootCAConfigMap` feature gate, which publishes a "kube-root-ca.crt" ConfigMap to every namespace. `RootCAConfigMap` feature gate is graduated to GA in 1.21 and default to true. (This flag will be removed from --feature-gate arg in 1.22) +1. A DownwardAPI that references the namespace of the pod. + +See more details about [projected volumes](/docs/tasks/configure-pod-container/configure-projected-volume-storage/). ### Token Controller @@ -140,4 +150,3 @@ kubectl delete secret mysecretname A ServiceAccount controller manages the ServiceAccounts inside namespaces, and ensures a ServiceAccount named "default" exists in every active namespace. - diff --git a/content/en/docs/reference/access-authn-authz/webhook.md b/content/en/docs/reference/access-authn-authz/webhook.md index 69be02ff76..d0ee79f4cf 100644 --- a/content/en/docs/reference/access-authn-authz/webhook.md +++ b/content/en/docs/reference/access-authn-authz/webhook.md @@ -172,5 +172,5 @@ Access to other non-resource paths can be disallowed without restricting access to the REST api. For further documentation refer to the authorization.v1beta1 API objects and -[webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go). +[webhook.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go). diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index daf525c781..d639029659 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -2,6 +2,9 @@ title: Feature Gates weight: 10 content_type: concept +card: + name: reference + weight: 60 --- @@ -25,7 +28,7 @@ Use `-h` flag to see a full set of feature gates for all components. To set feature gates for a component, such as kubelet, use the `--feature-gates` flag assigned to a list of feature pairs: ```shell ---feature-gates="...,DynamicKubeletConfig=true" +--feature-gates="...,GracefulNodeShutdown=true" ``` The following tables are a summary of the feature gates that you can set on @@ -53,133 +56,150 @@ different Kubernetes components. | `APIPriorityAndFairness` | `false` | Alpha | 1.17 | 1.19 | | `APIPriorityAndFairness` | `true` | Beta | 1.20 | | | `APIResponseCompression` | `false` | Alpha | 1.7 | 1.15 | -| `APIResponseCompression` | `false` | Beta | 1.16 | | +| `APIResponseCompression` | `true` | Beta | 1.16 | | | `APIServerIdentity` | `false` | Alpha | 1.20 | | +| `APIServerTracing` | `false` | Alpha | 1.22 | | | `AllowInsecureBackendProxy` | `true` | Beta | 1.17 | | | `AnyVolumeDataSource` | `false` | Alpha | 1.18 | | | `AppArmor` | `true` | Beta | 1.4 | | -| `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | | -| `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | | +| `ControllerManagerLeaderMigration` | `false` | Alpha | 1.21 | | | `CPUManager` | `false` | Alpha | 1.8 | 1.9 | | `CPUManager` | `true` | Beta | 1.10 | | -| `CRIContainerLogRotation` | `false` | Alpha | 1.10 | 1.10 | -| `CRIContainerLogRotation` | `true` | Beta| 1.11 | | +| `CPUManagerPolicyOptions` | `false` | Alpha | 1.22 | | | `CSIInlineVolume` | `false` | Alpha | 1.15 | 1.15 | | `CSIInlineVolume` | `true` | Beta | 1.16 | - | | `CSIMigration` | `false` | Alpha | 1.14 | 1.16 | | `CSIMigration` | `true` | Beta | 1.17 | | | `CSIMigrationAWS` | `false` | Alpha | 1.14 | | | `CSIMigrationAWS` | `false` | Beta | 1.17 | | -| `CSIMigrationAWSComplete` | `false` | Alpha | 1.17 | | | `CSIMigrationAzureDisk` | `false` | Alpha | 1.15 | 1.18 | | `CSIMigrationAzureDisk` | `false` | Beta | 1.19 | | -| `CSIMigrationAzureDiskComplete` | `false` | Alpha | 1.17 | | -| `CSIMigrationAzureFile` | `false` | Alpha | 1.15 | | -| `CSIMigrationAzureFileComplete` | `false` | Alpha | 1.17 | | +| `CSIMigrationAzureFile` | `false` | Alpha | 1.15 | 1.19 | +| `CSIMigrationAzureFile` | `false` | Beta | 1.21 | | | `CSIMigrationGCE` | `false` | Alpha | 1.14 | 1.16 | | `CSIMigrationGCE` | `false` | Beta | 1.17 | | -| `CSIMigrationGCEComplete` | `false` | Alpha | 1.17 | | | `CSIMigrationOpenStack` | `false` | Alpha | 1.14 | 1.17 | | `CSIMigrationOpenStack` | `true` | Beta | 1.18 | | -| `CSIMigrationOpenStackComplete` | `false` | Alpha | 1.17 | | | `CSIMigrationvSphere` | `false` | Beta | 1.19 | | -| `CSIMigrationvSphereComplete` | `false` | Beta | 1.19 | | -| `CSIServiceAccountToken` | `false` | Alpha | 1.20 | | -| `CSIStorageCapacity` | `false` | Alpha | 1.19 | | +| `CSIStorageCapacity` | `false` | Alpha | 1.19 | 1.20 | +| `CSIStorageCapacity` | `true` | Beta | 1.21 | | | `CSIVolumeFSGroupPolicy` | `false` | Alpha | 1.19 | 1.19 | | `CSIVolumeFSGroupPolicy` | `true` | Beta | 1.20 | | +| `CSIVolumeHealth` | `false` | Alpha | 1.21 | | +| `CSRDuration` | `true` | Beta | 1.22 | | | `ConfigurableFSGroupPolicy` | `false` | Alpha | 1.18 | 1.19 | | `ConfigurableFSGroupPolicy` | `true` | Beta | 1.20 | | -| `CronJobControllerV2` | `false` | Alpha | 1.20 | | +| `ControllerManagerLeaderMigration` | `false` | Alpha | 1.21 | 1.21 | +| `ControllerManagerLeaderMigration` | `true` | Beta | 1.22 | | | `CustomCPUCFSQuotaPeriod` | `false` | Alpha | 1.12 | | +| `DaemonSetUpdateSurge` | `false` | Alpha | 1.21 | 1.21 | +| `DaemonSetUpdateSurge` | `true` | Beta | 1.22 | | | `DefaultPodTopologySpread` | `false` | Alpha | 1.19 | 1.19 | | `DefaultPodTopologySpread` | `true` | Beta | 1.20 | | +| `DelegateFSGroupToCSIDriver` | `false` | Alpha | 1.22 | | | `DevicePlugins` | `false` | Alpha | 1.8 | 1.9 | | `DevicePlugins` | `true` | Beta | 1.10 | | | `DisableAcceleratorUsageMetrics` | `false` | Alpha | 1.19 | 1.19 | | `DisableAcceleratorUsageMetrics` | `true` | Beta | 1.20 | | -| `DownwardAPIHugePages` | `false` | Alpha | 1.20 | | -| `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 | -| `DynamicKubeletConfig` | `true` | Beta | 1.11 | | -| `EfficientWatchResumption` | `false` | Alpha | 1.20 | | -| `EndpointSlice` | `false` | Alpha | 1.16 | 1.16 | -| `EndpointSlice` | `false` | Beta | 1.17 | | -| `EndpointSlice` | `true` | Beta | 1.18 | | -| `EndpointSliceNodeName` | `false` | Alpha | 1.20 | | -| `EndpointSliceProxying` | `false` | Alpha | 1.18 | 1.18 | -| `EndpointSliceProxying` | `true` | Beta | 1.19 | | -| `EndpointSliceTerminatingCondition` | `false` | Alpha | 1.20 | | +| `DisableCloudProviders` | `false` | Alpha | 1.22 | | +| `DownwardAPIHugePages` | `false` | Alpha | 1.20 | 1.20 | +| `DownwardAPIHugePages` | `false` | Beta | 1.21 | | +| `EfficientWatchResumption` | `false` | Alpha | 1.20 | 1.20 | +| `EfficientWatchResumption` | `true` | Beta | 1.21 | | +| `EndpointSliceTerminatingCondition` | `false` | Alpha | 1.20 | 1.21 | +| `EndpointSliceTerminatingCondition` | `true` | Beta | 1.22 | | | `EphemeralContainers` | `false` | Alpha | 1.16 | | | `ExpandCSIVolumes` | `false` | Alpha | 1.14 | 1.15 | | `ExpandCSIVolumes` | `true` | Beta | 1.16 | | +| `ExpandedDNSConfig` | `false` | Alpha | 1.22 | | | `ExpandInUsePersistentVolumes` | `false` | Alpha | 1.11 | 1.14 | | `ExpandInUsePersistentVolumes` | `true` | Beta | 1.15 | | | `ExpandPersistentVolumes` | `false` | Alpha | 1.8 | 1.10 | | `ExpandPersistentVolumes` | `true` | Beta | 1.11 | | | `ExperimentalHostUserNamespaceDefaulting` | `false` | Beta | 1.5 | | -| `GenericEphemeralVolume` | `false` | Alpha | 1.19 | | -| `GracefulNodeShutdown` | `false` | Alpha | 1.20 | | +| `GenericEphemeralVolume` | `false` | Alpha | 1.19 | 1.20 | +| `GenericEphemeralVolume` | `true` | Beta | 1.21 | | +| `GracefulNodeShutdown` | `false` | Alpha | 1.20 | 1.20 | +| `GracefulNodeShutdown` | `true` | Beta | 1.21 | | | `HPAContainerMetrics` | `false` | Alpha | 1.20 | | | `HPAScaleToZero` | `false` | Alpha | 1.16 | | -| `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | 1.18 | -| `HugePageStorageMediumSize` | `true` | Beta | 1.19 | | -| `IPv6DualStack` | `false` | Alpha | 1.15 | | -| `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | 1.18 | -| `ImmutableEphemeralVolumes` | `true` | Beta | 1.19 | | +| `IndexedJob` | `false` | Alpha | 1.21 | 1.21 | +| `IndexedJob` | `true` | Beta | 1.22 | | +| `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | | +| `IngressClassNamespacedParams` | `false` | Alpha | 1.21 | 1.21 | +| `IngressClassNamespacedParams` | `true` | Beta | 1.22 | | +| `InTreePluginAWSUnregister` | `false` | Alpha | 1.21 | | +| `InTreePluginAzureDiskUnregister` | `false` | Alpha | 1.21 | | +| `InTreePluginAzureFileUnregister` | `false` | Alpha | 1.21 | | +| `InTreePluginGCEUnregister` | `false` | Alpha | 1.21 | | +| `InTreePluginOpenStackUnregister` | `false` | Alpha | 1.21 | | +| `InTreePluginvSphereUnregister` | `false` | Alpha | 1.21 | | +| `IPv6DualStack` | `false` | Alpha | 1.15 | 1.20 | +| `IPv6DualStack` | `true` | Beta | 1.21 | | +| `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | | | `KubeletCredentialProviders` | `false` | Alpha | 1.20 | | -| `KubeletPodResources` | `true` | Alpha | 1.13 | 1.14 | -| `KubeletPodResources` | `true` | Beta | 1.15 | | -| `LegacyNodeRoleBehavior` | `false` | Alpha | 1.16 | 1.18 | -| `LegacyNodeRoleBehavior` | `true` | True | 1.19 | | | `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 | | `LocalStorageCapacityIsolation` | `true` | Beta | 1.10 | | | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | | +| `LogarithmicScaleDown` | `false` | Alpha | 1.21 | 1.21 | +| `LogarithmicScaleDown` | `true` | Beta | 1.22 | | +| `KubeletInUserNamespace` | `false` | Alpha | 1.22 | | +| `KubeletPodResourcesGetAllocatable` | `false` | Alpha | 1.21 | | +| `MemoryManager` | `false` | Alpha | 1.21 | 1.21 | +| `MemoryManager` | `true` | Beta | 1.22 | | +| `MemoryQoS` | `false` | Alpha | 1.22 | | | `MixedProtocolLBService` | `false` | Alpha | 1.20 | | -| `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | 1.18 | -| `NodeDisruptionExclusion` | `true` | Beta | 1.19 | | +| `NetworkPolicyEndPort` | `false` | Alpha | 1.21 | 1.21 | +| `NetworkPolicyEndPort` | `true` | Beta | 1.22 | | +| `NodeSwap` | `false` | Alpha | 1.22 | | | `NonPreemptingPriority` | `false` | Alpha | 1.15 | 1.18 | | `NonPreemptingPriority` | `true` | Beta | 1.19 | | -| `PodDisruptionBudget` | `false` | Alpha | 1.3 | 1.4 | -| `PodDisruptionBudget` | `true` | Beta | 1.5 | | +| `PodDeletionCost` | `false` | Alpha | 1.21 | 1.21 | +| `PodDeletionCost` | `true` | Beta | 1.22 | | +| `PodAffinityNamespaceSelector` | `false` | Alpha | 1.21 | 1.21 | +| `PodAffinityNamespaceSelector` | `true` | Beta | 1.22 | | | `PodOverhead` | `false` | Alpha | 1.16 | 1.17 | -| `PodOverhead` | `true` | Beta | 1.18 | | +| `PodOverhead` | `true` | Beta | 1.18 | | +| `PodSecurity` | `false` | Alpha | 1.22 | | +| `PreferNominatedNode` | `false` | Alpha | 1.21 | 1.21 | +| `PreferNominatedNode` | `true` | Beta | 1.22 | | +| `ProbeTerminationGracePeriod` | `false` | Alpha | 1.21 | 1.21 | +| `ProbeTerminationGracePeriod` | `false` | Beta | 1.22 | | | `ProcMountType` | `false` | Alpha | 1.12 | | +| `ProxyTerminatingEndpoints` | `false` | Alpha | 1.22 | | | `QOSReserved` | `false` | Alpha | 1.11 | | -| `RemainingItemCount` | `false` | Alpha | 1.15 | | +| `ReadWriteOncePod` | `false` | Alpha | 1.22 | | +| `RemainingItemCount` | `false` | Alpha | 1.15 | 1.15 | +| `RemainingItemCount` | `true` | Beta | 1.16 | | | `RemoveSelfLink` | `false` | Alpha | 1.16 | 1.19 | | `RemoveSelfLink` | `true` | Beta | 1.20 | | -| `RootCAConfigMap` | `false` | Alpha | 1.13 | 1.19 | -| `RootCAConfigMap` | `true` | Beta | 1.20 | | | `RotateKubeletServerCertificate` | `false` | Alpha | 1.7 | 1.11 | | `RotateKubeletServerCertificate` | `true` | Beta | 1.12 | | -| `RunAsGroup` | `true` | Beta | 1.14 | | -| `SCTPSupport` | `false` | Alpha | 1.12 | 1.18 | -| `SCTPSupport` | `true` | Beta | 1.19 | | -| `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 | -| `ServerSideApply` | `true` | Beta | 1.16 | | -| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | 1.19 | -| `ServiceAccountIssuerDiscovery` | `true` | Beta | 1.20 | | -| `ServiceLBNodePortControl` | `false` | Alpha | 1.20 | | -| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | 1.18 | -| `ServiceNodeExclusion` | `true` | Beta | 1.19 | | -| `ServiceTopology` | `false` | Alpha | 1.17 | | -| `SetHostnameAsFQDN` | `false` | Alpha | 1.19 | 1.19 | -| `SetHostnameAsFQDN` | `true` | Beta | 1.20 | | -| `SizeMemoryBackedVolumes` | `false` | Alpha | 1.20 | | +| `SeccompDefault` | `false` | Alpha | 1.22 | | +| `ServiceInternalTrafficPolicy` | `false` | Alpha | 1.21 | 1.21 | +| `ServiceInternalTrafficPolicy` | `true` | Beta | 1.22 | | +| `ServiceLBNodePortControl` | `false` | Alpha | 1.20 | 1.21 | +| `ServiceLBNodePortControl` | `true` | Beta | 1.22 | | +| `ServiceLoadBalancerClass` | `false` | Alpha | 1.21 | 1.21 | +| `ServiceLoadBalancerClass` | `true` | Beta | 1.22 | | +| `SizeMemoryBackedVolumes` | `false` | Alpha | 1.20 | 1.21 | +| `SizeMemoryBackedVolumes` | `true` | Beta | 1.22 | | +| `StatefulSetMinReadySeconds` | `false` | Alpha | 1.22 | | | `StorageVersionAPI` | `false` | Alpha | 1.20 | | | `StorageVersionHash` | `false` | Alpha | 1.14 | 1.14 | | `StorageVersionHash` | `true` | Beta | 1.15 | | -| `Sysctls` | `true` | Beta | 1.11 | | -| `TTLAfterFinished` | `false` | Alpha | 1.12 | | +| `SuspendJob` | `false` | Alpha | 1.21 | 1.21 | +| `SuspendJob` | `true` | Beta | 1.22 | | +| `TTLAfterFinished` | `false` | Alpha | 1.12 | 1.20 | +| `TTLAfterFinished` | `true` | Beta | 1.21 | | +| `TopologyAwareHints` | `false` | Alpha | 1.21 | | | `TopologyManager` | `false` | Alpha | 1.16 | 1.17 | | `TopologyManager` | `true` | Beta | 1.18 | | -| `ValidateProxyRedirects` | `false` | Alpha | 1.12 | 1.13 | -| `ValidateProxyRedirects` | `true` | Beta | 1.14 | | -| `WarningHeaders` | `true` | Beta | 1.19 | | +| `VolumeCapacityPriority` | `false` | Alpha | 1.21 | - | | `WinDSR` | `false` | Alpha | 1.14 | | | `WinOverlay` | `false` | Alpha | 1.14 | 1.19 | | `WinOverlay` | `true` | Beta | 1.20 | | -| `WindowsEndpointSliceProxying` | `false` | Alpha | 1.19 | | +| `WindowsHostProcessContainers` | `false` | Alpha | 1.22 | | {{< /table >}} ### Feature gates for graduated or deprecated features @@ -197,24 +217,50 @@ different Kubernetes components. | `AffinityInAnnotations` | - | Deprecated | 1.8 | - | | `AllowExtTrafficLocalEndpoints` | `false` | Beta | 1.4 | 1.6 | | `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - | +| `AttachVolumeLimit` | `false` | Alpha | 1.11 | 1.11 | +| `AttachVolumeLimit` | `true` | Beta | 1.12 | 1.16 | +| `AttachVolumeLimit` | `true` | GA | 1.17 | - | +| `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | 1.21 | +| `BalanceAttachedNodeVolumes` | `false` | Deprecated | 1.22 | | | `BlockVolume` | `false` | Alpha | 1.9 | 1.12 | | `BlockVolume` | `true` | Beta | 1.13 | 1.17 | | `BlockVolume` | `true` | GA | 1.18 | - | +| `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | 1.20 | +| `BoundServiceAccountTokenVolume` | `true` | Beta | 1.21 | 1.21 | +| `BoundServiceAccountTokenVolume` | `true` | GA | 1.22 | - | +| `CRIContainerLogRotation` | `false` | Alpha | 1.10 | 1.10 | +| `CRIContainerLogRotation` | `true` | Beta | 1.11 | 1.20 | +| `CRIContainerLogRotation` | `true` | GA | 1.21 | - | | `CSIBlockVolume` | `false` | Alpha | 1.11 | 1.13 | | `CSIBlockVolume` | `true` | Beta | 1.14 | 1.17 | | `CSIBlockVolume` | `true` | GA | 1.18 | - | | `CSIDriverRegistry` | `false` | Alpha | 1.12 | 1.13 | | `CSIDriverRegistry` | `true` | Beta | 1.14 | 1.17 | | `CSIDriverRegistry` | `true` | GA | 1.18 | | +| `CSIMigrationAWSComplete` | `false` | Alpha | 1.17 | 1.20 | +| `CSIMigrationAWSComplete` | - | Deprecated | 1.21 | - | +| `CSIMigrationAzureDiskComplete` | `false` | Alpha | 1.17 | 1.20 | +| `CSIMigrationAzureDiskComplete` | - | Deprecated | 1.21 | - | +| `CSIMigrationAzureFileComplete` | `false` | Alpha | 1.17 | 1.20 | +| `CSIMigrationAzureFileComplete` | - | Deprecated | 1.21 | - | +| `CSIMigrationGCEComplete` | `false` | Alpha | 1.17 | 1.20 | +| `CSIMigrationGCEComplete` | - | Deprecated | 1.21 | - | +| `CSIMigrationOpenStackComplete` | `false` | Alpha | 1.17 | 1.20 | +| `CSIMigrationOpenStackComplete` | - | Deprecated | 1.21 | - | +| `CSIMigrationvSphereComplete` | `false` | Beta | 1.19 | 1.21 | +| `CSIMigrationvSphereComplete` | - | Deprecated | 1.22 | - | | `CSINodeInfo` | `false` | Alpha | 1.12 | 1.13 | | `CSINodeInfo` | `true` | Beta | 1.14 | 1.16 | | `CSINodeInfo` | `true` | GA | 1.17 | | -| `AttachVolumeLimit` | `false` | Alpha | 1.11 | 1.11 | -| `AttachVolumeLimit` | `true` | Beta | 1.12 | 1.16 | -| `AttachVolumeLimit` | `true` | GA | 1.17 | - | | `CSIPersistentVolume` | `false` | Alpha | 1.9 | 1.9 | | `CSIPersistentVolume` | `true` | Beta | 1.10 | 1.12 | | `CSIPersistentVolume` | `true` | GA | 1.13 | - | +| `CSIServiceAccountToken` | `false` | Alpha | 1.20 | 1.20 | +| `CSIServiceAccountToken` | `true` | Beta | 1.21 | 1.21 | +| `CSIServiceAccountToken` | `true` | GA | 1.22 | | +| `CronJobControllerV2` | `false` | Alpha | 1.20 | 1.20 | +| `CronJobControllerV2` | `true` | Beta | 1.21 | 1.21 | +| `CronJobControllerV2` | `true` | GA | 1.22 | - | | `CustomPodDNS` | `false` | Alpha | 1.9 | 1.9 | | `CustomPodDNS` | `true` | Beta| 1.10 | 1.13 | | `CustomPodDNS` | `true` | GA | 1.14 | - | @@ -238,26 +284,51 @@ different Kubernetes components. | `DryRun` | `true` | GA | 1.19 | - | | `DynamicAuditing` | `false` | Alpha | 1.13 | 1.18 | | `DynamicAuditing` | - | Deprecated | 1.19 | - | +| `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 | +| `DynamicKubeletConfig` | `true` | Beta | 1.11 | 1.21 | +| `DynamicKubeletConfig` | `false` | Deprecated | 1.22 | - | | `DynamicProvisioningScheduling` | `false` | Alpha | 1.11 | 1.11 | | `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - | +| `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 | +| `DynamicKubeletConfig` | `true` | Beta | 1.11 | 1.21 | +| `DynamicKubeletConfig` | `false` | Deprecated | 1.22 | - | | `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 | | `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - | | `EnableAggregatedDiscoveryTimeout` | `true` | Deprecated | 1.16 | - | | `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | 1.14 | | `EnableEquivalenceClassCache` | - | Deprecated | 1.15 | - | +| `EndpointSlice` | `false` | Alpha | 1.16 | 1.16 | +| `EndpointSlice` | `false` | Beta | 1.17 | 1.17 | +| `EndpointSlice` | `true` | Beta | 1.18 | 1.20 | +| `EndpointSlice` | `true` | GA | 1.21 | - | +| `EndpointSliceNodeName` | `false` | Alpha | 1.20 | 1.20 | +| `EndpointSliceNodeName` | `true` | GA | 1.21 | - | +| `EndpointSliceProxying` | `false` | Alpha | 1.18 | 1.18 | +| `EndpointSliceProxying` | `true` | Beta | 1.19 | 1.21 | +| `EndpointSliceProxying` | `true` | GA | 1.22 | - | | `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | 1.12 | | `ExperimentalCriticalPodAnnotation` | `false` | Deprecated | 1.13 | - | | `EvenPodsSpread` | `false` | Alpha | 1.16 | 1.17 | | `EvenPodsSpread` | `true` | Beta | 1.18 | 1.18 | | `EvenPodsSpread` | `true` | GA | 1.19 | - | | `ExecProbeTimeout` | `true` | GA | 1.20 | - | +| `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - | | `GCERegionalPersistentDisk` | `true` | Beta | 1.10 | 1.12 | | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - | +| `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | 1.18 | +| `HugePageStorageMediumSize` | `true` | Beta | 1.19 | 1.21 | +| `HugePageStorageMediumSize` | `true` | GA | 1.22 | - | | `HugePages` | `false` | Alpha | 1.8 | 1.9 | | `HugePages` | `true` | Beta| 1.10 | 1.13 | | `HugePages` | `true` | GA | 1.14 | - | +| `HugePageStorageMediumSize` | `false` | Alpha | 1.18 | 1.18 | +| `HugePageStorageMediumSize` | `true` | Beta | 1.19 | 1.21 | +| `HugePageStorageMediumSize` | `true` | GA | 1.22 | - | | `HyperVContainer` | `false` | Alpha | 1.10 | 1.19 | | `HyperVContainer` | `false` | Deprecated | 1.20 | - | +| `ImmutableEphemeralVolumes` | `false` | Alpha | 1.18 | 1.18 | +| `ImmutableEphemeralVolumes` | `true` | Beta | 1.19 | 1.20 | +| `ImmutableEphemeralVolumes` | `true` | GA | 1.21 | | | `Initializers` | `false` | Alpha | 1.7 | 1.13 | | `Initializers` | - | Deprecated | 1.14 | - | | `KubeletConfigFile` | `false` | Alpha | 1.8 | 1.9 | @@ -268,19 +339,30 @@ different Kubernetes components. | `KubeletPodResources` | `false` | Alpha | 1.13 | 1.14 | | `KubeletPodResources` | `true` | Beta | 1.15 | | | `KubeletPodResources` | `true` | GA | 1.20 | | +| `LegacyNodeRoleBehavior` | `false` | Alpha | 1.16 | 1.18 | +| `LegacyNodeRoleBehavior` | `true` | Beta | 1.19 | 1.20 | +| `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | - | | `MountContainers` | `false` | Alpha | 1.9 | 1.16 | | `MountContainers` | `false` | Deprecated | 1.17 | - | | `MountPropagation` | `false` | Alpha | 1.8 | 1.9 | | `MountPropagation` | `true` | Beta | 1.10 | 1.11 | | `MountPropagation` | `true` | GA | 1.12 | - | +| `NodeDisruptionExclusion` | `false` | Alpha | 1.16 | 1.18 | +| `NodeDisruptionExclusion` | `true` | Beta | 1.19 | 1.20 | +| `NodeDisruptionExclusion` | `true` | GA | 1.21 | - | | `NodeLease` | `false` | Alpha | 1.12 | 1.13 | | `NodeLease` | `true` | Beta | 1.14 | 1.16 | | `NodeLease` | `true` | GA | 1.17 | - | +| `NamespaceDefaultLabelName` | `true` | Beta | 1.21 | 1.21 | +| `NamespaceDefaultLabelName` | `true` | GA | 1.22 | - | | `PVCProtection` | `false` | Alpha | 1.9 | 1.9 | | `PVCProtection` | - | Deprecated | 1.10 | - | | `PersistentLocalVolumes` | `false` | Alpha | 1.7 | 1.9 | | `PersistentLocalVolumes` | `true` | Beta | 1.10 | 1.13 | | `PersistentLocalVolumes` | `true` | GA | 1.14 | - | +| `PodDisruptionBudget` | `false` | Alpha | 1.3 | 1.4 | +| `PodDisruptionBudget` | `true` | Beta | 1.5 | 1.20 | +| `PodDisruptionBudget` | `true` | GA | 1.21 | - | | `PodPriority` | `false` | Alpha | 1.8 | 1.10 | | `PodPriority` | `true` | Beta | 1.11 | 1.13 | | `PodPriority` | `true` | GA | 1.14 | - | @@ -291,36 +373,60 @@ different Kubernetes components. | `PodShareProcessNamespace` | `true` | Beta | 1.12 | 1.16 | | `PodShareProcessNamespace` | `true` | GA | 1.17 | - | | `RequestManagement` | `false` | Alpha | 1.15 | 1.16 | +| `RequestManagement` | - | Derecated | 1.17 | - | | `ResourceLimitsPriorityFunction` | `false` | Alpha | 1.9 | 1.18 | | `ResourceLimitsPriorityFunction` | - | Deprecated | 1.19 | - | | `ResourceQuotaScopeSelectors` | `false` | Alpha | 1.11 | 1.11 | | `ResourceQuotaScopeSelectors` | `true` | Beta | 1.12 | 1.16 | | `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - | +| `RootCAConfigMap` | `false` | Alpha | 1.13 | 1.19 | +| `RootCAConfigMap` | `true` | Beta | 1.20 | 1.20 | +| `RootCAConfigMap` | `true` | GA | 1.21 | - | | `RotateKubeletClientCertificate` | `true` | Beta | 1.8 | 1.18 | | `RotateKubeletClientCertificate` | `true` | GA | 1.19 | - | +| `RunAsGroup` | `true` | Beta | 1.14 | 1.20 | +| `RunAsGroup` | `true` | GA | 1.21 | - | | `RuntimeClass` | `false` | Alpha | 1.12 | 1.13 | | `RuntimeClass` | `true` | Beta | 1.14 | 1.19 | | `RuntimeClass` | `true` | GA | 1.20 | - | -| `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 | -| `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | 1.16 | -| `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - | | `SCTPSupport` | `false` | Alpha | 1.12 | 1.18 | | `SCTPSupport` | `true` | Beta | 1.19 | 1.19 | | `SCTPSupport` | `true` | GA | 1.20 | - | +| `ScheduleDaemonSetPods` | `false` | Alpha | 1.11 | 1.11 | +| `ScheduleDaemonSetPods` | `true` | Beta | 1.12 | 1.16 | +| `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - | +| `SelectorIndex` | `false` | Alpha | 1.18 | 1.18 | +| `SelectorIndex` | `true` | Beta | 1.19 | 1.19 | +| `SelectorIndex` | `true` | GA | 1.20 | - | +| `ServerSideApply` | `false` | Alpha | 1.14 | 1.15 | +| `ServerSideApply` | `true` | Beta | 1.16 | 1.21 | +| `ServerSideApply` | `true` | GA | 1.22 | - | +| `ServiceAccountIssuerDiscovery` | `false` | Alpha | 1.18 | 1.19 | +| `ServiceAccountIssuerDiscovery` | `true` | Beta | 1.20 | 1.20 | +| `ServiceAccountIssuerDiscovery` | `true` | GA | 1.21 | - | | `ServiceAppProtocol` | `false` | Alpha | 1.18 | 1.18 | -| `ServiceAppProtocol` | `true` | Beta | 1.19 | | +| `ServiceAppProtocol` | `true` | Beta | 1.19 | 1.19 | | `ServiceAppProtocol` | `true` | GA | 1.20 | - | | `ServiceLoadBalancerFinalizer` | `false` | Alpha | 1.15 | 1.15 | | `ServiceLoadBalancerFinalizer` | `true` | Beta | 1.16 | 1.16 | | `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - | +| `ServiceNodeExclusion` | `false` | Alpha | 1.8 | 1.18 | +| `ServiceNodeExclusion` | `true` | Beta | 1.19 | 1.20 | +| `ServiceNodeExclusion` | `true` | GA | 1.21 | - | +| `ServiceTopology` | `false` | Alpha | 1.17 | 1.19 | +| `ServiceTopology` | `false` | Deprecated | 1.20 | - | +| `SetHostnameAsFQDN` | `false` | Alpha | 1.19 | 1.19 | +| `SetHostnameAsFQDN` | `true` | Beta | 1.20 | 1.21 | +| `SetHostnameAsFQDN` | `true` | GA | 1.22 | - | | `StartupProbe` | `false` | Alpha | 1.16 | 1.17 | | `StartupProbe` | `true` | Beta | 1.18 | 1.19 | | `StartupProbe` | `true` | GA | 1.20 | - | | `StorageObjectInUseProtection` | `true` | Beta | 1.10 | 1.10 | | `StorageObjectInUseProtection` | `true` | GA | 1.11 | - | | `StreamingProxyRedirects` | `false` | Beta | 1.5 | 1.5 | -| `StreamingProxyRedirects` | `true` | Beta | 1.6 | 1.18 | -| `StreamingProxyRedirects` | - | Deprecated| 1.19 | - | +| `StreamingProxyRedirects` | `true` | Beta | 1.6 | 1.17 | +| `StreamingProxyRedirects` | `true` | Deprecated | 1.18 | 1.21 | +| `StreamingProxyRedirects` | `false` | Deprecated | 1.22 | - | | `SupportIPVSProxyMode` | `false` | Alpha | 1.8 | 1.8 | | `SupportIPVSProxyMode` | `false` | Beta | 1.9 | 1.9 | | `SupportIPVSProxyMode` | `true` | Beta | 1.10 | 1.10 | @@ -331,6 +437,8 @@ different Kubernetes components. | `SupportPodPidsLimit` | `false` | Alpha | 1.10 | 1.13 | | `SupportPodPidsLimit` | `true` | Beta | 1.14 | 1.19 | | `SupportPodPidsLimit` | `true` | GA | 1.20 | - | +| `Sysctls` | `true` | Beta | 1.11 | 1.20 | +| `Sysctls` | `true` | GA | 1.21 | | | `TaintBasedEvictions` | `false` | Alpha | 1.6 | 1.12 | | `TaintBasedEvictions` | `true` | Beta | 1.13 | 1.17 | | `TaintBasedEvictions` | `true` | GA | 1.18 | - | @@ -343,25 +451,34 @@ different Kubernetes components. | `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 | | `TokenRequestProjection` | `true` | Beta | 1.12 | 1.19 | | `TokenRequestProjection` | `true` | GA | 1.20 | - | -| `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | 1.16 | -| `VolumeSnapshotDataSource` | `true` | Beta | 1.17 | 1.19 | -| `VolumeSnapshotDataSource` | `true` | GA | 1.20 | - | +| `ValidateProxyRedirects` | `false` | Alpha | 1.12 | 1.13 | +| `ValidateProxyRedirects` | `true` | Beta | 1.14 | 1.21 | +| `ValidateProxyRedirects` | `true` | Deprecated | 1.22 | - | | `VolumePVCDataSource` | `false` | Alpha | 1.15 | 1.15 | | `VolumePVCDataSource` | `true` | Beta | 1.16 | 1.17 | | `VolumePVCDataSource` | `true` | GA | 1.18 | - | | `VolumeScheduling` | `false` | Alpha | 1.9 | 1.9 | | `VolumeScheduling` | `true` | Beta | 1.10 | 1.12 | | `VolumeScheduling` | `true` | GA | 1.13 | - | +| `VolumeSnapshotDataSource` | `false` | Alpha | 1.12 | 1.16 | +| `VolumeSnapshotDataSource` | `true` | Beta | 1.17 | 1.19 | +| `VolumeSnapshotDataSource` | `true` | GA | 1.20 | - | | `VolumeSubpath` | `true` | GA | 1.10 | - | | `VolumeSubpathEnvExpansion` | `false` | Alpha | 1.14 | 1.14 | | `VolumeSubpathEnvExpansion` | `true` | Beta | 1.15 | 1.16 | | `VolumeSubpathEnvExpansion` | `true` | GA | 1.17 | - | +| `WarningHeaders` | `true` | Beta | 1.19 | 1.21 | +| `WarningHeaders` | `true` | GA | 1.22 | - | | `WatchBookmark` | `false` | Alpha | 1.15 | 1.15 | | `WatchBookmark` | `true` | Beta | 1.16 | 1.16 | | `WatchBookmark` | `true` | GA | 1.17 | - | +| `WindowsEndpointSliceProxying` | `false` | Alpha | 1.19 | 1.20 | +| `WindowsEndpointSliceProxying` | `true` | Beta | 1.21 | 1.21 | +| `WindowsEndpointSliceProxying` | `true` | GA | 1.22| - | | `WindowsGMSA` | `false` | Alpha | 1.14 | 1.15 | | `WindowsGMSA` | `true` | Beta | 1.16 | 1.17 | | `WindowsGMSA` | `true` | GA | 1.18 | - | +| `WindowsHostProcessContainers` | `false` | Alpha | 1.22 | | `WindowsRunAsUserName` | `false` | Alpha | 1.16 | 1.16 | | `WindowsRunAsUserName` | `true` | Beta | 1.17 | 1.17 | | `WindowsRunAsUserName` | `true` | GA | 1.18 | - | @@ -416,9 +533,10 @@ Each feature gate is designed for enabling/disabling a specific feature: prioritization and fairness at each server. (Renamed from `RequestManagement`) - `APIResponseCompression`: Compress the API responses for `LIST` or `GET` requests. - `APIServerIdentity`: Assign each API server an ID in a cluster. +- `APIServerTracing`: Add support for distributed tracing in the API server. - `Accelerators`: Enable Nvidia GPU support when using Docker - `AdvancedAuditing`: Enable [advanced auditing](/docs/tasks/debug-application-cluster/audit/#advanced-audit) -- `AffinityInAnnotations`(*deprecated*): Enable setting +- `AffinityInAnnotations`: Enable setting [Pod affinity or anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity). - `AllowExtTrafficLocalEndpoints`: Enable a service to route external requests to node local endpoints. - `AllowInsecureBackendProxy`: Enable the users to skip TLS verification of @@ -442,9 +560,17 @@ Each feature gate is designed for enabling/disabling a specific feature: extended tokens by starting `kube-apiserver` with flag `--service-account-extend-token-expiration=false`. Check [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md) for more details. +- `ControllerManagerLeaderMigration`: Enables Leader Migration for + [kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration) and + [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager) which allows a cluster operator to live migrate + controllers from the kube-controller-manager into an external controller-manager + (e.g. the cloud-controller-manager) in an HA cluster without downtime. - `CPUManager`: Enable container level CPU affinity support, see [CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/). -- `CRIContainerLogRotation`: Enable container log rotation for cri container runtime. +- `CPUManagerPolicyOptions`: Allow fine-tuning of CPUManager policies. +- `CRIContainerLogRotation`: Enable container log rotation for CRI container runtime. The default max size of a log file is 10MB and the + default max number of log files allowed for a container is 5. These values can be configured in the kubelet config. + See the [logging at node level](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) documentation for more details. - `CSIBlockVolume`: Enable external CSI volume drivers to support block storage. See the [`csi` raw block volume support](/docs/concepts/storage/volumes/#csi-raw-block-volume-support) documentation for more details. @@ -461,7 +587,9 @@ Each feature gate is designed for enabling/disabling a specific feature: kubelet and volume controllers and enables shims and translation logic to route volume operations from the AWS-EBS in-tree plugin to EBS CSI plugin. Requires CSIMigration and CSIMigrationAWS feature flags enabled and EBS CSI - plugin installed and configured on all nodes in the cluster. + plugin installed and configured on all nodes in the cluster. This flag has + been deprecated in favor of the `InTreePluginAWSUnregister` feature flag + which prevents the registration of in-tree EBS plugin. - `CSIMigrationAzureDisk`: Enables shims and translation logic to route volume operations from the Azure-Disk in-tree plugin to AzureDisk CSI plugin. Supports falling back to in-tree AzureDisk plugin if a node does not have @@ -472,7 +600,8 @@ Each feature gate is designed for enabling/disabling a specific feature: logic to route volume operations from the Azure-Disk in-tree plugin to AzureDisk CSI plugin. Requires CSIMigration and CSIMigrationAzureDisk feature flags enabled and AzureDisk CSI plugin installed and configured on all nodes - in the cluster. + in the cluster. This flag has been deprecated in favor of the + `InTreePluginAzureDiskUnregister` feature flag which prevents the registration of in-tree AzureDisk plugin. - `CSIMigrationAzureFile`: Enables shims and translation logic to route volume operations from the Azure-File in-tree plugin to AzureFile CSI plugin. Supports falling back to in-tree AzureFile plugin if a node does not have @@ -483,7 +612,9 @@ Each feature gate is designed for enabling/disabling a specific feature: logic to route volume operations from the Azure-File in-tree plugin to AzureFile CSI plugin. Requires CSIMigration and CSIMigrationAzureFile feature flags enabled and AzureFile CSI plugin installed and configured on all nodes - in the cluster. + in the cluster. This flag has been deprecated in favor of the + `InTreePluginAzureFileUnregister` feature flag which prevents the registration + of in-tree AzureFile plugin. - `CSIMigrationGCE`: Enables shims and translation logic to route volume operations from the GCE-PD in-tree plugin to PD CSI plugin. Supports falling back to in-tree GCE plugin if a node does not have PD CSI plugin installed and @@ -492,7 +623,8 @@ Each feature gate is designed for enabling/disabling a specific feature: kubelet and volume controllers and enables shims and translation logic to route volume operations from the GCE-PD in-tree plugin to PD CSI plugin. Requires CSIMigration and CSIMigrationGCE feature flags enabled and PD CSI - plugin installed and configured on all nodes in the cluster. + plugin installed and configured on all nodes in the cluster. This flag has + been deprecated in favor of the `InTreePluginGCEUnregister` feature flag which prevents the registration of in-tree GCE PD plugin. - `CSIMigrationOpenStack`: Enables shims and translation logic to route volume operations from the Cinder in-tree plugin to Cinder CSI plugin. Supports falling back to in-tree Cinder plugin if a node does not have Cinder CSI @@ -501,7 +633,8 @@ Each feature gate is designed for enabling/disabling a specific feature: kubelet and volume controllers and enables shims and translation logic to route volume operations from the Cinder in-tree plugin to Cinder CSI plugin. Requires CSIMigration and CSIMigrationOpenStack feature flags enabled and Cinder - CSI plugin installed and configured on all nodes in the cluster. + CSI plugin installed and configured on all nodes in the cluster. This flag has + been deprecated in favor of the `InTreePluginOpenStackUnregister` feature flag which prevents the registration of in-tree openstack cinder plugin. - `CSIMigrationvSphere`: Enables shims and translation logic to route volume operations from the vSphere in-tree plugin to vSphere CSI plugin. Supports falling back to in-tree vSphere plugin if a node does not have vSphere @@ -510,7 +643,8 @@ Each feature gate is designed for enabling/disabling a specific feature: and volume controllers and enables shims and translation logic to route volume operations from the vSphere in-tree plugin to vSphere CSI plugin. Requires CSIMigration and CSIMigrationvSphere feature flags enabled and vSphere CSI plugin installed and - configured on all nodes in the cluster. + configured on all nodes in the cluster. This flag has been deprecated in favor + of the `InTreePluginvSphereUnregister` feature flag which prevents the registration of in-tree vsphere plugin. - `CSINodeInfo`: Enable all logic related to the CSINodeInfo API object in csi.storage.k8s.io. - `CSIPersistentVolume`: Enable discovering and mounting volumes provisioned through a [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) @@ -525,14 +659,18 @@ Each feature gate is designed for enabling/disabling a specific feature: - `CSIVolumeFSGroupPolicy`: Allows CSIDrivers to use the `fsGroupPolicy` field. This field controls whether volumes created by a CSIDriver support volume ownership and permission modifications when these volumes are mounted. +- `CSIVolumeHealth`: Enable support for CSI volume health monitoring on node. +- `CSRDuration`: Allows clients to request a duration for certificates issued + via the Kubernetes CSR API. - `ConfigurableFSGroupPolicy`: Allows user to configure volume permission change policy for fsGroups when mounting a volume in a Pod. See [Configure volume permission and ownership change policy for Pods](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods) for more details. +- `ControllerManagerLeaderMigration`: Enables leader migration for + `kube-controller-manager` and `cloud-controller-manager`. - `CronJobControllerV2`: Use an alternative implementation of the {{< glossary_tooltip text="CronJob" term_id="cronjob" >}} controller. Otherwise, version 1 of the same controller is selected. - The version 2 controller provides experimental performance improvements. - `CustomCPUCFSQuotaPeriod`: Enable nodes to change `cpuCFSQuotaPeriod` in [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/). - `CustomPodDNS`: Enable customizing the DNS settings for a Pod using its `dnsConfig` property. @@ -546,29 +684,36 @@ Each feature gate is designed for enabling/disabling a specific feature: [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). - `CustomResourceWebhookConversion`: Enable webhook-based conversion on resources created from [CustomResourceDefinition](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). - troubleshoot a running Pod. +- `DaemonSetUpdateSurge`: Enables the DaemonSet workloads to maintain + availability during update per node. - `DefaultPodTopologySpread`: Enables the use of `PodTopologySpread` scheduling plugin to do [default spreading](/docs/concepts/workloads/pods/pod-topology-spread-constraints/#internal-default-constraints). -- `DevicePlugins`: Enable the [device-plugins](/docs/concepts/cluster-administration/device-plugins/) +- `DelegateFSGroupToCSIDriver`: If supported by the CSI driver, delegates the + role of applying `fsGroup` from a Pod's `securityContext` to the driver by + passing `fsGroup` through the NodeStageVolume and NodePublishVolume CSI calls. +- `DevicePlugins`: Enable the [device-plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) based resource provisioning on nodes. - `DisableAcceleratorUsageMetrics`: [Disable accelerator metrics collected by the kubelet](/docs/concepts/cluster-administration/system-metrics/#disable-accelerator-metrics). +- `DisableCloudProviders`: Disables any functionality in `kube-apiserver`, + `kube-controller-manager` and `kubelet` related to the `--cloud-provider` + component flag. - `DownwardAPIHugePages`: Enables usage of hugepages in [downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information). - `DryRun`: Enable server-side [dry run](/docs/reference/using-api/api-concepts/#dry-run) requests so that validation, merging, and mutation can be tested without committing. -- `DynamicAuditing`(*deprecated*): Used to enable dynamic auditing before v1.19. +- `DynamicAuditing`: Used to enable dynamic auditing before v1.19. - `DynamicKubeletConfig`: Enable the dynamic configuration of kubelet. See [Reconfigure kubelet](/docs/tasks/administer-cluster/reconfigure-kubelet/). - `DynamicProvisioningScheduling`: Extend the default scheduler to be aware of volume topology and handle PV provisioning. This feature is superseded by the `VolumeScheduling` feature completely in v1.12. -- `DynamicVolumeProvisioning`(*deprecated*): Enable the +- `DynamicVolumeProvisioning`: Enable the [dynamic provisioning](/docs/concepts/storage/dynamic-provisioning/) of persistent volumes to Pods. - `EfficientWatchResumption`: Allows for storage-originated bookmark (progress notify) events to be delivered to the users. This is only applied to watch operations. -- `EnableAggregatedDiscoveryTimeout` (*deprecated*): Enable the five second +- `EnableAggregatedDiscoveryTimeout`: Enable the five second timeout on aggregated discovery calls. - `EnableEquivalenceClassCache`: Enable the scheduler to cache equivalence of nodes when scheduling Pods. @@ -591,6 +736,9 @@ Each feature gate is designed for enabling/disabling a specific feature: now-corrected fault where Kubernetes ignored exec probe timeouts. See [readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes). - `ExpandCSIVolumes`: Enable the expanding of CSI volumes. +- `ExpandedDNSConfig`: Enable kubelet and kube-apiserver to allow more DNS + search paths and longer list of DNS search paths. See + [Expanded DNS Configuration](/docs/concepts/services-networking/dns-pod-service/#expanded-dns-configuration). - `ExpandInUsePersistentVolumes`: Enable expanding in-use PVCs. See [Resizing an in-use PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim). - `ExpandPersistentVolumes`: Enable the expanding of persistent volumes. See @@ -603,6 +751,7 @@ Each feature gate is designed for enabling/disabling a specific feature: host mounts, or containers that are privileged or using specific non-namespaced capabilities (e.g. `MKNODE`, `SYS_MODULE` etc.). This should only be enabled if user namespace remapping is enabled in the Docker daemon. +- `ExternalPolicyForExternalIP`: Fix a bug where ExternalTrafficPolicy is not applied to Service ExternalIPs. - `GCERegionalPersistentDisk`: Enable the regional PD feature on GCE. - `GenericEphemeralVolume`: Enables ephemeral, inline volumes that support all features of normal volumes (can be provided by third-party storage vendors, storage capacity tracking, @@ -624,20 +773,48 @@ Each feature gate is designed for enabling/disabling a specific feature: - `HyperVContainer`: Enable [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) for Windows containers. -- `IPv6DualStack`: Enable [dual stack](/docs/concepts/services-networking/dual-stack/) - support for IPv6. - `ImmutableEphemeralVolumes`: Allows for marking individual Secrets and ConfigMaps as immutable for better safety and performance. -- `KubeletConfigFile` (*deprecated*): Enable loading kubelet configuration from +- `InTreePluginAWSUnregister`: Stops registering the aws-ebs in-tree plugin in kubelet + and volume controllers. +- `InTreePluginAzureDiskUnregister`: Stops registering the azuredisk in-tree plugin in kubelet + and volume controllers. +- `InTreePluginAzureFileUnregister`: Stops registering the azurefile in-tree plugin in kubelet + and volume controllers. +- `InTreePluginGCEUnregister`: Stops registering the gce-pd in-tree plugin in kubelet + and volume controllers. +- `InTreePluginOpenStackUnregister`: Stops registering the OpenStack cinder in-tree plugin in kubelet + and volume controllers. +- `InTreePluginvSphereUnregister`: Stops registering the vSphere in-tree plugin in kubelet + and volume controllers. +- `IndexedJob`: Allows the [Job](/docs/concepts/workloads/controllers/job/) + controller to manage Pod completions per completion index. +- `IngressClassNamespacedParams`: Allow namespace-scoped parameters reference in + `IngressClass` resource. This feature adds two fields - `Scope` and `Namespace` + to `IngressClass.spec.parameters`. +- `Initializers`: Allow asynchronous coordination of object creation using the + Initializers admission plugin. +- `IPv6DualStack`: Enable [dual stack](/docs/concepts/services-networking/dual-stack/) + support for IPv6. +- `JobTrackingWithFinalizers`: Enables tracking [Job](/docs/concepts/workloads/controllers/job) + completions without relying on Pods remaining in the cluster indefinitely. + The Job controller uses Pod finalizers and a field in the Job status to keep + track of the finished Pods to count towards completion. +- `KubeletConfigFile`: Enable loading kubelet configuration from a file specified using a config file. See [setting kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/) for more details. - `KubeletCredentialProviders`: Enable kubelet exec credential providers for image pull credentials. +- `KubeletInUserNamespace`: Enables support for running kubelet in a {{}}. + See [Running Kubernetes Node Components as a Non-root User](/docs/tasks/administer-cluster/kubelet-in-userns/). - `KubeletPluginsWatcher`: Enable probe-based plugin watcher utility to enable kubelet to discover plugins such as [CSI volume drivers](/docs/concepts/storage/volumes/#csi). - `KubeletPodResources`: Enable the kubelet's pod resources gRPC endpoint. See [Support Device Monitoring](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md) for more details. +- `KubeletPodResourcesGetAllocatable`: Enable the kubelet's pod resources `GetAllocatableResources` functionality. + This API augments the [resource allocation reporting](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources) + with informations about the allocatable resources, enabling clients to properly track the free compute resources on a node. - `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the feature-specific labels provided by `NodeDisruptionExclusion` and `ServiceNodeExclusion`. @@ -652,42 +829,69 @@ Each feature gate is designed for enabling/disabling a specific feature: supports project quotas and they are enabled, use project quotas to monitor [emptyDir volume](/docs/concepts/storage/volumes/#emptydir) storage consumption rather than filesystem walk for better performance and accuracy. +- `LogarithmicScaleDown`: Enable semi-random selection of pods to evict on controller scaledown + based on logarithmic bucketing of pod timestamps. +- `MemoryManager`: Allows setting memory affinity for a container based on + NUMA topology. +- `MemoryQoS`: Enable memory protection and usage throttle on pod / container using cgroup v2 memory controller. - `MixedProtocolLBService`: Enable using different protocols in the same `LoadBalancer` type Service instance. -- `MountContainers` (*deprecated*): Enable using utility containers on host as - the volume mounter. +- `MountContainers`: Enable using utility containers on host as the volume mounter. - `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods. For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation). +- `NamespaceDefaultLabelName`: Configure the API Server to set an immutable {{< glossary_tooltip text="label" term_id="label" >}} + `kubernetes.io/metadata.name` on all namespaces, containing the namespace name. +- `NetworkPolicyEndPort`: Enable use of the field `endPort` in NetworkPolicy objects, allowing the selection of a port range instead of a single port. - `NodeDisruptionExclusion`: Enable use of the Node label `node.kubernetes.io/exclude-disruption` which prevents nodes from being evacuated during zone failures. - `NodeLease`: Enable the new Lease API to report node heartbeats, which could be used as a node health signal. +- `NodeSwap`: Enable the kubelet to allocate swap memory for Kubernetes workloads on a node. + Must be used with `KubeletConfiguration.failSwapOn` set to false. + For more details, please see [swap memory](/docs/concepts/architecture/nodes/#swap-memory) - `NonPreemptingPriority`: Enable `preemptionPolicy` field for PriorityClass and Pod. - `PVCProtection`: Enable the prevention of a PersistentVolumeClaim (PVC) from being deleted when it is still used by any Pod. +- `PodDeletionCost`: Enable the [Pod Deletion Cost](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost) + feature which allows users to influence ReplicaSet downscaling order. - `PersistentLocalVolumes`: Enable the usage of `local` volume type in Pods. Pod affinity has to be specified if requesting a `local` volume. - `PodDisruptionBudget`: Enable the [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) feature. +- `PodAffinityNamespaceSelector`: Enable the [Pod Affinity Namespace Selector](/docs/concepts/scheduling-eviction/assign-pod-node/#namespace-selector) + and [CrossNamespacePodAffinity](/docs/concepts/policy/resource-quotas/#cross-namespace-pod-affinity-quota) quota scope features. - `PodOverhead`: Enable the [PodOverhead](/docs/concepts/scheduling-eviction/pod-overhead/) feature to account for pod overheads. - `PodPriority`: Enable the descheduling and preemption of Pods based on their - [priorities](/docs/concepts/configuration/pod-priority-preemption/). + [priorities](/docs/concepts/scheduling-eviction/pod-priority-preemption/). - `PodReadinessGates`: Enable the setting of `PodReadinessGate` field for extending Pod readiness evaluation. See [Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate) for more details. +- `PodSecurity`: Enables the `PodSecurity` admission plugin. - `PodShareProcessNamespace`: Enable the setting of `shareProcessNamespace` in a Pod for sharing a single process namespace between containers running in a pod. More details can be found in [Share Process Namespace between Containers in a Pod](/docs/tasks/configure-pod-container/share-process-namespace/). +- `PreferNominatedNode`: This flag tells the scheduler whether the nominated + nodes will be checked first before looping through all the other nodes in + the cluster. +- `ProbeTerminationGracePeriod`: Enable [setting probe-level + `terminationGracePeriodSeconds`](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds) + on pods. See the [enhancement proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period) for more details. - `ProcMountType`: Enables control over the type proc mounts for containers by setting the `procMount` field of a SecurityContext. +- `ProxyTerminatingEndpoints`: Enable the kube-proxy to handle terminating + endpoints when `ExternalTrafficPolicy=Local`. - `QOSReserved`: Allows resource reservations at the QoS level preventing pods at lower QoS levels from bursting into resources requested at higher QoS levels (memory only for now). +- `ReadWriteOncePod`: Enables the usage of `ReadWriteOncePod` PersistentVolume + access mode. - `RemainingItemCount`: Allow the API servers to show a count of remaining items in the response to a [chunking list request](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks). - `RemoveSelfLink`: Deprecates and removes `selfLink` from ObjectMeta and ListMeta. -- `ResourceLimitsPriorityFunction` (*deprecated*): Enable a scheduler priority function that +- `RequestManagement`: Enables managing request concurrency with prioritization and fairness + at each API server. Deprecated by `APIPriorityAndFairness` since 1.17. +- `ResourceLimitsPriorityFunction`: Enable a scheduler priority function that assigns a lowest possible score of 1 to a node that satisfies at least one of the input Pod's cpu and memory limits. The intent is to break ties between nodes with same scores. @@ -711,15 +915,21 @@ Each feature gate is designed for enabling/disabling a specific feature: instead of the DaemonSet controller. - `SCTPSupport`: Enables the _SCTP_ `protocol` value in Pod, Service, Endpoints, EndpointSlice, and NetworkPolicy definitions. +- `SeccompDefault`: Enables the use of `RuntimeDefault` as the default seccomp profile for all workloads. + The seccomp profile is specified in the `securityContext` of a Pod and/or a Container. +- `SelectorIndex`: Allows label and field based indexes in API server watch + cache to accelerate list operations. - `ServerSideApply`: Enables the [Sever Side Apply (SSA)](/docs/reference/using-api/server-side-apply/) feature on the API Server. - `ServiceAccountIssuerDiscovery`: Enable OIDC discovery endpoints (issuer and JWKS URLs) for the service account issuer in the API server. See [Configure Service Accounts for Pods](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery) for more details. -- `ServiceAppProtocol`: Enables the `AppProtocol` field on Services and Endpoints. -- `ServiceLBNodePortControl`: Enables the `spec.allocateLoadBalancerNodePorts` - field on Services. +- `ServiceAppProtocol`: Enables the `appProtocol` field on Services and Endpoints. +- `ServiceInternalTrafficPolicy`: Enables the `internalTrafficPolicy` field on Services +- `ServiceLBNodePortControl`: Enables the `allocateLoadBalancerNodePorts` field on Services. +- `ServiceLoadBalancerClass`: Enables the `loadBalancerClass` field on Services. See + [Specifying class of load balancer implementation](/docs/concepts/services-networking/service/#load-balancer-class) for more details. - `ServiceLoadBalancerFinalizer`: Enable finalizer protection for Service load balancers. - `ServiceNodeExclusion`: Enable the exclusion of nodes from load balancers created by a cloud provider. A node is eligible for exclusion if labelled with @@ -728,8 +938,6 @@ Each feature gate is designed for enabling/disabling a specific feature: topology of the cluster. See [ServiceTopology](/docs/concepts/services-networking/service-topology/) for more details. -- `SizeMemoryBackedVolumes`: Enables kubelet support to size memory backed volumes. - See [volumes](/docs/concepts/storage/volumes) for more details. - `SetHostnameAsFQDN`: Enable the ability of setting Fully Qualified Domain Name(FQDN) as the hostname of a pod. See [Pod's `setHostnameAsFQDN` field](/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field). @@ -738,6 +946,8 @@ Each feature gate is designed for enabling/disabling a specific feature: - `StartupProbe`: Enable the [startup](/docs/concepts/workloads/pods/pod-lifecycle/#when-should-you-use-a-startup-probe) probe in the kubelet. +- `StatefulSetMinReadySeconds`: Allows `minReadySeconds` to be respected by + the StatefulSet controller. - `StorageObjectInUseProtection`: Postpone the deletion of PersistentVolume or PersistentVolumeClaim objects if they are still being used. - `StorageVersionAPI`: Enable the @@ -749,12 +959,15 @@ Each feature gate is designed for enabling/disabling a specific feature: Examples of streaming requests include the `exec`, `attach` and `port-forward` requests. - `SupportIPVSProxyMode`: Enable providing in-cluster service load balancing using IPVS. See [service proxies](/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies) for more details. -- `SupportPodPidsLimit`: Enable the support to limiting PIDs in Pods. - `SupportNodePidsLimit`: Enable the support to limiting PIDs on the Node. The parameter `pid=` in the `--system-reserved` and `--kube-reserved` options can be specified to ensure that the specified number of process IDs will be reserved for the system as a whole and for Kubernetes system daemons respectively. +- `SupportPodPidsLimit`: Enable the support to limiting PIDs in Pods. +- `SuspendJob`: Enable support to suspend and resume Jobs. See + [the Jobs docs](/docs/concepts/workloads/controllers/job/) for + more details. - `Sysctls`: Enable support for namespaced kernel parameters (sysctls) that can be set for each pod. See [sysctls](/docs/tasks/administer-cluster/sysctl-cluster/) for more details. @@ -770,30 +983,41 @@ Each feature gate is designed for enabling/disabling a specific feature: - `TokenRequest`: Enable the `TokenRequest` endpoint on service account resources. - `TokenRequestProjection`: Enable the injection of service account tokens into a Pod through a [`projected` volume](/docs/concepts/storage/volumes/#projected). +- `TopologyAwareHints`: Enables topology aware routing based on topology hints + in EndpointSlices. See [Topology Aware + Hints](/docs/concepts/services-networking/topology-aware-hints/) for more + details. - `TopologyManager`: Enable a mechanism to coordinate fine-grained hardware resource assignments for different components in Kubernetes. See [Control Topology Management Policies on a node](/docs/tasks/administer-cluster/topology-manager/). +- `ValidateProxyRedirects`: This flag controls whether the API server should + validate that redirects are only followed to the same host. Only used if the + `StreamingProxyRedirects` flag is enabled. +- `VolumeCapacityPriority`: Enable support for prioritizing nodes in different + topologies based on available PV capacity. - `VolumePVCDataSource`: Enable support for specifying an existing PVC as a DataSource. - `VolumeScheduling`: Enable volume topology aware scheduling and make the PersistentVolumeClaim (PVC) binding aware of scheduling decisions. It also enables the usage of [`local`](/docs/concepts/storage/volumes/#local) volume type when used together with the `PersistentLocalVolumes` feature gate. - `VolumeSnapshotDataSource`: Enable volume snapshot data source support. +- `VolumeSubpath`: Allow mounting a subpath of a volume in a container. - `VolumeSubpathEnvExpansion`: Enable `subPathExpr` field for expanding environment variables into a `subPath`. - `WarningHeaders`: Allow sending warning headers in API responses. - `WatchBookmark`: Enable support for watch bookmark events. - `WinDSR`: Allows kube-proxy to create DSR loadbalancers for Windows. - `WinOverlay`: Allows kube-proxy to run in overlay mode for Windows. -- `WindowsGMSA`: Enables passing of GMSA credential specs from pods to container runtimes. -- `WindowsRunAsUserName` : Enable support for running applications in Windows containers - with as a non-default user. See - [Configuring RunAsUserName](/docs/tasks/configure-pod-container/configure-runasusername) - for more details. - `WindowsEndpointSliceProxying`: When enabled, kube-proxy running on Windows will use EndpointSlices as the primary data source instead of Endpoints, enabling scalability and performance improvements. See [Enabling Endpoint Slices](/docs/tasks/administer-cluster/enabling-endpointslices/). +- `WindowsGMSA`: Enables passing of GMSA credential specs from pods to container runtimes. +- `WindowsHostProcessContainers`: Enables support for Windows HostProcess containers. +- `WindowsRunAsUserName` : Enable support for running applications in Windows containers + with as a non-default user. See + [Configuring RunAsUserName](/docs/tasks/configure-pod-container/configure-runasusername) + for more details. ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md b/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md index edf25ad835..77b354dc70 100644 --- a/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md +++ b/content/en/docs/reference/command-line-tools-reference/kube-apiserver.md @@ -5,6 +5,7 @@ weight: 30 auto_generated: true --- + /=true|false for a specific API group and version (e.g. apps/v1=true)
api/all=true|false controls all API versions
api/ga=true|false controls all API versions of the form v[0-9]+
api/beta=true|false controls all API versions of the form v[0-9]+beta[0-9]+
api/alpha=true|false controls all API versions of the form v[0-9]+alpha[0-9]+
api/legacy is deprecated, and will be removed in a future version

+ @@ -956,10 +985,10 @@ kube-apiserver [flags] - + - + @@ -1001,7 +1030,7 @@ kube-apiserver [flags] - + @@ -1015,7 +1044,7 @@ kube-apiserver [flags] - + @@ -1060,6 +1089,13 @@ kube-apiserver [flags] + + + + + + + @@ -1102,6 +1138,13 @@ kube-apiserver [flags] + + + + + + + diff --git a/content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md b/content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md index a7ad248e94..a8389c69f0 100644 --- a/content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md +++ b/content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md @@ -5,6 +5,7 @@ weight: 30 auto_generated: true --- + ., e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.

+ diff --git a/content/en/docs/reference/command-line-tools-reference/kube-proxy.md b/content/en/docs/reference/command-line-tools-reference/kube-proxy.md index ad9d8b022d..3306668093 100644 --- a/content/en/docs/reference/command-line-tools-reference/kube-proxy.md +++ b/content/en/docs/reference/command-line-tools-reference/kube-proxy.md @@ -5,6 +5,7 @@ weight: 30 auto_generated: true --- + ., e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.

+ + + + + + + + + + + + + + + + + + + + + + @@ -335,6 +455,13 @@ kube-proxy [flags] + + + + + + + @@ -342,6 +469,13 @@ kube-proxy [flags] + + + + + + + diff --git a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md index 913d7eb925..621bac8aa2 100644 --- a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md +++ b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md @@ -5,6 +5,7 @@ weight: 30 auto_generated: true --- + ., e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.

+ diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md index 1b1142913f..5d2458079e 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md @@ -10,7 +10,7 @@ content_type: concept -In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes master components, specifically kube-apiserver. +In a Kubernetes cluster, the components on the worker nodes - kubelet and kube-proxy - need to communicate with Kubernetes control plane components, specifically kube-apiserver. In order to ensure that communication is kept private, not interfered with, and ensure that each component of the cluster is talking to another trusted component, we strongly recommend using client TLS certificates on nodes. @@ -18,7 +18,7 @@ The normal process of bootstrapping these components, especially worker nodes th can be a challenging process as it is often outside of the scope of Kubernetes and requires significant additional work. This in turn, can make it challenging to initialize or scale a cluster. -In order to simplify the process, beginning in version 1.4, Kubernetes introduced a certificate request and signing API to simplify the process. The proposal can be +In order to simplify the process, beginning in version 1.4, Kubernetes introduced a certificate request and signing API. The proposal can be found [here](https://github.com/kubernetes/kubernetes/pull/20439). This document describes the process of node initialization, how to set up TLS client certificate bootstrapping for @@ -44,7 +44,7 @@ Note that the above process depends upon: All of the following are responsibilities of whoever sets up and manages the cluster: 1. Creating the CA key and certificate -2. Distributing the CA certificate to the master nodes, where kube-apiserver is running +2. Distributing the CA certificate to the control plane nodes, where kube-apiserver is running 3. Creating a key and certificate for each kubelet; strongly recommended to have a unique one, with a unique CN, for each kubelet 4. Signing the kubelet certificate using the CA key 5. Distributing the kubelet key and signed certificate to the specific node on which the kubelet is running @@ -90,9 +90,9 @@ In addition, you need your Kubernetes Certificate Authority (CA). ## Certificate Authority As without bootstrapping, you will need a Certificate Authority (CA) key and certificate. As without bootstrapping, these will be used -to sign the kubelet certificate. As before, it is your responsibility to distribute them to master nodes. +to sign the kubelet certificate. As before, it is your responsibility to distribute them to control plane nodes. -For the purposes of this document, we will assume these have been distributed to master nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key). +For the purposes of this document, we will assume these have been distributed to control plane nodes at `/var/lib/kubernetes/ca.pem` (certificate) and `/var/lib/kubernetes/ca-key.pem` (key). We will refer to these as "Kubernetes CA certificate and key". All Kubernetes components that use these certificates - kubelet, kube-apiserver, kube-controller-manager - assume the key and certificate to be PEM-encoded. @@ -167,7 +167,7 @@ If you want to use bootstrap tokens, you must enable it on kube-apiserver with t #### Token authentication file -kube-apiserver has an ability to accept tokens as authentication. +kube-apiserver has the ability to accept tokens as authentication. These tokens are arbitrary but should represent at least 128 bits of entropy derived from a secure random number generator (such as `/dev/urandom` on most modern Linux systems). There are multiple ways you can generate a token. For example: @@ -234,7 +234,7 @@ In order for the controller-manager to sign certificates, it needs the following ### Access to key and certificate -As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the master nodes. +As described earlier, you need to create a Kubernetes CA key and certificate, and distribute it to the control plane nodes. These will be used by the controller-manager to sign the kubelet certificates. Since these signed certificates will, in turn, be used by the kubelet to authenticate as a regular kubelet to kube-apiserver, it is important that the CA @@ -319,7 +319,7 @@ collection. ## kubelet configuration -Finally, with the master nodes properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet. +Finally, with the control plane nodes properly set up and all of the necessary authentication and authorization in place, we can configure the kubelet. The kubelet requires the following configuration to bootstrap: diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet.md b/content/en/docs/reference/command-line-tools-reference/kubelet.md index 0e4ed2216e..0531f0847a 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md @@ -6,31 +6,33 @@ weight: 28 ## {{% heading "synopsis" %}} - -The kubelet is the primary "node agent" that runs on each -node. It can register the node with the apiserver using one of: the hostname; a flag to override the hostname; or specific logic for a cloud provider. +The kubelet is the primary "node agent" that runs on each node. It can +register the node with the apiserver using one of: the hostname; a flag to +override the hostname; or specific logic for a cloud provider. The kubelet works in terms of a PodSpec. A PodSpec is a YAML or JSON object -that describes a pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms (primarily through the apiserver) and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn't manage containers which were not created by Kubernetes. +that describes a pod. The kubelet takes a set of PodSpecs that are provided +through various mechanisms (primarily through the apiserver) and ensures that +the containers described in those PodSpecs are running and healthy. The +kubelet doesn't manage containers which were not created by Kubernetes. -Other than from a PodSpec from the apiserver, there are three ways that a container manifest can be provided to the Kubelet. +Other than from a PodSpec from the apiserver, there are three ways that a +container manifest can be provided to the Kubelet. -File: Path passed as a flag on the command line. Files under this path will be monitored periodically for updates. The monitoring period is 20s by default and is configurable via a flag. - -HTTP endpoint: HTTP endpoint passed as a parameter on the command line. This endpoint is checked every 20 seconds (also configurable with a flag). - -HTTP server: The kubelet can also listen for HTTP and respond to a simple API (underspec'd currently) to submit a new manifest. +- File: Path passed as a flag on the command line. Files under this path will be + monitored periodically for updates. The monitoring period is 20s by default + and is configurable via a flag. +- HTTP endpoint: HTTP endpoint passed as a parameter on the command line. This + endpoint is checked every 20 seconds (also configurable with a flag). +- HTTP server: The kubelet can also listen for HTTP and respond to a simple API + (underspec'd currently) to submit a new manifest. ``` kubelet [flags] ``` - - - ## {{% heading "options" %}} -
Restricted policy specification
Everything from the baseline profile.
Volume TypesVolume Types - In addition to restricting HostPath volumes, the restricted profile limits usage of non-core volume types to those defined through PersistentVolumes.
-
Restricted Fields:
- spec.volumes[*].hostPath
- spec.volumes[*].gcePersistentDisk
- spec.volumes[*].awsElasticBlockStore
- spec.volumes[*].gitRepo
- spec.volumes[*].nfs
- spec.volumes[*].iscsi
- spec.volumes[*].glusterfs
- spec.volumes[*].rbd
- spec.volumes[*].flexVolume
- spec.volumes[*].cinder
- spec.volumes[*].cephFS
- spec.volumes[*].flocker
- spec.volumes[*].fc
- spec.volumes[*].azureFile
- spec.volumes[*].vsphereVolume
- spec.volumes[*].quobyte
- spec.volumes[*].azureDisk
- spec.volumes[*].portworxVolume
- spec.volumes[*].scaleIO
- spec.volumes[*].storageos
- spec.volumes[*].csi
-
Allowed Values: undefined/nil
+

In addition to restricting HostPath volumes, the restricted policy limits usage of non-core volume types to those defined through PersistentVolumes.

+

Restricted Fields

+
    +
  • spec.volumes[*].hostPath
    • +
  • spec.volumes[*].gcePersistentDisk
    • +
  • spec.volumes[*].awsElasticBlockStore
    • +
  • spec.volumes[*].gitRepo
    • +
  • spec.volumes[*].nfs
    • +
  • spec.volumes[*].iscsi
    • +
  • spec.volumes[*].glusterfs
    • +
  • spec.volumes[*].rbd
    • +
  • spec.volumes[*].flexVolume
    • +
  • spec.volumes[*].cinder
    • +
  • spec.volumes[*].cephfs
    • +
  • spec.volumes[*].flocker
    • +
  • spec.volumes[*].fc
    • +
  • spec.volumes[*].azureFile
    • +
  • spec.volumes[*].vsphereVolume
    • +
  • spec.volumes[*].quobyte
    • +
  • spec.volumes[*].azureDisk
    • +
  • spec.volumes[*].portworxVolume
    • +
  • spec.volumes[*].scaleIO
    • +
  • spec.volumes[*].storageos
    • +
  • spec.volumes[*].photonPersistentDisk
    • +
+

Allowed Values

+
    +
  • Undefined/nil
    • +
Privilege EscalationPrivilege Escalation (v1.8+) - Privilege escalation (such as via set-user-ID or set-group-ID file mode) should not be allowed.
-
Restricted Fields:
- spec.containers[*].securityContext.allowPrivilegeEscalation
- spec.initContainers[*].securityContext.allowPrivilegeEscalation
-
Allowed Values: false
+

Privilege escalation (such as via set-user-ID or set-group-ID file mode) should not be allowed.

+

Restricted Fields

+
    +
  • spec.containers[*].securityContext.allowPrivilegeEscalation
    • +
  • spec.initContainers[*].securityContext.allowPrivilegeEscalation
    • +
  • spec.ephemeralContainers[*].securityContext.allowPrivilegeEscalation
    • +
+

Allowed Values

+
    +
  • false
    • +
Running as Non-rootRunning as Non-root - Containers must be required to run as non-root users.
-
Restricted Fields:
- spec.securityContext.runAsNonRoot
- spec.containers[*].securityContext.runAsNonRoot
- spec.initContainers[*].securityContext.runAsNonRoot
-
Allowed Values: true
+

Containers must be required to run as non-root users.

+

Restricted Fields

+
    +
  • spec.securityContext.runAsNonRoot
    • +
  • spec.containers[*].securityContext.runAsNonRoot
    • +
  • spec.initContainers[*].securityContext.runAsNonRoot
    • +
  • spec.ephemeralContainers[*].securityContext.runAsNonRoot
    • +
+

Allowed Values

+
    +
  • true
    • +
+ + The container fields may be undefined/nil if the pod-level + spec.securityContext.runAsNonRoot is set to true. +
Non-root groups (optional)Non-root groups (optional) - Containers should be forbidden from running with a root primary or supplementary GID.
-
Restricted Fields:
- spec.securityContext.runAsGroup
- spec.securityContext.supplementalGroups[*]
- spec.securityContext.fsGroup
- spec.containers[*].securityContext.runAsGroup
- spec.initContainers[*].securityContext.runAsGroup
-
Allowed Values:
- non-zero
- undefined / nil (except for `*.runAsGroup`)
+

Containers should be forbidden from running with a root primary or supplementary GID.

+

Restricted Fields

+
    +
  • spec.securityContext.runAsGroup
    • +
  • spec.securityContext.supplementalGroups[*]
    • +
  • spec.securityContext.fsGroup
    • +
  • spec.containers[*].securityContext.runAsGroup
    • +
  • spec.initContainers[*].securityContext.runAsGroup
    • +
  • spec.ephemeralContainers[*].securityContext.runAsGroup
    • +
+

Allowed Values

+
    +
  • Undefined/nil (except for *.runAsGroup)
    • +
  • Non-zero
    • +
SeccompSeccomp (v1.19+) +

Seccomp profile must be explicitly set to one of the allowed values. Both the Unconfined profile and the absence of a profile are prohibited.

+

Restricted Fields

+
    +
  • spec.securityContext.seccompProfile.type
    • +
  • spec.containers[*].securityContext.seccompProfile.type
    • +
  • spec.initContainers[*].securityContext.seccompProfile.type
    • +
  • spec.ephemeralContainers[*].securityContext.seccompProfile.type
    • +
+

Allowed Values

+
    +
  • RuntimeDefault
    • +
  • Localhost
    • +
+ + The container fields may be undefined/nil if the pod-level + spec.securityContext.seccompProfile.type field is set appropriately. + Conversely, the pod-level field may be undefined/nil if _all_ container- + level fields are set. + +
Capabilities (v1.22+) - The RuntimeDefault seccomp profile must be required, or allow specific additional profiles.
-
Restricted Fields:
- spec.securityContext.seccompProfile.type
- spec.containers[*].securityContext.seccompProfile
- spec.initContainers[*].securityContext.seccompProfile
-
Allowed Values:
- 'runtime/default'
- undefined / nil
+

+ Containers must drop ALL capabilities, and are only permitted to add back + the NET_BIND_SERVICE capability. +

+

Restricted Fields

+
    +
  • spec.containers[*].securityContext.capabilities.drop
    • +
  • spec.initContainers[*].securityContext.capabilities.drop
    • +
  • spec.ephemeralContainers[*].securityContext.capabilities.drop
    • +
+

Allowed Values

+
    +
  • Any list of capabilities that includes ALL
    • +
+
+

Restricted Fields

+
    +
  • spec.containers[*].securityContext.capabilities.add
    • +
  • spec.initContainers[*].securityContext.capabilities.add
    • +
  • spec.ephemeralContainers[*].securityContext.capabilities.add
    • +
+

Allowed Values

+
    +
  • Undefined/nil
    • +
  • NET_BIND_SERVICE
    • +
admin None Allows admin access, intended to be granted within a namespace using a RoleBinding. + If used in a RoleBinding, allows read/write access to most resources in a namespace, including the ability to create roles and role bindings within the namespace. -This role does not allow write access to resource quota or to the namespace itself.
edit
view

A set of key=value pairs that enable or disable built-in APIs. Supported options are:
v1=true|false for the core API group
<group>/<version>=true|false for a specific API group and version (e.g. apps/v1=true)
api/all=true|false controls all API versions
api/ga=true|false controls all API versions of the form v[0-9]+
api/beta=true|false controls all API versions of the form v[0-9]+beta[0-9]+
api/alpha=true|false controls all API versions of the form v[0-9]+alpha[0-9]+
api/legacy is deprecated, and will be removed in a future version
--service-account-issuer string--service-account-issuer strings

Identifier of the service account token issuer. The issuer will assert this identifier in "iss" claim of issued tokens. This value is a string or URI. If this option is not a valid URI per the OpenID Discovery 1.0 spec, the ServiceAccountIssuerDiscovery feature will remain disabled, even if the feature gate is set to true. It is highly recommended that this value comply with the OpenID spec: https://openid.net/specs/openid-connect-discovery-1_0.html. In practice, this means that service-account-issuer must be an https URL. It is also highly recommended that this URL be capable of serving OpenID discovery documents at {service-account-issuer}/.well-known/openid-configuration.

Identifier of the service account token issuer. The issuer will assert this identifier in "iss" claim of issued tokens. This value is a string or URI. If this option is not a valid URI per the OpenID Discovery 1.0 spec, the ServiceAccountIssuerDiscovery feature will remain disabled, even if the feature gate is set to true. It is highly recommended that this value comply with the OpenID spec: https://openid.net/specs/openid-connect-discovery-1_0.html. In practice, this means that service-account-issuer must be an https URL. It is also highly recommended that this URL be capable of serving OpenID discovery documents at {service-account-issuer}/.well-known/openid-configuration. When this flag is specified multiple times, the first is used to generate tokens and all are used to determine which issuers are accepted.
--service-cluster-ip-range string

A CIDR notation IP range from which to assign service cluster IPs. This must not overlap with any IP ranges assigned to nodes or pods.

A CIDR notation IP range from which to assign service cluster IPs. This must not overlap with any IP ranges assigned to nodes or pods. Max of two dual-stack CIDRs is allowed.
--show-hidden-metrics-for-version string

The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is ., e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.

The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is <major>.<minor>, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.

The media type to use to store objects in storage. Some resources or storage backends may only support a specific media type and will ignore this setting.
--strict-transport-security-directives strings

List of directives for HSTS, comma separated. If this list is empty, then HSTS directives will not be added. Example: 'max-age=31536000,includeSubDomains,preload'

--tls-cert-file string

If set, the file that will be used to secure the secure port of the API server via token authentication.
--tracing-config-file string

File with apiserver tracing configuration.

-v, --v int

The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is <major>.<minor>, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.

The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is <major>.<minor>, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.

--skip-headers

If true, avoid header prefixes in the log messages

--skip-log-headers

If true, avoid headers when opening log files

--stderrthreshold int     Default: 2

logs at or above this threshold go to stderr

How long an idle UDP connection will be kept open (e.g. '250ms', '2s'). Must be greater than 0. Only applicable for proxy-mode=userspace
-v, --v int

number for the log level verbosity

--version version[=true]

Print version information and quit
--vmodule <comma-separated 'pattern=N' settings>

comma-separated list of pattern=N settings for file-filtered logging

--write-config-to string

The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is <major>.<minor>, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.
@@ -46,66 +48,66 @@ kubelet [flags] - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -119,49 +121,42 @@ kubelet [flags] - + - + - + - + - - + - + - - - - - - - - + - + @@ -182,35 +177,35 @@ kubelet [flags] - + - + - + - + - + - + - + - + @@ -224,28 +219,28 @@ kubelet [flags] - + - + - + - + - + - + - + @@ -253,140 +248,140 @@ kubelet [flags] - + - + - + - + - + - + - + - + - + - + - + + + + + + + + - + - + - + - + - + - + - + - + - - - - - - - - + - + - + - + - + - + - + - + - + - + - + @@ -397,177 +392,185 @@ kubelet [flags] - + - + - + - + - + - - + - + - + - + - + - +WindowsHostProcessContainers=true|false (ALPHA - default=false)
+(DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) - + - + - + - + - + - + - + @@ -581,21 +584,14 @@ WindowsEndpointSliceProxying=true|false (ALPHA - default=false)
- + - + - - - - - - - - + @@ -616,42 +612,42 @@ WindowsEndpointSliceProxying=true|false (ALPHA - default=false)
- + - + - + - + - + - + - + @@ -665,56 +661,56 @@ WindowsEndpointSliceProxying=true|false (ALPHA - default=false)
- + - + - + - + - + - + - + - + - + - + @@ -725,10 +721,10 @@ WindowsEndpointSliceProxying=true|false (ALPHA - default=false)
- + - + @@ -753,48 +749,48 @@ WindowsEndpointSliceProxying=true|false (ALPHA - default=false)
- + - + - + - + - + - + - + - + - + @@ -804,176 +800,182 @@ WindowsEndpointSliceProxying=true|false (ALPHA - default=false)
- + - + - + - + + + + + + + + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -984,63 +986,63 @@ WindowsEndpointSliceProxying=true|false (ALPHA - default=false)
- + - + - + - - - - - - - - + - + - + - + - + - + - + - + + + + + + + + @@ -1050,21 +1052,21 @@ WindowsEndpointSliceProxying=true|false (ALPHA - default=false)
- + - + - + @@ -1075,39 +1077,46 @@ WindowsEndpointSliceProxying=true|false (ALPHA - default=false)
- + - + - + - + + + + + + + - + - + - + - + @@ -1118,84 +1127,86 @@ WindowsEndpointSliceProxying=true|false (ALPHA - default=false)
- + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + @@ -1213,26 +1224,25 @@ Insecure values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_R - + - + - + - + - + - +
--address ip     Default: 0.0.0.0 --address string     Default: 0.0.0.0
The IP address for the Kubelet to serve on (set to `0.0.0.0` for all IPv4 interfaces and `::` for all IPv6 interfaces) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The IP address for the Kubelet to serve on (set to 0.0.0.0 or :: for listening in gll interfaces and IP families) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--allowed-unsafe-sysctls strings
Comma-separated whitelist of unsafe sysctls or unsafe sysctl patterns (ending in `*`). Use these at your own risk. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Comma-separated whitelist of unsafe sysctls or unsafe sysctl patterns (ending in *). Use these at your own risk. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--alsologtostderr
log to standard error as well as filesLog to standard error as well as files
--anonymous-auth     Default: true
Enables anonymous requests to the Kubelet server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of `system:anonymous`, and a group name of `system:unauthenticated`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Enables anonymous requests to the Kubelet server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of system:anonymous, and a group name of system:unauthenticated. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--authentication-token-webhook
Use the `TokenReview` API to determine authentication for bearer tokens. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Use the TokenReview API to determine authentication for bearer tokens. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--authentication-token-webhook-cache-ttl duration     Default: `2m0s`--authentication-token-webhook-cache-ttl duration     Default: 2m0s
The duration to cache responses from the webhook token authenticator. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The duration to cache responses from the webhook token authenticator. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--authorization-mode string
Authorization mode for Kubelet server. Valid options are `AlwaysAllow` or `Webhook`. `Webhook` mode uses the `SubjectAccessReview` API to determine authorization. (default "AlwaysAllow" when `--config` flag is not provided; "Webhook" when `--config` flag presents.) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Authorization mode for Kubelet server. Valid options are AlwaysAllow or Webhook. Webhook mode uses the SubjectAccessReview API to determine authorization. Default AlwaysAllow when --config flag is not provided; Webhook when --config flag presents. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--authorization-webhook-cache-authorized-ttl duration     Default: `5m0s`--authorization-webhook-cache-authorized-ttl duration     Default: 5m0s
The duration to cache 'authorized' responses from the webhook authorizer. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The duration to cache 'authorized' responses from the webhook authorizer. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--authorization-webhook-cache-unauthorized-ttl duration     Default: `30s`--authorization-webhook-cache-unauthorized-ttl duration     Default: 30s
The duration to cache 'unauthorized' responses from the webhook authorizer. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The duration to cache 'unauthorized' responses from the webhook authorizer. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--bootstrap-kubeconfig string
Path to a kubeconfig file that will be used to get client certificate for kubelet. If the file specified by `--kubeconfig` does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On success, a kubeconfig file referencing the generated client certificate and key is written to the path specified by `--kubeconfig`. The client certificate and key file will be stored in the directory pointed by `--cert-dir`.Path to a kubeconfig file that will be used to get client certificate for kubelet. If the file specified by --kubeconfig does not exist, the bootstrap kubeconfig is used to request a client certificate from the API server. On success, a kubeconfig file referencing the generated client certificate and key is written to the path specified by --kubeconfig. The client certificate and key file will be stored in the directory pointed by --cert-dir.
--cert-dir string     Default: `/var/lib/kubelet/pki`--cert-dir string     Default: /var/lib/kubelet/pki
The directory where the TLS certs are located. If `--tls-cert-file` and `--tls-private-key-file` are provided, this flag will be ignored.The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored.
--cgroup-driver string     Default: `cgroupfs`--cgroup-driver string     Default: cgroupfs
Driver that the kubelet uses to manipulate cgroups on the host. Possible values: `cgroupfs`, `systemd`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)/td> +Driver that the kubelet uses to manipulate cgroups on the host. Possible values: cgroupfs, systemd. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)/td>
--cgroup-root string     Default: `''`--cgroup-root string     Default: ''
Optional root cgroup to use for pods. This is handled by the container runtime on a best effort basis. Default: '', which means use the container runtime default. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cgroups-per-qos     Default: `true`--cgroups-per-qos     Default: true
Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--chaos-chance float
If > 0.0, introduce random client errors and latency. Intended for testing. (DEPRECATED: will be removed in a future version.)Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--client-ca-file string
If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cluster-dns strings
Comma-separated list of DNS server IP address. This value is used for containers DNS server in case of Pods with "dnsPolicy=ClusterFirst". Note: all DNS servers appearing in the list MUST serve the same set of records otherwise name resolution within the cluster may not work correctly. There is no guarantee as to which DNS server may be contacted for name resolution. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Comma-separated list of DNS server IP address. This value is used for containers DNS server in case of Pods with "dnsPolicy=ClusterFirst".
Note: all DNS servers appearing in the list MUST serve the same set of records otherwise name resolution within the cluster may not work correctly. There is no guarantee as to which DNS server may be contacted for name resolution. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cluster-domain string
Domain for this cluster. If set, kubelet will configure all containers to search this domain in addition to the host's search domains (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Domain for this cluster. If set, kubelet will configure all containers to search this domain in addition to the host's search domains (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cni-bin-dir string     Default: `/opt/cni/bin`--cni-bin-dir string     Default: /opt/cni/bin
<Warning: Alpha feature> A comma-separated list of full paths of directories in which to search for CNI plugin binaries. This docker-specific flag only works when container-runtime is set to `docker`.A comma-separated list of full paths of directories in which to search for CNI plugin binaries. This docker-specific flag only works when container-runtime is set to docker. (DEPRECATED: will be removed along with dockershim.)
--cni-cache-dir string     Default: `/var/lib/cni/cache`--cni-cache-dir string     Default: /var/lib/cni/cache
<Warning: Alpha feature> The full path of the directory in which CNI should store cache files. This docker-specific flag only works when container-runtime is set to `docker`.The full path of the directory in which CNI should store cache files. This docker-specific flag only works when container-runtime is set to docker. (DEPRECATED: will be removed along with dockershim.)
--cni-conf-dir string     Default: `/etc/cni/net.d`--cni-conf-dir string     Default: /etc/cni/net.d
<Warning: Alpha feature> The full path of the directory in which to search for CNI config files. This docker-specific flag only works when container-runtime is set to `docker`.<Warning: Alpha feature> The full path of the directory in which to search for CNI config files. This docker-specific flag only works when container-runtime is set to docker. (DEPRECATED: will be removed along with dockershim.)
--container-log-max-files int32     Default: 5
<Warning: Beta feature> Set the maximum number of container log files that can be present for a container. The number must be ≥ 2. This flag can only be used with `--container-runtime=remote`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)<Warning: Beta feature> Set the maximum number of container log files that can be present for a container. The number must be >= 2. This flag can only be used with --container-runtime=remote. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--container-log-max-size string     Default: `10Mi`--container-log-max-size string     Default: 10Mi
<Warning: Beta feature> Set the maximum size (e.g. 10Mi) of container log file before it is rotated. This flag can only be used with `--container-runtime=remote`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)<Warning: Beta feature> Set the maximum size (e.g. 10Mi) of container log file before it is rotated. This flag can only be used with --container-runtime=remote. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--container-runtime string     Default: `docker`--container-runtime string     Default: docker
The container runtime to use. Possible values: `docker`, `remote`.The container runtime to use. Possible values: docker, remote.
--container-runtime-endpoint string     Default: `unix:///var/run/dockershim.sock`--container-runtime-endpoint string     Default: unix:///var/run/dockershim.sock
[Experimental] The endpoint of remote runtime service. Currently unix socket endpoint is supported on Linux, while npipe and tcp endpoints are supported on windows. Examples: `unix:///var/run/dockershim.sock`, `npipe:////./pipe/dockershim`.[Experimental] The endpoint of remote runtime service. Currently unix socket endpoint is supported on Linux, while npipe and tcp endpoints are supported on windows. Examples: unix:///var/run/dockershim.sock, npipe:////./pipe/dockershim.
--contention-profiling
Enable lock contention profiling, if profiling is enabled (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Enable lock contention profiling, if profiling is enabled (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cpu-cfs-quota     Default: `true`--cpu-cfs-quota     Default: true
Enable CPU CFS quota enforcement for containers that specify CPU limits (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Enable CPU CFS quota enforcement for containers that specify CPU limits (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cpu-cfs-quota-period duration     Default: `100ms`--cpu-cfs-quota-period duration     Default: 100ms
Sets CPU CFS quota period value, `cpu.cfs_period_us`, defaults to Linux Kernel default. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Sets CPU CFS quota period value, cpu.cfs_period_us, defaults to Linux Kernel default. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cpu-manager-policy string     Default: `none`--cpu-manager-policy string     Default: none
CPU Manager policy to use. Possible values: `none`, `static`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)CPU Manager policy to use. Possible values: none, static. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--cpu-manager-reconcile-period duration     Default: `10s`--cpu-manager-policy-options strings
<Warning: Alpha feature> CPU Manager reconciliation period. Examples: `10s`, or `1m`. If not supplied, defaults to node status update frequency. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Comma-separated list of options to fine-tune the behavior of the selected CPU Manager policy. If not supplied, keep the default behaviour. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--docker-endpoint string     Default: `unix:///var/run/docker.sock`--cpu-manager-reconcile-period duration     Default: 10s
Use this for the `docker` endpoint to communicate with. This docker-specific flag only works when container-runtime is set to `docker`.<Warning: Alpha feature> CPU Manager reconciliation period. Examples: 10s, or 1m. If not supplied, defaults to node status update frequency. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--docker-endpoint string     Default: unix:///var/run/docker.sock
Use this for the docker endpoint to communicate with. This docker-specific flag only works when container-runtime is set to docker.
--dynamic-config-dir string
The Kubelet will use this directory for checkpointing downloaded configurations and tracking configuration health. The Kubelet will create this directory if it does not already exist. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Providing this flag enables dynamic Kubelet configuration. The `DynamicKubeletConfig` feature gate must be enabled to pass this flag; this gate currently defaults to `true` because the feature is beta.The Kubelet will use this directory for checkpointing downloaded configurations and tracking configuration health. The Kubelet will create this directory if it does not already exist. The path may be absolute or relative; relative paths start at the Kubelet's current working directory. Providing this flag enables dynamic Kubelet configuration. The DynamicKubeletConfig feature gate must be enabled to pass this flag. (DEPRECATED: Feature DynamicKubeletConfig is deprecated in 1.22 and will not move to GA. It is planned to be removed from Kubernetes in the version 1.23. Please use alternative ways to update kubelet configuration.)
--enable-cadvisor-json-endpoints     Default: `false`--enable-controller-attach-detach     Default: true
Enable cAdvisor json `/spec` and `/stats/*` endpoints. This flag has no effect on the /stats/summary endpoint. (DEPRECATED: will be removed in a future version)Enables the Attach/Detach controller to manage attachment/detachment of volumes scheduled to this node, and disables kubelet from executing any attach/detach operations. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--enable-controller-attach-detach     Default: `true`--enable-debugging-handlers     Default: true
Enables the Attach/Detach controller to manage attachment/detachment of volumes scheduled to this node, and disables kubelet from executing any attach/detach operations.Enables server endpoints for log collection and local running of containers and commands. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--enable-debugging-handlers     Default: `true`--enable-server     Default: true
Enables server endpoints for log collection and local running of containers and commands. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Enable the Kubelet's server. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--enable-server     Default: `true`--enforce-node-allocatable strings     Default: pods
Enable the Kubelet's server. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--enforce-node-allocatable strings     Default: `pods`
A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptable options are `none`, `pods`, `system-reserved`, and `kube-reserved`. If the latter two options are specified, `--system-reserved-cgroup` and `--kube-reserved-cgroup` must also be set, respectively. If `none` is specified, no additional options should be set. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptable options are none, pods, system-reserved, and kube-reserved. If the latter two options are specified, --system-reserved-cgroup and --kube-reserved-cgroup must also be set, respectively. If none is specified, no additional options should be set. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--event-burst int32     Default: 10
Maximum size of a bursty event records, temporarily allows event records to burst to this number, while still not exceeding `--event-qps`. Only used if `--event-qps` > 0. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Maximum size of a bursty event records, temporarily allows event records to burst to this number, while still not exceeding --event-qps. The number must be >= 0. If 0 will use default burst (10). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--event-qps int32     Default: 5
If > `0`, limit event creations per second to this value. If `0`, unlimited. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)QPS to limit event creations. The number must be >= 0. If 0 will use default QPS (5). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-hard mapStringString     Default: `imagefs.available<15%,memory.available<100Mi,nodefs.available<10%`--eviction-hard mapStringString     Default: imagefs.available<15%,memory.available<100Mi,nodefs.available<10%
A set of eviction thresholds (e.g. `memory.available<1Gi`) that if met would trigger a pod eviction. On a Linux node, the default value also includes `nodefs.inodesFree<5%`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)A set of eviction thresholds (e.g. memory.available<1Gi) that if met would trigger a pod eviction. On a Linux node, the default value also includes nodefs.inodesFree<5%. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-max-pod-grace-period int32
Maximum allowed grace period (in seconds) to use when terminating pods in response to a soft eviction threshold being met. If negative, defer to pod specified value. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) Maximum allowed grace period (in seconds) to use when terminating pods in response to a soft eviction threshold being met. If negative, defer to pod specified value. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-minimum-reclaim mapStringString
A set of minimum reclaims (e.g. `imagefs.available=2Gi`) that describes the minimum amount of resource the kubelet will reclaim when performing a pod eviction if that resource is under pressure. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)A set of minimum reclaims (e.g. imagefs.available=2Gi) that describes the minimum amount of resource the kubelet will reclaim when performing a pod eviction if that resource is under pressure. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-pressure-transition-period duration     Default: `5m0s`--eviction-pressure-transition-period duration     Default: 5m0s
Duration for which the kubelet has to wait before transitioning out of an eviction pressure condition. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Duration for which the kubelet has to wait before transitioning out of an eviction pressure condition. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-soft mapStringString
A set of eviction thresholds (e.g. `memory.available>1.5Gi`) that if met over a corresponding grace period would trigger a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)A set of eviction thresholds (e.g. memory.available<1.5Gi) that if met over a corresponding grace period would trigger a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--eviction-soft-grace-period mapStringString
A set of eviction grace periods (e.g. `memory.available=1m30s`) that correspond to how long a soft eviction threshold must hold before triggering a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)A set of eviction grace periods (e.g. memory.available=1m30s) that correspond to how long a soft eviction threshold must hold before triggering a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--experimental-allocatable-ignore-eviction     Default: `false`--experimental-allocatable-ignore-eviction     Default: false
When set to `true`, Hard eviction thresholds will be ignored while calculating node allocatable. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (DEPRECATED: will be removed in 1.23)When set to true, hard eviction thresholds will be ignored while calculating node allocatable. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (DEPRECATED: will be removed in 1.23)
--experimental-bootstrap-kubeconfig string
DEPRECATED: Use `--bootstrap-kubeconfig`DEPRECATED: Use --bootstrap-kubeconfig
--experimental-check-node-capabilities-before-mount
[Experimental] if set to `true`, the kubelet will check the underlying node for required components (binaries, etc.) before performing the mount (DEPRECATED: will be removed in 1.23, in favor of using CSI.)[Experimental] if set to true, the kubelet will check the underlying node for required components (binaries, etc.) before performing the mount (DEPRECATED: will be removed in 1.23, in favor of using CSI.)
--experimental-kernel-memcg-notification
If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling. This flag will be removed in 1.23. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling. This flag will be removed in 1.23. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--experimental-log-sanitization bool
[Experimental] When enabled prevents logging of fields tagged as sensitive (passwords, keys, tokens). Runtime log sanitization may introduce significant computation overhead and therefore should not be enabled in production. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +[Experimental] When enabled, prevents logging of fields tagged as sensitive (passwords, keys, tokens). Runtime log sanitization may introduce significant computation overhead and therefore should not be enabled in production. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--experimental-mounter-path string     Default: `mount`--experimental-mounter-path string     Default: mount
[Experimental] Path of mounter binary. Leave empty to use the default `mount`. (DEPRECATED: will be removed in 1.23, in favor of using CSI.)[Experimental] Path of mounter binary. Leave empty to use the default mount. (DEPRECATED: will be removed in 1.23, in favor of using CSI.)
--fail-swap-on     Default: `true`--fail-swap-on     Default: true
Makes the Kubelet fail to start if swap is enabled on the node. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Makes the Kubelet fail to start if swap is enabled on the node. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--feature-gates mapStringBool--feature-gates <A list of 'key=true/false' pairs>
A set of `key=value` pairs that describe feature gates for alpha/experimental features. Options are:
+		A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
APIListChunking=true|false (BETA - default=true)
APIPriorityAndFairness=true|false (BETA - default=true)
APIResponseCompression=true|false (BETA - default=true)
APIServerIdentity=true|false (ALPHA - default=false)
+APIServerTracing=true|false (ALPHA - default=false)
AllAlpha=true|false (ALPHA - default=false)
AllBeta=true|false (BETA - default=false)
-AllowInsecureBackendProxy=true|false (BETA - default=true)
AnyVolumeDataSource=true|false (ALPHA - default=false)
AppArmor=true|false (BETA - default=true)
-BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)
-BoundServiceAccountTokenVolume=true|false (ALPHA - default=false)
CPUManager=true|false (BETA - default=true)
-CRIContainerLogRotation=true|false (BETA - default=true)
+CPUManagerPolicyOptions=true|false (ALPHA - default=false)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (BETA - default=true)
CSIMigrationAWS=true|false (BETA - default=false)
-CSIMigrationAWSComplete=true|false (ALPHA - default=false)
CSIMigrationAzureDisk=true|false (BETA - default=false)
-CSIMigrationAzureDiskComplete=true|false (ALPHA - default=false)
-CSIMigrationAzureFile=true|false (ALPHA - default=false)
-CSIMigrationAzureFileComplete=true|false (ALPHA - default=false)
+CSIMigrationAzureFile=true|false (BETA - default=false)
CSIMigrationGCE=true|false (BETA - default=false)
-CSIMigrationGCEComplete=true|false (ALPHA - default=false)
-CSIMigrationOpenStack=true|false (BETA - default=false)
-CSIMigrationOpenStackComplete=true|false (ALPHA - default=false)
+CSIMigrationOpenStack=true|false (BETA - default=true)
CSIMigrationvSphere=true|false (BETA - default=false)
-CSIMigrationvSphereComplete=true|false (BETA - default=false)
-CSIServiceAccountToken=true|false (ALPHA - default=false)
-CSIStorageCapacity=true|false (ALPHA - default=false)
+CSIStorageCapacity=true|false (BETA - default=true)
CSIVolumeFSGroupPolicy=true|false (BETA - default=true)
+CSIVolumeHealth=true|false (ALPHA - default=false)
+CSRDuration=true|false (BETA - default=true)
ConfigurableFSGroupPolicy=true|false (BETA - default=true)
-CronJobControllerV2=true|false (ALPHA - default=false)
+ControllerManagerLeaderMigration=true|false (BETA - default=true)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
+DaemonSetUpdateSurge=true|false (BETA - default=true)
DefaultPodTopologySpread=true|false (BETA - default=true)
+DelegateFSGroupToCSIDriver=true|false (ALPHA - default=false)
DevicePlugins=true|false (BETA - default=true)
DisableAcceleratorUsageMetrics=true|false (BETA - default=true)
-DownwardAPIHugePages=true|false (ALPHA - default=false)
-DynamicKubeletConfig=true|false (BETA - default=true)
-EfficientWatchResumption=true|false (ALPHA - default=false)
-EndpointSlice=true|false (BETA - default=true)
-EndpointSliceNodeName=true|false (ALPHA - default=false)
-EndpointSliceProxying=true|false (BETA - default=true)
-EndpointSliceTerminatingCondition=true|false (ALPHA - default=false)
+DisableCloudProviders=true|false (ALPHA - default=false)
+DownwardAPIHugePages=true|false (BETA - default=false)
+EfficientWatchResumption=true|false (BETA - default=true)
+EndpointSliceTerminatingCondition=true|false (BETA - default=true)
EphemeralContainers=true|false (ALPHA - default=false)
ExpandCSIVolumes=true|false (BETA - default=true)
ExpandInUsePersistentVolumes=true|false (BETA - default=true)
ExpandPersistentVolumes=true|false (BETA - default=true)
+ExpandedDNSConfig=true|false (ALPHA - default=false)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
-GenericEphemeralVolume=true|false (ALPHA - default=false)
-GracefulNodeShutdown=true|false (ALPHA - default=false)
+GenericEphemeralVolume=true|false (BETA - default=true)
+GracefulNodeShutdown=true|false (BETA - default=true)
HPAContainerMetrics=true|false (ALPHA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
-HugePageStorageMediumSize=true|false (BETA - default=true)
-IPv6DualStack=true|false (ALPHA - default=false)
-ImmutableEphemeralVolumes=true|false (BETA - default=true)
+IPv6DualStack=true|false (BETA - default=true)
+InTreePluginAWSUnregister=true|false (ALPHA - default=false)
+InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)
+InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)
+InTreePluginGCEUnregister=true|false (ALPHA - default=false)
+InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)
+InTreePluginvSphereUnregister=true|false (ALPHA - default=false)
+IndexedJob=true|false (BETA - default=true)
+IngressClassNamespacedParams=true|false (BETA - default=true)
+JobTrackingWithFinalizers=true|false (ALPHA - default=false)
KubeletCredentialProviders=true|false (ALPHA - default=false)
+KubeletInUserNamespace=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
-LegacyNodeRoleBehavior=true|false (BETA - default=true)
+KubeletPodResourcesGetAllocatable=true|false (ALPHA - default=false)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
+LogarithmicScaleDown=true|false (BETA - default=true)
+MemoryManager=true|false (BETA - default=true)
+MemoryQoS=true|false (ALPHA - default=false)
MixedProtocolLBService=true|false (ALPHA - default=false)
-NodeDisruptionExclusion=true|false (BETA - default=true)
+NetworkPolicyEndPort=true|false (BETA - default=true)
+NodeSwap=true|false (ALPHA - default=false)
NonPreemptingPriority=true|false (BETA - default=true)
-PodDisruptionBudget=true|false (BETA - default=true)
+PodAffinityNamespaceSelector=true|false (BETA - default=true)
+PodDeletionCost=true|false (BETA - default=true)
PodOverhead=true|false (BETA - default=true)
+PodSecurity=true|false (ALPHA - default=false)
+PreferNominatedNode=true|false (BETA - default=true)
+ProbeTerminationGracePeriod=true|false (BETA - default=false)
ProcMountType=true|false (ALPHA - default=false)
+ProxyTerminatingEndpoints=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
+ReadWriteOncePod=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RemoveSelfLink=true|false (BETA - default=true)
-RootCAConfigMap=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
-RunAsGroup=true|false (BETA - default=true)
-ServerSideApply=true|false (BETA - default=true)
-ServiceAccountIssuerDiscovery=true|false (BETA - default=true)
-ServiceLBNodePortControl=true|false (ALPHA - default=false)
-ServiceNodeExclusion=true|false (BETA - default=true)
-ServiceTopology=true|false (ALPHA - default=false)
-SetHostnameAsFQDN=true|false (BETA - default=true)
-SizeMemoryBackedVolumes=true|false (ALPHA - default=false)
+SeccompDefault=true|false (ALPHA - default=false)
+ServiceInternalTrafficPolicy=true|false (BETA - default=true)
+ServiceLBNodePortControl=true|false (BETA - default=true)
+ServiceLoadBalancerClass=true|false (BETA - default=true)
+SizeMemoryBackedVolumes=true|false (BETA - default=true)
+StatefulSetMinReadySeconds=true|false (ALPHA - default=false)
StorageVersionAPI=true|false (ALPHA - default=false)
StorageVersionHash=true|false (BETA - default=true)
-Sysctls=true|false (BETA - default=true)
-TTLAfterFinished=true|false (ALPHA - default=false)
+SuspendJob=true|false (BETA - default=true)
+TTLAfterFinished=true|false (BETA - default=true)
+TopologyAwareHints=true|false (ALPHA - default=false)
TopologyManager=true|false (BETA - default=true)
-ValidateProxyRedirects=true|false (BETA - default=true)
-WarningHeaders=true|false (BETA - default=true)
+VolumeCapacityPriority=true|false (ALPHA - default=false)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (BETA - default=true)
-WindowsEndpointSliceProxying=true|false (ALPHA - default=false)
-(DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--file-check-frequency duration     Default: `20s`--file-check-frequency duration     Default: 20s
Duration between checking config files for new data. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Duration between checking config files for new data. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--hairpin-mode string     Default: `promiscuous-bridge`--hairpin-mode string     Default: promiscuous-bridge
How should the kubelet setup hairpin NAT. This allows endpoints of a Service to load balance back to themselves if they should try to access their own Service. Valid values are `promiscuous-bridge`, `hairpin-veth` and `none`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)How should the kubelet setup hairpin NAT. This allows endpoints of a Service to load balance back to themselves if they should try to access their own Service. Valid values are promiscuous-bridge, hairpin-veth and none. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--healthz-bind-address ip     Default: `127.0.0.1`--healthz-bind-address string     Default: 127.0.0.1
The IP address for the healthz server to serve on (set to `0.0.0.0` for all IPv4 interfaces and `::` for all IPv6 interfaces). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The IP address for the healthz server to serve on (set to 0.0.0.0 or :: for listening in all interfaces and IP families). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--healthz-port int32     Default: 10248
The port of the localhost healthz endpoint (set to `0` to disable). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The port of the localhost healthz endpoint (set to 0 to disable). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--hostname-override string
If non-empty, will use this string as identification instead of the actual hostname. If `--cloud-provider` is set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used).If non-empty, will use this string as identification instead of the actual hostname. If --cloud-provider is set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used).
--housekeeping-interval duration     Default: `10s`--http-check-frequency duration     Default: 20s
Interval between container housekeepings.
--http-check-frequency duration     Default: `20s`
Duration between checking HTTP for new data. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Duration between checking HTTP for new data. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--image-gc-high-threshold int32     Default: 85
The percent of disk usage after which image garbage collection is always run. Values must be within the range [0, 100], To disable image garbage collection, set to 100. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The percent of disk usage after which image garbage collection is always run. Values must be within the range [0, 100], To disable image garbage collection, set to 100. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--image-gc-low-threshold int32     Default: 80
The percent of disk usage before which image garbage collection is never run. Lowest disk usage to garbage collect to. Values must be within the range [0, 100] and should not be larger than that of `--image-gc-high-threshold`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The percent of disk usage before which image garbage collection is never run. Lowest disk usage to garbage collect to. Values must be within the range [0, 100] and should not be larger than that of --image-gc-high-threshold. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--image-pull-progress-deadline duration     Default: `1m0s`--image-pull-progress-deadline duration     Default: 1m0s
If no pulling progress is made before this deadline, the image pulling will be cancelled. This docker-specific flag only works when container-runtime is set to `docker`.If no pulling progress is made before this deadline, the image pulling will be cancelled. This docker-specific flag only works when container-runtime is set to docker. (DEPRECATED: will be removed along with dockershim.)
--image-service-endpoint string
[Experimental] The endpoint of remote image service. If not specified, it will be the same with `--container-runtime-endpoint` by default. Currently UNIX socket endpoint is supported on Linux, while npipe and TCP endpoints are supported on Windows. Examples: `unix:///var/run/dockershim.sock`, `npipe:////./pipe/dockershim`[Experimental] The endpoint of remote image service. If not specified, it will be the same with --container-runtime-endpoint by default. Currently UNIX socket endpoint is supported on Linux, while npipe and TCP endpoints are supported on Windows. Examples: unix:///var/run/dockershim.sock, npipe:////./pipe/dockershim
--iptables-drop-bit int32     Default: 15
The bit of the `fwmark` space to mark packets for dropping. Must be within the range [0, 31]. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The bit of the fwmark space to mark packets for dropping. Must be within the range [0, 31]. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--iptables-masquerade-bit int32     Default: 14
The bit of the `fwmark` space to mark packets for SNAT. Must be within the range [0, 31]. Please match this parameter with corresponding parameter in `kube-proxy`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The bit of the fwmark space to mark packets for SNAT. Must be within the range [0, 31]. Please match this parameter with corresponding parameter in kube-proxy. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kernel-memcg-notification
If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kube-api-burst int32     Default: 10
Burst to use while talking with kubernetes API server. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Burst to use while talking with kubernetes API server. The number must be >= 0. If 0 will use default burst (10). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kube-api-content-type string     Default: `application/vnd.kubernetes.protobuf`--kube-api-content-type string     Default: application/vnd.kubernetes.protobuf
Content type of requests sent to apiserver. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Content type of requests sent to apiserver. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kube-api-qps int32     Default: 5
QPS to use while talking with kubernetes API server. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)QPS to use while talking with kubernetes API server. The number must be >= 0. If 0 will use default QPS (5). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kube-reserved mapStringString     Default: <None>
A set of `=` (e.g. `cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100'`) pairs that describe resources reserved for kubernetes system components. Currently `cpu`, `memory` and local `ephemeral-storage` for root file system are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)A set of <resource name>=<resource quantity> (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100') pairs that describe resources reserved for kubernetes system components. Currently cpu, memory and local ephemeral-storage for root file system are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kube-reserved-cgroup string     Default: `''`--kube-reserved-cgroup string     Default: ''
Absolute name of the top level cgroup that is used to manage kubernetes components for which compute resources were reserved via `--kube-reserved` flag. Ex. `/kube-reserved`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Absolute name of the top level cgroup that is used to manage kubernetes components for which compute resources were reserved via --kube-reserved flag. Ex. /kube-reserved. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--kubeconfig string
Path to a kubeconfig file, specifying how to connect to the API server. Providing `--kubeconfig` enables API server mode, omitting `--kubeconfig` enables standalone mode. Path to a kubeconfig file, specifying how to connect to the API server. Providing --kubeconfig enables API server mode, omitting --kubeconfig enables standalone mode.
--kubelet-cgroups string
Optional absolute name of cgroups to create and run the Kubelet in. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Optional absolute name of cgroups to create and run the Kubelet in. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--log-backtrace-at traceLocation     Default: `:0`--log-backtrace-at <A string of format 'file:line'>     Default: ":0"
When logging hits line `:`, emit a stack trace.When logging hits line :, emit a stack trace.
--log-flush-frequency duration     Default: `5s`--log-flush-frequency duration     Default: 5s
Maximum number of seconds between log flushes.
--logging-format string     Default: `text`--logging-format string     Default: text
Sets the log format. Permitted formats: `text`, `json`.\nNon-default formats don't honor these flags: `--add-dir-header`, `--alsologtostderr`, `--log-backtrace-at`, `--log-dir`, `--log-file`, `--log-file-max-size`, `--logtostderr`, `--skip_headers`, `--skip_log_headers`, `--stderrthreshold`, `--log-flush-frequency`.\nNon-default choices are currently alpha and subject to change without warning. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Sets the log format. Permitted formats: text, json.
Non-default formats don't honor these flags: --add-dir-header, --alsologtostderr, --log-backtrace-at, --log-dir, --log-file, --log-file-max-size, --logtostderr, --skip_headers, --skip_log_headers, --stderrthreshold, --log-flush-frequency.
Non-default choices are currently alpha and subject to change without warning. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--logtostderr     Default: `true`--logtostderr     Default: true
log to standard error instead of files.
--make-iptables-util-chains     Default: `true`--make-iptables-util-chains     Default: true
If true, kubelet will ensure `iptables` utility rules are present on host. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)If true, kubelet will ensure iptables utility rules are present on host. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--manifest-url string
URL for accessing additional Pod specifications to run (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)URL for accessing additional Pod specifications to run (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--manifest-url-header string
Comma-separated list of HTTP headers to use when accessing the URL provided to `--manifest-url`. Multiple headers with the same name will be added in the same order provided. This flag can be repeatedly invoked. For example: `--manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful'` (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Comma-separated list of HTTP headers to use when accessing the URL provided to --manifest-url. Multiple headers with the same name will be added in the same order provided. This flag can be repeatedly invoked. For example: --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful' (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--master-service-namespace string     Default: `default`--master-service-namespace string     Default: default
The namespace from which the kubernetes master services should be injected into pods. (DEPRECATED: This flag will be removed in a future version.) --max-open-files int     Default: 1000000
Number of files that can be opened by Kubelet process. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Number of files that can be opened by Kubelet process. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--max-pods int32     Default: 110
Number of Pods that can run on this Kubelet. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Number of Pods that can run on this Kubelet. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--maximum-dead-containers int32     Default: -1
Maximum number of old instances of containers to retain globally. Each container takes up some disk space. To disable, set to a negative number. (DEPRECATED: Use `--eviction-hard` or `--eviction-soft` instead. Will be removed in a future version.)Maximum number of old instances of containers to retain globally. Each container takes up some disk space. To disable, set to a negative number. (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)
--maximum-dead-containers-per-container int32     Default: 1
Maximum number of old instances to retain per container. Each container takes up some disk space. (DEPRECATED: Use `--eviction-hard` or `--eviction-soft` instead. Will be removed in a future version.)Maximum number of old instances to retain per container. Each container takes up some disk space. (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)
--memory-manager-policy string     Default: None
Memory Manager policy to use. Possible values: 'None', 'Static'. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--minimum-container-ttl-duration duration
Minimum age for a finished container before it is garbage collected. Examples: `300ms`, `10s` or `2h45m` (DEPRECATED: Use `--eviction-hard` or `--eviction-soft` instead. Will be removed in a future version.)Minimum age for a finished container before it is garbage collected. Examples: '300ms', '10s' or '2h45m' (DEPRECATED: Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.)
--minimum-image-ttl-duration duration     Default: `2m0s`--minimum-image-ttl-duration duration     Default: 2m0s
Minimum age for an unused image before it is garbage collected. Examples: `300ms`, `10s` or `2h45m`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Minimum age for an unused image before it is garbage collected. Examples: '300ms', '10s' or '2h45m'. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--network-plugin string
<Warning: Alpha feature> The name of the network plugin to be invoked for various events in kubelet/pod lifecycle. This docker-specific flag only works when container-runtime is set to `docker`.The name of the network plugin to be invoked for various events in kubelet/pod lifecycle. This docker-specific flag only works when container-runtime is set to docker. (DEPRECATED: will be removed along with dockershim.)
--network-plugin-mtu int32
<Warning: Alpha feature> The MTU to be passed to the network plugin, to override the default. Set to `0` to use the default 1460 MTU. This docker-specific flag only works when container-runtime is set to `docker`.The MTU to be passed to the network plugin, to override the default. Set to 0 to use the default 1460 MTU. This docker-specific flag only works when container-runtime is set to docker. (DEPRECATED: will be removed along with dockershim.)
--node-ip string
IP address of the node. If set, kubelet will use this IP address for the nodeIP address (or comma-separated dual-stack IP addresses) of the node. If unset, kubelet will use the node's default IPv4 address, if any, or its default IPv6 address if it has no IPv4 addresses. You can pass '::' to make it prefer the default IPv6 address rather than the default IPv4 address.
--node-labels mapStringString
<Warning: Alpha feature>Labels to add when registering the node in the cluster. Labels must be `key=value pairs` separated by `,`. Labels in the `kubernetes.io` namespace must begin with an allowed prefix (`kubelet.kubernetes.io`, `node.kubernetes.io`) or be in the specifically allowed set (`beta.kubernetes.io/arch`, `beta.kubernetes.io/instance-type`, `beta.kubernetes.io/os`, `failure-domain.beta.kubernetes.io/region`, `failure-domain.beta.kubernetes.io/zone`, `kubernetes.io/arch`, `kubernetes.io/hostname`, `kubernetes.io/os`, `node.kubernetes.io/instance-type`, `topology.kubernetes.io/region`, `topology.kubernetes.io/zone`)<Warning: Alpha feature>Labels to add when registering the node in the cluster. Labels must be key=value pairs separated by ','. Labels in the 'kubernetes.io' namespace must begin with an allowed prefix ('kubelet.kubernetes.io', 'node.kubernetes.io') or be in the specifically allowed set ('beta.kubernetes.io/arch', 'beta.kubernetes.io/instance-type', 'beta.kubernetes.io/os', 'failure-domain.beta.kubernetes.io/region', 'failure-domain.beta.kubernetes.io/zone', 'kubernetes.io/arch', 'kubernetes.io/hostname', 'kubernetes.io/os', 'node.kubernetes.io/instance-type', 'topology.kubernetes.io/region', 'topology.kubernetes.io/zone')
--node-status-max-images int32     Default: 50
The maximum number of images to report in `node.status.images`. If `-1` is specified, no cap will be applied. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The maximum number of images to report in node.status.images. If -1 is specified, no cap will be applied. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--node-status-update-frequency duration     Default: `10s`--node-status-update-frequency duration     Default: 10s
Specifies how often kubelet posts node status to master. Note: be cautious when changing the constant, it must work with nodeMonitorGracePeriod in Node controller. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Specifies how often kubelet posts node status to master. Note: be cautious when changing the constant, it must work with nodeMonitorGracePeriod in Node controller. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--non-masquerade-cidr string     Default: `10.0.0.0/8`--non-masquerade-cidr string     Default: 10.0.0.0/8
Traffic to IPs outside this range will use IP masquerade. Set to `0.0.0.0/0` to never masquerade. (DEPRECATED: will be removed in a future version)Traffic to IPs outside this range will use IP masquerade. Set to '0.0.0.0/0' to never masquerade. (DEPRECATED: will be removed in a future version)
--one-output
If true, only write logs to their native severity level (vs also writing to each lower severity level. -If true, only write logs to their native severity level (vs also writing to each lower severity level).
--oom-score-adj int32     Default: -999
The oom-score-adj value for kubelet process. Values must be within the range [-1000, 1000]. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The oom-score-adj value for kubelet process. Values must be within the range [-1000, 1000]. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--pod-cidr string
The CIDR to use for pod IP addresses, only used in standalone mode. In cluster mode, this is obtained from the master. For IPv6, the maximum number of IP's allocated is 65536 (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The CIDR to use for pod IP addresses, only used in standalone mode. In cluster mode, this is obtained from the master. For IPv6, the maximum number of IP's allocated is 65536 (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--pod-infra-container-image string     Default: `k8s.gcr.io/pause:3.2`--pod-infra-container-image string     Default: k8s.gcr.io/pause:3.5
Specified image will not be pruned by the image garbage collector. When container-runtime is set to `docker`, all containers in each pod will use the network/ipc namespaces from this image. Other CRI implementations have their own configuration to set this image.Specified image will not be pruned by the image garbage collector. When container-runtime is set to docker, all containers in each pod will use the network/IPC namespaces from this image. Other CRI implementations have their own configuration to set this image.
--pod-manifest-path string
Path to the directory containing static pod files to run, or the path to a single static pod file. Files starting with dots will be ignored. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Path to the directory containing static pod files to run, or the path to a single static pod file. Files starting with dots will be ignored. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--pod-max-pids int     Default: -1
Set the maximum number of processes per pod. If `-1`, the kubelet defaults to the node allocatable PID capacity. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Set the maximum number of processes per pod. If -1, the kubelet defaults to the node allocatable PID capacity. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--pods-per-core int32
Number of Pods per core that can run on this Kubelet. The total number of Pods on this Kubelet cannot exceed `--max-pods`, so `--max-pods` will be used if this calculation results in a larger number of Pods allowed on the Kubelet. A value of `0` disables this limit. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Number of Pods per core that can run on this kubelet. The total number of pods on this kubelet cannot exceed --max-pods, so --max-pods will be used if this calculation results in a larger number of pods allowed on the kubelet. A value of 0 disables this limit. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--port int32     Default: 10250
The port for the Kubelet to serve on. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The port for the kubelet to serve on. (DEPRECATED: This parameter should be set via the config file specified by the kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--protect-kernel-defaults
Default kubelet behaviour for kernel tuning. If set, kubelet errors if any of kernel tunables is different than kubelet defaults. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) Default kubelet behaviour for kernel tuning. If set, kubelet errors if any of kernel tunables is different than kubelet defaults. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--provider-id string
Unique identifier for identifying the node in a machine database, i.e cloud provider. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Unique identifier for identifying the node in a machine database, i.e cloud provider. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--qos-reserved mapStringString
<Warning: Alpha feature> A set of `=` (e.g. `memory=50%`) pairs that describe how pod resource requests are reserved at the QoS level. Currently only memory is supported. Requires the `QOSReserved` feature gate to be enabled. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)<Warning: Alpha feature> A set of <resource name>=<percentage> (e.g. memory=50%) pairs that describe how pod resource requests are reserved at the QoS level. Currently only memory is supported. Requires the QOSReserved feature gate to be enabled. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--read-only-port int32     Default: 10255
The read-only port for the Kubelet to serve on with no authentication/authorization (set to `0` to disable). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The read-only port for the kubelet to serve on with no authentication/authorization (set to 0 to disable). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--redirect-container-streaming--register-node     Default: true
Enables container streaming redirect. If false, kubelet will proxy container streaming data between the API server and container runtime; if `true`, kubelet will return an HTTP redirect to the API server, and the API server will access container runtime directly. The proxy approach is more secure, but introduces some overhead. The redirect approach is more performant, but less secure because the connection between apiserver and container runtime may not be authenticated. (DEPRECATED: Container streaming redirection will be removed from the kubelet in v1.20, and this flag will be removed in v1.22. For more details, see http://git.k8s.io/enhancements/keps/sig-node/20191205-container-streaming-requests.md)Register the node with the API server. If --kubeconfig is not provided, this flag is irrelevant, as the Kubelet won't have an API server to register with.
--register-node     Default: `true`--register-schedulable     Default: true
Register the node with the API server. If `--kubeconfig` is not provided, this flag is irrelevant, as the Kubelet won't have an API server to register with. Default to `true`.
--register-schedulable     Default: `true`
Register the node as schedulable. Won't have any effect if `--register-node` is false. (DEPRECATED: will be removed in a future version)Register the node as schedulable. Won't have any effect if --register-node is false. (DEPRECATED: will be removed in a future version)
--register-with-taints mapStringString
Register the node with the given list of taints (comma separated `=:`). No-op if `--register-node` is `false`.Register the node with the given list of taints (comma separated <key>=<value>:<effect>). No-op if --register-node is false.
--registry-burst int32     Default: 10
Maximum size of a bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding `--registry-qps`. Only used if `--registry-qps > 0`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Maximum size of a bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding --registry-qps. Only used if --registry-qps is greater than 0. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--registry-qps int32     Default: 5
If > 0, limit registry pull QPS to this value. If `0`, unlimited. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)If > 0, limit registry pull QPS to this value. If 0, unlimited. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--reserved-cpus string
A comma-separated list of CPUs or CPU ranges that are reserved for system and kubernetes usage. This specific list will supersede cpu counts in `--system-reserved` and `--kube-reserved`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)A comma-separated list of CPUs or CPU ranges that are reserved for system and kubernetes usage. This specific list will supersede cpu counts in --system-reserved and --kube-reserved. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--resolv-conf string     Default: `/etc/resolv.conf`--reserved-memory string
Resolver configuration file used as the basis for the container DNS resolution configuration. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)A comma-separated list of memory reservations for NUMA nodes. (e.g. --reserved-memory 0:memory=1Gi,hugepages-1M=2Gi --reserved-memory 1:memory=2Gi). The total sum for each memory type should be equal to the sum of --kube-reserved, --system-reserved and --eviction-threshold. See https://kubernetes.io/docs/tasks/administer-cluster/memory-manager/#reserved-memory-flag for more details. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--root-dir string     Default: `/var/lib/kubelet`--resolv-conf string     Default: /etc/resolv.conf
Resolver configuration file used as the basis for the container DNS resolution configuration. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--root-dir string     Default: /var/lib/kubelet
Directory path for managing kubelet files (volume mounts, etc). --rotate-certificates
<Warning: Beta feature> Auto rotate the kubelet client certificates by requesting new certificates from the `kube-apiserver` when the certificate expiration approaches. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)<Warning: Beta feature> Auto rotate the kubelet client certificates by requesting new certificates from the kube-apiserver when the certificate expiration approaches. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--rotate-server-certificates
Auto-request and rotate the kubelet serving certificates by requesting new certificates from the `kube-apiserver` when the certificate expiration approaches. Requires the `RotateKubeletServerCertificate` feature gate to be enabled, and approval of the submitted `CertificateSigningRequest` objects. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Auto-request and rotate the kubelet serving certificates by requesting new certificates from the kube-apiserver when the certificate expiration approaches. Requires the RotateKubeletServerCertificate feature gate to be enabled, and approval of the submitted CertificateSigningRequest objects. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--runonce
If `true`, exit after spawning pods from local manifests or remote urls. Exclusive with `--enable-server` (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)If true, exit after spawning pods from local manifests or remote urls. Exclusive with --enable-server (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--runtime-request-timeout duration     Default: `2m0s`--runtime-request-timeout duration     Default: 2m0s
Timeout of all runtime requests except long running request - `pull`, `logs`, `exec` and `attach`. When timeout exceeded, kubelet will cancel the request, throw out an error and retry later. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Timeout of all runtime requests except long running request - pull, logs, exec and attach. When timeout exceeded, kubelet will cancel the request, throw out an error and retry later. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--seccomp-profile-root string     Default: `/var/lib/kubelet/seccomp`--seccomp-default RuntimeDefault
<Warning: Alpha feature> Directory path for seccomp profiles. (DEPRECATED: will be removed in 1.23, in favor of using the `/seccomp` directory) +<Warning: Alpha feature> Enable the use of RuntimeDefault as the default seccomp profile for all workloads. The SeccompDefault feature gate must be enabled to allow this flag, which is disabled by default.
--seccomp-profile-root string     Default: /var/lib/kubelet/seccomp
<Warning: Alpha feature> Directory path for seccomp profiles. (DEPRECATED: will be removed in 1.23, in favor of using the /seccomp directory)
--serialize-image-pulls     Default: `true`--serialize-image-pulls     Default: true
Pull images one at a time. We recommend *not* changing the default value on nodes that run docker daemon with version < 1.9 or an `aufs` storage backend. Issue #10959 has more details. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Pull images one at a time. We recommend *not* changing the default value on nodes that run docker daemon with version < 1.9 or an aufs storage backend. Issue #10959 has more details. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--skip-headers
If `true`, avoid header prefixes in the log messagesIf true, avoid header prefixes in the log messages
--skip-log-headers
If `true`, avoid headers when opening log filesIf true, avoid headers when opening log files
--streaming-connection-idle-timeout duration     Default: `4h0m0s`--streaming-connection-idle-timeout duration     Default: 4h0m0s
Maximum time a streaming connection can be idle before the connection is automatically closed. `0` indicates no timeout. Example: `5m`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Maximum time a streaming connection can be idle before the connection is automatically closed. 0 indicates no timeout. Example: 5m. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--sync-frequency duration     Default: `1m0s`--sync-frequency duration     Default: 1m0s
Max period between synchronizing running containers and config. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Max period between synchronizing running containers and config. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--system-cgroups string
Optional absolute name of cgroups in which to place all non-kernel processes that are not already inside a cgroup under `/`. Empty for no container. Rolling back the flag requires a reboot. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Optional absolute name of cgroups in which to place all non-kernel processes that are not already inside a cgroup under '/'. Empty for no container. Rolling back the flag requires a reboot. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--system-reserved mapStringString     Default: \--system-reserved mapStringString     Default: <none>
A set of `=` (e.g. `cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100'`) pairs that describe resources reserved for non-kubernetes components. Currently only `cpu` and `memory` are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)A set of <resource name>=<resource quantity> (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100') pairs that describe resources reserved for non-kubernetes components. Currently only cpu and memory are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--system-reserved-cgroup string     Default: `''`--system-reserved-cgroup string     Default: ''
Absolute name of the top level cgroup that is used to manage non-kubernetes components for which compute resources were reserved via `--system-reserved` flag. Ex. `/system-reserved`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Absolute name of the top level cgroup that is used to manage non-kubernetes components for which compute resources were reserved via --system-reserved flag. Ex. /system-reserved. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--tls-cert-file string
File containing x509 Certificate used for serving HTTPS (with intermediate certs, if any, concatenated after server cert). If `--tls-cert-file` and `--tls-private-key-file` are not provided, a self-signed certificate and key are generated for the public address and saved to the directory passed to `--cert-dir`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)File containing x509 Certificate used for serving HTTPS (with intermediate certs, if any, concatenated after server cert). If --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory passed to --cert-dir. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--tls-cipher-suites stringSlice--tls-cipher-suites strings
Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used.
Preferred values: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384.
-Insecure values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Insecure values: +TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA. +(DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--tls-min-version string
Minimum TLS version supported. Possible values: `VersionTLS10`, `VersionTLS11`, `VersionTLS12`, `VersionTLS13` (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--tls-private-key-file string
File containing x509 private key matching `--tls-cert-file`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)File containing x509 private key matching --tls-cert-file. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--topology-manager-policy string     Default: `none`--topology-manager-policy string     Default: 'none'
Topology Manager policy to use. Possible values: `none`, `best-effort`, `restricted`, `single-numa-node`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Topology Manager policy to use. Possible values: 'none', 'best-effort', 'restricted', 'single-numa-node'. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--topology-manager-scope string     Default: `container`--topology-manager-scope string     Default: container
Scope to which topology hints applied. Topology Manager collects hints from Hint Providers and applies them to defined scope to ensure the pod admission. Possible values: 'container' (default), 'pod'. (default "container") (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Scope to which topology hints applied. Topology Manager collects hints from Hint Providers and applies them to defined scope to ensure the pod admission. Possible values: 'container', 'pod'. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--vmodule moduleSpec--vmodule <A list of 'pattern=N' string>
Comma-separated list of `pattern=N` settings for file-filtered loggingComma-separated list of pattern=N settings for file-filtered logging
--volume-plugin-dir string     Default: `/usr/libexec/kubernetes/kubelet-plugins/volume/exec/`--volume-plugin-dir string     Default: /usr/libexec/kubernetes/kubelet-plugins/volume/exec/
The full path of the directory in which to search for additional third party volume plugins. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)The full path of the directory in which to search for additional third party volume plugins. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
--volume-stats-agg-period duration     Default: `1m0s`--volume-stats-agg-period duration     Default: 1m0s
Specifies interval for kubelet to calculate and cache the volume disk usage for all pods and volumes. To disable volume calculations, set to `0`. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's `--config` flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)Specifies interval for kubelet to calculate and cache the volume disk usage for all pods and volumes. To disable volume calculations, set to 0. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
- diff --git a/content/en/docs/reference/config-api/apiserver-audit.v1.md b/content/en/docs/reference/config-api/apiserver-audit.v1.md index f0f36c2344..11df06bd8c 100644 --- a/content/en/docs/reference/config-api/apiserver-audit.v1.md +++ b/content/en/docs/reference/config-api/apiserver-audit.v1.md @@ -81,7 +81,7 @@ For non-resource requests, this is the lower-cased HTTP method. user [Required]
-authentication/v1.UserInfo +authentication/v1.UserInfo Authenticated user information. @@ -89,7 +89,7 @@ For non-resource requests, this is the lower-cased HTTP method. impersonatedUser
-authentication/v1.UserInfo +authentication/v1.UserInfo Impersonated user information. @@ -123,7 +123,7 @@ Does not apply for List-type requests, or non-resource requests. responseStatus
-meta/v1.Status +meta/v1.Status The response status, populated even when the ResponseObject is not a Status type. @@ -154,7 +154,7 @@ at Response Level. requestReceivedTimestamp
-meta/v1.MicroTime +meta/v1.MicroTime Time the request reached the apiserver. @@ -162,7 +162,7 @@ at Response Level. stageTimestamp
-meta/v1.MicroTime +meta/v1.MicroTime Time the request reached current audit stage. @@ -206,7 +206,7 @@ EventList is a list of audit Events. metadata
-meta/v1.ListMeta +meta/v1.ListMeta No description provided. @@ -252,7 +252,7 @@ categories are logged. metadata
-meta/v1.ObjectMeta +meta/v1.ObjectMeta ObjectMeta is included for interoperability with API infrastructure.Refer to the Kubernetes API documentation for the fields of the metadata field. @@ -303,7 +303,7 @@ PolicyList is a list of audit Policies. metadata
-meta/v1.ListMeta +meta/v1.ListMeta No description provided. diff --git a/content/en/docs/reference/config-api/apiserver-config.v1alpha1.md b/content/en/docs/reference/config-api/apiserver-config.v1alpha1.md new file mode 100644 index 0000000000..81702355a5 --- /dev/null +++ b/content/en/docs/reference/config-api/apiserver-config.v1alpha1.md @@ -0,0 +1,438 @@ +--- +title: kube-apiserver Configuration (v1alpha1) +content_type: tool-reference +package: apiserver.k8s.io/v1alpha1 +auto_generated: true +--- +Package v1alpha1 is the v1alpha1 version of the API. + +## Resource Types + + +- [AdmissionConfiguration](#apiserver-k8s-io-v1alpha1-AdmissionConfiguration) +- [EgressSelectorConfiguration](#apiserver-k8s-io-v1alpha1-EgressSelectorConfiguration) +- [TracingConfiguration](#apiserver-k8s-io-v1alpha1-TracingConfiguration) + + + + +## `AdmissionConfiguration` {#apiserver-k8s-io-v1alpha1-AdmissionConfiguration} + + + + + +AdmissionConfiguration provides versioned configuration for admission controllers. + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		apiserver.k8s.io/v1alpha1
kind
string		AdmissionConfiguration
plugins
+[]AdmissionPluginConfiguration +		 + Plugins allows specifying a configuration per admission control plugin.
+ + + +## `EgressSelectorConfiguration` {#apiserver-k8s-io-v1alpha1-EgressSelectorConfiguration} + + + + + +EgressSelectorConfiguration provides versioned configuration for egress selector clients. + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		apiserver.k8s.io/v1alpha1
kind
string		EgressSelectorConfiguration
egressSelections [Required]
+[]EgressSelection +		 + connectionServices contains a list of egress selection client configurations
+ + + +## `TracingConfiguration` {#apiserver-k8s-io-v1alpha1-TracingConfiguration} + + + + + +TracingConfiguration provides versioned configuration for tracing clients. + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		apiserver.k8s.io/v1alpha1
kind
string		TracingConfiguration
endpoint
+string +		 + Endpoint of the collector that's running on the control-plane node. +The APIServer uses the egressType ControlPlane when sending data to the collector. +The syntax is defined in https://github.com/grpc/grpc/blob/master/doc/naming.md. +Defaults to the otlpgrpc default, localhost:4317 +The connection is insecure, and does not support TLS.
samplingRatePerMillion
+int32 +		 + SamplingRatePerMillion is the number of samples to collect per million spans. +Defaults to 0.
+ + + +## `AdmissionPluginConfiguration` {#apiserver-k8s-io-v1alpha1-AdmissionPluginConfiguration} + + + + +**Appears in:** + +- [AdmissionConfiguration](#apiserver-k8s-io-v1alpha1-AdmissionConfiguration) + + +AdmissionPluginConfiguration provides the configuration for a single plug-in. + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
name [Required]
+string +		 + Name is the name of the admission controller. +It must match the registered admission plugin name.
path
+string +		 + Path is the path to a configuration file that contains the plugin's +configuration
configuration
+k8s.io/apimachinery/pkg/runtime.Unknown +		 + Configuration is an embedded configuration object to be used as the plugin's +configuration. If present, it will be used instead of the path to the configuration file.
+ + + +## `Connection` {#apiserver-k8s-io-v1alpha1-Connection} + + + + +**Appears in:** + +- [EgressSelection](#apiserver-k8s-io-v1alpha1-EgressSelection) + + +Connection provides the configuration for a single egress selection client. + + + + + + + + + + + + + + + + + + +
FieldDescription
proxyProtocol [Required]
+ProtocolType +		 + Protocol is the protocol used to connect from client to the konnectivity server.
transport
+Transport +		 + Transport defines the transport configurations we use to dial to the konnectivity server. +This is required if ProxyProtocol is HTTPConnect or GRPC.
+ + + +## `EgressSelection` {#apiserver-k8s-io-v1alpha1-EgressSelection} + + + + +**Appears in:** + +- [EgressSelectorConfiguration](#apiserver-k8s-io-v1alpha1-EgressSelectorConfiguration) + + +EgressSelection provides the configuration for a single egress selection client. + + + + + + + + + + + + + + + + + + +
FieldDescription
name [Required]
+string +		 + name is the name of the egress selection. +Currently supported values are "controlplane", "master", "etcd" and "cluster" +The "master" egress selector is deprecated in favor of "controlplane"
connection [Required]
+Connection +		 + connection is the exact information used to configure the egress selection
+ + + +## `ProtocolType` {#apiserver-k8s-io-v1alpha1-ProtocolType} + +(Alias of `string`) + + +**Appears in:** + +- [Connection](#apiserver-k8s-io-v1alpha1-Connection) + + +ProtocolType is a set of valid values for Connection.ProtocolType + + + + + +## `TCPTransport` {#apiserver-k8s-io-v1alpha1-TCPTransport} + + + + +**Appears in:** + +- [Transport](#apiserver-k8s-io-v1alpha1-Transport) + + +TCPTransport provides the information to connect to konnectivity server via TCP + + + + + + + + + + + + + + + + + + +
FieldDescription
url [Required]
+string +		 + URL is the location of the konnectivity server to connect to. +As an example it might be "https://127.0.0.1:8131"
tlsConfig
+TLSConfig +		 + TLSConfig is the config needed to use TLS when connecting to konnectivity server
+ + + +## `TLSConfig` {#apiserver-k8s-io-v1alpha1-TLSConfig} + + + + +**Appears in:** + +- [TCPTransport](#apiserver-k8s-io-v1alpha1-TCPTransport) + + +TLSConfig provides the authentication information to connect to konnectivity server +Only used with TCPTransport + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
caBundle
+string +		 + caBundle is the file location of the CA to be used to determine trust with the konnectivity server. +Must be absent/empty if TCPTransport.URL is prefixed with http:// +If absent while TCPTransport.URL is prefixed with https://, default to system trust roots.
clientKey
+string +		 + clientKey is the file location of the client key to be used in mtls handshakes with the konnectivity server. +Must be absent/empty if TCPTransport.URL is prefixed with http:// +Must be configured if TCPTransport.URL is prefixed with https://
clientCert
+string +		 + clientCert is the file location of the client certificate to be used in mtls handshakes with the konnectivity server. +Must be absent/empty if TCPTransport.URL is prefixed with http:// +Must be configured if TCPTransport.URL is prefixed with https://
+ + + +## `Transport` {#apiserver-k8s-io-v1alpha1-Transport} + + + + +**Appears in:** + +- [Connection](#apiserver-k8s-io-v1alpha1-Connection) + + +Transport defines the transport configurations we use to dial to the konnectivity server + + + + + + + + + + + + + + + + + + +
FieldDescription
tcp
+TCPTransport +		 + TCP is the TCP configuration for communicating with the konnectivity server via TCP +ProxyProtocol of GRPC is not supported with TCP transport at the moment +Requires at least one of TCP or UDS to be set
uds
+UDSTransport +		 + UDS is the UDS configuration for communicating with the konnectivity server via UDS +Requires at least one of TCP or UDS to be set
+ + + +## `UDSTransport` {#apiserver-k8s-io-v1alpha1-UDSTransport} + + + + +**Appears in:** + +- [Transport](#apiserver-k8s-io-v1alpha1-Transport) + + +UDSTransport provides the information to connect to konnectivity server via UDS + + + + + + + + + + + + + +
FieldDescription
udsName [Required]
+string +		 + UDSName is the name of the unix domain socket to connect to konnectivity server +This does not use a unix:// prefix. (Eg: /etc/srv/kubernetes/konnectivity-server/konnectivity-server.socket)
+ + diff --git a/content/en/docs/reference/config-api/apiserver-webhookadmission.v1.md b/content/en/docs/reference/config-api/apiserver-webhookadmission.v1.md new file mode 100644 index 0000000000..fb45ca7b1a --- /dev/null +++ b/content/en/docs/reference/config-api/apiserver-webhookadmission.v1.md @@ -0,0 +1,46 @@ +--- +title: WebhookAdmission Configuration (v1) +content_type: tool-reference +package: apiserver.config.k8s.io/v1 +auto_generated: true +--- +Package v1 is the v1 version of the API. + +## Resource Types + + +- [WebhookAdmission](#apiserver-config-k8s-io-v1-WebhookAdmission) + + + + +## `WebhookAdmission` {#apiserver-config-k8s-io-v1-WebhookAdmission} + + + + + +WebhookAdmission provides configuration for the webhook admission controller. + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		apiserver.config.k8s.io/v1
kind
string		WebhookAdmission
kubeConfigFile [Required]
+string +		 + KubeConfigFile is the path to the kubeconfig file.
+ + diff --git a/content/en/docs/reference/config-api/client-authentication.v1beta1.md b/content/en/docs/reference/config-api/client-authentication.v1beta1.md index e78edd23f6..d018fb208f 100644 --- a/content/en/docs/reference/config-api/client-authentication.v1beta1.md +++ b/content/en/docs/reference/config-api/client-authentication.v1beta1.md @@ -187,6 +187,14 @@ ExecConfig.ProvideClusterInfo). +interactive [Required]
+bool + + + Interactive declares whether stdin has been passed to this exec plugin. + + + @@ -215,7 +223,7 @@ itself should at least be protected via file permissions. expirationTimestamp
-meta/v1.Time +meta/v1.Time ExpirationTimestamp indicates a time when the provided credentials expire. diff --git a/content/en/docs/reference/config-api/kube-proxy-config.v1alpha1.md b/content/en/docs/reference/config-api/kube-proxy-config.v1alpha1.md index e66bcd7443..94209488fe 100644 --- a/content/en/docs/reference/config-api/kube-proxy-config.v1alpha1.md +++ b/content/en/docs/reference/config-api/kube-proxy-config.v1alpha1.md @@ -9,7 +9,6 @@ auto_generated: true ## Resource Types - - [KubeProxyConfiguration](#kubeproxy-config-k8s-io-v1alpha1-KubeProxyConfiguration) @@ -535,3 +534,247 @@ this always falls back to the userspace proxy. + + + +## `ClientConnectionConfiguration` {#ClientConnectionConfiguration} + + + + +**Appears in:** + +- [KubeProxyConfiguration](#kubeproxy-config-k8s-io-v1alpha1-KubeProxyConfiguration) + +- [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration) + +- [GenericControllerManagerConfiguration](#controllermanager-config-k8s-io-v1alpha1-GenericControllerManagerConfiguration) + + +ClientConnectionConfiguration contains details for constructing a client. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
kubeconfig [Required]
+string +		 + kubeconfig is the path to a KubeConfig file.
acceptContentTypes [Required]
+string +		 + acceptContentTypes defines the Accept header sent by clients when connecting to a server, overriding the +default value of 'application/json'. This field will control all connections to the server used by a particular +client.
contentType [Required]
+string +		 + contentType is the content type used when sending data to the server from this client.
qps [Required]
+float32 +		 + qps controls the number of queries per second allowed for this connection.
burst [Required]
+int32 +		 + burst allows extra queries to accumulate when a client is exceeding its rate.
+ +## `DebuggingConfiguration` {#DebuggingConfiguration} + + + + +**Appears in:** + +- [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration) + +- [GenericControllerManagerConfiguration](#controllermanager-config-k8s-io-v1alpha1-GenericControllerManagerConfiguration) + + +DebuggingConfiguration holds configuration for Debugging related features. + + + + + + + + + + + + + + + + + + +
FieldDescription
enableProfiling [Required]
+bool +		 + enableProfiling enables profiling via web interface host:port/debug/pprof/
enableContentionProfiling [Required]
+bool +		 + enableContentionProfiling enables lock contention profiling, if +enableProfiling is true.
+ +## `LeaderElectionConfiguration` {#LeaderElectionConfiguration} + + + + +**Appears in:** + +- [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration) + +- [GenericControllerManagerConfiguration](#controllermanager-config-k8s-io-v1alpha1-GenericControllerManagerConfiguration) + + +LeaderElectionConfiguration defines the configuration of leader election +clients for components that can run with leader election enabled. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
leaderElect [Required]
+bool +		 + leaderElect enables a leader election client to gain leadership +before executing the main loop. Enable this when running replicated +components for high availability.
leaseDuration [Required]
+meta/v1.Duration +		 + leaseDuration is the duration that non-leader candidates will wait +after observing a leadership renewal until attempting to acquire +leadership of a led but unrenewed leader slot. This is effectively the +maximum duration that a leader can be stopped before it is replaced +by another candidate. This is only applicable if leader election is +enabled.
renewDeadline [Required]
+meta/v1.Duration +		 + renewDeadline is the interval between attempts by the acting master to +renew a leadership slot before it stops leading. This must be less +than or equal to the lease duration. This is only applicable if leader +election is enabled.
retryPeriod [Required]
+meta/v1.Duration +		 + retryPeriod is the duration the clients should wait between attempting +acquisition and renewal of a leadership. This is only applicable if +leader election is enabled.
resourceLock [Required]
+string +		 + resourceLock indicates the resource object type that will be used to lock +during leader election cycles.
resourceName [Required]
+string +		 + resourceName indicates the name of resource object that will be used to lock +during leader election cycles.
resourceNamespace [Required]
+string +		 + resourceName indicates the namespace of resource object that will be used to lock +during leader election cycles.
+ +## `LoggingConfiguration` {#LoggingConfiguration} + + + + +**Appears in:** + +- [KubeletConfiguration](#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) + + +LoggingConfiguration contains logging options +Refer [Logs Options](https://github.com/kubernetes/component-base/blob/master/logs/options.go) for more information. + + + + + + + + + + + + + + + + + + +
FieldDescription
format [Required]
+string +		 + Format Flag specifies the structure of log messages. +default value of format is `text`
sanitization [Required]
+bool +		 + [Experimental] When enabled prevents logging of fields tagged as sensitive (passwords, keys, tokens). +Runtime log sanitization may introduce significant computation overhead and therefore should not be enabled in production.`)
diff --git a/content/en/docs/reference/config-api/kube-scheduler-config.v1beta2.md b/content/en/docs/reference/config-api/kube-scheduler-config.v1beta2.md new file mode 100644 index 0000000000..1a28c03c88 --- /dev/null +++ b/content/en/docs/reference/config-api/kube-scheduler-config.v1beta2.md @@ -0,0 +1,2108 @@ +--- +title: kube-scheduler Configuration (v1beta2) +content_type: tool-reference +package: kubescheduler.config.k8s.io/v1beta2 +auto_generated: true +--- + + +## Resource Types + + +- [DefaultPreemptionArgs](#kubescheduler-config-k8s-io-v1beta2-DefaultPreemptionArgs) +- [InterPodAffinityArgs](#kubescheduler-config-k8s-io-v1beta2-InterPodAffinityArgs) +- [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration) +- [NodeAffinityArgs](#kubescheduler-config-k8s-io-v1beta2-NodeAffinityArgs) +- [NodeResourcesBalancedAllocationArgs](#kubescheduler-config-k8s-io-v1beta2-NodeResourcesBalancedAllocationArgs) +- [NodeResourcesFitArgs](#kubescheduler-config-k8s-io-v1beta2-NodeResourcesFitArgs) +- [PodTopologySpreadArgs](#kubescheduler-config-k8s-io-v1beta2-PodTopologySpreadArgs) +- [VolumeBindingArgs](#kubescheduler-config-k8s-io-v1beta2-VolumeBindingArgs) +- [Policy](#kubescheduler-config-k8s-io-v1-Policy) + + + +## `ClientConnectionConfiguration` {#ClientConnectionConfiguration} + + + + +**Appears in:** + +- [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration) + + +ClientConnectionConfiguration contains details for constructing a client. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
kubeconfig [Required]
+string +		 + kubeconfig is the path to a KubeConfig file.
acceptContentTypes [Required]
+string +		 + acceptContentTypes defines the Accept header sent by clients when connecting to a server, overriding the +default value of 'application/json'. This field will control all connections to the server used by a particular +client.
contentType [Required]
+string +		 + contentType is the content type used when sending data to the server from this client.
qps [Required]
+float32 +		 + qps controls the number of queries per second allowed for this connection.
burst [Required]
+int32 +		 + burst allows extra queries to accumulate when a client is exceeding its rate.
+ +## `DebuggingConfiguration` {#DebuggingConfiguration} + + + + +**Appears in:** + +- [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration) + + +DebuggingConfiguration holds configuration for Debugging related features. + + + + + + + + + + + + + + + + + + +
FieldDescription
enableProfiling [Required]
+bool +		 + enableProfiling enables profiling via web interface host:port/debug/pprof/
enableContentionProfiling [Required]
+bool +		 + enableContentionProfiling enables lock contention profiling, if +enableProfiling is true.
+ +## `LeaderElectionConfiguration` {#LeaderElectionConfiguration} + + + + +**Appears in:** + +- [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration) + + +LeaderElectionConfiguration defines the configuration of leader election +clients for components that can run with leader election enabled. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
leaderElect [Required]
+bool +		 + leaderElect enables a leader election client to gain leadership +before executing the main loop. Enable this when running replicated +components for high availability.
leaseDuration [Required]
+meta/v1.Duration +		 + leaseDuration is the duration that non-leader candidates will wait +after observing a leadership renewal until attempting to acquire +leadership of a led but unrenewed leader slot. This is effectively the +maximum duration that a leader can be stopped before it is replaced +by another candidate. This is only applicable if leader election is +enabled.
renewDeadline [Required]
+meta/v1.Duration +		 + renewDeadline is the interval between attempts by the acting master to +renew a leadership slot before it stops leading. This must be less +than or equal to the lease duration. This is only applicable if leader +election is enabled.
retryPeriod [Required]
+meta/v1.Duration +		 + retryPeriod is the duration the clients should wait between attempting +acquisition and renewal of a leadership. This is only applicable if +leader election is enabled.
resourceLock [Required]
+string +		 + resourceLock indicates the resource object type that will be used to lock +during leader election cycles.
resourceName [Required]
+string +		 + resourceName indicates the name of resource object that will be used to lock +during leader election cycles.
resourceNamespace [Required]
+string +		 + resourceName indicates the namespace of resource object that will be used to lock +during leader election cycles.
+ +## `LoggingConfiguration` {#LoggingConfiguration} + + + + +**Appears in:** + +- [KubeletConfiguration](#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) + + +LoggingConfiguration contains logging options +Refer [Logs Options](https://github.com/kubernetes/component-base/blob/master/logs/options.go) for more information. + + + + + + + + + + + + + + + + + + +
FieldDescription
format [Required]
+string +		 + Format Flag specifies the structure of log messages. +default value of format is `text`
sanitization [Required]
+bool +		 + [Experimental] When enabled prevents logging of fields tagged as sensitive (passwords, keys, tokens). +Runtime log sanitization may introduce significant computation overhead and therefore should not be enabled in production.`)
+ + + + +## `DefaultPreemptionArgs` {#kubescheduler-config-k8s-io-v1beta2-DefaultPreemptionArgs} + + + + + +DefaultPreemptionArgs holds arguments used to configure the +DefaultPreemption plugin. + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubescheduler.config.k8s.io/v1beta2
kind
string		DefaultPreemptionArgs
minCandidateNodesPercentage [Required]
+int32 +		 + MinCandidateNodesPercentage is the minimum number of candidates to +shortlist when dry running preemption as a percentage of number of nodes. +Must be in the range [0, 100]. Defaults to 10% of the cluster size if +unspecified.
minCandidateNodesAbsolute [Required]
+int32 +		 + MinCandidateNodesAbsolute is the absolute minimum number of candidates to +shortlist. The likely number of candidates enumerated for dry running +preemption is given by the formula: +numCandidates = max(numNodes ∗ minCandidateNodesPercentage, minCandidateNodesAbsolute) +We say "likely" because there are other factors such as PDB violations +that play a role in the number of candidates shortlisted. Must be at least +0 nodes. Defaults to 100 nodes if unspecified.
+ + + +## `InterPodAffinityArgs` {#kubescheduler-config-k8s-io-v1beta2-InterPodAffinityArgs} + + + + + +InterPodAffinityArgs holds arguments used to configure the InterPodAffinity plugin. + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubescheduler.config.k8s.io/v1beta2
kind
string		InterPodAffinityArgs
hardPodAffinityWeight [Required]
+int32 +		 + HardPodAffinityWeight is the scoring weight for existing pods with a +matching hard affinity to the incoming pod.
+ + + +## `KubeSchedulerConfiguration` {#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration} + + + + + +KubeSchedulerConfiguration configures a scheduler + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubescheduler.config.k8s.io/v1beta2
kind
string		KubeSchedulerConfiguration
parallelism [Required]
+int32 +		 + Parallelism defines the amount of parallelism in algorithms for scheduling a Pods. Must be greater than 0. Defaults to 16
leaderElection [Required]
+LeaderElectionConfiguration +		 + LeaderElection defines the configuration of leader election client.
clientConnection [Required]
+ClientConnectionConfiguration +		 + ClientConnection specifies the kubeconfig file and client connection +settings for the proxy server to use when communicating with the apiserver.
healthzBindAddress [Required]
+string +		 + HealthzBindAddress is the IP address and port for the health check server to serve on, +defaulting to 0.0.0.0:10251
metricsBindAddress [Required]
+string +		 + MetricsBindAddress is the IP address and port for the metrics server to +serve on, defaulting to 0.0.0.0:10251.
DebuggingConfiguration [Required]
+DebuggingConfiguration +		(Members of DebuggingConfiguration are embedded into this type.) + DebuggingConfiguration holds configuration for Debugging related features +TODO: We might wanna make this a substruct like Debugging componentbaseconfigv1alpha1.DebuggingConfiguration
percentageOfNodesToScore [Required]
+int32 +		 + PercentageOfNodesToScore is the percentage of all nodes that once found feasible +for running a pod, the scheduler stops its search for more feasible nodes in +the cluster. This helps improve scheduler's performance. Scheduler always tries to find +at least "minFeasibleNodesToFind" feasible nodes no matter what the value of this flag is. +Example: if the cluster size is 500 nodes and the value of this flag is 30, +then scheduler stops finding further feasible nodes once it finds 150 feasible ones. +When the value is 0, default percentage (5%--50% based on the size of the cluster) of the +nodes will be scored.
podInitialBackoffSeconds [Required]
+int64 +		 + PodInitialBackoffSeconds is the initial backoff for unschedulable pods. +If specified, it must be greater than 0. If this value is null, the default value (1s) +will be used.
podMaxBackoffSeconds [Required]
+int64 +		 + PodMaxBackoffSeconds is the max backoff for unschedulable pods. +If specified, it must be greater than podInitialBackoffSeconds. If this value is null, +the default value (10s) will be used.
profiles [Required]
+[]KubeSchedulerProfile +		 + Profiles are scheduling profiles that kube-scheduler supports. Pods can +choose to be scheduled under a particular profile by setting its associated +scheduler name. Pods that don't specify any scheduler name are scheduled +with the "default-scheduler" profile, if present here.
extenders [Required]
+[]Extender +		 + Extenders are the list of scheduler extenders, each holding the values of how to communicate +with the extender. These extenders are shared by all scheduler profiles.
+ + + +## `NodeAffinityArgs` {#kubescheduler-config-k8s-io-v1beta2-NodeAffinityArgs} + + + + + +NodeAffinityArgs holds arguments to configure the NodeAffinity plugin. + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubescheduler.config.k8s.io/v1beta2
kind
string		NodeAffinityArgs
addedAffinity
+core/v1.NodeAffinity +		 + AddedAffinity is applied to all Pods additionally to the NodeAffinity +specified in the PodSpec. That is, Nodes need to satisfy AddedAffinity +AND .spec.NodeAffinity. AddedAffinity is empty by default (all Nodes +match). +When AddedAffinity is used, some Pods with affinity requirements that match +a specific Node (such as Daemonset Pods) might remain unschedulable.
+ + + +## `NodeResourcesBalancedAllocationArgs` {#kubescheduler-config-k8s-io-v1beta2-NodeResourcesBalancedAllocationArgs} + + + + + +NodeResourcesBalancedAllocationArgs holds arguments used to configure NodeResourcesBalancedAllocation plugin. + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubescheduler.config.k8s.io/v1beta2
kind
string		NodeResourcesBalancedAllocationArgs
resources [Required]
+[]ResourceSpec +		 + Resources to be managed, the default is "cpu" and "memory" if not specified.
+ + + +## `NodeResourcesFitArgs` {#kubescheduler-config-k8s-io-v1beta2-NodeResourcesFitArgs} + + + + + +NodeResourcesFitArgs holds arguments used to configure the NodeResourcesFit plugin. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubescheduler.config.k8s.io/v1beta2
kind
string		NodeResourcesFitArgs
ignoredResources [Required]
+[]string +		 + IgnoredResources is the list of resources that NodeResources fit filter +should ignore. This doesn't apply to scoring.
ignoredResourceGroups [Required]
+[]string +		 + IgnoredResourceGroups defines the list of resource groups that NodeResources fit filter should ignore. +e.g. if group is ["example.com"], it will ignore all resource names that begin +with "example.com", such as "example.com/aaa" and "example.com/bbb". +A resource group name can't contain '/'. This doesn't apply to scoring.
scoringStrategy [Required]
+ScoringStrategy +		 + ScoringStrategy selects the node resource scoring strategy. +The default strategy is LeastAllocated with an equal "cpu" and "memory" weight.
+ + + +## `PodTopologySpreadArgs` {#kubescheduler-config-k8s-io-v1beta2-PodTopologySpreadArgs} + + + + + +PodTopologySpreadArgs holds arguments used to configure the PodTopologySpread plugin. + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubescheduler.config.k8s.io/v1beta2
kind
string		PodTopologySpreadArgs
defaultConstraints
+[]core/v1.TopologySpreadConstraint +		 + DefaultConstraints defines topology spread constraints to be applied to +Pods that don't define any in `pod.spec.topologySpreadConstraints`. +`.defaultConstraints[∗].labelSelectors` must be empty, as they are +deduced from the Pod's membership to Services, ReplicationControllers, +ReplicaSets or StatefulSets. +When not empty, .defaultingType must be "List".
defaultingType
+PodTopologySpreadConstraintsDefaulting +		 + DefaultingType determines how .defaultConstraints are deduced. Can be one +of "System" or "List". + +- "System": Use kubernetes defined constraints that spread Pods among + Nodes and Zones. +- "List": Use constraints defined in .defaultConstraints. + +Defaults to "List" if feature gate DefaultPodTopologySpread is disabled +and to "System" if enabled.
+ + + +## `VolumeBindingArgs` {#kubescheduler-config-k8s-io-v1beta2-VolumeBindingArgs} + + + + + +VolumeBindingArgs holds arguments used to configure the VolumeBinding plugin. + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubescheduler.config.k8s.io/v1beta2
kind
string		VolumeBindingArgs
bindTimeoutSeconds [Required]
+int64 +		 + BindTimeoutSeconds is the timeout in seconds in volume binding operation. +Value must be non-negative integer. The value zero indicates no waiting. +If this value is nil, the default value (600) will be used.
shape
+[]UtilizationShapePoint +		 + Shape specifies the points defining the score function shape, which is +used to score nodes based on the utilization of statically provisioned +PVs. The utilization is calculated by dividing the total requested +storage of the pod by the total capacity of feasible PVs on each node. +Each point contains utilization (ranges from 0 to 100) and its +associated score (ranges from 0 to 10). You can turn the priority by +specifying different scores for different utilization numbers. +The default shape points are: +1) 0 for 0 utilization +2) 10 for 100 utilization +All points must be sorted in increasing order by utilization.
+ + + +## `Extender` {#kubescheduler-config-k8s-io-v1beta2-Extender} + + + + +**Appears in:** + +- [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration) + + +Extender holds the parameters used to communicate with the extender. If a verb is unspecified/empty, +it is assumed that the extender chose not to provide that extension. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
urlPrefix [Required]
+string +		 + URLPrefix at which the extender is available
filterVerb [Required]
+string +		 + Verb for the filter call, empty if not supported. This verb is appended to the URLPrefix when issuing the filter call to extender.
preemptVerb [Required]
+string +		 + Verb for the preempt call, empty if not supported. This verb is appended to the URLPrefix when issuing the preempt call to extender.
prioritizeVerb [Required]
+string +		 + Verb for the prioritize call, empty if not supported. This verb is appended to the URLPrefix when issuing the prioritize call to extender.
weight [Required]
+int64 +		 + The numeric multiplier for the node scores that the prioritize call generates. +The weight should be a positive integer
bindVerb [Required]
+string +		 + Verb for the bind call, empty if not supported. This verb is appended to the URLPrefix when issuing the bind call to extender. +If this method is implemented by the extender, it is the extender's responsibility to bind the pod to apiserver. Only one extender +can implement this function.
enableHTTPS [Required]
+bool +		 + EnableHTTPS specifies whether https should be used to communicate with the extender
tlsConfig [Required]
+ExtenderTLSConfig +		 + TLSConfig specifies the transport layer security config
httpTimeout [Required]
+meta/v1.Duration +		 + HTTPTimeout specifies the timeout duration for a call to the extender. Filter timeout fails the scheduling of the pod. Prioritize +timeout is ignored, k8s/other extenders priorities are used to select the node.
nodeCacheCapable [Required]
+bool +		 + NodeCacheCapable specifies that the extender is capable of caching node information, +so the scheduler should only send minimal information about the eligible nodes +assuming that the extender already cached full details of all nodes in the cluster
managedResources
+[]ExtenderManagedResource +		 + ManagedResources is a list of extended resources that are managed by +this extender. +- A pod will be sent to the extender on the Filter, Prioritize and Bind + (if the extender is the binder) phases iff the pod requests at least + one of the extended resources in this list. If empty or unspecified, + all pods will be sent to this extender. +- If IgnoredByScheduler is set to true for a resource, kube-scheduler + will skip checking the resource in predicates.
ignorable [Required]
+bool +		 + Ignorable specifies if the extender is ignorable, i.e. scheduling should not +fail when the extender returns an error or is not reachable.
+ + + +## `KubeSchedulerProfile` {#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerProfile} + + + + +**Appears in:** + +- [KubeSchedulerConfiguration](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerConfiguration) + + +KubeSchedulerProfile is a scheduling profile. + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
schedulerName [Required]
+string +		 + SchedulerName is the name of the scheduler associated to this profile. +If SchedulerName matches with the pod's "spec.schedulerName", then the pod +is scheduled with this profile.
plugins [Required]
+Plugins +		 + Plugins specify the set of plugins that should be enabled or disabled. +Enabled plugins are the ones that should be enabled in addition to the +default plugins. Disabled plugins are any of the default plugins that +should be disabled. +When no enabled or disabled plugin is specified for an extension point, +default plugins for that extension point will be used if there is any. +If a QueueSort plugin is specified, the same QueueSort Plugin and +PluginConfig must be specified for all profiles.
pluginConfig [Required]
+[]PluginConfig +		 + PluginConfig is an optional set of custom plugin arguments for each plugin. +Omitting config args for a plugin is equivalent to using the default config +for that plugin.
+ + + +## `Plugin` {#kubescheduler-config-k8s-io-v1beta2-Plugin} + + + + +**Appears in:** + +- [PluginSet](#kubescheduler-config-k8s-io-v1beta2-PluginSet) + + +Plugin specifies a plugin name and its weight when applicable. Weight is used only for Score plugins. + + + + + + + + + + + + + + + + + + +
FieldDescription
name [Required]
+string +		 + Name defines the name of plugin
weight [Required]
+int32 +		 + Weight defines the weight of plugin, only used for Score plugins.
+ + + +## `PluginConfig` {#kubescheduler-config-k8s-io-v1beta2-PluginConfig} + + + + +**Appears in:** + +- [KubeSchedulerProfile](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerProfile) + + +PluginConfig specifies arguments that should be passed to a plugin at the time of initialization. +A plugin that is invoked at multiple extension points is initialized once. Args can have arbitrary structure. +It is up to the plugin to process these Args. + + + + + + + + + + + + + + + + + + +
FieldDescription
name [Required]
+string +		 + Name defines the name of plugin being configured
args [Required]
+k8s.io/apimachinery/pkg/runtime.RawExtension +		 + Args defines the arguments passed to the plugins at the time of initialization. Args can have arbitrary structure.
+ + + +## `PluginSet` {#kubescheduler-config-k8s-io-v1beta2-PluginSet} + + + + +**Appears in:** + +- [Plugins](#kubescheduler-config-k8s-io-v1beta2-Plugins) + + +PluginSet specifies enabled and disabled plugins for an extension point. +If an array is empty, missing, or nil, default plugins at that extension point will be used. + + + + + + + + + + + + + + + + + + +
FieldDescription
enabled [Required]
+[]Plugin +		 + Enabled specifies plugins that should be enabled in addition to default plugins. +If the default plugin is also configured in the scheduler config file, the weight of plugin will +be overridden accordingly. +These are called after default plugins and in the same order specified here.
disabled [Required]
+[]Plugin +		 + Disabled specifies default plugins that should be disabled. +When all default plugins need to be disabled, an array containing only one "∗" should be provided.
+ + + +## `Plugins` {#kubescheduler-config-k8s-io-v1beta2-Plugins} + + + + +**Appears in:** + +- [KubeSchedulerProfile](#kubescheduler-config-k8s-io-v1beta2-KubeSchedulerProfile) + + +Plugins include multiple extension points. When specified, the list of plugins for +a particular extension point are the only ones enabled. If an extension point is +omitted from the config, then the default set of plugins is used for that extension point. +Enabled plugins are called in the order specified here, after default plugins. If they need to +be invoked before default plugins, default plugins must be disabled and re-enabled here in desired order. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
queueSort [Required]
+PluginSet +		 + QueueSort is a list of plugins that should be invoked when sorting pods in the scheduling queue.
preFilter [Required]
+PluginSet +		 + PreFilter is a list of plugins that should be invoked at "PreFilter" extension point of the scheduling framework.
filter [Required]
+PluginSet +		 + Filter is a list of plugins that should be invoked when filtering out nodes that cannot run the Pod.
postFilter [Required]
+PluginSet +		 + PostFilter is a list of plugins that are invoked after filtering phase, no matter whether filtering succeeds or not.
preScore [Required]
+PluginSet +		 + PreScore is a list of plugins that are invoked before scoring.
score [Required]
+PluginSet +		 + Score is a list of plugins that should be invoked when ranking nodes that have passed the filtering phase.
reserve [Required]
+PluginSet +		 + Reserve is a list of plugins invoked when reserving/unreserving resources +after a node is assigned to run the pod.
permit [Required]
+PluginSet +		 + Permit is a list of plugins that control binding of a Pod. These plugins can prevent or delay binding of a Pod.
preBind [Required]
+PluginSet +		 + PreBind is a list of plugins that should be invoked before a pod is bound.
bind [Required]
+PluginSet +		 + Bind is a list of plugins that should be invoked at "Bind" extension point of the scheduling framework. +The scheduler call these plugins in order. Scheduler skips the rest of these plugins as soon as one returns success.
postBind [Required]
+PluginSet +		 + PostBind is a list of plugins that should be invoked after a pod is successfully bound.
+ + + +## `PodTopologySpreadConstraintsDefaulting` {#kubescheduler-config-k8s-io-v1beta2-PodTopologySpreadConstraintsDefaulting} + +(Alias of `string`) + + +**Appears in:** + +- [PodTopologySpreadArgs](#kubescheduler-config-k8s-io-v1beta2-PodTopologySpreadArgs) + + +PodTopologySpreadConstraintsDefaulting defines how to set default constraints +for the PodTopologySpread plugin. + + + + + +## `RequestedToCapacityRatioParam` {#kubescheduler-config-k8s-io-v1beta2-RequestedToCapacityRatioParam} + + + + +**Appears in:** + +- [ScoringStrategy](#kubescheduler-config-k8s-io-v1beta2-ScoringStrategy) + + +RequestedToCapacityRatioParam define RequestedToCapacityRatio parameters + + + + + + + + + + + + + +
FieldDescription
shape [Required]
+[]UtilizationShapePoint +		 + Shape is a list of points defining the scoring function shape.
+ + + +## `ResourceSpec` {#kubescheduler-config-k8s-io-v1beta2-ResourceSpec} + + + + +**Appears in:** + +- [NodeResourcesBalancedAllocationArgs](#kubescheduler-config-k8s-io-v1beta2-NodeResourcesBalancedAllocationArgs) + +- [ScoringStrategy](#kubescheduler-config-k8s-io-v1beta2-ScoringStrategy) + + +ResourceSpec represents a single resource. + + + + + + + + + + + + + + + + + + +
FieldDescription
name [Required]
+string +		 + Name of the resource.
weight [Required]
+int64 +		 + Weight of the resource.
+ + + +## `ScoringStrategy` {#kubescheduler-config-k8s-io-v1beta2-ScoringStrategy} + + + + +**Appears in:** + +- [NodeResourcesFitArgs](#kubescheduler-config-k8s-io-v1beta2-NodeResourcesFitArgs) + + +ScoringStrategy define ScoringStrategyType for node resource plugin + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
type [Required]
+ScoringStrategyType +		 + Type selects which strategy to run.
resources [Required]
+[]ResourceSpec +		 + Resources to consider when scoring. +The default resource set includes "cpu" and "memory" with an equal weight. +Allowed weights go from 1 to 100. +Weight defaults to 1 if not specified or explicitly set to 0.
requestedToCapacityRatio [Required]
+RequestedToCapacityRatioParam +		 + Arguments specific to RequestedToCapacityRatio strategy.
+ + + +## `ScoringStrategyType` {#kubescheduler-config-k8s-io-v1beta2-ScoringStrategyType} + +(Alias of `string`) + + +**Appears in:** + +- [ScoringStrategy](#kubescheduler-config-k8s-io-v1beta2-ScoringStrategy) + + +ScoringStrategyType the type of scoring strategy used in NodeResourcesFit plugin. + + + + + +## `UtilizationShapePoint` {#kubescheduler-config-k8s-io-v1beta2-UtilizationShapePoint} + + + + +**Appears in:** + +- [VolumeBindingArgs](#kubescheduler-config-k8s-io-v1beta2-VolumeBindingArgs) + +- [RequestedToCapacityRatioParam](#kubescheduler-config-k8s-io-v1beta2-RequestedToCapacityRatioParam) + + +UtilizationShapePoint represents single point of priority function shape. + + + + + + + + + + + + + + + + + + +
FieldDescription
utilization [Required]
+int32 +		 + Utilization (x axis). Valid values are 0 to 100. Fully utilized node maps to 100.
score [Required]
+int32 +		 + Score assigned to given utilization (y axis). Valid values are 0 to 10.
+ + + + + + +## `Policy` {#kubescheduler-config-k8s-io-v1-Policy} + + + + + +Policy describes a struct for a policy resource used in api. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubescheduler.config.k8s.io/v1
kind
string		Policy
predicates [Required]
+[]PredicatePolicy +		 + Holds the information to configure the fit predicate functions
priorities [Required]
+[]PriorityPolicy +		 + Holds the information to configure the priority functions
extenders [Required]
+[]LegacyExtender +		 + Holds the information to communicate with the extender(s)
hardPodAffinitySymmetricWeight [Required]
+int32 +		 + RequiredDuringScheduling affinity is not symmetric, but there is an implicit PreferredDuringScheduling affinity rule +corresponding to every RequiredDuringScheduling affinity rule. +HardPodAffinitySymmetricWeight represents the weight of implicit PreferredDuringScheduling affinity rule, in the range 1-100.
alwaysCheckAllPredicates [Required]
+bool +		 + When AlwaysCheckAllPredicates is set to true, scheduler checks all +the configured predicates even after one or more of them fails. +When the flag is set to false, scheduler skips checking the rest +of the predicates after it finds one predicate that failed.
+ + + +## `ExtenderManagedResource` {#kubescheduler-config-k8s-io-v1-ExtenderManagedResource} + + + + +**Appears in:** + +- [Extender](#kubescheduler-config-k8s-io-v1beta2-Extender) + +- [LegacyExtender](#kubescheduler-config-k8s-io-v1-LegacyExtender) + + +ExtenderManagedResource describes the arguments of extended resources +managed by an extender. + + + + + + + + + + + + + + + + + + +
FieldDescription
name [Required]
+string +		 + Name is the extended resource name.
ignoredByScheduler [Required]
+bool +		 + IgnoredByScheduler indicates whether kube-scheduler should ignore this +resource when applying predicates.
+ + + +## `ExtenderTLSConfig` {#kubescheduler-config-k8s-io-v1-ExtenderTLSConfig} + + + + +**Appears in:** + +- [Extender](#kubescheduler-config-k8s-io-v1beta2-Extender) + +- [LegacyExtender](#kubescheduler-config-k8s-io-v1-LegacyExtender) + + +ExtenderTLSConfig contains settings to enable TLS with extender + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
insecure [Required]
+bool +		 + Server should be accessed without verifying the TLS certificate. For testing only.
serverName [Required]
+string +		 + ServerName is passed to the server for SNI and is used in the client to check server +certificates against. If ServerName is empty, the hostname used to contact the +server is used.
certFile [Required]
+string +		 + Server requires TLS client certificate authentication
keyFile [Required]
+string +		 + Server requires TLS client certificate authentication
caFile [Required]
+string +		 + Trusted root certificates for server
certData [Required]
+[]byte +		 + CertData holds PEM-encoded bytes (typically read from a client certificate file). +CertData takes precedence over CertFile
keyData [Required]
+[]byte +		 + KeyData holds PEM-encoded bytes (typically read from a client certificate key file). +KeyData takes precedence over KeyFile
caData [Required]
+[]byte +		 + CAData holds PEM-encoded bytes (typically read from a root certificates bundle). +CAData takes precedence over CAFile
+ + + +## `LabelPreference` {#kubescheduler-config-k8s-io-v1-LabelPreference} + + + + +**Appears in:** + +- [PriorityArgument](#kubescheduler-config-k8s-io-v1-PriorityArgument) + + +LabelPreference holds the parameters that are used to configure the corresponding priority function + + + + + + + + + + + + + + + + + + +
FieldDescription
label [Required]
+string +		 + Used to identify node "groups"
presence [Required]
+bool +		 + This is a boolean flag +If true, higher priority is given to nodes that have the label +If false, higher priority is given to nodes that do not have the label
+ + + +## `LabelsPresence` {#kubescheduler-config-k8s-io-v1-LabelsPresence} + + + + +**Appears in:** + +- [PredicateArgument](#kubescheduler-config-k8s-io-v1-PredicateArgument) + + +LabelsPresence holds the parameters that are used to configure the corresponding predicate in scheduler policy configuration. + + + + + + + + + + + + + + + + + + +
FieldDescription
labels [Required]
+[]string +		 + The list of labels that identify node "groups" +All of the labels should be either present (or absent) for the node to be considered a fit for hosting the pod
presence [Required]
+bool +		 + The boolean flag that indicates whether the labels should be present or absent from the node
+ + + +## `LegacyExtender` {#kubescheduler-config-k8s-io-v1-LegacyExtender} + + + + +**Appears in:** + +- [Policy](#kubescheduler-config-k8s-io-v1-Policy) + + +LegacyExtender holds the parameters used to communicate with the extender. If a verb is unspecified/empty, +it is assumed that the extender chose not to provide that extension. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
urlPrefix [Required]
+string +		 + URLPrefix at which the extender is available
filterVerb [Required]
+string +		 + Verb for the filter call, empty if not supported. This verb is appended to the URLPrefix when issuing the filter call to extender.
preemptVerb [Required]
+string +		 + Verb for the preempt call, empty if not supported. This verb is appended to the URLPrefix when issuing the preempt call to extender.
prioritizeVerb [Required]
+string +		 + Verb for the prioritize call, empty if not supported. This verb is appended to the URLPrefix when issuing the prioritize call to extender.
weight [Required]
+int64 +		 + The numeric multiplier for the node scores that the prioritize call generates. +The weight should be a positive integer
bindVerb [Required]
+string +		 + Verb for the bind call, empty if not supported. This verb is appended to the URLPrefix when issuing the bind call to extender. +If this method is implemented by the extender, it is the extender's responsibility to bind the pod to apiserver. Only one extender +can implement this function.
enableHttps [Required]
+bool +		 + EnableHTTPS specifies whether https should be used to communicate with the extender
tlsConfig [Required]
+ExtenderTLSConfig +		 + TLSConfig specifies the transport layer security config
httpTimeout [Required]
+time.Duration +		 + HTTPTimeout specifies the timeout duration for a call to the extender. Filter timeout fails the scheduling of the pod. Prioritize +timeout is ignored, k8s/other extenders priorities are used to select the node.
nodeCacheCapable [Required]
+bool +		 + NodeCacheCapable specifies that the extender is capable of caching node information, +so the scheduler should only send minimal information about the eligible nodes +assuming that the extender already cached full details of all nodes in the cluster
managedResources
+[]ExtenderManagedResource +		 + ManagedResources is a list of extended resources that are managed by +this extender. +- A pod will be sent to the extender on the Filter, Prioritize and Bind + (if the extender is the binder) phases iff the pod requests at least + one of the extended resources in this list. If empty or unspecified, + all pods will be sent to this extender. +- If IgnoredByScheduler is set to true for a resource, kube-scheduler + will skip checking the resource in predicates.
ignorable [Required]
+bool +		 + Ignorable specifies if the extender is ignorable, i.e. scheduling should not +fail when the extender returns an error or is not reachable.
+ + + +## `PredicateArgument` {#kubescheduler-config-k8s-io-v1-PredicateArgument} + + + + +**Appears in:** + +- [PredicatePolicy](#kubescheduler-config-k8s-io-v1-PredicatePolicy) + + +PredicateArgument represents the arguments to configure predicate functions in scheduler policy configuration. +Only one of its members may be specified + + + + + + + + + + + + + + + + + + +
FieldDescription
serviceAffinity [Required]
+ServiceAffinity +		 + The predicate that provides affinity for pods belonging to a service +It uses a label to identify nodes that belong to the same "group"
labelsPresence [Required]
+LabelsPresence +		 + The predicate that checks whether a particular node has a certain label +defined or not, regardless of value
+ + + +## `PredicatePolicy` {#kubescheduler-config-k8s-io-v1-PredicatePolicy} + + + + +**Appears in:** + +- [Policy](#kubescheduler-config-k8s-io-v1-Policy) + + +PredicatePolicy describes a struct of a predicate policy. + + + + + + + + + + + + + + + + + + +
FieldDescription
name [Required]
+string +		 + Identifier of the predicate policy +For a custom predicate, the name can be user-defined +For the Kubernetes provided predicates, the name is the identifier of the pre-defined predicate
argument [Required]
+PredicateArgument +		 + Holds the parameters to configure the given predicate
+ + + +## `PriorityArgument` {#kubescheduler-config-k8s-io-v1-PriorityArgument} + + + + +**Appears in:** + +- [PriorityPolicy](#kubescheduler-config-k8s-io-v1-PriorityPolicy) + + +PriorityArgument represents the arguments to configure priority functions in scheduler policy configuration. +Only one of its members may be specified + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
serviceAntiAffinity [Required]
+ServiceAntiAffinity +		 + The priority function that ensures a good spread (anti-affinity) for pods belonging to a service +It uses a label to identify nodes that belong to the same "group"
labelPreference [Required]
+LabelPreference +		 + The priority function that checks whether a particular node has a certain label +defined or not, regardless of value
requestedToCapacityRatioArguments [Required]
+RequestedToCapacityRatioArguments +		 + The RequestedToCapacityRatio priority function is parametrized with function shape.
+ + + +## `PriorityPolicy` {#kubescheduler-config-k8s-io-v1-PriorityPolicy} + + + + +**Appears in:** + +- [Policy](#kubescheduler-config-k8s-io-v1-Policy) + + +PriorityPolicy describes a struct of a priority policy. + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
name [Required]
+string +		 + Identifier of the priority policy +For a custom priority, the name can be user-defined +For the Kubernetes provided priority functions, the name is the identifier of the pre-defined priority function
weight [Required]
+int64 +		 + The numeric multiplier for the node scores that the priority function generates +The weight should be non-zero and can be a positive or a negative integer
argument [Required]
+PriorityArgument +		 + Holds the parameters to configure the given priority function
+ + + +## `RequestedToCapacityRatioArguments` {#kubescheduler-config-k8s-io-v1-RequestedToCapacityRatioArguments} + + + + +**Appears in:** + +- [PriorityArgument](#kubescheduler-config-k8s-io-v1-PriorityArgument) + + +RequestedToCapacityRatioArguments holds arguments specific to RequestedToCapacityRatio priority function. + + + + + + + + + + + + + + + + + + +
FieldDescription
shape [Required]
+[]UtilizationShapePoint +		 + Array of point defining priority function shape.
resources [Required]
+[]ResourceSpec +		 + No description provided. +
+ + + +## `ResourceSpec` {#kubescheduler-config-k8s-io-v1-ResourceSpec} + + + + +**Appears in:** + +- [RequestedToCapacityRatioArguments](#kubescheduler-config-k8s-io-v1-RequestedToCapacityRatioArguments) + + +ResourceSpec represents single resource and weight for bin packing of priority RequestedToCapacityRatioArguments. + + + + + + + + + + + + + + + + + + +
FieldDescription
name [Required]
+string +		 + Name of the resource to be managed by RequestedToCapacityRatio function.
weight [Required]
+int64 +		 + Weight of the resource.
+ + + +## `ServiceAffinity` {#kubescheduler-config-k8s-io-v1-ServiceAffinity} + + + + +**Appears in:** + +- [PredicateArgument](#kubescheduler-config-k8s-io-v1-PredicateArgument) + + +ServiceAffinity holds the parameters that are used to configure the corresponding predicate in scheduler policy configuration. + + + + + + + + + + + + + +
FieldDescription
labels [Required]
+[]string +		 + The list of labels that identify node "groups" +All of the labels should match for the node to be considered a fit for hosting the pod
+ + + +## `ServiceAntiAffinity` {#kubescheduler-config-k8s-io-v1-ServiceAntiAffinity} + + + + +**Appears in:** + +- [PriorityArgument](#kubescheduler-config-k8s-io-v1-PriorityArgument) + + +ServiceAntiAffinity holds the parameters that are used to configure the corresponding priority function + + + + + + + + + + + + + +
FieldDescription
label [Required]
+string +		 + Used to identify node "groups"
+ + + +## `UtilizationShapePoint` {#kubescheduler-config-k8s-io-v1-UtilizationShapePoint} + + + + +**Appears in:** + +- [RequestedToCapacityRatioArguments](#kubescheduler-config-k8s-io-v1-RequestedToCapacityRatioArguments) + + +UtilizationShapePoint represents single point of priority function shape. + + + + + + + + + + + + + + + + + + +
FieldDescription
utilization [Required]
+int32 +		 + Utilization (x axis). Valid values are 0 to 100. Fully utilized node maps to 100.
score [Required]
+int32 +		 + Score assigned to given utilization (y axis). Valid values are 0 to 10.
+ + diff --git a/content/en/docs/reference/config-api/kube-scheduler-policy-config.v1.md b/content/en/docs/reference/config-api/kube-scheduler-policy-config.v1.md index e694f7ecbc..8b6c0a9a24 100644 --- a/content/en/docs/reference/config-api/kube-scheduler-policy-config.v1.md +++ b/content/en/docs/reference/config-api/kube-scheduler-policy-config.v1.md @@ -89,7 +89,7 @@ of the predicates after it finds one predicate that failed. **Appears in:** -- [Extender](#kubescheduler-config-k8s-io-v1beta1-Extender) +- [Extender](#kubescheduler-config-k8s-io-v1beta2-Extender) - [LegacyExtender](#kubescheduler-config-k8s-io-v1-LegacyExtender) @@ -132,7 +132,7 @@ resource when applying predicates. **Appears in:** -- [Extender](#kubescheduler-config-k8s-io-v1beta1-Extender) +- [Extender](#kubescheduler-config-k8s-io-v1beta2-Extender) - [LegacyExtender](#kubescheduler-config-k8s-io-v1-LegacyExtender) diff --git a/content/en/docs/reference/config-api/kubeadm-config.v1beta2.md b/content/en/docs/reference/config-api/kubeadm-config.v1beta2.md new file mode 100644 index 0000000000..77595b4599 --- /dev/null +++ b/content/en/docs/reference/config-api/kubeadm-config.v1beta2.md @@ -0,0 +1,1489 @@ +--- +title: kubeadm Configuration (v1beta2) +content_type: tool-reference +package: kubeadm.k8s.io/v1beta2 +auto_generated: true +--- +Package v1beta2 defines the v1beta2 version of the kubeadm configuration file format. +This version improves on the v1beta1 format by fixing some minor issues and adding a few new fields. + +A list of changes since v1beta1: + +- `certificateKey" field is added to InitConfiguration and JoinConfiguration. +- "ignorePreflightErrors" field is added to the NodeRegistrationOptions. +- The JSON "omitempty" tag is used in a more places where appropriate. +- The JSON "omitempty" tag of the "taints" field (inside NodeRegistrationOptions) is removed. +See the Kubernetes 1.15 changelog for further details. + +## Migration from old kubeadm config versions + +Please convert your v1beta1 configuration files to v1beta2 using the "kubeadm config migrate" command of kubeadm v1.15.x +(conversion from older releases of kubeadm config files requires older release of kubeadm as well e.g. + +- kubeadm v1.11 should be used to migrate v1alpha1 to v1alpha2; kubeadm v1.12 should be used to translate v1alpha2 to v1alpha3; +- kubeadm v1.13 or v1.14 should be used to translate v1alpha3 to v1beta1) + +Nevertheless, kubeadm v1.15.x will support reading from v1beta1 version of the kubeadm config file format. + +## Basics + +The preferred way to configure kubeadm is to pass an YAML configuration file with the --config option. Some of the +configuration options defined in the kubeadm config file are also available as command line flags, but only +the most common/simple use case are supported with this approach. + +A kubeadm config file could contain multiple configuration types separated using three dashes (“---”). + +kubeadm supports the following configuration types: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: InitConfiguration + +apiVersion: kubeadm.k8s.io/v1beta2 +kind: ClusterConfiguration + +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration + +apiVersion: kubeproxy.config.k8s.io/v1alpha1 +kind: KubeProxyConfiguration + +apiVersion: kubeadm.k8s.io/v1beta2 +kind: JoinConfiguration +``` + +To print the defaults for "init" and "join" actions use the following commands: + +```shell +kubeadm config print init-defaults +kubeadm config print join-defaults +``` + +The list of configuration types that must be included in a configuration file depends by the action you are +performing (init or join) and by the configuration options you are going to use (defaults or advanced customization). + +If some configuration types are not provided, or provided only partially, kubeadm will use default values; defaults +provided by kubeadm includes also enforcing consistency of values across components when required (e.g. +cluster-cidr flag on controller manager and clusterCIDR on kube-proxy). + +Users are always allowed to override default values, with the only exception of a small subset of setting with +relevance for security (e.g. enforce authorization-mode Node and RBAC on api server) + +If the user provides a configuration types that is not expected for the action you are performing, kubeadm will +ignore those types and print a warning. + +## Kubeadm init configuration types + +When executing kubeadm init with the `--config` option, the following configuration types could be used: +InitConfiguration, ClusterConfiguration, KubeProxyConfiguration, KubeletConfiguration, but only one +between InitConfiguration and ClusterConfiguration is mandatory. + +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: InitConfiguration +bootstrapTokens: + ... +nodeRegistration: + ... +``` + +The InitConfiguration type should be used to configure runtime settings, that in case of kubeadm init +are the configuration of the bootstrap token and all the setting which are specific to the node where kubeadm +is executed, including: + +- NodeRegistration, that holds fields that relate to registering the new node to the cluster; + use it to customize the node name, the CRI socket to use or any other settings that should apply to this + node only (e.g. the node ip). + +- LocalAPIEndpoint, that represents the endpoint of the instance of the API server to be deployed on this node; + use it e.g. to customize the API server advertise address. + + ```yaml + apiVersion: kubeadm.k8s.io/v1beta2 + kind: ClusterConfiguration + networking: + ... + etcd: + ... + apiServer: + extraArgs: + ... + extraVolumes: + ... + ``` + +The ClusterConfiguration type should be used to configure cluster-wide settings, +including settings for: + +- Networking, that holds configuration for the networking topology of the cluster; use it e.g. to customize + pod subnet or services subnet. +- Etcd configurations; use it e.g. to customize the local etcd or to configure the API server + for using an external etcd cluster. +- kube-apiserver, kube-scheduler, kube-controller-manager configurations; use it to customize control-plane + components by adding customized setting or overriding kubeadm default settings. + + ```yaml + apiVersion: kubeproxy.config.k8s.io/v1alpha1 + kind: KubeProxyConfiguration + ... + ``` + +The KubeProxyConfiguration type should be used to change the configuration passed to kube-proxy instances deployed +in the cluster. If this object is not provided or provided only partially, kubeadm applies defaults. + +See https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/ or https://godoc.org/k8s.io/kube-proxy/config/v1alpha1#KubeProxyConfiguration +for kube proxy official documentation. + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +... +``` + +The KubeletConfiguration type should be used to change the configurations that will be passed to all kubelet instances +deployed in the cluster. If this object is not provided or provided only partially, kubeadm applies defaults. + +See https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ or https://godoc.org/k8s.io/kubelet/config/v1beta1#KubeletConfiguration +for kubelet official documentation. + +Here is a fully populated example of a single YAML file containing multiple +configuration types to be used during a `kubeadm init` run. + +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: InitConfiguration +bootstrapTokens: + - token: "9a08jv.c0izixklcxtmnze7" + description: "kubeadm bootstrap token" + ttl: "24h" + - token: "783bde.3f89s0fje9f38fhf" + description: "another bootstrap token" + usages: + - authentication + - signing + groups: + - system:bootstrappers:kubeadm:default-node-token +nodeRegistration: + name: "ec2-10-100-0-1" + criSocket: "/var/run/dockershim.sock" + taints: + - key: "kubeadmNode" + value: "master" + effect: "NoSchedule" + kubeletExtraArgs: + cgroup-driver: "cgroupfs" + ignorePreflightErrors: + - IsPrivilegedUser +localAPIEndpoint: + advertiseAddress: "10.100.0.1" + bindPort: 6443 +certificateKey: "e6a2eb8581237ab72a4f494f30285ec12a9694d750b9785706a83bfcbbbd2204" +--- +apiVersion: kubeadm.k8s.io/v1beta2 +kind: ClusterConfiguration +etcd: + # one of local or external + local: + imageRepository: "k8s.gcr.io" + imageTag: "3.2.24" + dataDir: "/var/lib/etcd" + extraArgs: + listen-client-urls: "http://10.100.0.1:2379" + serverCertSANs: + - "ec2-10-100-0-1.compute-1.amazonaws.com" + peerCertSANs: + - "10.100.0.1" + # external: + # endpoints: + # - "10.100.0.1:2379" + # - "10.100.0.2:2379" + # caFile: "/etcd/kubernetes/pki/etcd/etcd-ca.crt" + # certFile: "/etcd/kubernetes/pki/etcd/etcd.crt" + # keyFile: "/etcd/kubernetes/pki/etcd/etcd.key" + networking: + serviceSubnet: "10.96.0.0/12" + podSubnet: "10.100.0.1/24" + dnsDomain: "cluster.local" + kubernetesVersion: "v1.12.0" + controlPlaneEndpoint: "10.100.0.1:6443" + apiServer: + extraArgs: + authorization-mode: "Node,RBAC" + extraVolumes: + - name: "some-volume" + hostPath: "/etc/some-path" + mountPath: "/etc/some-pod-path" + readOnly: false + pathType: File + certSANs: + - "10.100.1.1" + - "ec2-10-100-0-1.compute-1.amazonaws.com" + timeoutForControlPlane: 4m0s + controllerManager: + extraArgs: + "node-cidr-mask-size": "20" + extraVolumes: + - name: "some-volume" + hostPath: "/etc/some-path" + mountPath: "/etc/some-pod-path" + readOnly: false + pathType: File + scheduler: + extraArgs: + address: "10.100.0.1" + extraVolumes: + - name: "some-volume" + hostPath: "/etc/some-path" + mountPath: "/etc/some-pod-path" + readOnly: false + pathType: File +certificatesDir: "/etc/kubernetes/pki" +imageRepository: "k8s.gcr.io" +useHyperKubeImage: false +clusterName: "example-cluster" +--- +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +# kubelet specific options here +--- +apiVersion: kubeproxy.config.k8s.io/v1alpha1 +kind: KubeProxyConfiguration +# kube-proxy specific options here +``` + +## Kubeadm join configuration types + +When executing kubeadm join with the `--config` option, the JoinConfiguration type should be provided. + +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: JoinConfiguration +... +``` + +The JoinConfiguration type should be used to configure runtime settings, that in case of kubeadm join +are the discovery method used for accessing the cluster info and all the setting which are specific +to the node where kubeadm is executed, including: + +- NodeRegistration, that holds fields that relate to registering the new node to the cluster; + use it to customize the node name, the CRI socket to use or any other settings that should apply to this + node only (e.g. the node ip). + +- APIEndpoint, that represents the endpoint of the instance of the API server to be eventually deployed on this node. + +## Resource Types + + +- [ClusterConfiguration](#kubeadm-k8s-io-v1beta2-ClusterConfiguration) +- [ClusterStatus](#kubeadm-k8s-io-v1beta2-ClusterStatus) +- [InitConfiguration](#kubeadm-k8s-io-v1beta2-InitConfiguration) +- [JoinConfiguration](#kubeadm-k8s-io-v1beta2-JoinConfiguration) + + + + +## `ClusterConfiguration` {#kubeadm-k8s-io-v1beta2-ClusterConfiguration} + + + + + +ClusterConfiguration contains cluster-wide configuration for a kubeadm cluster + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubeadm.k8s.io/v1beta2
kind
string		ClusterConfiguration
etcd [Required]
+Etcd +		 + `etcd` holds configuration for etcd.
networking [Required]
+Networking +		 + `networking` holds configuration for the networking topology of the cluster.
kubernetesVersion [Required]
+string +		 + `kubernetesVersion` is the target version of the control plane.
controlPlaneEndpoint [Required]
+string +		 + `controlPlaneEndpoint` sets a stable IP address or DNS name for the control plane; it +can be a valid IP address or a RFC-1123 DNS subdomain, both with optional TCP port. +In case the ControlPlaneEndpoint is not specified, the AdvertiseAddress + BindPort +are used; in case the ControlPlaneEndpoint is specified but without a TCP port, +the BindPort is used. +Possible usages are: + +- In a cluster with more than one control plane instances, this field should be + assigned the address of the external load balancer in front of the + control plane instances. +- In environments with enforced node recycling, the ControlPlaneEndpoint + could be used for assigning a stable DNS to the control plane.
apiServer [Required]
+APIServer +		 + `apiServer` contains extra settings for the API server.
controllerManager [Required]
+ControlPlaneComponent +		 + `controllerManager` contains extra settings for the controller manager.
scheduler [Required]
+ControlPlaneComponent +		 + `scheduler` contains extra settings for the scheduler.
dns [Required]
+DNS +		 + `dns` defines the options for the DNS add-on.
certificatesDir [Required]
+string +		 + `certificatesDir` specifies where to store or look for all required certificates.
imageRepository [Required]
+string +		 + `imageRepository` sets the container registry to pull images from. +If empty, `k8s.gcr.io` will be used by default; in case of kubernetes version is +a CI build (kubernetes version starts with `ci/` or `ci-cross/`) +`gcr.io/k8s-staging-ci-images` will be used as a default for control plane +components and for kube-proxy, while `k8s.gcr.io` will be used for all the other images.
useHyperKubeImage [Required]
+bool +		 + `useHyperKubeImage` controls if hyperkube should be used for Kubernetes +components instead of their respective separate images +DEPRECATED: As hyperkube is itself deprecated, this fields is too. It will +be removed in future kubeadm config versions, kubeadm will print multiple +warnings when this is set to true, and at some point it may become ignored.
featureGates [Required]
+map[string]bool +		 + Feature gates enabled by the user.
clusterName [Required]
+string +		 + The cluster name
+ + + +## `ClusterStatus` {#kubeadm-k8s-io-v1beta2-ClusterStatus} + + + + + +ClusterStatus contains the cluster status. The ClusterStatus will be stored in the kubeadm-config +ConfigMap in the cluster, and then updated by kubeadm when additional control plane instance joins or leaves the cluster. + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubeadm.k8s.io/v1beta2
kind
string		ClusterStatus
apiEndpoints [Required]
+map[string]github.com/tengqm/kubeconfig/config/kubeadm/v1beta2.APIEndpoint +		 + `apiEndpoints` currently available in the cluster, one for each control +plane/API server instance. The key of the map is the IP of the host's default interface
+ + + +## `InitConfiguration` {#kubeadm-k8s-io-v1beta2-InitConfiguration} + + + + + +InitConfiguration contains a list of elements that is specific "kubeadm init"-only runtime +information. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubeadm.k8s.io/v1beta2
kind
string		InitConfiguration
bootstrapTokens [Required]
+[]BootstrapToken +		 + `bootstrapTokens` is respected at `kubeadm init` time and describes a set of Bootstrap Tokens to create. +This information IS NOT uploaded to the kubeadm cluster configmap, partly because of its sensitive nature
nodeRegistration [Required]
+NodeRegistrationOptions +		 + `nodeRegistration` holds fields that relate to registering the new control-plane node to the cluster
localAPIEndpoint [Required]
+APIEndpoint +		 + `localAPIEndpoint` represents the endpoint of the API server instance that's deployed on this control plane node +In HA setups, this differs from ClusterConfiguration.ControlPlaneEndpoint in the sense that ControlPlaneEndpoint +is the global endpoint for the cluster, which then loadbalances the requests to each individual API server. This +configuration object lets you customize what IP/DNS name and port the local API server advertises it's accessible +on. By default, kubeadm tries to auto-detect the IP of the default interface and use that, but in case that process +fails you may set the desired value here.
certificateKey [Required]
+string +		 + `certificateKey` sets the key with which certificates and keys are encrypted prior to being uploaded in +a Secret in the cluster during the "uploadcerts" init phase.
+ + + +## `JoinConfiguration` {#kubeadm-k8s-io-v1beta2-JoinConfiguration} + + + + + +JoinConfiguration contains elements describing a particular node. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubeadm.k8s.io/v1beta2
kind
string		JoinConfiguration
nodeRegistration [Required]
+NodeRegistrationOptions +		 + `nodeRegistration` holds fields that relate to registering the new control-plane +node to the cluster
caCertPath [Required]
+string +		 + `caCertPath` is the path to the SSL certificate authority used to +secure comunications between node and control-plane. +Defaults to "/etc/kubernetes/pki/ca.crt".
discovery [Required]
+Discovery +		 + `discovery` specifies the options for the kubelet to use during the TLS Bootstrap +process
controlPlane [Required]
+JoinControlPlane +		 + `controlPlane` defines the additional control plane instance to be deployed on the +joining node. If nil, no additional control plane instance will be deployed.
+ + + +## `APIEndpoint` {#kubeadm-k8s-io-v1beta2-APIEndpoint} + + + + +**Appears in:** + +- [ClusterStatus](#kubeadm-k8s-io-v1beta2-ClusterStatus) + +- [InitConfiguration](#kubeadm-k8s-io-v1beta2-InitConfiguration) + +- [JoinControlPlane](#kubeadm-k8s-io-v1beta2-JoinControlPlane) + + +APIEndpoint struct contains elements of API server instance deployed on a node. + + + + + + + + + + + + + + + + + + +
FieldDescription
advertiseAddress [Required]
+string +		 + `advertiseAddress` sets the IP address for the API server to advertise.
bindPort [Required]
+int32 +		 + `bindPort` sets the secure port for the API Server to bind to. Defaults to 6443.
+ + + +## `APIServer` {#kubeadm-k8s-io-v1beta2-APIServer} + + + + +**Appears in:** + +- [ClusterConfiguration](#kubeadm-k8s-io-v1beta2-ClusterConfiguration) + + +APIServer holds settings necessary for API server deployments in the cluster + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
ControlPlaneComponent [Required]
+ControlPlaneComponent +		(Members of ControlPlaneComponent are embedded into this type.) + No description provided. +
certSANs [Required]
+[]string +		 + `certSANs` sets extra Subject Alternative Names for the API Server signing cert.
timeoutForControlPlane [Required]
+meta/v1.Duration +		 + `timeoutForControlPlane` controls the timeout that we use for API server to appear
+ + + +## `BootstrapToken` {#kubeadm-k8s-io-v1beta2-BootstrapToken} + + + + +**Appears in:** + +- [InitConfiguration](#kubeadm-k8s-io-v1beta2-InitConfiguration) + + +BootstrapToken describes one bootstrap token, stored as a Secret in the cluster + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
token [Required]
+BootstrapTokenString +		 + `token` used for establishing bidirectional trust between nodes and control-planes. +Used for joining nodes in the cluster.
description [Required]
+string +		 + `description` sets a human-friendly message why this token exists and what it's used +for, so other administrators can know its purpose.
ttl [Required]
+meta/v1.Duration +		 + `ttl` defines the time to live for this token. Defaults to "24h". +`expires` and `ttl` are mutually exclusive.
expires [Required]
+meta/v1.Time +		 + `expires` specifies the timestamp when this token expires. Defaults to being set +dynamically at runtime based on the `ttl`. `expires` and `ttl` are mutually exclusive.
usages [Required]
+[]string +		 + `usages` describes the ways in which this token can be used. Can by default be used +for establishing bidirectional trust, but that can be changed here.
groups [Required]
+[]string +		 + `groups` specifies the extra groups that this token will authenticate as when/if +used for authentication
+ + + +## `BootstrapTokenDiscovery` {#kubeadm-k8s-io-v1beta2-BootstrapTokenDiscovery} + + + + +**Appears in:** + +- [Discovery](#kubeadm-k8s-io-v1beta2-Discovery) + + +BootstrapTokenDiscovery is used to set the options for bootstrap token based discovery + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
token [Required]
+string +		 + `token` is a token used to validate cluster information fetched from the control-plane.
apiServerEndpoint [Required]
+string +		 + `apiServerEndpoint` is an IP or domain name to the API server from which +information will be fetched.
caCertHashes [Required]
+[]string +		 + discovery is used. The root CA found during discovery must match one of these +values. Specifying an empty set disables root CA pinning, which can be unsafe. +Each hash is specified as `:`, where the only currently supported +type is "sha256". This is a hex-encoded SHA-256 hash of the Subject Public Key +Info (SPKI) object in DER-encoded ASN.1. These hashes can be calculated using, +for example, OpenSSL.
unsafeSkipCAVerification [Required]
+bool +		 + `unsafeSkipCAVerification` allows token-based discovery without CA verification +via `caCertHashes`. This can weaken the security of kubeadm since other nodes +can impersonate the control-plane.
+ + + +## `BootstrapTokenString` {#kubeadm-k8s-io-v1beta2-BootstrapTokenString} + + + + +**Appears in:** + +- [BootstrapToken](#kubeadm-k8s-io-v1beta2-BootstrapToken) + + +BootstrapTokenString is a token of the format abcdef.abcdef0123456789 that is used +for both validation of the practically of the API server from a joining node's point +of view and as an authentication method for the node in the bootstrap phase of +"kubeadm join". This token is and should be short-lived + + + + + + + + + + + + + + + + + + +
FieldDescription
- [Required]
+string +		 + No description provided. +
- [Required]
+string +		 + No description provided. +
+ + + +## `ControlPlaneComponent` {#kubeadm-k8s-io-v1beta2-ControlPlaneComponent} + + + + +**Appears in:** + +- [ClusterConfiguration](#kubeadm-k8s-io-v1beta2-ClusterConfiguration) + +- [APIServer](#kubeadm-k8s-io-v1beta2-APIServer) + + +ControlPlaneComponent holds settings common to control plane component of the cluster + + + + + + + + + + + + + + + + + + +
FieldDescription
extraArgs [Required]
+map[string]string +		 + `extraArgs` is an extra set of flags to pass to the control plane component.
extraVolumes [Required]
+[]HostPathMount +		 + `extraVolumes` is an extra set of host volumes, mounted to the control plane component.
+ + + +## `DNS` {#kubeadm-k8s-io-v1beta2-DNS} + + + + +**Appears in:** + +- [ClusterConfiguration](#kubeadm-k8s-io-v1beta2-ClusterConfiguration) + + +DNS defines the DNS addon that should be used in the cluster + + + + + + + + + + + + + + + + + + +
FieldDescription
type [Required]
+DNSAddOnType +		 + `type` defines the DNS add-on to use.
ImageMeta [Required]
+ImageMeta +		(Members of ImageMeta are embedded into this type.) + `imageMeta` allows to customize the image used for the DNS.
+ + + +## `DNSAddOnType` {#kubeadm-k8s-io-v1beta2-DNSAddOnType} + +(Alias of `string`) + + +**Appears in:** + +- [DNS](#kubeadm-k8s-io-v1beta2-DNS) + + +DNSAddOnType defines string identifying DNS add-on types + + + + + +## `Discovery` {#kubeadm-k8s-io-v1beta2-Discovery} + + + + +**Appears in:** + +- [JoinConfiguration](#kubeadm-k8s-io-v1beta2-JoinConfiguration) + + +Discovery specifies the options for the kubelet to use during the TLS Bootstrap process + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
bootstrapToken [Required]
+BootstrapTokenDiscovery +		 + `bootstrapToken` is used to set the options for bootstrap token based discovery. +`bootstrapToken` and `file` are mutually exclusive.
file [Required]
+FileDiscovery +		 + `file` specifies a file or URL to a kubeconfig file from which to load cluster information. +`bootstrapToken` and `file` are mutually exclusive.
tlsBootstrapToken [Required]
+string +		 + `tlsBootstrapToken` is a token used for TLS bootstrapping. +If `bootstrapToken` is set, this field is defaulted to `bootstrapToken.token`, +but can be overridden. +If `file` is set, this field ∗∗must be set∗∗ in case the KubeConfigFile does +not contain any other authentication information
timeout [Required]
+meta/v1.Duration +		 + `timeout` modifies the discovery timeout.
+ + + +## `Etcd` {#kubeadm-k8s-io-v1beta2-Etcd} + + + + +**Appears in:** + +- [ClusterConfiguration](#kubeadm-k8s-io-v1beta2-ClusterConfiguration) + + +Etcd contains elements describing Etcd configuration. + + + + + + + + + + + + + + + + + + +
FieldDescription
local [Required]
+LocalEtcd +		 + `local` provides configuration knobs for configuring the local etcd instance. +`local` and `external` are mutually exclusive.
external [Required]
+ExternalEtcd +		 + `external` describes how to connect to an external etcd cluster. +`local` and `external` are mutually exclusive.
+ + + +## `ExternalEtcd` {#kubeadm-k8s-io-v1beta2-ExternalEtcd} + + + + +**Appears in:** + +- [Etcd](#kubeadm-k8s-io-v1beta2-Etcd) + + +ExternalEtcd describes an external etcd cluster. +Kubeadm has no knowledge of where certificate files live and they must be supplied. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
endpoints [Required]
+[]string +		 + `endpoints` are endpoints of etcd members. This field is required.
caFile [Required]
+string +		 + `caFile` is an SSL Certificate Authority file used to secure etcd communication. +Required if using a TLS connection.
certFile [Required]
+string +		 + `certFile` is an SSL certification file used to secure etcd communication. +Required if using a TLS connection.
keyFile [Required]
+string +		 + `keyFile` is an SSL key file used to secure etcd communication. +Required if using a TLS connection.
+ + + +## `FileDiscovery` {#kubeadm-k8s-io-v1beta2-FileDiscovery} + + + + +**Appears in:** + +- [Discovery](#kubeadm-k8s-io-v1beta2-Discovery) + + +FileDiscovery is used to specify a file or URL to a kubeconfig file from which to load cluster information + + + + + + + + + + + + + +
FieldDescription
kubeConfigPath [Required]
+string +		 + `kubeConfigPath` specifies the actual file path or URL to the kubeconfig file +from which to load cluster information
+ + + +## `HostPathMount` {#kubeadm-k8s-io-v1beta2-HostPathMount} + + + + +**Appears in:** + +- [ControlPlaneComponent](#kubeadm-k8s-io-v1beta2-ControlPlaneComponent) + + +HostPathMount contains elements describing volumes that are mounted from the host. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
name [Required]
+string +		 + `name` is the volume name inside the Pod template.
hostPath [Required]
+string +		 + `hostPath` is the path in the host that will be mounted inside the Pod.
mountPath [Required]
+string +		 + `mountPath` is the path inside the Pod where the `hostPath` volume is mounted.
readOnly [Required]
+bool +		 + `readOnly` controls write access to the volume.
pathType [Required]
+core/v1.HostPathType +		 + `pathType` is the type of the `hostPath` volume.
+ + + +## `ImageMeta` {#kubeadm-k8s-io-v1beta2-ImageMeta} + + + + +**Appears in:** + +- [DNS](#kubeadm-k8s-io-v1beta2-DNS) + +- [LocalEtcd](#kubeadm-k8s-io-v1beta2-LocalEtcd) + + +ImageMeta allows to customize the image used for components that are not +originated from the Kubernetes/Kubernetes release process + + + + + + + + + + + + + + + + + + +
FieldDescription
imageRepository [Required]
+string +		 + `imageRepository` sets the container registry to pull images from. +If not set, the ImageRepository defined in ClusterConfiguration will be used instead.
imageTag [Required]
+string +		 + `imageTag` allows to specify a tag for the image. +In case this value is set, kubeadm does not change automatically the +version of the above components during upgrades.
+ + + +## `JoinControlPlane` {#kubeadm-k8s-io-v1beta2-JoinControlPlane} + + + + +**Appears in:** + +- [JoinConfiguration](#kubeadm-k8s-io-v1beta2-JoinConfiguration) + + +JoinControlPlane contains elements describing an additional control plane instance to be deployed on the joining node. + + + + + + + + + + + + + + + + + + +
FieldDescription
localAPIEndpoint [Required]
+APIEndpoint +		 + `localAPIEndpoint` represents the endpoint of the API server instance to be deployed +on this node.
certificateKey [Required]
+string +		 + `certificateKey` is the key that is used for decryption of certificates after they +are downloaded from the secret upon joining a new control plane node. The +corresponding encryption key is in the InitConfiguration.
+ + + +## `LocalEtcd` {#kubeadm-k8s-io-v1beta2-LocalEtcd} + + + + +**Appears in:** + +- [Etcd](#kubeadm-k8s-io-v1beta2-Etcd) + + +LocalEtcd describes that kubeadm should run an etcd cluster locally + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
ImageMeta [Required]
+ImageMeta +		(Members of ImageMeta are embedded into this type.) + `ImageMeta` allows to customize the container used for etcd.
dataDir [Required]
+string +		 + `dataDir` is the directory etcd will place its data. +Defaults to "/var/lib/etcd".
extraArgs [Required]
+map[string]string +		 + `extraArgs` are extra arguments provided to the etcd binary +when run inside a static pod.
serverCertSANs [Required]
+[]string +		 + `serverCertSANs` sets extra Subject Alternative Names for the etcd server signing cert.
peerCertSANs [Required]
+[]string +		 + `peerCertSANs` sets extra Subject Alternative Names for the etcd peer signing cert.
+ + + +## `Networking` {#kubeadm-k8s-io-v1beta2-Networking} + + + + +**Appears in:** + +- [ClusterConfiguration](#kubeadm-k8s-io-v1beta2-ClusterConfiguration) + + +Networking contains elements describing cluster's networking configuration + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
serviceSubnet [Required]
+string +		 + `serviceSubnet` is the subnet used by k8s services. Defaults to "10.96.0.0/12".
podSubnet [Required]
+string +		 + `podSubnet` is the subnet used by Pods.
dnsDomain [Required]
+string +		 + `dnsDomain` is the DNS domain used by k8s services. Defaults to "cluster.local".
+ + + +## `NodeRegistrationOptions` {#kubeadm-k8s-io-v1beta2-NodeRegistrationOptions} + + + + +**Appears in:** + +- [InitConfiguration](#kubeadm-k8s-io-v1beta2-InitConfiguration) + +- [JoinConfiguration](#kubeadm-k8s-io-v1beta2-JoinConfiguration) + + +NodeRegistrationOptions holds fields that relate to registering a new control-plane or node to the cluster, either via "kubeadm init" or "kubeadm join" + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
name [Required]
+string +		 + `name` is the `.metadata.name` field of the Node API object that will be created in this +`kubeadm init` or `kubeadm join` operation. +This field is also used in the CommonName field of the kubelet's client certificate to the +API server. Defaults to the hostname of the node if not provided.
criSocket [Required]
+string +		 + `criSocket` is used to retrieve container runtime info. This information will be +annotated to the Node API object, for later re-use.
taints [Required]
+[]core/v1.Taint +		 + `taints` specifies the taints the Node API object should be registered with. If +this field is unset, i.e. nil, in the `kubeadm init` process, it will be defaulted +to `['"node-role.kubernetes.io/master"=""']`. If you don't want to taint your +control-plane node, set this field to an empty list, i.e. `taints: []` in the YAML +file. This field is solely used for Node registration.
kubeletExtraArgs [Required]
+map[string]string +		 + `kubeletExtraArgs` passes through extra arguments to the kubelet. The arguments here +are passed to the kubelet command line via the environment file kubeadm writes at +runtime for the kubelet to source. This overrides the generic base-level +configuration in the "kubelet-config-1.X" ConfigMap. Flags have higher priority when +parsing. These values are local and specific to the node kubeadm is executing on.
ignorePreflightErrors [Required]
+[]string +		 + `ignorePreflightErrors` provides a slice of pre-flight errors to be ignored when +the current node is registered.
+ + diff --git a/content/en/docs/reference/config-api/kubeadm-config.v1beta3.md b/content/en/docs/reference/config-api/kubeadm-config.v1beta3.md new file mode 100644 index 0000000000..5f73e8b3a8 --- /dev/null +++ b/content/en/docs/reference/config-api/kubeadm-config.v1beta3.md @@ -0,0 +1,1535 @@ +--- +title: kubeadm Configuration (v1beta3) +content_type: tool-reference +package: kubeadm.k8s.io/v1beta3 +auto_generated: true +--- +Package v1beta3 defines the v1beta3 version of the kubeadm configuration file format. +This version improves on the v1beta2 format by fixing some minor issues and adding a few new fields. + +A list of changes since v1beta2: + +- The deprecated `ClusterConfiguration.useHyperKubeImage` field has been removed. + Kubeadm no longer supports the hyperkube image. +- The `ClusterConfiguration.dns.type` field has been removed since CoreDNS is the only supported + DNS server type by kubeadm. +- Include "datapolicy" tags on the fields that hold secrets. + This would result in the field values to be omitted when API structures are printed with klog. +- Add `InitConfiguration.skipPhases`, `JoinConfiguration.skipPhases` to allow skipping + a list of phases during kubeadm init/join command execution. +- Add `InitConfiguration.nodeRegistration.imagePullPolicy" and + `JoinConfiguration.nodeRegistration.imagePullPolicy` to allow specifying + the images pull policy during kubeadm "init" and "join". The value must be + one of "Always", "Never" or "IfNotPresent". "IfNotPresent" is the default, + which has been the existing behavior prior to this addition. +- Add `InitConfiguration.patches.directory`, `JoinConfiguration.patches.directory` + to allow the user to configure a directory from which to take patches for + components deployed by kubeadm. +- Move the `BootstrapToken∗` API and related utilities out of the "kubeadm" API group + to a new group "bootstraptoken". The kubeadm API version v1beta3 no longer contains + the `BootstrapToken∗` structures. + +## Migration from old kubeadm config versions + +- kubeadm v1.15.x and newer can be used to migrate from the v1beta1 to v1beta2. +- kubeadm v1.22.x no longer supports v1beta1 and older APIs, but can be used to migrate v1beta2 to v1beta3. + +## Basics + +The preferred way to configure kubeadm is to pass an YAML configuration file with the --config option. Some of the +configuration options defined in the kubeadm config file are also available as command line flags, but only +the most common/simple use case are supported with this approach. + +A kubeadm config file could contain multiple configuration types separated using three dashes (“---”). + +kubeadm supports the following configuration types: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: InitConfiguration +--- +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +--- +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +--- +apiVersion: kubeproxy.config.k8s.io/v1alpha1 +kind: KubeProxyConfiguration +--- +apiVersion: kubeadm.k8s.io/v1beta3 +kind: JoinConfiguration +``` + +To print the defaults for "init" and "join" actions use the following commands: + +```shell +kubeadm config print init-defaults +kubeadm config print join-defaults +``` + +The list of configuration types that must be included in a configuration file depends by the action you are +performing (init or join) and by the configuration options you are going to use (defaults or advanced customization). + +If some configuration types are not provided, or provided only partially, kubeadm will use default values; defaults +provided by kubeadm includes also enforcing consistency of values across components when required (e.g. +cluster-cidr flag on controller manager and clusterCIDR on kube-proxy). + +Users are always allowed to override default values, with the only exception of a small subset of setting with +relevance for security (e.g. enforce authorization-mode Node and RBAC on api server) + +If the user provides a configuration types that is not expected for the action you are performing, kubeadm will +ignore those types and print a warning. + +## Kubeadm init configuration types + +When executing kubeadm init with the `--config` option, the following configuration types could be used: +InitConfiguration, ClusterConfiguration, KubeProxyConfiguration, KubeletConfiguration, but only one +between InitConfiguration and ClusterConfiguration is mandatory. + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: InitConfiguration +bootstrapTokens: + ... +nodeRegistration: + ... +``` + +The InitConfiguration type should be used to configure runtime settings, that in case of kubeadm init +are the configuration of the bootstrap token and all the setting which are specific to the node where kubeadm +is executed, including: + +- NodeRegistration, that holds fields that relate to registering the new node to the cluster; + use it to customize the node name, the CRI socket to use or any other settings that should apply to this + node only (e.g. the node ip). + +- LocalAPIEndpoint, that represents the endpoint of the instance of the API server to be deployed on this node; + use it e.g. to customize the API server advertise address. + + ```yaml + apiVersion: kubeadm.k8s.io/v1beta3 + kind: ClusterConfiguration + networking: + ... + etcd: + ... + apiServer: + extraArgs: + ... + extraVolumes: + ... + ... + ``` + +The ClusterConfiguration type should be used to configure cluster-wide settings, +including settings for: + +- Networking, that holds configuration for the networking topology of the cluster; use it e.g. to customize + pod subnet or services subnet. +- Etcd configurations; use it e.g. to customize the local etcd or to configure the API server + for using an external etcd cluster. +- kube-apiserver, kube-scheduler, kube-controller-manager configurations; use it to customize control-plane + components by adding customized setting or overriding kubeadm default settings. + + ```yaml + apiVersion: kubeproxy.config.k8s.io/v1alpha1 + kind: KubeProxyConfiguration + ... + ``` + +The KubeProxyConfiguration type should be used to change the configuration passed to kube-proxy instances deployed +in the cluster. If this object is not provided or provided only partially, kubeadm applies defaults. + +See https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/ or https://godoc.org/k8s.io/kube-proxy/config/v1alpha1#KubeProxyConfiguration +for kube proxy official documentation. + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +... +``` + +The KubeletConfiguration type should be used to change the configurations that will be passed to all kubelet instances +deployed in the cluster. If this object is not provided or provided only partially, kubeadm applies defaults. + +See https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/ or https://godoc.org/k8s.io/kubelet/config/v1beta1#KubeletConfiguration +for kubelet official documentation. + +Here is a fully populated example of a single YAML file containing multiple +configuration types to be used during a `kubeadm init` run. + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: InitConfiguration +bootstrapTokens: + - token: "9a08jv.c0izixklcxtmnze7" + description: "kubeadm bootstrap token" + ttl: "24h" + - token: "783bde.3f89s0fje9f38fhf" + description: "another bootstrap token" + usages: + - authentication + - signing + groups: + - system:bootstrappers:kubeadm:default-node-token +nodeRegistration: + name: "ec2-10-100-0-1" + criSocket: "/var/run/dockershim.sock" + taints: + - key: "kubeadmNode" + value: "master" + effect: "NoSchedule" + kubeletExtraArgs: + v: 4 + ignorePreflightErrors: + - IsPrivilegedUser + imagePullPolicy: "IfNotPresent" +localAPIEndpoint: + advertiseAddress: "10.100.0.1" + bindPort: 6443 +certificateKey: "e6a2eb8581237ab72a4f494f30285ec12a9694d750b9785706a83bfcbbbd2204" +skipPhases: + - add/kube-proxy +--- +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +etcd: + # one of local or external + local: + imageRepository: "k8s.gcr.io" + imageTag: "3.2.24" + dataDir: "/var/lib/etcd" + extraArgs: + listen-client-urls: "http://10.100.0.1:2379" + serverCertSANs: + - "ec2-10-100-0-1.compute-1.amazonaws.com" + peerCertSANs: + - "10.100.0.1" + # external: + # endpoints: + # - "10.100.0.1:2379" + # - "10.100.0.2:2379" + # caFile: "/etcd/kubernetes/pki/etcd/etcd-ca.crt" + # certFile: "/etcd/kubernetes/pki/etcd/etcd.crt" + # keyFile: "/etcd/kubernetes/pki/etcd/etcd.key" +networking: + serviceSubnet: "10.96.0.0/12" + podSubnet: "10.100.0.1/24" + dnsDomain: "cluster.local" +kubernetesVersion: "v1.12.0" +controlPlaneEndpoint: "10.100.0.1:6443" +apiServer: + extraArgs: + authorization-mode: "Node,RBAC" + extraVolumes: + - name: "some-volume" + hostPath: "/etc/some-path" + mountPath: "/etc/some-pod-path" + readOnly: false + pathType: File + certSANs: + - "10.100.1.1" + - "ec2-10-100-0-1.compute-1.amazonaws.com" + timeoutForControlPlane: 4m0s +controllerManager: + extraArgs: + "node-cidr-mask-size": "20" + extraVolumes: + - name: "some-volume" + hostPath: "/etc/some-path" + mountPath: "/etc/some-pod-path" + readOnly: false + pathType: File +scheduler: + extraArgs: + address: "10.100.0.1" + extraVolumes: + - name: "some-volume" + hostPath: "/etc/some-path" + mountPath: "/etc/some-pod-path" + readOnly: false + pathType: File +certificatesDir: "/etc/kubernetes/pki" +imageRepository: "k8s.gcr.io" +clusterName: "example-cluster" +--- +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +# kubelet specific options here +--- +apiVersion: kubeproxy.config.k8s.io/v1alpha1 +kind: KubeProxyConfiguration +# kube-proxy specific options here +``` + +## Kubeadm join configuration types + +When executing kubeadm join with the `--config` option, the JoinConfiguration type should be provided. + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: JoinConfiguration +... +``` + +The JoinConfiguration type should be used to configure runtime settings, that in case of kubeadm join +are the discovery method used for accessing the cluster info and all the setting which are specific +to the node where kubeadm is executed, including: + +- NodeRegistration, that holds fields that relate to registering the new node to the cluster; + use it to customize the node name, the CRI socket to use or any other settings that should apply to this + node only (e.g. the node ip). +- APIEndpoint, that represents the endpoint of the instance of the API server to be eventually + deployed on this node. + +## Resource Types + + +- [ClusterConfiguration](#kubeadm-k8s-io-v1beta3-ClusterConfiguration) +- [InitConfiguration](#kubeadm-k8s-io-v1beta3-InitConfiguration) +- [JoinConfiguration](#kubeadm-k8s-io-v1beta3-JoinConfiguration) + + + + +## `ClusterConfiguration` {#kubeadm-k8s-io-v1beta3-ClusterConfiguration} + + + + + +ClusterConfiguration contains cluster-wide configuration for a kubeadm cluster + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubeadm.k8s.io/v1beta3
kind
string		ClusterConfiguration
etcd
+Etcd +		 + `etcd` holds configuration for etcd.
networking
+Networking +		 + `networking` holds configuration for the networking topology of the cluster.
kubernetesVersion
+string +		 + `kubernetesVersion` is the target version of the control plane.
controlPlaneEndpoint
+string +		 + `controlPlaneEndpoint` sets a stable IP address or DNS name for the control plane; it +can be a valid IP address or a RFC-1123 DNS subdomain, both with optional TCP port. +In case the `controlPlaneEndpoint` is not specified, the `advertiseAddress` + `bindPort` +are used; in case the `controlPlaneEndpoint` is specified but without a TCP port, +the `bindPort` of the `localAPIEndpoint` is used. +Possible usages are: + +- In a cluster with more than one control plane instances, this field should be + assigned the address of the external load balancer in front of the + control plane instances. +- In environments with enforced node recycling, the ControlPlaneEndpoint + could be used for assigning a stable DNS to the control plane.
apiServer
+APIServer +		 + `apiServer` contains extra settings for the API server.
controllerManager
+ControlPlaneComponent +		 + `controllerManager` contains extra settings for the controller manager.
scheduler
+ControlPlaneComponent +		 + `scheduler` contains extra settings for the scheduler.
dns
+DNS +		 + `dns` defines the options for the DNS add-on.
certificatesDir
+string +		 + `certificatesDir` specifies where to store or look for all required certificates.
imageRepository
+string +		 + `imageRepository` sets the container registry to pull images from. +If empty, `k8s.gcr.io` will be used by default; in case of kubernetes version is +a CI build (kubernetes version starts with `ci/` or `ci-cross/`) +`gcr.io/k8s-staging-ci-images` will be used as a default for control plane +components and for kube-proxy, while `k8s.gcr.io` will be used for all the other images.
featureGates
+map[string]bool +		 + Feature gates enabled by the user.
clusterName
+string +		 + The cluster name.
+ + + +## `InitConfiguration` {#kubeadm-k8s-io-v1beta3-InitConfiguration} + + + + + +InitConfiguration contains a list of elements that is specific "kubeadm init"-only runtime +information. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubeadm.k8s.io/v1beta3
kind
string		InitConfiguration
bootstrapTokens
+[]BootstrapToken +		 + `bootstrapTokens` is respected at `kubeadm init` time and describes a set of Bootstrap Tokens to create. +This information IS NOT uploaded to the kubeadm cluster configmap, partly because of its sensitive nature.
nodeRegistration
+NodeRegistrationOptions +		 + `nodeRegistration` holds fields that relate to registering the new control-plane node to the cluster
localAPIEndpoint
+APIEndpoint +		 + `localAPIEndpoint` represents the endpoint of the API server instance that's deployed on this control plane node +In HA setups, this differs from ClusterConfiguration.ControlPlaneEndpoint in the sense that ControlPlaneEndpoint +is the global endpoint for the cluster, which then loadbalances the requests to each individual API server. This +configuration object lets you customize what IP/DNS name and port the local API server advertises it's accessible +on. By default, kubeadm tries to auto-detect the IP of the default interface and use that, but in case that process +fails you may set the desired value here.
certificateKey
+string +		 + `certificateKey` sets the key with which certificates and keys are encrypted prior to being uploaded in +a Secret in the cluster during the "uploadcerts" init phase.
skipPhases
+[]string +		 + `skipPhases` is a list of phases to skip during command execution. +The list of phases can be obtained with the `kubeadm init --help` command. +The flag `--skip-phases` takes precedence over this field.
patches
+Patches +		 + `patches` contains options related to applying patches to components deployed by kubeadm during +"kubeadm init".
+ + + +## `JoinConfiguration` {#kubeadm-k8s-io-v1beta3-JoinConfiguration} + + + + + +JoinConfiguration contains elements describing a particular node. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		kubeadm.k8s.io/v1beta3
kind
string		JoinConfiguration
nodeRegistration
+NodeRegistrationOptions +		 + `nodeRegistration` holds fields that relate to registering the new control-plane +node to the cluster
caCertPath
+string +		 + `caCertPath` is the path to the SSL certificate authority used to +secure comunications between node and control-plane. +Defaults to "/etc/kubernetes/pki/ca.crt".
discovery [Required]
+Discovery +		 + `discovery` specifies the options for the kubelet to use during the TLS Bootstrap process.
controlPlane
+JoinControlPlane +		 + `controlPlane` defines the additional control plane instance to be deployed on the +joining node. If nil, no additional control plane instance will be deployed.
skipPhases
+[]string +		 + `skipPhases` is a list of phases to skip during command execution. +The list of phases can be obtained with the `kubeadm join --help` command. +The flag `--skip-phases` takes precedence over this field.
patches
+Patches +		 + `patches` contains options related to applying patches to components deployed by kubeadm during +`kubeadm join`.
+ + + +## `APIEndpoint` {#kubeadm-k8s-io-v1beta3-APIEndpoint} + + + + +**Appears in:** + +- [InitConfiguration](#kubeadm-k8s-io-v1beta3-InitConfiguration) + +- [JoinControlPlane](#kubeadm-k8s-io-v1beta3-JoinControlPlane) + + +APIEndpoint struct contains elements of API server instance deployed on a node. + + + + + + + + + + + + + + + + + + +
FieldDescription
advertiseAddress
+string +		 + `advertiseAddress` sets the IP address for the API server to advertise.
bindPort
+int32 +		 + `bindPort` sets the secure port for the API Server to bind to. Defaults to 6443.
+ + + +## `APIServer` {#kubeadm-k8s-io-v1beta3-APIServer} + + + + +**Appears in:** + +- [ClusterConfiguration](#kubeadm-k8s-io-v1beta3-ClusterConfiguration) + + +APIServer holds settings necessary for API server deployments in the cluster + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
ControlPlaneComponent [Required]
+ControlPlaneComponent +		(Members of ControlPlaneComponent are embedded into this type.) + No description provided. +
certSANs
+[]string +		 + `certSANs` sets extra Subject Alternative Names for the API Server signing cert.
timeoutForControlPlane
+meta/v1.Duration +		 + `timeoutForControlPlane` controls the timeout that we use for API server to appear
+ + + +## `BootstrapTokenDiscovery` {#kubeadm-k8s-io-v1beta3-BootstrapTokenDiscovery} + + + + +**Appears in:** + +- [Discovery](#kubeadm-k8s-io-v1beta3-Discovery) + + +BootstrapTokenDiscovery is used to set the options for bootstrap token based discovery + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
token [Required]
+string +		 + `token` is a token used to validate cluster information fetched from the control-plane.
apiServerEndpoint
+string +		 + `apiServerEndpoint` is an IP or domain name to the API server from which +information will be fetched.
caCertHashes
+[]string +		 + CACertHashes specifies a set of public key pins to verify when token-based +discovery is used. The root CA found during discovery must match one of these +values. Specifying an empty set disables root CA pinning, which can be unsafe. +Each hash is specified as `:`, where the only currently supported +type is "sha256". This is a hex-encoded SHA-256 hash of the Subject Public Key +Info (SPKI) object in DER-encoded ASN.1. These hashes can be calculated using, +for example, OpenSSL.
unsafeSkipCAVerification
+bool +		 + `unsafeSkipCAVerification` allows token-based discovery without CA verification +via `caCertHashes`. This can weaken the security of kubeadm since other nodes +can impersonate the control-plane.
+ + + +## `ControlPlaneComponent` {#kubeadm-k8s-io-v1beta3-ControlPlaneComponent} + + + + +**Appears in:** + +- [ClusterConfiguration](#kubeadm-k8s-io-v1beta3-ClusterConfiguration) + +- [APIServer](#kubeadm-k8s-io-v1beta3-APIServer) + + +ControlPlaneComponent holds settings common to control plane component of the cluster + + + + + + + + + + + + + + + + + + +
FieldDescription
extraArgs
+map[string]string +		 + `extraArgs` is an extra set of flags to pass to the control plane component. +A key in this map is the flag name as it appears on the +command line except without leading dash(es).
extraVolumes
+[]HostPathMount +		 + `extraVolumes` is an extra set of host volumes, mounted to the control plane component.
+ + + +## `DNS` {#kubeadm-k8s-io-v1beta3-DNS} + + + + +**Appears in:** + +- [ClusterConfiguration](#kubeadm-k8s-io-v1beta3-ClusterConfiguration) + + +DNS defines the DNS addon that should be used in the cluster + + + + + + + + + + + + + +
FieldDescription
ImageMeta [Required]
+ImageMeta +		(Members of ImageMeta are embedded into this type.) + `imageMeta` allows to customize the image used for the DNS component.
+ + + +## `DNSAddOnType` {#kubeadm-k8s-io-v1beta3-DNSAddOnType} + +(Alias of `string`) + + + +DNSAddOnType defines string identifying DNS add-on types + + + + + +## `Discovery` {#kubeadm-k8s-io-v1beta3-Discovery} + + + + +**Appears in:** + +- [JoinConfiguration](#kubeadm-k8s-io-v1beta3-JoinConfiguration) + + +Discovery specifies the options for the kubelet to use during the TLS Bootstrap process + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
bootstrapToken
+BootstrapTokenDiscovery +		 + `bootstrapToken` is used to set the options for bootstrap token based discovery. +`bootstrapToken` and `file` are mutually exclusive.
file
+FileDiscovery +		 + `file` specifies a file or URL to a kubeconfig file from which to load cluster information. +`bootstrapToken` and `file` are mutually exclusive.
tlsBootstrapToken
+string +		 + `tlsBootstrapToken` is a token used for TLS bootstrapping. +If `bootstrapToken` is set, this field is defaulted to `bootstrapToken.token`, +but can be overridden. +If `file` is set, this field ∗∗must be set∗∗ in case the KubeConfigFile does +not contain any other authentication information
timeout
+meta/v1.Duration +		 + `timeout` modifies the discovery timeout.
+ + + +## `Etcd` {#kubeadm-k8s-io-v1beta3-Etcd} + + + + +**Appears in:** + +- [ClusterConfiguration](#kubeadm-k8s-io-v1beta3-ClusterConfiguration) + + +Etcd contains elements describing Etcd configuration. + + + + + + + + + + + + + + + + + + +
FieldDescription
local
+LocalEtcd +		 + `local` provides configuration knobs for configuring the local etcd instance. +`local` and `external` are mutually exclusive.
external
+ExternalEtcd +		 + `external` describes how to connect to an external etcd cluster. +`local` and `external` are mutually exclusive.
+ + + +## `ExternalEtcd` {#kubeadm-k8s-io-v1beta3-ExternalEtcd} + + + + +**Appears in:** + +- [Etcd](#kubeadm-k8s-io-v1beta3-Etcd) + + +ExternalEtcd describes an external etcd cluster. +Kubeadm has no knowledge of where certificate files live and they must be supplied. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
endpoints [Required]
+[]string +		 + `endpoints` are endpoints of etcd members. This field is required.
caFile [Required]
+string +		 + `caFile` is an SSL Certificate Authority file used to secure etcd communication. +Required if using a TLS connection.
certFile [Required]
+string +		 + `certFile` is an SSL certification file used to secure etcd communication. +Required if using a TLS connection.
keyFile [Required]
+string +		 + `keyFile` is an SSL key file used to secure etcd communication. +Required if using a TLS connection.
+ + + +## `FileDiscovery` {#kubeadm-k8s-io-v1beta3-FileDiscovery} + + + + +**Appears in:** + +- [Discovery](#kubeadm-k8s-io-v1beta3-Discovery) + + +FileDiscovery is used to specify a file or URL to a kubeconfig file from which to load cluster information + + + + + + + + + + + + + +
FieldDescription
kubeConfigPath [Required]
+string +		 + `kubeConfigPath` specifies the actual file path or URL to the kubeconfig file +from which to load cluster information
+ + + +## `HostPathMount` {#kubeadm-k8s-io-v1beta3-HostPathMount} + + + + +**Appears in:** + +- [ControlPlaneComponent](#kubeadm-k8s-io-v1beta3-ControlPlaneComponent) + + +HostPathMount contains elements describing volumes that are mounted from the host. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
name [Required]
+string +		 + `name` is the volume name inside the Pod template.
hostPath [Required]
+string +		 + `hostPath` is the path in the host that will be mounted inside the Pod.
mountPath [Required]
+string +		 + `mountPath` is the path inside the Pod where the `hostPath` volume is mounted.
readOnly
+bool +		 + `readOnly` controls write access to the volume.
pathType
+core/v1.HostPathType +		 + `pathType` is the type of the `hostPath` volume.
+ + + +## `ImageMeta` {#kubeadm-k8s-io-v1beta3-ImageMeta} + + + + +**Appears in:** + +- [DNS](#kubeadm-k8s-io-v1beta3-DNS) + +- [LocalEtcd](#kubeadm-k8s-io-v1beta3-LocalEtcd) + + +ImageMeta allows to customize the image used for components that are not +originated from the Kubernetes/Kubernetes release process + + + + + + + + + + + + + + + + + + +
FieldDescription
imageRepository
+string +		 + `imageRepository` sets the container registry to pull images from. +If not set, the ImageRepository defined in ClusterConfiguration will be used instead.
imageTag
+string +		 + `imageTag` allows to specify a tag for the image. +In case this value is set, kubeadm does not change automatically the +version of the above components during upgrades.
+ + + +## `JoinControlPlane` {#kubeadm-k8s-io-v1beta3-JoinControlPlane} + + + + +**Appears in:** + +- [JoinConfiguration](#kubeadm-k8s-io-v1beta3-JoinConfiguration) + + +JoinControlPlane contains elements describing an additional control plane instance to be deployed on the joining node. + + + + + + + + + + + + + + + + + + +
FieldDescription
localAPIEndpoint
+APIEndpoint +		 + `localAPIEndpoint` represents the endpoint of the API server instance to be deployed +on this node.
certificateKey
+string +		 + `certificateKey` is the key that is used for decryption of certificates after they +are downloaded from the secret upon joining a new control plane node. The +corresponding encryption key is in the InitConfiguration.
+ + + +## `LocalEtcd` {#kubeadm-k8s-io-v1beta3-LocalEtcd} + + + + +**Appears in:** + +- [Etcd](#kubeadm-k8s-io-v1beta3-Etcd) + + +LocalEtcd describes that kubeadm should run an etcd cluster locally + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
ImageMeta [Required]
+ImageMeta +		(Members of ImageMeta are embedded into this type.) + `ImageMeta` allows to customize the container used for etcd.
dataDir [Required]
+string +		 + `dataDir` is the directory etcd will place its data. +Defaults to "/var/lib/etcd".
extraArgs
+map[string]string +		 + `extraArgs` are extra arguments provided to the etcd binary +when run inside a static pod. +A key in this map is the flag name as it appears on the command line except +without leading dash(es).
serverCertSANs
+[]string +		 + `serverCertSANs` sets extra Subject Alternative Names for the etcd server signing cert.
peerCertSANs
+[]string +		 + `peerCertSANs` sets extra Subject Alternative Names for the etcd peer signing cert.
+ + + +## `Networking` {#kubeadm-k8s-io-v1beta3-Networking} + + + + +**Appears in:** + +- [ClusterConfiguration](#kubeadm-k8s-io-v1beta3-ClusterConfiguration) + + +Networking contains elements describing cluster's networking configuration + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
serviceSubnet
+string +		 + `serviceSubnet` is the subnet used by k8s services. Defaults to "10.96.0.0/12".
podSubnet
+string +		 + `podSubnet` is the subnet used by Pods.
dnsDomain
+string +		 + `dnsDomain` is the DNS domain used by k8s services. Defaults to "cluster.local".
+ + + +## `NodeRegistrationOptions` {#kubeadm-k8s-io-v1beta3-NodeRegistrationOptions} + + + + +**Appears in:** + +- [InitConfiguration](#kubeadm-k8s-io-v1beta3-InitConfiguration) + +- [JoinConfiguration](#kubeadm-k8s-io-v1beta3-JoinConfiguration) + + +NodeRegistrationOptions holds fields that relate to registering a new control-plane or node to the cluster, either via "kubeadm init" or "kubeadm join" + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
name
+string +		 + `name` is the `.metadata.name` field of the Node API object that will be created in this +`kubeadm init` or `kubeadm join` operation. +This field is also used in the `CommonName` field of the kubelet's client certificate to the +API server. Defaults to the hostname of the node if not provided.
criSocket
+string +		 + `criSocket` is used to retrieve container runtime info. This information will be +annotated to the Node API object, for later re-use.
taints [Required]
+[]core/v1.Taint +		 + `taints` specifies the taints the Node API object should be registered with. If +this field is unset, i.e. nil, in the `kubeadm init` process, it will be defaulted +to `['"node-role.kubernetes.io/master"=""']`. If you don't want to taint your +control-plane node, set this field to an empty list, i.e. `taints: []` in the YAML +file. This field is solely used for Node registration.
kubeletExtraArgs
+map[string]string +		 + `kubeletExtraArgs` passes through extra arguments to the kubelet. The arguments here +are passed to the kubelet command line via the environment file kubeadm writes at +runtime for the kubelet to source. This overrides the generic base-level +configuration in the "kubelet-config-1.X" ConfigMap. Flags have higher priority when +parsing. These values are local and specific to the node kubeadm is executing on. +A key in this map is the flag name as it appears on the command line except without +leading dash(es).
ignorePreflightErrors
+[]string +		 + `ignorePreflightErrors` provides a slice of pre-flight errors to be ignored when +the current node is registered.
imagePullPolicy
+core/v1.PullPolicy +		 + `imagePullPolicy` specifies the policy for image pulling during `kubeadm init` and +`kubeadm join` operations. +The value of this field must be one of "Always", "IfNotPresent" or "Never". +If this field is unset kubeadm will default it to "IfNotPresent", or pull the required +images if not present on the host.
+ + + +## `Patches` {#kubeadm-k8s-io-v1beta3-Patches} + + + + +**Appears in:** + +- [InitConfiguration](#kubeadm-k8s-io-v1beta3-InitConfiguration) + +- [JoinConfiguration](#kubeadm-k8s-io-v1beta3-JoinConfiguration) + + +Patches contains options related to applying patches to components deployed by kubeadm. + + + + + + + + + + + + + +
FieldDescription
directory
+string +		 + `directory` is a path to a directory that contains files named +`target[suffix][+patchtype].extension`. +For example, `kube-apiserver0+merge.yaml` or just `etcd.json`. `target` can be one of +"kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". `patchtype` can be one +of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. +The default `patchtype` is "strategic". `extension` must be either "json" or "yaml". +`suffix` is an optional string that can be used to determine which patches are applied +first alpha-numerically.
+ + + + + +## `BootstrapToken` {#BootstrapToken} + + + + +**Appears in:** + +- [InitConfiguration](#kubeadm-k8s-io-v1beta3-InitConfiguration) + + +BootstrapToken describes one bootstrap token, stored as a Secret in the cluster + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FieldDescription
token [Required]
+BootstrapTokenString +		 + `token` is used for establishing bidirectional trust between nodes and control-planes. +Used for joining nodes in the cluster.
description
+string +		 + `description` sets a human-friendly message why this token exists and what it's used +for, so other administrators can know its purpose.
ttl
+meta/v1.Duration +		 + `ttl` defines the time to live for this token. Defaults to `24h`. +`expires` and `ttl` are mutually exclusive.
expires
+meta/v1.Time +		 + `expires` specifies the timestamp when this token expires. Defaults to being set +dynamically at runtime based on the `ttl`. `expires` and `ttl` are mutually exclusive.
usages
+[]string +		 + `usages` describes the ways in which this token can be used. Can by default be used +for establishing bidirectional trust, but that can be changed here.
groups
+[]string +		 + `groups` specifies the extra groups that this token will authenticate as when/if +used for authentication
+ +## `BootstrapTokenString` {#BootstrapTokenString} + + + + +**Appears in:** + +- [BootstrapToken](#BootstrapToken) + + +BootstrapTokenString is a token of the format `abcdef.abcdef0123456789` that is used +for both validation of the practically of the API server from a joining node's point +of view and as an authentication method for the node in the bootstrap phase of +"kubeadm join". This token is and should be short-lived. + + + + + + + + + + + + + + + + + + +
FieldDescription
- [Required]
+string +		 + No description provided. +
- [Required]
+string +		 + No description provided. +
diff --git a/content/en/docs/reference/config-api/kubelet-config.v1beta1.md b/content/en/docs/reference/config-api/kubelet-config.v1beta1.md index bee05b68db..261a6dd5f8 100644 --- a/content/en/docs/reference/config-api/kubelet-config.v1beta1.md +++ b/content/en/docs/reference/config-api/kubelet-config.v1beta1.md @@ -39,7 +39,8 @@ KubeletConfiguration contains the configuration for the Kubelet enableServer enables Kubelet's secured server. Note: Kubelet's insecure port is controlled by the readOnlyPort option. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may disrupt components that interact with the Kubelet server. Default: true @@ -51,7 +52,8 @@ Default: true staticPodPath is the path to the directory containing local (static) pods to run, or the path to a single static pod file. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that the set of static pods specified at the new path may be different than the ones the Kubelet initially started with, and this may disrupt your node. Default: "" @@ -64,7 +66,8 @@ Default: "" syncFrequency is the max period between synchronizing running containers and config. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that shortening this duration may have a negative performance impact, especially as the number of Pods on the node increases. Alternatively, increasing this duration will result in longer refresh times for ConfigMaps and Secrets. @@ -77,8 +80,9 @@ Default: "1m" fileCheckFrequency is the duration between checking config files for -new data -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +new data. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that shortening the duration will cause the Kubelet to reload local Static Pod configurations more frequently, which may have a negative performance impact. Default: "20s" @@ -89,8 +93,9 @@ Default: "20s" meta/v1.Duration - httpCheckFrequency is the duration between checking http for new data -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + httpCheckFrequency is the duration between checking http for new data. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that shortening the duration will cause the Kubelet to poll staticPodURL more frequently, which may have a negative performance impact. Default: "20s" @@ -101,8 +106,9 @@ Default: "20s" string - staticPodURL is the URL for accessing static pods to run -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + staticPodURL is the URL for accessing static pods to run. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that the set of static pods specified at the new URL may be different than the ones the Kubelet initially started with, and this may disrupt your node. Default: "" @@ -113,8 +119,9 @@ Default: "" map[string][]string - staticPodURLHeader is a map of slices with HTTP headers to use when accessing the podURL -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + staticPodURLHeader is a map of slices with HTTP headers to use when accessing the podURL. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may disrupt the ability to read the latest set of static pods from StaticPodURL. Default: nil @@ -126,7 +133,8 @@ Default: nil address is the IP address for the Kubelet to serve on (set to 0.0.0.0 for all interfaces). -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may disrupt components that interact with the Kubelet server. Default: "0.0.0.0" @@ -137,7 +145,9 @@ Default: "0.0.0.0" port is the port for the Kubelet to serve on. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +The port number must be between 1 and 65535, inclusive. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may disrupt components that interact with the Kubelet server. Default: 10250 @@ -149,7 +159,10 @@ Default: 10250 readOnlyPort is the read-only port for the Kubelet to serve on with no authentication/authorization. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +The port number must be between 1 and 65535, inclusive. +Setting this field to 0 disables the read-only service. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may disrupt components that interact with the Kubelet server. Default: 0 (disabled) @@ -164,7 +177,8 @@ if any, concatenated after server cert). If tlsCertFile and tlsPrivateKeyFile are not provided, a self-signed certificate and key are generated for the public address and saved to the directory passed to the Kubelet's --cert-dir flag. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may disrupt components that interact with the Kubelet server. Default: "" @@ -174,8 +188,9 @@ Default: "" string - tlsPrivateKeyFile is the file containing x509 private key matching tlsCertFile -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + tlsPrivateKeyFile is the file containing x509 private key matching tlsCertFile. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may disrupt components that interact with the Kubelet server. Default: "" @@ -185,9 +200,10 @@ Default: "" []string - TLSCipherSuites is the list of allowed cipher suites for the server. + tlsCipherSuites is the list of allowed cipher suites for the server. Values are from tls package constants (https://golang.org/pkg/crypto/tls/#pkg-constants). -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may disrupt components that interact with the Kubelet server. Default: nil @@ -197,9 +213,10 @@ Default: nil string - TLSMinVersion is the minimum TLS version supported. + tlsMinVersion is the minimum TLS version supported. Values are from tls package constants (https://golang.org/pkg/crypto/tls/#pkg-constants). -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may disrupt components that interact with the Kubelet server. Default: "" @@ -212,7 +229,8 @@ Default: "" rotateCertificates enables client certificate rotation. The Kubelet will request a new certificate from the certificates.k8s.io API. This requires an approver to approve the certificate signing requests. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that disabling it may disrupt the Kubelet's ability to authenticate with the API server after the current certificate expires. Default: false @@ -225,10 +243,11 @@ Default: false serverTLSBootstrap enables server certificate bootstrap. Instead of self signing a serving certificate, the Kubelet will request a certificate from -the certificates.k8s.io API. This requires an approver to approve the -certificate signing requests. The RotateKubeletServerCertificate feature -must be enabled. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +the 'certificates.k8s.io' API. This requires an approver to approve the +certificate signing requests (CSR). The RotateKubeletServerCertificate feature +must be enabled when setting this field. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that disabling it will stop the renewal of Kubelet server certificates, which can disrupt components that interact with the Kubelet server in the long term, due to certificate expiration. @@ -240,8 +259,9 @@ Default: false KubeletAuthentication - authentication specifies how requests to the Kubelet's server are authenticated -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + authentication specifies how requests to the Kubelet's server are authenticated. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may disrupt components that interact with the Kubelet server. Defaults: anonymous: @@ -256,8 +276,9 @@ Defaults: KubeletAuthorization - authorization specifies how requests to the Kubelet's server are authorized -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + authorization specifies how requests to the Kubelet's server are authorized. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may disrupt components that interact with the Kubelet server. Defaults: mode: Webhook @@ -272,8 +293,10 @@ Defaults: registryPullQPS is the limit of registry pulls per second. -Set to 0 for no limit. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +The value must not be a negative number. +Setting it to 0 means no limit. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may impact scalability by changing the amount of traffic produced by image pulls. Default: 5 @@ -286,8 +309,10 @@ Default: 5 registryBurst is the maximum size of bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding registryPullQPS. -Only used if registryPullQPS > 0. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +The value must not be a negative number. +Only used if registryPullQPS is greater than 0. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may impact scalability by changing the amount of traffic produced by image pulls. Default: 10 @@ -299,8 +324,9 @@ Default: 10 eventRecordQPS is the maximum event creations per second. If 0, there -is no limit enforced. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +is no limit enforced. The value cannot be a negative number. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may impact scalability by changing the amount of traffic produced by event creations. Default: 5 @@ -313,8 +339,10 @@ Default: 5 eventBurst is the maximum size of a burst of event creations, temporarily allows event creations to burst to this number, while still not exceeding -eventRecordQPS. Only used if eventRecordQPS > 0. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +eventRecordQPS. This field canot be a negative number and it is only used +when eventRecordQPS > 0. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may impact scalability by changing the amount of traffic produced by event creations. Default: 10 @@ -328,7 +356,8 @@ Default: 10 enableDebuggingHandlers enables server endpoints for log access and local running of containers and commands, including the exec, attach, logs, and portforward features. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that disabling it may disrupt components that interact with the Kubelet server. Default: true @@ -339,7 +368,8 @@ Default: true enableContentionProfiling enables lock contention profiling, if enableDebuggingHandlers is true. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that enabling it may carry a performance impact. Default: false @@ -349,8 +379,10 @@ Default: false int32 - healthzPort is the port of the localhost healthz endpoint (set to 0 to disable) -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + healthzPort is the port of the localhost healthz endpoint (set to 0 to disable). +A valid number is between 1 and 65535. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may disrupt components that monitor Kubelet health. Default: 10248 @@ -360,8 +392,9 @@ Default: 10248 string - healthzBindAddress is the IP address for the healthz server to serve on -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + healthzBindAddress is the IP address for the healthz server to serve on. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may disrupt components that monitor Kubelet health. Default: "127.0.0.1" @@ -373,7 +406,8 @@ Default: "127.0.0.1" oomScoreAdj is The oom-score-adj value for kubelet process. Values must be within the range [-1000, 1000]. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may impact the stability of nodes under memory pressure. Default: -999 @@ -386,7 +420,7 @@ Default: -999 clusterDomain is the DNS domain for this cluster. If set, kubelet will configure all containers to search this domain in addition to the host's search domains. -Dynamic Kubelet Config (beta): Dynamically updating this field is not recommended, +Dynamic Kubelet Config (deprecated): Dynamically updating this field is not recommended, as it should be kept in sync with the rest of the cluster. Default: "" @@ -399,7 +433,8 @@ Default: "" clusterDNS is a list of IP addresses for the cluster DNS server. If set, kubelet will configure all containers to use this for DNS resolution instead of the host's DNS servers. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that changes will only take effect on Pods created after the update. Draining the node is recommended before changing this field. Default: nil @@ -412,7 +447,8 @@ Default: nil streamingConnectionIdleTimeout is the maximum time a streaming connection can be idle before the connection is automatically closed. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may impact components that rely on infrequent updates over streaming connections to the Kubelet server. Default: "4h" @@ -428,7 +464,8 @@ status. If node lease feature is not enabled, it is also the frequency that kubelet posts node status to master. Note: When node lease feature is not enabled, be cautious when changing the constant, it must work with nodeMonitorGracePeriod in nodecontroller. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may impact node scalability, and also that the node controller's nodeMonitorGracePeriod must be set to N∗NodeStatusUpdateFrequency, where N is the number of retries before the node controller marks @@ -445,10 +482,10 @@ Default: "10s" status to master if node status does not change. Kubelet will ignore this frequency and post node status immediately if any change is detected. It is only used when node lease feature is enabled. nodeStatusReportFrequency's -default value is 1m. But if nodeStatusUpdateFrequency is set explicitly, +default value is 5m. But if nodeStatusUpdateFrequency is set explicitly, nodeStatusReportFrequency's default value will be set to nodeStatusUpdateFrequency for backward compatibility. -Default: "1m" +Default: "5m" @@ -462,8 +499,10 @@ health by having the Kubelet create and periodically renew a lease, named after in the kube-node-lease namespace. If the lease expires, the node can be considered unhealthy. The lease is currently renewed every 10s, per KEP-0009. In the future, the lease renewal interval may be set based on the lease duration. +The field value must be greater than 0. Requires the NodeLease feature gate to be enabled. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that decreasing the duration may reduce tolerance for issues that temporarily prevent the Kubelet from renewing the lease (e.g. a short-lived network issue). Default: 40 @@ -476,7 +515,8 @@ Default: 40 imageMinimumGCAge is the minimum age for an unused image before it is garbage collected. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may trigger or delay garbage collection, and may change the image overhead on the node. Default: "2m" @@ -488,9 +528,12 @@ Default: "2m" imageGCHighThresholdPercent is the percent of disk usage after which -image garbage collection is always run. The percent is calculated as -this field value out of 100. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +image garbage collection is always run. The percent is calculated by +dividing this field value by 100, so this field must be between 0 and +100, inclusive. When specified, the value must be greater than +imageGCLowThresholdPercent. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may trigger or delay garbage collection, and may change the image overhead on the node. Default: 85 @@ -503,8 +546,11 @@ Default: 85 imageGCLowThresholdPercent is the percent of disk usage before which image garbage collection is never run. Lowest disk usage to garbage -collect to. The percent is calculated as this field value out of 100. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +collect to. The percent is calculated by dividing this field value by 100, +so the field value must be between 0 and 100, inclusive. When specified, the +value must be less than imageGCHighThresholdPercent. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may trigger or delay garbage collection, and may change the image overhead on the node. Default: 80 @@ -515,8 +561,10 @@ Default: 80 meta/v1.Duration - How frequently to calculate and cache volume disk usage for all pods -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + volumeStatsAggPeriod is the frequency for calculating and caching volume +disk usage for all pods. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that shortening the period may carry a performance impact. Default: "1m" @@ -527,7 +575,7 @@ Default: "1m" kubeletCgroups is the absolute name of cgroups to isolate the kubelet in -Dynamic Kubelet Config (beta): This field should not be updated without a full node +Dynamic Kubelet Config (deprecated): This field should not be updated without a full node reboot. It is safest to keep this value the same as the local config. Default: "" @@ -540,7 +588,8 @@ Default: "" systemCgroups is absolute name of cgroups in which to place all non-kernel processes that are not already in a container. Empty for no container. Rolling back the flag requires a reboot. -Dynamic Kubelet Config (beta): This field should not be updated without a full node +The cgroupRoot must be specified if this field is not empty. +Dynamic Kubelet Config (deprecated): This field should not be updated without a full node reboot. It is safest to keep this value the same as the local config. Default: "" @@ -552,7 +601,7 @@ Default: "" cgroupRoot is the root cgroup to use for pods. This is handled by the container runtime on a best effort basis. -Dynamic Kubelet Config (beta): This field should not be updated without a full node +Dynamic Kubelet Config (deprecated): This field should not be updated without a full node reboot. It is safest to keep this value the same as the local config. Default: "" @@ -562,10 +611,10 @@ Default: "" bool - Enable QoS based Cgroup hierarchy: top level cgroups for QoS Classes -And all Burstable and BestEffort pods are brought up under their -specific top level QoS cgroup. -Dynamic Kubelet Config (beta): This field should not be updated without a full node + cgroupsPerQOS enable QoS based CGroup hierarchy: top level CGroups for QoS classes +and all Burstable and BestEffort Pods are brought up under their specific top level +QoS CGroup. +Dynamic Kubelet Config (deprecated): This field should not be updated without a full node reboot. It is safest to keep this value the same as the local config. Default: true @@ -575,8 +624,9 @@ Default: true string - driver that the kubelet uses to manipulate cgroups on the host (cgroupfs or systemd) -Dynamic Kubelet Config (beta): This field should not be updated without a full node + cgroupDriver is the driver kubelet uses to manipulate CGroups on the host (cgroupfs +or systemd). +Dynamic Kubelet Config (deprecated): This field should not be updated without a full node reboot. It is safest to keep this value the same as the local config. Default: "cgroupfs" @@ -586,11 +636,24 @@ Default: "cgroupfs" string - CPUManagerPolicy is the name of the policy to use. + cpuManagerPolicy is the name of the policy to use. Requires the CPUManager feature gate to be enabled. +Dynamic Kubelet Config (deprecated): This field should not be updated without a full node +reboot. It is safest to keep this value the same as the local config. +Default: "None" + + + +cpuManagerPolicyOptions
+map[string]string + + + cpuManagerPolicyOptions is a set of key=value which allows to set extra options +to fine tune the behaviour of the cpu manager policies. +Requires both the "CPUManager" and "CPUManagerPolicyOptions" feature gates to be enabled. Dynamic Kubelet Config (beta): This field should not be updated without a full node reboot. It is safest to keep this value the same as the local config. -Default: "none" +Default: nil @@ -598,21 +661,44 @@ Default: "none" meta/v1.Duration - CPU Manager reconciliation period. + cpuManagerReconcilePeriod is the reconciliation period for the CPU Manager. Requires the CPUManager feature gate to be enabled. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that shortening the period may carry a performance impact. Default: "10s" +memoryManagerPolicy
+string + + + memoryManagerPolicy is the name of the policy to use by memory manager. +Requires the MemoryManager feature gate to be enabled. +Dynamic Kubelet Config (deprecated): This field should not be updated without a full node +reboot. It is safest to keep this value the same as the local config. +Default: "none" + + + topologyManagerPolicy
string - TopologyManagerPolicy is the name of the policy to use. + topologyManagerPolicy is the name of the topology manager policy to use. +Valid values include: + +- `restricted`: kubelet only allows pods with optimal NUMA node alignment for + requested resources; +- `best-effort`: kubelet will favor pods with NUMA alignment of CPU and device + resources; +- `none`: kublet has no knowledge of NUMA alignment of a pod's CPU and device resources. +- `single-numa-node`: kubelet only allows pods with a single NUMA alignment + of CPU and device resources. + Policies other than "none" require the TopologyManager feature gate to be enabled. -Dynamic Kubelet Config (beta): This field should not be updated without a full node +Dynamic Kubelet Config (deprecated): This field should not be updated without a full node reboot. It is safest to keep this value the same as the local config. Default: "none" @@ -622,8 +708,12 @@ Default: "none" string - TopologyManagerScope represents the scope of topology hint generation -that topology manager requests and hint providers generate. + topologyManagerScope represents the scope of topology hint generation +that topology manager requests and hint providers generate. Valid values include: + +- `container`: topology policy is applied on a per-container basis. +- `pod`: topology policy is applied on a per-pod basis. + "pod" scope requires the TopologyManager feature gate to be enabled. Default: "container" @@ -638,7 +728,7 @@ the minimum percentage of a resource reserved for exclusive use by the guaranteed QoS tier. Currently supported resources: "memory" Requires the QOSReserved feature gate to be enabled. -Dynamic Kubelet Config (beta): This field should not be updated without a full node +Dynamic Kubelet Config (deprecated): This field should not be updated without a full node reboot. It is safest to keep this value the same as the local config. Default: nil @@ -650,7 +740,8 @@ Default: nil runtimeRequestTimeout is the timeout for all runtime requests except long running requests - pull, logs, exec and attach. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may disrupt components that interact with the Kubelet server. Default: "2m" @@ -664,12 +755,15 @@ Default: "2m" bridge for hairpin packets. Setting this flag allows endpoints in a Service to loadbalance back to themselves if they should try to access their own Service. Values: - "promiscuous-bridge": make the container bridge promiscuous. - "hairpin-veth": set the hairpin flag on container veth interfaces. - "none": do nothing. -Generally, one must set --hairpin-mode=hairpin-veth to achieve hairpin NAT, + +- "promiscuous-bridge": make the container bridge promiscuous. +- "hairpin-veth": set the hairpin flag on container veth interfaces. +- "none": do nothing. + +Generally, one must set `--hairpin-mode=hairpin-veth to` achieve hairpin NAT, because promiscuous-bridge assumes the existence of a container bridge named cbr0. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may require a node reboot, depending on the network plugin. Default: "promiscuous-bridge" @@ -679,8 +773,10 @@ Default: "promiscuous-bridge" int32 - maxPods is the number of pods that can run on this Kubelet. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + maxPods is the maximum number of Pods that can run on this Kubelet. +The value must be a non-negative integer. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that changes may cause Pods to fail admission on Kubelet restart, and may change the value reported in Node.Status.Capacity[v1.ResourcePods], thus affecting future scheduling decisions. Increasing this value may also decrease performance, @@ -693,9 +789,9 @@ Default: 110 string - The CIDR to use for pod IP addresses, only used in standalone mode. -In cluster mode, this is obtained from the master. -Dynamic Kubelet Config (beta): This field should always be set to the empty default. + podCIDR is the CIDR to use for pod IP addresses, only used in standalone mode. +In cluster mode, this is obtained from the control plane. +Dynamic Kubelet Config (deprecated): This field should always be set to the empty default. It should only set for standalone Kubelets, which cannot use Dynamic Kubelet Config. Default: "" @@ -705,8 +801,9 @@ Default: "" int64 - PodPidsLimit is the maximum number of pids in any pod. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + podPidsLimit is the maximum number of PIDs in any pod. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that lowering it may prevent container processes from forking after the change. Default: -1 @@ -716,9 +813,10 @@ Default: -1 string - ResolverConfig is the resolver configuration file used as the basis + resolvConf is the resolver configuration file used as the basis for the container DNS resolution configuration. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that changes will only take effect on Pods created after the update. Draining the node is recommended before changing this field. Default: "/etc/resolv.conf" @@ -729,7 +827,7 @@ Default: "/etc/resolv.conf" bool - RunOnce causes the Kubelet to check the API server once for pods, + runOnce causes the Kubelet to check the API server once for pods, run those in addition to the pods specified by static pod files, and exit. Default: false @@ -741,7 +839,8 @@ Default: false cpuCFSQuota enables CPU CFS quota enforcement for containers that specify CPU limits. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that disabling it may reduce node stability. Default: true @@ -751,8 +850,11 @@ Default: true meta/v1.Duration - CPUCFSQuotaPeriod is the CPU CFS quota period value, cpu.cfs_period_us. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + cpuCFSQuotaPeriod is the CPU CFS quota period value, `cpu.cfs_period_us`. +The value must be between 1 us and 1 second, inclusive. +Requires the CustomCPUCFSQuotaPeriod feature gate to be enabled. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that limits set for containers will result in different cpu.cfs_quota settings. This will trigger container restarts on the node being reconfigured. Default: "100ms" @@ -763,9 +865,11 @@ Default: "100ms" int32 - nodeStatusMaxImages caps the number of images reported in Node.Status.Images. + nodeStatusMaxImages caps the number of images reported in Node.status.images. +The value must be greater than -2. Note: If -1 is specified, no cap will be applied. If 0 is specified, no image is returned. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that different values can be reported on node status. Default: 50 @@ -776,7 +880,9 @@ Default: 50 maxOpenFiles is Number of files that can be opened by Kubelet process. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +The value must be a non-negative number. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may impact the ability of the Kubelet to interact with the node's filesystem. Default: 1000000 @@ -787,7 +893,8 @@ Default: 1000000 contentType is contentType of requests sent to apiserver. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may impact the ability for the Kubelet to communicate with the API server. If the Kubelet loses contact with the API server due to a change to this field, the change cannot be reverted via dynamic Kubelet config. @@ -799,8 +906,9 @@ Default: "application/vnd.kubernetes.protobuf" int32 - kubeAPIQPS is the QPS to use while talking with kubernetes apiserver -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + kubeAPIQPS is the QPS to use while talking with kubernetes apiserver. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may impact scalability by changing the amount of traffic the Kubelet sends to the API server. Default: 5 @@ -811,8 +919,10 @@ Default: 5 int32 - kubeAPIBurst is the burst to allow while talking with kubernetes apiserver -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + kubeAPIBurst is the burst to allow while talking with kubernetes API server. +This field cannot be a negative number. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may impact scalability by changing the amount of traffic the Kubelet sends to the API server. Default: 10 @@ -827,7 +937,8 @@ Default: 10 at a time. We recommend ∗not∗ changing the default value on nodes that run docker daemon with version < 1.9 or an Aufs storage backend. Issue #10959 has more details. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may impact the performance of image pulls. Default: true @@ -837,9 +948,11 @@ Default: true map[string]string - Map of signal names to quantities that defines hard eviction thresholds. For example: {"memory.available": "300Mi"}. + evictionHard is a map of signal names to quantities that defines hard eviction +thresholds. For example: `{"memory.available": "300Mi"}`. To explicitly disable, pass a 0% or 100% threshold on an arbitrary resource. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may trigger or delay Pod evictions. Default: memory.available: "100Mi" @@ -853,9 +966,10 @@ Default: map[string]string - Map of signal names to quantities that defines soft eviction thresholds. -For example: {"memory.available": "300Mi"}. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + evictionSoft is a map of signal names to quantities that defines soft eviction thresholds. +For example: `{"memory.available": "300Mi"}`. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may trigger or delay Pod evictions, and may change the allocatable reported by the node. Default: nil @@ -866,9 +980,10 @@ Default: nil map[string]string - Map of signal names to quantities that defines grace periods for each soft eviction signal. -For example: {"memory.available": "30s"}. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + evictionSoftGracePeriod is a map of signal names to quantities that defines grace +periods for each soft eviction signal. For example: `{"memory.available": "30s"}`. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may trigger or delay Pod evictions. Default: nil @@ -878,8 +993,10 @@ Default: nil meta/v1.Duration - Duration for which the kubelet has to wait before transitioning out of an eviction pressure condition. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + evictionPressureTransitionPeriod is the duration for which the kubelet has to wait +before transitioning out of an eviction pressure condition. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that lowering it may decrease the stability of the node when the node is overcommitted. Default: "5m" @@ -889,13 +1006,14 @@ Default: "5m" int32 - Maximum allowed grace period (in seconds) to use when terminating pods in -response to a soft eviction threshold being met. This value effectively caps -the Pod's TerminationGracePeriodSeconds value during soft evictions. + evictionMaxPodGracePeriod is the maximum allowed grace period (in seconds) to use +when terminating pods in response to a soft eviction threshold being met. This value +effectively caps the Pod's terminationGracePeriodSeconds value during soft evictions. Note: Due to issue #64530, the behavior has a bug where this value currently just overrides the grace period during soft eviction, which can increase the grace period from what is set on the Pod. This bug will be fixed in a future release. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that lowering it decreases the amount of time Pods will have to gracefully clean up before being killed during a soft eviction. Default: 0 @@ -906,10 +1024,12 @@ Default: 0 map[string]string - Map of signal names to quantities that defines minimum reclaims, which describe the minimum -amount of a given resource the kubelet will reclaim when performing a pod eviction while -that resource is under pressure. For example: {"imagefs.available": "2Gi"} -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + evictionMinimumReclaim is a map of signal names to quantities that defines minimum reclaims, +which describe the minimum amount of a given resource the kubelet will reclaim when +performing a pod eviction while that resource is under pressure. +For example: `{"imagefs.available": "2Gi"}`. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may change how well eviction can manage resource pressure. Default: nil @@ -919,11 +1039,13 @@ Default: nil int32 - podsPerCore is the maximum number of pods per core. Cannot exceed MaxPods. -If 0, this field is ignored. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + podsPerCore is the maximum number of pods per core. Cannot exceed maxPods. +The value must be a non-negative integer. +If 0, there is no limit on the number of Pods. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that changes may cause Pods to fail admission on Kubelet restart, and may change -the value reported in Node.Status.Capacity[v1.ResourcePods], thus affecting +the value reported in `Node.status.capacity.pods`, thus affecting future scheduling decisions. Increasing this value may also decrease performance, as more Pods can be packed into a single node. Default: 0 @@ -936,8 +1058,9 @@ Default: 0 enableControllerAttachDetach enables the Attach/Detach controller to manage attachment/detachment of volumes scheduled to this node, and -disables kubelet from executing any attach/detach operations -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +disables kubelet from executing any attach/detach operations. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that changing which component is responsible for volume management on a live node may result in volumes refusing to detach if the node is not drained prior to the update, and if Pods are scheduled to the node before the @@ -954,7 +1077,8 @@ Default: true protectKernelDefaults, if true, causes the Kubelet to error if kernel flags are not as it expects. Otherwise the Kubelet will attempt to modify kernel flags to match its expectation. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that enabling it may cause the Kubelet to crash-loop if the Kernel is not configured as Kubelet expects. Default: false @@ -965,10 +1089,12 @@ Default: false bool - If true, Kubelet ensures a set of iptables rules are present on host. -These rules will serve as utility rules for various components, e.g. KubeProxy. -The rules will be created based on IPTablesMasqueradeBit and IPTablesDropBit. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + makeIPTablesUtilChains, if true, causes the Kubelet ensures a set of iptables rules +are present on host. +These rules will serve as utility rules for various components, e.g. kube-proxy. +The rules will be created based on iptablesMasqueradeBit and iptablesDropBit. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that disabling it will prevent the Kubelet from healing locally misconfigured iptables rules. Default: true @@ -978,11 +1104,12 @@ Default: true int32 - iptablesMasqueradeBit is the bit of the iptables fwmark space to mark for SNAT + iptablesMasqueradeBit is the bit of the iptables fwmark space to mark for SNAT. Values must be within the range [0, 31]. Must be different from other mark bits. Warning: Please match the value of the corresponding parameter in kube-proxy. -TODO: clean up IPTablesMasqueradeBit in kube-proxy -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +TODO: clean up IPTablesMasqueradeBit in kube-proxy. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it needs to be coordinated with other components, like kube-proxy, and the update will only be effective if MakeIPTablesUtilChains is enabled. Default: 14 @@ -995,7 +1122,8 @@ Default: 14 iptablesDropBit is the bit of the iptables fwmark space to mark for dropping packets. Values must be within the range [0, 31]. Must be different from other mark bits. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it needs to be coordinated with other components, like kube-proxy, and the update will only be effective if MakeIPTablesUtilChains is enabled. Default: 15 @@ -1006,10 +1134,11 @@ Default: 15 map[string]bool - featureGates is a map of feature names to bools that enable or disable alpha/experimental + featureGates is a map of feature names to bools that enable or disable experimental features. This field modifies piecemeal the built-in default values from "k8s.io/kubernetes/pkg/features/kube_features.go". -Dynamic Kubelet Config (beta): If dynamically updating this field, consider the +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider the documentation for the features you are enabling or disabling. While we encourage feature developers to make it possible to dynamically enable and disable features, some changes may require node reboots, and some @@ -1023,19 +1152,29 @@ Default: nil failSwapOn tells the Kubelet to fail to start if swap is enabled on the node. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that setting it to true will cause the Kubelet to crash-loop if swap is enabled. Default: true +memorySwap
+MemorySwapConfiguration + + + memorySwap configures swap memory available to container workloads. + + + containerLogMaxSize
string - A quantity defines the maximum size of the container log file before it is rotated. -For example: "5Mi" or "256Ki". -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + containerLogMaxSize is a quantity defining the maximum size of the container log +file before it is rotated. For example: "5Mi" or "256Ki". +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may trigger log rotation. Default: "10Mi" @@ -1045,8 +1184,10 @@ Default: "10Mi" int32 - Maximum number of container log files that can be present for a container. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + containerLogMaxFiles specifies the maximum number of container log files that can +be present for a container. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that lowering it may cause log files to be deleted. Default: 5 @@ -1056,8 +1197,13 @@ Default: 5 ResourceChangeDetectionStrategy - ConfigMapAndSecretChangeDetectionStrategy is a mode in which -config map and secret managers are running. + configMapAndSecretChangeDetectionStrategy is a mode in which ConfigMap and Secret +managers are running. Valid values include: + +- `Get`: kubelet fetches necessary objects directly from the API server; +- `Cache`: kubelet uses TTL cache for object fetched from the API server; +- `Watch`: kubelet uses watches to observe changes to objects that are in its interest. + Default: "Watch" @@ -1070,7 +1216,8 @@ Default: "Watch" pairs that describe resources reserved for non-kubernetes components. Currently only cpu and memory are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may not be possible to increase the reserved resources, because this requires resizing cgroups. Always look for a NodeAllocatableEnforced event after updating this field to ensure that the update was successful. @@ -1082,11 +1229,13 @@ Default: nil map[string]string - A set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=150G) pairs + kubeReserved is a set of ResourceName=ResourceQuantity (e.g. cpu=200m,memory=150G) pairs that describe resources reserved for kubernetes system components. Currently cpu, memory and local storage for root file system are supported. -See http://kubernetes.io/docs/user-guide/compute-resources for more detail. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +See https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ +for more details. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may not be possible to increase the reserved resources, because this requires resizing cgroups. Always look for a NodeAllocatableEnforced event after updating this field to ensure that the update was successful. @@ -1098,9 +1247,10 @@ Default: nil string - This ReservedSystemCPUs option specifies the cpu list reserved for the host level system threads and kubernetes related threads. -This provide a "static" CPU list rather than the "dynamic" list by system-reserved and kube-reserved. -This option overwrites CPUs provided by system-reserved and kube-reserved. + The reservedSystemCPUs option specifies the CPU list reserved for the host +level system threads and kubernetes related threads. This provide a "static" +CPU list rather than the "dynamic" list by systemReserved and kubeReserved. +This option does not support systemReservedCgroup or kubeReservedCgroup. @@ -1108,11 +1258,13 @@ This option overwrites CPUs provided by system-reserved and kube-reserved. string - The previous version for which you want to show hidden metrics. + showHiddenMetricsForVersion is the previous version for which you want to show +hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. -The format is ., e.g.: '1.16'. -The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, -rather than being surprised when they are permanently removed in the release after that. +The format is `.`, e.g.: `1.16`. +The purpose of this format is make sure you have the opportunity to notice +if the next release hides additional metrics, rather than being surprised +when they are permanently removed in the release after that. Default: "" @@ -1121,9 +1273,11 @@ Default: "" string - This flag helps kubelet identify absolute name of top level cgroup used to enforce `SystemReserved` compute resource reservation for OS system daemons. -Refer to [Node Allocatable](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md) doc for more information. -Dynamic Kubelet Config (beta): This field should not be updated without a full node + systemReservedCgroup helps the kubelet identify absolute name of top level CGroup used +to enforce `systemReserved` compute resource reservation for OS system daemons. +Refer to [Node Allocatable](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md) +doc for more information. +Dynamic Kubelet Config (deprecated): This field should not be updated without a full node reboot. It is safest to keep this value the same as the local config. Default: "" @@ -1133,9 +1287,11 @@ Default: "" string - This flag helps kubelet identify absolute name of top level cgroup used to enforce `KubeReserved` compute resource reservation for Kubernetes node system daemons. -Refer to [Node Allocatable](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md) doc for more information. -Dynamic Kubelet Config (beta): This field should not be updated without a full node + kubeReservedCgroup helps the kubelet identify absolute name of top level CGroup used +to enforce `KubeReserved` compute resource reservation for Kubernetes node system daemons. +Refer to [Node Allocatable](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md) +doc for more information. +Dynamic Kubelet Config (deprecated): This field should not be updated without a full node reboot. It is safest to keep this value the same as the local config. Default: "" @@ -1146,10 +1302,16 @@ Default: "" This flag specifies the various Node Allocatable enforcements that Kubelet needs to perform. -This flag accepts a list of options. Acceptable options are `none`, `pods`, `system-reserved` & `kube-reserved`. +This flag accepts a list of options. Acceptable options are `none`, `pods`, +`system-reserved` and `kube-reserved`. If `none` is specified, no other options may be specified. -Refer to [Node Allocatable](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md) doc for more information. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that +When `system-reserved` is in the list, systemReservedCgroup must be specified. +When `kube-reserved` is in the list, kubeReservedCgroup must be specified. +This field is supported only when `cgroupsPerQOS` is set to true. +Refer to [Node Allocatable](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md) +for more information. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that removing enforcements may reduce the stability of the node. Alternatively, adding enforcements may reduce the stability of components which were using more than the reserved amount of resources; for example, enforcing kube-reserved may cause @@ -1163,9 +1325,9 @@ Default: ["pods"] []string - A comma separated whitelist of unsafe sysctls or sysctl patterns (ending in ∗). -Unsafe sysctl groups are kernel.shm∗, kernel.msg∗, kernel.sem, fs.mqueue.∗, and net.∗. -These sysctls are namespaced but not allowed by default. For example: "kernel.msg∗,net.ipv4.route.min_pmtu" + A comma separated whitelist of unsafe sysctls or sysctl patterns (ending in `∗`). +Unsafe sysctl groups are `kernel.shm∗`, `kernel.msg∗`, `kernel.sem`, `fs.mqueue.∗`, +and `net.∗`. For example: "`kernel.msg∗,net.ipv4.route.min_pmtu`" Default: [] @@ -1176,7 +1338,8 @@ Default: [] volumePluginDir is the full path of the directory in which to search for additional third party volume plugins. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that changing +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that changing the volumePluginDir may disrupt workloads relying on third party volume plugins. Default: "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/" @@ -1186,9 +1349,10 @@ Default: "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/" string - providerID, if set, sets the unique id of the instance that an external provider (i.e. cloudprovider) -can use to identify a specific node. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + providerID, if set, sets the unique ID of the instance that an external +provider (i.e. cloudprovider) can use to identify a specific node. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may impact the ability of the Kubelet to interact with cloud providers. Default: "" @@ -1198,9 +1362,11 @@ Default: "" bool - kernelMemcgNotification, if set, the kubelet will integrate with the kernel memcg notification -to determine if memory eviction thresholds are crossed rather than polling. -Dynamic Kubelet Config (beta): If dynamically updating this field, consider that + kernelMemcgNotification, if set, instructs the the kubelet to integrate with the +kernel memcg notification for determining if memory eviction thresholds are +exceeded rather than polling. +If DynamicKubeletConfig (deprecated; default off) is on, when +dynamically updating this field, consider that it may impact the way Kubelet interacts with the kernel. Default: false @@ -1210,9 +1376,10 @@ Default: false LoggingConfiguration - Logging specifies the options of logging. -Refer [Logs Options](https://github.com/kubernetes/component-base/blob/master/logs/options.go) for more information. -Defaults: + logging specifies the options of logging. +Refer to [Logs Options](https://github.com/kubernetes/component-base/blob/master/logs/options.go) +for more information. +Default: Format: text @@ -1230,8 +1397,9 @@ Default: true meta/v1.Duration - ShutdownGracePeriod specifies the total duration that the node should delay the shutdown and total grace period for pod termination during a node shutdown. -Default: "30s" + shutdownGracePeriod specifies the total duration that the node should delay the +shutdown and total grace period for pod termination during a node shutdown. +Default: "0s" @@ -1239,9 +1407,81 @@ Default: "30s" meta/v1.Duration - ShutdownGracePeriodCriticalPods specifies the duration used to terminate critical pods during a node shutdown. This should be less than ShutdownGracePeriod. -For example, if ShutdownGracePeriod=30s, and ShutdownGracePeriodCriticalPods=10s, during a node shutdown the first 20 seconds would be reserved for gracefully terminating normal pods, and the last 10 seconds would be reserved for terminating critical pods. -Default: "10s" + shutdownGracePeriodCriticalPods specifies the duration used to terminate critical +pods during a node shutdown. This should be less than shutdownGracePeriod. +For example, if shutdownGracePeriod=30s, and shutdownGracePeriodCriticalPods=10s, +during a node shutdown the first 20 seconds would be reserved for gracefully +terminating normal pods, and the last 10 seconds would be reserved for terminating +critical pods. +Default: "0s" + + + +reservedMemory
+[]MemoryReservation + + + reservedMemory specifies a comma-separated list of memory reservations for NUMA nodes. +The parameter makes sense only in the context of the memory manager feature. +The memory manager will not allocate reserved memory for container workloads. +For example, if you have a NUMA0 with 10Gi of memory and the reservedMemory was +specified to reserve 1Gi of memory at NUMA0, the memory manager will assume that +only 9Gi is available for allocation. +You can specify a different amount of NUMA node and memory types. +You can omit this parameter at all, but you should be aware that the amount of +reserved memory from all NUMA nodes should be equal to the amount of memory specified +by the [node allocatable](https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). +If at least one node allocatable parameter has a non-zero value, you will need +to specify at least one NUMA node. +Also, avoid specifying: + +1. Duplicates, the same NUMA node, and memory type, but with a different value. +2. zero limits for any memory type. +3. NUMAs nodes IDs that do not exist under the machine. +4. memory types except for memory and hugepages- + +Default: nil + + + +enableProfilingHandler
+bool + + + enableProfilingHandler enables profiling via web interface host:port/debug/pprof/ +Default: true + + + +enableDebugFlagsHandler
+bool + + + enableDebugFlagsHandler enables flags endpoint via web interface host:port/debug/flags/v +Default: true + + + +seccompDefault
+bool + + + SeccompDefault enables the use of `RuntimeDefault` as the default seccomp profile for all workloads. +This requires the corresponding SeccompDefault feature gate to be enabled as well. +Default: false + + + +memoryThrottlingFactor
+float64 + + + MemoryThrottlingFactor specifies the factor multiplied by the memory limit or node allocatable memory +when setting the cgroupv2 memory.high value to enforce MemoryQoS. +Decreasing this factor will set lower high limit for container cgroups and put heavier reclaim pressure +while increasing will put less reclaim pressure. +See http://kep.k8s.io/2570 for more details. +Default: 0.8 @@ -1271,10 +1511,10 @@ It exists in the kubeletconfig API group because it is classified as a versioned source
-core/v1.NodeConfigSource +core/v1.NodeConfigSource - Source is the source that we are serializing + source is the source that we are serializing. @@ -1319,8 +1559,10 @@ hairpin packets. enabled allows anonymous requests to the kubelet server. -Requests that are not rejected by another authentication method are treated as anonymous requests. -Anonymous requests have a username of system:anonymous, and a group name of system:unauthenticated. +Requests that are not rejected by another authentication method are treated as +anonymous requests. +Anonymous requests have a username of `system:anonymous`, and a group name of +`system:unauthenticated`. @@ -1351,7 +1593,7 @@ Anonymous requests have a username of system:anonymous, and a group name of syst KubeletX509Authentication - x509 contains settings related to x509 client certificate authentication + x509 contains settings related to x509 client certificate authentication. @@ -1359,7 +1601,7 @@ Anonymous requests have a username of system:anonymous, and a group name of syst KubeletWebhookAuthentication - webhook contains settings related to webhook bearer token authentication + webhook contains settings related to webhook bearer token authentication. @@ -1367,7 +1609,7 @@ Anonymous requests have a username of system:anonymous, and a group name of syst KubeletAnonymousAuthentication - anonymous contains settings related to anonymous authentication + anonymous contains settings related to anonymous authentication. @@ -1399,7 +1641,7 @@ Anonymous requests have a username of system:anonymous, and a group name of syst mode is the authorization mode to apply to requests to the kubelet server. -Valid values are AlwaysAllow and Webhook. +Valid values are `AlwaysAllow` and `Webhook`. Webhook mode uses the SubjectAccessReview API to determine authorization. @@ -1455,7 +1697,8 @@ Webhook mode uses the SubjectAccessReview API to determine authorization. bool - enabled allows bearer token authentication backed by the tokenreviews.authentication.k8s.io API + enabled allows bearer token authentication backed by the +tokenreviews.authentication.k8s.io API. @@ -1494,7 +1737,8 @@ Webhook mode uses the SubjectAccessReview API to determine authorization. meta/v1.Duration - cacheAuthorizedTTL is the duration to cache 'authorized' responses from the webhook authorizer. + cacheAuthorizedTTL is the duration to cache 'authorized' responses from the +webhook authorizer. @@ -1502,7 +1746,8 @@ Webhook mode uses the SubjectAccessReview API to determine authorization. meta/v1.Duration - cacheUnauthorizedTTL is the duration to cache 'unauthorized' responses from the webhook authorizer. + cacheUnauthorizedTTL is the duration to cache 'unauthorized' responses from +the webhook authorizer. @@ -1533,8 +1778,9 @@ Webhook mode uses the SubjectAccessReview API to determine authorization. string - clientCAFile is the path to a PEM-encoded certificate bundle. If set, any request presenting a client certificate -signed by one of the authorities in the bundle is authenticated with a username corresponding to the CommonName, + clientCAFile is the path to a PEM-encoded certificate bundle. If set, any request +presenting a client certificate signed by one of the authorities in the bundle +is authenticated with a username corresponding to the CommonName, and groups corresponding to the Organization in the client certificate. @@ -1544,6 +1790,80 @@ and groups corresponding to the Organization in the client certificate. +## `MemoryReservation` {#kubelet-config-k8s-io-v1beta1-MemoryReservation} + + + + +**Appears in:** + +- [KubeletConfiguration](#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) + + +MemoryReservation specifies the memory reservation of different types for each NUMA node + + + + + + + + + + + + + + + + + + +
FieldDescription
numaNode [Required]
+int32 +		 + No description provided. +
limits [Required]
+core/v1.ResourceList +		 + No description provided. +
+ + + +## `MemorySwapConfiguration` {#kubelet-config-k8s-io-v1beta1-MemorySwapConfiguration} + + + + +**Appears in:** + +- [KubeletConfiguration](#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) + + + + + + + + + + + + + + + + +
FieldDescription
swapBehavior
+string +		 + swapBehavior configures swap memory available to container workloads. May be one of +"", "LimitedSwap": workload combined memory and swap usage cannot exceed pod memory limit +"UnlimitedSwap": workloads can use unlimited swap, up to the allocatable limit.
+ + + ## `ResourceChangeDetectionStrategy` {#kubelet-config-k8s-io-v1beta1-ResourceChangeDetectionStrategy} (Alias of `string`) diff --git a/content/en/docs/reference/glossary/affinity.md b/content/en/docs/reference/glossary/affinity.md new file mode 100644 index 0000000000..e5cfc92ea2 --- /dev/null +++ b/content/en/docs/reference/glossary/affinity.md @@ -0,0 +1,22 @@ +--- +title: Affinity +id: affinity +date: 2019-01-11 +full_link: /docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity +short_description: > + Rules used by the scheduler to determine where to place pods +aka: +tags: +- fundamental +--- + +In Kubernetes, _affinity_ is a set of rules that give hints to the scheduler about where to place pods. + + +There are two kinds of affinity: +* [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity) +* [pod-to-pod affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) + +The rules are defined using the Kubernetes {{< glossary_tooltip term_id="label" text="labels">}}, +and {{< glossary_tooltip term_id="selector" text="selectors">}} specified in {{< glossary_tooltip term_id="pod" text="pods" >}}, +and they can be either required or preferred, depending on how strictly you want the scheduler to enforce them. diff --git a/content/en/docs/reference/glossary/annotation.md b/content/en/docs/reference/glossary/annotation.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/api-eviction.md b/content/en/docs/reference/glossary/api-eviction.md new file mode 100644 index 0000000000..69fc9d9b0c --- /dev/null +++ b/content/en/docs/reference/glossary/api-eviction.md @@ -0,0 +1,22 @@ +--- +title: API-initiated eviction +id: api-eviction +date: 2021-04-27 +full_link: /docs/concepts/scheduling-eviction/api-eviction/ +short_description: > + API-initiated eviction is the process by which you use the Eviction API to create an + Eviction object that triggers graceful pod termination. +aka: +tags: +- operation +--- +API-initiated eviction is the process by which you use the [Eviction API](/docs/reference/generated/kubernetes-api/{{}}/#create-eviction-pod-v1-core) +to create an `Eviction` object that triggers graceful pod termination. + + + +You can request eviction either by directly calling the Eviction API +using a client of the kube-apiserver, like the `kubectl drain` command. +When an `Eviction` object is created, the API server terminates the Pod. + +API-initiated eviction is not the same as [node-pressure eviction](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction). diff --git a/content/en/docs/reference/glossary/application-architect.md b/content/en/docs/reference/glossary/application-architect.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/application-developer.md b/content/en/docs/reference/glossary/application-developer.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/approver.md b/content/en/docs/reference/glossary/approver.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/certificate.md b/content/en/docs/reference/glossary/certificate.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/cla.md b/content/en/docs/reference/glossary/cla.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/cloud-controller-manager.md b/content/en/docs/reference/glossary/cloud-controller-manager.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/cloud-provider.md b/content/en/docs/reference/glossary/cloud-provider.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/cluster-architect.md b/content/en/docs/reference/glossary/cluster-architect.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/cluster-operator.md b/content/en/docs/reference/glossary/cluster-operator.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/cluster.md b/content/en/docs/reference/glossary/cluster.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/cncf.md b/content/en/docs/reference/glossary/cncf.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/code-contributor.md b/content/en/docs/reference/glossary/code-contributor.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/configmap.md b/content/en/docs/reference/glossary/configmap.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/container-env-variables.md b/content/en/docs/reference/glossary/container-env-variables.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/container.md b/content/en/docs/reference/glossary/container.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/contributor.md b/content/en/docs/reference/glossary/contributor.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/controller.md b/content/en/docs/reference/glossary/controller.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/cronjob.md b/content/en/docs/reference/glossary/cronjob.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/customresourcedefinition.md b/content/en/docs/reference/glossary/customresourcedefinition.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/daemonset.md b/content/en/docs/reference/glossary/daemonset.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/deployment.md b/content/en/docs/reference/glossary/deployment.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/developer.md b/content/en/docs/reference/glossary/developer.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/docker.md b/content/en/docs/reference/glossary/docker.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/downstream.md b/content/en/docs/reference/glossary/downstream.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/dynamic-volume-provisioning.md b/content/en/docs/reference/glossary/dynamic-volume-provisioning.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/etcd.md b/content/en/docs/reference/glossary/etcd.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/eviction.md b/content/en/docs/reference/glossary/eviction.md new file mode 100644 index 0000000000..4437e43354 --- /dev/null +++ b/content/en/docs/reference/glossary/eviction.md @@ -0,0 +1,18 @@ +--- +title: Eviction +id: eviction +date: 2021-05-08 +full_link: /docs/concepts/scheduling-eviction/ +short_description: > + Process of terminating one or more Pods on Nodes +aka: +tags: +- operation +--- + +Eviction is the process of terminating one or more Pods on Nodes. + + +There are two kinds of eviction: +* [Node-pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) +* [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/) diff --git a/content/en/docs/reference/glossary/finalizer.md b/content/en/docs/reference/glossary/finalizer.md new file mode 100644 index 0000000000..c44386fbf3 --- /dev/null +++ b/content/en/docs/reference/glossary/finalizer.md @@ -0,0 +1,31 @@ +--- +title: Finalizer +id: finalizer +date: 2021-07-07 +full_link: /docs/concepts/overview/working-with-objects/finalizers/ +short_description: > + A namespaced key that tells Kubernetes to wait until specific conditions are met + before it fully deletes an object marked for deletion. +aka: +tags: +- fundamental +- operation +--- +Finalizers are namespaced keys that tell Kubernetes to wait until specific +conditions are met before it fully deletes resources marked for deletion. +Finalizers alert {{}} +to clean up resources the deleted object owned. + + + +When you tell Kubernetes to delete an object that has finalizers specified for +it, the Kubernetes API marks the object for deletion, putting it into a +read-only state. The target object remains in a terminating state while the +control plane, or other components, take the actions defined by the finalizers. +After these actions are complete, the controller removes the relevant finalizers +from the target object. When the `metadata.finalizers` field is empty, +Kubernetes considers the deletion complete. + +You can use finalizers to control {{}} +of resources. For example, you can define a finalizer to clean up related resources or +infrastructure before the controller deletes the target resource. \ No newline at end of file diff --git a/content/en/docs/reference/glossary/garbage-collection.md b/content/en/docs/reference/glossary/garbage-collection.md new file mode 100644 index 0000000000..ec2fe19af7 --- /dev/null +++ b/content/en/docs/reference/glossary/garbage-collection.md @@ -0,0 +1,24 @@ +--- +title: Garbage Collection +id: garbage-collection +date: 2021-07-07 +full_link: /docs/concepts/workloads/controllers/garbage-collection/ +short_description: > + A collective term for the various mechanisms Kubernetes uses to clean up cluster + resources. + +aka: +tags: +- fundamental +- operation +--- + Garbage collection is a collective term for the various mechanisms Kubernetes uses to clean up + cluster resources. + + + +Kubernetes uses garbage collection to clean up resources like [unused containers and images](/docs/concepts/workloads/controllers/garbage-collection/#containers-images), +[failed Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection), +[objects owned by the targeted resource](/docs/concepts/overview/working-with-objects/owners-dependents/), +[completed Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/), and resources +that have expired or failed. \ No newline at end of file diff --git a/content/en/docs/reference/glossary/helm-chart.md b/content/en/docs/reference/glossary/helm-chart.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/horizontal-pod-autoscaler.md b/content/en/docs/reference/glossary/horizontal-pod-autoscaler.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/image.md b/content/en/docs/reference/glossary/image.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/index.md b/content/en/docs/reference/glossary/index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/ingress.md b/content/en/docs/reference/glossary/ingress.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/init-container.md b/content/en/docs/reference/glossary/init-container.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/istio.md b/content/en/docs/reference/glossary/istio.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/job.md b/content/en/docs/reference/glossary/job.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/kops.md b/content/en/docs/reference/glossary/kops.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/kube-apiserver.md b/content/en/docs/reference/glossary/kube-apiserver.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/kube-controller-manager.md b/content/en/docs/reference/glossary/kube-controller-manager.md old mode 100755 new mode 100644 index fa4205292c..78c22b32c7 --- a/content/en/docs/reference/glossary/kube-controller-manager.md +++ b/content/en/docs/reference/glossary/kube-controller-manager.md @@ -11,7 +11,7 @@ tags: - architecture - fundamental --- - Control Plane component that runs {{< glossary_tooltip text="controller" term_id="controller" >}} processes. + Control plane component that runs {{< glossary_tooltip text="controller" term_id="controller" >}} processes. diff --git a/content/en/docs/reference/glossary/kube-proxy.md b/content/en/docs/reference/glossary/kube-proxy.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/kube-scheduler.md b/content/en/docs/reference/glossary/kube-scheduler.md old mode 100755 new mode 100644 index a1a91a1527..96fc11a71d --- a/content/en/docs/reference/glossary/kube-scheduler.md +++ b/content/en/docs/reference/glossary/kube-scheduler.md @@ -2,7 +2,7 @@ title: kube-scheduler id: kube-scheduler date: 2018-04-12 -full_link: /docs/reference/generated/kube-scheduler/ +full_link: /docs/reference/command-line-tools-reference/kube-scheduler/ short_description: > Control plane component that watches for newly created pods with no assigned node, and selects a node for them to run on. diff --git a/content/en/docs/reference/glossary/kubeadm.md b/content/en/docs/reference/glossary/kubeadm.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/kubectl.md b/content/en/docs/reference/glossary/kubectl.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/kubelet.md b/content/en/docs/reference/glossary/kubelet.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/kubernetes-api.md b/content/en/docs/reference/glossary/kubernetes-api.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/label.md b/content/en/docs/reference/glossary/label.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/limitrange.md b/content/en/docs/reference/glossary/limitrange.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/managed-service.md b/content/en/docs/reference/glossary/managed-service.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/member.md b/content/en/docs/reference/glossary/member.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/minikube.md b/content/en/docs/reference/glossary/minikube.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/mirror-pod.md b/content/en/docs/reference/glossary/mirror-pod.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/name.md b/content/en/docs/reference/glossary/name.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/namespace.md b/content/en/docs/reference/glossary/namespace.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/network-policy.md b/content/en/docs/reference/glossary/network-policy.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/node-pressure-eviction.md b/content/en/docs/reference/glossary/node-pressure-eviction.md new file mode 100644 index 0000000000..05d641aeda --- /dev/null +++ b/content/en/docs/reference/glossary/node-pressure-eviction.md @@ -0,0 +1,24 @@ +--- +title: Node-pressure eviction +id: node-pressure-eviction +date: 2021-05-13 +full_link: /docs/concepts/scheduling-eviction/node-pressure-eviction/ +short_description: > + Node-pressure eviction is the process by which the kubelet proactively fails + pods to reclaim resources on nodes. +aka: +- kubelet eviction +tags: +- operation +--- +Node-pressure eviction is the process by which the {{}} proactively terminates +pods to reclaim resources on nodes. + + + +The kubelet monitors resources like CPU, memory, disk space, and filesystem +inodes on your cluster's nodes. When one or more of these resources reach +specific consumption levels, the kubelet can proactively fail one or more pods +on the node to reclaim resources and prevent starvation. + +Node-pressure eviction is not the same as [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/). diff --git a/content/en/docs/reference/glossary/node.md b/content/en/docs/reference/glossary/node.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/object.md b/content/en/docs/reference/glossary/object.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/operator-pattern.md b/content/en/docs/reference/glossary/operator-pattern.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/persistent-volume-claim.md b/content/en/docs/reference/glossary/persistent-volume-claim.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/persistent-volume.md b/content/en/docs/reference/glossary/persistent-volume.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/platform-developer.md b/content/en/docs/reference/glossary/platform-developer.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/pod-disruption.md b/content/en/docs/reference/glossary/pod-disruption.md new file mode 100644 index 0000000000..1efd69dd4c --- /dev/null +++ b/content/en/docs/reference/glossary/pod-disruption.md @@ -0,0 +1,19 @@ +--- +id: pod-disruption +title: Pod Disruption +full_link: /docs/concepts/workloads/pods/disruptions/ +date: 2021-05-12 +short_description: > + The process by which Pods on Nodes are terminated either voluntarily or involuntarily. + +aka: +related: + - pod + - container +tags: + - operation +--- + +[Pod disruption](/docs/concepts/workloads/pods/disruptions/) is the process by which Pods on Nodes are terminated either voluntarily or involuntarily. + +Voluntary disruptions are started intentionally by application owners or cluster administrators. Involuntary disruptions are unintentional and can be triggered by unavoidable issues like Nodes running out of resources, or by accidental deletions. diff --git a/content/en/docs/reference/glossary/pod-priority.md b/content/en/docs/reference/glossary/pod-priority.md index 994f8bc4d8..f0e0a0f1c6 100644 --- a/content/en/docs/reference/glossary/pod-priority.md +++ b/content/en/docs/reference/glossary/pod-priority.md @@ -2,7 +2,7 @@ title: Pod Priority id: pod-priority date: 2019-01-31 -full_link: /docs/concepts/configuration/pod-priority-preemption/#pod-priority +full_link: /docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority short_description: > Pod Priority indicates the importance of a Pod relative to other Pods. @@ -14,4 +14,4 @@ tags: -[Pod Priority](/docs/concepts/configuration/pod-priority-preemption/#pod-priority) gives the ability to set scheduling priority of a Pod to be higher and lower than other Pods — an important feature for production clusters workload. +[Pod Priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority) gives the ability to set scheduling priority of a Pod to be higher and lower than other Pods — an important feature for production clusters workload. diff --git a/content/en/docs/reference/glossary/pod-security-policy.md b/content/en/docs/reference/glossary/pod-security-policy.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/pod.md b/content/en/docs/reference/glossary/pod.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/preemption.md b/content/en/docs/reference/glossary/preemption.md index f27e36c66f..1a1f0e929a 100644 --- a/content/en/docs/reference/glossary/preemption.md +++ b/content/en/docs/reference/glossary/preemption.md @@ -2,7 +2,7 @@ title: Preemption id: preemption date: 2019-01-31 -full_link: /docs/concepts/configuration/pod-priority-preemption/#preemption +full_link: /docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption short_description: > Preemption logic in Kubernetes helps a pending Pod to find a suitable Node by evicting low priority Pods existing on that Node. @@ -14,4 +14,4 @@ tags: -If a Pod cannot be scheduled, the scheduler tries to [preempt](/docs/concepts/configuration/pod-priority-preemption/#preemption) lower priority Pods to make scheduling of the pending Pod possible. +If a Pod cannot be scheduled, the scheduler tries to [preempt](/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption) lower priority Pods to make scheduling of the pending Pod possible. diff --git a/content/en/docs/reference/glossary/proxy.md b/content/en/docs/reference/glossary/proxy.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/qos-class.md b/content/en/docs/reference/glossary/qos-class.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/rbac.md b/content/en/docs/reference/glossary/rbac.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/replica-set.md b/content/en/docs/reference/glossary/replica-set.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/replication-controller.md b/content/en/docs/reference/glossary/replication-controller.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/resource-quota.md b/content/en/docs/reference/glossary/resource-quota.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/reviewer.md b/content/en/docs/reference/glossary/reviewer.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/secret.md b/content/en/docs/reference/glossary/secret.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/security-context.md b/content/en/docs/reference/glossary/security-context.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/selector.md b/content/en/docs/reference/glossary/selector.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/service-account.md b/content/en/docs/reference/glossary/service-account.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/service-broker.md b/content/en/docs/reference/glossary/service-broker.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/service-catalog.md b/content/en/docs/reference/glossary/service-catalog.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/service.md b/content/en/docs/reference/glossary/service.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/sig.md b/content/en/docs/reference/glossary/sig.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/statefulset.md b/content/en/docs/reference/glossary/statefulset.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/static-pod.md b/content/en/docs/reference/glossary/static-pod.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/storage-class.md b/content/en/docs/reference/glossary/storage-class.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/sysctl.md b/content/en/docs/reference/glossary/sysctl.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/uid.md b/content/en/docs/reference/glossary/uid.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/upstream.md b/content/en/docs/reference/glossary/upstream.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/userns.md b/content/en/docs/reference/glossary/userns.md new file mode 100644 index 0000000000..acfe754993 --- /dev/null +++ b/content/en/docs/reference/glossary/userns.md @@ -0,0 +1,28 @@ +--- +title: user namespace +id: userns +date: 2021-07-13 +full_link: https://man7.org/linux/man-pages/man7/user_namespaces.7.html +short_description: > + A Linux kernel feature to emulate superuser privilege for unprivileged users. + +aka: +tags: +- security +--- + +A kernel feature to emulate root. Used for "rootless containers". + + + +User namespaces are a Linux kernel feature that allows a non-root user to +emulate superuser ("root") privileges, +for example in order to run containers without being a superuser outside the container. + +User namespace is effective for mitigating damage of potential container break-out attacks. + +In the context of user namespaces, the namespace is a Linux kernel feature, and not a +{{< glossary_tooltip text="namespace" term_id="namespace" >}} in the Kubernetes sense +of the term. + + diff --git a/content/en/docs/reference/glossary/volume-plugin.md b/content/en/docs/reference/glossary/volume-plugin.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/volume.md b/content/en/docs/reference/glossary/volume.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/glossary/wg.md b/content/en/docs/reference/glossary/wg.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/issues-security/security.md b/content/en/docs/reference/issues-security/security.md index 43b01a4172..7fe91a037a 100644 --- a/content/en/docs/reference/issues-security/security.md +++ b/content/en/docs/reference/issues-security/security.md @@ -29,7 +29,7 @@ To make a report, submit your vulnerability to the [Kubernetes bug bounty progra You can also email the private [security@kubernetes.io](mailto:security@kubernetes.io) list with the security details and the details expected for [all Kubernetes bug reports](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md). -You may encrypt your email to this list using the GPG keys of the [Product Security Committee members](https://git.k8s.io/security/README.md#product-security-committee-psc). Encryption using GPG is NOT required to make a disclosure. +You may encrypt your email to this list using the GPG keys of the [Security Response Committee members](https://git.k8s.io/security/README.md#product-security-committee-psc). Encryption using GPG is NOT required to make a disclosure. ### When Should I Report a Vulnerability? @@ -47,13 +47,13 @@ You may encrypt your email to this list using the GPG keys of the [Product Secur ## Security Vulnerability Response -Each report is acknowledged and analyzed by Product Security Committee members within 3 working days. This will set off the [Security Release Process](https://git.k8s.io/security/security-release-process.md#disclosures). +Each report is acknowledged and analyzed by Security Response Committee members within 3 working days. This will set off the [Security Release Process](https://git.k8s.io/security/security-release-process.md#disclosures). -Any vulnerability information shared with Product Security Committee stays within Kubernetes project and will not be disseminated to other projects unless it is necessary to get the issue fixed. +Any vulnerability information shared with Security Response Committee stays within Kubernetes project and will not be disseminated to other projects unless it is necessary to get the issue fixed. As the security issue moves from triage, to identified fix, to release planning we will keep the reporter updated. ## Public Disclosure Timing -A public disclosure date is negotiated by the Kubernetes Product Security Committee and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. For a vulnerability with a straightforward mitigation, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes Product Security Committee holds the final say when setting a disclosure date. +A public disclosure date is negotiated by the Kubernetes Security Response Committee and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. For a vulnerability with a straightforward mitigation, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes Security Response Committee holds the final say when setting a disclosure date. diff --git a/content/en/docs/reference/kubectl/_index.md b/content/en/docs/reference/kubectl/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index f5a971d3bd..c32ba4f809 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -216,6 +216,10 @@ kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' # Produce a period-delimited tree of all keys returned for pods, etc kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' + +# Produce ENV for all pods, assuming you have a default container for the pods, default namespace and the `env` command is supported. +# Helpful when running any supported command across all pods, not just `env` +for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod env; done ``` ## Updating resources diff --git a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md index ac7b7a49f9..9c148702b5 100644 --- a/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/en/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -265,7 +265,7 @@ nginx-app 1/1 1 1 2m ``` ```shell -kubectl get po -l run=nginx-app +kubectl get po -l app=nginx-app ``` ``` NAME READY STATUS RESTARTS AGE @@ -279,7 +279,7 @@ deployment "nginx-app" deleted ``` ```shell -kubectl get po -l run=nginx-app +kubectl get po -l app=nginx-app # Return nothing ``` diff --git a/content/en/docs/reference/kubectl/kubectl.md b/content/en/docs/reference/kubectl/kubectl.md index 2cb2db7f9f..1b855168e5 100644 --- a/content/en/docs/reference/kubectl/kubectl.md +++ b/content/en/docs/reference/kubectl/kubectl.md @@ -328,7 +328,31 @@ kubectl [flags] +## {{% heading "envvars" %}} + ++++ + + + + + + + + + + + + + + + + + +
KUBECONFIG
Path to the kubectl configuration ("kubeconfig") file. Default: "$HOME/.kube/config"
KUBECTL_COMMAND_HEADERS
When set to false, turns off extra HTTP headers detailing invoked kubectl command (Kubernetes version v1.22 or later)
## {{% heading "seealso" %}} diff --git a/content/en/docs/reference/kubectl/overview.md b/content/en/docs/reference/kubectl/overview.md index f8ec7e5603..72a60f96a2 100644 --- a/content/en/docs/reference/kubectl/overview.md +++ b/content/en/docs/reference/kubectl/overview.md @@ -71,6 +71,32 @@ Flags that you specify from the command line override default values and any cor If you need help, run `kubectl help` from the terminal window. +## In-cluster authentication and namespace overrides + +By default `kubectl` will first determine if it is running within a pod, and thus in a cluster. It starts by checking for the `KUBERNETES_SERVICE_HOST` and `KUBERNETES_SERVICE_PORT` environment variables and the existence of a service account token file at `/var/run/secrets/kubernetes.io/serviceaccount/token`. If all three are found in-cluster authentication is assumed. + +To maintain backwards compatibility, if the `POD_NAMESPACE` environment variable is set during in-cluster authentication it will override the default namespace from the service account token. Any manifests or tools relying on namespace defaulting will be affected by this. + +**`POD_NAMESPACE` environment variable** + +If the `POD_NAMESPACE` environment variable is set, cli operations on namespaced resources will default to the variable value. For example, if the variable is set to `seattle`, `kubectl get pods` would return pods in the `seattle` namespace. This is because pods are a namespaced resource, and no namespace was provided in the command. Review the output of `kubectl api-resources` to determine if a resource is namespaced. + +Explicit use of `--namespace ` overrides this behavior. + +**How kubectl handles ServiceAccount tokens** + +If: +* there is Kubernetes service account token file mounted at + `/var/run/secrets/kubernetes.io/serviceaccount/token`, and +* the `KUBERNETES_SERVICE_HOST` environment variable is set, and +* the `KUBERNETES_SERVICE_PORT` environment variable is set, and +* you don't explicitly specify a namespace on the kubectl command line +then kubectl assumes it is running in your cluster. The kubectl tool looks up the +namespace of that ServiceAccount (this is the same as the namespace of the Pod) +and acts against that namespace. This is different from what happens outside of a +cluster; when kubectl runs outside a cluster and you don't specify a namespace, +the kubectl command acts against the `default` namespace. + ## Operations The following table includes short descriptions and the general syntax for all of the `kubectl` operations: @@ -89,7 +115,7 @@ Operation | Syntax | Description `cluster-info` | `kubectl cluster-info [flags]` | Display endpoint information about the master and services in the cluster. `completion` | `kubectl completion SHELL [options]` | Output shell completion code for the specified shell (bash or zsh). `config` | `kubectl config SUBCOMMAND [flags]` | Modifies kubeconfig files. See the individual subcommands for details. -`convert` | `kubectl convert -f FILENAME [options]` | Convert config files between different API versions. Both YAML and JSON formats are accepted. +`convert` | `kubectl convert -f FILENAME [options]` | Convert config files between different API versions. Both YAML and JSON formats are accepted. Note - requires `kubectl-convert` plugin to be installed. `cordon` | `kubectl cordon NODE [options]` | Mark node as unschedulable. `cp` | `kubectl cp [options]` | Copy files and directories to and from containers. `create` | `kubectl create -f FILENAME [flags]` | Create one or more resources from a file or stdin. diff --git a/content/en/docs/reference/kubernetes-api/authentication-resources/_index.md b/content/en/docs/reference/kubernetes-api/authentication-resources/_index.md index cca65e5302..fac624bf4b 100644 --- a/content/en/docs/reference/kubernetes-api/authentication-resources/_index.md +++ b/content/en/docs/reference/kubernetes-api/authentication-resources/_index.md @@ -1,4 +1,17 @@ --- title: "Authentication Resources" weight: 4 +auto_generated: true --- + + + diff --git a/content/en/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1.md b/content/en/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1.md index c6a0d34757..a02b668387 100644 --- a/content/en/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1.md +++ b/content/en/docs/reference/kubernetes-api/authentication-resources/certificate-signing-request-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "CertificateSigningRequest objects provide a mechanism to obtain x509 certificates by submitting a certificate signing request, and having it asynchronously approved and issued." title: "CertificateSigningRequest" weight: 4 +auto_generated: true --- + + `apiVersion: certificates.k8s.io/v1` `import "k8s.io/api/certificates/v1"` @@ -37,7 +49,7 @@ This API can be used to request client certificates to authenticate to kube-apis - **spec** (}}">CertificateSigningRequestSpec), required - spec contains the certificate request, and is immutable after creation. Only the request, signerName, and usages fields can be set on creation. Other fields are derived by Kubernetes and cannot be modified by users. + spec contains the certificate request, and is immutable after creation. Only the request, signerName, expirationSeconds, and usages fields can be set on creation. Other fields are derived by Kubernetes and cannot be modified by users. - **status** (}}">CertificateSigningRequestStatus) @@ -83,6 +95,23 @@ CertificateSigningRequestSpec contains the certificate request. 5. Expiration/certificate lifetime: whether it is fixed by the signer, configurable by the admin. 6. Whether or not requests for CA certificates are allowed. +- **expirationSeconds** (int32) + + expirationSeconds is the requested duration of validity of the issued certificate. The certificate signer may issue a certificate with a different validity duration so a client must check the delta between the notBefore and and notAfter fields in the issued certificate to determine the actual duration. + + The v1.22+ in-tree implementations of the well-known Kubernetes signers will honor this field as long as the requested duration is not greater than the maximum duration they will honor per the --cluster-signing-duration CLI flag to the Kubernetes controller manager. + + Certificate signers may not honor this field for various reasons: + + 1. Old signer that is unaware of the field (such as the in-tree + implementations prior to v1.22) + 2. Signer whose configured maximum is shorter than the requested duration + 3. Signer whose configured minimum is longer than the requested duration + + The minimum valid value for expirationSeconds is 600, i.e. 10 minutes. + + As of v1.22, this field is beta and is controlled via the CSRDuration feature gate. + - **extra** (map[string][]string) extra contains extra attributes of the user that created the CertificateSigningRequest. Populated by the API server on creation and immutable. @@ -618,6 +647,8 @@ PATCH /apis/certificates.k8s.io/v1/certificatesigningrequests/{name} 200 (}}">CertificateSigningRequest): OK +201 (}}">CertificateSigningRequest): Created + 401: Unauthorized @@ -666,6 +697,8 @@ PATCH /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/approval 200 (}}">CertificateSigningRequest): OK +201 (}}">CertificateSigningRequest): Created + 401: Unauthorized @@ -714,6 +747,8 @@ PATCH /apis/certificates.k8s.io/v1/certificatesigningrequests/{name}/status 200 (}}">CertificateSigningRequest): OK +201 (}}">CertificateSigningRequest): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/authentication-resources/service-account-v1.md b/content/en/docs/reference/kubernetes-api/authentication-resources/service-account-v1.md index 8e202ad28d..250bc29d07 100644 --- a/content/en/docs/reference/kubernetes-api/authentication-resources/service-account-v1.md +++ b/content/en/docs/reference/kubernetes-api/authentication-resources/service-account-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "ServiceAccount binds together: * a name, understood by users, and perhaps by peripheral systems, for an identity * a principal that can be authenticated and authorized * a set of secrets." title: "ServiceAccount" weight: 1 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` @@ -404,6 +416,8 @@ PATCH /api/v1/namespaces/{namespace}/serviceaccounts/{name} 200 (}}">ServiceAccount): OK +201 (}}">ServiceAccount): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/authentication-resources/token-request-v1.md b/content/en/docs/reference/kubernetes-api/authentication-resources/token-request-v1.md index c0ddd62af3..f215074e82 100644 --- a/content/en/docs/reference/kubernetes-api/authentication-resources/token-request-v1.md +++ b/content/en/docs/reference/kubernetes-api/authentication-resources/token-request-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "TokenRequest requests a token for a given service account." title: "TokenRequest" weight: 2 +auto_generated: true --- + + `apiVersion: authentication.k8s.io/v1` `import "k8s.io/api/authentication/v1"` @@ -28,12 +40,15 @@ TokenRequest requests a token for a given service account. - **metadata** (}}">ObjectMeta) + Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **spec** (}}">TokenRequestSpec), required + Spec holds information about the request being evaluated - **status** (}}">TokenRequestStatus) + Status is filled in by the server and indicates whether the token can be authenticated. diff --git a/content/en/docs/reference/kubernetes-api/authentication-resources/token-review-v1.md b/content/en/docs/reference/kubernetes-api/authentication-resources/token-review-v1.md index 06e0ffd5cd..8740fb27a4 100644 --- a/content/en/docs/reference/kubernetes-api/authentication-resources/token-review-v1.md +++ b/content/en/docs/reference/kubernetes-api/authentication-resources/token-review-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "TokenReview attempts to authenticate a token to a known user." title: "TokenReview" weight: 3 +auto_generated: true --- + + `apiVersion: authentication.k8s.io/v1` `import "k8s.io/api/authentication/v1"` @@ -28,6 +40,7 @@ TokenReview attempts to authenticate a token to a known user. Note: TokenReview - **metadata** (}}">ObjectMeta) + Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **spec** (}}">TokenReviewSpec), required diff --git a/content/en/docs/reference/kubernetes-api/authorization-resources/_index.md b/content/en/docs/reference/kubernetes-api/authorization-resources/_index.md index e5390914a1..5b58698bd8 100644 --- a/content/en/docs/reference/kubernetes-api/authorization-resources/_index.md +++ b/content/en/docs/reference/kubernetes-api/authorization-resources/_index.md @@ -1,4 +1,17 @@ --- title: "Authorization Resources" weight: 5 +auto_generated: true --- + + + diff --git a/content/en/docs/reference/kubernetes-api/authorization-resources/cluster-role-binding-v1.md b/content/en/docs/reference/kubernetes-api/authorization-resources/cluster-role-binding-v1.md index d7dfea2179..993148295b 100644 --- a/content/en/docs/reference/kubernetes-api/authorization-resources/cluster-role-binding-v1.md +++ b/content/en/docs/reference/kubernetes-api/authorization-resources/cluster-role-binding-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "ClusterRoleBinding references a ClusterRole, but not contain it." title: "ClusterRoleBinding" weight: 6 +auto_generated: true --- + + `apiVersion: rbac.authorization.k8s.io/v1` `import "k8s.io/api/rbac/v1"` @@ -339,6 +351,8 @@ PATCH /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/{name} 200 (}}">ClusterRoleBinding): OK +201 (}}">ClusterRoleBinding): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/authorization-resources/cluster-role-v1.md b/content/en/docs/reference/kubernetes-api/authorization-resources/cluster-role-v1.md index 34bb8099ef..307d6ffff0 100644 --- a/content/en/docs/reference/kubernetes-api/authorization-resources/cluster-role-v1.md +++ b/content/en/docs/reference/kubernetes-api/authorization-resources/cluster-role-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "ClusterRole is a cluster level, logical grouping of PolicyRules that can be referenced as a unit by a RoleBinding or ClusterRoleBinding." title: "ClusterRole" weight: 5 +auto_generated: true --- + + `apiVersion: rbac.authorization.k8s.io/v1` `import "k8s.io/api/rbac/v1"` @@ -54,11 +66,11 @@ ClusterRole is a cluster level, logical grouping of PolicyRules that can be refe - **rules.resources** ([]string) - Resources is a list of resources this rule applies to. ResourceAll represents all resources. + Resources is a list of resources this rule applies to. '*' represents all resources. - **rules.verbs** ([]string), required - Verbs is a list of Verbs that apply to ALL the ResourceKinds and AttributeRestrictions contained in this rule. VerbAll represents all kinds. + Verbs is a list of Verbs that apply to ALL the ResourceKinds and AttributeRestrictions contained in this rule. '*' represents all verbs. - **rules.resourceNames** ([]string) @@ -335,6 +347,8 @@ PATCH /apis/rbac.authorization.k8s.io/v1/clusterroles/{name} 200 (}}">ClusterRole): OK +201 (}}">ClusterRole): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/authorization-resources/local-subject-access-review-v1.md b/content/en/docs/reference/kubernetes-api/authorization-resources/local-subject-access-review-v1.md index 144dfe257b..d1a61db7d6 100644 --- a/content/en/docs/reference/kubernetes-api/authorization-resources/local-subject-access-review-v1.md +++ b/content/en/docs/reference/kubernetes-api/authorization-resources/local-subject-access-review-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "LocalSubjectAccessReview checks whether or not a user or group can perform an action in a given namespace." title: "LocalSubjectAccessReview" weight: 1 +auto_generated: true --- + + `apiVersion: authorization.k8s.io/v1` `import "k8s.io/api/authorization/v1"` @@ -28,6 +40,7 @@ LocalSubjectAccessReview checks whether or not a user or group can perform an ac - **metadata** (}}">ObjectMeta) + Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **spec** (}}">SubjectAccessReviewSpec), required diff --git a/content/en/docs/reference/kubernetes-api/authorization-resources/role-binding-v1.md b/content/en/docs/reference/kubernetes-api/authorization-resources/role-binding-v1.md index 36b5ebc4d6..f02dcee05a 100644 --- a/content/en/docs/reference/kubernetes-api/authorization-resources/role-binding-v1.md +++ b/content/en/docs/reference/kubernetes-api/authorization-resources/role-binding-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "RoleBinding references a role, but does not contain it." title: "RoleBinding" weight: 8 +auto_generated: true --- + + `apiVersion: rbac.authorization.k8s.io/v1` `import "k8s.io/api/rbac/v1"` @@ -432,6 +444,8 @@ PATCH /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/rolebindings/{na 200 (}}">RoleBinding): OK +201 (}}">RoleBinding): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/authorization-resources/role-v1.md b/content/en/docs/reference/kubernetes-api/authorization-resources/role-v1.md index f87d305247..d96769ef24 100644 --- a/content/en/docs/reference/kubernetes-api/authorization-resources/role-v1.md +++ b/content/en/docs/reference/kubernetes-api/authorization-resources/role-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "Role is a namespaced, logical grouping of PolicyRules that can be referenced as a unit by a RoleBinding." title: "Role" weight: 7 +auto_generated: true --- + + `apiVersion: rbac.authorization.k8s.io/v1` `import "k8s.io/api/rbac/v1"` @@ -43,11 +55,11 @@ Role is a namespaced, logical grouping of PolicyRules that can be referenced as - **rules.resources** ([]string) - Resources is a list of resources this rule applies to. ResourceAll represents all resources. + Resources is a list of resources this rule applies to. '*' represents all resources. - **rules.verbs** ([]string), required - Verbs is a list of Verbs that apply to ALL the ResourceKinds and AttributeRestrictions contained in this rule. VerbAll represents all kinds. + Verbs is a list of Verbs that apply to ALL the ResourceKinds and AttributeRestrictions contained in this rule. '*' represents all verbs. - **rules.resourceNames** ([]string) @@ -417,6 +429,8 @@ PATCH /apis/rbac.authorization.k8s.io/v1/namespaces/{namespace}/roles/{name} 200 (}}">Role): OK +201 (}}">Role): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/authorization-resources/self-subject-access-review-v1.md b/content/en/docs/reference/kubernetes-api/authorization-resources/self-subject-access-review-v1.md index aacafd39b1..a8496aab72 100644 --- a/content/en/docs/reference/kubernetes-api/authorization-resources/self-subject-access-review-v1.md +++ b/content/en/docs/reference/kubernetes-api/authorization-resources/self-subject-access-review-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "SelfSubjectAccessReview checks whether or the current user can perform an action." title: "SelfSubjectAccessReview" weight: 2 +auto_generated: true --- + + `apiVersion: authorization.k8s.io/v1` `import "k8s.io/api/authorization/v1"` @@ -28,6 +40,7 @@ SelfSubjectAccessReview checks whether or the current user can perform an action - **metadata** (}}">ObjectMeta) + Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **spec** (}}">SelfSubjectAccessReviewSpec), required diff --git a/content/en/docs/reference/kubernetes-api/authorization-resources/self-subject-rules-review-v1.md b/content/en/docs/reference/kubernetes-api/authorization-resources/self-subject-rules-review-v1.md index aa3d95332b..f8d85dc23c 100644 --- a/content/en/docs/reference/kubernetes-api/authorization-resources/self-subject-rules-review-v1.md +++ b/content/en/docs/reference/kubernetes-api/authorization-resources/self-subject-rules-review-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "SelfSubjectRulesReview enumerates the set of actions the current user can perform within a namespace." title: "SelfSubjectRulesReview" weight: 3 +auto_generated: true --- + + `apiVersion: authorization.k8s.io/v1` `import "k8s.io/api/authorization/v1"` @@ -28,6 +40,7 @@ SelfSubjectRulesReview enumerates the set of actions the current user can perfor - **metadata** (}}">ObjectMeta) + Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **spec** (}}">SelfSubjectRulesReviewSpec), required @@ -51,13 +64,13 @@ SelfSubjectRulesReview enumerates the set of actions the current user can perfor *NonResourceRule holds information that describes a rule for the non-resource* - - **status.nonResourceRules.verbs** ([]string), required + - **status.nonResourceRules.verbs** ([]string), required - Verb is a list of kubernetes non-resource API verbs, like: get, post, put, delete, patch, head, options. "*" means all. + Verb is a list of kubernetes non-resource API verbs, like: get, post, put, delete, patch, head, options. "*" means all. - - **status.nonResourceRules.nonResourceURLs** ([]string) + - **status.nonResourceRules.nonResourceURLs** ([]string) - NonResourceURLs is a set of partial urls that a user should have access to. *s are allowed, but only as the full, final step in the path. "*" means all. + NonResourceURLs is a set of partial urls that a user should have access to. *s are allowed, but only as the full, final step in the path. "*" means all. - **status.resourceRules** ([]ResourceRule), required @@ -66,22 +79,22 @@ SelfSubjectRulesReview enumerates the set of actions the current user can perfor *ResourceRule is the list of actions the subject is allowed to perform on resources. The list ordering isn't significant, may contain duplicates, and possibly be incomplete.* - - **status.resourceRules.verbs** ([]string), required + - **status.resourceRules.verbs** ([]string), required - Verb is a list of kubernetes resource API verbs, like: get, list, watch, create, update, delete, proxy. "*" means all. + Verb is a list of kubernetes resource API verbs, like: get, list, watch, create, update, delete, proxy. "*" means all. - - **status.resourceRules.apiGroups** ([]string) + - **status.resourceRules.apiGroups** ([]string) - APIGroups is the name of the APIGroup that contains the resources. If multiple API groups are specified, any action requested against one of the enumerated resources in any API group will be allowed. "*" means all. + APIGroups is the name of the APIGroup that contains the resources. If multiple API groups are specified, any action requested against one of the enumerated resources in any API group will be allowed. "*" means all. - - **status.resourceRules.resourceNames** ([]string) + - **status.resourceRules.resourceNames** ([]string) - ResourceNames is an optional white list of names that the rule applies to. An empty set means that everything is allowed. "*" means all. + ResourceNames is an optional white list of names that the rule applies to. An empty set means that everything is allowed. "*" means all. - - **status.resourceRules.resources** ([]string) + - **status.resourceRules.resources** ([]string) - Resources is a list of resources this rule applies to. "*" means all in the specified apiGroups. - "*/foo" represents the subresource 'foo' for all resources in the specified apiGroups. + Resources is a list of resources this rule applies to. "*" means all in the specified apiGroups. + "*/foo" represents the subresource 'foo' for all resources in the specified apiGroups. - **status.evaluationError** (string) @@ -93,7 +106,7 @@ SelfSubjectRulesReview enumerates the set of actions the current user can perfor ## SelfSubjectRulesReviewSpec {#SelfSubjectRulesReviewSpec} - +SelfSubjectRulesReviewSpec defines the specification for SelfSubjectRulesReview.
diff --git a/content/en/docs/reference/kubernetes-api/authorization-resources/subject-access-review-v1.md b/content/en/docs/reference/kubernetes-api/authorization-resources/subject-access-review-v1.md index 5385b125e1..cae105ba24 100644 --- a/content/en/docs/reference/kubernetes-api/authorization-resources/subject-access-review-v1.md +++ b/content/en/docs/reference/kubernetes-api/authorization-resources/subject-access-review-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "SubjectAccessReview checks whether or not a user or group can perform an action." title: "SubjectAccessReview" weight: 4 +auto_generated: true --- + + `apiVersion: authorization.k8s.io/v1` `import "k8s.io/api/authorization/v1"` @@ -28,6 +40,7 @@ SubjectAccessReview checks whether or not a user or group can perform an action. - **metadata** (}}">ObjectMeta) + Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **spec** (}}">SubjectAccessReviewSpec), required diff --git a/content/en/docs/reference/kubernetes-api/cluster-resources/_index.md b/content/en/docs/reference/kubernetes-api/cluster-resources/_index.md index 40d8cdc68d..c0fbcc0813 100644 --- a/content/en/docs/reference/kubernetes-api/cluster-resources/_index.md +++ b/content/en/docs/reference/kubernetes-api/cluster-resources/_index.md @@ -1,4 +1,17 @@ --- title: "Cluster Resources" weight: 8 +auto_generated: true --- + + + diff --git a/content/en/docs/reference/kubernetes-api/cluster-resources/api-service-v1.md b/content/en/docs/reference/kubernetes-api/cluster-resources/api-service-v1.md index 19ed5e0eb0..9f06c7b3fe 100644 --- a/content/en/docs/reference/kubernetes-api/cluster-resources/api-service-v1.md +++ b/content/en/docs/reference/kubernetes-api/cluster-resources/api-service-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "APIService represents a server for a particular GroupVersion." title: "APIService" weight: 4 +auto_generated: true --- + + `apiVersion: apiregistration.k8s.io/v1` `import "k8s.io/kube-aggregator/pkg/apis/apiregistration/v1"` @@ -28,6 +40,7 @@ APIService represents a server for a particular GroupVersion. Name must be "vers - **metadata** (}}">ObjectMeta) + Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **spec** (}}">APIServiceSpec) @@ -154,9 +167,11 @@ APIServiceList is a list of APIService objects. - **metadata** (}}">ListMeta) + Standard list metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **items** ([]}}">APIService), required + Items is the list of APIService @@ -474,6 +489,8 @@ PATCH /apis/apiregistration.k8s.io/v1/apiservices/{name} 200 (}}">APIService): OK +201 (}}">APIService): Created + 401: Unauthorized @@ -522,6 +539,8 @@ PATCH /apis/apiregistration.k8s.io/v1/apiservices/{name}/status 200 (}}">APIService): OK +201 (}}">APIService): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/cluster-resources/binding-v1.md b/content/en/docs/reference/kubernetes-api/cluster-resources/binding-v1.md index a007116367..4acdf07c98 100644 --- a/content/en/docs/reference/kubernetes-api/cluster-resources/binding-v1.md +++ b/content/en/docs/reference/kubernetes-api/cluster-resources/binding-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "Binding ties one object to another; for example, a pod is bound to a node by a scheduler." title: "Binding" weight: 9 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` diff --git a/content/en/docs/reference/kubernetes-api/cluster-resources/component-status-v1.md b/content/en/docs/reference/kubernetes-api/cluster-resources/component-status-v1.md index 3b52667550..0542fedfbd 100644 --- a/content/en/docs/reference/kubernetes-api/cluster-resources/component-status-v1.md +++ b/content/en/docs/reference/kubernetes-api/cluster-resources/component-status-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "ComponentStatus (and ComponentStatusList) holds the cluster validation info." title: "ComponentStatus" weight: 10 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` diff --git a/content/en/docs/reference/kubernetes-api/cluster-resources/event-v1.md b/content/en/docs/reference/kubernetes-api/cluster-resources/event-v1.md index 065cf5a7e7..644496e7f0 100644 --- a/content/en/docs/reference/kubernetes-api/cluster-resources/event-v1.md +++ b/content/en/docs/reference/kubernetes-api/cluster-resources/event-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "Event is a report of an event somewhere in the cluster." title: "Event" weight: 3 +auto_generated: true --- + + `apiVersion: events.k8s.io/v1` `import "k8s.io/api/events/v1"` @@ -26,6 +38,10 @@ Event is a report of an event somewhere in the cluster. It generally denotes som - **kind**: Event +- **metadata** (}}">ObjectMeta) + + Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + - **eventTime** (MicroTime), required eventTime is the time when this Event was first observed. It is required. @@ -33,9 +49,6 @@ Event is a report of an event somewhere in the cluster. It generally denotes som *MicroTime is version of Time with microsecond level precision.* -- **metadata** (}}">ObjectMeta), required - - - **action** (string) action is what action was taken/failed regarding to the regarding object. It is machine-readable. This field cannot be empty for new Events and it can have at most 128 characters. @@ -479,6 +492,8 @@ PATCH /apis/events.k8s.io/v1/namespaces/{namespace}/events/{name} 200 (}}">Event): OK +201 (}}">Event): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/cluster-resources/flow-schema-v1beta1.md b/content/en/docs/reference/kubernetes-api/cluster-resources/flow-schema-v1beta1.md index 8f94555ee2..0df4386eb1 100644 --- a/content/en/docs/reference/kubernetes-api/cluster-resources/flow-schema-v1beta1.md +++ b/content/en/docs/reference/kubernetes-api/cluster-resources/flow-schema-v1beta1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "FlowSchema defines the schema of a group of flows." title: "FlowSchema v1beta1" weight: 7 +auto_generated: true --- + + `apiVersion: flowcontrol.apiserver.k8s.io/v1beta1` `import "k8s.io/api/flowcontrol/v1beta1"` @@ -92,43 +104,46 @@ FlowSchemaSpec describes how the FlowSchema's specification looks like. *Subject matches the originator of a request, as identified by the request authentication system. There are three ways of matching an originator; by user, group, or service account.* - - **rules.subjects.kind** (string), required + - **rules.subjects.kind** (string), required - Required + `kind` indicates which one of the other fields is non-empty. Required - - **rules.subjects.group** (GroupSubject) + - **rules.subjects.group** (GroupSubject) + `group` matches based on user group name. - - *GroupSubject holds detailed information for group-kind subject.* + + *GroupSubject holds detailed information for group-kind subject.* - - **rules.subjects.group.name** (string), required + - **rules.subjects.group.name** (string), required - name is the user group that matches, or "*" to match all user groups. See https://github.com/kubernetes/apiserver/blob/master/pkg/authentication/user/user.go for some well-known group names. Required. + name is the user group that matches, or "*" to match all user groups. See https://github.com/kubernetes/apiserver/blob/master/pkg/authentication/user/user.go for some well-known group names. Required. - - **rules.subjects.serviceAccount** (ServiceAccountSubject) + - **rules.subjects.serviceAccount** (ServiceAccountSubject) + `serviceAccount` matches ServiceAccounts. - - *ServiceAccountSubject holds detailed information for service-account-kind subject.* + + *ServiceAccountSubject holds detailed information for service-account-kind subject.* - - **rules.subjects.serviceAccount.name** (string), required + - **rules.subjects.serviceAccount.name** (string), required - `name` is the name of matching ServiceAccount objects, or "*" to match regardless of name. Required. + `name` is the name of matching ServiceAccount objects, or "*" to match regardless of name. Required. - - **rules.subjects.serviceAccount.namespace** (string), required + - **rules.subjects.serviceAccount.namespace** (string), required - `namespace` is the namespace of matching ServiceAccount objects. Required. + `namespace` is the namespace of matching ServiceAccount objects. Required. - - **rules.subjects.user** (UserSubject) + - **rules.subjects.user** (UserSubject) + `user` matches based on username. - - *UserSubject holds detailed information for user-kind subject.* + + *UserSubject holds detailed information for user-kind subject.* - - **rules.subjects.user.name** (string), required + - **rules.subjects.user.name** (string), required - `name` is the username that matches, or "*" to match all usernames. Required. + `name` is the username that matches, or "*" to match all usernames. Required. - **rules.nonResourceRules** ([]NonResourcePolicyRule) @@ -139,23 +154,23 @@ FlowSchemaSpec describes how the FlowSchema's specification looks like. *NonResourcePolicyRule is a predicate that matches non-resource requests according to their verb and the target non-resource URL. A NonResourcePolicyRule matches a request if and only if both (a) at least one member of verbs matches the request and (b) at least one member of nonResourceURLs matches the request.* - - **rules.nonResourceRules.nonResourceURLs** ([]string), required + - **rules.nonResourceRules.nonResourceURLs** ([]string), required - *Set: unique values will be kept during a merge* - - `nonResourceURLs` is a set of url prefixes that a user should have access to and may not be empty. For example: - - "/healthz" is legal - - "/hea*" is illegal - - "/hea" is legal but matches nothing - - "/hea/*" also matches nothing - - "/healthz/*" matches all per-component health checks. - "*" matches all non-resource urls. if it is present, it must be the only entry. Required. + *Set: unique values will be kept during a merge* + + `nonResourceURLs` is a set of url prefixes that a user should have access to and may not be empty. For example: + - "/healthz" is legal + - "/hea*" is illegal + - "/hea" is legal but matches nothing + - "/hea/*" also matches nothing + - "/healthz/*" matches all per-component health checks. + "*" matches all non-resource urls. if it is present, it must be the only entry. Required. - - **rules.nonResourceRules.verbs** ([]string), required + - **rules.nonResourceRules.verbs** ([]string), required - *Set: unique values will be kept during a merge* - - `verbs` is a list of matching verbs and may not be empty. "*" matches all verbs. If it is present, it must be the only entry. Required. + *Set: unique values will be kept during a merge* + + `verbs` is a list of matching verbs and may not be empty. "*" matches all verbs. If it is present, it must be the only entry. Required. - **rules.resourceRules** ([]ResourcePolicyRule) @@ -166,33 +181,33 @@ FlowSchemaSpec describes how the FlowSchema's specification looks like. *ResourcePolicyRule is a predicate that matches some resource requests, testing the request's verb and the target resource. A ResourcePolicyRule matches a resource request if and only if: (a) at least one member of verbs matches the request, (b) at least one member of apiGroups matches the request, (c) at least one member of resources matches the request, and (d) least one member of namespaces matches the request.* - - **rules.resourceRules.apiGroups** ([]string), required + - **rules.resourceRules.apiGroups** ([]string), required - *Set: unique values will be kept during a merge* - - `apiGroups` is a list of matching API groups and may not be empty. "*" matches all API groups and, if present, must be the only entry. Required. + *Set: unique values will be kept during a merge* + + `apiGroups` is a list of matching API groups and may not be empty. "*" matches all API groups and, if present, must be the only entry. Required. - - **rules.resourceRules.resources** ([]string), required + - **rules.resourceRules.resources** ([]string), required - *Set: unique values will be kept during a merge* - - `resources` is a list of matching resources (i.e., lowercase and plural) with, if desired, subresource. For example, [ "services", "nodes/status" ]. This list may not be empty. "*" matches all resources and, if present, must be the only entry. Required. + *Set: unique values will be kept during a merge* + + `resources` is a list of matching resources (i.e., lowercase and plural) with, if desired, subresource. For example, [ "services", "nodes/status" ]. This list may not be empty. "*" matches all resources and, if present, must be the only entry. Required. - - **rules.resourceRules.verbs** ([]string), required + - **rules.resourceRules.verbs** ([]string), required - *Set: unique values will be kept during a merge* - - `verbs` is a list of matching verbs and may not be empty. "*" matches all verbs and, if present, must be the only entry. Required. + *Set: unique values will be kept during a merge* + + `verbs` is a list of matching verbs and may not be empty. "*" matches all verbs and, if present, must be the only entry. Required. - - **rules.resourceRules.clusterScope** (boolean) + - **rules.resourceRules.clusterScope** (boolean) - `clusterScope` indicates whether to match requests that do not specify a namespace (which happens either because the resource is not namespaced or the request targets all namespaces). If this field is omitted or false then the `namespaces` field must contain a non-empty list. + `clusterScope` indicates whether to match requests that do not specify a namespace (which happens either because the resource is not namespaced or the request targets all namespaces). If this field is omitted or false then the `namespaces` field must contain a non-empty list. - - **rules.resourceRules.namespaces** ([]string) + - **rules.resourceRules.namespaces** ([]string) - *Set: unique values will be kept during a merge* - - `namespaces` is a list of target namespaces that restricts matches. A request that specifies a target namespace matches only if either (a) this list contains that target namespace or (b) this list contains "*". Note that "*" matches any specified namespace but does not match a request that _does not specify_ a namespace (see the `clusterScope` field for that). This list may be empty, but only if `clusterScope` is true. + *Set: unique values will be kept during a merge* + + `namespaces` is a list of target namespaces that restricts matches. A request that specifies a target namespace matches only if either (a) this list contains that target namespace or (b) this list contains "*". Note that "*" matches any specified namespace but does not match a request that _does not specify_ a namespace (see the `clusterScope` field for that). This list may be empty, but only if `clusterScope` is true. @@ -576,6 +591,8 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name} 200 (}}">FlowSchema): OK +201 (}}">FlowSchema): Created + 401: Unauthorized @@ -624,6 +641,8 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/flowschemas/{name}/status 200 (}}">FlowSchema): OK +201 (}}">FlowSchema): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/cluster-resources/lease-v1.md b/content/en/docs/reference/kubernetes-api/cluster-resources/lease-v1.md index 478bc2a8e7..4db3251991 100644 --- a/content/en/docs/reference/kubernetes-api/cluster-resources/lease-v1.md +++ b/content/en/docs/reference/kubernetes-api/cluster-resources/lease-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "Lease defines a lease concept." title: "Lease" weight: 5 +auto_generated: true --- + + `apiVersion: coordination.k8s.io/v1` `import "k8s.io/api/coordination/v1"` @@ -430,6 +442,8 @@ PATCH /apis/coordination.k8s.io/v1/namespaces/{namespace}/leases/{name} 200 (}}">Lease): OK +201 (}}">Lease): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/cluster-resources/namespace-v1.md b/content/en/docs/reference/kubernetes-api/cluster-resources/namespace-v1.md index caa39a5856..8ae6934385 100644 --- a/content/en/docs/reference/kubernetes-api/cluster-resources/namespace-v1.md +++ b/content/en/docs/reference/kubernetes-api/cluster-resources/namespace-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "Namespace provides a scope for Names." title: "Namespace" weight: 2 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` @@ -480,6 +492,8 @@ PATCH /api/v1/namespaces/{name} 200 (}}">Namespace): OK +201 (}}">Namespace): Created + 401: Unauthorized @@ -528,6 +542,8 @@ PATCH /api/v1/namespaces/{name}/status 200 (}}">Namespace): OK +201 (}}">Namespace): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/cluster-resources/node-v1.md b/content/en/docs/reference/kubernetes-api/cluster-resources/node-v1.md index a5e796904f..0046895782 100644 --- a/content/en/docs/reference/kubernetes-api/cluster-resources/node-v1.md +++ b/content/en/docs/reference/kubernetes-api/cluster-resources/node-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "Node is a worker node in Kubernetes." title: "Node" weight: 1 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` @@ -50,37 +62,37 @@ NodeSpec describes the attributes that a node is created with. - **configSource** (NodeConfigSource) - If specified, the source to get node configuration from The DynamicKubeletConfig feature gate must be enabled for the Kubelet to use this field + Deprecated. If specified, the source of the node's configuration. The DynamicKubeletConfig feature gate must be enabled for the Kubelet to use this field. This field is deprecated as of 1.22: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration - *NodeConfigSource specifies a source of node configuration. Exactly one subfield (excluding metadata) must be non-nil.* + *NodeConfigSource specifies a source of node configuration. Exactly one subfield (excluding metadata) must be non-nil. This API is deprecated since 1.22* - **configSource.configMap** (ConfigMapNodeConfigSource) ConfigMap is a reference to a Node's ConfigMap - *ConfigMapNodeConfigSource contains the information to reference a ConfigMap as a config source for the Node.* + *ConfigMapNodeConfigSource contains the information to reference a ConfigMap as a config source for the Node. This API is deprecated since 1.22: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration* - - **configSource.configMap.kubeletConfigKey** (string), required + - **configSource.configMap.kubeletConfigKey** (string), required - KubeletConfigKey declares which key of the referenced ConfigMap corresponds to the KubeletConfiguration structure This field is required in all cases. + KubeletConfigKey declares which key of the referenced ConfigMap corresponds to the KubeletConfiguration structure This field is required in all cases. - - **configSource.configMap.name** (string), required + - **configSource.configMap.name** (string), required - Name is the metadata.name of the referenced ConfigMap. This field is required in all cases. + Name is the metadata.name of the referenced ConfigMap. This field is required in all cases. - - **configSource.configMap.namespace** (string), required + - **configSource.configMap.namespace** (string), required - Namespace is the metadata.namespace of the referenced ConfigMap. This field is required in all cases. + Namespace is the metadata.namespace of the referenced ConfigMap. This field is required in all cases. - - **configSource.configMap.resourceVersion** (string) + - **configSource.configMap.resourceVersion** (string) - ResourceVersion is the metadata.ResourceVersion of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. + ResourceVersion is the metadata.ResourceVersion of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. - - **configSource.configMap.uid** (string) + - **configSource.configMap.uid** (string) - UID is the metadata.UID of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. + UID is the metadata.UID of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. - **externalID** (string) @@ -214,68 +226,68 @@ NodeStatus is information about the current status of a node. Active reports the checkpointed config the node is actively using. Active will represent either the current version of the Assigned config, or the current LastKnownGood config, depending on whether attempting to use the Assigned config results in an error. - *NodeConfigSource specifies a source of node configuration. Exactly one subfield (excluding metadata) must be non-nil.* + *NodeConfigSource specifies a source of node configuration. Exactly one subfield (excluding metadata) must be non-nil. This API is deprecated since 1.22* - - **config.active.configMap** (ConfigMapNodeConfigSource) + - **config.active.configMap** (ConfigMapNodeConfigSource) - ConfigMap is a reference to a Node's ConfigMap + ConfigMap is a reference to a Node's ConfigMap - - *ConfigMapNodeConfigSource contains the information to reference a ConfigMap as a config source for the Node.* + + *ConfigMapNodeConfigSource contains the information to reference a ConfigMap as a config source for the Node. This API is deprecated since 1.22: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration* - - **config.active.configMap.kubeletConfigKey** (string), required + - **config.active.configMap.kubeletConfigKey** (string), required - KubeletConfigKey declares which key of the referenced ConfigMap corresponds to the KubeletConfiguration structure This field is required in all cases. + KubeletConfigKey declares which key of the referenced ConfigMap corresponds to the KubeletConfiguration structure This field is required in all cases. - - **config.active.configMap.name** (string), required + - **config.active.configMap.name** (string), required - Name is the metadata.name of the referenced ConfigMap. This field is required in all cases. + Name is the metadata.name of the referenced ConfigMap. This field is required in all cases. - - **config.active.configMap.namespace** (string), required + - **config.active.configMap.namespace** (string), required - Namespace is the metadata.namespace of the referenced ConfigMap. This field is required in all cases. + Namespace is the metadata.namespace of the referenced ConfigMap. This field is required in all cases. - - **config.active.configMap.resourceVersion** (string) + - **config.active.configMap.resourceVersion** (string) - ResourceVersion is the metadata.ResourceVersion of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. + ResourceVersion is the metadata.ResourceVersion of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. - - **config.active.configMap.uid** (string) + - **config.active.configMap.uid** (string) - UID is the metadata.UID of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. + UID is the metadata.UID of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. - **config.assigned** (NodeConfigSource) Assigned reports the checkpointed config the node will try to use. When Node.Spec.ConfigSource is updated, the node checkpoints the associated config payload to local disk, along with a record indicating intended config. The node refers to this record to choose its config checkpoint, and reports this record in Assigned. Assigned only updates in the status after the record has been checkpointed to disk. When the Kubelet is restarted, it tries to make the Assigned config the Active config by loading and validating the checkpointed payload identified by Assigned. - *NodeConfigSource specifies a source of node configuration. Exactly one subfield (excluding metadata) must be non-nil.* + *NodeConfigSource specifies a source of node configuration. Exactly one subfield (excluding metadata) must be non-nil. This API is deprecated since 1.22* - - **config.assigned.configMap** (ConfigMapNodeConfigSource) + - **config.assigned.configMap** (ConfigMapNodeConfigSource) - ConfigMap is a reference to a Node's ConfigMap + ConfigMap is a reference to a Node's ConfigMap - - *ConfigMapNodeConfigSource contains the information to reference a ConfigMap as a config source for the Node.* + + *ConfigMapNodeConfigSource contains the information to reference a ConfigMap as a config source for the Node. This API is deprecated since 1.22: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration* - - **config.assigned.configMap.kubeletConfigKey** (string), required + - **config.assigned.configMap.kubeletConfigKey** (string), required - KubeletConfigKey declares which key of the referenced ConfigMap corresponds to the KubeletConfiguration structure This field is required in all cases. + KubeletConfigKey declares which key of the referenced ConfigMap corresponds to the KubeletConfiguration structure This field is required in all cases. - - **config.assigned.configMap.name** (string), required + - **config.assigned.configMap.name** (string), required - Name is the metadata.name of the referenced ConfigMap. This field is required in all cases. + Name is the metadata.name of the referenced ConfigMap. This field is required in all cases. - - **config.assigned.configMap.namespace** (string), required + - **config.assigned.configMap.namespace** (string), required - Namespace is the metadata.namespace of the referenced ConfigMap. This field is required in all cases. + Namespace is the metadata.namespace of the referenced ConfigMap. This field is required in all cases. - - **config.assigned.configMap.resourceVersion** (string) + - **config.assigned.configMap.resourceVersion** (string) - ResourceVersion is the metadata.ResourceVersion of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. + ResourceVersion is the metadata.ResourceVersion of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. - - **config.assigned.configMap.uid** (string) + - **config.assigned.configMap.uid** (string) - UID is the metadata.UID of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. + UID is the metadata.UID of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. - **config.error** (string) @@ -286,34 +298,34 @@ NodeStatus is information about the current status of a node. LastKnownGood reports the checkpointed config the node will fall back to when it encounters an error attempting to use the Assigned config. The Assigned config becomes the LastKnownGood config when the node determines that the Assigned config is stable and correct. This is currently implemented as a 10-minute soak period starting when the local record of Assigned config is updated. If the Assigned config is Active at the end of this period, it becomes the LastKnownGood. Note that if Spec.ConfigSource is reset to nil (use local defaults), the LastKnownGood is also immediately reset to nil, because the local default config is always assumed good. You should not make assumptions about the node's method of determining config stability and correctness, as this may change or become configurable in the future. - *NodeConfigSource specifies a source of node configuration. Exactly one subfield (excluding metadata) must be non-nil.* + *NodeConfigSource specifies a source of node configuration. Exactly one subfield (excluding metadata) must be non-nil. This API is deprecated since 1.22* - - **config.lastKnownGood.configMap** (ConfigMapNodeConfigSource) + - **config.lastKnownGood.configMap** (ConfigMapNodeConfigSource) - ConfigMap is a reference to a Node's ConfigMap + ConfigMap is a reference to a Node's ConfigMap - - *ConfigMapNodeConfigSource contains the information to reference a ConfigMap as a config source for the Node.* + + *ConfigMapNodeConfigSource contains the information to reference a ConfigMap as a config source for the Node. This API is deprecated since 1.22: https://git.k8s.io/enhancements/keps/sig-node/281-dynamic-kubelet-configuration* - - **config.lastKnownGood.configMap.kubeletConfigKey** (string), required + - **config.lastKnownGood.configMap.kubeletConfigKey** (string), required - KubeletConfigKey declares which key of the referenced ConfigMap corresponds to the KubeletConfiguration structure This field is required in all cases. + KubeletConfigKey declares which key of the referenced ConfigMap corresponds to the KubeletConfiguration structure This field is required in all cases. - - **config.lastKnownGood.configMap.name** (string), required + - **config.lastKnownGood.configMap.name** (string), required - Name is the metadata.name of the referenced ConfigMap. This field is required in all cases. + Name is the metadata.name of the referenced ConfigMap. This field is required in all cases. - - **config.lastKnownGood.configMap.namespace** (string), required + - **config.lastKnownGood.configMap.namespace** (string), required - Namespace is the metadata.namespace of the referenced ConfigMap. This field is required in all cases. + Namespace is the metadata.namespace of the referenced ConfigMap. This field is required in all cases. - - **config.lastKnownGood.configMap.resourceVersion** (string) + - **config.lastKnownGood.configMap.resourceVersion** (string) - ResourceVersion is the metadata.ResourceVersion of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. + ResourceVersion is the metadata.ResourceVersion of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. - - **config.lastKnownGood.configMap.uid** (string) + - **config.lastKnownGood.configMap.uid** (string) - UID is the metadata.UID of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. + UID is the metadata.UID of the referenced ConfigMap. This field is forbidden in Node.Spec, and required in Node.Status. - **daemonEndpoints** (NodeDaemonEndpoints) @@ -329,9 +341,9 @@ NodeStatus is information about the current status of a node. *DaemonEndpoint contains information about a single Daemon endpoint.* - - **daemonEndpoints.kubeletEndpoint.Port** (int32), required + - **daemonEndpoints.kubeletEndpoint.Port** (int32), required - Port number of the given endpoint. + Port number of the given endpoint. - **images** ([]ContainerImage) @@ -340,7 +352,7 @@ NodeStatus is information about the current status of a node. *Describe a container image* - - **images.names** ([]string), required + - **images.names** ([]string) Names by which this image is known. e.g. ["k8s.gcr.io/hyperkube:v1.0.7", "dockerhub.io/google_containers/hyperkube:v1.0.7"] @@ -758,6 +770,8 @@ PATCH /api/v1/nodes/{name} 200 (}}">Node): OK +201 (}}">Node): Created + 401: Unauthorized @@ -806,6 +820,8 @@ PATCH /api/v1/nodes/{name}/status 200 (}}">Node): OK +201 (}}">Node): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/cluster-resources/priority-level-configuration-v1beta1.md b/content/en/docs/reference/kubernetes-api/cluster-resources/priority-level-configuration-v1beta1.md index f5776972a0..eda105ab73 100644 --- a/content/en/docs/reference/kubernetes-api/cluster-resources/priority-level-configuration-v1beta1.md +++ b/content/en/docs/reference/kubernetes-api/cluster-resources/priority-level-configuration-v1beta1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "PriorityLevelConfiguration represents the configuration of a priority level." title: "PriorityLevelConfiguration v1beta1" weight: 8 +auto_generated: true --- + + `apiVersion: flowcontrol.apiserver.k8s.io/v1beta1` `import "k8s.io/api/flowcontrol/v1beta1"` @@ -76,28 +88,28 @@ PriorityLevelConfigurationSpec specifies the configuration of a priority level. *LimitResponse defines how to handle requests that can not be executed right now.* - - **limited.limitResponse.type** (string), required + - **limited.limitResponse.type** (string), required - `type` is "Queue" or "Reject". "Queue" means that requests that can not be executed upon arrival are held in a queue until they can be executed or a queuing limit is reached. "Reject" means that requests that can not be executed upon arrival are rejected. Required. + `type` is "Queue" or "Reject". "Queue" means that requests that can not be executed upon arrival are held in a queue until they can be executed or a queuing limit is reached. "Reject" means that requests that can not be executed upon arrival are rejected. Required. - - **limited.limitResponse.queuing** (QueuingConfiguration) + - **limited.limitResponse.queuing** (QueuingConfiguration) - `queuing` holds the configuration parameters for queuing. This field may be non-empty only if `type` is `"Queue"`. + `queuing` holds the configuration parameters for queuing. This field may be non-empty only if `type` is `"Queue"`. - - *QueuingConfiguration holds the configuration parameters for queuing* + + *QueuingConfiguration holds the configuration parameters for queuing* - - **limited.limitResponse.queuing.handSize** (int32) + - **limited.limitResponse.queuing.handSize** (int32) - `handSize` is a small positive number that configures the shuffle sharding of requests into queues. When enqueuing a request at this priority level the request's flow identifier (a string pair) is hashed and the hash value is used to shuffle the list of queues and deal a hand of the size specified here. The request is put into one of the shortest queues in that hand. `handSize` must be no larger than `queues`, and should be significantly smaller (so that a few heavy flows do not saturate most of the queues). See the user-facing documentation for more extensive guidance on setting this field. This field has a default value of 8. + `handSize` is a small positive number that configures the shuffle sharding of requests into queues. When enqueuing a request at this priority level the request's flow identifier (a string pair) is hashed and the hash value is used to shuffle the list of queues and deal a hand of the size specified here. The request is put into one of the shortest queues in that hand. `handSize` must be no larger than `queues`, and should be significantly smaller (so that a few heavy flows do not saturate most of the queues). See the user-facing documentation for more extensive guidance on setting this field. This field has a default value of 8. - - **limited.limitResponse.queuing.queueLengthLimit** (int32) + - **limited.limitResponse.queuing.queueLengthLimit** (int32) - `queueLengthLimit` is the maximum number of requests allowed to be waiting in a given queue of this priority level at a time; excess requests are rejected. This value must be positive. If not specified, it will be defaulted to 50. + `queueLengthLimit` is the maximum number of requests allowed to be waiting in a given queue of this priority level at a time; excess requests are rejected. This value must be positive. If not specified, it will be defaulted to 50. - - **limited.limitResponse.queuing.queues** (int32) + - **limited.limitResponse.queuing.queues** (int32) - `queues` is the number of queues for this priority level. The queues exist independently at each apiserver. The value must be positive. Setting it to 1 effectively precludes shufflesharding and thus makes the distinguisher method of associated flow schemas irrelevant. This field has a default value of 64. + `queues` is the number of queues for this priority level. The queues exist independently at each apiserver. The value must be positive. Setting it to 1 effectively precludes shufflesharding and thus makes the distinguisher method of associated flow schemas irrelevant. This field has a default value of 64. @@ -481,6 +493,8 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{na 200 (}}">PriorityLevelConfiguration): OK +201 (}}">PriorityLevelConfiguration): Created + 401: Unauthorized @@ -529,6 +543,8 @@ PATCH /apis/flowcontrol.apiserver.k8s.io/v1beta1/prioritylevelconfigurations/{na 200 (}}">PriorityLevelConfiguration): OK +201 (}}">PriorityLevelConfiguration): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/cluster-resources/runtime-class-v1.md b/content/en/docs/reference/kubernetes-api/cluster-resources/runtime-class-v1.md index 040c894ae3..fad02bc731 100644 --- a/content/en/docs/reference/kubernetes-api/cluster-resources/runtime-class-v1.md +++ b/content/en/docs/reference/kubernetes-api/cluster-resources/runtime-class-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "RuntimeClass defines a class of container runtime supported in the cluster." title: "RuntimeClass" weight: 6 +auto_generated: true --- + + `apiVersion: node.k8s.io/v1` `import "k8s.io/api/node/v1"` @@ -67,25 +79,25 @@ RuntimeClass defines a class of container runtime supported in the cluster. The *The pod this Toleration is attached to tolerates any taint that matches the triple using the matching operator .* - - **scheduling.tolerations.key** (string) + - **scheduling.tolerations.key** (string) - Key is the taint key that the toleration applies to. Empty means match all taint keys. If the key is empty, operator must be Exists; this combination means to match all values and all keys. + Key is the taint key that the toleration applies to. Empty means match all taint keys. If the key is empty, operator must be Exists; this combination means to match all values and all keys. - - **scheduling.tolerations.operator** (string) + - **scheduling.tolerations.operator** (string) - Operator represents a key's relationship to the value. Valid operators are Exists and Equal. Defaults to Equal. Exists is equivalent to wildcard for value, so that a pod can tolerate all taints of a particular category. + Operator represents a key's relationship to the value. Valid operators are Exists and Equal. Defaults to Equal. Exists is equivalent to wildcard for value, so that a pod can tolerate all taints of a particular category. - - **scheduling.tolerations.value** (string) + - **scheduling.tolerations.value** (string) - Value is the taint value the toleration matches to. If the operator is Exists, the value should be empty, otherwise just a regular string. + Value is the taint value the toleration matches to. If the operator is Exists, the value should be empty, otherwise just a regular string. - - **scheduling.tolerations.effect** (string) + - **scheduling.tolerations.effect** (string) - Effect indicates the taint effect to match. Empty means match all taint effects. When specified, allowed values are NoSchedule, PreferNoSchedule and NoExecute. + Effect indicates the taint effect to match. Empty means match all taint effects. When specified, allowed values are NoSchedule, PreferNoSchedule and NoExecute. - - **scheduling.tolerations.tolerationSeconds** (int64) + - **scheduling.tolerations.tolerationSeconds** (int64) - TolerationSeconds represents the period of time the toleration (which must be of effect NoExecute, otherwise this field is ignored) tolerates the taint. By default, it is not set, which means tolerate the taint forever (do not evict). Zero and negative values will be treated as 0 (evict immediately) by the system. + TolerationSeconds represents the period of time the toleration (which must be of effect NoExecute, otherwise this field is ignored) tolerates the taint. By default, it is not set, which means tolerate the taint forever (do not evict). Zero and negative values will be treated as 0 (evict immediately) by the system. @@ -354,6 +366,8 @@ PATCH /apis/node.k8s.io/v1/runtimeclasses/{name} 200 (}}">RuntimeClass): OK +201 (}}">RuntimeClass): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/_index.md b/content/en/docs/reference/kubernetes-api/common-definitions/_index.md index 580fa96ff2..00b036aa6e 100644 --- a/content/en/docs/reference/kubernetes-api/common-definitions/_index.md +++ b/content/en/docs/reference/kubernetes-api/common-definitions/_index.md @@ -1,4 +1,17 @@ --- title: "Common Definitions" weight: 9 +auto_generated: true --- + + + diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/delete-options.md b/content/en/docs/reference/kubernetes-api/common-definitions/delete-options.md index 09fd2ce3d1..4131bcb1dd 100644 --- a/content/en/docs/reference/kubernetes-api/common-definitions/delete-options.md +++ b/content/en/docs/reference/kubernetes-api/common-definitions/delete-options.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "DeleteOptions may be provided when deleting an API object." title: "DeleteOptions" weight: 1 +auto_generated: true --- + + `import "k8s.io/apimachinery/pkg/apis/meta/v1"` diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/downward-api-volume-file.md b/content/en/docs/reference/kubernetes-api/common-definitions/downward-api-volume-file.md deleted file mode 100644 index 5aa9f29822..0000000000 --- a/content/en/docs/reference/kubernetes-api/common-definitions/downward-api-volume-file.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -api_metadata: - apiVersion: "" - import: "k8s.io/api/core/v1" - kind: "DownwardAPIVolumeFile" -content_type: "api_reference" -description: "DownwardAPIVolumeFile represents information to create the file containing the pod field." -title: "DownwardAPIVolumeFile" -weight: 2 ---- - - - -`import "k8s.io/api/core/v1"` - - -DownwardAPIVolumeFile represents information to create the file containing the pod field - -
- -- **path** (string), required - - Required: Path is the relative path name of the file to be created. Must not be absolute or contain the '..' path. Must be utf-8 encoded. The first item of the relative path must not start with '..' - -- **fieldRef** (}}">ObjectFieldSelector) - - Required: Selects a field of the pod: only annotations, labels, name and namespace are supported. - -- **mode** (int32) - - Optional: mode bits used to set permissions on this file, must be an octal value between 0000 and 0777 or a decimal value between 0 and 511. YAML accepts both octal and decimal values, JSON requires decimal values for mode bits. If not specified, the volume defaultMode will be used. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set. - -- **resourceFieldRef** (}}">ResourceFieldSelector) - - Selects a resource of the container: only resources limits and requests (limits.cpu, limits.memory, requests.cpu and requests.memory) are currently supported. - - - - - diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/exec-action.md b/content/en/docs/reference/kubernetes-api/common-definitions/exec-action.md deleted file mode 100644 index 0078859720..0000000000 --- a/content/en/docs/reference/kubernetes-api/common-definitions/exec-action.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -api_metadata: - apiVersion: "" - import: "k8s.io/api/core/v1" - kind: "ExecAction" -content_type: "api_reference" -description: "ExecAction describes a \"run in container\" action." -title: "ExecAction" -weight: 3 ---- - - - -`import "k8s.io/api/core/v1"` - - -ExecAction describes a "run in container" action. - -
- -- **command** ([]string) - - Command is the command line to execute inside the container, the working directory for the command is root ('/') in the container's filesystem. The command is simply exec'd, it is not run inside a shell, so traditional shell instructions ('|', etc) won't work. To use a shell, you need to explicitly call out to that shell. Exit status of 0 is treated as live/healthy and non-zero is unhealthy. - - - - - diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/http-get-action.md b/content/en/docs/reference/kubernetes-api/common-definitions/http-get-action.md deleted file mode 100644 index 1eabe9ac2d..0000000000 --- a/content/en/docs/reference/kubernetes-api/common-definitions/http-get-action.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -api_metadata: - apiVersion: "" - import: "k8s.io/api/core/v1" - kind: "HTTPGetAction" -content_type: "api_reference" -description: "HTTPGetAction describes an action based on HTTP Get requests." -title: "HTTPGetAction" -weight: 4 ---- - - - -`import "k8s.io/api/core/v1"` - - -HTTPGetAction describes an action based on HTTP Get requests. - -
- -- **port** (IntOrString), required - - Name or number of the port to access on the container. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. - - - *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* - -- **host** (string) - - Host name to connect to, defaults to the pod IP. You probably want to set "Host" in httpHeaders instead. - -- **httpHeaders** ([]HTTPHeader) - - Custom headers to set in the request. HTTP allows repeated headers. - - - *HTTPHeader describes a custom header to be used in HTTP probes* - - - **httpHeaders.name** (string), required - - The header field name - - - **httpHeaders.value** (string), required - - The header field value - -- **path** (string) - - Path to access on the HTTP server. - -- **scheme** (string) - - Scheme to use for connecting to the host. Defaults to HTTP. - - - - - diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/json-schema-props.md b/content/en/docs/reference/kubernetes-api/common-definitions/json-schema-props.md deleted file mode 100644 index 622dba69a2..0000000000 --- a/content/en/docs/reference/kubernetes-api/common-definitions/json-schema-props.md +++ /dev/null @@ -1,226 +0,0 @@ ---- -api_metadata: - apiVersion: "" - import: "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1" - kind: "JSONSchemaProps" -content_type: "api_reference" -description: "JSONSchemaProps is a JSON-Schema following Specification Draft 4 (http://json-schema." -title: "JSONSchemaProps" -weight: 5 ---- - - - -`import "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1"` - - -JSONSchemaProps is a JSON-Schema following Specification Draft 4 (http://json-schema.org/). - -
- -- **$ref** (string) - - -- **$schema** (string) - - -- **additionalItems** (JSONSchemaPropsOrBool) - - - - *JSONSchemaPropsOrBool represents JSONSchemaProps or a boolean value. Defaults to true for the boolean property.* - -- **additionalProperties** (JSONSchemaPropsOrBool) - - - - *JSONSchemaPropsOrBool represents JSONSchemaProps or a boolean value. Defaults to true for the boolean property.* - -- **allOf** ([]}}">JSONSchemaProps) - - -- **anyOf** ([]}}">JSONSchemaProps) - - -- **default** (JSON) - - default is a default value for undefined object fields. Defaulting is a beta feature under the CustomResourceDefaulting feature gate. Defaulting requires spec.preserveUnknownFields to be false. - - - *JSON represents any valid JSON value. These types are supported: bool, int64, float64, string, []interface{}, map[string]interface{} and nil.* - -- **definitions** (map[string]}}">JSONSchemaProps) - - -- **dependencies** (map[string]JSONSchemaPropsOrStringArray) - - - - *JSONSchemaPropsOrStringArray represents a JSONSchemaProps or a string array.* - -- **description** (string) - - -- **enum** ([]JSON) - - - - *JSON represents any valid JSON value. These types are supported: bool, int64, float64, string, []interface{}, map[string]interface{} and nil.* - -- **example** (JSON) - - - - *JSON represents any valid JSON value. These types are supported: bool, int64, float64, string, []interface{}, map[string]interface{} and nil.* - -- **exclusiveMaximum** (boolean) - - -- **exclusiveMinimum** (boolean) - - -- **externalDocs** (ExternalDocumentation) - - - - *ExternalDocumentation allows referencing an external resource for extended documentation.* - - - **externalDocs.description** (string) - - - - **externalDocs.url** (string) - - -- **format** (string) - - format is an OpenAPI v3 format string. Unknown formats are ignored. The following formats are validated: - - - bsonobjectid: a bson object ID, i.e. a 24 characters hex string - uri: an URI as parsed by Golang net/url.ParseRequestURI - email: an email address as parsed by Golang net/mail.ParseAddress - hostname: a valid representation for an Internet host name, as defined by RFC 1034, section 3.1 [RFC1034]. - ipv4: an IPv4 IP as parsed by Golang net.ParseIP - ipv6: an IPv6 IP as parsed by Golang net.ParseIP - cidr: a CIDR as parsed by Golang net.ParseCIDR - mac: a MAC address as parsed by Golang net.ParseMAC - uuid: an UUID that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{12}$ - uuid3: an UUID3 that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?3[0-9a-f]{3}-?[0-9a-f]{4}-?[0-9a-f]{12}$ - uuid4: an UUID4 that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?4[0-9a-f]{3}-?[89ab][0-9a-f]{3}-?[0-9a-f]{12}$ - uuid5: an UUID5 that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?5[0-9a-f]{3}-?[89ab][0-9a-f]{3}-?[0-9a-f]{12}$ - isbn: an ISBN10 or ISBN13 number string like "0321751043" or "978-0321751041" - isbn10: an ISBN10 number string like "0321751043" - isbn13: an ISBN13 number string like "978-0321751041" - creditcard: a credit card number defined by the regex ^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})$ with any non digit characters mixed in - ssn: a U.S. social security number following the regex ^\d{3}[- ]?\d{2}[- ]?\d{4}$ - hexcolor: an hexadecimal color code like "#FFFFFF: following the regex ^#?([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$ - rgbcolor: an RGB color code like rgb like "rgb(255,255,2559" - byte: base64 encoded binary data - password: any kind of string - date: a date string like "2006-01-02" as defined by full-date in RFC3339 - duration: a duration string like "22 ns" as parsed by Golang time.ParseDuration or compatible with Scala duration format - datetime: a date time string like "2014-12-15T19:30:20.000Z" as defined by date-time in RFC3339. - -- **id** (string) - - -- **items** (JSONSchemaPropsOrArray) - - - - *JSONSchemaPropsOrArray represents a value that can either be a JSONSchemaProps or an array of JSONSchemaProps. Mainly here for serialization purposes.* - -- **maxItems** (int64) - - -- **maxLength** (int64) - - -- **maxProperties** (int64) - - -- **maximum** (double) - - -- **minItems** (int64) - - -- **minLength** (int64) - - -- **minProperties** (int64) - - -- **minimum** (double) - - -- **multipleOf** (double) - - -- **not** (}}">JSONSchemaProps) - - -- **nullable** (boolean) - - -- **oneOf** ([]}}">JSONSchemaProps) - - -- **pattern** (string) - - -- **patternProperties** (map[string]}}">JSONSchemaProps) - - -- **properties** (map[string]}}">JSONSchemaProps) - - -- **required** ([]string) - - -- **title** (string) - - -- **type** (string) - - -- **uniqueItems** (boolean) - - -- **x-kubernetes-embedded-resource** (boolean) - - x-kubernetes-embedded-resource defines that the value is an embedded Kubernetes runtime.Object, with TypeMeta and ObjectMeta. The type must be object. It is allowed to further restrict the embedded object. kind, apiVersion and metadata are validated automatically. x-kubernetes-preserve-unknown-fields is allowed to be true, but does not have to be if the object is fully specified (up to kind, apiVersion, metadata). - -- **x-kubernetes-int-or-string** (boolean) - - x-kubernetes-int-or-string specifies that this value is either an integer or a string. If this is true, an empty type is allowed and type as child of anyOf is permitted if following one of the following patterns: - - 1) anyOf: - - type: integer - - type: string - 2) allOf: - - anyOf: - - type: integer - - type: string - - ... zero or more - -- **x-kubernetes-list-map-keys** ([]string) - - x-kubernetes-list-map-keys annotates an array with the x-kubernetes-list-type `map` by specifying the keys used as the index of the map. - - This tag MUST only be used on lists that have the "x-kubernetes-list-type" extension set to "map". Also, the values specified for this attribute must be a scalar typed field of the child structure (no nesting is supported). - - The properties specified must either be required or have a default value, to ensure those properties are present for all list items. - -- **x-kubernetes-list-type** (string) - - x-kubernetes-list-type annotates an array to further describe its topology. This extension must only be used on lists and may have 3 possible values: - - 1) `atomic`: the list is treated as a single entity, like a scalar. - Atomic lists will be entirely replaced when updated. This extension - may be used on any type of list (struct, scalar, ...). - 2) `set`: - Sets are lists that must not have multiple items with the same value. Each - value must be a scalar, an object with x-kubernetes-map-type `atomic` or an - array with x-kubernetes-list-type `atomic`. - 3) `map`: - These lists are like maps in that their elements have a non-index key - used to identify them. Order is preserved upon merge. The map tag - must only be used on a list with elements of type object. - Defaults to atomic for arrays. - -- **x-kubernetes-map-type** (string) - - x-kubernetes-map-type annotates an object to further describe its topology. This extension must only be used when type is object and may have 2 possible values: - - 1) `granular`: - These maps are actual maps (key-value pairs) and each fields are independent - from each other (they can each be manipulated by separate actors). This is - the default behaviour for all maps. - 2) `atomic`: the list is treated as a single entity, like a scalar. - Atomic maps will be entirely replaced when updated. - -- **x-kubernetes-preserve-unknown-fields** (boolean) - - x-kubernetes-preserve-unknown-fields stops the API server decoding step from pruning fields which are not specified in the validation schema. This affects fields recursively, but switches back to normal pruning behaviour if nested properties or additionalProperties are specified in the schema. This can either be true or undefined. False is forbidden. - - - - - diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/key-to-path.md b/content/en/docs/reference/kubernetes-api/common-definitions/key-to-path.md deleted file mode 100644 index 64068fe1a2..0000000000 --- a/content/en/docs/reference/kubernetes-api/common-definitions/key-to-path.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -api_metadata: - apiVersion: "" - import: "k8s.io/api/core/v1" - kind: "KeyToPath" -content_type: "api_reference" -description: "Maps a string key to a path within a volume." -title: "KeyToPath" -weight: 6 ---- - - - -`import "k8s.io/api/core/v1"` - - -Maps a string key to a path within a volume. - -
- -- **key** (string), required - - The key to project. - -- **path** (string), required - - The relative path of the file to map the key to. May not be an absolute path. May not contain the path element '..'. May not start with the string '..'. - -- **mode** (int32) - - Optional: mode bits used to set permissions on this file. Must be an octal value between 0000 and 0777 or a decimal value between 0 and 511. YAML accepts both octal and decimal values, JSON requires decimal values for mode bits. If not specified, the volume defaultMode will be used. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set. - - - - - diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/label-selector.md b/content/en/docs/reference/kubernetes-api/common-definitions/label-selector.md index a588677077..d81c26d17a 100644 --- a/content/en/docs/reference/kubernetes-api/common-definitions/label-selector.md +++ b/content/en/docs/reference/kubernetes-api/common-definitions/label-selector.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "A label selector is a label query over a set of resources." title: "LabelSelector" -weight: 7 +weight: 2 +auto_generated: true --- + + `import "k8s.io/apimachinery/pkg/apis/meta/v1"` diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/list-meta.md b/content/en/docs/reference/kubernetes-api/common-definitions/list-meta.md index 0b703734b0..96f2dafd30 100644 --- a/content/en/docs/reference/kubernetes-api/common-definitions/list-meta.md +++ b/content/en/docs/reference/kubernetes-api/common-definitions/list-meta.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "ListMeta describes metadata that synthetic resources must have, including lists and various status objects." title: "ListMeta" -weight: 8 +weight: 3 +auto_generated: true --- + + `import "k8s.io/apimachinery/pkg/apis/meta/v1"` diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/local-object-reference.md b/content/en/docs/reference/kubernetes-api/common-definitions/local-object-reference.md index e97b84aca9..ce56803bac 100644 --- a/content/en/docs/reference/kubernetes-api/common-definitions/local-object-reference.md +++ b/content/en/docs/reference/kubernetes-api/common-definitions/local-object-reference.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "LocalObjectReference contains enough information to let you locate the referenced object inside the same namespace." title: "LocalObjectReference" -weight: 9 +weight: 4 +auto_generated: true --- + + `import "k8s.io/api/core/v1"` diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/node-affinity.md b/content/en/docs/reference/kubernetes-api/common-definitions/node-affinity.md deleted file mode 100644 index 57b0b62715..0000000000 --- a/content/en/docs/reference/kubernetes-api/common-definitions/node-affinity.md +++ /dev/null @@ -1,72 +0,0 @@ ---- -api_metadata: - apiVersion: "" - import: "k8s.io/api/core/v1" - kind: "NodeAffinity" -content_type: "api_reference" -description: "Node affinity is a group of node affinity scheduling rules." -title: "NodeAffinity" -weight: 10 ---- - - - -`import "k8s.io/api/core/v1"` - - -Node affinity is a group of node affinity scheduling rules. - -
- -- **preferredDuringSchedulingIgnoredDuringExecution** ([]PreferredSchedulingTerm) - - The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node matches the corresponding matchExpressions; the node(s) with the highest sum are the most preferred. - - - *An empty preferred scheduling term matches all objects with implicit weight 0 (i.e. it's a no-op). A null preferred scheduling term matches no objects (i.e. is also a no-op).* - - - **preferredDuringSchedulingIgnoredDuringExecution.preference** (NodeSelectorTerm), required - - A node selector term, associated with the corresponding weight. - - - *A null or empty node selector term matches no objects. The requirements of them are ANDed. The TopologySelectorTerm type implements a subset of the NodeSelectorTerm.* - - - **preferredDuringSchedulingIgnoredDuringExecution.preference.matchExpressions** ([]}}">NodeSelectorRequirement) - - A list of node selector requirements by node's labels. - - - **preferredDuringSchedulingIgnoredDuringExecution.preference.matchFields** ([]}}">NodeSelectorRequirement) - - A list of node selector requirements by node's fields. - - - **preferredDuringSchedulingIgnoredDuringExecution.weight** (int32), required - - Weight associated with matching the corresponding nodeSelectorTerm, in the range 1-100. - -- **requiredDuringSchedulingIgnoredDuringExecution** (NodeSelector) - - If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to an update), the system may or may not try to eventually evict the pod from its node. - - - *A node selector represents the union of the results of one or more label queries over a set of nodes; that is, it represents the OR of the selectors represented by the node selector terms.* - - - **requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms** ([]NodeSelectorTerm), required - - Required. A list of node selector terms. The terms are ORed. - - - *A null or empty node selector term matches no objects. The requirements of them are ANDed. The TopologySelectorTerm type implements a subset of the NodeSelectorTerm.* - - - **requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchExpressions** ([]}}">NodeSelectorRequirement) - - A list of node selector requirements by node's labels. - - - **requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchFields** ([]}}">NodeSelectorRequirement) - - A list of node selector requirements by node's fields. - - - - - diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/node-selector-requirement.md b/content/en/docs/reference/kubernetes-api/common-definitions/node-selector-requirement.md index 3e8b935ef7..33af2e88e3 100644 --- a/content/en/docs/reference/kubernetes-api/common-definitions/node-selector-requirement.md +++ b/content/en/docs/reference/kubernetes-api/common-definitions/node-selector-requirement.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "A node selector requirement is a selector that contains values, a key, and an operator that relates the key and values." title: "NodeSelectorRequirement" -weight: 11 +weight: 5 +auto_generated: true --- + + `import "k8s.io/api/core/v1"` diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/object-field-selector.md b/content/en/docs/reference/kubernetes-api/common-definitions/object-field-selector.md index c109fa3fdf..9d1fc9e9c8 100644 --- a/content/en/docs/reference/kubernetes-api/common-definitions/object-field-selector.md +++ b/content/en/docs/reference/kubernetes-api/common-definitions/object-field-selector.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "ObjectFieldSelector selects an APIVersioned field of an object." title: "ObjectFieldSelector" -weight: 12 +weight: 6 +auto_generated: true --- + + `import "k8s.io/api/core/v1"` diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/object-meta.md b/content/en/docs/reference/kubernetes-api/common-definitions/object-meta.md index b3bc31e716..40c7899adc 100644 --- a/content/en/docs/reference/kubernetes-api/common-definitions/object-meta.md +++ b/content/en/docs/reference/kubernetes-api/common-definitions/object-meta.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "ObjectMeta is metadata that all persisted resources must have, which includes all objects users must create." title: "ObjectMeta" -weight: 13 +weight: 7 +auto_generated: true --- + + `import "k8s.io/apimachinery/pkg/apis/meta/v1"` @@ -87,6 +99,10 @@ ObjectMeta is metadata that all persisted resources must have, which includes al Operation is the type of operation which lead to this ManagedFieldsEntry being created. The only valid values for this field are 'Apply' and 'Update'. + - **managedFields.subresource** (string) + + Subresource is the name of the subresource used to update that object, or empty string if the object was updated through the main resource. The value of this field is used to distinguish between managers, even if they share the same name. For example, a status update will be distinct from a regular update using the same manager name. Note that the APIVersion field is not related to the Subresource field and it always corresponds to the version of the main resource. + - **managedFields.time** (Time) Time is timestamp of when these fields were set. It should always be empty if Operation is 'Apply' diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/object-reference.md b/content/en/docs/reference/kubernetes-api/common-definitions/object-reference.md index 71c40a0702..fa999b11f4 100644 --- a/content/en/docs/reference/kubernetes-api/common-definitions/object-reference.md +++ b/content/en/docs/reference/kubernetes-api/common-definitions/object-reference.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "ObjectReference contains enough information to let you inspect or modify the referred object." title: "ObjectReference" -weight: 14 +weight: 8 +auto_generated: true --- + + `import "k8s.io/api/core/v1"` diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/patch.md b/content/en/docs/reference/kubernetes-api/common-definitions/patch.md index 054508e807..a32a88b309 100644 --- a/content/en/docs/reference/kubernetes-api/common-definitions/patch.md +++ b/content/en/docs/reference/kubernetes-api/common-definitions/patch.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "Patch is provided to give a concrete name and type to the Kubernetes PATCH request body." title: "Patch" -weight: 15 +weight: 9 +auto_generated: true --- + + `import "k8s.io/apimachinery/pkg/apis/meta/v1"` diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/pod-affinity.md b/content/en/docs/reference/kubernetes-api/common-definitions/pod-affinity.md deleted file mode 100644 index 06291de393..0000000000 --- a/content/en/docs/reference/kubernetes-api/common-definitions/pod-affinity.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -api_metadata: - apiVersion: "" - import: "k8s.io/api/core/v1" - kind: "PodAffinity" -content_type: "api_reference" -description: "Pod affinity is a group of inter pod affinity scheduling rules." -title: "PodAffinity" -weight: 16 ---- - - - -`import "k8s.io/api/core/v1"` - - -Pod affinity is a group of inter pod affinity scheduling rules. - -
- -- **preferredDuringSchedulingIgnoredDuringExecution** ([]WeightedPodAffinityTerm) - - The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the node(s) with the highest sum are the most preferred. - - - *The weights of all of the matched WeightedPodAffinityTerm fields are added per-node to find the most preferred node(s)* - - - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm** (PodAffinityTerm), required - - Required. A pod affinity term, associated with the corresponding weight. - - - *Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key matches that of any node on which a pod of the set of pods is running* - - - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.topologyKey** (string), required - - This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed. - - - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.labelSelector** (}}">LabelSelector) - - A label query over a set of resources, in this case pods. - - - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.namespaces** ([]string) - - namespaces specifies which namespaces the labelSelector applies to (matches against); null or empty list means "this pod's namespace" - - - **preferredDuringSchedulingIgnoredDuringExecution.weight** (int32), required - - weight associated with matching the corresponding podAffinityTerm, in the range 1-100. - -- **requiredDuringSchedulingIgnoredDuringExecution** ([]PodAffinityTerm) - - If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node. When there are multiple elements, the lists of nodes corresponding to each podAffinityTerm are intersected, i.e. all terms must be satisfied. - - - *Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key matches that of any node on which a pod of the set of pods is running* - - - **requiredDuringSchedulingIgnoredDuringExecution.topologyKey** (string), required - - This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed. - - - **requiredDuringSchedulingIgnoredDuringExecution.labelSelector** (}}">LabelSelector) - - A label query over a set of resources, in this case pods. - - - **requiredDuringSchedulingIgnoredDuringExecution.namespaces** ([]string) - - namespaces specifies which namespaces the labelSelector applies to (matches against); null or empty list means "this pod's namespace" - - - - - diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/pod-anti-affinity.md b/content/en/docs/reference/kubernetes-api/common-definitions/pod-anti-affinity.md deleted file mode 100644 index baebcc3c0c..0000000000 --- a/content/en/docs/reference/kubernetes-api/common-definitions/pod-anti-affinity.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -api_metadata: - apiVersion: "" - import: "k8s.io/api/core/v1" - kind: "PodAntiAffinity" -content_type: "api_reference" -description: "Pod anti affinity is a group of inter pod anti affinity scheduling rules." -title: "PodAntiAffinity" -weight: 17 ---- - - - -`import "k8s.io/api/core/v1"` - - -Pod anti affinity is a group of inter pod anti affinity scheduling rules. - -
- -- **preferredDuringSchedulingIgnoredDuringExecution** ([]WeightedPodAffinityTerm) - - The scheduler will prefer to schedule pods to nodes that satisfy the anti-affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling anti-affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the node(s) with the highest sum are the most preferred. - - - *The weights of all of the matched WeightedPodAffinityTerm fields are added per-node to find the most preferred node(s)* - - - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm** (PodAffinityTerm), required - - Required. A pod affinity term, associated with the corresponding weight. - - - *Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key matches that of any node on which a pod of the set of pods is running* - - - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.topologyKey** (string), required - - This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed. - - - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.labelSelector** (}}">LabelSelector) - - A label query over a set of resources, in this case pods. - - - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.namespaces** ([]string) - - namespaces specifies which namespaces the labelSelector applies to (matches against); null or empty list means "this pod's namespace" - - - **preferredDuringSchedulingIgnoredDuringExecution.weight** (int32), required - - weight associated with matching the corresponding podAffinityTerm, in the range 1-100. - -- **requiredDuringSchedulingIgnoredDuringExecution** ([]PodAffinityTerm) - - If the anti-affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the anti-affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node. When there are multiple elements, the lists of nodes corresponding to each podAffinityTerm are intersected, i.e. all terms must be satisfied. - - - *Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key matches that of any node on which a pod of the set of pods is running* - - - **requiredDuringSchedulingIgnoredDuringExecution.topologyKey** (string), required - - This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed. - - - **requiredDuringSchedulingIgnoredDuringExecution.labelSelector** (}}">LabelSelector) - - A label query over a set of resources, in this case pods. - - - **requiredDuringSchedulingIgnoredDuringExecution.namespaces** ([]string) - - namespaces specifies which namespaces the labelSelector applies to (matches against); null or empty list means "this pod's namespace" - - - - - diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/quantity.md b/content/en/docs/reference/kubernetes-api/common-definitions/quantity.md index c049cd40e4..45f909c5e7 100644 --- a/content/en/docs/reference/kubernetes-api/common-definitions/quantity.md +++ b/content/en/docs/reference/kubernetes-api/common-definitions/quantity.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "Quantity is a fixed-point representation of a number." title: "Quantity" -weight: 18 +weight: 10 +auto_generated: true --- + + `import "k8s.io/apimachinery/pkg/api/resource"` diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/resource-field-selector.md b/content/en/docs/reference/kubernetes-api/common-definitions/resource-field-selector.md index 85e7a9a814..76576bdb5d 100644 --- a/content/en/docs/reference/kubernetes-api/common-definitions/resource-field-selector.md +++ b/content/en/docs/reference/kubernetes-api/common-definitions/resource-field-selector.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "ResourceFieldSelector represents container resources (cpu, memory) and their output format." title: "ResourceFieldSelector" -weight: 19 +weight: 11 +auto_generated: true --- + + `import "k8s.io/api/core/v1"` diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/status.md b/content/en/docs/reference/kubernetes-api/common-definitions/status.md index 634e5068fb..d40a22d6da 100644 --- a/content/en/docs/reference/kubernetes-api/common-definitions/status.md +++ b/content/en/docs/reference/kubernetes-api/common-definitions/status.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "Status is a return value for calls that don't return other objects." title: "Status" -weight: 20 +weight: 12 +auto_generated: true --- + + `import "k8s.io/apimachinery/pkg/apis/meta/v1"` @@ -40,21 +52,21 @@ Status is a return value for calls that don't return other objects. *StatusCause provides more information about an api.Status failure, including cases when multiple errors are encountered.* - - **details.causes.field** (string) + - **details.causes.field** (string) - The field of the resource that has caused this error, as named by its JSON serialization. May include dot and postfix notation for nested attributes. Arrays are zero-indexed. Fields may appear more than once in an array of causes due to fields having multiple errors. Optional. - - Examples: - "name" - the field "name" on the current resource - "items[0].name" - the field "name" on the first array entry in "items" + The field of the resource that has caused this error, as named by its JSON serialization. May include dot and postfix notation for nested attributes. Arrays are zero-indexed. Fields may appear more than once in an array of causes due to fields having multiple errors. Optional. + + Examples: + "name" - the field "name" on the current resource + "items[0].name" - the field "name" on the first array entry in "items" - - **details.causes.message** (string) + - **details.causes.message** (string) - A human-readable description of the cause of the error. This field may be presented as-is to a reader. + A human-readable description of the cause of the error. This field may be presented as-is to a reader. - - **details.causes.reason** (string) + - **details.causes.reason** (string) - A machine-readable description of the cause of the error. If this value is empty there is no information available. + A machine-readable description of the cause of the error. If this value is empty there is no information available. - **details.group** (string) diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/tcp-socket-action.md b/content/en/docs/reference/kubernetes-api/common-definitions/tcp-socket-action.md deleted file mode 100644 index 991518a57a..0000000000 --- a/content/en/docs/reference/kubernetes-api/common-definitions/tcp-socket-action.md +++ /dev/null @@ -1,35 +0,0 @@ ---- -api_metadata: - apiVersion: "" - import: "k8s.io/api/core/v1" - kind: "TCPSocketAction" -content_type: "api_reference" -description: "TCPSocketAction describes an action based on opening a socket." -title: "TCPSocketAction" -weight: 21 ---- - - - -`import "k8s.io/api/core/v1"` - - -TCPSocketAction describes an action based on opening a socket - -
- -- **port** (IntOrString), required - - Number or name of the port to access on the container. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. - - - *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* - -- **host** (string) - - Optional: Host name to connect to, defaults to the pod IP. - - - - - diff --git a/content/en/docs/reference/kubernetes-api/common-definitions/typed-local-object-reference.md b/content/en/docs/reference/kubernetes-api/common-definitions/typed-local-object-reference.md index c03c3c8409..a6d75abf25 100644 --- a/content/en/docs/reference/kubernetes-api/common-definitions/typed-local-object-reference.md +++ b/content/en/docs/reference/kubernetes-api/common-definitions/typed-local-object-reference.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "TypedLocalObjectReference contains enough information to let you locate the typed referenced object inside the same namespace." title: "TypedLocalObjectReference" -weight: 22 +weight: 13 +auto_generated: true --- + + `import "k8s.io/api/core/v1"` diff --git a/content/en/docs/reference/kubernetes-api/common-parameters/common-parameters.md b/content/en/docs/reference/kubernetes-api/common-parameters/common-parameters.md index 12792cbd08..45a90e0411 100644 --- a/content/en/docs/reference/kubernetes-api/common-parameters/common-parameters.md +++ b/content/en/docs/reference/kubernetes-api/common-parameters/common-parameters.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "" title: "Common Parameters" weight: 10 +auto_generated: true --- + + @@ -16,7 +28,7 @@ weight: 10 ## allowWatchBookmarks {#allowWatchBookmarks} -allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored. If the feature gate WatchBookmarks is not enabled in apiserver, this field is ignored. +allowWatchBookmarks requests watch events with type "BOOKMARK". Servers that do not implement bookmarks may ignore this flag and bookmarks are sent at the server's discretion. Clients should not assume bookmarks are returned at any specific interval, nor may they assume the server will send any BOOKMARK event during a session. If this is not a watch, this field is ignored.
diff --git a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/_index.md b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/_index.md index 4f29e8ec4f..aac30882a9 100644 --- a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/_index.md +++ b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/_index.md @@ -1,4 +1,17 @@ --- title: "Config and Storage Resources" weight: 3 +auto_generated: true --- + + + diff --git a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/config-map-v1.md b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/config-map-v1.md index b543e6c9ac..774f12ae97 100644 --- a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/config-map-v1.md +++ b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/config-map-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "ConfigMap holds configuration data for pods to consume." title: "ConfigMap" weight: 1 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` @@ -40,7 +52,7 @@ ConfigMap holds configuration data for pods to consume. - **immutable** (boolean) - Immutable, if set to true, ensures that data stored in the ConfigMap cannot be updated (only object metadata can be modified). If not set to true, the field can be modified at any time. Defaulted to nil. This is a beta field enabled by ImmutableEphemeralVolumes feature gate. + Immutable, if set to true, ensures that data stored in the ConfigMap cannot be updated (only object metadata can be modified). If not set to true, the field can be modified at any time. Defaulted to nil. @@ -402,6 +414,8 @@ PATCH /api/v1/namespaces/{namespace}/configmaps/{name} 200 (}}">ConfigMap): OK +201 (}}">ConfigMap): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/csi-driver-v1.md b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/csi-driver-v1.md index b1c634b6b2..db3a2a389b 100644 --- a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/csi-driver-v1.md +++ b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/csi-driver-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "CSIDriver captures information about a Container Storage Interface (CSI) volume driver deployed on the cluster." title: "CSIDriver" weight: 8 +auto_generated: true --- + + `apiVersion: storage.k8s.io/v1` `import "k8s.io/api/storage/v1"` @@ -47,25 +59,31 @@ CSIDriverSpec is the specification of a CSIDriver. - **attachRequired** (boolean) attachRequired indicates this CSI volume driver requires an attach operation (because it implements the CSI ControllerPublishVolume() method), and that the Kubernetes attach detach controller should call the attach volume interface which checks the volumeattachment status and waits until the volume is attached before proceeding to mounting. The CSI external-attacher coordinates with CSI volume driver and updates the volumeattachment status when the attach operation is complete. If the CSIDriverRegistry feature gate is enabled and the value is specified to false, the attach operation will be skipped. Otherwise the attach operation will be called. + + This field is immutable. - **fsGroupPolicy** (string) - Defines if the underlying volume supports changing ownership and permission of the volume before being mounted. Refer to the specific FSGroupPolicy values for additional details. This field is alpha-level, and is only honored by servers that enable the CSIVolumeFSGroupPolicy feature gate. + Defines if the underlying volume supports changing ownership and permission of the volume before being mounted. Refer to the specific FSGroupPolicy values for additional details. This field is beta, and is only honored by servers that enable the CSIVolumeFSGroupPolicy feature gate. + + This field is immutable. + + Defaults to ReadWriteOnceWithFSType, which will examine each volume to determine if Kubernetes should modify ownership and permissions of the volume. With the default policy the defined fsGroup will only be applied if a fstype is defined and the volume's access mode contains ReadWriteOnce. - **podInfoOnMount** (boolean) - If set to true, podInfoOnMount indicates this CSI volume driver requires additional pod information (like podName, podUID, etc.) during mount operations. If set to false, pod information will not be passed on mount. Default is false. The CSI driver specifies podInfoOnMount as part of driver deployment. If true, Kubelet will pass pod information as VolumeContext in the CSI NodePublishVolume() calls. The CSI driver is responsible for parsing and validating the information passed in as VolumeContext. The following VolumeConext will be passed if podInfoOnMount is set to true. This list might grow, but the prefix will be used. "csi.storage.k8s.io/pod.name": pod.Name "csi.storage.k8s.io/pod.namespace": pod.Namespace "csi.storage.k8s.io/pod.uid": string(pod.UID) "csi.storage.k8s.io/ephemeral": "true" iff the volume is an ephemeral inline volume + If set to true, podInfoOnMount indicates this CSI volume driver requires additional pod information (like podName, podUID, etc.) during mount operations. If set to false, pod information will not be passed on mount. Default is false. The CSI driver specifies podInfoOnMount as part of driver deployment. If true, Kubelet will pass pod information as VolumeContext in the CSI NodePublishVolume() calls. The CSI driver is responsible for parsing and validating the information passed in as VolumeContext. The following VolumeConext will be passed if podInfoOnMount is set to true. This list might grow, but the prefix will be used. "csi.storage.k8s.io/pod.name": pod.Name "csi.storage.k8s.io/pod.namespace": pod.Namespace "csi.storage.k8s.io/pod.uid": string(pod.UID) "csi.storage.k8s.io/ephemeral": "true" if the volume is an ephemeral inline volume defined by a CSIVolumeSource, otherwise "false" "csi.storage.k8s.io/ephemeral" is a new feature in Kubernetes 1.16. It is only required for drivers which support both the "Persistent" and "Ephemeral" VolumeLifecycleMode. Other drivers can leave pod info disabled and/or ignore this field. As Kubernetes 1.15 doesn't support this field, drivers can only support one mode when deployed on such a cluster and the deployment determines which mode that is, for example via a command line parameter of the driver. + + This field is immutable. - **requiresRepublish** (boolean) RequiresRepublish indicates the CSI driver wants `NodePublishVolume` being periodically called to reflect any possible change in the mounted volume. This field defaults to false. Note: After a successful initial NodePublishVolume call, subsequent calls to NodePublishVolume should only update the contents of the volume. New mount points will not be seen by a running container. - - This is an alpha feature and only available when the CSIServiceAccountToken feature is enabled. - **storageCapacity** (boolean) @@ -75,7 +93,9 @@ CSIDriverSpec is the specification of a CSIDriver. Alternatively, the driver can be deployed with the field unset or false and it can be flipped later when storage capacity information has been published. - This is an alpha field and only available when the CSIStorageCapacity feature is enabled. The default is false. + This field is immutable. + + This is a beta field and only available when the CSIStorageCapacity feature is enabled. The default is false. - **tokenRequests** ([]TokenRequest) @@ -90,8 +110,6 @@ CSIDriverSpec is the specification of a CSIDriver. } Note: Audience in each TokenRequest should be different and at most one token is empty string. To receive a new token after expiry, RequiresRepublish can be used to trigger NodePublishVolume periodically. - - This is an alpha feature and only available when the CSIServiceAccountToken feature is enabled. *TokenRequest contains parameters of a service account token.* @@ -109,6 +127,8 @@ CSIDriverSpec is the specification of a CSIDriver. *Set: unique values will be kept during a merge* volumeLifecycleModes defines what kind of volumes this CSI volume driver supports. The default if the list is empty is "Persistent", which is the usage defined by the CSI specification and implemented in Kubernetes via the usual PV/PVC mechanism. The other mode is "Ephemeral". In this mode, volumes are defined inline inside the pod spec with CSIVolumeSource and their lifecycle is tied to the lifecycle of that pod. A driver has to be aware of this because it is only going to get a NodePublishVolume call for such a volume. For more information about implementing this mode, see https://kubernetes-csi.github.io/docs/ephemeral-local-volumes.html A driver can support one or more of these modes and more modes may be added in the future. This field is beta. + + This field is immutable. @@ -377,6 +397,8 @@ PATCH /apis/storage.k8s.io/v1/csidrivers/{name} 200 (}}">CSIDriver): OK +201 (}}">CSIDriver): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/csi-node-v1.md b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/csi-node-v1.md index aaee041979..5eb65b7e54 100644 --- a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/csi-node-v1.md +++ b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/csi-node-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "CSINode holds information about all CSI drivers installed on a node." title: "CSINode" weight: 9 +auto_generated: true --- + + `apiVersion: storage.k8s.io/v1` `import "k8s.io/api/storage/v1"` @@ -68,9 +80,9 @@ CSINodeSpec holds information about the specification of all CSI drivers install *VolumeNodeResources is a set of resource limits for scheduling of volumes.* - - **drivers.allocatable.count** (int32) + - **drivers.allocatable.count** (int32) - Maximum number of unique volumes managed by the CSI driver that can be used on a node. A volume that is both attached and mounted on a node is considered to be used once, not twice. The same rule applies for a unique volume that is shared among multiple pods on the same node. If this field is not specified, then the supported number of volumes on this node is unbounded. + Maximum number of unique volumes managed by the CSI driver that can be used on a node. A volume that is both attached and mounted on a node is considered to be used once, not twice. The same rule applies for a unique volume that is shared among multiple pods on the same node. If this field is not specified, then the supported number of volumes on this node is unbounded. - **drivers.topologyKeys** ([]string) @@ -343,6 +355,8 @@ PATCH /apis/storage.k8s.io/v1/csinodes/{name} 200 (}}">CSINode): OK +201 (}}">CSINode): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/cron-job-v2alpha1.md b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/csi-storage-capacity-v1beta1.md similarity index 50% rename from content/en/docs/reference/kubernetes-api/workload-resources/cron-job-v2alpha1.md rename to content/en/docs/reference/kubernetes-api/config-and-storage-resources/csi-storage-capacity-v1beta1.md index fc6a933131..08c6572f89 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/cron-job-v2alpha1.md +++ b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/csi-storage-capacity-v1beta1.md @@ -1,136 +1,104 @@ --- api_metadata: - apiVersion: "batch/v2alpha1" - import: "k8s.io/api/batch/v2alpha1" - kind: "CronJob" + apiVersion: "storage.k8s.io/v1beta1" + import: "k8s.io/api/storage/v1beta1" + kind: "CSIStorageCapacity" content_type: "api_reference" -description: "CronJob represents the configuration of a single cron job." -title: "CronJob v2alpha1" -weight: 13 +description: "CSIStorageCapacity stores the result of one CSI GetCapacity call." +title: "CSIStorageCapacity v1beta1" +weight: 10 +auto_generated: true --- -`apiVersion: batch/v2alpha1` + -`import "k8s.io/api/batch/v2alpha1"` +`apiVersion: storage.k8s.io/v1beta1` + +`import "k8s.io/api/storage/v1beta1"` -## CronJob {#CronJob} +## CSIStorageCapacity {#CSIStorageCapacity} -CronJob represents the configuration of a single cron job. +CSIStorageCapacity stores the result of one CSI GetCapacity call. For a given StorageClass, this describes the available capacity in a particular topology segment. This can be used when considering where to instantiate new PersistentVolumes. + +For example this can express things like: - StorageClass "standard" has "1234 GiB" available in "topology.kubernetes.io/zone=us-east1" - StorageClass "localssd" has "10 GiB" available in "kubernetes.io/hostname=knode-abc123" + +The following three cases all imply that no capacity is available for a certain combination: - no object exists with suitable topology and storage class name - such an object exists, but the capacity is unset - such an object exists, but the capacity is zero + +The producer of these objects can decide which approach is more suitable. + +They are consumed by the kube-scheduler if the CSIStorageCapacity beta feature gate is enabled there and a CSI driver opts into capacity-aware scheduling with CSIDriver.StorageCapacity.
-- **apiVersion**: batch/v2alpha1 +- **apiVersion**: storage.k8s.io/v1beta1 -- **kind**: CronJob +- **kind**: CSIStorageCapacity - **metadata** (}}">ObjectMeta) - Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + Standard object's metadata. The name has no particular meaning. It must be be a DNS subdomain (dots allowed, 253 characters). To ensure that there are no conflicts with other CSI drivers on the cluster, the recommendation is to use csisc-\, a generated name, or a reverse-domain name which ends with the unique CSI driver name. + + Objects are namespaced. + + More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata -- **spec** (}}">CronJobSpec) +- **storageClassName** (string), required - Specification of the desired behavior of a cron job, including the schedule. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status + The name of the StorageClass that the reported capacity applies to. It must meet the same requirements as the name of a StorageClass object (non-empty, DNS subdomain). If that object no longer exists, the CSIStorageCapacity object is obsolete and should be removed by its creator. This field is immutable. -- **status** (}}">CronJobStatus) +- **capacity** (}}">Quantity) - Current status of a cron job. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status + Capacity is the value reported by the CSI driver in its GetCapacityResponse for a GetCapacityRequest with topology and parameters that match the previous fields. + + The semantic is currently (CSI spec 1.2) defined as: The available capacity, in bytes, of the storage that can be used to provision volumes. If not set, that information is currently unavailable and treated like zero capacity. + +- **maximumVolumeSize** (}}">Quantity) + + MaximumVolumeSize is the value reported by the CSI driver in its GetCapacityResponse for a GetCapacityRequest with topology and parameters that match the previous fields. + + This is defined since CSI spec 1.4.0 as the largest size that may be used in a CreateVolumeRequest.capacity_range.required_bytes field to create a volume with the same parameters as those in GetCapacityRequest. The corresponding value in the Kubernetes API is ResourceRequirements.Requests in a volume claim. + +- **nodeTopology** (}}">LabelSelector) + + NodeTopology defines which nodes have access to the storage for which capacity was reported. If not set, the storage is not accessible from any node in the cluster. If empty, the storage is accessible from all nodes. This field is immutable. -## CronJobSpec {#CronJobSpec} +## CSIStorageCapacityList {#CSIStorageCapacityList} -CronJobSpec describes how the job execution will look like and when it will actually run. +CSIStorageCapacityList is a collection of CSIStorageCapacity objects.
-- **jobTemplate** (JobTemplateSpec), required - - Specifies the job that will be created when executing a CronJob. - - - *JobTemplateSpec describes the data a Job should have when created from a template* - - - **jobTemplate.metadata** (}}">ObjectMeta) - - Standard object's metadata of the jobs created from this template. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - - - **jobTemplate.spec** (}}">JobSpec) - - Specification of the desired behavior of the job. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status - -- **schedule** (string), required - - The schedule in Cron format, see https://en.wikipedia.org/wiki/Cron. - -- **concurrencyPolicy** (string) - - Specifies how to treat concurrent executions of a Job. Valid values are: - "Allow" (default): allows CronJobs to run concurrently; - "Forbid": forbids concurrent runs, skipping next run if previous run hasn't finished yet; - "Replace": cancels currently running job and replaces it with a new one - -- **failedJobsHistoryLimit** (int32) - - The number of failed finished jobs to retain. This is a pointer to distinguish between explicit zero and not specified. - -- **startingDeadlineSeconds** (int64) - - Optional deadline in seconds for starting the job if it misses scheduled time for any reason. Missed jobs executions will be counted as failed ones. - -- **successfulJobsHistoryLimit** (int32) - - The number of successful finished jobs to retain. This is a pointer to distinguish between explicit zero and not specified. - -- **suspend** (boolean) - - This flag tells the controller to suspend subsequent executions, it does not apply to already started executions. Defaults to false. +- **apiVersion**: storage.k8s.io/v1beta1 - - - -## CronJobStatus {#CronJobStatus} - -CronJobStatus represents the current state of a cron job. - -
- -- **active** ([]}}">ObjectReference) - - A list of pointers to currently running jobs. - -- **lastScheduleTime** (Time) - - Information when was the last time the job was successfully scheduled. - - - *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* - - - - - -## CronJobList {#CronJobList} - -CronJobList is a collection of cron jobs. - -
- -- **apiVersion**: batch/v2alpha1 - - -- **kind**: CronJobList +- **kind**: CSIStorageCapacityList - **metadata** (}}">ListMeta) - Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + Standard list metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata -- **items** ([]}}">CronJob), required +- **items** ([]}}">CSIStorageCapacity), required - items is the list of CronJobs. + *Map: unique values on key name will be kept during a merge* + + Items is the list of CSIStorageCapacity objects. @@ -147,18 +115,18 @@ CronJobList is a collection of cron jobs. -### `get` read the specified CronJob +### `get` read the specified CSIStorageCapacity #### HTTP Request -GET /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name} +GET /apis/storage.k8s.io/v1beta1/namespaces/{namespace}/csistoragecapacities/{name} #### Parameters - **name** (*in path*): string, required - name of the CronJob + name of the CSIStorageCapacity - **namespace** (*in path*): string, required @@ -175,49 +143,16 @@ GET /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name} #### Response -200 (}}">CronJob): OK +200 (}}">CSIStorageCapacity): OK 401: Unauthorized -### `get` read status of the specified CronJob +### `list` list or watch objects of kind CSIStorageCapacity #### HTTP Request -GET /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name}/status - -#### Parameters - - -- **name** (*in path*): string, required - - name of the CronJob - - -- **namespace** (*in path*): string, required - - }}">namespace - - -- **pretty** (*in query*): string - - }}">pretty - - - -#### Response - - -200 (}}">CronJob): OK - -401: Unauthorized - - -### `list` list or watch objects of kind CronJob - -#### HTTP Request - -GET /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs +GET /apis/storage.k8s.io/v1beta1/namespaces/{namespace}/csistoragecapacities #### Parameters @@ -281,16 +216,16 @@ GET /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs #### Response -200 (}}">CronJobList): OK +200 (}}">CSIStorageCapacityList): OK 401: Unauthorized -### `list` list or watch objects of kind CronJob +### `list` list or watch objects of kind CSIStorageCapacity #### HTTP Request -GET /apis/batch/v2alpha1/cronjobs +GET /apis/storage.k8s.io/v1beta1/csistoragecapacities #### Parameters @@ -349,16 +284,16 @@ GET /apis/batch/v2alpha1/cronjobs #### Response -200 (}}">CronJobList): OK +200 (}}">CSIStorageCapacityList): OK 401: Unauthorized -### `create` create a CronJob +### `create` create a CSIStorageCapacity #### HTTP Request -POST /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs +POST /apis/storage.k8s.io/v1beta1/namespaces/{namespace}/csistoragecapacities #### Parameters @@ -368,7 +303,7 @@ POST /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs }}">namespace -- **body**: }}">CronJob, required +- **body**: }}">CSIStorageCapacity, required @@ -392,27 +327,27 @@ POST /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs #### Response -200 (}}">CronJob): OK +200 (}}">CSIStorageCapacity): OK -201 (}}">CronJob): Created +201 (}}">CSIStorageCapacity): Created -202 (}}">CronJob): Accepted +202 (}}">CSIStorageCapacity): Accepted 401: Unauthorized -### `update` replace the specified CronJob +### `update` replace the specified CSIStorageCapacity #### HTTP Request -PUT /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name} +PUT /apis/storage.k8s.io/v1beta1/namespaces/{namespace}/csistoragecapacities/{name} #### Parameters - **name** (*in path*): string, required - name of the CronJob + name of the CSIStorageCapacity - **namespace** (*in path*): string, required @@ -420,7 +355,7 @@ PUT /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name} }}">namespace -- **body**: }}">CronJob, required +- **body**: }}">CSIStorageCapacity, required @@ -444,75 +379,25 @@ PUT /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name} #### Response -200 (}}">CronJob): OK +200 (}}">CSIStorageCapacity): OK -201 (}}">CronJob): Created +201 (}}">CSIStorageCapacity): Created 401: Unauthorized -### `update` replace status of the specified CronJob +### `patch` partially update the specified CSIStorageCapacity #### HTTP Request -PUT /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name}/status +PATCH /apis/storage.k8s.io/v1beta1/namespaces/{namespace}/csistoragecapacities/{name} #### Parameters - **name** (*in path*): string, required - name of the CronJob - - -- **namespace** (*in path*): string, required - - }}">namespace - - -- **body**: }}">CronJob, required - - - - -- **dryRun** (*in query*): string - - }}">dryRun - - -- **fieldManager** (*in query*): string - - }}">fieldManager - - -- **pretty** (*in query*): string - - }}">pretty - - - -#### Response - - -200 (}}">CronJob): OK - -201 (}}">CronJob): Created - -401: Unauthorized - - -### `patch` partially update the specified CronJob - -#### HTTP Request - -PATCH /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name} - -#### Parameters - - -- **name** (*in path*): string, required - - name of the CronJob + name of the CSIStorageCapacity - **namespace** (*in path*): string, required @@ -549,76 +434,25 @@ PATCH /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name} #### Response -200 (}}">CronJob): OK +200 (}}">CSIStorageCapacity): OK + +201 (}}">CSIStorageCapacity): Created 401: Unauthorized -### `patch` partially update status of the specified CronJob +### `delete` delete a CSIStorageCapacity #### HTTP Request -PATCH /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name}/status +DELETE /apis/storage.k8s.io/v1beta1/namespaces/{namespace}/csistoragecapacities/{name} #### Parameters - **name** (*in path*): string, required - name of the CronJob - - -- **namespace** (*in path*): string, required - - }}">namespace - - -- **body**: }}">Patch, required - - - - -- **dryRun** (*in query*): string - - }}">dryRun - - -- **fieldManager** (*in query*): string - - }}">fieldManager - - -- **force** (*in query*): boolean - - }}">force - - -- **pretty** (*in query*): string - - }}">pretty - - - -#### Response - - -200 (}}">CronJob): OK - -401: Unauthorized - - -### `delete` delete a CronJob - -#### HTTP Request - -DELETE /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name} - -#### Parameters - - -- **name** (*in path*): string, required - - name of the CronJob + name of the CSIStorageCapacity - **namespace** (*in path*): string, required @@ -662,11 +496,11 @@ DELETE /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs/{name} 401: Unauthorized -### `deletecollection` delete collection of CronJob +### `deletecollection` delete collection of CSIStorageCapacity #### HTTP Request -DELETE /apis/batch/v2alpha1/namespaces/{namespace}/cronjobs +DELETE /apis/storage.k8s.io/v1beta1/namespaces/{namespace}/csistoragecapacities #### Parameters diff --git a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1.md b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1.md index 23b4f3214e..e1461951e8 100644 --- a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1.md +++ b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-claim-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "PersistentVolumeClaim is a user's request for and claim to a persistent volume." title: "PersistentVolumeClaim" weight: 4 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` @@ -65,11 +77,11 @@ PersistentVolumeClaimSpec describes the common attributes of storage devices and - **resources.limits** (map[string]}}">Quantity) - Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/ + Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ - **resources.requests** (map[string]}}">Quantity) - Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/ + Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ - **volumeName** (string) @@ -90,7 +102,16 @@ PersistentVolumeClaimSpec describes the common attributes of storage devices and - **dataSource** (}}">TypedLocalObjectReference) - This field can be used to specify either: * An existing VolumeSnapshot object (snapshot.storage.k8s.io/VolumeSnapshot) * An existing PVC (PersistentVolumeClaim) * An existing custom resource that implements data population (Alpha) In order to use custom resource types that implement data population, the AnyVolumeDataSource feature gate must be enabled. If the provisioner or an external controller can support the specified data source, it will create a new volume based on the contents of the specified data source. + This field can be used to specify either: * An existing VolumeSnapshot object (snapshot.storage.k8s.io/VolumeSnapshot) * An existing PVC (PersistentVolumeClaim) If the provisioner or an external controller can support the specified data source, it will create a new volume based on the contents of the specified data source. If the AnyVolumeDataSource feature gate is enabled, this field will always have the same contents as the DataSourceRef field. + +- **dataSourceRef** (}}">TypedLocalObjectReference) + + Specifies the object from which to populate the volume with data, if a non-empty volume is desired. This may be any local object from a non-empty API group (non core object) or a PersistentVolumeClaim object. When this field is specified, volume binding will only succeed if the type of the specified object matches some installed volume populator or dynamic provisioner. This field will replace the functionality of the DataSource field and as such if both fields are non-empty, they must have the same value. For backwards compatibility, both fields (DataSource and DataSourceRef) will be set to the same value automatically if one of them is empty and the other is non-empty. There are two important differences between DataSource and DataSourceRef: * While DataSource only allows two specific types of objects, DataSourceRef + allows any non-core object, as well as PersistentVolumeClaim objects. + * While DataSource ignores disallowed values (dropping them), DataSourceRef + preserves all values, and generates an error if a disallowed value is + specified. + (Alpha) Using this field requires the AnyVolumeDataSource feature gate to be enabled. @@ -592,6 +613,8 @@ PATCH /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name} 200 (}}">PersistentVolumeClaim): OK +201 (}}">PersistentVolumeClaim): Created + 401: Unauthorized @@ -645,6 +668,8 @@ PATCH /api/v1/namespaces/{namespace}/persistentvolumeclaims/{name}/status 200 (}}">PersistentVolumeClaim): OK +201 (}}">PersistentVolumeClaim): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1.md b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1.md index cbc4a613d5..86c689dc44 100644 --- a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1.md +++ b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "PersistentVolume (PV) is a storage resource provisioned by an administrator." title: "PersistentVolume" weight: 5 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` @@ -78,20 +90,20 @@ PersistentVolumeSpec is the specification of a persistent volume. *A node selector represents the union of the results of one or more label queries over a set of nodes; that is, it represents the OR of the selectors represented by the node selector terms.* - - **nodeAffinity.required.nodeSelectorTerms** ([]NodeSelectorTerm), required + - **nodeAffinity.required.nodeSelectorTerms** ([]NodeSelectorTerm), required - Required. A list of node selector terms. The terms are ORed. + Required. A list of node selector terms. The terms are ORed. - - *A null or empty node selector term matches no objects. The requirements of them are ANDed. The TopologySelectorTerm type implements a subset of the NodeSelectorTerm.* + + *A null or empty node selector term matches no objects. The requirements of them are ANDed. The TopologySelectorTerm type implements a subset of the NodeSelectorTerm.* - - **nodeAffinity.required.nodeSelectorTerms.matchExpressions** ([]}}">NodeSelectorRequirement) + - **nodeAffinity.required.nodeSelectorTerms.matchExpressions** ([]}}">NodeSelectorRequirement) - A list of node selector requirements by node's labels. + A list of node selector requirements by node's labels. - - **nodeAffinity.required.nodeSelectorTerms.matchFields** ([]}}">NodeSelectorRequirement) + - **nodeAffinity.required.nodeSelectorTerms.matchFields** ([]}}">NodeSelectorRequirement) - A list of node selector requirements by node's fields. + A list of node selector requirements by node's fields. - **persistentVolumeReclaimPolicy** (string) @@ -252,13 +264,13 @@ PersistentVolumeSpec is the specification of a persistent volume. *SecretReference represents a Secret Reference. It has enough information to retrieve secret in any namespace* - - **cephfs.secretRef.name** (string) + - **cephfs.secretRef.name** (string) - Name is unique within a namespace to reference a secret resource. + Name is unique within a namespace to reference a secret resource. - - **cephfs.secretRef.namespace** (string) + - **cephfs.secretRef.namespace** (string) - Namespace defines the space within which the secret name must be unique. + Namespace defines the space within which the secret name must be unique. - **cephfs.user** (string) @@ -290,13 +302,100 @@ PersistentVolumeSpec is the specification of a persistent volume. *SecretReference represents a Secret Reference. It has enough information to retrieve secret in any namespace* - - **cinder.secretRef.name** (string) + - **cinder.secretRef.name** (string) - Name is unique within a namespace to reference a secret resource. + Name is unique within a namespace to reference a secret resource. - - **cinder.secretRef.namespace** (string) + - **cinder.secretRef.namespace** (string) - Namespace defines the space within which the secret name must be unique. + Namespace defines the space within which the secret name must be unique. + +- **csi** (CSIPersistentVolumeSource) + + CSI represents storage that is handled by an external CSI driver (Beta feature). + + + *Represents storage that is managed by an external CSI volume driver (Beta feature)* + + - **csi.driver** (string), required + + Driver is the name of the driver to use for this volume. Required. + + - **csi.volumeHandle** (string), required + + VolumeHandle is the unique volume name returned by the CSI volume plugin’s CreateVolume to refer to the volume on all subsequent calls. Required. + + - **csi.controllerExpandSecretRef** (SecretReference) + + ControllerExpandSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI ControllerExpandVolume call. This is an alpha field and requires enabling ExpandCSIVolumes feature gate. This field is optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secrets are passed. + + + *SecretReference represents a Secret Reference. It has enough information to retrieve secret in any namespace* + + - **csi.controllerExpandSecretRef.name** (string) + + Name is unique within a namespace to reference a secret resource. + + - **csi.controllerExpandSecretRef.namespace** (string) + + Namespace defines the space within which the secret name must be unique. + + - **csi.controllerPublishSecretRef** (SecretReference) + + ControllerPublishSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI ControllerPublishVolume and ControllerUnpublishVolume calls. This field is optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secrets are passed. + + + *SecretReference represents a Secret Reference. It has enough information to retrieve secret in any namespace* + + - **csi.controllerPublishSecretRef.name** (string) + + Name is unique within a namespace to reference a secret resource. + + - **csi.controllerPublishSecretRef.namespace** (string) + + Namespace defines the space within which the secret name must be unique. + + - **csi.fsType** (string) + + Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. "ext4", "xfs", "ntfs". + + - **csi.nodePublishSecretRef** (SecretReference) + + NodePublishSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI NodePublishVolume and NodeUnpublishVolume calls. This field is optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secrets are passed. + + + *SecretReference represents a Secret Reference. It has enough information to retrieve secret in any namespace* + + - **csi.nodePublishSecretRef.name** (string) + + Name is unique within a namespace to reference a secret resource. + + - **csi.nodePublishSecretRef.namespace** (string) + + Namespace defines the space within which the secret name must be unique. + + - **csi.nodeStageSecretRef** (SecretReference) + + NodeStageSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI NodeStageVolume and NodeStageVolume and NodeUnstageVolume calls. This field is optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secrets are passed. + + + *SecretReference represents a Secret Reference. It has enough information to retrieve secret in any namespace* + + - **csi.nodeStageSecretRef.name** (string) + + Name is unique within a namespace to reference a secret resource. + + - **csi.nodeStageSecretRef.namespace** (string) + + Namespace defines the space within which the secret name must be unique. + + - **csi.readOnly** (boolean) + + Optional: The value to pass to ControllerPublishVolumeRequest. Defaults to false (read/write). + + - **csi.volumeAttributes** (map[string]string) + + Attributes of the volume to publish. - **fc** (FCVolumeSource) @@ -355,13 +454,13 @@ PersistentVolumeSpec is the specification of a persistent volume. *SecretReference represents a Secret Reference. It has enough information to retrieve secret in any namespace* - - **flexVolume.secretRef.name** (string) + - **flexVolume.secretRef.name** (string) - Name is unique within a namespace to reference a secret resource. + Name is unique within a namespace to reference a secret resource. - - **flexVolume.secretRef.namespace** (string) + - **flexVolume.secretRef.namespace** (string) - Namespace defines the space within which the secret name must be unique. + Namespace defines the space within which the secret name must be unique. - **flocker** (FlockerVolumeSource) @@ -480,13 +579,13 @@ PersistentVolumeSpec is the specification of a persistent volume. *SecretReference represents a Secret Reference. It has enough information to retrieve secret in any namespace* - - **iscsi.secretRef.name** (string) + - **iscsi.secretRef.name** (string) - Name is unique within a namespace to reference a secret resource. + Name is unique within a namespace to reference a secret resource. - - **iscsi.secretRef.namespace** (string) + - **iscsi.secretRef.namespace** (string) - Namespace defines the space within which the secret name must be unique. + Namespace defines the space within which the secret name must be unique. - **nfs** (NFSVolumeSource) @@ -610,13 +709,13 @@ PersistentVolumeSpec is the specification of a persistent volume. *SecretReference represents a Secret Reference. It has enough information to retrieve secret in any namespace* - - **rbd.secretRef.name** (string) + - **rbd.secretRef.name** (string) - Name is unique within a namespace to reference a secret resource. + Name is unique within a namespace to reference a secret resource. - - **rbd.secretRef.namespace** (string) + - **rbd.secretRef.namespace** (string) - Namespace defines the space within which the secret name must be unique. + Namespace defines the space within which the secret name must be unique. - **rbd.user** (string) @@ -640,13 +739,13 @@ PersistentVolumeSpec is the specification of a persistent volume. *SecretReference represents a Secret Reference. It has enough information to retrieve secret in any namespace* - - **scaleIO.secretRef.name** (string) + - **scaleIO.secretRef.name** (string) - Name is unique within a namespace to reference a secret resource. + Name is unique within a namespace to reference a secret resource. - - **scaleIO.secretRef.namespace** (string) + - **scaleIO.secretRef.namespace** (string) - Namespace defines the space within which the secret name must be unique. + Namespace defines the space within which the secret name must be unique. - **scaleIO.system** (string), required @@ -730,96 +829,6 @@ PersistentVolumeSpec is the specification of a persistent volume. Storage Policy Based Management (SPBM) profile name. -### Beta level - - -- **csi** (CSIPersistentVolumeSource) - - CSI represents storage that is handled by an external CSI driver (Beta feature). - - - *Represents storage that is managed by an external CSI volume driver (Beta feature)* - - - **csi.driver** (string), required - - Driver is the name of the driver to use for this volume. Required. - - - **csi.volumeHandle** (string), required - - VolumeHandle is the unique volume name returned by the CSI volume plugin’s CreateVolume to refer to the volume on all subsequent calls. Required. - - - **csi.controllerExpandSecretRef** (SecretReference) - - ControllerExpandSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI ControllerExpandVolume call. This is an alpha field and requires enabling ExpandCSIVolumes feature gate. This field is optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secrets are passed. - - - *SecretReference represents a Secret Reference. It has enough information to retrieve secret in any namespace* - - - **csi.controllerExpandSecretRef.name** (string) - - Name is unique within a namespace to reference a secret resource. - - - **csi.controllerExpandSecretRef.namespace** (string) - - Namespace defines the space within which the secret name must be unique. - - - **csi.controllerPublishSecretRef** (SecretReference) - - ControllerPublishSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI ControllerPublishVolume and ControllerUnpublishVolume calls. This field is optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secrets are passed. - - - *SecretReference represents a Secret Reference. It has enough information to retrieve secret in any namespace* - - - **csi.controllerPublishSecretRef.name** (string) - - Name is unique within a namespace to reference a secret resource. - - - **csi.controllerPublishSecretRef.namespace** (string) - - Namespace defines the space within which the secret name must be unique. - - - **csi.fsType** (string) - - Filesystem type to mount. Must be a filesystem type supported by the host operating system. Ex. "ext4", "xfs", "ntfs". - - - **csi.nodePublishSecretRef** (SecretReference) - - NodePublishSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI NodePublishVolume and NodeUnpublishVolume calls. This field is optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secrets are passed. - - - *SecretReference represents a Secret Reference. It has enough information to retrieve secret in any namespace* - - - **csi.nodePublishSecretRef.name** (string) - - Name is unique within a namespace to reference a secret resource. - - - **csi.nodePublishSecretRef.namespace** (string) - - Namespace defines the space within which the secret name must be unique. - - - **csi.nodeStageSecretRef** (SecretReference) - - NodeStageSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI NodeStageVolume and NodeStageVolume and NodeUnstageVolume calls. This field is optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secrets are passed. - - - *SecretReference represents a Secret Reference. It has enough information to retrieve secret in any namespace* - - - **csi.nodeStageSecretRef.name** (string) - - Name is unique within a namespace to reference a secret resource. - - - **csi.nodeStageSecretRef.namespace** (string) - - Namespace defines the space within which the secret name must be unique. - - - **csi.readOnly** (boolean) - - Optional: The value to pass to ControllerPublishVolumeRequest. Defaults to false (read/write). - - - **csi.volumeAttributes** (map[string]string) - - Attributes of the volume to publish. - ## PersistentVolumeStatus {#PersistentVolumeStatus} @@ -1180,6 +1189,8 @@ PATCH /api/v1/persistentvolumes/{name} 200 (}}">PersistentVolume): OK +201 (}}">PersistentVolume): Created + 401: Unauthorized @@ -1228,6 +1239,8 @@ PATCH /api/v1/persistentvolumes/{name}/status 200 (}}">PersistentVolume): OK +201 (}}">PersistentVolume): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1.md b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1.md index 84d9a08c0f..bb2710e4c8 100644 --- a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1.md +++ b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "Secret holds secret data of a certain type." title: "Secret" weight: 2 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` @@ -36,11 +48,11 @@ Secret holds secret data of a certain type. The total bytes of the values in the - **immutable** (boolean) - Immutable, if set to true, ensures that data stored in the Secret cannot be updated (only object metadata can be modified). If not set to true, the field can be modified at any time. Defaulted to nil. This is a beta field enabled by ImmutableEphemeralVolumes feature gate. + Immutable, if set to true, ensures that data stored in the Secret cannot be updated (only object metadata can be modified). If not set to true, the field can be modified at any time. Defaulted to nil. - **stringData** (map[string]string) - stringData allows specifying non-binary secret data in string form. It is provided as a write-only convenience method. All keys and values are merged into the data field on write, overwriting any existing values. It is never output when reading from the API. + stringData allows specifying non-binary secret data in string form. It is provided as a write-only input field for convenience. All keys and values are merged into the data field on write, overwriting any existing values. The stringData field is never output when reading from the API. - **type** (string) @@ -406,6 +418,8 @@ PATCH /api/v1/namespaces/{namespace}/secrets/{name} 200 (}}">Secret): OK +201 (}}">Secret): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/storage-class-v1.md b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/storage-class-v1.md index 752735f6f6..e5cb3b4b3e 100644 --- a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/storage-class-v1.md +++ b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/storage-class-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "StorageClass describes the parameters for a class of storage for which PersistentVolumes can be dynamically provisioned." title: "StorageClass" weight: 6 +auto_generated: true --- + + `apiVersion: storage.k8s.io/v1` `import "k8s.io/api/storage/v1"` @@ -42,6 +54,8 @@ StorageClasses are non-namespaced; the name of the storage class according to et - **allowedTopologies** ([]TopologySelectorTerm) + *Atomic: will be replaced during a merge* + Restrict the node topologies where volumes can be dynamically provisioned. Each volume plugin defines its own supported topology specifications. An empty TopologySelectorTerm list means there is no topology restriction. This field is only honored by servers that enable the VolumeScheduling feature. @@ -54,13 +68,13 @@ StorageClasses are non-namespaced; the name of the storage class according to et *A topology selector requirement is a selector that matches given label. This is an alpha feature and may change in the future.* - - **allowedTopologies.matchLabelExpressions.key** (string), required + - **allowedTopologies.matchLabelExpressions.key** (string), required - The label key that the selector applies to. + The label key that the selector applies to. - - **allowedTopologies.matchLabelExpressions.values** ([]string), required + - **allowedTopologies.matchLabelExpressions.values** ([]string), required - An array of string values. One value must match the label to be selected. Each entry in Values is ORed. + An array of string values. One value must match the label to be selected. Each entry in Values is ORed. - **mountOptions** ([]string) @@ -345,6 +359,8 @@ PATCH /apis/storage.k8s.io/v1/storageclasses/{name} 200 (}}">StorageClass): OK +201 (}}">StorageClass): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/volume-attachment-v1.md b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/volume-attachment-v1.md index 95102c3988..332053b4a9 100644 --- a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/volume-attachment-v1.md +++ b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/volume-attachment-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "VolumeAttachment captures the intent to attach or detach the specified volume to/from the specified node." title: "VolumeAttachment" weight: 7 +auto_generated: true --- + + `apiVersion: storage.k8s.io/v1` `import "k8s.io/api/storage/v1"` @@ -67,7 +79,7 @@ VolumeAttachmentSpec is the specification of a VolumeAttachment request. - **source.inlineVolumeSpec** (}}">PersistentVolumeSpec) - inlineVolumeSpec contains all the information necessary to attach a persistent volume defined by a pod's inline VolumeSource. This field is populated only for the CSIMigration feature. It contains translated fields from a pod's inline VolumeSource to a PersistentVolumeSpec. This field is alpha-level and is only honored by servers that enabled the CSIMigration feature. + inlineVolumeSpec contains all the information necessary to attach a persistent volume defined by a pod's inline VolumeSource. This field is populated only for the CSIMigration feature. It contains translated fields from a pod's inline VolumeSource to a PersistentVolumeSpec. This field is beta-level and is only honored by servers that enabled the CSIMigration feature. - **source.persistentVolumeName** (string) @@ -467,6 +479,8 @@ PATCH /apis/storage.k8s.io/v1/volumeattachments/{name} 200 (}}">VolumeAttachment): OK +201 (}}">VolumeAttachment): Created + 401: Unauthorized @@ -515,6 +529,8 @@ PATCH /apis/storage.k8s.io/v1/volumeattachments/{name}/status 200 (}}">VolumeAttachment): OK +201 (}}">VolumeAttachment): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/volume.md b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/volume.md index ff45652ace..60badecc43 100644 --- a/content/en/docs/reference/kubernetes-api/config-and-storage-resources/volume.md +++ b/content/en/docs/reference/kubernetes-api/config-and-storage-resources/volume.md @@ -7,13 +7,27 @@ content_type: "api_reference" description: "Volume represents a named volume in a pod that may be accessed by any container in the pod." title: "Volume" weight: 3 +auto_generated: true --- + + `import "k8s.io/api/core/v1"` +## Volume {#Volume} + Volume represents a named volume in a pod that may be accessed by any container in the pod.
@@ -24,7 +38,7 @@ Volume represents a named volume in a pod that may be accessed by any container -### Exposed Persistent volumes {#Exposed-Persistent-volumes} +### Exposed Persistent volumes - **persistentVolumeClaim** (PersistentVolumeClaimVolumeSource) @@ -42,7 +56,7 @@ Volume represents a named volume in a pod that may be accessed by any container Will force the ReadOnly setting in VolumeMounts. Default false. -### Projections {#Projections} +### Projections - **configMap** (ConfigMapVolumeSource) @@ -66,7 +80,7 @@ Volume represents a named volume in a pod that may be accessed by any container Optional: mode bits used to set permissions on created files by default. Must be an octal value between 0000 and 0777 or a decimal value between 0 and 511. YAML accepts both octal and decimal values, JSON requires decimal values for mode bits. Defaults to 0644. Directories within the path are not affected by this setting. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set. - - **configMap.items** ([]}}">KeyToPath) + - **configMap.items** ([]}}">KeyToPath) If unspecified, each key-value pair in the Data field of the referenced ConfigMap will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the ConfigMap, the volume setup will error unless it is marked optional. Paths must be relative and may not contain the '..' path or start with '..'. @@ -91,7 +105,7 @@ Volume represents a named volume in a pod that may be accessed by any container Optional: mode bits used to set permissions on created files by default. Must be an octal value between 0000 and 0777 or a decimal value between 0 and 511. YAML accepts both octal and decimal values, JSON requires decimal values for mode bits. Defaults to 0644. Directories within the path are not affected by this setting. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set. - - **secret.items** ([]}}">KeyToPath) + - **secret.items** ([]}}">KeyToPath) If unspecified, each key-value pair in the Data field of the referenced Secret will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the Secret, the volume setup will error unless it is marked optional. Paths must be relative and may not contain the '..' path or start with '..'. @@ -106,7 +120,7 @@ Volume represents a named volume in a pod that may be accessed by any container Optional: mode bits to use on created files by default. Must be a Optional: mode bits used to set permissions on created files by default. Must be an octal value between 0000 and 0777 or a decimal value between 0 and 511. YAML accepts both octal and decimal values, JSON requires decimal values for mode bits. Defaults to 0644. Directories within the path are not affected by this setting. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set. - - **downwardAPI.items** ([]}}">DownwardAPIVolumeFile) + - **downwardAPI.items** ([]}}">DownwardAPIVolumeFile) Items is a list of downward API volume file @@ -128,79 +142,79 @@ Volume represents a named volume in a pod that may be accessed by any container *Projection that may be projected along with other supported volume types* - - **projected.sources.configMap** (ConfigMapProjection) + - **projected.sources.configMap** (ConfigMapProjection) - information about the configMap data to project + information about the configMap data to project - - *Adapts a ConfigMap into a projected volume. - - The contents of the target ConfigMap's Data field will be presented in a projected volume as files using the keys in the Data field as the file names, unless the items element is populated with specific mappings of keys to paths. Note that this is identical to a configmap volume source without the default mode.* + + *Adapts a ConfigMap into a projected volume. + + The contents of the target ConfigMap's Data field will be presented in a projected volume as files using the keys in the Data field as the file names, unless the items element is populated with specific mappings of keys to paths. Note that this is identical to a configmap volume source without the default mode.* - - **projected.sources.configMap.name** (string) + - **projected.sources.configMap.name** (string) - Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names + Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names - - **projected.sources.configMap.optional** (boolean) + - **projected.sources.configMap.optional** (boolean) - Specify whether the ConfigMap or its keys must be defined + Specify whether the ConfigMap or its keys must be defined - - **projected.sources.configMap.items** ([]}}">KeyToPath) + - **projected.sources.configMap.items** ([]}}">KeyToPath) - If unspecified, each key-value pair in the Data field of the referenced ConfigMap will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the ConfigMap, the volume setup will error unless it is marked optional. Paths must be relative and may not contain the '..' path or start with '..'. + If unspecified, each key-value pair in the Data field of the referenced ConfigMap will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the ConfigMap, the volume setup will error unless it is marked optional. Paths must be relative and may not contain the '..' path or start with '..'. - - **projected.sources.downwardAPI** (DownwardAPIProjection) + - **projected.sources.downwardAPI** (DownwardAPIProjection) - information about the downwardAPI data to project + information about the downwardAPI data to project - - *Represents downward API info for projecting into a projected volume. Note that this is identical to a downwardAPI volume source without the default mode.* + + *Represents downward API info for projecting into a projected volume. Note that this is identical to a downwardAPI volume source without the default mode.* - - **projected.sources.downwardAPI.items** ([]}}">DownwardAPIVolumeFile) + - **projected.sources.downwardAPI.items** ([]}}">DownwardAPIVolumeFile) - Items is a list of DownwardAPIVolume file + Items is a list of DownwardAPIVolume file - - **projected.sources.secret** (SecretProjection) + - **projected.sources.secret** (SecretProjection) - information about the secret data to project + information about the secret data to project - - *Adapts a secret into a projected volume. - - The contents of the target Secret's Data field will be presented in a projected volume as files using the keys in the Data field as the file names. Note that this is identical to a secret volume source without the default mode.* + + *Adapts a secret into a projected volume. + + The contents of the target Secret's Data field will be presented in a projected volume as files using the keys in the Data field as the file names. Note that this is identical to a secret volume source without the default mode.* - - **projected.sources.secret.name** (string) + - **projected.sources.secret.name** (string) - Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names + Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names - - **projected.sources.secret.optional** (boolean) + - **projected.sources.secret.optional** (boolean) - Specify whether the Secret or its key must be defined + Specify whether the Secret or its key must be defined - - **projected.sources.secret.items** ([]}}">KeyToPath) + - **projected.sources.secret.items** ([]}}">KeyToPath) - If unspecified, each key-value pair in the Data field of the referenced Secret will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the Secret, the volume setup will error unless it is marked optional. Paths must be relative and may not contain the '..' path or start with '..'. + If unspecified, each key-value pair in the Data field of the referenced Secret will be projected into the volume as a file whose name is the key and content is the value. If specified, the listed keys will be projected into the specified paths, and unlisted keys will not be present. If a key is specified which is not present in the Secret, the volume setup will error unless it is marked optional. Paths must be relative and may not contain the '..' path or start with '..'. - - **projected.sources.serviceAccountToken** (ServiceAccountTokenProjection) + - **projected.sources.serviceAccountToken** (ServiceAccountTokenProjection) - information about the serviceAccountToken data to project + information about the serviceAccountToken data to project - - *ServiceAccountTokenProjection represents a projected service account token volume. This projection can be used to insert a service account token into the pods runtime filesystem for use against APIs (Kubernetes API Server or otherwise).* + + *ServiceAccountTokenProjection represents a projected service account token volume. This projection can be used to insert a service account token into the pods runtime filesystem for use against APIs (Kubernetes API Server or otherwise).* - - **projected.sources.serviceAccountToken.path** (string), required + - **projected.sources.serviceAccountToken.path** (string), required - Path is the path relative to the mount point of the file to project the token into. + Path is the path relative to the mount point of the file to project the token into. - - **projected.sources.serviceAccountToken.audience** (string) + - **projected.sources.serviceAccountToken.audience** (string) - Audience is the intended audience of the token. A recipient of a token must identify itself with an identifier specified in the audience of the token, and otherwise should reject the token. The audience defaults to the identifier of the apiserver. + Audience is the intended audience of the token. A recipient of a token must identify itself with an identifier specified in the audience of the token, and otherwise should reject the token. The audience defaults to the identifier of the apiserver. - - **projected.sources.serviceAccountToken.expirationSeconds** (int64) + - **projected.sources.serviceAccountToken.expirationSeconds** (int64) - ExpirationSeconds is the requested duration of validity of the service account token. As the token approaches expiration, the kubelet volume plugin will proactively rotate the service account token. The kubelet will start trying to rotate the token if the token is older than 80 percent of its time to live or if the token is older than 24 hours.Defaults to 1 hour and must be at least 10 minutes. + ExpirationSeconds is the requested duration of validity of the service account token. As the token approaches expiration, the kubelet volume plugin will proactively rotate the service account token. The kubelet will start trying to rotate the token if the token is older than 80 percent of its time to live or if the token is older than 24 hours.Defaults to 1 hour and must be at least 10 minutes. -### Local / Temporary Directory {#Local-Temporary-Directory} +### Local / Temporary Directory - **emptyDir** (EmptyDirVolumeSource) @@ -233,7 +247,7 @@ Volume represents a named volume in a pod that may be accessed by any container Type for HostPath Volume Defaults to "" More info: https://kubernetes.io/docs/concepts/storage/volumes#hostpath -### Persistent volumes {#Persistent-volumes} +### Persistent volumes - **awsElasticBlockStore** (AWSElasticBlockStoreVolumeSource) @@ -365,6 +379,33 @@ Volume represents a named volume in a pod that may be accessed by any container Optional: points to a secret object containing parameters used to connect to OpenStack. +- **csi** (CSIVolumeSource) + + CSI (Container Storage Interface) represents ephemeral storage that is handled by certain external CSI drivers (Beta feature). + + + *Represents a source location of a volume to mount, managed by an external CSI driver* + + - **csi.driver** (string), required + + Driver is the name of the CSI driver that handles this volume. Consult with your admin for the correct name as registered in the cluster. + + - **csi.fsType** (string) + + Filesystem type to mount. Ex. "ext4", "xfs", "ntfs". If not provided, the empty value is passed to the associated CSI driver which will determine the default filesystem to apply. + + - **csi.nodePublishSecretRef** (}}">LocalObjectReference) + + NodePublishSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI NodePublishVolume and NodeUnpublishVolume calls. This field is optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secret references are passed. + + - **csi.readOnly** (boolean) + + Specifies a read-only configuration for the volume. Defaults to false (read/write). + + - **csi.volumeAttributes** (map[string]string) + + VolumeAttributes stores driver-specific properties that are passed to the CSI driver. Consult your driver's documentation for supported values. + - **fc** (FCVolumeSource) FC represents a Fibre Channel resource that is attached to a kubelet's host machine and then exposed to the pod. @@ -749,42 +790,12 @@ Volume represents a named volume in a pod that may be accessed by any container Storage Policy Based Management (SPBM) profile name. -### Beta level {#Beta-level} - - -- **csi** (CSIVolumeSource) - - CSI (Container Storage Interface) represents ephemeral storage that is handled by certain external CSI drivers (Beta feature). - - - *Represents a source location of a volume to mount, managed by an external CSI driver* - - - **csi.driver** (string), required - - Driver is the name of the CSI driver that handles this volume. Consult with your admin for the correct name as registered in the cluster. - - - **csi.fsType** (string) - - Filesystem type to mount. Ex. "ext4", "xfs", "ntfs". If not provided, the empty value is passed to the associated CSI driver which will determine the default filesystem to apply. - - - **csi.nodePublishSecretRef** (}}">LocalObjectReference) - - NodePublishSecretRef is a reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI NodePublishVolume and NodeUnpublishVolume calls. This field is optional, and may be empty if no secret is required. If the secret object contains more than one secret, all secret references are passed. - - - **csi.readOnly** (boolean) - - Specifies a read-only configuration for the volume. Defaults to false (read/write). - - - **csi.volumeAttributes** (map[string]string) - - VolumeAttributes stores driver-specific properties that are passed to the CSI driver. Consult your driver's documentation for supported values. - -### Alpha level {#Alpha-level} +### Alpha level - **ephemeral** (EphemeralVolumeSource) - Ephemeral represents a volume that is handled by a cluster storage driver (Alpha feature). The volume's lifecycle is tied to the pod that defines it - it will be created before the pod starts, and deleted when the pod is removed. + Ephemeral represents a volume that is handled by a cluster storage driver. The volume's lifecycle is tied to the pod that defines it - it will be created before the pod starts, and deleted when the pod is removed. Use this if: a) the volume is only needed while the pod runs, b) features of normal volumes like restoring from snapshot or capacity tracking are needed, @@ -798,14 +809,12 @@ Volume represents a named volume in a pod that may be accessed by any container Use CSI for light-weight local ephemeral volumes if the CSI driver is meant to be used that way - see the documentation of the driver for more information. A pod can use both types of ephemeral volumes and persistent volumes at the same time. + + This is a beta feature and only available when the GenericEphemeralVolume feature gate is enabled. *Represents an ephemeral volume that is handled by a normal storage driver.* - - **ephemeral.readOnly** (boolean) - - Specifies a read-only configuration for the volume. Defaults to false (read/write). - - **ephemeral.volumeClaimTemplate** (PersistentVolumeClaimTemplate) Will be used to create a stand-alone PVC to provision the volume. The pod in which this EphemeralVolumeSource is embedded will be the owner of the PVC, i.e. the PVC will be deleted together with the pod. The name of the PVC will be `\-\` where `\` is the name from the `PodSpec.Volumes` array entry. Pod validation will reject the pod if the concatenated name is not valid for a PVC (for example, too long). @@ -819,15 +828,15 @@ Volume represents a named volume in a pod that may be accessed by any container *PersistentVolumeClaimTemplate is used to produce PersistentVolumeClaim objects as part of an EphemeralVolumeSource.* - - **ephemeral.volumeClaimTemplate.spec** (}}">PersistentVolumeClaimSpec), required + - **ephemeral.volumeClaimTemplate.spec** (}}">PersistentVolumeClaimSpec), required - The specification for the PersistentVolumeClaim. The entire content is copied unchanged into the PVC that gets created from this template. The same fields as in a PersistentVolumeClaim are also valid here. + The specification for the PersistentVolumeClaim. The entire content is copied unchanged into the PVC that gets created from this template. The same fields as in a PersistentVolumeClaim are also valid here. - - **ephemeral.volumeClaimTemplate.metadata** (}}">ObjectMeta) + - **ephemeral.volumeClaimTemplate.metadata** (}}">ObjectMeta) - May contain labels and annotations that will be copied into the PVC when creating it. No other fields are allowed and will be rejected during validation. + May contain labels and annotations that will be copied into the PVC when creating it. No other fields are allowed and will be rejected during validation. -### Deprecated {#Deprecated} +### Deprecated - **gitRepo** (GitRepoVolumeSource) @@ -853,3 +862,51 @@ Volume represents a named volume in a pod that may be accessed by any container +## DownwardAPIVolumeFile {#DownwardAPIVolumeFile} + +DownwardAPIVolumeFile represents information to create the file containing the pod field + +
+ +- **path** (string), required + + Required: Path is the relative path name of the file to be created. Must not be absolute or contain the '..' path. Must be utf-8 encoded. The first item of the relative path must not start with '..' + +- **fieldRef** (}}">ObjectFieldSelector) + + Required: Selects a field of the pod: only annotations, labels, name and namespace are supported. + +- **mode** (int32) + + Optional: mode bits used to set permissions on this file, must be an octal value between 0000 and 0777 or a decimal value between 0 and 511. YAML accepts both octal and decimal values, JSON requires decimal values for mode bits. If not specified, the volume defaultMode will be used. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set. + +- **resourceFieldRef** (}}">ResourceFieldSelector) + + Selects a resource of the container: only resources limits and requests (limits.cpu, limits.memory, requests.cpu and requests.memory) are currently supported. + + + + + +## KeyToPath {#KeyToPath} + +Maps a string key to a path within a volume. + +
+ +- **key** (string), required + + The key to project. + +- **path** (string), required + + The relative path of the file to map the key to. May not be an absolute path. May not contain the path element '..'. May not start with the string '..'. + +- **mode** (int32) + + Optional: mode bits used to set permissions on this file. Must be an octal value between 0000 and 0777 or a decimal value between 0 and 511. YAML accepts both octal and decimal values, JSON requires decimal values for mode bits. If not specified, the volume defaultMode will be used. This might be in conflict with other options that affect the file mode, like fsGroup, and the result can be other mode bits set. + + + + + diff --git a/content/en/docs/reference/kubernetes-api/extend-resources/_index.md b/content/en/docs/reference/kubernetes-api/extend-resources/_index.md index ce6d3d3e39..1886f6e26c 100644 --- a/content/en/docs/reference/kubernetes-api/extend-resources/_index.md +++ b/content/en/docs/reference/kubernetes-api/extend-resources/_index.md @@ -1,4 +1,17 @@ --- title: "Extend Resources" weight: 7 +auto_generated: true --- + + + diff --git a/content/en/docs/reference/kubernetes-api/extend-resources/custom-resource-definition-v1.md b/content/en/docs/reference/kubernetes-api/extend-resources/custom-resource-definition-v1.md index 8aa8ed0c78..89cb9687f6 100644 --- a/content/en/docs/reference/kubernetes-api/extend-resources/custom-resource-definition-v1.md +++ b/content/en/docs/reference/kubernetes-api/extend-resources/custom-resource-definition-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "CustomResourceDefinition represents a resource that should be exposed on the API server." title: "CustomResourceDefinition" weight: 1 +auto_generated: true --- + + `apiVersion: apiextensions.k8s.io/v1` `import "k8s.io/apiextensions-apiserver/pkg/apis/apiextensions/v1"` @@ -28,6 +40,7 @@ CustomResourceDefinition represents a resource that should be exposed on the API - **metadata** (}}">ObjectMeta) + Standard object's metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **spec** (}}">CustomResourceDefinitionSpec), required @@ -112,29 +125,29 @@ CustomResourceDefinitionSpec describes how a user wants their resource to appear *CustomResourceColumnDefinition specifies a column for server side printing.* - - **versions.additionalPrinterColumns.jsonPath** (string), required + - **versions.additionalPrinterColumns.jsonPath** (string), required - jsonPath is a simple JSON path (i.e. with array notation) which is evaluated against each custom resource to produce the value for this column. + jsonPath is a simple JSON path (i.e. with array notation) which is evaluated against each custom resource to produce the value for this column. - - **versions.additionalPrinterColumns.name** (string), required + - **versions.additionalPrinterColumns.name** (string), required - name is a human readable name for the column. + name is a human readable name for the column. - - **versions.additionalPrinterColumns.type** (string), required + - **versions.additionalPrinterColumns.type** (string), required - type is an OpenAPI type definition for this column. See https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types for details. + type is an OpenAPI type definition for this column. See https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types for details. - - **versions.additionalPrinterColumns.description** (string) + - **versions.additionalPrinterColumns.description** (string) - description is a human readable description of this column. + description is a human readable description of this column. - - **versions.additionalPrinterColumns.format** (string) + - **versions.additionalPrinterColumns.format** (string) - format is an optional OpenAPI type definition for this column. The 'name' format is applied to the primary identifier column to assist in clients identifying column is the resource name. See https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types for details. + format is an optional OpenAPI type definition for this column. The 'name' format is applied to the primary identifier column to assist in clients identifying column is the resource name. See https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md#data-types for details. - - **versions.additionalPrinterColumns.priority** (int32) + - **versions.additionalPrinterColumns.priority** (int32) - priority is an integer defining the relative importance of this column compared to others. Lower numbers are considered higher priority. Columns that may be omitted in limited space scenarios should be given a priority greater than 0. + priority is an integer defining the relative importance of this column compared to others. Lower numbers are considered higher priority. Columns that may be omitted in limited space scenarios should be given a priority greater than 0. - **versions.deprecated** (boolean) @@ -151,9 +164,9 @@ CustomResourceDefinitionSpec describes how a user wants their resource to appear *CustomResourceValidation is a list of validation methods for CustomResources.* - - **versions.schema.openAPIV3Schema** (}}">JSONSchemaProps) + - **versions.schema.openAPIV3Schema** (}}">JSONSchemaProps) - openAPIV3Schema is the OpenAPI v3 schema to use for validation and pruning. + openAPIV3Schema is the OpenAPI v3 schema to use for validation and pruning. - **versions.subresources** (CustomResourceSubresources) @@ -162,31 +175,31 @@ CustomResourceDefinitionSpec describes how a user wants their resource to appear *CustomResourceSubresources defines the status and scale subresources for CustomResources.* - - **versions.subresources.scale** (CustomResourceSubresourceScale) + - **versions.subresources.scale** (CustomResourceSubresourceScale) - scale indicates the custom resource should serve a `/scale` subresource that returns an `autoscaling/v1` Scale object. + scale indicates the custom resource should serve a `/scale` subresource that returns an `autoscaling/v1` Scale object. - - *CustomResourceSubresourceScale defines how to serve the scale subresource for CustomResources.* + + *CustomResourceSubresourceScale defines how to serve the scale subresource for CustomResources.* - - **versions.subresources.scale.specReplicasPath** (string), required + - **versions.subresources.scale.specReplicasPath** (string), required - specReplicasPath defines the JSON path inside of a custom resource that corresponds to Scale `spec.replicas`. Only JSON paths without the array notation are allowed. Must be a JSON Path under `.spec`. If there is no value under the given path in the custom resource, the `/scale` subresource will return an error on GET. + specReplicasPath defines the JSON path inside of a custom resource that corresponds to Scale `spec.replicas`. Only JSON paths without the array notation are allowed. Must be a JSON Path under `.spec`. If there is no value under the given path in the custom resource, the `/scale` subresource will return an error on GET. - - **versions.subresources.scale.statusReplicasPath** (string), required + - **versions.subresources.scale.statusReplicasPath** (string), required - statusReplicasPath defines the JSON path inside of a custom resource that corresponds to Scale `status.replicas`. Only JSON paths without the array notation are allowed. Must be a JSON Path under `.status`. If there is no value under the given path in the custom resource, the `status.replicas` value in the `/scale` subresource will default to 0. + statusReplicasPath defines the JSON path inside of a custom resource that corresponds to Scale `status.replicas`. Only JSON paths without the array notation are allowed. Must be a JSON Path under `.status`. If there is no value under the given path in the custom resource, the `status.replicas` value in the `/scale` subresource will default to 0. - - **versions.subresources.scale.labelSelectorPath** (string) + - **versions.subresources.scale.labelSelectorPath** (string) - labelSelectorPath defines the JSON path inside of a custom resource that corresponds to Scale `status.selector`. Only JSON paths without the array notation are allowed. Must be a JSON Path under `.status` or `.spec`. Must be set to work with HorizontalPodAutoscaler. The field pointed by this JSON path must be a string field (not a complex selector struct) which contains a serialized label selector in string form. More info: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions#scale-subresource If there is no value under the given path in the custom resource, the `status.selector` value in the `/scale` subresource will default to the empty string. + labelSelectorPath defines the JSON path inside of a custom resource that corresponds to Scale `status.selector`. Only JSON paths without the array notation are allowed. Must be a JSON Path under `.status` or `.spec`. Must be set to work with HorizontalPodAutoscaler. The field pointed by this JSON path must be a string field (not a complex selector struct) which contains a serialized label selector in string form. More info: https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions#scale-subresource If there is no value under the given path in the custom resource, the `status.selector` value in the `/scale` subresource will default to the empty string. - - **versions.subresources.status** (CustomResourceSubresourceStatus) + - **versions.subresources.status** (CustomResourceSubresourceStatus) - status indicates the custom resource should serve a `/status` subresource. When enabled: 1. requests to the custom resource primary endpoint ignore changes to the `status` stanza of the object. 2. requests to the custom resource `/status` subresource ignore changes to anything other than the `status` stanza of the object. + status indicates the custom resource should serve a `/status` subresource. When enabled: 1. requests to the custom resource primary endpoint ignore changes to the `status` stanza of the object. 2. requests to the custom resource `/status` subresource ignore changes to anything other than the `status` stanza of the object. - - *CustomResourceSubresourceStatus defines how to serve the status subresource for CustomResources. Status is represented by the `.status` JSON path inside of a CustomResource. When set, * exposes a /status subresource for the custom resource * PUT requests to the /status subresource take a custom resource object, and ignore changes to anything except the status stanza * PUT/POST/PATCH requests to the custom resource ignore changes to the status stanza* + + *CustomResourceSubresourceStatus defines how to serve the status subresource for CustomResources. Status is represented by the `.status` JSON path inside of a CustomResource. When set, * exposes a /status subresource for the custom resource * PUT requests to the /status subresource take a custom resource object, and ignore changes to anything except the status stanza * PUT/POST/PATCH requests to the custom resource ignore changes to the status stanza* - **conversion** (CustomResourceConversion) @@ -207,59 +220,59 @@ CustomResourceDefinitionSpec describes how a user wants their resource to appear *WebhookConversion describes how to call a conversion webhook* - - **conversion.webhook.conversionReviewVersions** ([]string), required + - **conversion.webhook.conversionReviewVersions** ([]string), required - conversionReviewVersions is an ordered list of preferred `ConversionReview` versions the Webhook expects. The API server will use the first version in the list which it supports. If none of the versions specified in this list are supported by API server, conversion will fail for the custom resource. If a persisted Webhook configuration specifies allowed versions and does not include any versions known to the API Server, calls to the webhook will fail. + conversionReviewVersions is an ordered list of preferred `ConversionReview` versions the Webhook expects. The API server will use the first version in the list which it supports. If none of the versions specified in this list are supported by API server, conversion will fail for the custom resource. If a persisted Webhook configuration specifies allowed versions and does not include any versions known to the API Server, calls to the webhook will fail. - - **conversion.webhook.clientConfig** (WebhookClientConfig) + - **conversion.webhook.clientConfig** (WebhookClientConfig) - clientConfig is the instructions for how to call the webhook if strategy is `Webhook`. + clientConfig is the instructions for how to call the webhook if strategy is `Webhook`. - - *WebhookClientConfig contains the information to make a TLS connection with the webhook.* + + *WebhookClientConfig contains the information to make a TLS connection with the webhook.* - - **conversion.webhook.clientConfig.caBundle** ([]byte) + - **conversion.webhook.clientConfig.caBundle** ([]byte) - caBundle is a PEM encoded CA bundle which will be used to validate the webhook's server certificate. If unspecified, system trust roots on the apiserver are used. + caBundle is a PEM encoded CA bundle which will be used to validate the webhook's server certificate. If unspecified, system trust roots on the apiserver are used. - - **conversion.webhook.clientConfig.service** (ServiceReference) + - **conversion.webhook.clientConfig.service** (ServiceReference) - service is a reference to the service for this webhook. Either service or url must be specified. - - If the webhook is running within the cluster, then you should use `service`. + service is a reference to the service for this webhook. Either service or url must be specified. + + If the webhook is running within the cluster, then you should use `service`. - - *ServiceReference holds a reference to Service.legacy.k8s.io* + + *ServiceReference holds a reference to Service.legacy.k8s.io* - - **conversion.webhook.clientConfig.service.name** (string), required + - **conversion.webhook.clientConfig.service.name** (string), required - name is the name of the service. Required + name is the name of the service. Required - - **conversion.webhook.clientConfig.service.namespace** (string), required + - **conversion.webhook.clientConfig.service.namespace** (string), required - namespace is the namespace of the service. Required + namespace is the namespace of the service. Required - - **conversion.webhook.clientConfig.service.path** (string) + - **conversion.webhook.clientConfig.service.path** (string) - path is an optional URL path at which the webhook will be contacted. + path is an optional URL path at which the webhook will be contacted. - - **conversion.webhook.clientConfig.service.port** (int32) + - **conversion.webhook.clientConfig.service.port** (int32) - port is an optional service port at which the webhook will be contacted. `port` should be a valid port number (1-65535, inclusive). Defaults to 443 for backward compatibility. + port is an optional service port at which the webhook will be contacted. `port` should be a valid port number (1-65535, inclusive). Defaults to 443 for backward compatibility. - - **conversion.webhook.clientConfig.url** (string) + - **conversion.webhook.clientConfig.url** (string) - url gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified. - - The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address. - - Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installations are likely to be non-portable or not readily run in a new cluster. - - The scheme must be "https"; the URL must begin with "https://". - - A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier. - - Attempting to use a user or basic auth e.g. "user:password@" is not allowed. Fragments ("#...") and query parameters ("?...") are not allowed, either. + url gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified. + + The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address. + + Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster. + + The scheme must be "https"; the URL must begin with "https://". + + A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier. + + Attempting to use a user or basic auth e.g. "user:password@" is not allowed. Fragments ("#...") and query parameters ("?...") are not allowed, either. - **preserveUnknownFields** (boolean) @@ -269,6 +282,218 @@ CustomResourceDefinitionSpec describes how a user wants their resource to appear +## JSONSchemaProps {#JSONSchemaProps} + +JSONSchemaProps is a JSON-Schema following Specification Draft 4 (http://json-schema.org/). + +
+ +- **$ref** (string) + + +- **$schema** (string) + + +- **additionalItems** (JSONSchemaPropsOrBool) + + + + *JSONSchemaPropsOrBool represents JSONSchemaProps or a boolean value. Defaults to true for the boolean property.* + +- **additionalProperties** (JSONSchemaPropsOrBool) + + + + *JSONSchemaPropsOrBool represents JSONSchemaProps or a boolean value. Defaults to true for the boolean property.* + +- **allOf** ([]}}">JSONSchemaProps) + + +- **anyOf** ([]}}">JSONSchemaProps) + + +- **default** (JSON) + + default is a default value for undefined object fields. Defaulting is a beta feature under the CustomResourceDefaulting feature gate. Defaulting requires spec.preserveUnknownFields to be false. + + + *JSON represents any valid JSON value. These types are supported: bool, int64, float64, string, []interface{}, map[string]interface{} and nil.* + +- **definitions** (map[string]}}">JSONSchemaProps) + + +- **dependencies** (map[string]JSONSchemaPropsOrStringArray) + + + + *JSONSchemaPropsOrStringArray represents a JSONSchemaProps or a string array.* + +- **description** (string) + + +- **enum** ([]JSON) + + + + *JSON represents any valid JSON value. These types are supported: bool, int64, float64, string, []interface{}, map[string]interface{} and nil.* + +- **example** (JSON) + + + + *JSON represents any valid JSON value. These types are supported: bool, int64, float64, string, []interface{}, map[string]interface{} and nil.* + +- **exclusiveMaximum** (boolean) + + +- **exclusiveMinimum** (boolean) + + +- **externalDocs** (ExternalDocumentation) + + + + *ExternalDocumentation allows referencing an external resource for extended documentation.* + + - **externalDocs.description** (string) + + + - **externalDocs.url** (string) + + +- **format** (string) + + format is an OpenAPI v3 format string. Unknown formats are ignored. The following formats are validated: + + - bsonobjectid: a bson object ID, i.e. a 24 characters hex string - uri: an URI as parsed by Golang net/url.ParseRequestURI - email: an email address as parsed by Golang net/mail.ParseAddress - hostname: a valid representation for an Internet host name, as defined by RFC 1034, section 3.1 [RFC1034]. - ipv4: an IPv4 IP as parsed by Golang net.ParseIP - ipv6: an IPv6 IP as parsed by Golang net.ParseIP - cidr: a CIDR as parsed by Golang net.ParseCIDR - mac: a MAC address as parsed by Golang net.ParseMAC - uuid: an UUID that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{4}-?[0-9a-f]{12}$ - uuid3: an UUID3 that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?3[0-9a-f]{3}-?[0-9a-f]{4}-?[0-9a-f]{12}$ - uuid4: an UUID4 that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?4[0-9a-f]{3}-?[89ab][0-9a-f]{3}-?[0-9a-f]{12}$ - uuid5: an UUID5 that allows uppercase defined by the regex (?i)^[0-9a-f]{8}-?[0-9a-f]{4}-?5[0-9a-f]{3}-?[89ab][0-9a-f]{3}-?[0-9a-f]{12}$ - isbn: an ISBN10 or ISBN13 number string like "0321751043" or "978-0321751041" - isbn10: an ISBN10 number string like "0321751043" - isbn13: an ISBN13 number string like "978-0321751041" - creditcard: a credit card number defined by the regex ^(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})$ with any non digit characters mixed in - ssn: a U.S. social security number following the regex ^\d{3}[- ]?\d{2}[- ]?\d{4}$ - hexcolor: an hexadecimal color code like "#FFFFFF: following the regex ^#?([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$ - rgbcolor: an RGB color code like rgb like "rgb(255,255,2559" - byte: base64 encoded binary data - password: any kind of string - date: a date string like "2006-01-02" as defined by full-date in RFC3339 - duration: a duration string like "22 ns" as parsed by Golang time.ParseDuration or compatible with Scala duration format - datetime: a date time string like "2014-12-15T19:30:20.000Z" as defined by date-time in RFC3339. + +- **id** (string) + + +- **items** (JSONSchemaPropsOrArray) + + + + *JSONSchemaPropsOrArray represents a value that can either be a JSONSchemaProps or an array of JSONSchemaProps. Mainly here for serialization purposes.* + +- **maxItems** (int64) + + +- **maxLength** (int64) + + +- **maxProperties** (int64) + + +- **maximum** (double) + + +- **minItems** (int64) + + +- **minLength** (int64) + + +- **minProperties** (int64) + + +- **minimum** (double) + + +- **multipleOf** (double) + + +- **not** (}}">JSONSchemaProps) + + +- **nullable** (boolean) + + +- **oneOf** ([]}}">JSONSchemaProps) + + +- **pattern** (string) + + +- **patternProperties** (map[string]}}">JSONSchemaProps) + + +- **properties** (map[string]}}">JSONSchemaProps) + + +- **required** ([]string) + + +- **title** (string) + + +- **type** (string) + + +- **uniqueItems** (boolean) + + +- **x-kubernetes-embedded-resource** (boolean) + + x-kubernetes-embedded-resource defines that the value is an embedded Kubernetes runtime.Object, with TypeMeta and ObjectMeta. The type must be object. It is allowed to further restrict the embedded object. kind, apiVersion and metadata are validated automatically. x-kubernetes-preserve-unknown-fields is allowed to be true, but does not have to be if the object is fully specified (up to kind, apiVersion, metadata). + +- **x-kubernetes-int-or-string** (boolean) + + x-kubernetes-int-or-string specifies that this value is either an integer or a string. If this is true, an empty type is allowed and type as child of anyOf is permitted if following one of the following patterns: + + 1) anyOf: + - type: integer + - type: string + 2) allOf: + - anyOf: + - type: integer + - type: string + - ... zero or more + +- **x-kubernetes-list-map-keys** ([]string) + + x-kubernetes-list-map-keys annotates an array with the x-kubernetes-list-type `map` by specifying the keys used as the index of the map. + + This tag MUST only be used on lists that have the "x-kubernetes-list-type" extension set to "map". Also, the values specified for this attribute must be a scalar typed field of the child structure (no nesting is supported). + + The properties specified must either be required or have a default value, to ensure those properties are present for all list items. + +- **x-kubernetes-list-type** (string) + + x-kubernetes-list-type annotates an array to further describe its topology. This extension must only be used on lists and may have 3 possible values: + + 1) `atomic`: the list is treated as a single entity, like a scalar. + Atomic lists will be entirely replaced when updated. This extension + may be used on any type of list (struct, scalar, ...). + 2) `set`: + Sets are lists that must not have multiple items with the same value. Each + value must be a scalar, an object with x-kubernetes-map-type `atomic` or an + array with x-kubernetes-list-type `atomic`. + 3) `map`: + These lists are like maps in that their elements have a non-index key + used to identify them. Order is preserved upon merge. The map tag + must only be used on a list with elements of type object. + Defaults to atomic for arrays. + +- **x-kubernetes-map-type** (string) + + x-kubernetes-map-type annotates an object to further describe its topology. This extension must only be used when type is object and may have 2 possible values: + + 1) `granular`: + These maps are actual maps (key-value pairs) and each fields are independent + from each other (they can each be manipulated by separate actors). This is + the default behaviour for all maps. + 2) `atomic`: the list is treated as a single entity, like a scalar. + Atomic maps will be entirely replaced when updated. + +- **x-kubernetes-preserve-unknown-fields** (boolean) + + x-kubernetes-preserve-unknown-fields stops the API server decoding step from pruning fields which are not specified in the validation schema. This affects fields recursively, but switches back to normal pruning behaviour if nested properties or additionalProperties are specified in the schema. This can either be true or undefined. False is forbidden. + + + + + ## CustomResourceDefinitionStatus {#CustomResourceDefinitionStatus} CustomResourceDefinitionStatus indicates the state of the CustomResourceDefinition @@ -308,6 +533,8 @@ CustomResourceDefinitionStatus indicates the state of the CustomResourceDefiniti - **conditions** ([]CustomResourceDefinitionCondition) + *Map: unique values on key type will be kept during a merge* + conditions indicate state for particular aspects of a CustomResourceDefinition @@ -350,19 +577,22 @@ CustomResourceDefinitionList is a list of CustomResourceDefinition objects.
-- **apiVersion**: apiextensions.k8s.io/v1 - - -- **kind**: CustomResourceDefinitionList - - -- **metadata** (}}">ListMeta) - - - **items** ([]}}">CustomResourceDefinition), required items list individual CustomResourceDefinition objects +- **apiVersion** (string) + + APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources + +- **kind** (string) + + Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds + +- **metadata** (}}">ListMeta) + + Standard object's metadata More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata + @@ -679,6 +909,8 @@ PATCH /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name} 200 (}}">CustomResourceDefinition): OK +201 (}}">CustomResourceDefinition): Created + 401: Unauthorized @@ -727,6 +959,8 @@ PATCH /apis/apiextensions.k8s.io/v1/customresourcedefinitions/{name}/status 200 (}}">CustomResourceDefinition): OK +201 (}}">CustomResourceDefinition): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/extend-resources/mutating-webhook-configuration-v1.md b/content/en/docs/reference/kubernetes-api/extend-resources/mutating-webhook-configuration-v1.md index 9e17c11ae3..499daa6405 100644 --- a/content/en/docs/reference/kubernetes-api/extend-resources/mutating-webhook-configuration-v1.md +++ b/content/en/docs/reference/kubernetes-api/extend-resources/mutating-webhook-configuration-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "MutatingWebhookConfiguration describes the configuration of and admission webhook that accept or reject and may change the object." title: "MutatingWebhookConfiguration" weight: 2 +auto_generated: true --- + + `apiVersion: admissionregistration.k8s.io/v1` `import "k8s.io/api/admissionregistration/v1"` @@ -50,48 +62,48 @@ MutatingWebhookConfiguration describes the configuration of and admission webhoo *WebhookClientConfig contains the information to make a TLS connection with the webhook* - - **webhooks.clientConfig.caBundle** ([]byte) + - **webhooks.clientConfig.caBundle** ([]byte) - `caBundle` is a PEM encoded CA bundle which will be used to validate the webhook's server certificate. If unspecified, system trust roots on the apiserver are used. + `caBundle` is a PEM encoded CA bundle which will be used to validate the webhook's server certificate. If unspecified, system trust roots on the apiserver are used. - - **webhooks.clientConfig.service** (ServiceReference) + - **webhooks.clientConfig.service** (ServiceReference) - `service` is a reference to the service for this webhook. Either `service` or `url` must be specified. - - If the webhook is running within the cluster, then you should use `service`. + `service` is a reference to the service for this webhook. Either `service` or `url` must be specified. + + If the webhook is running within the cluster, then you should use `service`. - - *ServiceReference holds a reference to Service.legacy.k8s.io* + + *ServiceReference holds a reference to Service.legacy.k8s.io* - - **webhooks.clientConfig.service.name** (string), required + - **webhooks.clientConfig.service.name** (string), required - `name` is the name of the service. Required + `name` is the name of the service. Required - - **webhooks.clientConfig.service.namespace** (string), required + - **webhooks.clientConfig.service.namespace** (string), required - `namespace` is the namespace of the service. Required + `namespace` is the namespace of the service. Required - - **webhooks.clientConfig.service.path** (string) + - **webhooks.clientConfig.service.path** (string) - `path` is an optional URL path which will be sent in any request to this service. + `path` is an optional URL path which will be sent in any request to this service. - - **webhooks.clientConfig.service.port** (int32) + - **webhooks.clientConfig.service.port** (int32) - If specified, the port on the service that hosting webhook. Default to 443 for backward compatibility. `port` should be a valid port number (1-65535, inclusive). + If specified, the port on the service that hosting webhook. Default to 443 for backward compatibility. `port` should be a valid port number (1-65535, inclusive). - - **webhooks.clientConfig.url** (string) + - **webhooks.clientConfig.url** (string) - `url` gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified. - - The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address. - - Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installations are likely to be non-portable or not readily run in a new cluster. - - The scheme must be "https"; the URL must begin with "https://". - - A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier. - - Attempting to use a user or basic auth e.g. "user:password@" is not allowed. Fragments ("#...") and query parameters ("?...") are not allowed, either. + `url` gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified. + + The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address. + + Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster. + + The scheme must be "https"; the URL must begin with "https://". + + A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier. + + Attempting to use a user or basic auth e.g. "user:password@" is not allowed. Fragments ("#...") and query parameters ("?...") are not allowed, either. - **webhooks.name** (string), required @@ -99,7 +111,7 @@ MutatingWebhookConfiguration describes the configuration of and admission webhoo - **webhooks.sideEffects** (string), required - SideEffects states whether this webhook has side effects. Acceptable values are: None, NoneOnDryRun (webhooks created via v1beta1 may also specify Some or Unknown). Webhooks with side effects MUST implement a reconciliation system, since a request may be rejected by a future step in the admission change and the side effects therefore need to be undone. Requests with the dryRun attribute will be auto-rejected if they match a webhook with sideEffects == Unknown or Some. + SideEffects states whether this webhook has side effects. Acceptable values are: None, NoneOnDryRun (webhooks created via v1beta1 may also specify Some or Unknown). Webhooks with side effects MUST implement a reconciliation system, since a request may be rejected by a future step in the admission chain and the side effects therefore need to be undone. Requests with the dryRun attribute will be auto-rejected if they match a webhook with sideEffects == Unknown or Some. - **webhooks.failurePolicy** (string) @@ -170,31 +182,31 @@ MutatingWebhookConfiguration describes the configuration of and admission webhoo *RuleWithOperations is a tuple of Operations and Resources. It is recommended to make sure that all the tuple expansions are valid.* - - **webhooks.rules.apiGroups** ([]string) + - **webhooks.rules.apiGroups** ([]string) - APIGroups is the API groups the resources belong to. '*' is all groups. If '*' is present, the length of the slice must be one. Required. + APIGroups is the API groups the resources belong to. '*' is all groups. If '*' is present, the length of the slice must be one. Required. - - **webhooks.rules.apiVersions** ([]string) + - **webhooks.rules.apiVersions** ([]string) - APIVersions is the API versions the resources belong to. '*' is all versions. If '*' is present, the length of the slice must be one. Required. + APIVersions is the API versions the resources belong to. '*' is all versions. If '*' is present, the length of the slice must be one. Required. - - **webhooks.rules.operations** ([]string) + - **webhooks.rules.operations** ([]string) - Operations is the operations the admission hook cares about - CREATE, UPDATE, DELETE, CONNECT or * for all of those operations and any future admission operations that are added. If '*' is present, the length of the slice must be one. Required. + Operations is the operations the admission hook cares about - CREATE, UPDATE, DELETE, CONNECT or * for all of those operations and any future admission operations that are added. If '*' is present, the length of the slice must be one. Required. - - **webhooks.rules.resources** ([]string) + - **webhooks.rules.resources** ([]string) - Resources is a list of resources this rule applies to. - - For example: 'pods' means pods. 'pods/log' means the log subresource of pods. '*' means all resources, but not subresources. 'pods/*' means all subresources of pods. '*/scale' means all scale subresources. '*/*' means all resources and their subresources. - - If wildcard is present, the validation rule will ensure resources do not overlap with each other. - - Depending on the enclosing object, subresources might not be allowed. Required. + Resources is a list of resources this rule applies to. + + For example: 'pods' means pods. 'pods/log' means the log subresource of pods. '*' means all resources, but not subresources. 'pods/*' means all subresources of pods. '*/scale' means all scale subresources. '*/*' means all resources and their subresources. + + If wildcard is present, the validation rule will ensure resources do not overlap with each other. + + Depending on the enclosing object, subresources might not be allowed. Required. - - **webhooks.rules.scope** (string) + - **webhooks.rules.scope** (string) - scope specifies the scope of this rule. Valid values are "Cluster", "Namespaced", and "*" "Cluster" means that only cluster-scoped resources will match this rule. Namespace API objects are cluster-scoped. "Namespaced" means that only namespaced resources will match this rule. "*" means that there are no scope restrictions. Subresources match the scope of their parent resource. Default is "*". + scope specifies the scope of this rule. Valid values are "Cluster", "Namespaced", and "*" "Cluster" means that only cluster-scoped resources will match this rule. Namespace API objects are cluster-scoped. "Namespaced" means that only namespaced resources will match this rule. "*" means that there are no scope restrictions. Subresources match the scope of their parent resource. Default is "*". - **webhooks.timeoutSeconds** (int32) @@ -467,6 +479,8 @@ PATCH /apis/admissionregistration.k8s.io/v1/mutatingwebhookconfigurations/{name} 200 (}}">MutatingWebhookConfiguration): OK +201 (}}">MutatingWebhookConfiguration): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/extend-resources/validating-webhook-configuration-v1.md b/content/en/docs/reference/kubernetes-api/extend-resources/validating-webhook-configuration-v1.md index 84d26265a3..417f90402e 100644 --- a/content/en/docs/reference/kubernetes-api/extend-resources/validating-webhook-configuration-v1.md +++ b/content/en/docs/reference/kubernetes-api/extend-resources/validating-webhook-configuration-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "ValidatingWebhookConfiguration describes the configuration of and admission webhook that accept or reject and object without changing it." title: "ValidatingWebhookConfiguration" weight: 3 +auto_generated: true --- + + `apiVersion: admissionregistration.k8s.io/v1` `import "k8s.io/api/admissionregistration/v1"` @@ -50,48 +62,48 @@ ValidatingWebhookConfiguration describes the configuration of and admission webh *WebhookClientConfig contains the information to make a TLS connection with the webhook* - - **webhooks.clientConfig.caBundle** ([]byte) + - **webhooks.clientConfig.caBundle** ([]byte) - `caBundle` is a PEM encoded CA bundle which will be used to validate the webhook's server certificate. If unspecified, system trust roots on the apiserver are used. + `caBundle` is a PEM encoded CA bundle which will be used to validate the webhook's server certificate. If unspecified, system trust roots on the apiserver are used. - - **webhooks.clientConfig.service** (ServiceReference) + - **webhooks.clientConfig.service** (ServiceReference) - `service` is a reference to the service for this webhook. Either `service` or `url` must be specified. - - If the webhook is running within the cluster, then you should use `service`. + `service` is a reference to the service for this webhook. Either `service` or `url` must be specified. + + If the webhook is running within the cluster, then you should use `service`. - - *ServiceReference holds a reference to Service.legacy.k8s.io* + + *ServiceReference holds a reference to Service.legacy.k8s.io* - - **webhooks.clientConfig.service.name** (string), required + - **webhooks.clientConfig.service.name** (string), required - `name` is the name of the service. Required + `name` is the name of the service. Required - - **webhooks.clientConfig.service.namespace** (string), required + - **webhooks.clientConfig.service.namespace** (string), required - `namespace` is the namespace of the service. Required + `namespace` is the namespace of the service. Required - - **webhooks.clientConfig.service.path** (string) + - **webhooks.clientConfig.service.path** (string) - `path` is an optional URL path which will be sent in any request to this service. + `path` is an optional URL path which will be sent in any request to this service. - - **webhooks.clientConfig.service.port** (int32) + - **webhooks.clientConfig.service.port** (int32) - If specified, the port on the service that hosting webhook. Default to 443 for backward compatibility. `port` should be a valid port number (1-65535, inclusive). + If specified, the port on the service that hosting webhook. Default to 443 for backward compatibility. `port` should be a valid port number (1-65535, inclusive). - - **webhooks.clientConfig.url** (string) + - **webhooks.clientConfig.url** (string) - `url` gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified. - - The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address. - - Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installations are likely to be non-portable or not readily run in a new cluster. - - The scheme must be "https"; the URL must begin with "https://". - - A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier. - - Attempting to use a user or basic auth e.g. "user:password@" is not allowed. Fragments ("#...") and query parameters ("?...") are not allowed, either. + `url` gives the location of the webhook, in standard URL form (`scheme://host:port/path`). Exactly one of `url` or `service` must be specified. + + The `host` should not refer to a service running in the cluster; use the `service` field instead. The host might be resolved via external DNS in some apiservers (e.g., `kube-apiserver` cannot resolve in-cluster DNS as that would be a layering violation). `host` may also be an IP address. + + Please note that using `localhost` or `127.0.0.1` as a `host` is risky unless you take great care to run this webhook on all hosts which run an apiserver which might need to make calls to this webhook. Such installs are likely to be non-portable, i.e., not easy to turn up in a new cluster. + + The scheme must be "https"; the URL must begin with "https://". + + A path is optional, and if present may be any string permissible in a URL. You may use the path to pass an arbitrary string to the webhook, for example, a cluster identifier. + + Attempting to use a user or basic auth e.g. "user:password@" is not allowed. Fragments ("#...") and query parameters ("?...") are not allowed, either. - **webhooks.name** (string), required @@ -99,7 +111,7 @@ ValidatingWebhookConfiguration describes the configuration of and admission webh - **webhooks.sideEffects** (string), required - SideEffects states whether this webhook has side effects. Acceptable values are: None, NoneOnDryRun (webhooks created via v1beta1 may also specify Some or Unknown). Webhooks with side effects MUST implement a reconciliation system, since a request may be rejected by a future step in the admission change and the side effects therefore need to be undone. Requests with the dryRun attribute will be auto-rejected if they match a webhook with sideEffects == Unknown or Some. + SideEffects states whether this webhook has side effects. Acceptable values are: None, NoneOnDryRun (webhooks created via v1beta1 may also specify Some or Unknown). Webhooks with side effects MUST implement a reconciliation system, since a request may be rejected by a future step in the admission chain and the side effects therefore need to be undone. Requests with the dryRun attribute will be auto-rejected if they match a webhook with sideEffects == Unknown or Some. - **webhooks.failurePolicy** (string) @@ -160,31 +172,31 @@ ValidatingWebhookConfiguration describes the configuration of and admission webh *RuleWithOperations is a tuple of Operations and Resources. It is recommended to make sure that all the tuple expansions are valid.* - - **webhooks.rules.apiGroups** ([]string) + - **webhooks.rules.apiGroups** ([]string) - APIGroups is the API groups the resources belong to. '*' is all groups. If '*' is present, the length of the slice must be one. Required. + APIGroups is the API groups the resources belong to. '*' is all groups. If '*' is present, the length of the slice must be one. Required. - - **webhooks.rules.apiVersions** ([]string) + - **webhooks.rules.apiVersions** ([]string) - APIVersions is the API versions the resources belong to. '*' is all versions. If '*' is present, the length of the slice must be one. Required. + APIVersions is the API versions the resources belong to. '*' is all versions. If '*' is present, the length of the slice must be one. Required. - - **webhooks.rules.operations** ([]string) + - **webhooks.rules.operations** ([]string) - Operations is the operations the admission hook cares about - CREATE, UPDATE, DELETE, CONNECT or * for all of those operations and any future admission operations that are added. If '*' is present, the length of the slice must be one. Required. + Operations is the operations the admission hook cares about - CREATE, UPDATE, DELETE, CONNECT or * for all of those operations and any future admission operations that are added. If '*' is present, the length of the slice must be one. Required. - - **webhooks.rules.resources** ([]string) + - **webhooks.rules.resources** ([]string) - Resources is a list of resources this rule applies to. - - For example: 'pods' means pods. 'pods/log' means the log subresource of pods. '*' means all resources, but not subresources. 'pods/*' means all subresources of pods. '*/scale' means all scale subresources. '*/*' means all resources and their subresources. - - If wildcard is present, the validation rule will ensure resources do not overlap with each other. - - Depending on the enclosing object, subresources might not be allowed. Required. + Resources is a list of resources this rule applies to. + + For example: 'pods' means pods. 'pods/log' means the log subresource of pods. '*' means all resources, but not subresources. 'pods/*' means all subresources of pods. '*/scale' means all scale subresources. '*/*' means all resources and their subresources. + + If wildcard is present, the validation rule will ensure resources do not overlap with each other. + + Depending on the enclosing object, subresources might not be allowed. Required. - - **webhooks.rules.scope** (string) + - **webhooks.rules.scope** (string) - scope specifies the scope of this rule. Valid values are "Cluster", "Namespaced", and "*" "Cluster" means that only cluster-scoped resources will match this rule. Namespace API objects are cluster-scoped. "Namespaced" means that only namespaced resources will match this rule. "*" means that there are no scope restrictions. Subresources match the scope of their parent resource. Default is "*". + scope specifies the scope of this rule. Valid values are "Cluster", "Namespaced", and "*" "Cluster" means that only cluster-scoped resources will match this rule. Namespace API objects are cluster-scoped. "Namespaced" means that only namespaced resources will match this rule. "*" means that there are no scope restrictions. Subresources match the scope of their parent resource. Default is "*". - **webhooks.timeoutSeconds** (int32) @@ -457,6 +469,8 @@ PATCH /apis/admissionregistration.k8s.io/v1/validatingwebhookconfigurations/{nam 200 (}}">ValidatingWebhookConfiguration): OK +201 (}}">ValidatingWebhookConfiguration): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/policy-resources/_index.md b/content/en/docs/reference/kubernetes-api/policy-resources/_index.md index 06a9e27fee..2b614bb534 100644 --- a/content/en/docs/reference/kubernetes-api/policy-resources/_index.md +++ b/content/en/docs/reference/kubernetes-api/policy-resources/_index.md @@ -1,4 +1,17 @@ --- title: "Policy Resources" weight: 6 +auto_generated: true --- + + + diff --git a/content/en/docs/reference/kubernetes-api/policy-resources/limit-range-v1.md b/content/en/docs/reference/kubernetes-api/policy-resources/limit-range-v1.md index 00982c5ab8..36d9ff42c4 100644 --- a/content/en/docs/reference/kubernetes-api/policy-resources/limit-range-v1.md +++ b/content/en/docs/reference/kubernetes-api/policy-resources/limit-range-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "LimitRange sets resource usage limits for each kind of resource in a Namespace." title: "LimitRange" weight: 1 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` @@ -97,7 +109,7 @@ LimitRangeList is a list of LimitRange items. - **items** ([]}}">LimitRange), required - Items is a list of LimitRange objects. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/ + Items is a list of LimitRange objects. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ @@ -435,6 +447,8 @@ PATCH /api/v1/namespaces/{namespace}/limitranges/{name} 200 (}}">LimitRange): OK +201 (}}">LimitRange): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/policy-resources/network-policy-v1.md b/content/en/docs/reference/kubernetes-api/policy-resources/network-policy-v1.md index 78e4868d94..2ba558d7b1 100644 --- a/content/en/docs/reference/kubernetes-api/policy-resources/network-policy-v1.md +++ b/content/en/docs/reference/kubernetes-api/policy-resources/network-policy-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "NetworkPolicy describes what network traffic is allowed for a set of Pods." title: "NetworkPolicy" weight: 3 +auto_generated: true --- + + `apiVersion: networking.k8s.io/v1` `import "k8s.io/api/networking/v1"` @@ -50,7 +62,7 @@ NetworkPolicySpec provides the specification of a NetworkPolicy - **policyTypes** ([]string) - List of rule types that the NetworkPolicy relates to. Valid options are "Ingress", "Egress", or "Ingress,Egress". If this field is not specified, it will default based on the existence of Ingress or Egress rules; policies that contain an Egress section are assumed to affect Egress, and all policies (whether or not they contain an Ingress section) are assumed to affect Ingress. If you want to write an egress-only policy, you must explicitly specify policyTypes [ "Egress" ]. Likewise, if you want to write a policy that specifies that no egress is allowed, you must specify a policyTypes value that include "Egress" (since such a policy would not include an Egress section and would otherwise default to just [ "Ingress" ]). This field is beta-level in 1.8 + List of rule types that the NetworkPolicy relates to. Valid options are ["Ingress"], ["Egress"], or ["Ingress", "Egress"]. If this field is not specified, it will default based on the existence of Ingress or Egress rules; policies that contain an Egress section are assumed to affect Egress, and all policies (whether or not they contain an Ingress section) are assumed to affect Ingress. If you want to write an egress-only policy, you must explicitly specify policyTypes [ "Egress" ]. Likewise, if you want to write a policy that specifies that no egress is allowed, you must specify a policyTypes value that include "Egress" (since such a policy would not include an Egress section and would otherwise default to just [ "Ingress" ]). This field is beta-level in 1.8 - **ingress** ([]NetworkPolicyIngressRule) @@ -66,32 +78,32 @@ NetworkPolicySpec provides the specification of a NetworkPolicy *NetworkPolicyPeer describes a peer to allow traffic to/from. Only certain combinations of fields are allowed* - - **ingress.from.ipBlock** (IPBlock) + - **ingress.from.ipBlock** (IPBlock) - IPBlock defines policy on a particular IPBlock. If this field is set then neither of the other fields can be. + IPBlock defines policy on a particular IPBlock. If this field is set then neither of the other fields can be. - - *IPBlock describes a particular CIDR (Ex. "192.168.1.1/24","2001:db9::/64") that is allowed to the pods matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs that should not be included within this rule.* + + *IPBlock describes a particular CIDR (Ex. "192.168.1.1/24","2001:db9::/64") that is allowed to the pods matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs that should not be included within this rule.* - - **ingress.from.ipBlock.cidr** (string), required + - **ingress.from.ipBlock.cidr** (string), required - CIDR is a string representing the IP Block Valid examples are "192.168.1.1/24" or "2001:db9::/64" + CIDR is a string representing the IP Block Valid examples are "192.168.1.1/24" or "2001:db9::/64" - - **ingress.from.ipBlock.except** ([]string) + - **ingress.from.ipBlock.except** ([]string) - Except is a slice of CIDRs that should not be included within an IP Block Valid examples are "192.168.1.1/24" or "2001:db9::/64" Except values will be rejected if they are outside the CIDR range + Except is a slice of CIDRs that should not be included within an IP Block Valid examples are "192.168.1.1/24" or "2001:db9::/64" Except values will be rejected if they are outside the CIDR range - - **ingress.from.namespaceSelector** (}}">LabelSelector) + - **ingress.from.namespaceSelector** (}}">LabelSelector) - Selects Namespaces using cluster-scoped labels. This field follows standard label selector semantics; if present but empty, it selects all namespaces. - - If PodSelector is also set, then the NetworkPolicyPeer as a whole selects the Pods matching PodSelector in the Namespaces selected by NamespaceSelector. Otherwise it selects all Pods in the Namespaces selected by NamespaceSelector. + Selects Namespaces using cluster-scoped labels. This field follows standard label selector semantics; if present but empty, it selects all namespaces. + + If PodSelector is also set, then the NetworkPolicyPeer as a whole selects the Pods matching PodSelector in the Namespaces selected by NamespaceSelector. Otherwise it selects all Pods in the Namespaces selected by NamespaceSelector. - - **ingress.from.podSelector** (}}">LabelSelector) + - **ingress.from.podSelector** (}}">LabelSelector) - This is a label selector which selects Pods. This field follows standard label selector semantics; if present but empty, it selects all pods. - - If NamespaceSelector is also set, then the NetworkPolicyPeer as a whole selects the Pods matching PodSelector in the Namespaces selected by NamespaceSelector. Otherwise it selects the Pods matching PodSelector in the policy's own Namespace. + This is a label selector which selects Pods. This field follows standard label selector semantics; if present but empty, it selects all pods. + + If NamespaceSelector is also set, then the NetworkPolicyPeer as a whole selects the Pods matching PodSelector in the Namespaces selected by NamespaceSelector. Otherwise it selects the Pods matching PodSelector in the policy's own Namespace. - **ingress.ports** ([]NetworkPolicyPort) @@ -100,16 +112,20 @@ NetworkPolicySpec provides the specification of a NetworkPolicy *NetworkPolicyPort describes a port to allow traffic on* - - **ingress.ports.port** (IntOrString) + - **ingress.ports.port** (IntOrString) - The port on the given protocol. This can either be a numerical or named port on a pod. If this field is not provided, this matches all port names and numbers. + The port on the given protocol. This can either be a numerical or named port on a pod. If this field is not provided, this matches all port names and numbers. If present, only traffic on the specified protocol AND port will be matched. - - *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* + + *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* - - **ingress.ports.protocol** (string) + - **ingress.ports.endPort** (int32) - The protocol (TCP, UDP, or SCTP) which traffic must match. If not specified, this field defaults to TCP. + If set, indicates that the range of ports from port to endPort, inclusive, should be allowed by the policy. This field cannot be defined if the port field is not defined or if the port field is defined as a named (string) port. The endPort must be equal or greater than port. This feature is in Beta state and is enabled by default. It can be disabled using the Feature Gate "NetworkPolicyEndPort". + + - **ingress.ports.protocol** (string) + + The protocol (TCP, UDP, or SCTP) which traffic must match. If not specified, this field defaults to TCP. - **egress** ([]NetworkPolicyEgressRule) @@ -125,32 +141,32 @@ NetworkPolicySpec provides the specification of a NetworkPolicy *NetworkPolicyPeer describes a peer to allow traffic to/from. Only certain combinations of fields are allowed* - - **egress.to.ipBlock** (IPBlock) + - **egress.to.ipBlock** (IPBlock) - IPBlock defines policy on a particular IPBlock. If this field is set then neither of the other fields can be. + IPBlock defines policy on a particular IPBlock. If this field is set then neither of the other fields can be. - - *IPBlock describes a particular CIDR (Ex. "192.168.1.1/24","2001:db9::/64") that is allowed to the pods matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs that should not be included within this rule.* + + *IPBlock describes a particular CIDR (Ex. "192.168.1.1/24","2001:db9::/64") that is allowed to the pods matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs that should not be included within this rule.* - - **egress.to.ipBlock.cidr** (string), required + - **egress.to.ipBlock.cidr** (string), required - CIDR is a string representing the IP Block Valid examples are "192.168.1.1/24" or "2001:db9::/64" + CIDR is a string representing the IP Block Valid examples are "192.168.1.1/24" or "2001:db9::/64" - - **egress.to.ipBlock.except** ([]string) + - **egress.to.ipBlock.except** ([]string) - Except is a slice of CIDRs that should not be included within an IP Block Valid examples are "192.168.1.1/24" or "2001:db9::/64" Except values will be rejected if they are outside the CIDR range + Except is a slice of CIDRs that should not be included within an IP Block Valid examples are "192.168.1.1/24" or "2001:db9::/64" Except values will be rejected if they are outside the CIDR range - - **egress.to.namespaceSelector** (}}">LabelSelector) + - **egress.to.namespaceSelector** (}}">LabelSelector) - Selects Namespaces using cluster-scoped labels. This field follows standard label selector semantics; if present but empty, it selects all namespaces. - - If PodSelector is also set, then the NetworkPolicyPeer as a whole selects the Pods matching PodSelector in the Namespaces selected by NamespaceSelector. Otherwise it selects all Pods in the Namespaces selected by NamespaceSelector. + Selects Namespaces using cluster-scoped labels. This field follows standard label selector semantics; if present but empty, it selects all namespaces. + + If PodSelector is also set, then the NetworkPolicyPeer as a whole selects the Pods matching PodSelector in the Namespaces selected by NamespaceSelector. Otherwise it selects all Pods in the Namespaces selected by NamespaceSelector. - - **egress.to.podSelector** (}}">LabelSelector) + - **egress.to.podSelector** (}}">LabelSelector) - This is a label selector which selects Pods. This field follows standard label selector semantics; if present but empty, it selects all pods. - - If NamespaceSelector is also set, then the NetworkPolicyPeer as a whole selects the Pods matching PodSelector in the Namespaces selected by NamespaceSelector. Otherwise it selects the Pods matching PodSelector in the policy's own Namespace. + This is a label selector which selects Pods. This field follows standard label selector semantics; if present but empty, it selects all pods. + + If NamespaceSelector is also set, then the NetworkPolicyPeer as a whole selects the Pods matching PodSelector in the Namespaces selected by NamespaceSelector. Otherwise it selects the Pods matching PodSelector in the policy's own Namespace. - **egress.ports** ([]NetworkPolicyPort) @@ -159,16 +175,20 @@ NetworkPolicySpec provides the specification of a NetworkPolicy *NetworkPolicyPort describes a port to allow traffic on* - - **egress.ports.port** (IntOrString) + - **egress.ports.port** (IntOrString) - The port on the given protocol. This can either be a numerical or named port on a pod. If this field is not provided, this matches all port names and numbers. + The port on the given protocol. This can either be a numerical or named port on a pod. If this field is not provided, this matches all port names and numbers. If present, only traffic on the specified protocol AND port will be matched. - - *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* + + *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* - - **egress.ports.protocol** (string) + - **egress.ports.endPort** (int32) - The protocol (TCP, UDP, or SCTP) which traffic must match. If not specified, this field defaults to TCP. + If set, indicates that the range of ports from port to endPort, inclusive, should be allowed by the policy. This field cannot be defined if the port field is not defined or if the port field is defined as a named (string) port. The endPort must be equal or greater than port. This feature is in Beta state and is enabled by default. It can be disabled using the Feature Gate "NetworkPolicyEndPort". + + - **egress.ports.protocol** (string) + + The protocol (TCP, UDP, or SCTP) which traffic must match. If not specified, this field defaults to TCP. @@ -530,6 +550,8 @@ PATCH /apis/networking.k8s.io/v1/namespaces/{namespace}/networkpolicies/{name} 200 (}}">NetworkPolicy): OK +201 (}}">NetworkPolicy): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/policy-resources/pod-disruption-budget-v1beta1.md b/content/en/docs/reference/kubernetes-api/policy-resources/pod-disruption-budget-v1.md similarity index 72% rename from content/en/docs/reference/kubernetes-api/policy-resources/pod-disruption-budget-v1beta1.md rename to content/en/docs/reference/kubernetes-api/policy-resources/pod-disruption-budget-v1.md index 9120b19468..5b88652bb2 100644 --- a/content/en/docs/reference/kubernetes-api/policy-resources/pod-disruption-budget-v1beta1.md +++ b/content/en/docs/reference/kubernetes-api/policy-resources/pod-disruption-budget-v1.md @@ -1,17 +1,29 @@ --- api_metadata: - apiVersion: "policy/v1beta1" - import: "k8s.io/api/policy/v1beta1" + apiVersion: "policy/v1" + import: "k8s.io/api/policy/v1" kind: "PodDisruptionBudget" content_type: "api_reference" description: "PodDisruptionBudget is an object to define the max disruption that can be caused to a collection of pods." -title: "PodDisruptionBudget v1beta1" +title: "PodDisruptionBudget" weight: 4 +auto_generated: true --- -`apiVersion: policy/v1beta1` + -`import "k8s.io/api/policy/v1beta1"` +`apiVersion: policy/v1` + +`import "k8s.io/api/policy/v1"` ## PodDisruptionBudget {#PodDisruptionBudget} @@ -20,7 +32,7 @@ PodDisruptionBudget is an object to define the max disruption that can be caused
-- **apiVersion**: policy/v1beta1 +- **apiVersion**: policy/v1 - **kind**: PodDisruptionBudget @@ -28,12 +40,13 @@ PodDisruptionBudget is an object to define the max disruption that can be caused - **metadata** (}}">ObjectMeta) + Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata -- **spec** (}}">PodDisruptionBudgetSpec) +- **spec** (}}">PodDisruptionBudgetSpec) Specification of the desired behavior of the PodDisruptionBudget. -- **status** (}}">PodDisruptionBudgetStatus) +- **status** (}}">PodDisruptionBudgetStatus) Most recently observed status of the PodDisruptionBudget. @@ -63,7 +76,7 @@ PodDisruptionBudgetSpec is a description of a PodDisruptionBudget. - **selector** (}}">LabelSelector) - Label query over pods whose evictions are managed by the disruption budget. + Label query over pods whose evictions are managed by the disruption budget. A null selector will match no pods, while an empty ({}) selector will select all pods within the namespace. @@ -91,6 +104,52 @@ PodDisruptionBudgetStatus represents information about the status of a PodDisrup total number of pods counted by this disruption budget +- **conditions** ([]Condition) + + *Patch strategy: merge on key `type`* + + *Map: unique values on key type will be kept during a merge* + + Conditions contain conditions for PDB. The disruption controller sets the DisruptionAllowed condition. The following are known values for the reason field (additional reasons could be added in the future): - SyncFailed: The controller encountered an error and wasn't able to compute + the number of allowed disruptions. Therefore no disruptions are + allowed and the status of the condition will be False. + - InsufficientPods: The number of pods are either at or below the number + required by the PodDisruptionBudget. No disruptions are + allowed and the status of the condition will be False. + - SufficientPods: There are more pods than required by the PodDisruptionBudget. + The condition will be True, and the number of allowed + disruptions are provided by the disruptionsAllowed property. + + + *Condition contains details for one aspect of the current state of this API Resource.* + + - **conditions.lastTransitionTime** (Time), required + + lastTransitionTime is the last time the condition transitioned from one status to another. This should be when the underlying condition changed. If that is not known, then using the time when the API field changed is acceptable. + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **conditions.message** (string), required + + message is a human readable message indicating details about the transition. This may be an empty string. + + - **conditions.reason** (string), required + + reason contains a programmatic identifier indicating the reason for the condition's last transition. Producers of specific condition types may define expected values and meanings for this field, and whether the values are considered a guaranteed API. The value should be a CamelCase string. This field may not be empty. + + - **conditions.status** (string), required + + status of the condition, one of True, False, Unknown. + + - **conditions.type** (string), required + + type of condition in CamelCase or in foo.example.com/CamelCase. + + - **conditions.observedGeneration** (int64) + + observedGeneration represents the .metadata.generation that the condition was set based upon. For instance, if .metadata.generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date with respect to the current state of the instance. + - **disruptedPods** (map[string]Time) DisruptedPods contains information about pods whose eviction was processed by the API server eviction subresource handler but has not yet been observed by the PodDisruptionBudget controller. A pod will be in this map from the time when the API server processed the eviction request to the time when the pod is seen by PDB controller as having been marked for deletion (or after a timeout). The key in the map is the name of the pod and the value is the time when the API server processed the eviction request. If the deletion didn't occur and a pod is still there it will be removed from the list automatically by PodDisruptionBudget controller after some time. If everything goes smooth this map should be empty for the most of the time. Large number of entries in the map may indicate problems with pod deletions. @@ -112,7 +171,7 @@ PodDisruptionBudgetList is a collection of PodDisruptionBudgets.
-- **apiVersion**: policy/v1beta1 +- **apiVersion**: policy/v1 - **kind**: PodDisruptionBudgetList @@ -120,9 +179,11 @@ PodDisruptionBudgetList is a collection of PodDisruptionBudgets. - **metadata** (}}">ListMeta) + Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata -- **items** ([]}}">PodDisruptionBudget), required +- **items** ([]}}">PodDisruptionBudget), required + Items is a list of PodDisruptionBudgets @@ -143,7 +204,7 @@ PodDisruptionBudgetList is a collection of PodDisruptionBudgets. #### HTTP Request -GET /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name} +GET /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name} #### Parameters @@ -167,7 +228,7 @@ GET /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name} #### Response -200 (}}">PodDisruptionBudget): OK +200 (}}">PodDisruptionBudget): OK 401: Unauthorized @@ -176,7 +237,7 @@ GET /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name} #### HTTP Request -GET /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}/status +GET /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}/status #### Parameters @@ -200,7 +261,7 @@ GET /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}/stat #### Response -200 (}}">PodDisruptionBudget): OK +200 (}}">PodDisruptionBudget): OK 401: Unauthorized @@ -209,7 +270,7 @@ GET /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}/stat #### HTTP Request -GET /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets +GET /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets #### Parameters @@ -273,7 +334,7 @@ GET /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets #### Response -200 (}}">PodDisruptionBudgetList): OK +200 (}}">PodDisruptionBudgetList): OK 401: Unauthorized @@ -282,7 +343,7 @@ GET /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets #### HTTP Request -GET /apis/policy/v1beta1/poddisruptionbudgets +GET /apis/policy/v1/poddisruptionbudgets #### Parameters @@ -341,7 +402,7 @@ GET /apis/policy/v1beta1/poddisruptionbudgets #### Response -200 (}}">PodDisruptionBudgetList): OK +200 (}}">PodDisruptionBudgetList): OK 401: Unauthorized @@ -350,7 +411,7 @@ GET /apis/policy/v1beta1/poddisruptionbudgets #### HTTP Request -POST /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets +POST /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets #### Parameters @@ -360,7 +421,7 @@ POST /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets }}">namespace -- **body**: }}">PodDisruptionBudget, required +- **body**: }}">PodDisruptionBudget, required @@ -384,11 +445,11 @@ POST /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets #### Response -200 (}}">PodDisruptionBudget): OK +200 (}}">PodDisruptionBudget): OK -201 (}}">PodDisruptionBudget): Created +201 (}}">PodDisruptionBudget): Created -202 (}}">PodDisruptionBudget): Accepted +202 (}}">PodDisruptionBudget): Accepted 401: Unauthorized @@ -397,7 +458,7 @@ POST /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets #### HTTP Request -PUT /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name} +PUT /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name} #### Parameters @@ -412,7 +473,7 @@ PUT /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name} }}">namespace -- **body**: }}">PodDisruptionBudget, required +- **body**: }}">PodDisruptionBudget, required @@ -436,9 +497,9 @@ PUT /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name} #### Response -200 (}}">PodDisruptionBudget): OK +200 (}}">PodDisruptionBudget): OK -201 (}}">PodDisruptionBudget): Created +201 (}}">PodDisruptionBudget): Created 401: Unauthorized @@ -447,7 +508,7 @@ PUT /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name} #### HTTP Request -PUT /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}/status +PUT /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}/status #### Parameters @@ -462,7 +523,7 @@ PUT /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}/stat }}">namespace -- **body**: }}">PodDisruptionBudget, required +- **body**: }}">PodDisruptionBudget, required @@ -486,9 +547,9 @@ PUT /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}/stat #### Response -200 (}}">PodDisruptionBudget): OK +200 (}}">PodDisruptionBudget): OK -201 (}}">PodDisruptionBudget): Created +201 (}}">PodDisruptionBudget): Created 401: Unauthorized @@ -497,7 +558,7 @@ PUT /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}/stat #### HTTP Request -PATCH /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name} +PATCH /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name} #### Parameters @@ -541,7 +602,9 @@ PATCH /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name} #### Response -200 (}}">PodDisruptionBudget): OK +200 (}}">PodDisruptionBudget): OK + +201 (}}">PodDisruptionBudget): Created 401: Unauthorized @@ -550,7 +613,7 @@ PATCH /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name} #### HTTP Request -PATCH /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}/status +PATCH /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name}/status #### Parameters @@ -594,7 +657,9 @@ PATCH /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}/st #### Response -200 (}}">PodDisruptionBudget): OK +200 (}}">PodDisruptionBudget): OK + +201 (}}">PodDisruptionBudget): Created 401: Unauthorized @@ -603,7 +668,7 @@ PATCH /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name}/st #### HTTP Request -DELETE /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name} +DELETE /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets/{name} #### Parameters @@ -658,7 +723,7 @@ DELETE /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets/{name} #### HTTP Request -DELETE /apis/policy/v1beta1/namespaces/{namespace}/poddisruptionbudgets +DELETE /apis/policy/v1/namespaces/{namespace}/poddisruptionbudgets #### Parameters diff --git a/content/en/docs/reference/kubernetes-api/policy-resources/pod-security-policy-v1beta1.md b/content/en/docs/reference/kubernetes-api/policy-resources/pod-security-policy-v1beta1.md index 59444cbbcf..2f03cfa5bf 100644 --- a/content/en/docs/reference/kubernetes-api/policy-resources/pod-security-policy-v1beta1.md +++ b/content/en/docs/reference/kubernetes-api/policy-resources/pod-security-policy-v1beta1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "PodSecurityPolicy governs the ability to make requests that affect the Security Context that will be applied to a pod and container." title: "PodSecurityPolicy v1beta1" weight: 5 +auto_generated: true --- + + `apiVersion: policy/v1beta1` `import "k8s.io/api/policy/v1beta1"` @@ -16,7 +28,7 @@ weight: 5 ## PodSecurityPolicy {#PodSecurityPolicy} -PodSecurityPolicy governs the ability to make requests that affect the Security Context that will be applied to a pod and container. +PodSecurityPolicy governs the ability to make requests that affect the Security Context that will be applied to a pod and container. Deprecated in 1.21.
@@ -62,13 +74,13 @@ PodSecurityPolicySpec defines the policy enforced. *IDRange provides a min/max of an allowed range of IDs.* - - **runAsUser.ranges.max** (int64), required + - **runAsUser.ranges.max** (int64), required - max is the end of the range, inclusive. + max is the end of the range, inclusive. - - **runAsUser.ranges.min** (int64), required + - **runAsUser.ranges.min** (int64), required - min is the start of the range, inclusive. + min is the start of the range, inclusive. - **runAsGroup** (RunAsGroupStrategyOptions) @@ -88,13 +100,13 @@ PodSecurityPolicySpec defines the policy enforced. *IDRange provides a min/max of an allowed range of IDs.* - - **runAsGroup.ranges.max** (int64), required + - **runAsGroup.ranges.max** (int64), required - max is the end of the range, inclusive. + max is the end of the range, inclusive. - - **runAsGroup.ranges.min** (int64), required + - **runAsGroup.ranges.min** (int64), required - min is the start of the range, inclusive. + min is the start of the range, inclusive. - **fsGroup** (FSGroupStrategyOptions), required @@ -110,13 +122,13 @@ PodSecurityPolicySpec defines the policy enforced. *IDRange provides a min/max of an allowed range of IDs.* - - **fsGroup.ranges.max** (int64), required + - **fsGroup.ranges.max** (int64), required - max is the end of the range, inclusive. + max is the end of the range, inclusive. - - **fsGroup.ranges.min** (int64), required + - **fsGroup.ranges.min** (int64), required - min is the start of the range, inclusive. + min is the start of the range, inclusive. - **fsGroup.rule** (string) @@ -136,13 +148,13 @@ PodSecurityPolicySpec defines the policy enforced. *IDRange provides a min/max of an allowed range of IDs.* - - **supplementalGroups.ranges.max** (int64), required + - **supplementalGroups.ranges.max** (int64), required - max is the end of the range, inclusive. + max is the end of the range, inclusive. - - **supplementalGroups.ranges.min** (int64), required + - **supplementalGroups.ranges.min** (int64), required - min is the start of the range, inclusive. + min is the start of the range, inclusive. - **supplementalGroups.rule** (string) @@ -166,21 +178,21 @@ PodSecurityPolicySpec defines the policy enforced. *SELinuxOptions are the labels to be applied to the container* - - **seLinux.seLinuxOptions.level** (string) + - **seLinux.seLinuxOptions.level** (string) - Level is SELinux level label that applies to the container. + Level is SELinux level label that applies to the container. - - **seLinux.seLinuxOptions.role** (string) + - **seLinux.seLinuxOptions.role** (string) - Role is a SELinux role label that applies to the container. + Role is a SELinux role label that applies to the container. - - **seLinux.seLinuxOptions.type** (string) + - **seLinux.seLinuxOptions.type** (string) - Type is a SELinux type label that applies to the container. + Type is a SELinux type label that applies to the container. - - **seLinux.seLinuxOptions.user** (string) + - **seLinux.seLinuxOptions.user** (string) - User is a SELinux user label that applies to the container. + User is a SELinux user label that applies to the container. - **readOnlyRootFilesystem** (boolean) @@ -578,6 +590,8 @@ PATCH /apis/policy/v1beta1/podsecuritypolicies/{name} 200 (}}">PodSecurityPolicy): OK +201 (}}">PodSecurityPolicy): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/policy-resources/resource-quota-v1.md b/content/en/docs/reference/kubernetes-api/policy-resources/resource-quota-v1.md index 93b8cbc9e8..e71631863e 100644 --- a/content/en/docs/reference/kubernetes-api/policy-resources/resource-quota-v1.md +++ b/content/en/docs/reference/kubernetes-api/policy-resources/resource-quota-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "ResourceQuota sets aggregate quota restrictions enforced per namespace." title: "ResourceQuota" weight: 2 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` @@ -66,17 +78,17 @@ ResourceQuotaSpec defines the desired hard limits to enforce for Quota. *A scoped-resource selector requirement is a selector that contains values, a scope name, and an operator that relates the scope name and values.* - - **scopeSelector.matchExpressions.operator** (string), required + - **scopeSelector.matchExpressions.operator** (string), required - Represents a scope's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. + Represents a scope's relationship to a set of values. Valid operators are In, NotIn, Exists, DoesNotExist. - - **scopeSelector.matchExpressions.scopeName** (string), required + - **scopeSelector.matchExpressions.scopeName** (string), required - The name of the scope that the selector applies to. + The name of the scope that the selector applies to. - - **scopeSelector.matchExpressions.values** ([]string) + - **scopeSelector.matchExpressions.values** ([]string) - An array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch. + An array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty. This array is replaced during a strategic merge patch. - **scopes** ([]string) @@ -543,6 +555,8 @@ PATCH /api/v1/namespaces/{namespace}/resourcequotas/{name} 200 (}}">ResourceQuota): OK +201 (}}">ResourceQuota): Created + 401: Unauthorized @@ -596,6 +610,8 @@ PATCH /api/v1/namespaces/{namespace}/resourcequotas/{name}/status 200 (}}">ResourceQuota): OK +201 (}}">ResourceQuota): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/service-resources/_index.md b/content/en/docs/reference/kubernetes-api/service-resources/_index.md index 0ab511b5a4..4f2d9118d9 100644 --- a/content/en/docs/reference/kubernetes-api/service-resources/_index.md +++ b/content/en/docs/reference/kubernetes-api/service-resources/_index.md @@ -1,4 +1,17 @@ --- title: "Service Resources" weight: 2 +auto_generated: true --- + + + diff --git a/content/en/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1beta1.md b/content/en/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1.md similarity index 73% rename from content/en/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1beta1.md rename to content/en/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1.md index 1ad467b022..b602f0e728 100644 --- a/content/en/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1beta1.md +++ b/content/en/docs/reference/kubernetes-api/service-resources/endpoint-slice-v1.md @@ -1,17 +1,29 @@ --- api_metadata: - apiVersion: "discovery.k8s.io/v1beta1" - import: "k8s.io/api/discovery/v1beta1" + apiVersion: "discovery.k8s.io/v1" + import: "k8s.io/api/discovery/v1" kind: "EndpointSlice" content_type: "api_reference" description: "EndpointSlice represents a subset of the endpoints that implement a service." -title: "EndpointSlice v1beta1" +title: "EndpointSlice" weight: 3 +auto_generated: true --- -`apiVersion: discovery.k8s.io/v1beta1` + -`import "k8s.io/api/discovery/v1beta1"` +`apiVersion: discovery.k8s.io/v1` + +`import "k8s.io/api/discovery/v1"` ## EndpointSlice {#EndpointSlice} @@ -20,7 +32,7 @@ EndpointSlice represents a subset of the endpoints that implement a service. For
-- **apiVersion**: discovery.k8s.io/v1beta1 +- **apiVersion**: discovery.k8s.io/v1 - **kind**: EndpointSlice @@ -56,17 +68,41 @@ EndpointSlice represents a subset of the endpoints that implement a service. For *EndpointConditions represents the current condition of an endpoint.* - - **endpoints.conditions.ready** (boolean) + - **endpoints.conditions.ready** (boolean) - ready indicates that this endpoint is prepared to receive traffic, according to whatever system is managing the endpoint. A nil value indicates an unknown state. In most cases consumers should interpret this unknown state as ready. For compatibility reasons, ready should never be "true" for terminating endpoints. + ready indicates that this endpoint is prepared to receive traffic, according to whatever system is managing the endpoint. A nil value indicates an unknown state. In most cases consumers should interpret this unknown state as ready. For compatibility reasons, ready should never be "true" for terminating endpoints. - - **endpoints.conditions.serving** (boolean) + - **endpoints.conditions.serving** (boolean) - serving is identical to ready except that it is set regardless of the terminating state of endpoints. This condition should be set to true for a ready endpoint that is terminating. If nil, consumers should defer to the ready condition. This field can be enabled with the EndpointSliceTerminatingCondition feature gate. + serving is identical to ready except that it is set regardless of the terminating state of endpoints. This condition should be set to true for a ready endpoint that is terminating. If nil, consumers should defer to the ready condition. This field can be enabled with the EndpointSliceTerminatingCondition feature gate. - - **endpoints.conditions.terminating** (boolean) + - **endpoints.conditions.terminating** (boolean) - terminating indicates that this endpoint is terminating. A nil value indicates an unknown state. Consumers should interpret this unknown state to mean that the endpoint is not terminating. This field can be enabled with the EndpointSliceTerminatingCondition feature gate. + terminating indicates that this endpoint is terminating. A nil value indicates an unknown state. Consumers should interpret this unknown state to mean that the endpoint is not terminating. This field can be enabled with the EndpointSliceTerminatingCondition feature gate. + + - **endpoints.deprecatedTopology** (map[string]string) + + deprecatedTopology contains topology information part of the v1beta1 API. This field is deprecated, and will be removed when the v1beta1 API is removed (no sooner than kubernetes v1.24). While this field can hold values, it is not writable through the v1 API, and any attempts to write to it will be silently ignored. Topology information can be found in the zone and nodeName fields instead. + + - **endpoints.hints** (EndpointHints) + + hints contains information associated with how an endpoint should be consumed. + + + *EndpointHints provides hints describing how an endpoint should be consumed.* + + - **endpoints.hints.forZones** ([]ForZone) + + *Atomic: will be replaced during a merge* + + forZones indicates the zone(s) this endpoint should be consumed by to enable topology aware routing. + + + *ForZone provides information about which zones should consume this endpoint.* + + - **endpoints.hints.forZones.name** (string), required + + name represents the name of the zone. - **endpoints.hostname** (string) @@ -80,16 +116,9 @@ EndpointSlice represents a subset of the endpoints that implement a service. For targetRef is a reference to a Kubernetes object that represents this endpoint. - - **endpoints.topology** (map[string]string) + - **endpoints.zone** (string) - topology contains arbitrary topology information associated with the endpoint. These key/value pairs must conform with the label format. https://kubernetes.io/docs/concepts/overview/working-with-objects/labels Topology may include a maximum of 16 key/value pairs. This includes, but is not limited to the following well known keys: * kubernetes.io/hostname: the value indicates the hostname of the node - where the endpoint is located. This should match the corresponding - node label. - * topology.kubernetes.io/zone: the value indicates the zone where the - endpoint is located. This should match the corresponding node label. - * topology.kubernetes.io/region: the value indicates the region where the - endpoint is located. This should match the corresponding node label. - This field is deprecated and will be removed in future api versions. + zone is the name of the Zone this endpoint exists in. - **ports** ([]EndpointPort) @@ -126,7 +155,7 @@ EndpointSliceList represents a list of endpoint slices
-- **apiVersion**: discovery.k8s.io/v1beta1 +- **apiVersion**: discovery.k8s.io/v1 - **kind**: EndpointSliceList @@ -136,7 +165,7 @@ EndpointSliceList represents a list of endpoint slices Standard list metadata. -- **items** ([]}}">EndpointSlice), required +- **items** ([]}}">EndpointSlice), required List of endpoint slices @@ -159,7 +188,7 @@ EndpointSliceList represents a list of endpoint slices #### HTTP Request -GET /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{name} +GET /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices/{name} #### Parameters @@ -183,7 +212,7 @@ GET /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{name} #### Response -200 (}}">EndpointSlice): OK +200 (}}">EndpointSlice): OK 401: Unauthorized @@ -192,7 +221,7 @@ GET /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{name} #### HTTP Request -GET /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices +GET /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices #### Parameters @@ -256,7 +285,7 @@ GET /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices #### Response -200 (}}">EndpointSliceList): OK +200 (}}">EndpointSliceList): OK 401: Unauthorized @@ -265,7 +294,7 @@ GET /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices #### HTTP Request -GET /apis/discovery.k8s.io/v1beta1/endpointslices +GET /apis/discovery.k8s.io/v1/endpointslices #### Parameters @@ -324,7 +353,7 @@ GET /apis/discovery.k8s.io/v1beta1/endpointslices #### Response -200 (}}">EndpointSliceList): OK +200 (}}">EndpointSliceList): OK 401: Unauthorized @@ -333,7 +362,7 @@ GET /apis/discovery.k8s.io/v1beta1/endpointslices #### HTTP Request -POST /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices +POST /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices #### Parameters @@ -343,7 +372,7 @@ POST /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices }}">namespace -- **body**: }}">EndpointSlice, required +- **body**: }}">EndpointSlice, required @@ -367,11 +396,11 @@ POST /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices #### Response -200 (}}">EndpointSlice): OK +200 (}}">EndpointSlice): OK -201 (}}">EndpointSlice): Created +201 (}}">EndpointSlice): Created -202 (}}">EndpointSlice): Accepted +202 (}}">EndpointSlice): Accepted 401: Unauthorized @@ -380,7 +409,7 @@ POST /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices #### HTTP Request -PUT /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{name} +PUT /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices/{name} #### Parameters @@ -395,7 +424,7 @@ PUT /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{name} }}">namespace -- **body**: }}">EndpointSlice, required +- **body**: }}">EndpointSlice, required @@ -419,9 +448,9 @@ PUT /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{name} #### Response -200 (}}">EndpointSlice): OK +200 (}}">EndpointSlice): OK -201 (}}">EndpointSlice): Created +201 (}}">EndpointSlice): Created 401: Unauthorized @@ -430,7 +459,7 @@ PUT /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{name} #### HTTP Request -PATCH /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{name} +PATCH /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices/{name} #### Parameters @@ -474,7 +503,9 @@ PATCH /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{name #### Response -200 (}}">EndpointSlice): OK +200 (}}">EndpointSlice): OK + +201 (}}">EndpointSlice): Created 401: Unauthorized @@ -483,7 +514,7 @@ PATCH /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{name #### HTTP Request -DELETE /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{name} +DELETE /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices/{name} #### Parameters @@ -538,7 +569,7 @@ DELETE /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices/{nam #### HTTP Request -DELETE /apis/discovery.k8s.io/v1beta1/namespaces/{namespace}/endpointslices +DELETE /apis/discovery.k8s.io/v1/namespaces/{namespace}/endpointslices #### Parameters diff --git a/content/en/docs/reference/kubernetes-api/service-resources/endpoints-v1.md b/content/en/docs/reference/kubernetes-api/service-resources/endpoints-v1.md index ce5c582b30..ccc385b983 100644 --- a/content/en/docs/reference/kubernetes-api/service-resources/endpoints-v1.md +++ b/content/en/docs/reference/kubernetes-api/service-resources/endpoints-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "Endpoints is a collection of endpoints that implement the actual service." title: "Endpoints" weight: 2 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` @@ -62,21 +74,21 @@ Endpoints is a collection of endpoints that implement the actual service. Exampl *EndpointAddress is a tuple that describes single IP address.* - - **subsets.addresses.ip** (string), required + - **subsets.addresses.ip** (string), required - The IP of this endpoint. May not be loopback (127.0.0.0/8), link-local (169.254.0.0/16), or link-local multicast ((224.0.0.0/24). IPv6 is also accepted but not fully supported on all platforms. Also, certain kubernetes components, like kube-proxy, are not IPv6 ready. + The IP of this endpoint. May not be loopback (127.0.0.0/8), link-local (169.254.0.0/16), or link-local multicast ((224.0.0.0/24). IPv6 is also accepted but not fully supported on all platforms. Also, certain kubernetes components, like kube-proxy, are not IPv6 ready. - - **subsets.addresses.hostname** (string) + - **subsets.addresses.hostname** (string) - The Hostname of this endpoint + The Hostname of this endpoint - - **subsets.addresses.nodeName** (string) + - **subsets.addresses.nodeName** (string) - Optional: Node hosting this endpoint. This can be used to determine endpoints local to a node. + Optional: Node hosting this endpoint. This can be used to determine endpoints local to a node. - - **subsets.addresses.targetRef** (}}">ObjectReference) + - **subsets.addresses.targetRef** (}}">ObjectReference) - Reference to object providing the endpoint. + Reference to object providing the endpoint. - **subsets.notReadyAddresses** ([]EndpointAddress) @@ -85,21 +97,21 @@ Endpoints is a collection of endpoints that implement the actual service. Exampl *EndpointAddress is a tuple that describes single IP address.* - - **subsets.notReadyAddresses.ip** (string), required + - **subsets.notReadyAddresses.ip** (string), required - The IP of this endpoint. May not be loopback (127.0.0.0/8), link-local (169.254.0.0/16), or link-local multicast ((224.0.0.0/24). IPv6 is also accepted but not fully supported on all platforms. Also, certain kubernetes components, like kube-proxy, are not IPv6 ready. + The IP of this endpoint. May not be loopback (127.0.0.0/8), link-local (169.254.0.0/16), or link-local multicast ((224.0.0.0/24). IPv6 is also accepted but not fully supported on all platforms. Also, certain kubernetes components, like kube-proxy, are not IPv6 ready. - - **subsets.notReadyAddresses.hostname** (string) + - **subsets.notReadyAddresses.hostname** (string) - The Hostname of this endpoint + The Hostname of this endpoint - - **subsets.notReadyAddresses.nodeName** (string) + - **subsets.notReadyAddresses.nodeName** (string) - Optional: Node hosting this endpoint. This can be used to determine endpoints local to a node. + Optional: Node hosting this endpoint. This can be used to determine endpoints local to a node. - - **subsets.notReadyAddresses.targetRef** (}}">ObjectReference) + - **subsets.notReadyAddresses.targetRef** (}}">ObjectReference) - Reference to object providing the endpoint. + Reference to object providing the endpoint. - **subsets.ports** ([]EndpointPort) @@ -108,21 +120,21 @@ Endpoints is a collection of endpoints that implement the actual service. Exampl *EndpointPort is a tuple that describes a single port.* - - **subsets.ports.port** (int32), required + - **subsets.ports.port** (int32), required - The port number of the endpoint. + The port number of the endpoint. - - **subsets.ports.protocol** (string) + - **subsets.ports.protocol** (string) - The IP protocol for this port. Must be UDP, TCP, or SCTP. Default is TCP. + The IP protocol for this port. Must be UDP, TCP, or SCTP. Default is TCP. - - **subsets.ports.name** (string) + - **subsets.ports.name** (string) - The name of this port. This must match the 'name' field in the corresponding ServicePort. Must be a DNS_LABEL. Optional only if one port is defined. + The name of this port. This must match the 'name' field in the corresponding ServicePort. Must be a DNS_LABEL. Optional only if one port is defined. - - **subsets.ports.appProtocol** (string) + - **subsets.ports.appProtocol** (string) - The application protocol for this port. This field follows standard Kubernetes label syntax. Un-prefixed names are reserved for IANA standard service names (as per RFC-6335 and http://www.iana.org/assignments/service-names). Non-standard protocols should use prefixed names such as mycompany.com/my-custom-protocol. This is a beta field that is guarded by the ServiceAppProtocol feature gate and enabled by default. + The application protocol for this port. This field follows standard Kubernetes label syntax. Un-prefixed names are reserved for IANA standard service names (as per RFC-6335 and http://www.iana.org/assignments/service-names). Non-standard protocols should use prefixed names such as mycompany.com/my-custom-protocol. @@ -484,6 +496,8 @@ PATCH /api/v1/namespaces/{namespace}/endpoints/{name} 200 (}}">Endpoints): OK +201 (}}">Endpoints): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/service-resources/ingress-class-v1.md b/content/en/docs/reference/kubernetes-api/service-resources/ingress-class-v1.md index 92ad085310..335597af49 100644 --- a/content/en/docs/reference/kubernetes-api/service-resources/ingress-class-v1.md +++ b/content/en/docs/reference/kubernetes-api/service-resources/ingress-class-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "IngressClass represents the class of the Ingress, referenced by the Ingress Spec." title: "IngressClass" weight: 5 +auto_generated: true --- + + `apiVersion: networking.k8s.io/v1` `import "k8s.io/api/networking/v1"` @@ -48,10 +60,33 @@ IngressClassSpec provides information about the class of an Ingress. Controller refers to the name of the controller that should handle this class. This allows for different "flavors" that are controlled by the same controller. For example, you may have different Parameters for the same implementing controller. This should be specified as a domain-prefixed path no more than 250 characters in length, e.g. "acme.io/ingress-controller". This field is immutable. -- **parameters** (}}">TypedLocalObjectReference) +- **parameters** (IngressClassParametersReference) Parameters is a link to a custom resource containing additional configuration for the controller. This is optional if the controller does not require extra parameters. + + *IngressClassParametersReference identifies an API object. This can be used to specify a cluster or namespace-scoped resource.* + + - **parameters.kind** (string), required + + Kind is the type of resource being referenced. + + - **parameters.name** (string), required + + Name is the name of resource being referenced. + + - **parameters.apiGroup** (string) + + APIGroup is the group for the resource being referenced. If APIGroup is not specified, the specified Kind must be in the core API group. For any other third-party types, APIGroup is required. + + - **parameters.namespace** (string) + + Namespace is the namespace of the resource being referenced. This field is required when scope is set to "Namespace" and must be unset when scope is set to "Cluster". + + - **parameters.scope** (string) + + Scope represents if this refers to a cluster or namespace scoped resource. This may be set to "Cluster" (default) or "Namespace". Field can be enabled with IngressClassNamespacedParams feature gate. + @@ -319,6 +354,8 @@ PATCH /apis/networking.k8s.io/v1/ingressclasses/{name} 200 (}}">IngressClass): OK +201 (}}">IngressClass): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/service-resources/ingress-v1.md b/content/en/docs/reference/kubernetes-api/service-resources/ingress-v1.md index 72a0383f96..7bdec1fcb2 100644 --- a/content/en/docs/reference/kubernetes-api/service-resources/ingress-v1.md +++ b/content/en/docs/reference/kubernetes-api/service-resources/ingress-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "Ingress is a collection of rules that allow inbound connections to reach the endpoints defined by a backend." title: "Ingress" weight: 4 +auto_generated: true --- + + `apiVersion: networking.k8s.io/v1` `import "k8s.io/api/networking/v1"` @@ -48,43 +60,10 @@ IngressSpec describes the Ingress the user wishes to exist.
-- **defaultBackend** (IngressBackend) +- **defaultBackend** (}}">IngressBackend) DefaultBackend is the backend that should handle requests that don't match any rule. If Rules are not specified, DefaultBackend must be specified. If DefaultBackend is not set, the handling of requests that do not match any of the rules will be up to the Ingress controller. - - *IngressBackend describes all endpoints for a given service and port.* - - - **defaultBackend.resource** (}}">TypedLocalObjectReference) - - Resource is an ObjectRef to another Kubernetes resource in the namespace of the Ingress object. If resource is specified, a service.Name and service.Port must not be specified. This is a mutually exclusive setting with "Service". - - - **defaultBackend.service** (IngressServiceBackend) - - Service references a Service as a Backend. This is a mutually exclusive setting with "Resource". - - - *IngressServiceBackend references a Kubernetes Service as a Backend.* - - - **defaultBackend.service.name** (string), required - - Name is the referenced service. The service must exist in the same namespace as the Ingress object. - - - **defaultBackend.service.port** (ServiceBackendPort) - - Port of the referenced service. A port name or port number is required for a IngressServiceBackend. - - - *ServiceBackendPort is the service port being referenced.* - - - **defaultBackend.service.port.name** (string) - - Name is the name of the port on the Service. This is a mutually exclusive setting with "Number". - - - **defaultBackend.service.port.number** (int32) - - Number is the numerical port number (e.g. 80) on the Service. This is a mutually exclusive setting with "Name". - - **ingressClassName** (string) IngressClassName is the name of the IngressClass cluster resource. The associated IngressClass defines which controller will implement the resource. This replaces the deprecated `kubernetes.io/ingress.class` annotation. For backwards compatibility, when that annotation is set, it must be given precedence over this field. The controller may emit a warning if the field and annotation have different values. Implementations of this API should ignore Ingresses without a class specified. An IngressClass resource may be marked as default, which can be used to set a default value for this field. For more information, refer to the IngressClass documentation. @@ -115,69 +94,36 @@ IngressSpec describes the Ingress the user wishes to exist. *HTTPIngressRuleValue is a list of http selectors pointing to backends. In the example: http:///? -> backend where where parts of the url correspond to RFC 3986, this resource will be used to match against everything after the last '/' and before the first '?' or '#'.* - - **rules.http.paths** ([]HTTPIngressPath), required + - **rules.http.paths** ([]HTTPIngressPath), required - *Atomic: will be replaced during a merge* - - A collection of paths that map requests to backends. + *Atomic: will be replaced during a merge* + + A collection of paths that map requests to backends. - - *HTTPIngressPath associates a path with a backend. Incoming urls matching the path are forwarded to the backend.* + + *HTTPIngressPath associates a path with a backend. Incoming urls matching the path are forwarded to the backend.* - - **rules.http.paths.backend** (IngressBackend), required + - **rules.http.paths.backend** (}}">IngressBackend), required - Backend defines the referenced service endpoint to which the traffic will be forwarded to. + Backend defines the referenced service endpoint to which the traffic will be forwarded to. - - *IngressBackend describes all endpoints for a given service and port.* + - **rules.http.paths.pathType** (string), required - - **rules.http.paths.backend.resource** (}}">TypedLocalObjectReference) + PathType determines the interpretation of the Path matching. PathType can be one of the following values: * Exact: Matches the URL path exactly. * Prefix: Matches based on a URL path prefix split by '/'. Matching is + done on a path element by element basis. A path element refers is the + list of labels in the path split by the '/' separator. A request is a + match for path p if every p is an element-wise prefix of p of the + request path. Note that if the last element of the path is a substring + of the last element in request path, it is not a match (e.g. /foo/bar + matches /foo/bar/baz, but does not match /foo/barbaz). + * ImplementationSpecific: Interpretation of the Path matching is up to + the IngressClass. Implementations can treat this as a separate PathType + or treat it identically to Prefix or Exact path types. + Implementations are required to support all path types. - Resource is an ObjectRef to another Kubernetes resource in the namespace of the Ingress object. If resource is specified, a service.Name and service.Port must not be specified. This is a mutually exclusive setting with "Service". + - **rules.http.paths.path** (string) - - **rules.http.paths.backend.service** (IngressServiceBackend) - - Service references a Service as a Backend. This is a mutually exclusive setting with "Resource". - - - *IngressServiceBackend references a Kubernetes Service as a Backend.* - - - **rules.http.paths.backend.service.name** (string), required - - Name is the referenced service. The service must exist in the same namespace as the Ingress object. - - - **rules.http.paths.backend.service.port** (ServiceBackendPort) - - Port of the referenced service. A port name or port number is required for a IngressServiceBackend. - - - *ServiceBackendPort is the service port being referenced.* - - - **rules.http.paths.backend.service.port.name** (string) - - Name is the name of the port on the Service. This is a mutually exclusive setting with "Number". - - - **rules.http.paths.backend.service.port.number** (int32) - - Number is the numerical port number (e.g. 80) on the Service. This is a mutually exclusive setting with "Name". - - - **rules.http.paths.path** (string) - - Path is matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a '/'. When unspecified, all paths from incoming requests are matched. - - - **rules.http.paths.pathType** (string) - - PathType determines the interpretation of the Path matching. PathType can be one of the following values: * Exact: Matches the URL path exactly. * Prefix: Matches based on a URL path prefix split by '/'. Matching is - done on a path element by element basis. A path element refers is the - list of labels in the path split by the '/' separator. A request is a - match for path p if every p is an element-wise prefix of p of the - request path. Note that if the last element of the path is a substring - of the last element in request path, it is not a match (e.g. /foo/bar - matches /foo/bar/baz, but does not match /foo/barbaz). - * ImplementationSpecific: Interpretation of the Path matching is up to - the IngressClass. Implementations can treat this as a separate PathType - or treat it identically to Prefix or Exact path types. - Implementations are required to support all path types. + Path is matched against the path of an incoming request. Currently it can contain characters disallowed from the conventional "path" part of a URL as defined by RFC 3986. Paths must begin with a '/' and must be present when using PathType with value "Exact" or "Prefix". - **tls** ([]IngressTLS) @@ -202,6 +148,46 @@ IngressSpec describes the Ingress the user wishes to exist. +## IngressBackend {#IngressBackend} + +IngressBackend describes all endpoints for a given service and port. + +
+ +- **resource** (}}">TypedLocalObjectReference) + + Resource is an ObjectRef to another Kubernetes resource in the namespace of the Ingress object. If resource is specified, a service.Name and service.Port must not be specified. This is a mutually exclusive setting with "Service". + +- **service** (IngressServiceBackend) + + Service references a Service as a Backend. This is a mutually exclusive setting with "Resource". + + + *IngressServiceBackend references a Kubernetes Service as a Backend.* + + - **service.name** (string), required + + Name is the referenced service. The service must exist in the same namespace as the Ingress object. + + - **service.port** (ServiceBackendPort) + + Port of the referenced service. A port name or port number is required for a IngressServiceBackend. + + + *ServiceBackendPort is the service port being referenced.* + + - **service.port.name** (string) + + Name is the name of the port on the Service. This is a mutually exclusive setting with "Number". + + - **service.port.number** (int32) + + Number is the numerical port number (e.g. 80) on the Service. This is a mutually exclusive setting with "Name". + + + + + ## IngressStatus {#IngressStatus} IngressStatus describe the current state of the Ingress. @@ -222,37 +208,37 @@ IngressStatus describe the current state of the Ingress. *LoadBalancerIngress represents the status of a load-balancer ingress point: traffic intended for the service should be sent to an ingress point.* - - **loadBalancer.ingress.hostname** (string) + - **loadBalancer.ingress.hostname** (string) - Hostname is set for load-balancer ingress points that are DNS based (typically AWS load-balancers) + Hostname is set for load-balancer ingress points that are DNS based (typically AWS load-balancers) - - **loadBalancer.ingress.ip** (string) + - **loadBalancer.ingress.ip** (string) - IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers) + IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers) - - **loadBalancer.ingress.ports** ([]PortStatus) + - **loadBalancer.ingress.ports** ([]PortStatus) - *Atomic: will be replaced during a merge* - - Ports is a list of records of service ports If used, every port defined in the service should have an entry in it + *Atomic: will be replaced during a merge* + + Ports is a list of records of service ports If used, every port defined in the service should have an entry in it - - ** + + ** - - **loadBalancer.ingress.ports.port** (int32), required + - **loadBalancer.ingress.ports.port** (int32), required - Port is the port number of the service port of which status is recorded here + Port is the port number of the service port of which status is recorded here - - **loadBalancer.ingress.ports.protocol** (string), required + - **loadBalancer.ingress.ports.protocol** (string), required - Protocol is the protocol of the service port of which status is recorded here The supported values are: "TCP", "UDP", "SCTP" + Protocol is the protocol of the service port of which status is recorded here The supported values are: "TCP", "UDP", "SCTP" - - **loadBalancer.ingress.ports.error** (string) + - **loadBalancer.ingress.ports.error** (string) - Error is to record the problem with the service port The format of the error shall comply with the following rules: - built-in error values shall be specified in this file and those shall use - CamelCase names - - cloud provider specific error values must have names that comply with the - format foo.example.com/CamelCase. + Error is to record the problem with the service port The format of the error shall comply with the following rules: - built-in error values shall be specified in this file and those shall use + CamelCase names + - cloud provider specific error values must have names that comply with the + format foo.example.com/CamelCase. @@ -264,20 +250,22 @@ IngressList is a collection of Ingress.
-- **apiVersion**: networking.k8s.io/v1 +- **items** ([]}}">Ingress), required + Items is the list of Ingress. -- **kind**: IngressList +- **apiVersion** (string) + APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources + +- **kind** (string) + + Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds - **metadata** (}}">ListMeta) Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata -- **items** ([]}}">Ingress), required - - Items is the list of Ingress. - @@ -697,6 +685,8 @@ PATCH /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name} 200 (}}">Ingress): OK +201 (}}">Ingress): Created + 401: Unauthorized @@ -750,6 +740,8 @@ PATCH /apis/networking.k8s.io/v1/namespaces/{namespace}/ingresses/{name}/status 200 (}}">Ingress): OK +201 (}}">Ingress): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/service-resources/service-v1.md b/content/en/docs/reference/kubernetes-api/service-resources/service-v1.md index 3ed9e93d96..c49b2607c1 100644 --- a/content/en/docs/reference/kubernetes-api/service-resources/service-v1.md +++ b/content/en/docs/reference/kubernetes-api/service-resources/service-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "Service is a named abstraction of software service (for example, mysql) consisting of local port (for example 3306) that the proxy listens on, and the selector that determines which pods will answer requests sent through the proxy." title: "Service" weight: 1 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` @@ -88,7 +100,7 @@ ServiceSpec describes the attributes that a user creates on a service. - **ports.appProtocol** (string) - The application protocol for this port. This field follows standard Kubernetes label syntax. Un-prefixed names are reserved for IANA standard service names (as per RFC-6335 and http://www.iana.org/assignments/service-names). Non-standard protocols should use prefixed names such as mycompany.com/my-custom-protocol. This is a beta field that is guarded by the ServiceAppProtocol feature gate and enabled by default. + The application protocol for this port. This field follows standard Kubernetes label syntax. Un-prefixed names are reserved for IANA standard service names (as per RFC-6335 and http://www.iana.org/assignments/service-names). Non-standard protocols should use prefixed names such as mycompany.com/my-custom-protocol. - **type** (string) @@ -132,16 +144,24 @@ ServiceSpec describes the attributes that a user creates on a service. - **loadBalancerSourceRanges** ([]string) - If specified and supported by the platform, this will restrict traffic through the cloud-provider load-balancer will be restricted to the specified client IPs. This field will be ignored if the cloud-provider does not support the feature." More info: https://kubernetes.io/docs/tasks/access-application-cluster/configure-cloud-provider-firewall/ + If specified and supported by the platform, this will restrict traffic through the cloud-provider load-balancer will be restricted to the specified client IPs. This field will be ignored if the cloud-provider does not support the feature." More info: https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/ + +- **loadBalancerClass** (string) + + loadBalancerClass is the class of the load balancer implementation this Service belongs to. If specified, the value of this field must be a label-style identifier, with an optional prefix, e.g. "internal-vip" or "example.com/internal-vip". Unprefixed names are reserved for end-users. This field can only be set when the Service type is 'LoadBalancer'. If not set, the default load balancer implementation is used, today this is typically done through the cloud provider integration, but should apply for any default implementation. If set, it is assumed that a load balancer implementation is watching for Services with a matching class. Any default load balancer implementation (e.g. cloud providers) should ignore Services that set this field. This field can only be set when creating or updating a Service to type 'LoadBalancer'. Once set, it can not be changed. This field will be wiped when a service is updated to a non 'LoadBalancer' type. - **externalName** (string) - externalName is the external reference that discovery mechanisms will return as an alias for this service (e.g. a DNS CNAME record). No proxying will be involved. Must be a lowercase RFC-1123 hostname (https://tools.ietf.org/html/rfc1123) and requires Type to be + externalName is the external reference that discovery mechanisms will return as an alias for this service (e.g. a DNS CNAME record). No proxying will be involved. Must be a lowercase RFC-1123 hostname (https://tools.ietf.org/html/rfc1123) and requires `type` to be "ExternalName". - **externalTrafficPolicy** (string) externalTrafficPolicy denotes if this Service desires to route external traffic to node-local or cluster-wide endpoints. "Local" preserves the client source IP and avoids a second hop for LoadBalancer and Nodeport type services, but risks potentially imbalanced traffic spreading. "Cluster" obscures the client source IP and may cause a second hop to another node, but should have good overall load-spreading. +- **internalTrafficPolicy** (string) + + InternalTrafficPolicy specifies if the cluster internal traffic should be routed to all endpoints or node-local endpoints only. "Cluster" routes internal traffic to a Service to all endpoints. "Local" routes traffic to node-local endpoints only, traffic is dropped if no node-local endpoints are ready. The default value is "Cluster". + - **healthCheckNodePort** (int32) healthCheckNodePort specifies the healthcheck nodePort for the service. This only applies when type is set to LoadBalancer and externalTrafficPolicy is set to Local. If a value is specified, is in-range, and is not in use, it will be used. If not specified, a value will be automatically allocated. External systems (e.g. load-balancers) can use this port to determine if a given node holds endpoints for this service or not. If this field is specified when creating a Service which does not need it, creation will fail. This field will be wiped when updating a Service to no longer need it (e.g. changing type). @@ -164,17 +184,13 @@ ServiceSpec describes the attributes that a user creates on a service. *ClientIPConfig represents the configurations of Client IP based session affinity.* - - **sessionAffinityConfig.clientIP.timeoutSeconds** (int32) + - **sessionAffinityConfig.clientIP.timeoutSeconds** (int32) - timeoutSeconds specifies the seconds of ClientIP type session sticky time. The value must be >0 && \<=86400(for 1 day) if ServiceAffinity == "ClientIP". Default value is 10800(for 3 hours). - -- **topologyKeys** ([]string) - - topologyKeys is a preference-order list of topology keys which implementations of services should use to preferentially sort endpoints when accessing this Service, it can not be used at the same time as externalTrafficPolicy=Local. Topology keys must be valid label keys and at most 16 keys may be specified. Endpoints are chosen based on the first topology key with available backends. If this field is specified and all entries have no backends that match the topology of the client, the service has no backends for that client and connections should fail. The special value "*" may be used to mean "any topology". This catch-all value, if used, only makes sense as the last value in the list. If this is not specified or empty, no topology constraints will be applied. This field is alpha-level and is only honored by servers that enable the ServiceTopology feature. + timeoutSeconds specifies the seconds of ClientIP type session sticky time. The value must be >0 && \<=86400(for 1 day) if ServiceAffinity == "ClientIP". Default value is 10800(for 3 hours). - **allocateLoadBalancerNodePorts** (boolean) - allocateLoadBalancerNodePorts defines if NodePorts will be automatically allocated for services with type LoadBalancer. Default is "true". It may be set to "false" if the cluster load-balancer does not rely on NodePorts. allocateLoadBalancerNodePorts may only be set for services with type LoadBalancer and will be cleared if the type is changed to any other type. This field is alpha-level and is only honored by servers that enable the ServiceLBNodePortControl feature. + allocateLoadBalancerNodePorts defines if NodePorts will be automatically allocated for services with type LoadBalancer. Default is "true". It may be set to "false" if the cluster load-balancer does not rely on NodePorts. If the caller requests specific NodePorts (by specifying a value), those requests will be respected, regardless of this field. This field may only be set for services with type LoadBalancer and will be cleared if the type is changed to any other type. This field is beta-level and is only honored by servers that enable the ServiceLBNodePortControl feature. @@ -238,37 +254,37 @@ ServiceStatus represents the current status of a service. *LoadBalancerIngress represents the status of a load-balancer ingress point: traffic intended for the service should be sent to an ingress point.* - - **loadBalancer.ingress.hostname** (string) + - **loadBalancer.ingress.hostname** (string) - Hostname is set for load-balancer ingress points that are DNS based (typically AWS load-balancers) + Hostname is set for load-balancer ingress points that are DNS based (typically AWS load-balancers) - - **loadBalancer.ingress.ip** (string) + - **loadBalancer.ingress.ip** (string) - IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers) + IP is set for load-balancer ingress points that are IP based (typically GCE or OpenStack load-balancers) - - **loadBalancer.ingress.ports** ([]PortStatus) + - **loadBalancer.ingress.ports** ([]PortStatus) - *Atomic: will be replaced during a merge* - - Ports is a list of records of service ports If used, every port defined in the service should have an entry in it + *Atomic: will be replaced during a merge* + + Ports is a list of records of service ports If used, every port defined in the service should have an entry in it - - ** + + ** - - **loadBalancer.ingress.ports.port** (int32), required + - **loadBalancer.ingress.ports.port** (int32), required - Port is the port number of the service port of which status is recorded here + Port is the port number of the service port of which status is recorded here - - **loadBalancer.ingress.ports.protocol** (string), required + - **loadBalancer.ingress.ports.protocol** (string), required - Protocol is the protocol of the service port of which status is recorded here The supported values are: "TCP", "UDP", "SCTP" + Protocol is the protocol of the service port of which status is recorded here The supported values are: "TCP", "UDP", "SCTP" - - **loadBalancer.ingress.ports.error** (string) + - **loadBalancer.ingress.ports.error** (string) - Error is to record the problem with the service port The format of the error shall comply with the following rules: - built-in error values shall be specified in this file and those shall use - CamelCase names - - cloud provider specific error values must have names that comply with the - format foo.example.com/CamelCase. + Error is to record the problem with the service port The format of the error shall comply with the following rules: - built-in error values shall be specified in this file and those shall use + CamelCase names + - cloud provider specific error values must have names that comply with the + format foo.example.com/CamelCase. @@ -713,6 +729,8 @@ PATCH /api/v1/namespaces/{namespace}/services/{name} 200 (}}">Service): OK +201 (}}">Service): Created + 401: Unauthorized @@ -766,6 +784,8 @@ PATCH /api/v1/namespaces/{namespace}/services/{name}/status 200 (}}">Service): OK +201 (}}">Service): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/_index.md b/content/en/docs/reference/kubernetes-api/workload-resources/_index.md index 85d1bfa44f..7c4e44d99a 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/_index.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/_index.md @@ -1,4 +1,17 @@ --- title: "Workload Resources" weight: 1 +auto_generated: true --- + + + diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/container.md b/content/en/docs/reference/kubernetes-api/workload-resources/container.md deleted file mode 100644 index d87cd422c8..0000000000 --- a/content/en/docs/reference/kubernetes-api/workload-resources/container.md +++ /dev/null @@ -1,774 +0,0 @@ ---- -api_metadata: - apiVersion: "" - import: "k8s.io/api/core/v1" - kind: "Container" -content_type: "api_reference" -description: "A single application container that you want to run within a pod." -title: "Container" -weight: 2 ---- - - - -`import "k8s.io/api/core/v1"` - - -## Container {#Container} - -A single application container that you want to run within a pod. - -
- -- **name** (string), required - - Name of the container specified as a DNS_LABEL. Each container in a pod must have a unique name (DNS_LABEL). Cannot be updated. - - - -### Image - - -- **image** (string) - - Docker image name. More info: https://kubernetes.io/docs/concepts/containers/images This field is optional to allow higher level config management to default or override container images in workload controllers like Deployments and StatefulSets. - -- **imagePullPolicy** (string) - - Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated. More info: https://kubernetes.io/docs/concepts/containers/images#updating-images - -### Entrypoint - - -- **command** ([]string) - - Entrypoint array. Not executed within a shell. The docker image's ENTRYPOINT is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container's environment. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell - -- **args** ([]string) - - Arguments to the entrypoint. The docker image's CMD is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container's environment. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell - -- **workingDir** (string) - - Container's working directory. If not specified, the container runtime's default will be used, which might be configured in the container image. Cannot be updated. - -### Ports - - -- **ports** ([]ContainerPort) - - *Patch strategy: merge on key `containerPort`* - - *Map: unique values on keys `containerPort, protocol` will be kept during a merge* - - List of ports to expose from the container. Exposing a port here gives the system additional information about the network connections a container uses, but is primarily informational. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. Cannot be updated. - - - *ContainerPort represents a network port in a single container.* - - - **ports.containerPort** (int32), required - - Number of port to expose on the pod's IP address. This must be a valid port number, 0 \< x \< 65536. - - - **ports.hostIP** (string) - - What host IP to bind the external port to. - - - **ports.hostPort** (int32) - - Number of port to expose on the host. If specified, this must be a valid port number, 0 \< x \< 65536. If HostNetwork is specified, this must match ContainerPort. Most containers do not need this. - - - **ports.name** (string) - - If specified, this must be an IANA_SVC_NAME and unique within the pod. Each named port in a pod must have a unique name. Name for the port that can be referred to by services. - - - **ports.protocol** (string) - - Protocol for port. Must be UDP, TCP, or SCTP. Defaults to "TCP". - -### Environment variables - - -- **env** ([]EnvVar) - - *Patch strategy: merge on key `name`* - - List of environment variables to set in the container. Cannot be updated. - - - *EnvVar represents an environment variable present in a Container.* - - - **env.name** (string), required - - Name of the environment variable. Must be a C_IDENTIFIER. - - - **env.value** (string) - - Variable references $(VAR_NAME) are expanded using the previous defined environment variables in the container and any service environment variables. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not. Defaults to "". - - - **env.valueFrom** (EnvVarSource) - - Source for the environment variable's value. Cannot be used if value is not empty. - - - *EnvVarSource represents a source for the value of an EnvVar.* - - - **env.valueFrom.configMapKeyRef** (ConfigMapKeySelector) - - Selects a key of a ConfigMap. - - - *Selects a key from a ConfigMap.* - - - **env.valueFrom.configMapKeyRef.key** (string), required - - The key to select. - - - **env.valueFrom.configMapKeyRef.name** (string) - - Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names - - - **env.valueFrom.configMapKeyRef.optional** (boolean) - - Specify whether the ConfigMap or its key must be defined - - - **env.valueFrom.fieldRef** (}}">ObjectFieldSelector) - - Selects a field of the pod: supports metadata.name, metadata.namespace, `metadata.labels['\']`, `metadata.annotations['\']`, spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs. - - - **env.valueFrom.resourceFieldRef** (}}">ResourceFieldSelector) - - Selects a resource of the container: only resources limits and requests (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory and requests.ephemeral-storage) are currently supported. - - - **env.valueFrom.secretKeyRef** (SecretKeySelector) - - Selects a key of a secret in the pod's namespace - - - *SecretKeySelector selects a key of a Secret.* - - - **env.valueFrom.secretKeyRef.key** (string), required - - The key of the secret to select from. Must be a valid secret key. - - - **env.valueFrom.secretKeyRef.name** (string) - - Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names - - - **env.valueFrom.secretKeyRef.optional** (boolean) - - Specify whether the Secret or its key must be defined - -- **envFrom** ([]EnvFromSource) - - List of sources to populate environment variables in the container. The keys defined within a source must be a C_IDENTIFIER. All invalid keys will be reported as an event when the container is starting. When a key exists in multiple sources, the value associated with the last source will take precedence. Values defined by an Env with a duplicate key will take precedence. Cannot be updated. - - - *EnvFromSource represents the source of a set of ConfigMaps* - - - **envFrom.configMapRef** (ConfigMapEnvSource) - - The ConfigMap to select from - - - *ConfigMapEnvSource selects a ConfigMap to populate the environment variables with. - - The contents of the target ConfigMap's Data field will represent the key-value pairs as environment variables.* - - - **envFrom.configMapRef.name** (string) - - Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names - - - **envFrom.configMapRef.optional** (boolean) - - Specify whether the ConfigMap must be defined - - - **envFrom.prefix** (string) - - An optional identifier to prepend to each key in the ConfigMap. Must be a C_IDENTIFIER. - - - **envFrom.secretRef** (SecretEnvSource) - - The Secret to select from - - - *SecretEnvSource selects a Secret to populate the environment variables with. - - The contents of the target Secret's Data field will represent the key-value pairs as environment variables.* - - - **envFrom.secretRef.name** (string) - - Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names - - - **envFrom.secretRef.optional** (boolean) - - Specify whether the Secret must be defined - -### Volumes - - -- **volumeMounts** ([]VolumeMount) - - *Patch strategy: merge on key `mountPath`* - - Pod volumes to mount into the container's filesystem. Cannot be updated. - - - *VolumeMount describes a mounting of a Volume within a container.* - - - **volumeMounts.mountPath** (string), required - - Path within the container at which the volume should be mounted. Must not contain ':'. - - - **volumeMounts.name** (string), required - - This must match the Name of a Volume. - - - **volumeMounts.mountPropagation** (string) - - mountPropagation determines how mounts are propagated from the host to container and the other way around. When not set, MountPropagationNone is used. This field is beta in 1.10. - - - **volumeMounts.readOnly** (boolean) - - Mounted read-only if true, read-write otherwise (false or unspecified). Defaults to false. - - - **volumeMounts.subPath** (string) - - Path within the volume from which the container's volume should be mounted. Defaults to "" (volume's root). - - - **volumeMounts.subPathExpr** (string) - - Expanded path within the volume from which the container's volume should be mounted. Behaves similarly to SubPath but environment variable references $(VAR_NAME) are expanded using the container's environment. Defaults to "" (volume's root). SubPathExpr and SubPath are mutually exclusive. - -- **volumeDevices** ([]VolumeDevice) - - *Patch strategy: merge on key `devicePath`* - - volumeDevices is the list of block devices to be used by the container. - - - *volumeDevice describes a mapping of a raw block device within a container.* - - - **volumeDevices.devicePath** (string), required - - devicePath is the path inside of the container that the device will be mapped to. - - - **volumeDevices.name** (string), required - - name must match the name of a persistentVolumeClaim in the pod - -### Resources - - -- **resources** (ResourceRequirements) - - Compute Resources required by this container. Cannot be updated. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/ - - - *ResourceRequirements describes the compute resource requirements.* - - - **resources.limits** (map[string]}}">Quantity) - - Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/ - - - **resources.requests** (map[string]}}">Quantity) - - Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/ - -### Lifecycle - - -- **lifecycle** (Lifecycle) - - Actions that the management system should take in response to container lifecycle events. Cannot be updated. - - - *Lifecycle describes actions that the management system should take in response to container lifecycle events. For the PostStart and PreStop lifecycle handlers, management of the container blocks until the action is complete, unless the container process fails, in which case the handler is aborted.* - - - **lifecycle.postStart** (Handler) - - PostStart is called immediately after a container is created. If the handler fails, the container is terminated and restarted according to its restart policy. Other management of the container blocks until the hook completes. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks - - - *Handler defines a specific action that should be taken* - - - **lifecycle.postStart.exec** (}}">ExecAction) - - One and only one of the following should be specified. Exec specifies the action to take. - - - **lifecycle.postStart.httpGet** (}}">HTTPGetAction) - - HTTPGet specifies the http request to perform. - - - **lifecycle.postStart.tcpSocket** (}}">TCPSocketAction) - - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported - - - **lifecycle.preStop** (Handler) - - PreStop is called immediately before a container is terminated due to an API request or management event such as liveness/startup probe failure, preemption, resource contention, etc. The handler is not called if the container crashes or exits. The reason for termination is passed to the handler. The Pod's termination grace period countdown begins before the PreStop hooked is executed. Regardless of the outcome of the handler, the container will eventually terminate within the Pod's termination grace period. Other management of the container blocks until the hook completes or until the termination grace period is reached. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks - - - *Handler defines a specific action that should be taken* - - - **lifecycle.preStop.exec** (}}">ExecAction) - - One and only one of the following should be specified. Exec specifies the action to take. - - - **lifecycle.preStop.httpGet** (}}">HTTPGetAction) - - HTTPGet specifies the http request to perform. - - - **lifecycle.preStop.tcpSocket** (}}">TCPSocketAction) - - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported - -- **terminationMessagePath** (string) - - Optional: Path at which the file to which the container's termination message will be written is mounted into the container's filesystem. Message written is intended to be brief final status, such as an assertion failure message. Will be truncated by the node if greater than 4096 bytes. The total message length across all containers will be limited to 12kb. Defaults to /dev/termination-log. Cannot be updated. - -- **terminationMessagePolicy** (string) - - Indicate how the termination message should be populated. File will use the contents of terminationMessagePath to populate the container status message on both success and failure. FallbackToLogsOnError will use the last chunk of container log output if the termination message file is empty and the container exited with an error. The log output is limited to 2048 bytes or 80 lines, whichever is smaller. Defaults to File. Cannot be updated. - -- **livenessProbe** (Probe) - - Periodic probe of container liveness. Container will be restarted if the probe fails. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes - - - *Probe describes a health check to be performed against a container to determine whether it is alive or ready to receive traffic.* - - - **livenessProbe.exec** (}}">ExecAction) - - One and only one of the following should be specified. Exec specifies the action to take. - - - **livenessProbe.httpGet** (}}">HTTPGetAction) - - HTTPGet specifies the http request to perform. - - - **livenessProbe.tcpSocket** (}}">TCPSocketAction) - - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported - - - **livenessProbe.initialDelaySeconds** (int32) - - Number of seconds after the container has started before liveness probes are initiated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes - - - **livenessProbe.periodSeconds** (int32) - - How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is 1. - - - **livenessProbe.timeoutSeconds** (int32) - - Number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes - - - **livenessProbe.failureThreshold** (int32) - - Minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3. Minimum value is 1. - - - **livenessProbe.successThreshold** (int32) - - Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness and startup. Minimum value is 1. - -- **readinessProbe** (Probe) - - Periodic probe of container service readiness. Container will be removed from service endpoints if the probe fails. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes - - - *Probe describes a health check to be performed against a container to determine whether it is alive or ready to receive traffic.* - - - **readinessProbe.exec** (}}">ExecAction) - - One and only one of the following should be specified. Exec specifies the action to take. - - - **readinessProbe.httpGet** (}}">HTTPGetAction) - - HTTPGet specifies the http request to perform. - - - **readinessProbe.tcpSocket** (}}">TCPSocketAction) - - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported - - - **readinessProbe.initialDelaySeconds** (int32) - - Number of seconds after the container has started before liveness probes are initiated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes - - - **readinessProbe.periodSeconds** (int32) - - How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is 1. - - - **readinessProbe.timeoutSeconds** (int32) - - Number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes - - - **readinessProbe.failureThreshold** (int32) - - Minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3. Minimum value is 1. - - - **readinessProbe.successThreshold** (int32) - - Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness and startup. Minimum value is 1. - -### Security Context - - -- **securityContext** (SecurityContext) - - Security options the pod should run with. More info: https://kubernetes.io/docs/concepts/policy/security-context/ More info: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ - - - *SecurityContext holds security configuration that will be applied to a container. Some fields are present in both SecurityContext and PodSecurityContext. When both are set, the values in SecurityContext take precedence.* - - - **securityContext.runAsUser** (int64) - - The UID to run the entrypoint of the container process. Defaults to user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. - - - **securityContext.runAsNonRoot** (boolean) - - Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. - - - **securityContext.runAsGroup** (int64) - - The GID to run the entrypoint of the container process. Uses runtime default if unset. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. - - - **securityContext.readOnlyRootFilesystem** (boolean) - - Whether this container has a read-only root filesystem. Default is false. - - - **securityContext.procMount** (string) - - procMount denotes the type of proc mount to use for the containers. The default is DefaultProcMount which uses the container runtime defaults for readonly paths and masked paths. This requires the ProcMountType feature flag to be enabled. - - - **securityContext.privileged** (boolean) - - Run container in privileged mode. Processes in privileged containers are essentially equivalent to root on the host. Defaults to false. - - - **securityContext.allowPrivilegeEscalation** (boolean) - - AllowPrivilegeEscalation controls whether a process can gain more privileges than its parent process. This bool directly controls if the no_new_privs flag will be set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged 2) has CAP_SYS_ADMIN - - - **securityContext.capabilities** (Capabilities) - - The capabilities to add/drop when running containers. Defaults to the default set of capabilities granted by the container runtime. - - - *Adds and removes POSIX capabilities from running containers.* - - - **securityContext.capabilities.add** ([]string) - - Added capabilities - - - **securityContext.capabilities.drop** ([]string) - - Removed capabilities - - - **securityContext.seccompProfile** (SeccompProfile) - - The seccomp options to use by this container. If seccomp options are provided at both the pod & container level, the container options override the pod options. - - - *SeccompProfile defines a pod/container's seccomp profile settings. Only one profile source may be set.* - - - **securityContext.seccompProfile.type** (string), required - - type indicates which kind of seccomp profile will be applied. Valid options are: - - Localhost - a profile defined in a file on the node should be used. RuntimeDefault - the container runtime default profile should be used. Unconfined - no profile should be applied. - - - **securityContext.seccompProfile.localhostProfile** (string) - - localhostProfile indicates a profile defined in a file on the node should be used. The profile must be preconfigured on the node to work. Must be a descending path, relative to the kubelet's configured seccomp profile location. Must only be set if type is "Localhost". - - - **securityContext.seLinuxOptions** (SELinuxOptions) - - The SELinux context to be applied to the container. If unspecified, the container runtime will allocate a random SELinux context for each container. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. - - - *SELinuxOptions are the labels to be applied to the container* - - - **securityContext.seLinuxOptions.level** (string) - - Level is SELinux level label that applies to the container. - - - **securityContext.seLinuxOptions.role** (string) - - Role is a SELinux role label that applies to the container. - - - **securityContext.seLinuxOptions.type** (string) - - Type is a SELinux type label that applies to the container. - - - **securityContext.seLinuxOptions.user** (string) - - User is a SELinux user label that applies to the container. - - - **securityContext.windowsOptions** (WindowsSecurityContextOptions) - - The Windows specific settings applied to all containers. If unspecified, the options from the PodSecurityContext will be used. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. - - - *WindowsSecurityContextOptions contain Windows-specific options and credentials.* - - - **securityContext.windowsOptions.gmsaCredentialSpec** (string) - - GMSACredentialSpec is where the GMSA admission webhook (https://github.com/kubernetes-sigs/windows-gmsa) inlines the contents of the GMSA credential spec named by the GMSACredentialSpecName field. - - - **securityContext.windowsOptions.gmsaCredentialSpecName** (string) - - GMSACredentialSpecName is the name of the GMSA credential spec to use. - - - **securityContext.windowsOptions.runAsUserName** (string) - - The UserName in Windows to run the entrypoint of the container process. Defaults to the user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. - -### Debugging - - -- **stdin** (boolean) - - Whether this container should allocate a buffer for stdin in the container runtime. If this is not set, reads from stdin in the container will always result in EOF. Default is false. - -- **stdinOnce** (boolean) - - Whether the container runtime should close the stdin channel after it has been opened by a single attach. When stdin is true the stdin stream will remain open across multiple attach sessions. If stdinOnce is set to true, stdin is opened on container start, is empty until the first client attaches to stdin, and then remains open and accepts data until the client disconnects, at which time stdin is closed and remains closed until the container is restarted. If this flag is false, a container processes that reads from stdin will never receive an EOF. Default is false - -- **tty** (boolean) - - Whether this container should allocate a TTY for itself, also requires 'stdin' to be true. Default is false. - -### Beta level - - -- **startupProbe** (Probe) - - StartupProbe indicates that the Pod has successfully initialized. If specified, no other probes are executed until this completes successfully. If this probe fails, the Pod will be restarted, just as if the livenessProbe failed. This can be used to provide different probe parameters at the beginning of a Pod's lifecycle, when it might take a long time to load data or warm a cache, than during steady-state operation. This cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes - - - *Probe describes a health check to be performed against a container to determine whether it is alive or ready to receive traffic.* - - - **startupProbe.exec** (}}">ExecAction) - - One and only one of the following should be specified. Exec specifies the action to take. - - - **startupProbe.httpGet** (}}">HTTPGetAction) - - HTTPGet specifies the http request to perform. - - - **startupProbe.tcpSocket** (}}">TCPSocketAction) - - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported - - - **startupProbe.initialDelaySeconds** (int32) - - Number of seconds after the container has started before liveness probes are initiated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes - - - **startupProbe.periodSeconds** (int32) - - How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is 1. - - - **startupProbe.timeoutSeconds** (int32) - - Number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes - - - **startupProbe.failureThreshold** (int32) - - Minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3. Minimum value is 1. - - - **startupProbe.successThreshold** (int32) - - Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness and startup. Minimum value is 1. - - - -## ContainerStatus {#ContainerStatus} - -ContainerStatus contains details for the current status of this container. - -
- -- **name** (string), required - - This must be a DNS_LABEL. Each container in a pod must have a unique name. Cannot be updated. - -- **image** (string), required - - The image the container is running. More info: https://kubernetes.io/docs/concepts/containers/images - -- **imageID** (string), required - - ImageID of the container's image. - -- **containerID** (string) - - Container's ID in the format 'docker://\'. - -- **state** (ContainerState) - - Details about the container's current condition. - - - *ContainerState holds a possible state of container. Only one of its members may be specified. If none of them is specified, the default one is ContainerStateWaiting.* - - - **state.running** (ContainerStateRunning) - - Details about a running container - - - *ContainerStateRunning is a running state of a container.* - - - **state.running.startedAt** (Time) - - Time at which the container was last (re-)started - - - *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* - - - **state.terminated** (ContainerStateTerminated) - - Details about a terminated container - - - *ContainerStateTerminated is a terminated state of a container.* - - - **state.terminated.containerID** (string) - - Container's ID in the format 'docker://\' - - - **state.terminated.exitCode** (int32), required - - Exit status from the last termination of the container - - - **state.terminated.startedAt** (Time) - - Time at which previous execution of the container started - - - *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* - - - **state.terminated.finishedAt** (Time) - - Time at which the container last terminated - - - *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* - - - **state.terminated.message** (string) - - Message regarding the last termination of the container - - - **state.terminated.reason** (string) - - (brief) reason from the last termination of the container - - - **state.terminated.signal** (int32) - - Signal from the last termination of the container - - - **state.waiting** (ContainerStateWaiting) - - Details about a waiting container - - - *ContainerStateWaiting is a waiting state of a container.* - - - **state.waiting.message** (string) - - Message regarding why the container is not yet running. - - - **state.waiting.reason** (string) - - (brief) reason the container is not yet running. - -- **lastState** (ContainerState) - - Details about the container's last termination condition. - - - *ContainerState holds a possible state of container. Only one of its members may be specified. If none of them is specified, the default one is ContainerStateWaiting.* - - - **lastState.running** (ContainerStateRunning) - - Details about a running container - - - *ContainerStateRunning is a running state of a container.* - - - **lastState.running.startedAt** (Time) - - Time at which the container was last (re-)started - - - *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* - - - **lastState.terminated** (ContainerStateTerminated) - - Details about a terminated container - - - *ContainerStateTerminated is a terminated state of a container.* - - - **lastState.terminated.containerID** (string) - - Container's ID in the format 'docker://\' - - - **lastState.terminated.exitCode** (int32), required - - Exit status from the last termination of the container - - - **lastState.terminated.startedAt** (Time) - - Time at which previous execution of the container started - - - *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* - - - **lastState.terminated.finishedAt** (Time) - - Time at which the container last terminated - - - *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* - - - **lastState.terminated.message** (string) - - Message regarding the last termination of the container - - - **lastState.terminated.reason** (string) - - (brief) reason from the last termination of the container - - - **lastState.terminated.signal** (int32) - - Signal from the last termination of the container - - - **lastState.waiting** (ContainerStateWaiting) - - Details about a waiting container - - - *ContainerStateWaiting is a waiting state of a container.* - - - **lastState.waiting.message** (string) - - Message regarding why the container is not yet running. - - - **lastState.waiting.reason** (string) - - (brief) reason the container is not yet running. - -- **ready** (boolean), required - - Specifies whether the container has passed its readiness probe. - -- **restartCount** (int32), required - - The number of times the container has been restarted, currently based on the number of dead containers that have not yet been removed. Note that this is calculated from dead containers. But those containers are subject to garbage collection. This value will get capped at 5 by GC. - -- **started** (boolean) - - Specifies whether the container has passed its startup probe. Initialized as false, becomes true after startupProbe is considered successful. Resets to false when the container is restarted, or if kubelet loses state temporarily. Is always true when no startupProbe is defined. - - - - - diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/controller-revision-v1.md b/content/en/docs/reference/kubernetes-api/workload-resources/controller-revision-v1.md index 5caea2a5d9..bf3ffa7f12 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/controller-revision-v1.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/controller-revision-v1.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "ControllerRevision implements an immutable snapshot of state data." title: "ControllerRevision" -weight: 9 +weight: 7 +auto_generated: true --- + + `apiVersion: apps/v1` `import "k8s.io/api/apps/v1"` @@ -428,6 +440,8 @@ PATCH /apis/apps/v1/namespaces/{namespace}/controllerrevisions/{name} 200 (}}">ControllerRevision): OK +201 (}}">ControllerRevision): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/cron-job-v1beta1.md b/content/en/docs/reference/kubernetes-api/workload-resources/cron-job-v1.md similarity index 79% rename from content/en/docs/reference/kubernetes-api/workload-resources/cron-job-v1beta1.md rename to content/en/docs/reference/kubernetes-api/workload-resources/cron-job-v1.md index c99aa57998..3aa5ceb8be 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/cron-job-v1beta1.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/cron-job-v1.md @@ -1,17 +1,29 @@ --- api_metadata: - apiVersion: "batch/v1beta1" - import: "k8s.io/api/batch/v1beta1" + apiVersion: "batch/v1" + import: "k8s.io/api/batch/v1" kind: "CronJob" content_type: "api_reference" description: "CronJob represents the configuration of a single cron job." -title: "CronJob v1beta1" -weight: 12 +title: "CronJob" +weight: 10 +auto_generated: true --- -`apiVersion: batch/v1beta1` + -`import "k8s.io/api/batch/v1beta1"` +`apiVersion: batch/v1` + +`import "k8s.io/api/batch/v1"` ## CronJob {#CronJob} @@ -20,7 +32,7 @@ CronJob represents the configuration of a single cron job.
-- **apiVersion**: batch/v1beta1 +- **apiVersion**: batch/v1 - **kind**: CronJob @@ -30,11 +42,11 @@ CronJob represents the configuration of a single cron job. Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata -- **spec** (}}">CronJobSpec) +- **spec** (}}">CronJobSpec) Specification of the desired behavior of a cron job, including the schedule. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status -- **status** (}}">CronJobStatus) +- **status** (}}">CronJobStatus) Current status of a cron job. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status @@ -81,11 +93,11 @@ CronJobSpec describes how the job execution will look like and when it will actu - **successfulJobsHistoryLimit** (int32) - The number of successful finished jobs to retain. This is a pointer to distinguish between explicit zero and not specified. Defaults to 3. + The number of successful finished jobs to retain. Value must be non-negative integer. Defaults to 3. - **failedJobsHistoryLimit** (int32) - The number of failed finished jobs to retain. This is a pointer to distinguish between explicit zero and not specified. Defaults to 1. + The number of failed finished jobs to retain. Value must be non-negative integer. Defaults to 1. @@ -99,6 +111,8 @@ CronJobStatus represents the current state of a cron job. - **active** ([]}}">ObjectReference) + *Atomic: will be replaced during a merge* + A list of pointers to currently running jobs. - **lastScheduleTime** (Time) @@ -108,6 +122,13 @@ CronJobStatus represents the current state of a cron job. *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* +- **lastSuccessfulTime** (Time) + + Information when was the last time the job successfully completed. + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + @@ -118,7 +139,7 @@ CronJobList is a collection of cron jobs.
-- **apiVersion**: batch/v1beta1 +- **apiVersion**: batch/v1 - **kind**: CronJobList @@ -128,7 +149,7 @@ CronJobList is a collection of cron jobs. Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata -- **items** ([]}}">CronJob), required +- **items** ([]}}">CronJob), required items is the list of CronJobs. @@ -151,7 +172,7 @@ CronJobList is a collection of cron jobs. #### HTTP Request -GET /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name} +GET /apis/batch/v1/namespaces/{namespace}/cronjobs/{name} #### Parameters @@ -175,7 +196,7 @@ GET /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name} #### Response -200 (}}">CronJob): OK +200 (}}">CronJob): OK 401: Unauthorized @@ -184,7 +205,7 @@ GET /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name} #### HTTP Request -GET /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}/status +GET /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}/status #### Parameters @@ -208,7 +229,7 @@ GET /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}/status #### Response -200 (}}">CronJob): OK +200 (}}">CronJob): OK 401: Unauthorized @@ -217,7 +238,7 @@ GET /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}/status #### HTTP Request -GET /apis/batch/v1beta1/namespaces/{namespace}/cronjobs +GET /apis/batch/v1/namespaces/{namespace}/cronjobs #### Parameters @@ -281,7 +302,7 @@ GET /apis/batch/v1beta1/namespaces/{namespace}/cronjobs #### Response -200 (}}">CronJobList): OK +200 (}}">CronJobList): OK 401: Unauthorized @@ -290,7 +311,7 @@ GET /apis/batch/v1beta1/namespaces/{namespace}/cronjobs #### HTTP Request -GET /apis/batch/v1beta1/cronjobs +GET /apis/batch/v1/cronjobs #### Parameters @@ -349,7 +370,7 @@ GET /apis/batch/v1beta1/cronjobs #### Response -200 (}}">CronJobList): OK +200 (}}">CronJobList): OK 401: Unauthorized @@ -358,7 +379,7 @@ GET /apis/batch/v1beta1/cronjobs #### HTTP Request -POST /apis/batch/v1beta1/namespaces/{namespace}/cronjobs +POST /apis/batch/v1/namespaces/{namespace}/cronjobs #### Parameters @@ -368,7 +389,7 @@ POST /apis/batch/v1beta1/namespaces/{namespace}/cronjobs }}">namespace -- **body**: }}">CronJob, required +- **body**: }}">CronJob, required @@ -392,11 +413,11 @@ POST /apis/batch/v1beta1/namespaces/{namespace}/cronjobs #### Response -200 (}}">CronJob): OK +200 (}}">CronJob): OK -201 (}}">CronJob): Created +201 (}}">CronJob): Created -202 (}}">CronJob): Accepted +202 (}}">CronJob): Accepted 401: Unauthorized @@ -405,7 +426,7 @@ POST /apis/batch/v1beta1/namespaces/{namespace}/cronjobs #### HTTP Request -PUT /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name} +PUT /apis/batch/v1/namespaces/{namespace}/cronjobs/{name} #### Parameters @@ -420,7 +441,7 @@ PUT /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name} }}">namespace -- **body**: }}">CronJob, required +- **body**: }}">CronJob, required @@ -444,9 +465,9 @@ PUT /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name} #### Response -200 (}}">CronJob): OK +200 (}}">CronJob): OK -201 (}}">CronJob): Created +201 (}}">CronJob): Created 401: Unauthorized @@ -455,7 +476,7 @@ PUT /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name} #### HTTP Request -PUT /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}/status +PUT /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}/status #### Parameters @@ -470,7 +491,7 @@ PUT /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}/status }}">namespace -- **body**: }}">CronJob, required +- **body**: }}">CronJob, required @@ -494,9 +515,9 @@ PUT /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}/status #### Response -200 (}}">CronJob): OK +200 (}}">CronJob): OK -201 (}}">CronJob): Created +201 (}}">CronJob): Created 401: Unauthorized @@ -505,7 +526,7 @@ PUT /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}/status #### HTTP Request -PATCH /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name} +PATCH /apis/batch/v1/namespaces/{namespace}/cronjobs/{name} #### Parameters @@ -549,7 +570,9 @@ PATCH /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name} #### Response -200 (}}">CronJob): OK +200 (}}">CronJob): OK + +201 (}}">CronJob): Created 401: Unauthorized @@ -558,7 +581,7 @@ PATCH /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name} #### HTTP Request -PATCH /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}/status +PATCH /apis/batch/v1/namespaces/{namespace}/cronjobs/{name}/status #### Parameters @@ -602,7 +625,9 @@ PATCH /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}/status #### Response -200 (}}">CronJob): OK +200 (}}">CronJob): OK + +201 (}}">CronJob): Created 401: Unauthorized @@ -611,7 +636,7 @@ PATCH /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name}/status #### HTTP Request -DELETE /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name} +DELETE /apis/batch/v1/namespaces/{namespace}/cronjobs/{name} #### Parameters @@ -666,7 +691,7 @@ DELETE /apis/batch/v1beta1/namespaces/{namespace}/cronjobs/{name} #### HTTP Request -DELETE /apis/batch/v1beta1/namespaces/{namespace}/cronjobs +DELETE /apis/batch/v1/namespaces/{namespace}/cronjobs #### Parameters diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/daemon-set-v1.md b/content/en/docs/reference/kubernetes-api/workload-resources/daemon-set-v1.md index 169d361c2a..9d7eb6c24c 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/daemon-set-v1.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/daemon-set-v1.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "DaemonSet represents the configuration of a daemon set." title: "DaemonSet" -weight: 10 +weight: 8 +auto_generated: true --- + + `apiVersion: apps/v1` `import "k8s.io/api/apps/v1"` @@ -78,12 +90,19 @@ DaemonSetSpec is the specification of a daemon set. *Spec to control the desired behavior of daemon set rolling update.* - - **updateStrategy.rollingUpdate.maxUnavailable** (IntOrString) + - **updateStrategy.rollingUpdate.maxSurge** (IntOrString) - The maximum number of DaemonSet pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of total number of DaemonSet pods at the start of the update (ex: 10%). Absolute number is calculated from percentage by rounding up. This cannot be 0. Default value is 1. Example: when this is set to 30%, at most 30% of the total number of nodes that should be running the daemon pod (i.e. status.desiredNumberScheduled) can have their pods stopped for an update at any given time. The update starts by stopping at most 30% of those DaemonSet pods and then brings up new DaemonSet pods in their place. Once the new pods are available, it then proceeds onto other DaemonSet pods, thus ensuring that at least 70% of original number of DaemonSet pods are available at all times during the update. + The maximum number of nodes with an existing available DaemonSet pod that can have an updated DaemonSet pod during during an update. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). This can not be 0 if MaxUnavailable is 0. Absolute number is calculated from percentage by rounding up to a minimum of 1. Default value is 0. Example: when this is set to 30%, at most 30% of the total number of nodes that should be running the daemon pod (i.e. status.desiredNumberScheduled) can have their a new pod created before the old pod is marked as deleted. The update starts by launching new pods on 30% of nodes. Once an updated pod is available (Ready for at least minReadySeconds) the old DaemonSet pod on that node is marked deleted. If the old pod becomes unavailable for any reason (Ready transitions to false, is evicted, or is drained) an updated pod is immediatedly created on that node without considering surge limits. Allowing surge implies the possibility that the resources consumed by the daemonset on any given node can double if the readiness check fails, and so resource intensive daemonsets should take into account that they may cause evictions during disruption. This is beta field and enabled/disabled by DaemonSetUpdateSurge feature gate. - - *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* + + *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* + + - **updateStrategy.rollingUpdate.maxUnavailable** (IntOrString) + + The maximum number of DaemonSet pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of total number of DaemonSet pods at the start of the update (ex: 10%). Absolute number is calculated from percentage by rounding up. This cannot be 0 if MaxSurge is 0 Default value is 1. Example: when this is set to 30%, at most 30% of the total number of nodes that should be running the daemon pod (i.e. status.desiredNumberScheduled) can have their pods stopped for an update at any given time. The update starts by stopping at most 30% of those DaemonSet pods and then brings up new DaemonSet pods in their place. Once the new pods are available, it then proceeds onto other DaemonSet pods, thus ensuring that at least 70% of original number of DaemonSet pods are available at all times during the update. + + + *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* - **revisionHistoryLimit** (int32) @@ -610,6 +629,8 @@ PATCH /apis/apps/v1/namespaces/{namespace}/daemonsets/{name} 200 (}}">DaemonSet): OK +201 (}}">DaemonSet): Created + 401: Unauthorized @@ -663,6 +684,8 @@ PATCH /apis/apps/v1/namespaces/{namespace}/daemonsets/{name}/status 200 (}}">DaemonSet): OK +201 (}}">DaemonSet): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/deployment-v1.md b/content/en/docs/reference/kubernetes-api/workload-resources/deployment-v1.md index 052a54bcc8..c56bf76df7 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/deployment-v1.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/deployment-v1.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "Deployment enables declarative updates for Pods and ReplicaSets." title: "Deployment" -weight: 7 +weight: 5 +auto_generated: true --- + + `apiVersion: apps/v1` `import "k8s.io/api/apps/v1"` @@ -28,7 +40,7 @@ Deployment enables declarative updates for Pods and ReplicaSets. - **metadata** (}}">ObjectMeta) - Standard object metadata. + Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **spec** (}}">DeploymentSpec) @@ -84,19 +96,19 @@ DeploymentSpec is the specification of the desired behavior of the Deployment. *Spec to control the desired behavior of rolling update.* - - **strategy.rollingUpdate.maxSurge** (IntOrString) + - **strategy.rollingUpdate.maxSurge** (IntOrString) - The maximum number of pods that can be scheduled above the desired number of pods. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). This can not be 0 if MaxUnavailable is 0. Absolute number is calculated from percentage by rounding up. Defaults to 25%. Example: when this is set to 30%, the new ReplicaSet can be scaled up immediately when the rolling update starts, such that the total number of old and new pods do not exceed 130% of desired pods. Once old pods have been killed, new ReplicaSet can be scaled up further, ensuring that total number of pods running at any time during the update is at most 130% of desired pods. + The maximum number of pods that can be scheduled above the desired number of pods. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). This can not be 0 if MaxUnavailable is 0. Absolute number is calculated from percentage by rounding up. Defaults to 25%. Example: when this is set to 30%, the new ReplicaSet can be scaled up immediately when the rolling update starts, such that the total number of old and new pods do not exceed 130% of desired pods. Once old pods have been killed, new ReplicaSet can be scaled up further, ensuring that total number of pods running at any time during the update is at most 130% of desired pods. - - *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* + + *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* - - **strategy.rollingUpdate.maxUnavailable** (IntOrString) + - **strategy.rollingUpdate.maxUnavailable** (IntOrString) - The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). Absolute number is calculated from percentage by rounding down. This can not be 0 if MaxSurge is 0. Defaults to 25%. Example: when this is set to 30%, the old ReplicaSet can be scaled down to 70% of desired pods immediately when the rolling update starts. Once new pods are ready, old ReplicaSet can be scaled down further, followed by scaling up the new ReplicaSet, ensuring that the total number of pods available at all times during the update is at least 70% of desired pods. + The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). Absolute number is calculated from percentage by rounding down. This can not be 0 if MaxSurge is 0. Defaults to 25%. Example: when this is set to 30%, the old ReplicaSet can be scaled down to 70% of desired pods immediately when the rolling update starts. Once new pods are ready, old ReplicaSet can be scaled down further, followed by scaling up the new ReplicaSet, ensuring that the total number of pods available at all times during the update is at least 70% of desired pods. - - *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* + + *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* - **revisionHistoryLimit** (int32) @@ -630,6 +642,8 @@ PATCH /apis/apps/v1/namespaces/{namespace}/deployments/{name} 200 (}}">Deployment): OK +201 (}}">Deployment): Created + 401: Unauthorized @@ -683,6 +697,8 @@ PATCH /apis/apps/v1/namespaces/{namespace}/deployments/{name}/status 200 (}}">Deployment): OK +201 (}}">Deployment): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/ephemeral-container.md b/content/en/docs/reference/kubernetes-api/workload-resources/ephemeral-container.md deleted file mode 100644 index 7355af9df8..0000000000 --- a/content/en/docs/reference/kubernetes-api/workload-resources/ephemeral-container.md +++ /dev/null @@ -1,571 +0,0 @@ ---- -api_metadata: - apiVersion: "" - import: "k8s.io/api/core/v1" - kind: "EphemeralContainer" -content_type: "api_reference" -description: "An EphemeralContainer is a container that may be added temporarily to an existing pod for user-initiated activities such as debugging." -title: "EphemeralContainer" -weight: 3 ---- - - - -`import "k8s.io/api/core/v1"` - - -An EphemeralContainer is a container that may be added temporarily to an existing pod for user-initiated activities such as debugging. Ephemeral containers have no resource or scheduling guarantees, and they will not be restarted when they exit or when a pod is removed or restarted. If an ephemeral container causes a pod to exceed its resource allocation, the pod may be evicted. Ephemeral containers may not be added by directly updating the pod spec. They must be added via the pod's ephemeralcontainers subresource, and they will appear in the pod spec once added. This is an alpha feature enabled by the EphemeralContainers feature flag. - -
- -- **name** (string), required - - Name of the ephemeral container specified as a DNS_LABEL. This name must be unique among all containers, init containers and ephemeral containers. - -- **targetContainerName** (string) - - If set, the name of the container from PodSpec that this ephemeral container targets. The ephemeral container will be run in the namespaces (IPC, PID, etc) of this container. If not set then the ephemeral container is run in whatever namespaces are shared for the pod. Note that the container runtime must support this feature. - - - -### Image {#Image} - - -- **image** (string) - - Docker image name. More info: https://kubernetes.io/docs/concepts/containers/images - -- **imagePullPolicy** (string) - - Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated. More info: https://kubernetes.io/docs/concepts/containers/images#updating-images - -### Entrypoint {#Entrypoint} - - -- **command** ([]string) - - Entrypoint array. Not executed within a shell. The docker image's ENTRYPOINT is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container's environment. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell - -- **args** ([]string) - - Arguments to the entrypoint. The docker image's CMD is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container's environment. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell - -- **workingDir** (string) - - Container's working directory. If not specified, the container runtime's default will be used, which might be configured in the container image. Cannot be updated. - -### Environment variables {#Environment-variables} - - -- **env** ([]EnvVar) - - *Patch strategy: merge on key `name`* - - List of environment variables to set in the container. Cannot be updated. - - - *EnvVar represents an environment variable present in a Container.* - - - **env.name** (string), required - - Name of the environment variable. Must be a C_IDENTIFIER. - - - **env.value** (string) - - Variable references $(VAR_NAME) are expanded using the previous defined environment variables in the container and any service environment variables. If a variable cannot be resolved, the reference in the input string will be unchanged. The $(VAR_NAME) syntax can be escaped with a double $$, ie: $$(VAR_NAME). Escaped references will never be expanded, regardless of whether the variable exists or not. Defaults to "". - - - **env.valueFrom** (EnvVarSource) - - Source for the environment variable's value. Cannot be used if value is not empty. - - - *EnvVarSource represents a source for the value of an EnvVar.* - - - **env.valueFrom.configMapKeyRef** (ConfigMapKeySelector) - - Selects a key of a ConfigMap. - - - *Selects a key from a ConfigMap.* - - - **env.valueFrom.configMapKeyRef.key** (string), required - - The key to select. - - - **env.valueFrom.configMapKeyRef.name** (string) - - Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names - - - **env.valueFrom.configMapKeyRef.optional** (boolean) - - Specify whether the ConfigMap or its key must be defined - - - **env.valueFrom.fieldRef** (}}">ObjectFieldSelector) - - Selects a field of the pod: supports metadata.name, metadata.namespace, `metadata.labels['\']`, `metadata.annotations['\']`, spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs. - - - **env.valueFrom.resourceFieldRef** (}}">ResourceFieldSelector) - - Selects a resource of the container: only resources limits and requests (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory and requests.ephemeral-storage) are currently supported. - - - **env.valueFrom.secretKeyRef** (SecretKeySelector) - - Selects a key of a secret in the pod's namespace - - - *SecretKeySelector selects a key of a Secret.* - - - **env.valueFrom.secretKeyRef.key** (string), required - - The key of the secret to select from. Must be a valid secret key. - - - **env.valueFrom.secretKeyRef.name** (string) - - Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names - - - **env.valueFrom.secretKeyRef.optional** (boolean) - - Specify whether the Secret or its key must be defined - -- **envFrom** ([]EnvFromSource) - - List of sources to populate environment variables in the container. The keys defined within a source must be a C_IDENTIFIER. All invalid keys will be reported as an event when the container is starting. When a key exists in multiple sources, the value associated with the last source will take precedence. Values defined by an Env with a duplicate key will take precedence. Cannot be updated. - - - *EnvFromSource represents the source of a set of ConfigMaps* - - - **envFrom.configMapRef** (ConfigMapEnvSource) - - The ConfigMap to select from - - - *ConfigMapEnvSource selects a ConfigMap to populate the environment variables with. - - The contents of the target ConfigMap's Data field will represent the key-value pairs as environment variables.* - - - **envFrom.configMapRef.name** (string) - - Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names - - - **envFrom.configMapRef.optional** (boolean) - - Specify whether the ConfigMap must be defined - - - **envFrom.prefix** (string) - - An optional identifier to prepend to each key in the ConfigMap. Must be a C_IDENTIFIER. - - - **envFrom.secretRef** (SecretEnvSource) - - The Secret to select from - - - *SecretEnvSource selects a Secret to populate the environment variables with. - - The contents of the target Secret's Data field will represent the key-value pairs as environment variables.* - - - **envFrom.secretRef.name** (string) - - Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names - - - **envFrom.secretRef.optional** (boolean) - - Specify whether the Secret must be defined - -### Volumes {#Volumes} - - -- **volumeMounts** ([]VolumeMount) - - *Patch strategy: merge on key `mountPath`* - - Pod volumes to mount into the container's filesystem. Cannot be updated. - - - *VolumeMount describes a mounting of a Volume within a container.* - - - **volumeMounts.mountPath** (string), required - - Path within the container at which the volume should be mounted. Must not contain ':'. - - - **volumeMounts.name** (string), required - - This must match the Name of a Volume. - - - **volumeMounts.mountPropagation** (string) - - mountPropagation determines how mounts are propagated from the host to container and the other way around. When not set, MountPropagationNone is used. This field is beta in 1.10. - - - **volumeMounts.readOnly** (boolean) - - Mounted read-only if true, read-write otherwise (false or unspecified). Defaults to false. - - - **volumeMounts.subPath** (string) - - Path within the volume from which the container's volume should be mounted. Defaults to "" (volume's root). - - - **volumeMounts.subPathExpr** (string) - - Expanded path within the volume from which the container's volume should be mounted. Behaves similarly to SubPath but environment variable references $(VAR_NAME) are expanded using the container's environment. Defaults to "" (volume's root). SubPathExpr and SubPath are mutually exclusive. - -- **volumeDevices** ([]VolumeDevice) - - *Patch strategy: merge on key `devicePath`* - - volumeDevices is the list of block devices to be used by the container. - - - *volumeDevice describes a mapping of a raw block device within a container.* - - - **volumeDevices.devicePath** (string), required - - devicePath is the path inside of the container that the device will be mapped to. - - - **volumeDevices.name** (string), required - - name must match the name of a persistentVolumeClaim in the pod - -### Lifecycle {#Lifecycle} - - -- **terminationMessagePath** (string) - - Optional: Path at which the file to which the container's termination message will be written is mounted into the container's filesystem. Message written is intended to be brief final status, such as an assertion failure message. Will be truncated by the node if greater than 4096 bytes. The total message length across all containers will be limited to 12kb. Defaults to /dev/termination-log. Cannot be updated. - -- **terminationMessagePolicy** (string) - - Indicate how the termination message should be populated. File will use the contents of terminationMessagePath to populate the container status message on both success and failure. FallbackToLogsOnError will use the last chunk of container log output if the termination message file is empty and the container exited with an error. The log output is limited to 2048 bytes or 80 lines, whichever is smaller. Defaults to File. Cannot be updated. - -### Debugging {#Debugging} - - -- **stdin** (boolean) - - Whether this container should allocate a buffer for stdin in the container runtime. If this is not set, reads from stdin in the container will always result in EOF. Default is false. - -- **stdinOnce** (boolean) - - Whether the container runtime should close the stdin channel after it has been opened by a single attach. When stdin is true the stdin stream will remain open across multiple attach sessions. If stdinOnce is set to true, stdin is opened on container start, is empty until the first client attaches to stdin, and then remains open and accepts data until the client disconnects, at which time stdin is closed and remains closed until the container is restarted. If this flag is false, a container processes that reads from stdin will never receive an EOF. Default is false - -- **tty** (boolean) - - Whether this container should allocate a TTY for itself, also requires 'stdin' to be true. Default is false. - -### Not allowed {#Not-allowed} - - -- **ports** ([]ContainerPort) - - Ports are not allowed for ephemeral containers. - - - *ContainerPort represents a network port in a single container.* - - - **ports.containerPort** (int32), required - - Number of port to expose on the pod's IP address. This must be a valid port number, 0 \< x \< 65536. - - - **ports.hostIP** (string) - - What host IP to bind the external port to. - - - **ports.hostPort** (int32) - - Number of port to expose on the host. If specified, this must be a valid port number, 0 \< x \< 65536. If HostNetwork is specified, this must match ContainerPort. Most containers do not need this. - - - **ports.name** (string) - - If specified, this must be an IANA_SVC_NAME and unique within the pod. Each named port in a pod must have a unique name. Name for the port that can be referred to by services. - - - **ports.protocol** (string) - - Protocol for port. Must be UDP, TCP, or SCTP. Defaults to "TCP". - -- **resources** (ResourceRequirements) - - Resources are not allowed for ephemeral containers. Ephemeral containers use spare resources already allocated to the pod. - - - *ResourceRequirements describes the compute resource requirements.* - - - **resources.limits** (map[string]}}">Quantity) - - Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/ - - - **resources.requests** (map[string]}}">Quantity) - - Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/ - -- **lifecycle** (Lifecycle) - - Lifecycle is not allowed for ephemeral containers. - - - *Lifecycle describes actions that the management system should take in response to container lifecycle events. For the PostStart and PreStop lifecycle handlers, management of the container blocks until the action is complete, unless the container process fails, in which case the handler is aborted.* - - - **lifecycle.postStart** (Handler) - - PostStart is called immediately after a container is created. If the handler fails, the container is terminated and restarted according to its restart policy. Other management of the container blocks until the hook completes. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks - - - *Handler defines a specific action that should be taken* - - - **lifecycle.postStart.exec** (}}">ExecAction) - - One and only one of the following should be specified. Exec specifies the action to take. - - - **lifecycle.postStart.httpGet** (}}">HTTPGetAction) - - HTTPGet specifies the http request to perform. - - - **lifecycle.postStart.tcpSocket** (}}">TCPSocketAction) - - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported - - - **lifecycle.preStop** (Handler) - - PreStop is called immediately before a container is terminated due to an API request or management event such as liveness/startup probe failure, preemption, resource contention, etc. The handler is not called if the container crashes or exits. The reason for termination is passed to the handler. The Pod's termination grace period countdown begins before the PreStop hooked is executed. Regardless of the outcome of the handler, the container will eventually terminate within the Pod's termination grace period. Other management of the container blocks until the hook completes or until the termination grace period is reached. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks - - - *Handler defines a specific action that should be taken* - - - **lifecycle.preStop.exec** (}}">ExecAction) - - One and only one of the following should be specified. Exec specifies the action to take. - - - **lifecycle.preStop.httpGet** (}}">HTTPGetAction) - - HTTPGet specifies the http request to perform. - - - **lifecycle.preStop.tcpSocket** (}}">TCPSocketAction) - - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported - -- **livenessProbe** (Probe) - - Probes are not allowed for ephemeral containers. - - - *Probe describes a health check to be performed against a container to determine whether it is alive or ready to receive traffic.* - - - **livenessProbe.exec** (}}">ExecAction) - - One and only one of the following should be specified. Exec specifies the action to take. - - - **livenessProbe.httpGet** (}}">HTTPGetAction) - - HTTPGet specifies the http request to perform. - - - **livenessProbe.tcpSocket** (}}">TCPSocketAction) - - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported - - - **livenessProbe.initialDelaySeconds** (int32) - - Number of seconds after the container has started before liveness probes are initiated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes - - - **livenessProbe.periodSeconds** (int32) - - How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is 1. - - - **livenessProbe.timeoutSeconds** (int32) - - Number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes - - - **livenessProbe.failureThreshold** (int32) - - Minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3. Minimum value is 1. - - - **livenessProbe.successThreshold** (int32) - - Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness and startup. Minimum value is 1. - -- **readinessProbe** (Probe) - - Probes are not allowed for ephemeral containers. - - - *Probe describes a health check to be performed against a container to determine whether it is alive or ready to receive traffic.* - - - **readinessProbe.exec** (}}">ExecAction) - - One and only one of the following should be specified. Exec specifies the action to take. - - - **readinessProbe.httpGet** (}}">HTTPGetAction) - - HTTPGet specifies the http request to perform. - - - **readinessProbe.tcpSocket** (}}">TCPSocketAction) - - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported - - - **readinessProbe.initialDelaySeconds** (int32) - - Number of seconds after the container has started before liveness probes are initiated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes - - - **readinessProbe.periodSeconds** (int32) - - How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is 1. - - - **readinessProbe.timeoutSeconds** (int32) - - Number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes - - - **readinessProbe.failureThreshold** (int32) - - Minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3. Minimum value is 1. - - - **readinessProbe.successThreshold** (int32) - - Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness and startup. Minimum value is 1. - -- **securityContext** (SecurityContext) - - SecurityContext is not allowed for ephemeral containers. - - - *SecurityContext holds security configuration that will be applied to a container. Some fields are present in both SecurityContext and PodSecurityContext. When both are set, the values in SecurityContext take precedence.* - - - **securityContext.runAsUser** (int64) - - The UID to run the entrypoint of the container process. Defaults to user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. - - - **securityContext.runAsNonRoot** (boolean) - - Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. - - - **securityContext.runAsGroup** (int64) - - The GID to run the entrypoint of the container process. Uses runtime default if unset. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. - - - **securityContext.readOnlyRootFilesystem** (boolean) - - Whether this container has a read-only root filesystem. Default is false. - - - **securityContext.procMount** (string) - - procMount denotes the type of proc mount to use for the containers. The default is DefaultProcMount which uses the container runtime defaults for readonly paths and masked paths. This requires the ProcMountType feature flag to be enabled. - - - **securityContext.privileged** (boolean) - - Run container in privileged mode. Processes in privileged containers are essentially equivalent to root on the host. Defaults to false. - - - **securityContext.allowPrivilegeEscalation** (boolean) - - AllowPrivilegeEscalation controls whether a process can gain more privileges than its parent process. This bool directly controls if the no_new_privs flag will be set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged 2) has CAP_SYS_ADMIN - - - **securityContext.capabilities** (Capabilities) - - The capabilities to add/drop when running containers. Defaults to the default set of capabilities granted by the container runtime. - - - *Adds and removes POSIX capabilities from running containers.* - - - **securityContext.capabilities.add** ([]string) - - Added capabilities - - - **securityContext.capabilities.drop** ([]string) - - Removed capabilities - - - **securityContext.seccompProfile** (SeccompProfile) - - The seccomp options to use by this container. If seccomp options are provided at both the pod & container level, the container options override the pod options. - - - *SeccompProfile defines a pod/container's seccomp profile settings. Only one profile source may be set.* - - - **securityContext.seccompProfile.type** (string), required - - type indicates which kind of seccomp profile will be applied. Valid options are: - - Localhost - a profile defined in a file on the node should be used. RuntimeDefault - the container runtime default profile should be used. Unconfined - no profile should be applied. - - - **securityContext.seccompProfile.localhostProfile** (string) - - localhostProfile indicates a profile defined in a file on the node should be used. The profile must be preconfigured on the node to work. Must be a descending path, relative to the kubelet's configured seccomp profile location. Must only be set if type is "Localhost". - - - **securityContext.seLinuxOptions** (SELinuxOptions) - - The SELinux context to be applied to the container. If unspecified, the container runtime will allocate a random SELinux context for each container. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. - - - *SELinuxOptions are the labels to be applied to the container* - - - **securityContext.seLinuxOptions.level** (string) - - Level is SELinux level label that applies to the container. - - - **securityContext.seLinuxOptions.role** (string) - - Role is a SELinux role label that applies to the container. - - - **securityContext.seLinuxOptions.type** (string) - - Type is a SELinux type label that applies to the container. - - - **securityContext.seLinuxOptions.user** (string) - - User is a SELinux user label that applies to the container. - - - **securityContext.windowsOptions** (WindowsSecurityContextOptions) - - The Windows specific settings applied to all containers. If unspecified, the options from the PodSecurityContext will be used. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. - - - *WindowsSecurityContextOptions contain Windows-specific options and credentials.* - - - **securityContext.windowsOptions.gmsaCredentialSpec** (string) - - GMSACredentialSpec is where the GMSA admission webhook (https://github.com/kubernetes-sigs/windows-gmsa) inlines the contents of the GMSA credential spec named by the GMSACredentialSpecName field. - - - **securityContext.windowsOptions.gmsaCredentialSpecName** (string) - - GMSACredentialSpecName is the name of the GMSA credential spec to use. - - - **securityContext.windowsOptions.runAsUserName** (string) - - The UserName in Windows to run the entrypoint of the container process. Defaults to the user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. - -- **startupProbe** (Probe) - - Probes are not allowed for ephemeral containers. - - - *Probe describes a health check to be performed against a container to determine whether it is alive or ready to receive traffic.* - - - **startupProbe.exec** (}}">ExecAction) - - One and only one of the following should be specified. Exec specifies the action to take. - - - **startupProbe.httpGet** (}}">HTTPGetAction) - - HTTPGet specifies the http request to perform. - - - **startupProbe.tcpSocket** (}}">TCPSocketAction) - - TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported - - - **startupProbe.initialDelaySeconds** (int32) - - Number of seconds after the container has started before liveness probes are initiated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes - - - **startupProbe.periodSeconds** (int32) - - How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is 1. - - - **startupProbe.timeoutSeconds** (int32) - - Number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes - - - **startupProbe.failureThreshold** (int32) - - Minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3. Minimum value is 1. - - - **startupProbe.successThreshold** (int32) - - Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness and startup. Minimum value is 1. - - - diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v1.md b/content/en/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v1.md index 8ed1581cbe..d2da0c286a 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v1.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v1.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "configuration of a horizontal pod autoscaler." title: "HorizontalPodAutoscaler" -weight: 14 +weight: 11 +auto_generated: true --- + + `apiVersion: autoscaling/v1` `import "k8s.io/api/autoscaling/v1"` @@ -555,6 +567,8 @@ PATCH /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name 200 (}}">HorizontalPodAutoscaler): OK +201 (}}">HorizontalPodAutoscaler): Created + 401: Unauthorized @@ -608,6 +622,8 @@ PATCH /apis/autoscaling/v1/namespaces/{namespace}/horizontalpodautoscalers/{name 200 (}}">HorizontalPodAutoscaler): OK +201 (}}">HorizontalPodAutoscaler): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2beta2.md b/content/en/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2beta2.md index 2f8f15d505..67894ab9c4 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2beta2.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2beta2.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "HorizontalPodAutoscaler is the configuration for a horizontal pod autoscaler, which automatically manages the replica count of any resource implementing the scale subresource based on the metrics specified." title: "HorizontalPodAutoscaler v2beta2" -weight: 15 +weight: 12 +auto_generated: true --- + + `apiVersion: autoscaling/v2beta2` `import "k8s.io/api/autoscaling/v2beta2"` @@ -89,32 +101,32 @@ HorizontalPodAutoscalerSpec describes the desired functionality of the Horizonta *HPAScalingRules configures the scaling behavior for one direction. These Rules are applied after calculating DesiredReplicas from metrics for the HPA. They can limit the scaling velocity by specifying scaling policies. They can prevent flapping by specifying the stabilization window, so that the number of replicas is not set instantly, instead, the safest value from the stabilization window is chosen.* - - **behavior.scaleDown.policies** ([]HPAScalingPolicy) + - **behavior.scaleDown.policies** ([]HPAScalingPolicy) - policies is a list of potential scaling polices which can be used during scaling. At least one policy must be specified, otherwise the HPAScalingRules will be discarded as invalid + policies is a list of potential scaling polices which can be used during scaling. At least one policy must be specified, otherwise the HPAScalingRules will be discarded as invalid - - *HPAScalingPolicy is a single policy which must hold true for a specified past interval.* + + *HPAScalingPolicy is a single policy which must hold true for a specified past interval.* - - **behavior.scaleDown.policies.type** (string), required + - **behavior.scaleDown.policies.type** (string), required - Type is used to specify the scaling policy. + Type is used to specify the scaling policy. - - **behavior.scaleDown.policies.value** (int32), required + - **behavior.scaleDown.policies.value** (int32), required - Value contains the amount of change which is permitted by the policy. It must be greater than zero + Value contains the amount of change which is permitted by the policy. It must be greater than zero - - **behavior.scaleDown.policies.periodSeconds** (int32), required + - **behavior.scaleDown.policies.periodSeconds** (int32), required - PeriodSeconds specifies the window of time for which the policy should hold true. PeriodSeconds must be greater than zero and less than or equal to 1800 (30 min). + PeriodSeconds specifies the window of time for which the policy should hold true. PeriodSeconds must be greater than zero and less than or equal to 1800 (30 min). - - **behavior.scaleDown.selectPolicy** (string) + - **behavior.scaleDown.selectPolicy** (string) - selectPolicy is used to specify which policy should be used. If not set, the default value MaxPolicySelect is used. + selectPolicy is used to specify which policy should be used. If not set, the default value MaxPolicySelect is used. - - **behavior.scaleDown.stabilizationWindowSeconds** (int32) + - **behavior.scaleDown.stabilizationWindowSeconds** (int32) - StabilizationWindowSeconds is the number of seconds for which past recommendations should be considered while scaling up or scaling down. StabilizationWindowSeconds must be greater than or equal to zero and less than or equal to 3600 (one hour). If not set, use the default values: - For scale up: 0 (i.e. no stabilization is done). - For scale down: 300 (i.e. the stabilization window is 300 seconds long). + StabilizationWindowSeconds is the number of seconds for which past recommendations should be considered while scaling up or scaling down. StabilizationWindowSeconds must be greater than or equal to zero and less than or equal to 3600 (one hour). If not set, use the default values: - For scale up: 0 (i.e. no stabilization is done). - For scale down: 300 (i.e. the stabilization window is 300 seconds long). - **behavior.scaleUp** (HPAScalingRules) @@ -126,32 +138,32 @@ HorizontalPodAutoscalerSpec describes the desired functionality of the Horizonta *HPAScalingRules configures the scaling behavior for one direction. These Rules are applied after calculating DesiredReplicas from metrics for the HPA. They can limit the scaling velocity by specifying scaling policies. They can prevent flapping by specifying the stabilization window, so that the number of replicas is not set instantly, instead, the safest value from the stabilization window is chosen.* - - **behavior.scaleUp.policies** ([]HPAScalingPolicy) + - **behavior.scaleUp.policies** ([]HPAScalingPolicy) - policies is a list of potential scaling polices which can be used during scaling. At least one policy must be specified, otherwise the HPAScalingRules will be discarded as invalid + policies is a list of potential scaling polices which can be used during scaling. At least one policy must be specified, otherwise the HPAScalingRules will be discarded as invalid - - *HPAScalingPolicy is a single policy which must hold true for a specified past interval.* + + *HPAScalingPolicy is a single policy which must hold true for a specified past interval.* - - **behavior.scaleUp.policies.type** (string), required + - **behavior.scaleUp.policies.type** (string), required - Type is used to specify the scaling policy. + Type is used to specify the scaling policy. - - **behavior.scaleUp.policies.value** (int32), required + - **behavior.scaleUp.policies.value** (int32), required - Value contains the amount of change which is permitted by the policy. It must be greater than zero + Value contains the amount of change which is permitted by the policy. It must be greater than zero - - **behavior.scaleUp.policies.periodSeconds** (int32), required + - **behavior.scaleUp.policies.periodSeconds** (int32), required - PeriodSeconds specifies the window of time for which the policy should hold true. PeriodSeconds must be greater than zero and less than or equal to 1800 (30 min). + PeriodSeconds specifies the window of time for which the policy should hold true. PeriodSeconds must be greater than zero and less than or equal to 1800 (30 min). - - **behavior.scaleUp.selectPolicy** (string) + - **behavior.scaleUp.selectPolicy** (string) - selectPolicy is used to specify which policy should be used. If not set, the default value MaxPolicySelect is used. + selectPolicy is used to specify which policy should be used. If not set, the default value MaxPolicySelect is used. - - **behavior.scaleUp.stabilizationWindowSeconds** (int32) + - **behavior.scaleUp.stabilizationWindowSeconds** (int32) - StabilizationWindowSeconds is the number of seconds for which past recommendations should be considered while scaling up or scaling down. StabilizationWindowSeconds must be greater than or equal to zero and less than or equal to 3600 (one hour). If not set, use the default values: - For scale up: 0 (i.e. no stabilization is done). - For scale down: 300 (i.e. the stabilization window is 300 seconds long). + StabilizationWindowSeconds is the number of seconds for which past recommendations should be considered while scaling up or scaling down. StabilizationWindowSeconds must be greater than or equal to zero and less than or equal to 3600 (one hour). If not set, use the default values: - For scale up: 0 (i.e. no stabilization is done). - For scale down: 300 (i.e. the stabilization window is 300 seconds long). - **metrics** ([]MetricSpec) @@ -171,36 +183,36 @@ HorizontalPodAutoscalerSpec describes the desired functionality of the Horizonta *ContainerResourceMetricSource indicates how to scale on a resource metric known to Kubernetes, as specified in requests and limits, describing each pod in the current scale target (e.g. CPU or memory). The values will be averaged together before being compared to the target. Such metrics are built in to Kubernetes, and have special scaling options on top of those available to normal per-pod metrics using the "pods" source. Only one "target" type should be set.* - - **metrics.containerResource.container** (string), required + - **metrics.containerResource.container** (string), required - container is the name of the container in the pods of the scaling target + container is the name of the container in the pods of the scaling target - - **metrics.containerResource.name** (string), required + - **metrics.containerResource.name** (string), required - name is the name of the resource in question. + name is the name of the resource in question. - - **metrics.containerResource.target** (MetricTarget), required + - **metrics.containerResource.target** (MetricTarget), required - target specifies the target value for the given metric + target specifies the target value for the given metric - - *MetricTarget defines the target value, average value, or average utilization of a specific metric* + + *MetricTarget defines the target value, average value, or average utilization of a specific metric* - - **metrics.containerResource.target.type** (string), required + - **metrics.containerResource.target.type** (string), required - type represents whether the metric type is Utilization, Value, or AverageValue + type represents whether the metric type is Utilization, Value, or AverageValue - - **metrics.containerResource.target.averageUtilization** (int32) + - **metrics.containerResource.target.averageUtilization** (int32) - averageUtilization is the target value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. Currently only valid for Resource metric source type + averageUtilization is the target value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. Currently only valid for Resource metric source type - - **metrics.containerResource.target.averageValue** (}}">Quantity) + - **metrics.containerResource.target.averageValue** (}}">Quantity) - averageValue is the target value of the average of the metric across all relevant pods (as a quantity) + averageValue is the target value of the average of the metric across all relevant pods (as a quantity) - - **metrics.containerResource.target.value** (}}">Quantity) + - **metrics.containerResource.target.value** (}}">Quantity) - value is the target value of the metric (as a quantity). + value is the target value of the metric (as a quantity). - **metrics.external** (ExternalMetricSource) @@ -209,43 +221,43 @@ HorizontalPodAutoscalerSpec describes the desired functionality of the Horizonta *ExternalMetricSource indicates how to scale on a metric not associated with any Kubernetes object (for example length of queue in cloud messaging service, or QPS from loadbalancer running outside of cluster).* - - **metrics.external.metric** (MetricIdentifier), required + - **metrics.external.metric** (MetricIdentifier), required - metric identifies the target metric by name and selector + metric identifies the target metric by name and selector - - *MetricIdentifier defines the name and optionally selector for a metric* + + *MetricIdentifier defines the name and optionally selector for a metric* - - **metrics.external.metric.name** (string), required + - **metrics.external.metric.name** (string), required - name is the name of the given metric + name is the name of the given metric - - **metrics.external.metric.selector** (}}">LabelSelector) + - **metrics.external.metric.selector** (}}">LabelSelector) - selector is the string-encoded form of a standard kubernetes label selector for the given metric When set, it is passed as an additional parameter to the metrics server for more specific metrics scoping. When unset, just the metricName will be used to gather metrics. + selector is the string-encoded form of a standard kubernetes label selector for the given metric When set, it is passed as an additional parameter to the metrics server for more specific metrics scoping. When unset, just the metricName will be used to gather metrics. - - **metrics.external.target** (MetricTarget), required + - **metrics.external.target** (MetricTarget), required - target specifies the target value for the given metric + target specifies the target value for the given metric - - *MetricTarget defines the target value, average value, or average utilization of a specific metric* + + *MetricTarget defines the target value, average value, or average utilization of a specific metric* - - **metrics.external.target.type** (string), required + - **metrics.external.target.type** (string), required - type represents whether the metric type is Utilization, Value, or AverageValue + type represents whether the metric type is Utilization, Value, or AverageValue - - **metrics.external.target.averageUtilization** (int32) + - **metrics.external.target.averageUtilization** (int32) - averageUtilization is the target value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. Currently only valid for Resource metric source type + averageUtilization is the target value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. Currently only valid for Resource metric source type - - **metrics.external.target.averageValue** (}}">Quantity) + - **metrics.external.target.averageValue** (}}">Quantity) - averageValue is the target value of the average of the metric across all relevant pods (as a quantity) + averageValue is the target value of the average of the metric across all relevant pods (as a quantity) - - **metrics.external.target.value** (}}">Quantity) + - **metrics.external.target.value** (}}">Quantity) - value is the target value of the metric (as a quantity). + value is the target value of the metric (as a quantity). - **metrics.object** (ObjectMetricSource) @@ -254,61 +266,61 @@ HorizontalPodAutoscalerSpec describes the desired functionality of the Horizonta *ObjectMetricSource indicates how to scale on a metric describing a kubernetes object (for example, hits-per-second on an Ingress object).* - - **metrics.object.describedObject** (CrossVersionObjectReference), required + - **metrics.object.describedObject** (CrossVersionObjectReference), required - - *CrossVersionObjectReference contains enough information to let you identify the referred resource.* + + *CrossVersionObjectReference contains enough information to let you identify the referred resource.* - - **metrics.object.describedObject.kind** (string), required + - **metrics.object.describedObject.kind** (string), required - Kind of the referent; More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds" + Kind of the referent; More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds" - - **metrics.object.describedObject.name** (string), required + - **metrics.object.describedObject.name** (string), required - Name of the referent; More info: http://kubernetes.io/docs/user-guide/identifiers#names + Name of the referent; More info: http://kubernetes.io/docs/user-guide/identifiers#names - - **metrics.object.describedObject.apiVersion** (string) + - **metrics.object.describedObject.apiVersion** (string) - API version of the referent + API version of the referent - - **metrics.object.metric** (MetricIdentifier), required + - **metrics.object.metric** (MetricIdentifier), required - metric identifies the target metric by name and selector + metric identifies the target metric by name and selector - - *MetricIdentifier defines the name and optionally selector for a metric* + + *MetricIdentifier defines the name and optionally selector for a metric* - - **metrics.object.metric.name** (string), required + - **metrics.object.metric.name** (string), required - name is the name of the given metric + name is the name of the given metric - - **metrics.object.metric.selector** (}}">LabelSelector) + - **metrics.object.metric.selector** (}}">LabelSelector) - selector is the string-encoded form of a standard kubernetes label selector for the given metric When set, it is passed as an additional parameter to the metrics server for more specific metrics scoping. When unset, just the metricName will be used to gather metrics. + selector is the string-encoded form of a standard kubernetes label selector for the given metric When set, it is passed as an additional parameter to the metrics server for more specific metrics scoping. When unset, just the metricName will be used to gather metrics. - - **metrics.object.target** (MetricTarget), required + - **metrics.object.target** (MetricTarget), required - target specifies the target value for the given metric + target specifies the target value for the given metric - - *MetricTarget defines the target value, average value, or average utilization of a specific metric* + + *MetricTarget defines the target value, average value, or average utilization of a specific metric* - - **metrics.object.target.type** (string), required + - **metrics.object.target.type** (string), required - type represents whether the metric type is Utilization, Value, or AverageValue + type represents whether the metric type is Utilization, Value, or AverageValue - - **metrics.object.target.averageUtilization** (int32) + - **metrics.object.target.averageUtilization** (int32) - averageUtilization is the target value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. Currently only valid for Resource metric source type + averageUtilization is the target value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. Currently only valid for Resource metric source type - - **metrics.object.target.averageValue** (}}">Quantity) + - **metrics.object.target.averageValue** (}}">Quantity) - averageValue is the target value of the average of the metric across all relevant pods (as a quantity) + averageValue is the target value of the average of the metric across all relevant pods (as a quantity) - - **metrics.object.target.value** (}}">Quantity) + - **metrics.object.target.value** (}}">Quantity) - value is the target value of the metric (as a quantity). + value is the target value of the metric (as a quantity). - **metrics.pods** (PodsMetricSource) @@ -317,43 +329,43 @@ HorizontalPodAutoscalerSpec describes the desired functionality of the Horizonta *PodsMetricSource indicates how to scale on a metric describing each pod in the current scale target (for example, transactions-processed-per-second). The values will be averaged together before being compared to the target value.* - - **metrics.pods.metric** (MetricIdentifier), required + - **metrics.pods.metric** (MetricIdentifier), required - metric identifies the target metric by name and selector + metric identifies the target metric by name and selector - - *MetricIdentifier defines the name and optionally selector for a metric* + + *MetricIdentifier defines the name and optionally selector for a metric* - - **metrics.pods.metric.name** (string), required + - **metrics.pods.metric.name** (string), required - name is the name of the given metric + name is the name of the given metric - - **metrics.pods.metric.selector** (}}">LabelSelector) + - **metrics.pods.metric.selector** (}}">LabelSelector) - selector is the string-encoded form of a standard kubernetes label selector for the given metric When set, it is passed as an additional parameter to the metrics server for more specific metrics scoping. When unset, just the metricName will be used to gather metrics. + selector is the string-encoded form of a standard kubernetes label selector for the given metric When set, it is passed as an additional parameter to the metrics server for more specific metrics scoping. When unset, just the metricName will be used to gather metrics. - - **metrics.pods.target** (MetricTarget), required + - **metrics.pods.target** (MetricTarget), required - target specifies the target value for the given metric + target specifies the target value for the given metric - - *MetricTarget defines the target value, average value, or average utilization of a specific metric* + + *MetricTarget defines the target value, average value, or average utilization of a specific metric* - - **metrics.pods.target.type** (string), required + - **metrics.pods.target.type** (string), required - type represents whether the metric type is Utilization, Value, or AverageValue + type represents whether the metric type is Utilization, Value, or AverageValue - - **metrics.pods.target.averageUtilization** (int32) + - **metrics.pods.target.averageUtilization** (int32) - averageUtilization is the target value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. Currently only valid for Resource metric source type + averageUtilization is the target value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. Currently only valid for Resource metric source type - - **metrics.pods.target.averageValue** (}}">Quantity) + - **metrics.pods.target.averageValue** (}}">Quantity) - averageValue is the target value of the average of the metric across all relevant pods (as a quantity) + averageValue is the target value of the average of the metric across all relevant pods (as a quantity) - - **metrics.pods.target.value** (}}">Quantity) + - **metrics.pods.target.value** (}}">Quantity) - value is the target value of the metric (as a quantity). + value is the target value of the metric (as a quantity). - **metrics.resource** (ResourceMetricSource) @@ -362,32 +374,32 @@ HorizontalPodAutoscalerSpec describes the desired functionality of the Horizonta *ResourceMetricSource indicates how to scale on a resource metric known to Kubernetes, as specified in requests and limits, describing each pod in the current scale target (e.g. CPU or memory). The values will be averaged together before being compared to the target. Such metrics are built in to Kubernetes, and have special scaling options on top of those available to normal per-pod metrics using the "pods" source. Only one "target" type should be set.* - - **metrics.resource.name** (string), required + - **metrics.resource.name** (string), required - name is the name of the resource in question. + name is the name of the resource in question. - - **metrics.resource.target** (MetricTarget), required + - **metrics.resource.target** (MetricTarget), required - target specifies the target value for the given metric + target specifies the target value for the given metric - - *MetricTarget defines the target value, average value, or average utilization of a specific metric* + + *MetricTarget defines the target value, average value, or average utilization of a specific metric* - - **metrics.resource.target.type** (string), required + - **metrics.resource.target.type** (string), required - type represents whether the metric type is Utilization, Value, or AverageValue + type represents whether the metric type is Utilization, Value, or AverageValue - - **metrics.resource.target.averageUtilization** (int32) + - **metrics.resource.target.averageUtilization** (int32) - averageUtilization is the target value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. Currently only valid for Resource metric source type + averageUtilization is the target value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. Currently only valid for Resource metric source type - - **metrics.resource.target.averageValue** (}}">Quantity) + - **metrics.resource.target.averageValue** (}}">Quantity) - averageValue is the target value of the average of the metric across all relevant pods (as a quantity) + averageValue is the target value of the average of the metric across all relevant pods (as a quantity) - - **metrics.resource.target.value** (}}">Quantity) + - **metrics.resource.target.value** (}}">Quantity) - value is the target value of the metric (as a quantity). + value is the target value of the metric (as a quantity). @@ -455,32 +467,32 @@ HorizontalPodAutoscalerStatus describes the current status of a horizontal pod a *ContainerResourceMetricStatus indicates the current value of a resource metric known to Kubernetes, as specified in requests and limits, describing a single container in each pod in the current scale target (e.g. CPU or memory). Such metrics are built in to Kubernetes, and have special scaling options on top of those available to normal per-pod metrics using the "pods" source.* - - **currentMetrics.containerResource.container** (string), required + - **currentMetrics.containerResource.container** (string), required - Container is the name of the container in the pods of the scaling target + Container is the name of the container in the pods of the scaling target - - **currentMetrics.containerResource.current** (MetricValueStatus), required + - **currentMetrics.containerResource.current** (MetricValueStatus), required - current contains the current value for the given metric + current contains the current value for the given metric - - *MetricValueStatus holds the current value for a metric* + + *MetricValueStatus holds the current value for a metric* - - **currentMetrics.containerResource.current.averageUtilization** (int32) + - **currentMetrics.containerResource.current.averageUtilization** (int32) - currentAverageUtilization is the current value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. + currentAverageUtilization is the current value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - - **currentMetrics.containerResource.current.averageValue** (}}">Quantity) + - **currentMetrics.containerResource.current.averageValue** (}}">Quantity) - averageValue is the current value of the average of the metric across all relevant pods (as a quantity) + averageValue is the current value of the average of the metric across all relevant pods (as a quantity) - - **currentMetrics.containerResource.current.value** (}}">Quantity) + - **currentMetrics.containerResource.current.value** (}}">Quantity) - value is the current value of the metric (as a quantity). + value is the current value of the metric (as a quantity). - - **currentMetrics.containerResource.name** (string), required + - **currentMetrics.containerResource.name** (string), required - Name is the name of the resource in question. + Name is the name of the resource in question. - **currentMetrics.external** (ExternalMetricStatus) @@ -489,39 +501,39 @@ HorizontalPodAutoscalerStatus describes the current status of a horizontal pod a *ExternalMetricStatus indicates the current value of a global metric not associated with any Kubernetes object.* - - **currentMetrics.external.current** (MetricValueStatus), required + - **currentMetrics.external.current** (MetricValueStatus), required - current contains the current value for the given metric + current contains the current value for the given metric - - *MetricValueStatus holds the current value for a metric* + + *MetricValueStatus holds the current value for a metric* - - **currentMetrics.external.current.averageUtilization** (int32) + - **currentMetrics.external.current.averageUtilization** (int32) - currentAverageUtilization is the current value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. + currentAverageUtilization is the current value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - - **currentMetrics.external.current.averageValue** (}}">Quantity) + - **currentMetrics.external.current.averageValue** (}}">Quantity) - averageValue is the current value of the average of the metric across all relevant pods (as a quantity) + averageValue is the current value of the average of the metric across all relevant pods (as a quantity) - - **currentMetrics.external.current.value** (}}">Quantity) + - **currentMetrics.external.current.value** (}}">Quantity) - value is the current value of the metric (as a quantity). + value is the current value of the metric (as a quantity). - - **currentMetrics.external.metric** (MetricIdentifier), required + - **currentMetrics.external.metric** (MetricIdentifier), required - metric identifies the target metric by name and selector + metric identifies the target metric by name and selector - - *MetricIdentifier defines the name and optionally selector for a metric* + + *MetricIdentifier defines the name and optionally selector for a metric* - - **currentMetrics.external.metric.name** (string), required + - **currentMetrics.external.metric.name** (string), required - name is the name of the given metric + name is the name of the given metric - - **currentMetrics.external.metric.selector** (}}">LabelSelector) + - **currentMetrics.external.metric.selector** (}}">LabelSelector) - selector is the string-encoded form of a standard kubernetes label selector for the given metric When set, it is passed as an additional parameter to the metrics server for more specific metrics scoping. When unset, just the metricName will be used to gather metrics. + selector is the string-encoded form of a standard kubernetes label selector for the given metric When set, it is passed as an additional parameter to the metrics server for more specific metrics scoping. When unset, just the metricName will be used to gather metrics. - **currentMetrics.object** (ObjectMetricStatus) @@ -530,57 +542,57 @@ HorizontalPodAutoscalerStatus describes the current status of a horizontal pod a *ObjectMetricStatus indicates the current value of a metric describing a kubernetes object (for example, hits-per-second on an Ingress object).* - - **currentMetrics.object.current** (MetricValueStatus), required + - **currentMetrics.object.current** (MetricValueStatus), required - current contains the current value for the given metric + current contains the current value for the given metric - - *MetricValueStatus holds the current value for a metric* + + *MetricValueStatus holds the current value for a metric* - - **currentMetrics.object.current.averageUtilization** (int32) + - **currentMetrics.object.current.averageUtilization** (int32) - currentAverageUtilization is the current value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. + currentAverageUtilization is the current value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - - **currentMetrics.object.current.averageValue** (}}">Quantity) + - **currentMetrics.object.current.averageValue** (}}">Quantity) - averageValue is the current value of the average of the metric across all relevant pods (as a quantity) + averageValue is the current value of the average of the metric across all relevant pods (as a quantity) - - **currentMetrics.object.current.value** (}}">Quantity) + - **currentMetrics.object.current.value** (}}">Quantity) - value is the current value of the metric (as a quantity). + value is the current value of the metric (as a quantity). - - **currentMetrics.object.describedObject** (CrossVersionObjectReference), required + - **currentMetrics.object.describedObject** (CrossVersionObjectReference), required - - *CrossVersionObjectReference contains enough information to let you identify the referred resource.* + + *CrossVersionObjectReference contains enough information to let you identify the referred resource.* - - **currentMetrics.object.describedObject.kind** (string), required + - **currentMetrics.object.describedObject.kind** (string), required - Kind of the referent; More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds" + Kind of the referent; More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds" - - **currentMetrics.object.describedObject.name** (string), required + - **currentMetrics.object.describedObject.name** (string), required - Name of the referent; More info: http://kubernetes.io/docs/user-guide/identifiers#names + Name of the referent; More info: http://kubernetes.io/docs/user-guide/identifiers#names - - **currentMetrics.object.describedObject.apiVersion** (string) + - **currentMetrics.object.describedObject.apiVersion** (string) - API version of the referent + API version of the referent - - **currentMetrics.object.metric** (MetricIdentifier), required + - **currentMetrics.object.metric** (MetricIdentifier), required - metric identifies the target metric by name and selector + metric identifies the target metric by name and selector - - *MetricIdentifier defines the name and optionally selector for a metric* + + *MetricIdentifier defines the name and optionally selector for a metric* - - **currentMetrics.object.metric.name** (string), required + - **currentMetrics.object.metric.name** (string), required - name is the name of the given metric + name is the name of the given metric - - **currentMetrics.object.metric.selector** (}}">LabelSelector) + - **currentMetrics.object.metric.selector** (}}">LabelSelector) - selector is the string-encoded form of a standard kubernetes label selector for the given metric When set, it is passed as an additional parameter to the metrics server for more specific metrics scoping. When unset, just the metricName will be used to gather metrics. + selector is the string-encoded form of a standard kubernetes label selector for the given metric When set, it is passed as an additional parameter to the metrics server for more specific metrics scoping. When unset, just the metricName will be used to gather metrics. - **currentMetrics.pods** (PodsMetricStatus) @@ -589,39 +601,39 @@ HorizontalPodAutoscalerStatus describes the current status of a horizontal pod a *PodsMetricStatus indicates the current value of a metric describing each pod in the current scale target (for example, transactions-processed-per-second).* - - **currentMetrics.pods.current** (MetricValueStatus), required + - **currentMetrics.pods.current** (MetricValueStatus), required - current contains the current value for the given metric + current contains the current value for the given metric - - *MetricValueStatus holds the current value for a metric* + + *MetricValueStatus holds the current value for a metric* - - **currentMetrics.pods.current.averageUtilization** (int32) + - **currentMetrics.pods.current.averageUtilization** (int32) - currentAverageUtilization is the current value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. + currentAverageUtilization is the current value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - - **currentMetrics.pods.current.averageValue** (}}">Quantity) + - **currentMetrics.pods.current.averageValue** (}}">Quantity) - averageValue is the current value of the average of the metric across all relevant pods (as a quantity) + averageValue is the current value of the average of the metric across all relevant pods (as a quantity) - - **currentMetrics.pods.current.value** (}}">Quantity) + - **currentMetrics.pods.current.value** (}}">Quantity) - value is the current value of the metric (as a quantity). + value is the current value of the metric (as a quantity). - - **currentMetrics.pods.metric** (MetricIdentifier), required + - **currentMetrics.pods.metric** (MetricIdentifier), required - metric identifies the target metric by name and selector + metric identifies the target metric by name and selector - - *MetricIdentifier defines the name and optionally selector for a metric* + + *MetricIdentifier defines the name and optionally selector for a metric* - - **currentMetrics.pods.metric.name** (string), required + - **currentMetrics.pods.metric.name** (string), required - name is the name of the given metric + name is the name of the given metric - - **currentMetrics.pods.metric.selector** (}}">LabelSelector) + - **currentMetrics.pods.metric.selector** (}}">LabelSelector) - selector is the string-encoded form of a standard kubernetes label selector for the given metric When set, it is passed as an additional parameter to the metrics server for more specific metrics scoping. When unset, just the metricName will be used to gather metrics. + selector is the string-encoded form of a standard kubernetes label selector for the given metric When set, it is passed as an additional parameter to the metrics server for more specific metrics scoping. When unset, just the metricName will be used to gather metrics. - **currentMetrics.resource** (ResourceMetricStatus) @@ -630,28 +642,28 @@ HorizontalPodAutoscalerStatus describes the current status of a horizontal pod a *ResourceMetricStatus indicates the current value of a resource metric known to Kubernetes, as specified in requests and limits, describing each pod in the current scale target (e.g. CPU or memory). Such metrics are built in to Kubernetes, and have special scaling options on top of those available to normal per-pod metrics using the "pods" source.* - - **currentMetrics.resource.current** (MetricValueStatus), required + - **currentMetrics.resource.current** (MetricValueStatus), required - current contains the current value for the given metric + current contains the current value for the given metric - - *MetricValueStatus holds the current value for a metric* + + *MetricValueStatus holds the current value for a metric* - - **currentMetrics.resource.current.averageUtilization** (int32) + - **currentMetrics.resource.current.averageUtilization** (int32) - currentAverageUtilization is the current value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. + currentAverageUtilization is the current value of the average of the resource metric across all relevant pods, represented as a percentage of the requested value of the resource for the pods. - - **currentMetrics.resource.current.averageValue** (}}">Quantity) + - **currentMetrics.resource.current.averageValue** (}}">Quantity) - averageValue is the current value of the average of the metric across all relevant pods (as a quantity) + averageValue is the current value of the average of the metric across all relevant pods (as a quantity) - - **currentMetrics.resource.current.value** (}}">Quantity) + - **currentMetrics.resource.current.value** (}}">Quantity) - value is the current value of the metric (as a quantity). + value is the current value of the metric (as a quantity). - - **currentMetrics.resource.name** (string), required + - **currentMetrics.resource.name** (string), required - Name is the name of the resource in question. + Name is the name of the resource in question. - **lastScaleTime** (Time) @@ -1107,6 +1119,8 @@ PATCH /apis/autoscaling/v2beta2/namespaces/{namespace}/horizontalpodautoscalers/ 200 (}}">HorizontalPodAutoscaler): OK +201 (}}">HorizontalPodAutoscaler): Created + 401: Unauthorized @@ -1160,6 +1174,8 @@ PATCH /apis/autoscaling/v2beta2/namespaces/{namespace}/horizontalpodautoscalers/ 200 (}}">HorizontalPodAutoscaler): OK +201 (}}">HorizontalPodAutoscaler): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/job-v1.md b/content/en/docs/reference/kubernetes-api/workload-resources/job-v1.md index f01c257e45..0f61e522eb 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/job-v1.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/job-v1.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "Job represents the configuration of a single job." title: "Job" -weight: 11 +weight: 9 +auto_generated: true --- + + `apiVersion: batch/v1` `import "k8s.io/api/batch/v1"` @@ -68,18 +80,34 @@ JobSpec describes how the job execution will look like. Specifies the desired number of successfully finished pods the job should be run with. Setting to nil means that the success of any pod signals the success of all pods, and allows parallelism to have any positive value. Setting to 1 means that parallelism is limited to 1 and the success of that pod signals the success of the job. More info: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/ +- **completionMode** (string) + + CompletionMode specifies how Pod completions are tracked. It can be `NonIndexed` (default) or `Indexed`. + + `NonIndexed` means that the Job is considered complete when there have been .spec.completions successfully completed Pods. Each Pod completion is homologous to each other. + + `Indexed` means that the Pods of a Job get an associated completion index from 0 to (.spec.completions - 1), available in the annotation batch.kubernetes.io/job-completion-index. The Job is considered complete when there is one successfully completed Pod for each index. When value is `Indexed`, .spec.completions must be specified and `.spec.parallelism` must be less than or equal to 10^5. In addition, The Pod name takes the form `$(job-name)-$(index)-$(random-string)`, the Pod hostname takes the form `$(job-name)-$(index)`. + + This field is beta-level. More completion modes can be added in the future. If the Job controller observes a mode that it doesn't recognize, the controller skips updates for the Job. + - **backoffLimit** (int32) Specifies the number of retries before marking this job failed. Defaults to 6 - **activeDeadlineSeconds** (int64) - Specifies the duration in seconds relative to the startTime that the job may be active before the system tries to terminate it; value must be positive integer + Specifies the duration in seconds relative to the startTime that the job may be continuously active before the system tries to terminate it; value must be positive integer. If a Job is suspended (at creation or through an update), this timer will effectively be stopped and reset when the Job is resumed again. - **ttlSecondsAfterFinished** (int32) ttlSecondsAfterFinished limits the lifetime of a Job that has finished execution (either Complete or Failed). If this field is set, ttlSecondsAfterFinished after the Job finishes, it is eligible to be automatically deleted. When the Job is being deleted, its lifecycle guarantees (e.g. finalizers) will be honored. If this field is unset, the Job won't be automatically deleted. If this field is set to zero, the Job becomes eligible to be deleted immediately after it finishes. This field is alpha-level and is only honored by servers that enable the TTLAfterFinished feature. +- **suspend** (boolean) + + Suspend specifies whether the Job controller should create Pods or not. If a Job is created with suspend set to true, no Pods are created by the Job controller. If a Job is suspended after creation (i.e. the flag goes from false to true), the Job controller will delete all active Pods associated with this Job. Users must design their workload to gracefully handle this. Suspending a Job will reset the StartTime field of the Job, effectively resetting the ActiveDeadlineSeconds timer too. Defaults to false. + + This field is beta-level, gated by SuspendJob feature flag (enabled by default). + ### Selector @@ -101,7 +129,7 @@ JobStatus represents the current state of a Job. - **startTime** (Time) - Represents time when the job was acknowledged by the job controller. It is not guaranteed to be set in happens-before order across separate operations. It is represented in RFC3339 form and is in UTC. + Represents time when the job controller started processing a job. When a Job is created in the suspended state, this field is not set until the first time it is resumed. This field is reset every time a Job is resumed from suspension. It is represented in RFC3339 form and is in UTC. *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* @@ -125,11 +153,17 @@ JobStatus represents the current state of a Job. The number of pods which reached phase Succeeded. +- **completedIndexes** (string) + + CompletedIndexes holds the completed indexes when .spec.completionMode = "Indexed" in a text format. The indexes are represented as decimal integers separated by commas. The numbers are listed in increasing order. Three or more consecutive numbers are compressed and represented by the first and last element of the series, separated by a hyphen. For example, if the completed indexes are 1, 3, 4, 5 and 7, they are represented as "1,3-5,7". + - **conditions** ([]JobCondition) *Patch strategy: merge on key `type`* - The latest available observations of an object's current state. When a job fails, one of the conditions will have type == "Failed". More info: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/ + *Atomic: will be replaced during a merge* + + The latest available observations of an object's current state. When a Job fails, one of the conditions will have type "Failed" and status true. When a Job is suspended, one of the conditions will have type "Suspended" and status true; when the Job is resumed, the status of this condition will become false. When a Job is completed, one of the conditions will have type "Complete" and status true. More info: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/ *JobCondition describes current state of a job.* @@ -164,6 +198,30 @@ JobStatus represents the current state of a Job. (brief) reason for the condition's last transition. +- **uncountedTerminatedPods** (UncountedTerminatedPods) + + UncountedTerminatedPods holds the UIDs of Pods that have terminated but the job controller hasn't yet accounted for in the status counters. + + The job controller creates pods with a finalizer. When a pod terminates (succeeded or failed), the controller does three steps to account for it in the job status: (1) Add the pod UID to the arrays in this field. (2) Remove the pod finalizer. (3) Remove the pod UID from the arrays while increasing the corresponding + counter. + + This field is alpha-level. The job controller only makes use of this field when the feature gate PodTrackingWithFinalizers is enabled. Old jobs might not be tracked using this field, in which case the field remains null. + + + *UncountedTerminatedPods holds UIDs of Pods that have terminated but haven't been accounted in Job status counters.* + + - **uncountedTerminatedPods.failed** ([]string) + + *Set: unique values will be kept during a merge* + + Failed holds UIDs of failed Pods. + + - **uncountedTerminatedPods.succeeded** ([]string) + + *Set: unique values will be kept during a merge* + + Succeeded holds UIDs of succeeded Pods. + @@ -607,6 +665,8 @@ PATCH /apis/batch/v1/namespaces/{namespace}/jobs/{name} 200 (}}">Job): OK +201 (}}">Job): Created + 401: Unauthorized @@ -660,6 +720,8 @@ PATCH /apis/batch/v1/namespaces/{namespace}/jobs/{name}/status 200 (}}">Job): OK +201 (}}">Job): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/pod-template-v1.md b/content/en/docs/reference/kubernetes-api/workload-resources/pod-template-v1.md index 663ab6bea4..7e75ea07de 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/pod-template-v1.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/pod-template-v1.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "PodTemplate describes a template for creating copies of a predefined pod." title: "PodTemplate" -weight: 4 +weight: 2 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` @@ -412,6 +424,8 @@ PATCH /api/v1/namespaces/{namespace}/podtemplates/{name} 200 (}}">PodTemplate): OK +201 (}}">PodTemplate): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md b/content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md index 4be3289e9f..8c166cfd9e 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md @@ -7,8 +7,20 @@ content_type: "api_reference" description: "Pod is a collection of containers that can run on a host." title: "Pod" weight: 1 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` @@ -53,13 +65,13 @@ PodSpec is a description of a pod. ### Containers -- **containers** ([]}}">Container), required +- **containers** ([]}}">Container), required *Patch strategy: merge on key `name`* List of containers belonging to the pod. Containers cannot currently be added or removed. There must be at least one container in a Pod. Cannot be updated. -- **initContainers** ([]}}">Container) +- **initContainers** ([]}}">Container) *Patch strategy: merge on key `name`* @@ -102,15 +114,15 @@ PodSpec is a description of a pod. *Affinity is a group of affinity scheduling rules.* - - **affinity.nodeAffinity** (}}">NodeAffinity) + - **affinity.nodeAffinity** (}}">NodeAffinity) Describes node affinity scheduling rules for the pod. - - **affinity.podAffinity** (}}">PodAffinity) + - **affinity.podAffinity** (}}">PodAffinity) Describes pod affinity scheduling rules (e.g. co-locate this pod in the same node, zone, etc. as some other pod(s)). - - **affinity.podAntiAffinity** (}}">PodAntiAffinity) + - **affinity.podAntiAffinity** (}}">PodAntiAffinity) Describes pod anti-affinity scheduling rules (e.g. avoid putting this pod in the same node, zone, etc. as some other pod(s)). @@ -147,7 +159,7 @@ PodSpec is a description of a pod. - **runtimeClassName** (string) - RuntimeClassName refers to a RuntimeClass object in the node.k8s.io group, which should be used to run this pod. If no RuntimeClass resource matches the named class, the pod will not be run. If unset or empty, the "legacy" RuntimeClass will be used, which is an implicit class with an empty definition that uses the default runtime handler. More info: https://git.k8s.io/enhancements/keps/sig-node/runtime-class.md This is a beta feature as of Kubernetes v1.14. + RuntimeClassName refers to a RuntimeClass object in the node.k8s.io group, which should be used to run this pod. If no RuntimeClass resource matches the named class, the pod will not be run. If unset or empty, the "legacy" RuntimeClass will be used, which is an implicit class with an empty definition that uses the default runtime handler. More info: https://git.k8s.io/enhancements/keps/sig-node/585-runtime-class This is a beta feature as of Kubernetes v1.14. - **priorityClassName** (string) @@ -157,6 +169,36 @@ PodSpec is a description of a pod. The priority value. Various system components use this field to find the priority of the pod. When Priority Admission Controller is enabled, it prevents users from setting this field. The admission controller populates this field from PriorityClassName. The higher the value, the higher the priority. +- **topologySpreadConstraints** ([]TopologySpreadConstraint) + + *Patch strategy: merge on key `topologyKey`* + + *Map: unique values on keys `topologyKey, whenUnsatisfiable` will be kept during a merge* + + TopologySpreadConstraints describes how a group of pods ought to spread across topology domains. Scheduler will schedule pods in a way which abides by the constraints. All topologySpreadConstraints are ANDed. + + + *TopologySpreadConstraint specifies how to spread matching pods among the given topology.* + + - **topologySpreadConstraints.maxSkew** (int32), required + + MaxSkew describes the degree to which pods may be unevenly distributed. When `whenUnsatisfiable=DoNotSchedule`, it is the maximum permitted difference between the number of matching pods in the target topology and the global minimum. For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same labelSelector spread as 1/1/0: | zone1 | zone2 | zone3 | | P | P | | - if MaxSkew is 1, incoming pod can only be scheduled to zone3 to become 1/1/1; scheduling it onto zone1(zone2) would make the ActualSkew(2-0) on zone1(zone2) violate MaxSkew(1). - if MaxSkew is 2, incoming pod can be scheduled onto any zone. When `whenUnsatisfiable=ScheduleAnyway`, it is used to give higher precedence to topologies that satisfy it. It's a required field. Default value is 1 and 0 is not allowed. + + - **topologySpreadConstraints.topologyKey** (string), required + + TopologyKey is the key of node labels. Nodes that have a label with this key and identical values are considered to be in the same topology. We consider each \ as a "bucket", and try to put balanced number of pods into each bucket. It's a required field. + + - **topologySpreadConstraints.whenUnsatisfiable** (string), required + + WhenUnsatisfiable indicates how to deal with a pod if it doesn't satisfy the spread constraint. - DoNotSchedule (default) tells the scheduler not to schedule it. - ScheduleAnyway tells the scheduler to schedule the pod in any location, + but giving higher precedence to topologies that would help reduce the + skew. + A constraint is considered "Unsatisfiable" for an incoming pod if and only if every possible node assigment for that pod would violate "MaxSkew" on some topology. For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same labelSelector spread as 3/1/1: | zone1 | zone2 | zone3 | | P P P | P | P | If WhenUnsatisfiable is set to DoNotSchedule, incoming pod can only be scheduled to zone2(zone3) to become 3/2/1(3/1/2) as ActualSkew(2-1) on zone2(zone3) satisfies MaxSkew(1). In other words, the cluster can still be imbalanced, but scheduler won't make it *more* imbalanced. It's a required field. + + - **topologySpreadConstraints.labelSelector** (}}">LabelSelector) + + LabelSelector is used to find matching pods. Pods that match this label selector are counted to determine the number of pods in their corresponding topology domain. + ### Lifecycle @@ -166,7 +208,7 @@ PodSpec is a description of a pod. - **terminationGracePeriodSeconds** (int64) - Optional duration in seconds the pod needs to terminate gracefully. May be decreased in delete request. Value must be non-negative integer. The value zero indicates delete immediately. If this value is nil, the default grace period will be used instead. The grace period is the duration in seconds after the processes running in the pod are sent a termination signal and the time when the processes are forcibly halted with a kill signal. Set this value longer than the expected cleanup time for your process. Defaults to 30 seconds. + Optional duration in seconds the pod needs to terminate gracefully. May be decreased in delete request. Value must be non-negative integer. The value zero indicates stop immediately via the kill signal (no opportunity to shut down). If this value is nil, the default grace period will be used instead. The grace period is the duration in seconds after the processes running in the pod are sent a termination signal and the time when the processes are forcibly halted with a kill signal. Set this value longer than the expected cleanup time for your process. Defaults to 30 seconds. - **activeDeadlineSeconds** (int64) @@ -174,7 +216,7 @@ PodSpec is a description of a pod. - **readinessGates** ([]PodReadinessGate) - If specified, all readiness gates will be evaluated for pod readiness. A pod is ready when all its containers are ready AND all conditions specified in the readiness gates have status equal to "True" More info: https://git.k8s.io/enhancements/keps/sig-network/0007-pod-ready%2B%2B.md + If specified, all readiness gates will be evaluated for pod readiness. A pod is ready when all its containers are ready AND all conditions specified in the readiness gates have status equal to "True" More info: https://git.k8s.io/enhancements/keps/sig-network/580-pod-readiness-gates *PodReadinessGate contains the reference to a pod condition* @@ -233,11 +275,11 @@ PodSpec is a description of a pod. *PodDNSConfigOption defines DNS resolver options of a pod.* - - **dnsConfig.options.name** (string) + - **dnsConfig.options.name** (string) - Required. + Required. - - **dnsConfig.options.value** (string) + - **dnsConfig.options.value** (string) - **dnsConfig.searches** ([]string) @@ -323,15 +365,15 @@ PodSpec is a description of a pod. *SeccompProfile defines a pod/container's seccomp profile settings. Only one profile source may be set.* - - **securityContext.seccompProfile.type** (string), required + - **securityContext.seccompProfile.type** (string), required - type indicates which kind of seccomp profile will be applied. Valid options are: - - Localhost - a profile defined in a file on the node should be used. RuntimeDefault - the container runtime default profile should be used. Unconfined - no profile should be applied. + type indicates which kind of seccomp profile will be applied. Valid options are: + + Localhost - a profile defined in a file on the node should be used. RuntimeDefault - the container runtime default profile should be used. Unconfined - no profile should be applied. - - **securityContext.seccompProfile.localhostProfile** (string) + - **securityContext.seccompProfile.localhostProfile** (string) - localhostProfile indicates a profile defined in a file on the node should be used. The profile must be preconfigured on the node to work. Must be a descending path, relative to the kubelet's configured seccomp profile location. Must only be set if type is "Localhost". + localhostProfile indicates a profile defined in a file on the node should be used. The profile must be preconfigured on the node to work. Must be a descending path, relative to the kubelet's configured seccomp profile location. Must only be set if type is "Localhost". - **securityContext.seLinuxOptions** (SELinuxOptions) @@ -340,21 +382,21 @@ PodSpec is a description of a pod. *SELinuxOptions are the labels to be applied to the container* - - **securityContext.seLinuxOptions.level** (string) + - **securityContext.seLinuxOptions.level** (string) - Level is SELinux level label that applies to the container. + Level is SELinux level label that applies to the container. - - **securityContext.seLinuxOptions.role** (string) + - **securityContext.seLinuxOptions.role** (string) - Role is a SELinux role label that applies to the container. + Role is a SELinux role label that applies to the container. - - **securityContext.seLinuxOptions.type** (string) + - **securityContext.seLinuxOptions.type** (string) - Type is a SELinux type label that applies to the container. + Type is a SELinux type label that applies to the container. - - **securityContext.seLinuxOptions.user** (string) + - **securityContext.seLinuxOptions.user** (string) - User is a SELinux user label that applies to the container. + User is a SELinux user label that applies to the container. - **securityContext.sysctls** ([]Sysctl) @@ -363,13 +405,13 @@ PodSpec is a description of a pod. *Sysctl defines a kernel parameter to be set* - - **securityContext.sysctls.name** (string), required + - **securityContext.sysctls.name** (string), required - Name of a property to set + Name of a property to set - - **securityContext.sysctls.value** (string), required + - **securityContext.sysctls.value** (string), required - Value of a property to set + Value of a property to set - **securityContext.windowsOptions** (WindowsSecurityContextOptions) @@ -378,68 +420,42 @@ PodSpec is a description of a pod. *WindowsSecurityContextOptions contain Windows-specific options and credentials.* - - **securityContext.windowsOptions.gmsaCredentialSpec** (string) + - **securityContext.windowsOptions.gmsaCredentialSpec** (string) - GMSACredentialSpec is where the GMSA admission webhook (https://github.com/kubernetes-sigs/windows-gmsa) inlines the contents of the GMSA credential spec named by the GMSACredentialSpecName field. + GMSACredentialSpec is where the GMSA admission webhook (https://github.com/kubernetes-sigs/windows-gmsa) inlines the contents of the GMSA credential spec named by the GMSACredentialSpecName field. - - **securityContext.windowsOptions.gmsaCredentialSpecName** (string) + - **securityContext.windowsOptions.gmsaCredentialSpecName** (string) - GMSACredentialSpecName is the name of the GMSA credential spec to use. + GMSACredentialSpecName is the name of the GMSA credential spec to use. - - **securityContext.windowsOptions.runAsUserName** (string) + - **securityContext.windowsOptions.hostProcess** (boolean) - The UserName in Windows to run the entrypoint of the container process. Defaults to the user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. + HostProcess determines if a container should be run as a 'Host Process' container. This field is alpha-level and will only be honored by components that enable the WindowsHostProcessContainers feature flag. Setting this field without the feature flag will result in errors when validating the Pod. All of a Pod's containers must have the same effective HostProcess value (it is not allowed to have a mix of HostProcess containers and non-HostProcess containers). In addition, if HostProcess is true then HostNetwork must also be set to true. + + - **securityContext.windowsOptions.runAsUserName** (string) + + The UserName in Windows to run the entrypoint of the container process. Defaults to the user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. ### Beta level +- **preemptionPolicy** (string) + + PreemptionPolicy is the Policy for preempting pods with lower priority. One of Never, PreemptLowerPriority. Defaults to PreemptLowerPriority if unset. This field is beta-level, gated by the NonPreemptingPriority feature-gate. + - **overhead** (map[string]}}">Quantity) - Overhead represents the resource overhead associated with running a pod for a given RuntimeClass. This field will be autopopulated at admission time by the RuntimeClass admission controller. If the RuntimeClass admission controller is enabled, overhead must not be set in Pod create requests. The RuntimeClass admission controller will reject Pod create requests which have the overhead already set. If RuntimeClass is configured and selected in the PodSpec, Overhead will be set to the value defined in the corresponding RuntimeClass, otherwise it will remain unset and treated as zero. More info: https://git.k8s.io/enhancements/keps/sig-node/20190226-pod-overhead.md This field is alpha-level as of Kubernetes v1.16, and is only honored by servers that enable the PodOverhead feature. - -- **topologySpreadConstraints** ([]TopologySpreadConstraint) - - *Patch strategy: merge on key `topologyKey`* - - *Map: unique values on keys `topologyKey, whenUnsatisfiable` will be kept during a merge* - - TopologySpreadConstraints describes how a group of pods ought to spread across topology domains. Scheduler will schedule pods in a way which abides by the constraints. All topologySpreadConstraints are ANDed. - - - *TopologySpreadConstraint specifies how to spread matching pods among the given topology.* - - - **topologySpreadConstraints.maxSkew** (int32), required - - MaxSkew describes the degree to which pods may be unevenly distributed. When `whenUnsatisfiable=DoNotSchedule`, it is the maximum permitted difference between the number of matching pods in the target topology and the global minimum. For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same labelSelector spread as 1/1/0: | zone1 | zone2 | zone3 | | P | P | | - if MaxSkew is 1, incoming pod can only be scheduled to zone3 to become 1/1/1; scheduling it onto zone1(zone2) would make the ActualSkew(2-0) on zone1(zone2) violate MaxSkew(1). - if MaxSkew is 2, incoming pod can be scheduled onto any zone. When `whenUnsatisfiable=ScheduleAnyway`, it is used to give higher precedence to topologies that satisfy it. It's a required field. Default value is 1 and 0 is not allowed. - - - **topologySpreadConstraints.topologyKey** (string), required - - TopologyKey is the key of node labels. Nodes that have a label with this key and identical values are considered to be in the same topology. We consider each \ as a "bucket", and try to put balanced number of pods into each bucket. It's a required field. - - - **topologySpreadConstraints.whenUnsatisfiable** (string), required - - WhenUnsatisfiable indicates how to deal with a pod if it doesn't satisfy the spread constraint. - DoNotSchedule (default) tells the scheduler not to schedule it. - ScheduleAnyway tells the scheduler to schedule the pod in any location, - but giving higher precedence to topologies that would help reduce the - skew. - A constraint is considered "Unsatisfiable" for an incoming pod if and only if every possible node assigment for that pod would violate "MaxSkew" on some topology. For example, in a 3-zone cluster, MaxSkew is set to 1, and pods with the same labelSelector spread as 3/1/1: | zone1 | zone2 | zone3 | | P P P | P | P | If WhenUnsatisfiable is set to DoNotSchedule, incoming pod can only be scheduled to zone2(zone3) to become 3/2/1(3/1/2) as ActualSkew(2-1) on zone2(zone3) satisfies MaxSkew(1). In other words, the cluster can still be imbalanced, but scheduler won't make it *more* imbalanced. It's a required field. - - - **topologySpreadConstraints.labelSelector** (}}">LabelSelector) - - LabelSelector is used to find matching pods. Pods that match this label selector are counted to determine the number of pods in their corresponding topology domain. + Overhead represents the resource overhead associated with running a pod for a given RuntimeClass. This field will be autopopulated at admission time by the RuntimeClass admission controller. If the RuntimeClass admission controller is enabled, overhead must not be set in Pod create requests. The RuntimeClass admission controller will reject Pod create requests which have the overhead already set. If RuntimeClass is configured and selected in the PodSpec, Overhead will be set to the value defined in the corresponding RuntimeClass, otherwise it will remain unset and treated as zero. More info: https://git.k8s.io/enhancements/keps/sig-node/688-pod-overhead/README.md This field is beta-level as of Kubernetes v1.18, and is only honored by servers that enable the PodOverhead feature. ### Alpha level -- **ephemeralContainers** ([]}}">EphemeralContainer) +- **ephemeralContainers** ([]}}">EphemeralContainer) *Patch strategy: merge on key `name`* List of ephemeral containers run in this pod. Ephemeral containers may be run in an existing pod to perform user-initiated actions such as debugging. This list cannot be specified when creating a pod, and it cannot be modified by updating the pod spec. In order to add an ephemeral container to an existing pod, use the pod's ephemeralcontainers subresource. This field is alpha-level and is only honored by servers that enable the EphemeralContainers feature. -- **preemptionPolicy** (string) - - PreemptionPolicy is the Policy for preempting pods with lower priority. One of Never, PreemptLowerPriority. Defaults to PreemptLowerPriority if unset. This field is beta-level, gated by the NonPreemptingPriority feature-gate. - ### Deprecated @@ -449,6 +465,1240 @@ PodSpec is a description of a pod. +## Container {#Container} + +A single application container that you want to run within a pod. + +
+ +- **name** (string), required + + Name of the container specified as a DNS_LABEL. Each container in a pod must have a unique name (DNS_LABEL). Cannot be updated. + + + +### Image + + +- **image** (string) + + Docker image name. More info: https://kubernetes.io/docs/concepts/containers/images This field is optional to allow higher level config management to default or override container images in workload controllers like Deployments and StatefulSets. + +- **imagePullPolicy** (string) + + Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated. More info: https://kubernetes.io/docs/concepts/containers/images#updating-images + +### Entrypoint + + +- **command** ([]string) + + Entrypoint array. Not executed within a shell. The docker image's ENTRYPOINT is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container's environment. If a variable cannot be resolved, the reference in the input string will be unchanged. Double $$ are reduced to a single $, which allows for escaping the $(VAR_NAME) syntax: i.e. "$$(VAR_NAME)" will produce the string literal "$(VAR_NAME)". Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell + +- **args** ([]string) + + Arguments to the entrypoint. The docker image's CMD is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container's environment. If a variable cannot be resolved, the reference in the input string will be unchanged. Double $$ are reduced to a single $, which allows for escaping the $(VAR_NAME) syntax: i.e. "$$(VAR_NAME)" will produce the string literal "$(VAR_NAME)". Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell + +- **workingDir** (string) + + Container's working directory. If not specified, the container runtime's default will be used, which might be configured in the container image. Cannot be updated. + +### Ports + + +- **ports** ([]ContainerPort) + + *Patch strategy: merge on key `containerPort`* + + *Map: unique values on keys `containerPort, protocol` will be kept during a merge* + + List of ports to expose from the container. Exposing a port here gives the system additional information about the network connections a container uses, but is primarily informational. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. Cannot be updated. + + + *ContainerPort represents a network port in a single container.* + + - **ports.containerPort** (int32), required + + Number of port to expose on the pod's IP address. This must be a valid port number, 0 \< x \< 65536. + + - **ports.hostIP** (string) + + What host IP to bind the external port to. + + - **ports.hostPort** (int32) + + Number of port to expose on the host. If specified, this must be a valid port number, 0 \< x \< 65536. If HostNetwork is specified, this must match ContainerPort. Most containers do not need this. + + - **ports.name** (string) + + If specified, this must be an IANA_SVC_NAME and unique within the pod. Each named port in a pod must have a unique name. Name for the port that can be referred to by services. + + - **ports.protocol** (string) + + Protocol for port. Must be UDP, TCP, or SCTP. Defaults to "TCP". + +### Environment variables + + +- **env** ([]EnvVar) + + *Patch strategy: merge on key `name`* + + List of environment variables to set in the container. Cannot be updated. + + + *EnvVar represents an environment variable present in a Container.* + + - **env.name** (string), required + + Name of the environment variable. Must be a C_IDENTIFIER. + + - **env.value** (string) + + Variable references $(VAR_NAME) are expanded using the previously defined environment variables in the container and any service environment variables. If a variable cannot be resolved, the reference in the input string will be unchanged. Double $$ are reduced to a single $, which allows for escaping the $(VAR_NAME) syntax: i.e. "$$(VAR_NAME)" will produce the string literal "$(VAR_NAME)". Escaped references will never be expanded, regardless of whether the variable exists or not. Defaults to "". + + - **env.valueFrom** (EnvVarSource) + + Source for the environment variable's value. Cannot be used if value is not empty. + + + *EnvVarSource represents a source for the value of an EnvVar.* + + - **env.valueFrom.configMapKeyRef** (ConfigMapKeySelector) + + Selects a key of a ConfigMap. + + + *Selects a key from a ConfigMap.* + + - **env.valueFrom.configMapKeyRef.key** (string), required + + The key to select. + + - **env.valueFrom.configMapKeyRef.name** (string) + + Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names + + - **env.valueFrom.configMapKeyRef.optional** (boolean) + + Specify whether the ConfigMap or its key must be defined + + - **env.valueFrom.fieldRef** (}}">ObjectFieldSelector) + + Selects a field of the pod: supports metadata.name, metadata.namespace, `metadata.labels['\']`, `metadata.annotations['\']`, spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs. + + - **env.valueFrom.resourceFieldRef** (}}">ResourceFieldSelector) + + Selects a resource of the container: only resources limits and requests (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory and requests.ephemeral-storage) are currently supported. + + - **env.valueFrom.secretKeyRef** (SecretKeySelector) + + Selects a key of a secret in the pod's namespace + + + *SecretKeySelector selects a key of a Secret.* + + - **env.valueFrom.secretKeyRef.key** (string), required + + The key of the secret to select from. Must be a valid secret key. + + - **env.valueFrom.secretKeyRef.name** (string) + + Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names + + - **env.valueFrom.secretKeyRef.optional** (boolean) + + Specify whether the Secret or its key must be defined + +- **envFrom** ([]EnvFromSource) + + List of sources to populate environment variables in the container. The keys defined within a source must be a C_IDENTIFIER. All invalid keys will be reported as an event when the container is starting. When a key exists in multiple sources, the value associated with the last source will take precedence. Values defined by an Env with a duplicate key will take precedence. Cannot be updated. + + + *EnvFromSource represents the source of a set of ConfigMaps* + + - **envFrom.configMapRef** (ConfigMapEnvSource) + + The ConfigMap to select from + + + *ConfigMapEnvSource selects a ConfigMap to populate the environment variables with. + + The contents of the target ConfigMap's Data field will represent the key-value pairs as environment variables.* + + - **envFrom.configMapRef.name** (string) + + Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names + + - **envFrom.configMapRef.optional** (boolean) + + Specify whether the ConfigMap must be defined + + - **envFrom.prefix** (string) + + An optional identifier to prepend to each key in the ConfigMap. Must be a C_IDENTIFIER. + + - **envFrom.secretRef** (SecretEnvSource) + + The Secret to select from + + + *SecretEnvSource selects a Secret to populate the environment variables with. + + The contents of the target Secret's Data field will represent the key-value pairs as environment variables.* + + - **envFrom.secretRef.name** (string) + + Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names + + - **envFrom.secretRef.optional** (boolean) + + Specify whether the Secret must be defined + +### Volumes + + +- **volumeMounts** ([]VolumeMount) + + *Patch strategy: merge on key `mountPath`* + + Pod volumes to mount into the container's filesystem. Cannot be updated. + + + *VolumeMount describes a mounting of a Volume within a container.* + + - **volumeMounts.mountPath** (string), required + + Path within the container at which the volume should be mounted. Must not contain ':'. + + - **volumeMounts.name** (string), required + + This must match the Name of a Volume. + + - **volumeMounts.mountPropagation** (string) + + mountPropagation determines how mounts are propagated from the host to container and the other way around. When not set, MountPropagationNone is used. This field is beta in 1.10. + + - **volumeMounts.readOnly** (boolean) + + Mounted read-only if true, read-write otherwise (false or unspecified). Defaults to false. + + - **volumeMounts.subPath** (string) + + Path within the volume from which the container's volume should be mounted. Defaults to "" (volume's root). + + - **volumeMounts.subPathExpr** (string) + + Expanded path within the volume from which the container's volume should be mounted. Behaves similarly to SubPath but environment variable references $(VAR_NAME) are expanded using the container's environment. Defaults to "" (volume's root). SubPathExpr and SubPath are mutually exclusive. + +- **volumeDevices** ([]VolumeDevice) + + *Patch strategy: merge on key `devicePath`* + + volumeDevices is the list of block devices to be used by the container. + + + *volumeDevice describes a mapping of a raw block device within a container.* + + - **volumeDevices.devicePath** (string), required + + devicePath is the path inside of the container that the device will be mapped to. + + - **volumeDevices.name** (string), required + + name must match the name of a persistentVolumeClaim in the pod + +### Resources + + +- **resources** (ResourceRequirements) + + Compute Resources required by this container. Cannot be updated. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ + + + *ResourceRequirements describes the compute resource requirements.* + + - **resources.limits** (map[string]}}">Quantity) + + Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ + + - **resources.requests** (map[string]}}">Quantity) + + Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ + +### Lifecycle + + +- **lifecycle** (Lifecycle) + + Actions that the management system should take in response to container lifecycle events. Cannot be updated. + + + *Lifecycle describes actions that the management system should take in response to container lifecycle events. For the PostStart and PreStop lifecycle handlers, management of the container blocks until the action is complete, unless the container process fails, in which case the handler is aborted.* + + - **lifecycle.postStart** (}}">Handler) + + PostStart is called immediately after a container is created. If the handler fails, the container is terminated and restarted according to its restart policy. Other management of the container blocks until the hook completes. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks + + - **lifecycle.preStop** (}}">Handler) + + PreStop is called immediately before a container is terminated due to an API request or management event such as liveness/startup probe failure, preemption, resource contention, etc. The handler is not called if the container crashes or exits. The reason for termination is passed to the handler. The Pod's termination grace period countdown begins before the PreStop hooked is executed. Regardless of the outcome of the handler, the container will eventually terminate within the Pod's termination grace period. Other management of the container blocks until the hook completes or until the termination grace period is reached. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks + +- **terminationMessagePath** (string) + + Optional: Path at which the file to which the container's termination message will be written is mounted into the container's filesystem. Message written is intended to be brief final status, such as an assertion failure message. Will be truncated by the node if greater than 4096 bytes. The total message length across all containers will be limited to 12kb. Defaults to /dev/termination-log. Cannot be updated. + +- **terminationMessagePolicy** (string) + + Indicate how the termination message should be populated. File will use the contents of terminationMessagePath to populate the container status message on both success and failure. FallbackToLogsOnError will use the last chunk of container log output if the termination message file is empty and the container exited with an error. The log output is limited to 2048 bytes or 80 lines, whichever is smaller. Defaults to File. Cannot be updated. + +- **livenessProbe** (}}">Probe) + + Periodic probe of container liveness. Container will be restarted if the probe fails. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes + +- **readinessProbe** (}}">Probe) + + Periodic probe of container service readiness. Container will be removed from service endpoints if the probe fails. Cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes + +- **startupProbe** (}}">Probe) + + StartupProbe indicates that the Pod has successfully initialized. If specified, no other probes are executed until this completes successfully. If this probe fails, the Pod will be restarted, just as if the livenessProbe failed. This can be used to provide different probe parameters at the beginning of a Pod's lifecycle, when it might take a long time to load data or warm a cache, than during steady-state operation. This cannot be updated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes + +### Security Context + + +- **securityContext** (SecurityContext) + + SecurityContext defines the security options the container should be run with. If set, the fields of SecurityContext override the equivalent fields of PodSecurityContext. More info: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ + + + *SecurityContext holds security configuration that will be applied to a container. Some fields are present in both SecurityContext and PodSecurityContext. When both are set, the values in SecurityContext take precedence.* + + - **securityContext.runAsUser** (int64) + + The UID to run the entrypoint of the container process. Defaults to user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. + + - **securityContext.runAsNonRoot** (boolean) + + Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. + + - **securityContext.runAsGroup** (int64) + + The GID to run the entrypoint of the container process. Uses runtime default if unset. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. + + - **securityContext.readOnlyRootFilesystem** (boolean) + + Whether this container has a read-only root filesystem. Default is false. + + - **securityContext.procMount** (string) + + procMount denotes the type of proc mount to use for the containers. The default is DefaultProcMount which uses the container runtime defaults for readonly paths and masked paths. This requires the ProcMountType feature flag to be enabled. + + - **securityContext.privileged** (boolean) + + Run container in privileged mode. Processes in privileged containers are essentially equivalent to root on the host. Defaults to false. + + - **securityContext.allowPrivilegeEscalation** (boolean) + + AllowPrivilegeEscalation controls whether a process can gain more privileges than its parent process. This bool directly controls if the no_new_privs flag will be set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged 2) has CAP_SYS_ADMIN + + - **securityContext.capabilities** (Capabilities) + + The capabilities to add/drop when running containers. Defaults to the default set of capabilities granted by the container runtime. + + + *Adds and removes POSIX capabilities from running containers.* + + - **securityContext.capabilities.add** ([]string) + + Added capabilities + + - **securityContext.capabilities.drop** ([]string) + + Removed capabilities + + - **securityContext.seccompProfile** (SeccompProfile) + + The seccomp options to use by this container. If seccomp options are provided at both the pod & container level, the container options override the pod options. + + + *SeccompProfile defines a pod/container's seccomp profile settings. Only one profile source may be set.* + + - **securityContext.seccompProfile.type** (string), required + + type indicates which kind of seccomp profile will be applied. Valid options are: + + Localhost - a profile defined in a file on the node should be used. RuntimeDefault - the container runtime default profile should be used. Unconfined - no profile should be applied. + + - **securityContext.seccompProfile.localhostProfile** (string) + + localhostProfile indicates a profile defined in a file on the node should be used. The profile must be preconfigured on the node to work. Must be a descending path, relative to the kubelet's configured seccomp profile location. Must only be set if type is "Localhost". + + - **securityContext.seLinuxOptions** (SELinuxOptions) + + The SELinux context to be applied to the container. If unspecified, the container runtime will allocate a random SELinux context for each container. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. + + + *SELinuxOptions are the labels to be applied to the container* + + - **securityContext.seLinuxOptions.level** (string) + + Level is SELinux level label that applies to the container. + + - **securityContext.seLinuxOptions.role** (string) + + Role is a SELinux role label that applies to the container. + + - **securityContext.seLinuxOptions.type** (string) + + Type is a SELinux type label that applies to the container. + + - **securityContext.seLinuxOptions.user** (string) + + User is a SELinux user label that applies to the container. + + - **securityContext.windowsOptions** (WindowsSecurityContextOptions) + + The Windows specific settings applied to all containers. If unspecified, the options from the PodSecurityContext will be used. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. + + + *WindowsSecurityContextOptions contain Windows-specific options and credentials.* + + - **securityContext.windowsOptions.gmsaCredentialSpec** (string) + + GMSACredentialSpec is where the GMSA admission webhook (https://github.com/kubernetes-sigs/windows-gmsa) inlines the contents of the GMSA credential spec named by the GMSACredentialSpecName field. + + - **securityContext.windowsOptions.gmsaCredentialSpecName** (string) + + GMSACredentialSpecName is the name of the GMSA credential spec to use. + + - **securityContext.windowsOptions.hostProcess** (boolean) + + HostProcess determines if a container should be run as a 'Host Process' container. This field is alpha-level and will only be honored by components that enable the WindowsHostProcessContainers feature flag. Setting this field without the feature flag will result in errors when validating the Pod. All of a Pod's containers must have the same effective HostProcess value (it is not allowed to have a mix of HostProcess containers and non-HostProcess containers). In addition, if HostProcess is true then HostNetwork must also be set to true. + + - **securityContext.windowsOptions.runAsUserName** (string) + + The UserName in Windows to run the entrypoint of the container process. Defaults to the user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. + +### Debugging + + +- **stdin** (boolean) + + Whether this container should allocate a buffer for stdin in the container runtime. If this is not set, reads from stdin in the container will always result in EOF. Default is false. + +- **stdinOnce** (boolean) + + Whether the container runtime should close the stdin channel after it has been opened by a single attach. When stdin is true the stdin stream will remain open across multiple attach sessions. If stdinOnce is set to true, stdin is opened on container start, is empty until the first client attaches to stdin, and then remains open and accepts data until the client disconnects, at which time stdin is closed and remains closed until the container is restarted. If this flag is false, a container processes that reads from stdin will never receive an EOF. Default is false + +- **tty** (boolean) + + Whether this container should allocate a TTY for itself, also requires 'stdin' to be true. Default is false. + + + +## EphemeralContainer {#EphemeralContainer} + +An EphemeralContainer is a container that may be added temporarily to an existing pod for user-initiated activities such as debugging. Ephemeral containers have no resource or scheduling guarantees, and they will not be restarted when they exit or when a pod is removed or restarted. If an ephemeral container causes a pod to exceed its resource allocation, the pod may be evicted. Ephemeral containers may not be added by directly updating the pod spec. They must be added via the pod's ephemeralcontainers subresource, and they will appear in the pod spec once added. This is an alpha feature enabled by the EphemeralContainers feature flag. + +
+ +- **name** (string), required + + Name of the ephemeral container specified as a DNS_LABEL. This name must be unique among all containers, init containers and ephemeral containers. + +- **targetContainerName** (string) + + If set, the name of the container from PodSpec that this ephemeral container targets. The ephemeral container will be run in the namespaces (IPC, PID, etc) of this container. If not set then the ephemeral container is run in whatever namespaces are shared for the pod. Note that the container runtime must support this feature. + + + +### Image + + +- **image** (string) + + Docker image name. More info: https://kubernetes.io/docs/concepts/containers/images + +- **imagePullPolicy** (string) + + Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated. More info: https://kubernetes.io/docs/concepts/containers/images#updating-images + +### Entrypoint + + +- **command** ([]string) + + Entrypoint array. Not executed within a shell. The docker image's ENTRYPOINT is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container's environment. If a variable cannot be resolved, the reference in the input string will be unchanged. Double $$ are reduced to a single $, which allows for escaping the $(VAR_NAME) syntax: i.e. "$$(VAR_NAME)" will produce the string literal "$(VAR_NAME)". Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell + +- **args** ([]string) + + Arguments to the entrypoint. The docker image's CMD is used if this is not provided. Variable references $(VAR_NAME) are expanded using the container's environment. If a variable cannot be resolved, the reference in the input string will be unchanged. Double $$ are reduced to a single $, which allows for escaping the $(VAR_NAME) syntax: i.e. "$$(VAR_NAME)" will produce the string literal "$(VAR_NAME)". Escaped references will never be expanded, regardless of whether the variable exists or not. Cannot be updated. More info: https://kubernetes.io/docs/tasks/inject-data-application/define-command-argument-container/#running-a-command-in-a-shell + +- **workingDir** (string) + + Container's working directory. If not specified, the container runtime's default will be used, which might be configured in the container image. Cannot be updated. + +### Environment variables + + +- **env** ([]EnvVar) + + *Patch strategy: merge on key `name`* + + List of environment variables to set in the container. Cannot be updated. + + + *EnvVar represents an environment variable present in a Container.* + + - **env.name** (string), required + + Name of the environment variable. Must be a C_IDENTIFIER. + + - **env.value** (string) + + Variable references $(VAR_NAME) are expanded using the previously defined environment variables in the container and any service environment variables. If a variable cannot be resolved, the reference in the input string will be unchanged. Double $$ are reduced to a single $, which allows for escaping the $(VAR_NAME) syntax: i.e. "$$(VAR_NAME)" will produce the string literal "$(VAR_NAME)". Escaped references will never be expanded, regardless of whether the variable exists or not. Defaults to "". + + - **env.valueFrom** (EnvVarSource) + + Source for the environment variable's value. Cannot be used if value is not empty. + + + *EnvVarSource represents a source for the value of an EnvVar.* + + - **env.valueFrom.configMapKeyRef** (ConfigMapKeySelector) + + Selects a key of a ConfigMap. + + + *Selects a key from a ConfigMap.* + + - **env.valueFrom.configMapKeyRef.key** (string), required + + The key to select. + + - **env.valueFrom.configMapKeyRef.name** (string) + + Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names + + - **env.valueFrom.configMapKeyRef.optional** (boolean) + + Specify whether the ConfigMap or its key must be defined + + - **env.valueFrom.fieldRef** (}}">ObjectFieldSelector) + + Selects a field of the pod: supports metadata.name, metadata.namespace, `metadata.labels['\']`, `metadata.annotations['\']`, spec.nodeName, spec.serviceAccountName, status.hostIP, status.podIP, status.podIPs. + + - **env.valueFrom.resourceFieldRef** (}}">ResourceFieldSelector) + + Selects a resource of the container: only resources limits and requests (limits.cpu, limits.memory, limits.ephemeral-storage, requests.cpu, requests.memory and requests.ephemeral-storage) are currently supported. + + - **env.valueFrom.secretKeyRef** (SecretKeySelector) + + Selects a key of a secret in the pod's namespace + + + *SecretKeySelector selects a key of a Secret.* + + - **env.valueFrom.secretKeyRef.key** (string), required + + The key of the secret to select from. Must be a valid secret key. + + - **env.valueFrom.secretKeyRef.name** (string) + + Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names + + - **env.valueFrom.secretKeyRef.optional** (boolean) + + Specify whether the Secret or its key must be defined + +- **envFrom** ([]EnvFromSource) + + List of sources to populate environment variables in the container. The keys defined within a source must be a C_IDENTIFIER. All invalid keys will be reported as an event when the container is starting. When a key exists in multiple sources, the value associated with the last source will take precedence. Values defined by an Env with a duplicate key will take precedence. Cannot be updated. + + + *EnvFromSource represents the source of a set of ConfigMaps* + + - **envFrom.configMapRef** (ConfigMapEnvSource) + + The ConfigMap to select from + + + *ConfigMapEnvSource selects a ConfigMap to populate the environment variables with. + + The contents of the target ConfigMap's Data field will represent the key-value pairs as environment variables.* + + - **envFrom.configMapRef.name** (string) + + Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names + + - **envFrom.configMapRef.optional** (boolean) + + Specify whether the ConfigMap must be defined + + - **envFrom.prefix** (string) + + An optional identifier to prepend to each key in the ConfigMap. Must be a C_IDENTIFIER. + + - **envFrom.secretRef** (SecretEnvSource) + + The Secret to select from + + + *SecretEnvSource selects a Secret to populate the environment variables with. + + The contents of the target Secret's Data field will represent the key-value pairs as environment variables.* + + - **envFrom.secretRef.name** (string) + + Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names + + - **envFrom.secretRef.optional** (boolean) + + Specify whether the Secret must be defined + +### Volumes + + +- **volumeMounts** ([]VolumeMount) + + *Patch strategy: merge on key `mountPath`* + + Pod volumes to mount into the container's filesystem. Cannot be updated. + + + *VolumeMount describes a mounting of a Volume within a container.* + + - **volumeMounts.mountPath** (string), required + + Path within the container at which the volume should be mounted. Must not contain ':'. + + - **volumeMounts.name** (string), required + + This must match the Name of a Volume. + + - **volumeMounts.mountPropagation** (string) + + mountPropagation determines how mounts are propagated from the host to container and the other way around. When not set, MountPropagationNone is used. This field is beta in 1.10. + + - **volumeMounts.readOnly** (boolean) + + Mounted read-only if true, read-write otherwise (false or unspecified). Defaults to false. + + - **volumeMounts.subPath** (string) + + Path within the volume from which the container's volume should be mounted. Defaults to "" (volume's root). + + - **volumeMounts.subPathExpr** (string) + + Expanded path within the volume from which the container's volume should be mounted. Behaves similarly to SubPath but environment variable references $(VAR_NAME) are expanded using the container's environment. Defaults to "" (volume's root). SubPathExpr and SubPath are mutually exclusive. + +- **volumeDevices** ([]VolumeDevice) + + *Patch strategy: merge on key `devicePath`* + + volumeDevices is the list of block devices to be used by the container. + + + *volumeDevice describes a mapping of a raw block device within a container.* + + - **volumeDevices.devicePath** (string), required + + devicePath is the path inside of the container that the device will be mapped to. + + - **volumeDevices.name** (string), required + + name must match the name of a persistentVolumeClaim in the pod + +### Lifecycle + + +- **terminationMessagePath** (string) + + Optional: Path at which the file to which the container's termination message will be written is mounted into the container's filesystem. Message written is intended to be brief final status, such as an assertion failure message. Will be truncated by the node if greater than 4096 bytes. The total message length across all containers will be limited to 12kb. Defaults to /dev/termination-log. Cannot be updated. + +- **terminationMessagePolicy** (string) + + Indicate how the termination message should be populated. File will use the contents of terminationMessagePath to populate the container status message on both success and failure. FallbackToLogsOnError will use the last chunk of container log output if the termination message file is empty and the container exited with an error. The log output is limited to 2048 bytes or 80 lines, whichever is smaller. Defaults to File. Cannot be updated. + +### Debugging + + +- **stdin** (boolean) + + Whether this container should allocate a buffer for stdin in the container runtime. If this is not set, reads from stdin in the container will always result in EOF. Default is false. + +- **stdinOnce** (boolean) + + Whether the container runtime should close the stdin channel after it has been opened by a single attach. When stdin is true the stdin stream will remain open across multiple attach sessions. If stdinOnce is set to true, stdin is opened on container start, is empty until the first client attaches to stdin, and then remains open and accepts data until the client disconnects, at which time stdin is closed and remains closed until the container is restarted. If this flag is false, a container processes that reads from stdin will never receive an EOF. Default is false + +- **tty** (boolean) + + Whether this container should allocate a TTY for itself, also requires 'stdin' to be true. Default is false. + +### Not allowed + + +- **ports** ([]ContainerPort) + + Ports are not allowed for ephemeral containers. + + + *ContainerPort represents a network port in a single container.* + + - **ports.containerPort** (int32), required + + Number of port to expose on the pod's IP address. This must be a valid port number, 0 \< x \< 65536. + + - **ports.hostIP** (string) + + What host IP to bind the external port to. + + - **ports.hostPort** (int32) + + Number of port to expose on the host. If specified, this must be a valid port number, 0 \< x \< 65536. If HostNetwork is specified, this must match ContainerPort. Most containers do not need this. + + - **ports.name** (string) + + If specified, this must be an IANA_SVC_NAME and unique within the pod. Each named port in a pod must have a unique name. Name for the port that can be referred to by services. + + - **ports.protocol** (string) + + Protocol for port. Must be UDP, TCP, or SCTP. Defaults to "TCP". + +- **resources** (ResourceRequirements) + + Resources are not allowed for ephemeral containers. Ephemeral containers use spare resources already allocated to the pod. + + + *ResourceRequirements describes the compute resource requirements.* + + - **resources.limits** (map[string]}}">Quantity) + + Limits describes the maximum amount of compute resources allowed. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ + + - **resources.requests** (map[string]}}">Quantity) + + Requests describes the minimum amount of compute resources required. If Requests is omitted for a container, it defaults to Limits if that is explicitly specified, otherwise to an implementation-defined value. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ + +- **lifecycle** (Lifecycle) + + Lifecycle is not allowed for ephemeral containers. + + + *Lifecycle describes actions that the management system should take in response to container lifecycle events. For the PostStart and PreStop lifecycle handlers, management of the container blocks until the action is complete, unless the container process fails, in which case the handler is aborted.* + + - **lifecycle.postStart** (}}">Handler) + + PostStart is called immediately after a container is created. If the handler fails, the container is terminated and restarted according to its restart policy. Other management of the container blocks until the hook completes. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks + + - **lifecycle.preStop** (}}">Handler) + + PreStop is called immediately before a container is terminated due to an API request or management event such as liveness/startup probe failure, preemption, resource contention, etc. The handler is not called if the container crashes or exits. The reason for termination is passed to the handler. The Pod's termination grace period countdown begins before the PreStop hooked is executed. Regardless of the outcome of the handler, the container will eventually terminate within the Pod's termination grace period. Other management of the container blocks until the hook completes or until the termination grace period is reached. More info: https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#container-hooks + +- **livenessProbe** (}}">Probe) + + Probes are not allowed for ephemeral containers. + +- **readinessProbe** (}}">Probe) + + Probes are not allowed for ephemeral containers. + +- **securityContext** (SecurityContext) + + Optional: SecurityContext defines the security options the ephemeral container should be run with. If set, the fields of SecurityContext override the equivalent fields of PodSecurityContext. + + + *SecurityContext holds security configuration that will be applied to a container. Some fields are present in both SecurityContext and PodSecurityContext. When both are set, the values in SecurityContext take precedence.* + + - **securityContext.runAsUser** (int64) + + The UID to run the entrypoint of the container process. Defaults to user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. + + - **securityContext.runAsNonRoot** (boolean) + + Indicates that the container must run as a non-root user. If true, the Kubelet will validate the image at runtime to ensure that it does not run as UID 0 (root) and fail to start the container if it does. If unset or false, no such validation will be performed. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. + + - **securityContext.runAsGroup** (int64) + + The GID to run the entrypoint of the container process. Uses runtime default if unset. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. + + - **securityContext.readOnlyRootFilesystem** (boolean) + + Whether this container has a read-only root filesystem. Default is false. + + - **securityContext.procMount** (string) + + procMount denotes the type of proc mount to use for the containers. The default is DefaultProcMount which uses the container runtime defaults for readonly paths and masked paths. This requires the ProcMountType feature flag to be enabled. + + - **securityContext.privileged** (boolean) + + Run container in privileged mode. Processes in privileged containers are essentially equivalent to root on the host. Defaults to false. + + - **securityContext.allowPrivilegeEscalation** (boolean) + + AllowPrivilegeEscalation controls whether a process can gain more privileges than its parent process. This bool directly controls if the no_new_privs flag will be set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged 2) has CAP_SYS_ADMIN + + - **securityContext.capabilities** (Capabilities) + + The capabilities to add/drop when running containers. Defaults to the default set of capabilities granted by the container runtime. + + + *Adds and removes POSIX capabilities from running containers.* + + - **securityContext.capabilities.add** ([]string) + + Added capabilities + + - **securityContext.capabilities.drop** ([]string) + + Removed capabilities + + - **securityContext.seccompProfile** (SeccompProfile) + + The seccomp options to use by this container. If seccomp options are provided at both the pod & container level, the container options override the pod options. + + + *SeccompProfile defines a pod/container's seccomp profile settings. Only one profile source may be set.* + + - **securityContext.seccompProfile.type** (string), required + + type indicates which kind of seccomp profile will be applied. Valid options are: + + Localhost - a profile defined in a file on the node should be used. RuntimeDefault - the container runtime default profile should be used. Unconfined - no profile should be applied. + + - **securityContext.seccompProfile.localhostProfile** (string) + + localhostProfile indicates a profile defined in a file on the node should be used. The profile must be preconfigured on the node to work. Must be a descending path, relative to the kubelet's configured seccomp profile location. Must only be set if type is "Localhost". + + - **securityContext.seLinuxOptions** (SELinuxOptions) + + The SELinux context to be applied to the container. If unspecified, the container runtime will allocate a random SELinux context for each container. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. + + + *SELinuxOptions are the labels to be applied to the container* + + - **securityContext.seLinuxOptions.level** (string) + + Level is SELinux level label that applies to the container. + + - **securityContext.seLinuxOptions.role** (string) + + Role is a SELinux role label that applies to the container. + + - **securityContext.seLinuxOptions.type** (string) + + Type is a SELinux type label that applies to the container. + + - **securityContext.seLinuxOptions.user** (string) + + User is a SELinux user label that applies to the container. + + - **securityContext.windowsOptions** (WindowsSecurityContextOptions) + + The Windows specific settings applied to all containers. If unspecified, the options from the PodSecurityContext will be used. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. + + + *WindowsSecurityContextOptions contain Windows-specific options and credentials.* + + - **securityContext.windowsOptions.gmsaCredentialSpec** (string) + + GMSACredentialSpec is where the GMSA admission webhook (https://github.com/kubernetes-sigs/windows-gmsa) inlines the contents of the GMSA credential spec named by the GMSACredentialSpecName field. + + - **securityContext.windowsOptions.gmsaCredentialSpecName** (string) + + GMSACredentialSpecName is the name of the GMSA credential spec to use. + + - **securityContext.windowsOptions.hostProcess** (boolean) + + HostProcess determines if a container should be run as a 'Host Process' container. This field is alpha-level and will only be honored by components that enable the WindowsHostProcessContainers feature flag. Setting this field without the feature flag will result in errors when validating the Pod. All of a Pod's containers must have the same effective HostProcess value (it is not allowed to have a mix of HostProcess containers and non-HostProcess containers). In addition, if HostProcess is true then HostNetwork must also be set to true. + + - **securityContext.windowsOptions.runAsUserName** (string) + + The UserName in Windows to run the entrypoint of the container process. Defaults to the user specified in image metadata if unspecified. May also be set in PodSecurityContext. If set in both SecurityContext and PodSecurityContext, the value specified in SecurityContext takes precedence. + +- **startupProbe** (}}">Probe) + + Probes are not allowed for ephemeral containers. + + + +## Handler {#Handler} + +Handler defines a specific action that should be taken + +
+ +- **exec** (ExecAction) + + One and only one of the following should be specified. Exec specifies the action to take. + + + *ExecAction describes a "run in container" action.* + + - **exec.command** ([]string) + + Command is the command line to execute inside the container, the working directory for the command is root ('/') in the container's filesystem. The command is simply exec'd, it is not run inside a shell, so traditional shell instructions ('|', etc) won't work. To use a shell, you need to explicitly call out to that shell. Exit status of 0 is treated as live/healthy and non-zero is unhealthy. + +- **httpGet** (HTTPGetAction) + + HTTPGet specifies the http request to perform. + + + *HTTPGetAction describes an action based on HTTP Get requests.* + + - **httpGet.port** (IntOrString), required + + Name or number of the port to access on the container. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. + + + *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* + + - **httpGet.host** (string) + + Host name to connect to, defaults to the pod IP. You probably want to set "Host" in httpHeaders instead. + + - **httpGet.httpHeaders** ([]HTTPHeader) + + Custom headers to set in the request. HTTP allows repeated headers. + + + *HTTPHeader describes a custom header to be used in HTTP probes* + + - **httpGet.httpHeaders.name** (string), required + + The header field name + + - **httpGet.httpHeaders.value** (string), required + + The header field value + + - **httpGet.path** (string) + + Path to access on the HTTP server. + + - **httpGet.scheme** (string) + + Scheme to use for connecting to the host. Defaults to HTTP. + +- **tcpSocket** (TCPSocketAction) + + TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported + + + *TCPSocketAction describes an action based on opening a socket* + + - **tcpSocket.port** (IntOrString), required + + Number or name of the port to access on the container. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. + + + *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* + + - **tcpSocket.host** (string) + + Optional: Host name to connect to, defaults to the pod IP. + + + + + +## NodeAffinity {#NodeAffinity} + +Node affinity is a group of node affinity scheduling rules. + +
+ +- **preferredDuringSchedulingIgnoredDuringExecution** ([]PreferredSchedulingTerm) + + The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node matches the corresponding matchExpressions; the node(s) with the highest sum are the most preferred. + + + *An empty preferred scheduling term matches all objects with implicit weight 0 (i.e. it's a no-op). A null preferred scheduling term matches no objects (i.e. is also a no-op).* + + - **preferredDuringSchedulingIgnoredDuringExecution.preference** (NodeSelectorTerm), required + + A node selector term, associated with the corresponding weight. + + + *A null or empty node selector term matches no objects. The requirements of them are ANDed. The TopologySelectorTerm type implements a subset of the NodeSelectorTerm.* + + - **preferredDuringSchedulingIgnoredDuringExecution.preference.matchExpressions** ([]}}">NodeSelectorRequirement) + + A list of node selector requirements by node's labels. + + - **preferredDuringSchedulingIgnoredDuringExecution.preference.matchFields** ([]}}">NodeSelectorRequirement) + + A list of node selector requirements by node's fields. + + - **preferredDuringSchedulingIgnoredDuringExecution.weight** (int32), required + + Weight associated with matching the corresponding nodeSelectorTerm, in the range 1-100. + +- **requiredDuringSchedulingIgnoredDuringExecution** (NodeSelector) + + If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to an update), the system may or may not try to eventually evict the pod from its node. + + + *A node selector represents the union of the results of one or more label queries over a set of nodes; that is, it represents the OR of the selectors represented by the node selector terms.* + + - **requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms** ([]NodeSelectorTerm), required + + Required. A list of node selector terms. The terms are ORed. + + + *A null or empty node selector term matches no objects. The requirements of them are ANDed. The TopologySelectorTerm type implements a subset of the NodeSelectorTerm.* + + - **requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchExpressions** ([]}}">NodeSelectorRequirement) + + A list of node selector requirements by node's labels. + + - **requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms.matchFields** ([]}}">NodeSelectorRequirement) + + A list of node selector requirements by node's fields. + + + + + +## PodAffinity {#PodAffinity} + +Pod affinity is a group of inter pod affinity scheduling rules. + +
+ +- **preferredDuringSchedulingIgnoredDuringExecution** ([]WeightedPodAffinityTerm) + + The scheduler will prefer to schedule pods to nodes that satisfy the affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the node(s) with the highest sum are the most preferred. + + + *The weights of all of the matched WeightedPodAffinityTerm fields are added per-node to find the most preferred node(s)* + + - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm** (PodAffinityTerm), required + + Required. A pod affinity term, associated with the corresponding weight. + + + *Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key matches that of any node on which a pod of the set of pods is running* + + - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.topologyKey** (string), required + + This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed. + + - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.labelSelector** (}}">LabelSelector) + + A label query over a set of resources, in this case pods. + + - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.namespaceSelector** (}}">LabelSelector) + + A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces. This field is beta-level and is only honored when PodAffinityNamespaceSelector feature is enabled. + + - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.namespaces** ([]string) + + namespaces specifies a static list of namespace names that the term applies to. The term is applied to the union of the namespaces listed in this field and the ones selected by namespaceSelector. null or empty namespaces list and null namespaceSelector means "this pod's namespace" + + - **preferredDuringSchedulingIgnoredDuringExecution.weight** (int32), required + + weight associated with matching the corresponding podAffinityTerm, in the range 1-100. + +- **requiredDuringSchedulingIgnoredDuringExecution** ([]PodAffinityTerm) + + If the affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node. When there are multiple elements, the lists of nodes corresponding to each podAffinityTerm are intersected, i.e. all terms must be satisfied. + + + *Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key matches that of any node on which a pod of the set of pods is running* + + - **requiredDuringSchedulingIgnoredDuringExecution.topologyKey** (string), required + + This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed. + + - **requiredDuringSchedulingIgnoredDuringExecution.labelSelector** (}}">LabelSelector) + + A label query over a set of resources, in this case pods. + + - **requiredDuringSchedulingIgnoredDuringExecution.namespaceSelector** (}}">LabelSelector) + + A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces. This field is beta-level and is only honored when PodAffinityNamespaceSelector feature is enabled. + + - **requiredDuringSchedulingIgnoredDuringExecution.namespaces** ([]string) + + namespaces specifies a static list of namespace names that the term applies to. The term is applied to the union of the namespaces listed in this field and the ones selected by namespaceSelector. null or empty namespaces list and null namespaceSelector means "this pod's namespace" + + + + + +## PodAntiAffinity {#PodAntiAffinity} + +Pod anti affinity is a group of inter pod anti affinity scheduling rules. + +
+ +- **preferredDuringSchedulingIgnoredDuringExecution** ([]WeightedPodAffinityTerm) + + The scheduler will prefer to schedule pods to nodes that satisfy the anti-affinity expressions specified by this field, but it may choose a node that violates one or more of the expressions. The node that is most preferred is the one with the greatest sum of weights, i.e. for each node that meets all of the scheduling requirements (resource request, requiredDuringScheduling anti-affinity expressions, etc.), compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node has pods which matches the corresponding podAffinityTerm; the node(s) with the highest sum are the most preferred. + + + *The weights of all of the matched WeightedPodAffinityTerm fields are added per-node to find the most preferred node(s)* + + - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm** (PodAffinityTerm), required + + Required. A pod affinity term, associated with the corresponding weight. + + + *Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key matches that of any node on which a pod of the set of pods is running* + + - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.topologyKey** (string), required + + This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed. + + - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.labelSelector** (}}">LabelSelector) + + A label query over a set of resources, in this case pods. + + - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.namespaceSelector** (}}">LabelSelector) + + A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces. This field is beta-level and is only honored when PodAffinityNamespaceSelector feature is enabled. + + - **preferredDuringSchedulingIgnoredDuringExecution.podAffinityTerm.namespaces** ([]string) + + namespaces specifies a static list of namespace names that the term applies to. The term is applied to the union of the namespaces listed in this field and the ones selected by namespaceSelector. null or empty namespaces list and null namespaceSelector means "this pod's namespace" + + - **preferredDuringSchedulingIgnoredDuringExecution.weight** (int32), required + + weight associated with matching the corresponding podAffinityTerm, in the range 1-100. + +- **requiredDuringSchedulingIgnoredDuringExecution** ([]PodAffinityTerm) + + If the anti-affinity requirements specified by this field are not met at scheduling time, the pod will not be scheduled onto the node. If the anti-affinity requirements specified by this field cease to be met at some point during pod execution (e.g. due to a pod label update), the system may or may not try to eventually evict the pod from its node. When there are multiple elements, the lists of nodes corresponding to each podAffinityTerm are intersected, i.e. all terms must be satisfied. + + + *Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key matches that of any node on which a pod of the set of pods is running* + + - **requiredDuringSchedulingIgnoredDuringExecution.topologyKey** (string), required + + This pod should be co-located (affinity) or not co-located (anti-affinity) with the pods matching the labelSelector in the specified namespaces, where co-located is defined as running on a node whose value of the label with key topologyKey matches that of any node on which any of the selected pods is running. Empty topologyKey is not allowed. + + - **requiredDuringSchedulingIgnoredDuringExecution.labelSelector** (}}">LabelSelector) + + A label query over a set of resources, in this case pods. + + - **requiredDuringSchedulingIgnoredDuringExecution.namespaceSelector** (}}">LabelSelector) + + A label query over the set of namespaces that the term applies to. The term is applied to the union of the namespaces selected by this field and the ones listed in the namespaces field. null selector and null or empty namespaces list means "this pod's namespace". An empty selector ({}) matches all namespaces. This field is beta-level and is only honored when PodAffinityNamespaceSelector feature is enabled. + + - **requiredDuringSchedulingIgnoredDuringExecution.namespaces** ([]string) + + namespaces specifies a static list of namespace names that the term applies to. The term is applied to the union of the namespaces listed in this field and the ones selected by namespaceSelector. null or empty namespaces list and null namespaceSelector means "this pod's namespace" + + + + + +## Probe {#Probe} + +Probe describes a health check to be performed against a container to determine whether it is alive or ready to receive traffic. + +
+ +- **exec** (ExecAction) + + One and only one of the following should be specified. Exec specifies the action to take. + + + *ExecAction describes a "run in container" action.* + + - **exec.command** ([]string) + + Command is the command line to execute inside the container, the working directory for the command is root ('/') in the container's filesystem. The command is simply exec'd, it is not run inside a shell, so traditional shell instructions ('|', etc) won't work. To use a shell, you need to explicitly call out to that shell. Exit status of 0 is treated as live/healthy and non-zero is unhealthy. + +- **httpGet** (HTTPGetAction) + + HTTPGet specifies the http request to perform. + + + *HTTPGetAction describes an action based on HTTP Get requests.* + + - **httpGet.port** (IntOrString), required + + Name or number of the port to access on the container. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. + + + *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* + + - **httpGet.host** (string) + + Host name to connect to, defaults to the pod IP. You probably want to set "Host" in httpHeaders instead. + + - **httpGet.httpHeaders** ([]HTTPHeader) + + Custom headers to set in the request. HTTP allows repeated headers. + + + *HTTPHeader describes a custom header to be used in HTTP probes* + + - **httpGet.httpHeaders.name** (string), required + + The header field name + + - **httpGet.httpHeaders.value** (string), required + + The header field value + + - **httpGet.path** (string) + + Path to access on the HTTP server. + + - **httpGet.scheme** (string) + + Scheme to use for connecting to the host. Defaults to HTTP. + +- **tcpSocket** (TCPSocketAction) + + TCPSocket specifies an action involving a TCP port. TCP hooks not yet supported + + + *TCPSocketAction describes an action based on opening a socket* + + - **tcpSocket.port** (IntOrString), required + + Number or name of the port to access on the container. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. + + + *IntOrString is a type that can hold an int32 or a string. When used in JSON or YAML marshalling and unmarshalling, it produces or consumes the inner type. This allows you to have, for example, a JSON field that can accept a name or number.* + + - **tcpSocket.host** (string) + + Optional: Host name to connect to, defaults to the pod IP. + +- **initialDelaySeconds** (int32) + + Number of seconds after the container has started before liveness probes are initiated. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes + +- **terminationGracePeriodSeconds** (int64) + + Optional duration in seconds the pod needs to terminate gracefully upon probe failure. The grace period is the duration in seconds after the processes running in the pod are sent a termination signal and the time when the processes are forcibly halted with a kill signal. Set this value longer than the expected cleanup time for your process. If this value is nil, the pod's terminationGracePeriodSeconds will be used. Otherwise, this value overrides the value provided by the pod spec. Value must be non-negative integer. The value zero indicates stop immediately via the kill signal (no opportunity to shut down). This is a beta field and requires enabling ProbeTerminationGracePeriod feature gate. Minimum value is 1. spec.terminationGracePeriodSeconds is used if unset. + +- **periodSeconds** (int32) + + How often (in seconds) to perform the probe. Default to 10 seconds. Minimum value is 1. + +- **timeoutSeconds** (int32) + + Number of seconds after which the probe times out. Defaults to 1 second. Minimum value is 1. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes + +- **failureThreshold** (int32) + + Minimum consecutive failures for the probe to be considered failed after having succeeded. Defaults to 3. Minimum value is 1. + +- **successThreshold** (int32) + + Minimum consecutive successes for the probe to be considered successful after having failed. Defaults to 1. Must be 1 for liveness and startup. Minimum value is 1. + + + + + ## PodStatus {#PodStatus} PodStatus represents information about the status of a pod. Status may trail the actual state of a system, especially if the node that hosts the pod cannot contact the control plane. @@ -547,18 +1797,573 @@ PodStatus represents information about the status of a pod. Status may trail the The Quality of Service (QOS) classification assigned to the pod based on resource requirements See PodQOSClass type for available QOS classes More info: https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md -- **initContainerStatuses** ([]}}">ContainerStatus) +- **initContainerStatuses** ([]ContainerStatus) The list has one entry per init container in the manifest. The most recent successful init container will have ready = true, the most recently started container will have startTime set. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-and-container-status -- **containerStatuses** ([]}}">ContainerStatus) + + *ContainerStatus contains details for the current status of this container.* + + - **initContainerStatuses.name** (string), required + + This must be a DNS_LABEL. Each container in a pod must have a unique name. Cannot be updated. + + - **initContainerStatuses.image** (string), required + + The image the container is running. More info: https://kubernetes.io/docs/concepts/containers/images + + - **initContainerStatuses.imageID** (string), required + + ImageID of the container's image. + + - **initContainerStatuses.containerID** (string) + + Container's ID in the format 'docker://\'. + + - **initContainerStatuses.state** (ContainerState) + + Details about the container's current condition. + + + *ContainerState holds a possible state of container. Only one of its members may be specified. If none of them is specified, the default one is ContainerStateWaiting.* + + - **initContainerStatuses.state.running** (ContainerStateRunning) + + Details about a running container + + + *ContainerStateRunning is a running state of a container.* + + - **initContainerStatuses.state.running.startedAt** (Time) + + Time at which the container was last (re-)started + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **initContainerStatuses.state.terminated** (ContainerStateTerminated) + + Details about a terminated container + + + *ContainerStateTerminated is a terminated state of a container.* + + - **initContainerStatuses.state.terminated.containerID** (string) + + Container's ID in the format 'docker://\' + + - **initContainerStatuses.state.terminated.exitCode** (int32), required + + Exit status from the last termination of the container + + - **initContainerStatuses.state.terminated.startedAt** (Time) + + Time at which previous execution of the container started + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **initContainerStatuses.state.terminated.finishedAt** (Time) + + Time at which the container last terminated + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **initContainerStatuses.state.terminated.message** (string) + + Message regarding the last termination of the container + + - **initContainerStatuses.state.terminated.reason** (string) + + (brief) reason from the last termination of the container + + - **initContainerStatuses.state.terminated.signal** (int32) + + Signal from the last termination of the container + + - **initContainerStatuses.state.waiting** (ContainerStateWaiting) + + Details about a waiting container + + + *ContainerStateWaiting is a waiting state of a container.* + + - **initContainerStatuses.state.waiting.message** (string) + + Message regarding why the container is not yet running. + + - **initContainerStatuses.state.waiting.reason** (string) + + (brief) reason the container is not yet running. + + - **initContainerStatuses.lastState** (ContainerState) + + Details about the container's last termination condition. + + + *ContainerState holds a possible state of container. Only one of its members may be specified. If none of them is specified, the default one is ContainerStateWaiting.* + + - **initContainerStatuses.lastState.running** (ContainerStateRunning) + + Details about a running container + + + *ContainerStateRunning is a running state of a container.* + + - **initContainerStatuses.lastState.running.startedAt** (Time) + + Time at which the container was last (re-)started + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **initContainerStatuses.lastState.terminated** (ContainerStateTerminated) + + Details about a terminated container + + + *ContainerStateTerminated is a terminated state of a container.* + + - **initContainerStatuses.lastState.terminated.containerID** (string) + + Container's ID in the format 'docker://\' + + - **initContainerStatuses.lastState.terminated.exitCode** (int32), required + + Exit status from the last termination of the container + + - **initContainerStatuses.lastState.terminated.startedAt** (Time) + + Time at which previous execution of the container started + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **initContainerStatuses.lastState.terminated.finishedAt** (Time) + + Time at which the container last terminated + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **initContainerStatuses.lastState.terminated.message** (string) + + Message regarding the last termination of the container + + - **initContainerStatuses.lastState.terminated.reason** (string) + + (brief) reason from the last termination of the container + + - **initContainerStatuses.lastState.terminated.signal** (int32) + + Signal from the last termination of the container + + - **initContainerStatuses.lastState.waiting** (ContainerStateWaiting) + + Details about a waiting container + + + *ContainerStateWaiting is a waiting state of a container.* + + - **initContainerStatuses.lastState.waiting.message** (string) + + Message regarding why the container is not yet running. + + - **initContainerStatuses.lastState.waiting.reason** (string) + + (brief) reason the container is not yet running. + + - **initContainerStatuses.ready** (boolean), required + + Specifies whether the container has passed its readiness probe. + + - **initContainerStatuses.restartCount** (int32), required + + The number of times the container has been restarted, currently based on the number of dead containers that have not yet been removed. Note that this is calculated from dead containers. But those containers are subject to garbage collection. This value will get capped at 5 by GC. + + - **initContainerStatuses.started** (boolean) + + Specifies whether the container has passed its startup probe. Initialized as false, becomes true after startupProbe is considered successful. Resets to false when the container is restarted, or if kubelet loses state temporarily. Is always true when no startupProbe is defined. + +- **containerStatuses** ([]ContainerStatus) The list has one entry per container in the manifest. Each entry is currently the output of `docker inspect`. More info: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#pod-and-container-status -- **ephemeralContainerStatuses** ([]}}">ContainerStatus) + + *ContainerStatus contains details for the current status of this container.* + + - **containerStatuses.name** (string), required + + This must be a DNS_LABEL. Each container in a pod must have a unique name. Cannot be updated. + + - **containerStatuses.image** (string), required + + The image the container is running. More info: https://kubernetes.io/docs/concepts/containers/images + + - **containerStatuses.imageID** (string), required + + ImageID of the container's image. + + - **containerStatuses.containerID** (string) + + Container's ID in the format 'docker://\'. + + - **containerStatuses.state** (ContainerState) + + Details about the container's current condition. + + + *ContainerState holds a possible state of container. Only one of its members may be specified. If none of them is specified, the default one is ContainerStateWaiting.* + + - **containerStatuses.state.running** (ContainerStateRunning) + + Details about a running container + + + *ContainerStateRunning is a running state of a container.* + + - **containerStatuses.state.running.startedAt** (Time) + + Time at which the container was last (re-)started + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **containerStatuses.state.terminated** (ContainerStateTerminated) + + Details about a terminated container + + + *ContainerStateTerminated is a terminated state of a container.* + + - **containerStatuses.state.terminated.containerID** (string) + + Container's ID in the format 'docker://\' + + - **containerStatuses.state.terminated.exitCode** (int32), required + + Exit status from the last termination of the container + + - **containerStatuses.state.terminated.startedAt** (Time) + + Time at which previous execution of the container started + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **containerStatuses.state.terminated.finishedAt** (Time) + + Time at which the container last terminated + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **containerStatuses.state.terminated.message** (string) + + Message regarding the last termination of the container + + - **containerStatuses.state.terminated.reason** (string) + + (brief) reason from the last termination of the container + + - **containerStatuses.state.terminated.signal** (int32) + + Signal from the last termination of the container + + - **containerStatuses.state.waiting** (ContainerStateWaiting) + + Details about a waiting container + + + *ContainerStateWaiting is a waiting state of a container.* + + - **containerStatuses.state.waiting.message** (string) + + Message regarding why the container is not yet running. + + - **containerStatuses.state.waiting.reason** (string) + + (brief) reason the container is not yet running. + + - **containerStatuses.lastState** (ContainerState) + + Details about the container's last termination condition. + + + *ContainerState holds a possible state of container. Only one of its members may be specified. If none of them is specified, the default one is ContainerStateWaiting.* + + - **containerStatuses.lastState.running** (ContainerStateRunning) + + Details about a running container + + + *ContainerStateRunning is a running state of a container.* + + - **containerStatuses.lastState.running.startedAt** (Time) + + Time at which the container was last (re-)started + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **containerStatuses.lastState.terminated** (ContainerStateTerminated) + + Details about a terminated container + + + *ContainerStateTerminated is a terminated state of a container.* + + - **containerStatuses.lastState.terminated.containerID** (string) + + Container's ID in the format 'docker://\' + + - **containerStatuses.lastState.terminated.exitCode** (int32), required + + Exit status from the last termination of the container + + - **containerStatuses.lastState.terminated.startedAt** (Time) + + Time at which previous execution of the container started + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **containerStatuses.lastState.terminated.finishedAt** (Time) + + Time at which the container last terminated + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **containerStatuses.lastState.terminated.message** (string) + + Message regarding the last termination of the container + + - **containerStatuses.lastState.terminated.reason** (string) + + (brief) reason from the last termination of the container + + - **containerStatuses.lastState.terminated.signal** (int32) + + Signal from the last termination of the container + + - **containerStatuses.lastState.waiting** (ContainerStateWaiting) + + Details about a waiting container + + + *ContainerStateWaiting is a waiting state of a container.* + + - **containerStatuses.lastState.waiting.message** (string) + + Message regarding why the container is not yet running. + + - **containerStatuses.lastState.waiting.reason** (string) + + (brief) reason the container is not yet running. + + - **containerStatuses.ready** (boolean), required + + Specifies whether the container has passed its readiness probe. + + - **containerStatuses.restartCount** (int32), required + + The number of times the container has been restarted, currently based on the number of dead containers that have not yet been removed. Note that this is calculated from dead containers. But those containers are subject to garbage collection. This value will get capped at 5 by GC. + + - **containerStatuses.started** (boolean) + + Specifies whether the container has passed its startup probe. Initialized as false, becomes true after startupProbe is considered successful. Resets to false when the container is restarted, or if kubelet loses state temporarily. Is always true when no startupProbe is defined. + +- **ephemeralContainerStatuses** ([]ContainerStatus) Status for any ephemeral containers that have run in this pod. This field is alpha-level and is only populated by servers that enable the EphemeralContainers feature. + + *ContainerStatus contains details for the current status of this container.* + + - **ephemeralContainerStatuses.name** (string), required + + This must be a DNS_LABEL. Each container in a pod must have a unique name. Cannot be updated. + + - **ephemeralContainerStatuses.image** (string), required + + The image the container is running. More info: https://kubernetes.io/docs/concepts/containers/images + + - **ephemeralContainerStatuses.imageID** (string), required + + ImageID of the container's image. + + - **ephemeralContainerStatuses.containerID** (string) + + Container's ID in the format 'docker://\'. + + - **ephemeralContainerStatuses.state** (ContainerState) + + Details about the container's current condition. + + + *ContainerState holds a possible state of container. Only one of its members may be specified. If none of them is specified, the default one is ContainerStateWaiting.* + + - **ephemeralContainerStatuses.state.running** (ContainerStateRunning) + + Details about a running container + + + *ContainerStateRunning is a running state of a container.* + + - **ephemeralContainerStatuses.state.running.startedAt** (Time) + + Time at which the container was last (re-)started + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **ephemeralContainerStatuses.state.terminated** (ContainerStateTerminated) + + Details about a terminated container + + + *ContainerStateTerminated is a terminated state of a container.* + + - **ephemeralContainerStatuses.state.terminated.containerID** (string) + + Container's ID in the format 'docker://\' + + - **ephemeralContainerStatuses.state.terminated.exitCode** (int32), required + + Exit status from the last termination of the container + + - **ephemeralContainerStatuses.state.terminated.startedAt** (Time) + + Time at which previous execution of the container started + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **ephemeralContainerStatuses.state.terminated.finishedAt** (Time) + + Time at which the container last terminated + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **ephemeralContainerStatuses.state.terminated.message** (string) + + Message regarding the last termination of the container + + - **ephemeralContainerStatuses.state.terminated.reason** (string) + + (brief) reason from the last termination of the container + + - **ephemeralContainerStatuses.state.terminated.signal** (int32) + + Signal from the last termination of the container + + - **ephemeralContainerStatuses.state.waiting** (ContainerStateWaiting) + + Details about a waiting container + + + *ContainerStateWaiting is a waiting state of a container.* + + - **ephemeralContainerStatuses.state.waiting.message** (string) + + Message regarding why the container is not yet running. + + - **ephemeralContainerStatuses.state.waiting.reason** (string) + + (brief) reason the container is not yet running. + + - **ephemeralContainerStatuses.lastState** (ContainerState) + + Details about the container's last termination condition. + + + *ContainerState holds a possible state of container. Only one of its members may be specified. If none of them is specified, the default one is ContainerStateWaiting.* + + - **ephemeralContainerStatuses.lastState.running** (ContainerStateRunning) + + Details about a running container + + + *ContainerStateRunning is a running state of a container.* + + - **ephemeralContainerStatuses.lastState.running.startedAt** (Time) + + Time at which the container was last (re-)started + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **ephemeralContainerStatuses.lastState.terminated** (ContainerStateTerminated) + + Details about a terminated container + + + *ContainerStateTerminated is a terminated state of a container.* + + - **ephemeralContainerStatuses.lastState.terminated.containerID** (string) + + Container's ID in the format 'docker://\' + + - **ephemeralContainerStatuses.lastState.terminated.exitCode** (int32), required + + Exit status from the last termination of the container + + - **ephemeralContainerStatuses.lastState.terminated.startedAt** (Time) + + Time at which previous execution of the container started + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **ephemeralContainerStatuses.lastState.terminated.finishedAt** (Time) + + Time at which the container last terminated + + + *Time is a wrapper around time.Time which supports correct marshaling to YAML and JSON. Wrappers are provided for many of the factory methods that the time package offers.* + + - **ephemeralContainerStatuses.lastState.terminated.message** (string) + + Message regarding the last termination of the container + + - **ephemeralContainerStatuses.lastState.terminated.reason** (string) + + (brief) reason from the last termination of the container + + - **ephemeralContainerStatuses.lastState.terminated.signal** (int32) + + Signal from the last termination of the container + + - **ephemeralContainerStatuses.lastState.waiting** (ContainerStateWaiting) + + Details about a waiting container + + + *ContainerStateWaiting is a waiting state of a container.* + + - **ephemeralContainerStatuses.lastState.waiting.message** (string) + + Message regarding why the container is not yet running. + + - **ephemeralContainerStatuses.lastState.waiting.reason** (string) + + (brief) reason the container is not yet running. + + - **ephemeralContainerStatuses.ready** (boolean), required + + Specifies whether the container has passed its readiness probe. + + - **ephemeralContainerStatuses.restartCount** (int32), required + + The number of times the container has been restarted, currently based on the number of dead containers that have not yet been removed. Note that this is calculated from dead containers. But those containers are subject to garbage collection. This value will get capped at 5 by GC. + + - **ephemeralContainerStatuses.started** (boolean) + + Specifies whether the container has passed its startup probe. Initialized as false, becomes true after startupProbe is considered successful. Resets to false when the container is restarted, or if kubelet loses state temporarily. Is always true when no startupProbe is defined. + @@ -569,20 +2374,22 @@ PodList is a list of Pods.
-- **apiVersion**: v1 +- **items** ([]}}">Pod), required + List of pods. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md -- **kind**: PodList +- **apiVersion** (string) + APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources + +- **kind** (string) + + Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds - **metadata** (}}">ListMeta) Standard list metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds -- **items** ([]}}">Pod), required - - List of pods. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md - @@ -623,6 +2430,39 @@ GET /api/v1/namespaces/{namespace}/pods/{name} +#### Response + + +200 (}}">Pod): OK + +401: Unauthorized + + +### `get` read ephemeralcontainers of the specified Pod + +#### HTTP Request + +GET /api/v1/namespaces/{namespace}/pods/{name}/ephemeralcontainers + +#### Parameters + + +- **name** (*in path*): string, required + + name of the Pod + + +- **namespace** (*in path*): string, required + + }}">namespace + + +- **pretty** (*in query*): string + + }}">pretty + + + #### Response @@ -949,6 +2789,56 @@ PUT /api/v1/namespaces/{namespace}/pods/{name} +- **dryRun** (*in query*): string + + }}">dryRun + + +- **fieldManager** (*in query*): string + + }}">fieldManager + + +- **pretty** (*in query*): string + + }}">pretty + + + +#### Response + + +200 (}}">Pod): OK + +201 (}}">Pod): Created + +401: Unauthorized + + +### `update` replace ephemeralcontainers of the specified Pod + +#### HTTP Request + +PUT /api/v1/namespaces/{namespace}/pods/{name}/ephemeralcontainers + +#### Parameters + + +- **name** (*in path*): string, required + + name of the Pod + + +- **namespace** (*in path*): string, required + + }}">namespace + + +- **body**: }}">Pod, required + + + + - **dryRun** (*in query*): string }}">dryRun @@ -1075,6 +2965,63 @@ PATCH /api/v1/namespaces/{namespace}/pods/{name} 200 (}}">Pod): OK +201 (}}">Pod): Created + +401: Unauthorized + + +### `patch` partially update ephemeralcontainers of the specified Pod + +#### HTTP Request + +PATCH /api/v1/namespaces/{namespace}/pods/{name}/ephemeralcontainers + +#### Parameters + + +- **name** (*in path*): string, required + + name of the Pod + + +- **namespace** (*in path*): string, required + + }}">namespace + + +- **body**: }}">Patch, required + + + + +- **dryRun** (*in query*): string + + }}">dryRun + + +- **fieldManager** (*in query*): string + + }}">fieldManager + + +- **force** (*in query*): boolean + + }}">force + + +- **pretty** (*in query*): string + + }}">pretty + + + +#### Response + + +200 (}}">Pod): OK + +201 (}}">Pod): Created + 401: Unauthorized @@ -1128,6 +3075,8 @@ PATCH /api/v1/namespaces/{namespace}/pods/{name}/status 200 (}}">Pod): OK +201 (}}">Pod): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/priority-class-v1.md b/content/en/docs/reference/kubernetes-api/workload-resources/priority-class-v1.md index 28087807c1..cd96fe6790 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/priority-class-v1.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/priority-class-v1.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "PriorityClass defines mapping from a priority class name to the priority integer value." title: "PriorityClass" -weight: 16 +weight: 13 +auto_generated: true --- + + `apiVersion: scheduling.k8s.io/v1` `import "k8s.io/api/scheduling/v1"` @@ -313,6 +325,8 @@ PATCH /apis/scheduling.k8s.io/v1/priorityclasses/{name} 200 (}}">PriorityClass): OK +201 (}}">PriorityClass): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/replica-set-v1.md b/content/en/docs/reference/kubernetes-api/workload-resources/replica-set-v1.md index 708b0fd966..f2c5f894af 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/replica-set-v1.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/replica-set-v1.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "ReplicaSet ensures that a specified number of pod replicas are running at any given time." title: "ReplicaSet" -weight: 6 +weight: 4 +auto_generated: true --- + + `apiVersion: apps/v1` `import "k8s.io/api/apps/v1"` @@ -569,6 +581,8 @@ PATCH /apis/apps/v1/namespaces/{namespace}/replicasets/{name} 200 (}}">ReplicaSet): OK +201 (}}">ReplicaSet): Created + 401: Unauthorized @@ -622,6 +636,8 @@ PATCH /apis/apps/v1/namespaces/{namespace}/replicasets/{name}/status 200 (}}">ReplicaSet): OK +201 (}}">ReplicaSet): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/replication-controller-v1.md b/content/en/docs/reference/kubernetes-api/workload-resources/replication-controller-v1.md index 1f7962ee96..890897ecbb 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/replication-controller-v1.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/replication-controller-v1.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "ReplicationController represents the configuration of a replication controller." title: "ReplicationController" -weight: 5 +weight: 3 +auto_generated: true --- + + `apiVersion: v1` `import "k8s.io/api/core/v1"` @@ -569,6 +581,8 @@ PATCH /api/v1/namespaces/{namespace}/replicationcontrollers/{name} 200 (}}">ReplicationController): OK +201 (}}">ReplicationController): Created + 401: Unauthorized @@ -622,6 +636,8 @@ PATCH /api/v1/namespaces/{namespace}/replicationcontrollers/{name}/status 200 (}}">ReplicationController): OK +201 (}}">ReplicationController): Created + 401: Unauthorized diff --git a/content/en/docs/reference/kubernetes-api/workload-resources/stateful-set-v1.md b/content/en/docs/reference/kubernetes-api/workload-resources/stateful-set-v1.md index 17ea7755f2..6bc6da0e15 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/stateful-set-v1.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/stateful-set-v1.md @@ -6,9 +6,21 @@ api_metadata: content_type: "api_reference" description: "StatefulSet represents a set of pods with consistent identities." title: "StatefulSet" -weight: 8 +weight: 6 +auto_generated: true --- + + `apiVersion: apps/v1` `import "k8s.io/api/apps/v1"` @@ -31,6 +43,7 @@ The StatefulSet guarantees that a given network identity will always map to the - **metadata** (}}">ObjectMeta) + Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **spec** (}}">StatefulSetSpec) @@ -84,9 +97,9 @@ A StatefulSetSpec is the specification of a StatefulSet. *RollingUpdateStatefulSetStrategy is used to communicate parameter for RollingUpdateStatefulSetStrategyType.* - - **updateStrategy.rollingUpdate.partition** (int32) + - **updateStrategy.rollingUpdate.partition** (int32) - Partition indicates the ordinal at which the StatefulSet should be partitioned. Default value is 0. + Partition indicates the ordinal at which the StatefulSet should be partitioned. Default value is 0. - **podManagementPolicy** (string) @@ -100,6 +113,10 @@ A StatefulSetSpec is the specification of a StatefulSet. volumeClaimTemplates is a list of claims that pods are allowed to reference. The StatefulSet controller is responsible for mapping network identities to claims in a way that maintains the identity of a pod. Every claim in this list must have at least one matching (by name) volumeMount in one container in the template. A claim in this list takes precedence over any volumes in the template, with the same name. +- **minReadySeconds** (int32) + + Minimum number of seconds for which a newly created pod should be ready without any of its container crashing for it to be considered available. Defaults to 0 (pod will be considered available as soon as it is ready) This is an alpha field and requires enabling StatefulSetMinReadySeconds feature gate. + @@ -126,6 +143,10 @@ StatefulSetStatus represents the current state of a StatefulSet. updatedReplicas is the number of Pods created by the StatefulSet controller from the StatefulSet version indicated by updateRevision. +- **availableReplicas** (int32) + + Total number of available pods (ready for at least minReadySeconds) targeted by this statefulset. This is an alpha field and requires enabling StatefulSetMinReadySeconds feature gate. Remove omitempty when graduating to beta + - **collisionCount** (int32) collisionCount is the count of hash collisions for the StatefulSet. The StatefulSet controller uses this field as a collision avoidance mechanism when it needs to create the name for the newest ControllerRevision. @@ -192,9 +213,11 @@ StatefulSetList is a collection of StatefulSets. - **metadata** (}}">ListMeta) + Standard list's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata - **items** ([]}}">StatefulSet), required + Items is the list of stateful sets. @@ -615,6 +638,8 @@ PATCH /apis/apps/v1/namespaces/{namespace}/statefulsets/{name} 200 (}}">StatefulSet): OK +201 (}}">StatefulSet): Created + 401: Unauthorized @@ -668,6 +693,8 @@ PATCH /apis/apps/v1/namespaces/{namespace}/statefulsets/{name}/status 200 (}}">StatefulSet): OK +201 (}}">StatefulSet): Created + 401: Unauthorized diff --git a/content/en/docs/reference/labels-annotations-taints.md b/content/en/docs/reference/labels-annotations-taints.md index 8f4327ceca..07e6d19426 100644 --- a/content/en/docs/reference/labels-annotations-taints.md +++ b/content/en/docs/reference/labels-annotations-taints.md @@ -30,6 +30,20 @@ Used on: Node The Kubelet populates this with `runtime.GOOS` as defined by Go. This can be handy if you are mixing operating systems in your cluster (for example: mixing Linux and Windows nodes). +## kubernetes.io/metadata.name + +Example: `kubernetes.io/metadata.name=mynamespace` + +Used on: Namespaces + +When the `NamespaceDefaultLabelName` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled, +the Kubernetes API server sets this label on all namespaces. The label value is set to +the name of the namespace. + +This is useful if you want to target a specific namespace with a label +{{< glossary_tooltip text="selector" term_id="selector" >}}. + ## beta.kubernetes.io/arch (deprecated) This label has been deprecated. Please use `kubernetes.io/arch` instead. @@ -48,6 +62,16 @@ The Kubelet populates this label with the hostname. Note that the hostname can b This label is also used as part of the topology hierarchy. See [topology.kubernetes.io/zone](#topologykubernetesiozone) for more information. + +## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost} + +Example: `controller.kubernetes.io/pod-deletion-cost=10` + +Used on: Pod + +This annotation is used to set [Pod Deletion Cost](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost) +which allows users to influence ReplicaSet downscaling order. The annotation parses into an `int32` type. + ## beta.kubernetes.io/instance-type (deprecated) {{< note >}} Starting in v1.17, this label is deprecated in favor of [node.kubernetes.io/instance-type](#nodekubernetesioinstance-type). {{< /note >}} @@ -75,6 +99,18 @@ See [topology.kubernetes.io/zone](#topologykubernetesiozone). {{< note >}} Starting in v1.17, this label is deprecated in favor of [topology.kubernetes.io/zone](#topologykubernetesiozone). {{< /note >}} +## statefulset.kubernetes.io/pod-name {#statefulsetkubernetesiopod-name} + +Example: + +`statefulset.kubernetes.io/pod-name=mystatefulset-7` + +When a StatefulSet controller creates a Pod for the StatefulSet, the control plane +sets this label on that Pod. The value of the label is the name of the Pod being created. + +See [Pod Name Label](/docs/concepts/workloads/controllers/statefulset/#pod-name-label) in the +StatefulSet topic for more details. + ## topology.kubernetes.io/region {#topologykubernetesioregion} Example: @@ -164,7 +200,7 @@ Used on: Service The kube-proxy has this label for custom proxy, which delegates service control to custom proxy. -## experimental.windows.kubernetes.io/isolation-type +## experimental.windows.kubernetes.io/isolation-type (deprecated) {#experimental-windows-kubernetes-io-isolation-type} Example: `experimental.windows.kubernetes.io/isolation-type: "hyperv"` @@ -174,6 +210,7 @@ The annotation is used to run Windows containers with Hyper-V isolation. To use {{< note >}} You can only set this annotation on Pods that have a single container. +Starting from v1.20, this annotation is deprecated. Experimental Hyper-V support was removed in 1.21. {{< /note >}} ## ingressclass.kubernetes.io/is-default-class @@ -186,7 +223,18 @@ When a single IngressClass resource has this annotation set to `"true"`, new Ing ## kubernetes.io/ingress.class (deprecated) -{{< note >}} Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassName`. {{< /note >}} +{{< note >}} +Starting in v1.18, this annotation is deprecated in favor of `spec.ingressClassName`. +{{< /note >}} + +## storageclass.kubernetes.io/is-default-class + +Example: `storageclass.kubernetes.io/is-default-class=true` + +Used on: StorageClass + +When a single StorageClass resource has this annotation set to `"true"`, new PersistentVolumeClaim +resource without a class specified will be assigned this default class. ## alpha.kubernetes.io/provided-node-ip @@ -198,6 +246,47 @@ The kubelet can set this annotation on a Node to denote its configured IPv4 addr When kubelet is started with the "external" cloud provider, it sets this annotation on the Node to denote an IP address set from the command line flag (`--node-ip`). This IP is verified with the cloud provider as valid by the cloud-controller-manager. +## batch.kubernetes.io/job-completion-index + +Example: `batch.kubernetes.io/job-completion-index: "3"` + +Used on: Pod + +The Job controller in the kube-controller-manager sets this annotation for Pods +created with Indexed [completion mode](/docs/concepts/workloads/controllers/job/#completion-mode). + +## kubectl.kubernetes.io/default-container + +Example: `kubectl.kubernetes.io/default-container: "front-end-app"` + +The value of the annotation is the container name that is default for this Pod. For example, `kubectl logs` or `kubectl exec` without `-c` or `--container` flag will use this default container. + +## endpoints.kubernetes.io/over-capacity + +Example: `endpoints.kubernetes.io/over-capacity:truncated` + +Used on: Endpoints + +In Kubernetes clusters v1.22 (or later), the Endpoints controller adds this annotation to an Endpoints resource if it has more than 1000 endpoints. The annotation indicates that the Endpoints resource is over capacity and the number of endpoints has been truncated to 1000. + +## batch.kubernetes.io/job-tracking + +Example: `batch.kubernetes.io/job-tracking: ""` + +Used on: Jobs + +The presence of this annotation on a Job indicates that the control plane is +[tracking the Job status using finalizers](/docs/concepts/workloads/controllers/job/#job-tracking-with-finalizers). +You should **not** manually add or remove this annotation. + +## scheduler.alpha.kubernetes.io/preferAvoidPods (deprecated) {#scheduleralphakubernetesio-preferavoidpods} + +Used on: Nodes + +This annotation requires the [NodePreferAvoidPods scheduling plugin](/docs/reference/scheduling/config/#scheduling-plugins) +to be enabled. The plugin is deprecated since Kubernetes 1.22. +Use [Taints and Tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) instead. + **The taints listed below are always used on Nodes** ## node.kubernetes.io/not-ready @@ -254,3 +343,86 @@ Example: `node.cloudprovider.kubernetes.io/shutdown:NoSchedule` If a Node is in a cloud provider specified shutdown state, the Node gets tainted accordingly with `node.cloudprovider.kubernetes.io/shutdown` and the taint effect of `NoSchedule`. +## pod-security.kubernetes.io/enforce + +Example: `pod-security.kubernetes.io/enforce: baseline` + +Used on: Namespace + +Value **must** be one of `privileged`, `baseline`, or `restricted` which correspond to +[Pod Security Standard](/docs/concepts/security/pod-security-standards) levels. Specifically, +the `enforce` label _prohibits_ the creation of any Pod in the labeled Namespace which does not meet +the requirements outlined in the indicated level. + +See [Enforcing Pod Security at the Namespace Level](/docs/concepts/security/pod-security-admission) +for more information. + +## pod-security.kubernetes.io/enforce-version + +Example: `pod-security.kubernetes.io/enforce-version: {{< skew latestVersion >}}` + +Used on: Namespace + +Value **must** be `latest` or a valid Kubernetes version in the format `v.`. +This determines the version of the [Pod Security Standard](/docs/concepts/security/pod-security-standards) +policies to apply when validating a submitted Pod. + +See [Enforcing Pod Security at the Namespace Level](/docs/concepts/security/pod-security-admission) +for more information. + +## pod-security.kubernetes.io/audit + +Example: `pod-security.kubernetes.io/audit: baseline` + +Used on: Namespace + +Value **must** be one of `privileged`, `baseline`, or `restricted` which correspond to +[Pod Security Standard](/docs/concepts/security/pod-security-standards) levels. Specifically, +the `audit` label does not prevent the creation of a Pod in the labeled Namespace which does not meet +the requirements outlined in the indicated level, but adds an audit annotation to that Pod. + +See [Enforcing Pod Security at the Namespace Level](/docs/concepts/security/pod-security-admission) +for more information. + +## pod-security.kubernetes.io/audit-version + +Example: `pod-security.kubernetes.io/audit-version: {{< skew latestVersion >}}` + +Used on: Namespace + +Value **must** be `latest` or a valid Kubernetes version in the format `v.`. +This determines the version of the [Pod Security Standard](/docs/concepts/security/pod-security-standards) +policies to apply when validating a submitted Pod. + +See [Enforcing Pod Security at the Namespace Level](/docs/concepts/security/pod-security-admission) +for more information. + +## pod-security.kubernetes.io/warn + +Example: `pod-security.kubernetes.io/warn: baseline` + +Used on: Namespace + +Value **must** be one of `privileged`, `baseline`, or `restricted` which correspond to +[Pod Security Standard](/docs/concepts/security/pod-security-standards) levels. Specifically, +the `warn` label does not prevent the creation of a Pod in the labeled Namespace which does not meet the +requirements outlined in the indicated level, but returns a warning to the user after doing so. +Note that warnings are also displayed when creating or updating objects that contain Pod templates, +such as Deployments, Jobs, StatefulSets, etc. + +See [Enforcing Pod Security at the Namespace Level](/docs/concepts/security/pod-security-admission) +for more information. + +## pod-security.kubernetes.io/warn-version + +Example: `pod-security.kubernetes.io/warn-version: {{< skew latestVersion >}}` + +Used on: Namespace + +Value **must** be `latest` or a valid Kubernetes version in the format `v.`. +This determines the version of the [Pod Security Standard](/docs/concepts/security/pod-security-standards) +policies to apply when validating a submitted Pod. Note that warnings are also displayed when creating +or updating objects that contain Pod templates, such as Deployments, Jobs, StatefulSets, etc. + +See [Enforcing Pod Security at the Namespace Level](/docs/concepts/security/pod-security-admission) +for more information. \ No newline at end of file diff --git a/content/en/docs/reference/ports-and-protocols.md b/content/en/docs/reference/ports-and-protocols.md new file mode 100644 index 0000000000..91d6cba8e7 --- /dev/null +++ b/content/en/docs/reference/ports-and-protocols.md @@ -0,0 +1,40 @@ +--- +title: Ports and Protocols +content_type: reference +weight: 50 +--- + +When running Kubernetes in an environment with strict network boundaries, such +as on-premises datacenter with physical network firewalls or Virtual +Networks in Public Cloud, it is useful to be aware of the ports and protocols +used by Kubernetes components + +## Control plane + +| Protocol | Direction | Port Range | Purpose | Used By | +|----------|-----------|------------|-------------------------|---------------------------| +| TCP | Inbound | 6443 | Kubernetes API server | All | +| TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver, etcd | +| TCP | Inbound | 10250 | Kubelet API | Self, Control plane | +| TCP | Inbound | 10259 | kube-scheduler | Self | +| TCP | Inbound | 10257 | kube-controller-manager | Self | + +Although etcd ports are included in control plane section, you can also host your own +etcd cluster externally or on custom ports. + +## Worker node(s) {#node} + +| Protocol | Direction | Port Range | Purpose | Used By | +|----------|-----------|-------------|-----------------------|-------------------------| +| TCP | Inbound | 10250 | Kubelet API | Self, Control plane | +| TCP | Inbound | 30000-32767 | NodePort Services† | All | + +† Default port range for [NodePort Services](/docs/concepts/services-networking/service/). + +All default port numbers can be overridden. When custom ports are used those +ports need to be open instead of defaults mentioned here. + +One common example is API server port that is sometimes switched +to 443. Alternatively, the default port is kept as is and API server is put +behind a load balancer that listens on 443 and routes the requests to API server +on the default port. diff --git a/content/en/docs/reference/scheduling/config.md b/content/en/docs/reference/scheduling/config.md index 53889a21f3..e30ab2e133 100644 --- a/content/en/docs/reference/scheduling/config.md +++ b/content/en/docs/reference/scheduling/config.md @@ -15,18 +15,19 @@ file and passing its path as a command line argument. A scheduling Profile allows you to configure the different stages of scheduling in the {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}. -Each stage is exposed in a extension point. Plugins provide scheduling behaviors +Each stage is exposed in an extension point. Plugins provide scheduling behaviors by implementing one or more of these extension points. You can specify scheduling profiles by running `kube-scheduler --config `, -using the -[KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) +using the +KubeSchedulerConfiguration ([v1beta1](/docs/reference/config-api/kube-scheduler-config.v1beta1/) +or [v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/)) struct. A minimal configuration looks as follows: ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration clientConnection: kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig @@ -48,38 +49,41 @@ You can configure a single instance of `kube-scheduler` to run Scheduling happens in a series of stages that are exposed through the following extension points: -1. `QueueSort`: These plugins provide an ordering function that is used to +1. `queueSort`: These plugins provide an ordering function that is used to sort pending Pods in the scheduling queue. Exactly one queue sort plugin may be enabled at a time. -1. `PreFilter`: These plugins are used to pre-process or check information +1. `preFilter`: These plugins are used to pre-process or check information about a Pod or the cluster before filtering. They can mark a pod as unschedulable. -1. `Filter`: These plugins are the equivalent of Predicates in a scheduling +1. `filter`: These plugins are the equivalent of Predicates in a scheduling Policy and are used to filter out nodes that can not run the Pod. Filters are called in the configured order. A pod is marked as unschedulable if no nodes pass all the filters. -1. `PreScore`: This is an informational extension point that can be used +1. `postFilter`: These plugins are called in their configured order when no + feasible nodes were found for the pod. If any `postFilter` plugin marks the + Pod _schedulable_, the remaining plugins are not called. +1. `preScore`: This is an informational extension point that can be used for doing pre-scoring work. -1. `Score`: These plugins provide a score to each node that has passed the +1. `score`: These plugins provide a score to each node that has passed the filtering phase. The scheduler will then select the node with the highest weighted scores sum. -1. `Reserve`: This is an informational extension point that notifies plugins +1. `reserve`: This is an informational extension point that notifies plugins when resources have been reserved for a given Pod. Plugins also implement an `Unreserve` call that gets called in the case of failure during or after `Reserve`. -1. `Permit`: These plugins can prevent or delay the binding of a Pod. -1. `PreBind`: These plugins perform any work required before a Pod is bound. -1. `Bind`: The plugins bind a Pod to a Node. Bind plugins are called in order +1. `permit`: These plugins can prevent or delay the binding of a Pod. +1. `preBind`: These plugins perform any work required before a Pod is bound. +1. `bind`: The plugins bind a Pod to a Node. `bind` plugins are called in order and once one has done the binding, the remaining plugins are skipped. At least one bind plugin is required. -1. `PostBind`: This is an informational extension point that is called after +1. `postBind`: This is an informational extension point that is called after a Pod has been bound. For each extension point, you could disable specific [default plugins](#scheduling-plugins) or enable your own. For example: ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - plugins: @@ -99,101 +103,109 @@ desired. ### Scheduling plugins -1. `UnReserve`: This is an informational extension point that is called if - a Pod is rejected after being reserved and put on hold by a `Permit` plugin. - -## Scheduling plugins - The following plugins, enabled by default, implement one or more of these extension points: +- `ImageLocality`: Favors nodes that already have the container images that the + Pod runs. + Extension points: `score`. +- `TaintToleration`: Implements + [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/). + Implements extension points: `filter`, `preScore`, `score`. +- `NodeName`: Checks if a Pod spec node name matches the current node. + Extension points: `filter`. +- `NodePorts`: Checks if a node has free ports for the requested Pod ports. + Extension points: `preFilter`, `filter`. +- `NodePreferAvoidPods`: Scores nodes according to the node + {{< glossary_tooltip text="annotation" term_id="annotation" >}} + `scheduler.alpha.kubernetes.io/preferAvoidPods`. + Extension points: `score`. +- `NodeAffinity`: Implements + [node selectors](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) + and [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity). + Extension points: `filter`, `score`. +- `PodTopologySpread`: Implements + [Pod topology spread](/docs/concepts/workloads/pods/pod-topology-spread-constraints/). + Extension points: `preFilter`, `filter`, `preScore`, `score`. +- `NodeUnschedulable`: Filters out nodes that have `.spec.unschedulable` set to + true. + Extension points: `filter`. +- `NodeResourcesFit`: Checks if the node has all the resources that the Pod is + requesting. The score can use one of three strategies: `LeastAllocated` + (default), `MostAllocated` and `RequestedToCapacityRatio`. + Extension points: `preFilter`, `filter`, `score`. +- `NodeResourcesBalancedAllocation`: Favors nodes that would obtain a more + balanced resource usage if the Pod is scheduled there. + Extension points: `score`. +- `VolumeBinding`: Checks if the node has or if it can bind the requested + {{< glossary_tooltip text="volumes" term_id="volume" >}}. + Extension points: `preFilter`, `filter`, `reserve`, `preBind`, `score`. + {{< note >}} + `score` extension point is enabled when `VolumeCapacityPriority` feature is + enabled. It prioritizes the smallest PVs that can fit the requested volume + size. + {{< /note >}} +- `VolumeRestrictions`: Checks that volumes mounted in the node satisfy + restrictions that are specific to the volume provider. + Extension points: `filter`. +- `VolumeZone`: Checks that volumes requested satisfy any zone requirements they + might have. + Extension points: `filter`. +- `NodeVolumeLimits`: Checks that CSI volume limits can be satisfied for the + node. + Extension points: `filter`. +- `EBSLimits`: Checks that AWS EBS volume limits can be satisfied for the node. + Extension points: `filter`. +- `GCEPDLimits`: Checks that GCP-PD volume limits can be satisfied for the node. + Extension points: `filter`. +- `AzureDiskLimits`: Checks that Azure disk volume limits can be satisfied for + the node. + Extension points: `filter`. +- `InterPodAffinity`: Implements + [inter-Pod affinity and anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity). + Extension points: `preFilter`, `filter`, `preScore`, `score`. +- `PrioritySort`: Provides the default priority based sorting. + Extension points: `queueSort`. +- `DefaultBinder`: Provides the default binding mechanism. + Extension points: `bind`. +- `DefaultPreemption`: Provides the default preemption mechanism. + Extension points: `postFilter`. + +You can also enable the following plugins, through the component config APIs, +that are not enabled by default: + - `SelectorSpread`: Favors spreading across nodes for Pods that belong to {{< glossary_tooltip text="Services" term_id="service" >}}, {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}} and {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}. - Extension points: `PreScore`, `Score`. -- `ImageLocality`: Favors nodes that already have the container images that the - Pod runs. - Extension points: `Score`. -- `TaintToleration`: Implements - [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/). - Implements extension points: `Filter`, `Prescore`, `Score`. -- `NodeName`: Checks if a Pod spec node name matches the current node. - Extension points: `Filter`. -- `NodePorts`: Checks if a node has free ports for the requested Pod ports. - Extension points: `PreFilter`, `Filter`. -- `NodePreferAvoidPods`: Scores nodes according to the node - {{< glossary_tooltip text="annotation" term_id="annotation" >}} - `scheduler.alpha.kubernetes.io/preferAvoidPods`. - Extension points: `Score`. -- `NodeAffinity`: Implements - [node selectors](/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) - and [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity). - Extension points: `Filter`, `Score`. -- `PodTopologySpread`: Implements - [Pod topology spread](/docs/concepts/workloads/pods/pod-topology-spread-constraints/). - Extension points: `PreFilter`, `Filter`, `PreScore`, `Score`. -- `NodeUnschedulable`: Filters out nodes that have `.spec.unschedulable` set to - true. - Extension points: `Filter`. -- `NodeResourcesFit`: Checks if the node has all the resources that the Pod is - requesting. - Extension points: `PreFilter`, `Filter`. -- `NodeResourcesBalancedAllocation`: Favors nodes that would obtain a more - balanced resource usage if the Pod is scheduled there. - Extension points: `Score`. + Extension points: `preScore`, `score`. +- `CinderLimits`: Checks that [OpenStack Cinder](https://docs.openstack.org/cinder/) + volume limits can be satisfied for the node. + Extension points: `filter`. + +The following plugins are deprecated and can only be enabled in a `v1beta1` +configuration: + - `NodeResourcesLeastAllocated`: Favors nodes that have a low allocation of resources. - Extension points: `Score`. -- `VolumeBinding`: Checks if the node has or if it can bind the requested - {{< glossary_tooltip text="volumes" term_id="volume" >}}. - Extension points: `PreFilter`, `Filter`, `Reserve`, `PreBind`. -- `VolumeRestrictions`: Checks that volumes mounted in the node satisfy - restrictions that are specific to the volume provider. - Extension points: `Filter`. -- `VolumeZone`: Checks that volumes requested satisfy any zone requirements they - might have. - Extension points: `Filter`. -- `NodeVolumeLimits`: Checks that CSI volume limits can be satisfied for the - node. - Extension points: `Filter`. -- `EBSLimits`: Checks that AWS EBS volume limits can be satisfied for the node. - Extension points: `Filter`. -- `GCEPDLimits`: Checks that GCP-PD volume limits can be satisfied for the node. - Extension points: `Filter`. -- `AzureDiskLimits`: Checks that Azure disk volume limits can be satisfied for - the node. - Extension points: `Filter`. -- `InterPodAffinity`: Implements - [inter-Pod affinity and anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity). - Extension points: `PreFilter`, `Filter`, `PreScore`, `Score`. -- `PrioritySort`: Provides the default priority based sorting. - Extension points: `QueueSort`. -- `DefaultBinder`: Provides the default binding mechanism. - Extension points: `Bind`. -- `DefaultPreemption`: Provides the default preemption mechanism. - Extension points: `PostFilter`. - -You can also enable the following plugins, through the component config APIs, -that are not enabled by default: - + Extension points: `score`. - `NodeResourcesMostAllocated`: Favors nodes that have a high allocation of resources. - Extension points: `Score`. + Extension points: `score`. - `RequestedToCapacityRatio`: Favor nodes according to a configured function of the allocated resources. - Extension points: `Score`. -- `CinderVolume`: Checks that OpenStack Cinder volume limits can be satisfied - for the node. - Extension points: `Filter`. + Extension points: `score`. - `NodeLabel`: Filters and / or scores a node according to configured {{< glossary_tooltip text="label(s)" term_id="label" >}}. - Extension points: `Filter`, `Score`. + Extension points: `filter`, `score`. - `ServiceAffinity`: Checks that Pods that belong to a {{< glossary_tooltip term_id="service" >}} fit in a set of nodes defined by configured labels. This plugin also favors spreading the Pods belonging to a Service across nodes. - Extension points: `PreFilter`, `Filter`, `Score`. + Extension points: `preFilter`, `filter`, `score`. +- `NodePreferAvoidPods`: Prioritizes nodes according to the node annotation + `scheduler.alpha.kubernetes.io/preferAvoidPods`. + Extension points: `score`. ### Multiple profiles @@ -206,7 +218,7 @@ profiles: one with the default plugins and one with all scoring plugins disabled. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta2 kind: KubeSchedulerConfiguration profiles: - schedulerName: default-scheduler @@ -238,14 +250,15 @@ list. {{< /note >}} {{< note >}} -All profiles must use the same plugin in the QueueSort extension point and have +All profiles must use the same plugin in the `queueSort` extension point and have the same configuration parameters (if applicable). This is because the scheduler only has one pending pods queue. {{< /note >}} ## {{% heading "whatsnext" %}} -* Read the [kube-scheduler reference](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) +* Read the [kube-scheduler reference](/docs/reference/command-line-tools-reference/kube-scheduler/) * Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/) * Read the [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) reference +* Read the [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) reference diff --git a/content/en/docs/reference/scheduling/policies.md b/content/en/docs/reference/scheduling/policies.md index fc9a740266..99291c2b37 100644 --- a/content/en/docs/reference/scheduling/policies.md +++ b/content/en/docs/reference/scheduling/policies.md @@ -43,21 +43,6 @@ The following *predicates* implement filtering: - `MaxCSIVolumeCount`: Decides how many {{< glossary_tooltip text="CSI" term_id="csi" >}} volumes should be attached, and whether that's over a configured limit. -- `CheckNodeMemoryPressure`: If a Node is reporting memory pressure, and there's no - configured exception, the Pod won't be scheduled there. - -- `CheckNodePIDPressure`: If a Node is reporting that process IDs are scarce, and - there's no configured exception, the Pod won't be scheduled there. - -- `CheckNodeDiskPressure`: If a Node is reporting storage pressure (a filesystem that - is full or nearly full), and there's no configured exception, the Pod won't be - scheduled there. - -- `CheckNodeCondition`: Nodes can report that they have a completely full filesystem, - that networking isn't available or that kubelet is otherwise not ready to run Pods. - If such a condition is set for a Node, and there's no configured exception, the Pod - won't be scheduled there. - - `PodToleratesNodeTaints`: checks if a Pod's {{< glossary_tooltip text="tolerations" term_id="toleration" >}} can tolerate the Node's {{< glossary_tooltip text="taints" term_id="taint" >}}. @@ -119,6 +104,6 @@ The following *priorities* implement scoring: * Learn about [scheduling](/docs/concepts/scheduling-eviction/kube-scheduler/) * Learn about [kube-scheduler Configuration](/docs/reference/scheduling/config/) -* Read the [kube-scheduler configuration reference (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1) +* Read the [kube-scheduler configuration reference (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2) * Read the [kube-scheduler Policy reference (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) diff --git a/content/en/docs/reference/setup-tools/kubeadm/_index.md b/content/en/docs/reference/setup-tools/kubeadm/_index.md old mode 100755 new mode 100644 index d747c05124..00120e3d9d --- a/content/en/docs/reference/setup-tools/kubeadm/_index.md +++ b/content/en/docs/reference/setup-tools/kubeadm/_index.md @@ -8,7 +8,7 @@ card: weight: 40 --- -Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice "fast paths" for creating Kubernetes clusters. +Kubeadm is a tool built to provide `kubeadm init` and `kubeadm join` as best-practice "fast paths" for creating Kubernetes clusters. kubeadm performs the actions necessary to get a minimum viable cluster up and running. By design, it cares only about bootstrapping, not about provisioning machines. Likewise, installing various nice-to-have addons, like the Kubernetes Dashboard, monitoring solutions, and cloud-specific addons, is not in scope. @@ -26,5 +26,7 @@ To install kubeadm, see the [installation guide](/docs/setup/production-environm * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config) if you initialized your cluster using kubeadm v1.7.x or lower, to configure your cluster for `kubeadm upgrade` * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token) to manage tokens for `kubeadm join` * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset) to revert any changes made to this host by `kubeadm init` or `kubeadm join` +* [kubeadm certs](/docs/reference/setup-tools/kubeadm/kubeadm-certs) to manage Kubernetes certificates +* [kubeadm kubeconfig](/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig) to manage kubeconfig files * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version) to print the kubeadm version * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha) to preview a set of features made available for gathering feedback from the community diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm.md index ed03bf49c4..ff545b4042 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm.md @@ -1,3 +1,16 @@ + + + +kubeadm: easily bootstrap a secure Kubernetes cluster ### Synopsis @@ -47,14 +60,14 @@ Example usage: -h, --help -help for kubeadm +

help for kubeadm

--rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha.md deleted file mode 100644 index 95b034be1b..0000000000 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha.md +++ /dev/null @@ -1,48 +0,0 @@ - -### Synopsis - - -Kubeadm experimental sub-commands - -### Options - - ---- - - - - - - - - - - -
-h, --help
help for alpha
- - - -### Options inherited from parent commands - - ---- - - - - - - - - - - -
--rootfs string
[EXPERIMENTAL] The path to the 'real' host root filesystem.
- - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig.md deleted file mode 100644 index 67f30bc3f8..0000000000 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig.md +++ /dev/null @@ -1,50 +0,0 @@ - -### Synopsis - - -Kubeconfig file utilities. - -Alpha Disclaimer: this command is currently alpha. - -### Options - - ---- - - - - - - - - - - -
-h, --help
help for kubeconfig
- - - -### Options inherited from parent commands - - ---- - - - - - - - - - - -
--rootfs string
[EXPERIMENTAL] The path to the 'real' host root filesystem.
- - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig_user.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig_user.md deleted file mode 100644 index bdb246232f..0000000000 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubeconfig_user.md +++ /dev/null @@ -1,89 +0,0 @@ - -### Synopsis - - -Output a kubeconfig file for an additional user. - -Alpha Disclaimer: this command is currently alpha. - -``` -kubeadm alpha kubeconfig user [flags] -``` - -### Examples - -``` - # Output a kubeconfig file for an additional user named foo using a kubeadm config file bar - kubeadm alpha kubeconfig user --client-name=foo --config=bar -``` - -### Options - - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
--client-name string
The name of user. It will be used as the CN if client certificates are created
--config string
Path to a kubeadm configuration file.
-h, --help
help for user
--org stringSlice
The orgnizations of the client certificate. It will be used as the O if client certificates are created
--token string
The token that should be used as the authentication mechanism for this kubeconfig, instead of client certificates
- - - -### Options inherited from parent commands - - ---- - - - - - - - - - - -
--rootfs string
[EXPERIMENTAL] The path to the 'real' host root filesystem.
- - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet.md deleted file mode 100644 index 055c8ecac5..0000000000 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet.md +++ /dev/null @@ -1,48 +0,0 @@ - -### Synopsis - - -This command is not meant to be run on its own. See list of available subcommands. - -### Options - - ---- - - - - - - - - - - -
-h, --help
help for kubelet
- - - -### Options inherited from parent commands - - ---- - - - - - - - - - - -
--rootfs string
[EXPERIMENTAL] The path to the 'real' host root filesystem.
- - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config.md deleted file mode 100644 index 563d9fe227..0000000000 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config.md +++ /dev/null @@ -1,48 +0,0 @@ - -### Synopsis - - -This command is not meant to be run on its own. See list of available subcommands. - -### Options - - ---- - - - - - - - - - - -
-h, --help
help for config
- - - -### Options inherited from parent commands - - ---- - - - - - - - - - - -
--rootfs string
[EXPERIMENTAL] The path to the 'real' host root filesystem.
- - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_enable-dynamic.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_enable-dynamic.md deleted file mode 100644 index 278def1dd3..0000000000 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_kubelet_config_enable-dynamic.md +++ /dev/null @@ -1,87 +0,0 @@ - -### Synopsis - - -Enable or update dynamic kubelet configuration for a Node, against the kubelet-config-1.X ConfigMap in the cluster, where X is the minor version of the desired kubelet version. - -WARNING: This feature is still experimental, and disabled by default. Enable only if you know what you are doing, as it may have surprising side-effects at this stage. - -Alpha Disclaimer: this command is currently alpha. - -``` -kubeadm alpha kubelet config enable-dynamic [flags] -``` - -### Examples - -``` - # Enable dynamic kubelet configuration for a Node. - kubeadm alpha phase kubelet enable-dynamic-config --node-name node-1 --kubelet-version 1.18.0 - - WARNING: This feature is still experimental, and disabled by default. Enable only if you know what you are doing, as it - may have surprising side-effects at this stage. -``` - -### Options - - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-h, --help
help for enable-dynamic
--kubeconfig string     Default: "/etc/kubernetes/admin.conf"
The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.
--kubelet-version string
The desired version for the kubelet
--node-name string
Name of the node that should enable the dynamic kubelet configuration
- - - -### Options inherited from parent commands - - ---- - - - - - - - - - - -
--rootfs string
[EXPERIMENTAL] The path to the 'real' host root filesystem.
- - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting.md deleted file mode 100644 index 77646b064b..0000000000 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting.md +++ /dev/null @@ -1,48 +0,0 @@ - -### Synopsis - - -This command is not meant to be run on its own. See list of available subcommands. - -### Options - - ---- - - - - - - - - - - -
-h, --help
help for selfhosting
- - - -### Options inherited from parent commands - - ---- - - - - - - - - - - -
--rootfs string
[EXPERIMENTAL] The path to the 'real' host root filesystem.
- - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting_pivot.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting_pivot.md deleted file mode 100644 index 554b8fe4c6..0000000000 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_alpha_selfhosting_pivot.md +++ /dev/null @@ -1,99 +0,0 @@ - -### Synopsis - - -Convert static Pod files for control plane components into self-hosted DaemonSets configured via the Kubernetes API. - -See the documentation for self-hosting limitations. - -Alpha Disclaimer: this command is currently alpha. - -``` -kubeadm alpha selfhosting pivot [flags] -``` - -### Examples - -``` - # Convert a static Pod-hosted control plane into a self-hosted one. - - kubeadm alpha phase self-hosting convert-from-staticpods -``` - -### Options - - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
--cert-dir string     Default: "/etc/kubernetes/pki"
The path where certificates are stored
--config string
Path to a kubeadm configuration file.
-f, --force
Pivot the cluster without prompting for confirmation
-h, --help
help for pivot
--kubeconfig string     Default: "/etc/kubernetes/admin.conf"
The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.
-s, --store-certs-in-secrets
Enable storing certs in secrets
- - - -### Options inherited from parent commands - - ---- - - - - - - - - - - -
--rootfs string
[EXPERIMENTAL] The path to the 'real' host root filesystem.
- - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs.md index fef772e702..9458702330 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs.md @@ -1,3 +1,16 @@ + + + +Commands related to handling kubernetes certificates ### Synopsis @@ -17,7 +30,7 @@ Commands related to handling kubernetes certificates -h, --help -help for certs +

help for certs

@@ -38,7 +51,7 @@ Commands related to handling kubernetes certificates --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_certificate-key.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_certificate-key.md index 2de0366641..3f978e50fd 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_certificate-key.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_certificate-key.md @@ -1,3 +1,16 @@ + + + +Generate certificate keys ### Synopsis @@ -27,7 +40,7 @@ kubeadm certs certificate-key [flags] -h, --help -help for certificate-key +

help for certificate-key

@@ -48,7 +61,7 @@ kubeadm certs certificate-key [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_check-expiration.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_check-expiration.md index 50a3cb8bf2..e321a5a029 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_check-expiration.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_check-expiration.md @@ -1,3 +1,16 @@ + + + +Check certificates expiration for a Kubernetes cluster ### Synopsis @@ -21,28 +34,28 @@ kubeadm certs check-expiration [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save the certificates +

The path where to save the certificates

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for check-expiration +

help for check-expiration

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -63,7 +76,7 @@ kubeadm certs check-expiration [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_generate-csr.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_generate-csr.md index 81b248e4f0..1abc7d9bac 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_generate-csr.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_generate-csr.md @@ -1,3 +1,16 @@ + + + +Generate keys and certificate signing requests ### Synopsis @@ -16,7 +29,7 @@ kubeadm certs generate-csr [flags] ``` # The following command will generate keys and CSRs for all control-plane certificates and kubeconfig files: - kubeadm alpha certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki + kubeadm certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki ``` ### Options @@ -32,28 +45,28 @@ kubeadm certs generate-csr [flags] --cert-dir string -The path where to save the certificates +

The path where to save the certificates

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for generate-csr +

help for generate-csr

--kubeconfig-dir string     Default: "/etc/kubernetes" -The path where to save the kubeconfig file. +

The path where to save the kubeconfig file.

@@ -74,7 +87,7 @@ kubeadm certs generate-csr [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew.md index 8b627a595d..e728f9f060 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew.md @@ -1,3 +1,16 @@ + + + +Renew certificates for a Kubernetes cluster ### Synopsis @@ -21,7 +34,7 @@ kubeadm certs renew [flags] -h, --help -help for renew +

help for renew

@@ -42,7 +55,7 @@ kubeadm certs renew [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_admin.conf.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_admin.conf.md index 536164c45a..31192cf3f7 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_admin.conf.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_admin.conf.md @@ -1,3 +1,16 @@ + + + +Renew the certificate embedded in the kubeconfig file for the admin to use and for kubeadm itself ### Synopsis @@ -27,42 +40,28 @@ kubeadm certs renew admin.conf [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save the certificates +

The path where to save the certificates

--config string -Path to a kubeadm configuration file. - - - ---csr-dir string - - -The path to output the CSRs and private keys to - - - ---csr-only - - -Create CSRs instead of generating certificates +

Path to a kubeadm configuration file.

-h, --help -help for admin.conf +

help for admin.conf

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -83,7 +82,7 @@ kubeadm certs renew admin.conf [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_all.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_all.md index 13c12ed0d0..77ea6e45a1 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_all.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_all.md @@ -1,3 +1,16 @@ + + + +Renew all available certificates ### Synopsis @@ -21,42 +34,28 @@ kubeadm certs renew all [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save the certificates +

The path where to save the certificates

--config string -Path to a kubeadm configuration file. - - - ---csr-dir string - - -The path to output the CSRs and private keys to - - - ---csr-only - - -Create CSRs instead of generating certificates +

Path to a kubeadm configuration file.

-h, --help -help for all +

help for all

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -77,7 +76,7 @@ kubeadm certs renew all [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_apiserver-etcd-client.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_apiserver-etcd-client.md index fac6861a7c..f95a51e1a7 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_apiserver-etcd-client.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_apiserver-etcd-client.md @@ -1,3 +1,16 @@ + + + +Renew the certificate the apiserver uses to access etcd ### Synopsis @@ -27,42 +40,28 @@ kubeadm certs renew apiserver-etcd-client [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save the certificates +

The path where to save the certificates

--config string -Path to a kubeadm configuration file. - - - ---csr-dir string - - -The path to output the CSRs and private keys to - - - ---csr-only - - -Create CSRs instead of generating certificates +

Path to a kubeadm configuration file.

-h, --help -help for apiserver-etcd-client +

help for apiserver-etcd-client

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -83,7 +82,7 @@ kubeadm certs renew apiserver-etcd-client [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_apiserver-kubelet-client.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_apiserver-kubelet-client.md index 030fb1425a..27ba374b9f 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_apiserver-kubelet-client.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_apiserver-kubelet-client.md @@ -1,3 +1,16 @@ + + + +Renew the certificate for the API server to connect to kubelet ### Synopsis @@ -27,42 +40,28 @@ kubeadm certs renew apiserver-kubelet-client [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save the certificates +

The path where to save the certificates

--config string -Path to a kubeadm configuration file. - - - ---csr-dir string - - -The path to output the CSRs and private keys to - - - ---csr-only - - -Create CSRs instead of generating certificates +

Path to a kubeadm configuration file.

-h, --help -help for apiserver-kubelet-client +

help for apiserver-kubelet-client

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -83,7 +82,7 @@ kubeadm certs renew apiserver-kubelet-client [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_apiserver.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_apiserver.md index 8ab01efd89..7dc59c45d4 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_apiserver.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_apiserver.md @@ -1,3 +1,16 @@ + + + +Renew the certificate for serving the Kubernetes API ### Synopsis @@ -27,42 +40,28 @@ kubeadm certs renew apiserver [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save the certificates +

The path where to save the certificates

--config string -Path to a kubeadm configuration file. - - - ---csr-dir string - - -The path to output the CSRs and private keys to - - - ---csr-only - - -Create CSRs instead of generating certificates +

Path to a kubeadm configuration file.

-h, --help -help for apiserver +

help for apiserver

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -83,7 +82,7 @@ kubeadm certs renew apiserver [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_controller-manager.conf.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_controller-manager.conf.md index 10b44f7c3e..4df1d8221c 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_controller-manager.conf.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_controller-manager.conf.md @@ -1,3 +1,16 @@ + + + +Renew the certificate embedded in the kubeconfig file for the controller manager to use ### Synopsis @@ -27,42 +40,28 @@ kubeadm certs renew controller-manager.conf [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save the certificates +

The path where to save the certificates

--config string -Path to a kubeadm configuration file. - - - ---csr-dir string - - -The path to output the CSRs and private keys to - - - ---csr-only - - -Create CSRs instead of generating certificates +

Path to a kubeadm configuration file.

-h, --help -help for controller-manager.conf +

help for controller-manager.conf

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -83,7 +82,7 @@ kubeadm certs renew controller-manager.conf [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_etcd-healthcheck-client.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_etcd-healthcheck-client.md index b9ddadd6f1..84d75bfd36 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_etcd-healthcheck-client.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_etcd-healthcheck-client.md @@ -1,3 +1,16 @@ + + + +Renew the certificate for liveness probes to healthcheck etcd ### Synopsis @@ -27,42 +40,28 @@ kubeadm certs renew etcd-healthcheck-client [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save the certificates +

The path where to save the certificates

--config string -Path to a kubeadm configuration file. - - - ---csr-dir string - - -The path to output the CSRs and private keys to - - - ---csr-only - - -Create CSRs instead of generating certificates +

Path to a kubeadm configuration file.

-h, --help -help for etcd-healthcheck-client +

help for etcd-healthcheck-client

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -83,7 +82,7 @@ kubeadm certs renew etcd-healthcheck-client [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_etcd-peer.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_etcd-peer.md index 3b15fa02f0..60acaae1db 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_etcd-peer.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_etcd-peer.md @@ -1,3 +1,16 @@ + + + +Renew the certificate for etcd nodes to communicate with each other ### Synopsis @@ -27,42 +40,28 @@ kubeadm certs renew etcd-peer [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save the certificates +

The path where to save the certificates

--config string -Path to a kubeadm configuration file. - - - ---csr-dir string - - -The path to output the CSRs and private keys to - - - ---csr-only - - -Create CSRs instead of generating certificates +

Path to a kubeadm configuration file.

-h, --help -help for etcd-peer +

help for etcd-peer

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -83,7 +82,7 @@ kubeadm certs renew etcd-peer [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_etcd-server.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_etcd-server.md index 82b9e43e34..969157fe3e 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_etcd-server.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_etcd-server.md @@ -1,3 +1,16 @@ + + + +Renew the certificate for serving etcd ### Synopsis @@ -27,42 +40,28 @@ kubeadm certs renew etcd-server [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save the certificates +

The path where to save the certificates

--config string -Path to a kubeadm configuration file. - - - ---csr-dir string - - -The path to output the CSRs and private keys to - - - ---csr-only - - -Create CSRs instead of generating certificates +

Path to a kubeadm configuration file.

-h, --help -help for etcd-server +

help for etcd-server

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -83,7 +82,7 @@ kubeadm certs renew etcd-server [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_front-proxy-client.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_front-proxy-client.md index b1f3bc0c84..3d9564e485 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_front-proxy-client.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_front-proxy-client.md @@ -1,3 +1,16 @@ + + + +Renew the certificate for the front proxy client ### Synopsis @@ -27,42 +40,28 @@ kubeadm certs renew front-proxy-client [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save the certificates +

The path where to save the certificates

--config string -Path to a kubeadm configuration file. - - - ---csr-dir string - - -The path to output the CSRs and private keys to - - - ---csr-only - - -Create CSRs instead of generating certificates +

Path to a kubeadm configuration file.

-h, --help -help for front-proxy-client +

help for front-proxy-client

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -83,7 +82,7 @@ kubeadm certs renew front-proxy-client [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_scheduler.conf.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_scheduler.conf.md index f26fbc22b1..6c8d40dae3 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_scheduler.conf.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_renew_scheduler.conf.md @@ -1,3 +1,16 @@ + + + +Renew the certificate embedded in the kubeconfig file for the scheduler manager to use ### Synopsis @@ -27,42 +40,28 @@ kubeadm certs renew scheduler.conf [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save the certificates +

The path where to save the certificates

--config string -Path to a kubeadm configuration file. - - - ---csr-dir string - - -The path to output the CSRs and private keys to - - - ---csr-only - - -Create CSRs instead of generating certificates +

Path to a kubeadm configuration file.

-h, --help -help for scheduler.conf +

help for scheduler.conf

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -83,7 +82,7 @@ kubeadm certs renew scheduler.conf [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_completion.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_completion.md index f5a69d79fd..5fe7d65b40 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_completion.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_completion.md @@ -1,3 +1,16 @@ + + + +Output shell completion code for the specified shell (bash or zsh) ### Synopsis @@ -59,7 +72,7 @@ source <(kubeadm completion zsh) -h, --help -help for completion +

help for completion

@@ -80,7 +93,7 @@ source <(kubeadm completion zsh) --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config.md index b39cdd7a0d..50cb9f63b9 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config.md @@ -1,3 +1,16 @@ + + + +Manage configuration for a kubeadm cluster persisted in a ConfigMap in the cluster ### Synopsis @@ -26,14 +39,14 @@ kubeadm config [flags] -h, --help -help for config +

help for config

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -54,7 +67,7 @@ kubeadm config [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images.md index 436f3c3c7e..0f85b4fbc2 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images.md @@ -1,3 +1,16 @@ + + + +Interact with container images used by kubeadm ### Synopsis @@ -21,7 +34,7 @@ kubeadm config images [flags] -h, --help -help for images +

help for images

@@ -42,14 +55,14 @@ kubeadm config images [flags] --kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_list.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_list.md index 842fb2fe92..b7f3e05a8b 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_list.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_list.md @@ -1,3 +1,16 @@ + + + +Print a list of images kubeadm will use. The configuration file is used in case any images or image repositories are customized ### Synopsis @@ -21,49 +34,56 @@ kubeadm config images list [flags] --allow-missing-template-keys     Default: true -If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. +

If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-o, --experimental-output string     Default: "text" -Output format. One of: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file. +

Output format. One of: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

--feature-gates string -A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (ALPHA - default=false)
PublicKeysECDSA=true|false (ALPHA - default=false) +

A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (BETA - default=true)
PublicKeysECDSA=true|false (ALPHA - default=false)
RootlessControlPlane=true|false (ALPHA - default=false)

-h, --help -help for list +

help for list

--image-repository string     Default: "k8s.gcr.io" -Choose a container registry to pull control plane images from +

Choose a container registry to pull control plane images from

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

+ + + +--show-managed-fields + + +

If true, keep the managedFields when printing objects in JSON or YAML format.

@@ -84,14 +104,14 @@ kubeadm config images list [flags] --kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_pull.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_pull.md index d2f5961f85..a44970a68a 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_pull.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_images_pull.md @@ -1,3 +1,16 @@ + + + +Pull images used by kubeadm ### Synopsis @@ -21,42 +34,42 @@ kubeadm config images pull [flags] --config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--cri-socket string -Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket. +

Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket.

--feature-gates string -A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (ALPHA - default=false)
PublicKeysECDSA=true|false (ALPHA - default=false) +

A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (BETA - default=true)
PublicKeysECDSA=true|false (ALPHA - default=false)
RootlessControlPlane=true|false (ALPHA - default=false)

-h, --help -help for pull +

help for pull

--image-repository string     Default: "k8s.gcr.io" -Choose a container registry to pull control plane images from +

Choose a container registry to pull control plane images from

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

@@ -77,14 +90,14 @@ kubeadm config images pull [flags] --kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_migrate.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_migrate.md index d07ffe8677..8aa2f6f1d2 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_migrate.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_migrate.md @@ -1,3 +1,16 @@ + + + +Read an older version of the kubeadm configuration API types from a file, and output the similar config object for the newer version ### Synopsis @@ -6,9 +19,9 @@ This command lets you convert configuration objects of older versions to the latest supported version, locally in the CLI tool without ever touching anything in the cluster. In this version of kubeadm, the following API versions are supported: -- kubeadm.k8s.io/v1beta2 +- kubeadm.k8s.io/v1beta3 -Further, kubeadm can only write out config of version "kubeadm.k8s.io/v1beta2", but read both types. +Further, kubeadm can only write out config of version "kubeadm.k8s.io/v1beta3", but read both types. So regardless of what version you pass to the --old-config parameter here, the API object will be read, deserialized, defaulted, converted, validated, and re-serialized when written to stdout or --new-config if specified. @@ -34,21 +47,21 @@ kubeadm config migrate [flags] -h, --help -help for migrate +

help for migrate

--new-config string -Path to the resulting equivalent kubeadm config file using the new API version. Optional, if not specified output will be sent to STDOUT. +

Path to the resulting equivalent kubeadm config file using the new API version. Optional, if not specified output will be sent to STDOUT.

--old-config string -Path to the kubeadm config file that is using an old API version and should be converted. This flag is mandatory. +

Path to the kubeadm config file that is using an old API version and should be converted. This flag is mandatory.

@@ -69,14 +82,14 @@ kubeadm config migrate [flags] --kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print.md index c6e1ea2173..e8aa81abf6 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print.md @@ -1,10 +1,23 @@ + + + +Print configuration ### Synopsis This command prints configurations for subcommands provided. -For details, see: https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2 +For details, see: https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories ``` kubeadm config print [flags] @@ -23,7 +36,7 @@ kubeadm config print [flags] -h, --help -help for print +

help for print

@@ -44,14 +57,14 @@ kubeadm config print [flags] --kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print_init-defaults.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print_init-defaults.md index adc76ee41c..f8200dfd52 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print_init-defaults.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print_init-defaults.md @@ -1,3 +1,16 @@ + + + +Print default init configuration, that can be used for 'kubeadm init' ### Synopsis @@ -5,7 +18,7 @@ This command prints objects such as the default init configuration that is used for 'kubeadm init'. -Note that sensitive values like the Bootstrap Token fields are replaced with placeholder values like {"abcdef.0123456789abcdef" "" "nil" <nil> [] []} in order to pass validation but +Note that sensitive values like the Bootstrap Token fields are replaced with placeholder values like "abcdef.0123456789abcdef" in order to pass validation but not perform the real computation for creating a token. @@ -23,17 +36,17 @@ kubeadm config print init-defaults [flags] ---component-configs stringSlice +--component-configs strings -A comma-separated list for component config API objects to print the default values for. Available values: [KubeProxyConfiguration KubeletConfiguration]. If this flag is not set, no component configs will be printed. +

A comma-separated list for component config API objects to print the default values for. Available values: [KubeProxyConfiguration KubeletConfiguration]. If this flag is not set, no component configs will be printed.

-h, --help -help for init-defaults +

help for init-defaults

@@ -54,14 +67,14 @@ kubeadm config print init-defaults [flags] --kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print_join-defaults.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print_join-defaults.md index b1c976c663..1c634871eb 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print_join-defaults.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_print_join-defaults.md @@ -1,3 +1,16 @@ + + + +Print default join configuration, that can be used for 'kubeadm join' ### Synopsis @@ -5,7 +18,7 @@ This command prints objects such as the default join configuration that is used for 'kubeadm join'. -Note that sensitive values like the Bootstrap Token fields are replaced with placeholder values like {"abcdef.0123456789abcdef" "" "nil" <nil> [] []} in order to pass validation but +Note that sensitive values like the Bootstrap Token fields are replaced with placeholder values like "abcdef.0123456789abcdef" in order to pass validation but not perform the real computation for creating a token. @@ -23,17 +36,17 @@ kubeadm config print join-defaults [flags] ---component-configs stringSlice +--component-configs strings -A comma-separated list for component config API objects to print the default values for. Available values: [KubeProxyConfiguration KubeletConfiguration]. If this flag is not set, no component configs will be printed. +

A comma-separated list for component config API objects to print the default values for. Available values: [KubeProxyConfiguration KubeletConfiguration]. If this flag is not set, no component configs will be printed.

-h, --help -help for join-defaults +

help for join-defaults

@@ -54,14 +67,14 @@ kubeadm config print join-defaults [flags] --kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_view.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_view.md deleted file mode 100644 index c3a3137105..0000000000 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_config_view.md +++ /dev/null @@ -1,63 +0,0 @@ - -### Synopsis - - - -Using this command, you can view the ConfigMap in the cluster where the configuration for kubeadm is located. - -The configuration is located in the "kube-system" namespace in the "kubeadm-config" ConfigMap. - - -``` -kubeadm config view [flags] -``` - -### Options - - ---- - - - - - - - - - - -
-h, --help
help for view
- - - -### Options inherited from parent commands - - ---- - - - - - - - - - - - - - - - - - -
--kubeconfig string     Default: "/etc/kubernetes/admin.conf"
The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.
--rootfs string
[EXPERIMENTAL] The path to the 'real' host root filesystem.
- - - diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md index 49c7fd112a..62f4ca7e5b 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init.md @@ -1,3 +1,16 @@ + + + +Run this command in order to set up the Kubernetes control plane ### Synopsis @@ -39,7 +52,7 @@ mark-control-plane Mark a node as a control-plane bootstrap-token Generates bootstrap tokens used to join a node to a cluster kubelet-finalize Updates settings relevant to the kubelet after TLS bootstrap /experimental-cert-rotation Enable kubelet client certificate rotation -addon Install required addons for passing Conformance tests +addon Install required addons for passing conformance tests /coredns Install the CoreDNS addon to a Kubernetes cluster /kube-proxy Install the kube-proxy addon to a Kubernetes cluster ``` @@ -62,175 +75,175 @@ kubeadm init [flags] --apiserver-advertise-address string -The IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

The IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--apiserver-bind-port int32     Default: 6443 -Port for the API Server to bind to. +

Port for the API Server to bind to.

---apiserver-cert-extra-sans stringSlice +--apiserver-cert-extra-sans strings -Optional extra Subject Alternative Names (SANs) to use for the API Server serving certificate. Can be both IP addresses and DNS names. +

Optional extra Subject Alternative Names (SANs) to use for the API Server serving certificate. Can be both IP addresses and DNS names.

--cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--certificate-key string -Key used to encrypt the control-plane certificates in the kubeadm-certs Secret. +

Key used to encrypt the control-plane certificates in the kubeadm-certs Secret.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--control-plane-endpoint string -Specify a stable IP address or DNS name for the control plane. +

Specify a stable IP address or DNS name for the control plane.

--cri-socket string -Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket. +

Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket.

--dry-run -Don't apply any changes; just output what would be done. - - - ---experimental-patches string - - -Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically. +

Don't apply any changes; just output what would be done.

--feature-gates string -A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (ALPHA - default=false)
PublicKeysECDSA=true|false (ALPHA - default=false) +

A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (BETA - default=true)
PublicKeysECDSA=true|false (ALPHA - default=false)
RootlessControlPlane=true|false (ALPHA - default=false)

-h, --help -help for init +

help for init

---ignore-preflight-errors stringSlice +--ignore-preflight-errors strings -A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks. +

A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.

--image-repository string     Default: "k8s.gcr.io" -Choose a container registry to pull control plane images from +

Choose a container registry to pull control plane images from

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

--node-name string -Specify the node name. +

Specify the node name.

+ + + +--patches string + + +

Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "target" can be one of "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically.

--pod-network-cidr string -Specify range of IP addresses for the pod network. If set, the control plane will automatically allocate CIDRs for every node. +

Specify range of IP addresses for the pod network. If set, the control plane will automatically allocate CIDRs for every node.

--service-cidr string     Default: "10.96.0.0/12" -Use alternative range of IP address for service VIPs. +

Use alternative range of IP address for service VIPs.

--service-dns-domain string     Default: "cluster.local" -Use alternative domain for services, e.g. "myorg.internal". +

Use alternative domain for services, e.g. "myorg.internal".

--skip-certificate-key-print -Don't print the key used to encrypt the control-plane certificates. +

Don't print the key used to encrypt the control-plane certificates.

---skip-phases stringSlice +--skip-phases strings -List of phases to be skipped +

List of phases to be skipped

--skip-token-print -Skip printing of the default bootstrap token generated by 'kubeadm init'. +

Skip printing of the default bootstrap token generated by 'kubeadm init'.

--token string -The token to use for establishing bidirectional trust between nodes and control-plane nodes. The format is [a-z0-9]{6}\.[a-z0-9]{16} - e.g. abcdef.0123456789abcdef +

The token to use for establishing bidirectional trust between nodes and control-plane nodes. The format is [a-z0-9]{6}.[a-z0-9]{16} - e.g. abcdef.0123456789abcdef

--token-ttl duration     Default: 24h0m0s -The duration before the token is automatically deleted (e.g. 1s, 2m, 3h). If set to '0', the token will never expire +

The duration before the token is automatically deleted (e.g. 1s, 2m, 3h). If set to '0', the token will never expire

--upload-certs -Upload control-plane certificates to the kubeadm-certs Secret. +

Upload control-plane certificates to the kubeadm-certs Secret.

@@ -251,7 +264,7 @@ kubeadm init [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase.md index 2db3ea5e54..48ccd99cd5 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase.md @@ -1,3 +1,16 @@ + + + +Use this command to invoke single phase of the init workflow ### Synopsis @@ -17,7 +30,7 @@ Use this command to invoke single phase of the init workflow -h, --help -help for phase +

help for phase

@@ -38,7 +51,7 @@ Use this command to invoke single phase of the init workflow --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon.md index 67b9c3af75..64777661d0 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon.md @@ -1,3 +1,16 @@ + + + +Install required addons for passing conformance tests ### Synopsis @@ -21,7 +34,7 @@ kubeadm init phase addon [flags] -h, --help -help for addon +

help for addon

@@ -42,7 +55,7 @@ kubeadm init phase addon [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_all.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_all.md index 103dd7e7c5..c30d45980c 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_all.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_all.md @@ -1,3 +1,16 @@ + + + +Install all the addons ### Synopsis @@ -21,84 +34,84 @@ kubeadm init phase addon all [flags] --apiserver-advertise-address string -The IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

The IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--apiserver-bind-port int32     Default: 6443 -Port for the API Server to bind to. +

Port for the API Server to bind to.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--control-plane-endpoint string -Specify a stable IP address or DNS name for the control plane. +

Specify a stable IP address or DNS name for the control plane.

--feature-gates string -A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (ALPHA - default=false)
PublicKeysECDSA=true|false (ALPHA - default=false) +

A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (BETA - default=true)
PublicKeysECDSA=true|false (ALPHA - default=false)
RootlessControlPlane=true|false (ALPHA - default=false)

-h, --help -help for all +

help for all

--image-repository string     Default: "k8s.gcr.io" -Choose a container registry to pull control plane images from +

Choose a container registry to pull control plane images from

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

--pod-network-cidr string -Specify range of IP addresses for the pod network. If set, the control plane will automatically allocate CIDRs for every node. +

Specify range of IP addresses for the pod network. If set, the control plane will automatically allocate CIDRs for every node.

--service-cidr string     Default: "10.96.0.0/12" -Use alternative range of IP address for service VIPs. +

Use alternative range of IP address for service VIPs.

--service-dns-domain string     Default: "cluster.local" -Use alternative domain for services, e.g. "myorg.internal". +

Use alternative domain for services, e.g. "myorg.internal".

@@ -119,7 +132,7 @@ kubeadm init phase addon all [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_coredns.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_coredns.md index 3eebcb828b..3e4076a862 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_coredns.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_coredns.md @@ -1,3 +1,16 @@ + + + +Install the CoreDNS addon to a Kubernetes cluster ### Synopsis @@ -21,56 +34,56 @@ kubeadm init phase addon coredns [flags] --config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--feature-gates string -A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (ALPHA - default=false)
PublicKeysECDSA=true|false (ALPHA - default=false) +

A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (BETA - default=true)
PublicKeysECDSA=true|false (ALPHA - default=false)
RootlessControlPlane=true|false (ALPHA - default=false)

-h, --help -help for coredns +

help for coredns

--image-repository string     Default: "k8s.gcr.io" -Choose a container registry to pull control plane images from +

Choose a container registry to pull control plane images from

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

--service-cidr string     Default: "10.96.0.0/12" -Use alternative range of IP address for service VIPs. +

Use alternative range of IP address for service VIPs.

--service-dns-domain string     Default: "cluster.local" -Use alternative domain for services, e.g. "myorg.internal". +

Use alternative domain for services, e.g. "myorg.internal".

@@ -91,7 +104,7 @@ kubeadm init phase addon coredns [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_kube-proxy.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_kube-proxy.md index 78140e94e8..4dc9a18339 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_kube-proxy.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_addon_kube-proxy.md @@ -1,3 +1,16 @@ + + + +Install the kube-proxy addon to a Kubernetes cluster ### Synopsis @@ -21,63 +34,63 @@ kubeadm init phase addon kube-proxy [flags] --apiserver-advertise-address string -The IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

The IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--apiserver-bind-port int32     Default: 6443 -Port for the API Server to bind to. +

Port for the API Server to bind to.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--control-plane-endpoint string -Specify a stable IP address or DNS name for the control plane. +

Specify a stable IP address or DNS name for the control plane.

-h, --help -help for kube-proxy +

help for kube-proxy

--image-repository string     Default: "k8s.gcr.io" -Choose a container registry to pull control plane images from +

Choose a container registry to pull control plane images from

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

--pod-network-cidr string -Specify range of IP addresses for the pod network. If set, the control plane will automatically allocate CIDRs for every node. +

Specify range of IP addresses for the pod network. If set, the control plane will automatically allocate CIDRs for every node.

@@ -98,7 +111,7 @@ kubeadm init phase addon kube-proxy [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_bootstrap-token.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_bootstrap-token.md index 123ab38fdc..652399d5cf 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_bootstrap-token.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_bootstrap-token.md @@ -1,3 +1,16 @@ + + + +Generates bootstrap tokens used to join a node to a cluster ### Synopsis @@ -31,28 +44,28 @@ kubeadm init phase bootstrap-token [flags] --config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for bootstrap-token +

help for bootstrap-token

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--skip-token-print -Skip printing of the default bootstrap token generated by 'kubeadm init'. +

Skip printing of the default bootstrap token generated by 'kubeadm init'.

@@ -73,7 +86,7 @@ kubeadm init phase bootstrap-token [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs.md index 28f5acc3e3..c779b920e1 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs.md @@ -1,3 +1,16 @@ + + + +Certificate generation ### Synopsis @@ -21,7 +34,7 @@ kubeadm init phase certs [flags] -h, --help -help for certs +

help for certs

@@ -42,7 +55,7 @@ kubeadm init phase certs [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_all.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_all.md index 7ac391c078..7485310462 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_all.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_all.md @@ -1,3 +1,16 @@ + + + +Generate all certificates ### Synopsis @@ -21,63 +34,63 @@ kubeadm init phase certs all [flags] --apiserver-advertise-address string -The IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

The IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

---apiserver-cert-extra-sans stringSlice +--apiserver-cert-extra-sans strings -Optional extra Subject Alternative Names (SANs) to use for the API Server serving certificate. Can be both IP addresses and DNS names. +

Optional extra Subject Alternative Names (SANs) to use for the API Server serving certificate. Can be both IP addresses and DNS names.

--cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--control-plane-endpoint string -Specify a stable IP address or DNS name for the control plane. +

Specify a stable IP address or DNS name for the control plane.

-h, --help -help for all +

help for all

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

--service-cidr string     Default: "10.96.0.0/12" -Use alternative range of IP address for service VIPs. +

Use alternative range of IP address for service VIPs.

--service-dns-domain string     Default: "cluster.local" -Use alternative domain for services, e.g. "myorg.internal". +

Use alternative domain for services, e.g. "myorg.internal".

@@ -98,7 +111,7 @@ kubeadm init phase certs all [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-etcd-client.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-etcd-client.md index eef07b2afa..3280fdc0eb 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-etcd-client.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-etcd-client.md @@ -1,8 +1,21 @@ + + + +Generate the certificate the apiserver uses to access etcd ### Synopsis -Generate the certificate the apiserver uses to access etcd, and save them into apiserver-etcd-client.cert and apiserver-etcd-client.key files. +Generate the certificate the apiserver uses to access etcd, and save them into apiserver-etcd-client.crt and apiserver-etcd-client.key files. If both files already exist, kubeadm skips the generation step and existing files will be used. @@ -25,28 +38,28 @@ kubeadm init phase certs apiserver-etcd-client [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for apiserver-etcd-client +

help for apiserver-etcd-client

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

@@ -67,7 +80,7 @@ kubeadm init phase certs apiserver-etcd-client [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-kubelet-client.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-kubelet-client.md index 1d03b13ef1..f98f75def0 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-kubelet-client.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver-kubelet-client.md @@ -1,8 +1,21 @@ + + + +Generate the certificate for the API server to connect to kubelet ### Synopsis -Generate the certificate for the API server to connect to kubelet, and save them into apiserver-kubelet-client.cert and apiserver-kubelet-client.key files. +Generate the certificate for the API server to connect to kubelet, and save them into apiserver-kubelet-client.crt and apiserver-kubelet-client.key files. If both files already exist, kubeadm skips the generation step and existing files will be used. @@ -25,28 +38,28 @@ kubeadm init phase certs apiserver-kubelet-client [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for apiserver-kubelet-client +

help for apiserver-kubelet-client

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

@@ -67,7 +80,7 @@ kubeadm init phase certs apiserver-kubelet-client [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver.md index 28f6cc6244..afa192d3de 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_apiserver.md @@ -1,10 +1,21 @@ + + + +Generate the certificate for serving the Kubernetes API ### Synopsis -Generate the certificate for serving the Kubernetes API, and save them into apiserver.cert and apiserver.key files. - -Default SANs are kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, 10.96.0.1, 127.0.0.1 +Generate the certificate for serving the Kubernetes API, and save them into apiserver.crt and apiserver.key files. If both files already exist, kubeadm skips the generation step and existing files will be used. @@ -27,63 +38,63 @@ kubeadm init phase certs apiserver [flags] --apiserver-advertise-address string -The IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

The IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

---apiserver-cert-extra-sans stringSlice +--apiserver-cert-extra-sans strings -Optional extra Subject Alternative Names (SANs) to use for the API Server serving certificate. Can be both IP addresses and DNS names. +

Optional extra Subject Alternative Names (SANs) to use for the API Server serving certificate. Can be both IP addresses and DNS names.

--cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--control-plane-endpoint string -Specify a stable IP address or DNS name for the control plane. +

Specify a stable IP address or DNS name for the control plane.

-h, --help -help for apiserver +

help for apiserver

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

--service-cidr string     Default: "10.96.0.0/12" -Use alternative range of IP address for service VIPs. +

Use alternative range of IP address for service VIPs.

--service-dns-domain string     Default: "cluster.local" -Use alternative domain for services, e.g. "myorg.internal". +

Use alternative domain for services, e.g. "myorg.internal".

@@ -104,7 +115,7 @@ kubeadm init phase certs apiserver [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_ca.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_ca.md index 81ccc2cbc2..b94061e8d4 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_ca.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_ca.md @@ -1,8 +1,21 @@ + + + +Generate the self-signed Kubernetes CA to provision identities for other Kubernetes components ### Synopsis -Generate the self-signed Kubernetes CA to provision identities for other Kubernetes components, and save them into ca.cert and ca.key files. +Generate the self-signed Kubernetes CA to provision identities for other Kubernetes components, and save them into ca.crt and ca.key files. If both files already exist, kubeadm skips the generation step and existing files will be used. @@ -25,28 +38,28 @@ kubeadm init phase certs ca [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for ca +

help for ca

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

@@ -67,7 +80,7 @@ kubeadm init phase certs ca [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-ca.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-ca.md index 17066413dd..547601e364 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-ca.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-ca.md @@ -1,8 +1,21 @@ + + + +Generate the self-signed CA to provision identities for etcd ### Synopsis -Generate the self-signed CA to provision identities for etcd, and save them into etcd/ca.cert and etcd/ca.key files. +Generate the self-signed CA to provision identities for etcd, and save them into etcd/ca.crt and etcd/ca.key files. If both files already exist, kubeadm skips the generation step and existing files will be used. @@ -25,28 +38,28 @@ kubeadm init phase certs etcd-ca [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for etcd-ca +

help for etcd-ca

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

@@ -67,7 +80,7 @@ kubeadm init phase certs etcd-ca [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-healthcheck-client.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-healthcheck-client.md index 6ee2e7ea11..ea3755c786 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-healthcheck-client.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-healthcheck-client.md @@ -1,8 +1,21 @@ + + + +Generate the certificate for liveness probes to healthcheck etcd ### Synopsis -Generate the certificate for liveness probes to healthcheck etcd, and save them into etcd/healthcheck-client.cert and etcd/healthcheck-client.key files. +Generate the certificate for liveness probes to healthcheck etcd, and save them into etcd/healthcheck-client.crt and etcd/healthcheck-client.key files. If both files already exist, kubeadm skips the generation step and existing files will be used. @@ -25,28 +38,28 @@ kubeadm init phase certs etcd-healthcheck-client [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for etcd-healthcheck-client +

help for etcd-healthcheck-client

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

@@ -67,7 +80,7 @@ kubeadm init phase certs etcd-healthcheck-client [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-peer.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-peer.md index a127d4095a..904b00a68f 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-peer.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-peer.md @@ -1,8 +1,21 @@ + + + +Generate the certificate for etcd nodes to communicate with each other ### Synopsis -Generate the certificate for etcd nodes to communicate with each other, and save them into etcd/peer.cert and etcd/peer.key files. +Generate the certificate for etcd nodes to communicate with each other, and save them into etcd/peer.crt and etcd/peer.key files. Default SANs are localhost, 127.0.0.1, 127.0.0.1, ::1 @@ -27,28 +40,28 @@ kubeadm init phase certs etcd-peer [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for etcd-peer +

help for etcd-peer

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

@@ -69,7 +82,7 @@ kubeadm init phase certs etcd-peer [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-server.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-server.md index 07a58373c1..4b8894075c 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-server.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_etcd-server.md @@ -1,8 +1,21 @@ + + + +Generate the certificate for serving etcd ### Synopsis -Generate the certificate for serving etcd, and save them into etcd/server.cert and etcd/server.key files. +Generate the certificate for serving etcd, and save them into etcd/server.crt and etcd/server.key files. Default SANs are localhost, 127.0.0.1, 127.0.0.1, ::1 @@ -27,28 +40,28 @@ kubeadm init phase certs etcd-server [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for etcd-server +

help for etcd-server

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

@@ -69,7 +82,7 @@ kubeadm init phase certs etcd-server [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-ca.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-ca.md index 4a05b78d77..8193d38fce 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-ca.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-ca.md @@ -1,8 +1,21 @@ + + + +Generate the self-signed CA to provision identities for front proxy ### Synopsis -Generate the self-signed CA to provision identities for front proxy, and save them into front-proxy-ca.cert and front-proxy-ca.key files. +Generate the self-signed CA to provision identities for front proxy, and save them into front-proxy-ca.crt and front-proxy-ca.key files. If both files already exist, kubeadm skips the generation step and existing files will be used. @@ -25,28 +38,28 @@ kubeadm init phase certs front-proxy-ca [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for front-proxy-ca +

help for front-proxy-ca

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

@@ -67,7 +80,7 @@ kubeadm init phase certs front-proxy-ca [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-client.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-client.md index 8e2d76f451..d5cff5b662 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-client.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_front-proxy-client.md @@ -1,8 +1,21 @@ + + + +Generate the certificate for the front proxy client ### Synopsis -Generate the certificate for the front proxy client, and save them into front-proxy-client.cert and front-proxy-client.key files. +Generate the certificate for the front proxy client, and save them into front-proxy-client.crt and front-proxy-client.key files. If both files already exist, kubeadm skips the generation step and existing files will be used. @@ -25,28 +38,28 @@ kubeadm init phase certs front-proxy-client [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for front-proxy-client +

help for front-proxy-client

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

@@ -67,7 +80,7 @@ kubeadm init phase certs front-proxy-client [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_sa.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_sa.md index 8d36df6c52..a3df321d88 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_sa.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_certs_sa.md @@ -1,3 +1,16 @@ + + + +Generate a private key for signing service account tokens along with its public key ### Synopsis @@ -23,14 +36,14 @@ kubeadm init phase certs sa [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

-h, --help -help for sa +

help for sa

@@ -51,7 +64,7 @@ kubeadm init phase certs sa [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane.md index 2bed8442d3..86ef35d14d 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane.md @@ -1,3 +1,16 @@ + + + +Generate all static Pod manifest files necessary to establish the control plane ### Synopsis @@ -21,7 +34,7 @@ kubeadm init phase control-plane [flags] -h, --help -help for control-plane +

help for control-plane

@@ -42,7 +55,7 @@ kubeadm init phase control-plane [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_all.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_all.md index e03cdb6274..6a53512cc4 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_all.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_all.md @@ -1,3 +1,16 @@ + + + +Generate all static Pod manifest files ### Synopsis @@ -32,105 +45,112 @@ kubeadm init phase control-plane all [flags] --apiserver-advertise-address string -The IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

The IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--apiserver-bind-port int32     Default: 6443 -Port for the API Server to bind to. +

Port for the API Server to bind to.

---apiserver-extra-args mapStringString +--apiserver-extra-args <comma-separated 'key=value' pairs> -A set of extra flags to pass to the API Server or override default ones in form of <flagname>=<value> +

A set of extra flags to pass to the API Server or override default ones in form of <flagname>=<value>

--cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--control-plane-endpoint string -Specify a stable IP address or DNS name for the control plane. +

Specify a stable IP address or DNS name for the control plane.

---controller-manager-extra-args mapStringString +--controller-manager-extra-args <comma-separated 'key=value' pairs> -A set of extra flags to pass to the Controller Manager or override default ones in form of <flagname>=<value> +

A set of extra flags to pass to the Controller Manager or override default ones in form of <flagname>=<value>

---experimental-patches string +--dry-run -Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically. +

Don't apply any changes; just output what would be done.

--feature-gates string -A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (ALPHA - default=false)
PublicKeysECDSA=true|false (ALPHA - default=false) +

A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (BETA - default=true)
PublicKeysECDSA=true|false (ALPHA - default=false)
RootlessControlPlane=true|false (ALPHA - default=false)

-h, --help -help for all +

help for all

--image-repository string     Default: "k8s.gcr.io" -Choose a container registry to pull control plane images from +

Choose a container registry to pull control plane images from

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

+ + + +--patches string + + +

Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "target" can be one of "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically.

--pod-network-cidr string -Specify range of IP addresses for the pod network. If set, the control plane will automatically allocate CIDRs for every node. +

Specify range of IP addresses for the pod network. If set, the control plane will automatically allocate CIDRs for every node.

---scheduler-extra-args mapStringString +--scheduler-extra-args <comma-separated 'key=value' pairs> -A set of extra flags to pass to the Scheduler or override default ones in form of <flagname>=<value> +

A set of extra flags to pass to the Scheduler or override default ones in form of <flagname>=<value>

--service-cidr string     Default: "10.96.0.0/12" -Use alternative range of IP address for service VIPs. +

Use alternative range of IP address for service VIPs.

@@ -151,7 +171,7 @@ kubeadm init phase control-plane all [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_apiserver.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_apiserver.md index 50aef041fd..b46d5ea7c8 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_apiserver.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_apiserver.md @@ -1,3 +1,16 @@ + + + +Generates the kube-apiserver static Pod manifest ### Synopsis @@ -21,84 +34,91 @@ kubeadm init phase control-plane apiserver [flags] --apiserver-advertise-address string -The IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

The IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--apiserver-bind-port int32     Default: 6443 -Port for the API Server to bind to. +

Port for the API Server to bind to.

---apiserver-extra-args mapStringString +--apiserver-extra-args <comma-separated 'key=value' pairs> -A set of extra flags to pass to the API Server or override default ones in form of <flagname>=<value> +

A set of extra flags to pass to the API Server or override default ones in form of <flagname>=<value>

--cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--control-plane-endpoint string -Specify a stable IP address or DNS name for the control plane. +

Specify a stable IP address or DNS name for the control plane.

---experimental-patches string +--dry-run -Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically. +

Don't apply any changes; just output what would be done.

--feature-gates string -A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (ALPHA - default=false)
PublicKeysECDSA=true|false (ALPHA - default=false) +

A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (BETA - default=true)
PublicKeysECDSA=true|false (ALPHA - default=false)
RootlessControlPlane=true|false (ALPHA - default=false)

-h, --help -help for apiserver +

help for apiserver

--image-repository string     Default: "k8s.gcr.io" -Choose a container registry to pull control plane images from +

Choose a container registry to pull control plane images from

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

+ + + +--patches string + + +

Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "target" can be one of "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically.

--service-cidr string     Default: "10.96.0.0/12" -Use alternative range of IP address for service VIPs. +

Use alternative range of IP address for service VIPs.

@@ -119,7 +139,7 @@ kubeadm init phase control-plane apiserver [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md index c1f0989cb6..48d36cb899 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_controller-manager.md @@ -1,3 +1,16 @@ + + + +Generates the kube-controller-manager static Pod manifest ### Synopsis @@ -21,56 +34,63 @@ kubeadm init phase control-plane controller-manager [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

---controller-manager-extra-args mapStringString +--controller-manager-extra-args <comma-separated 'key=value' pairs> -A set of extra flags to pass to the Controller Manager or override default ones in form of <flagname>=<value> +

A set of extra flags to pass to the Controller Manager or override default ones in form of <flagname>=<value>

---experimental-patches string +--dry-run -Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically. +

Don't apply any changes; just output what would be done.

-h, --help -help for controller-manager +

help for controller-manager

--image-repository string     Default: "k8s.gcr.io" -Choose a container registry to pull control plane images from +

Choose a container registry to pull control plane images from

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

+ + + +--patches string + + +

Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "target" can be one of "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically.

--pod-network-cidr string -Specify range of IP addresses for the pod network. If set, the control plane will automatically allocate CIDRs for every node. +

Specify range of IP addresses for the pod network. If set, the control plane will automatically allocate CIDRs for every node.

@@ -91,7 +111,7 @@ kubeadm init phase control-plane controller-manager [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_scheduler.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_scheduler.md index ce2f366b13..f726834229 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_scheduler.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_control-plane_scheduler.md @@ -1,3 +1,16 @@ + + + +Generates the kube-scheduler static Pod manifest ### Synopsis @@ -21,49 +34,56 @@ kubeadm init phase control-plane scheduler [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

---experimental-patches string +--dry-run -Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically. +

Don't apply any changes; just output what would be done.

-h, --help -help for scheduler +

help for scheduler

--image-repository string     Default: "k8s.gcr.io" -Choose a container registry to pull control plane images from +

Choose a container registry to pull control plane images from

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

---scheduler-extra-args mapStringString +--patches string -A set of extra flags to pass to the Scheduler or override default ones in form of <flagname>=<value> +

Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "target" can be one of "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically.

+ + + +--scheduler-extra-args <comma-separated 'key=value' pairs> + + +

A set of extra flags to pass to the Scheduler or override default ones in form of <flagname>=<value>

@@ -84,7 +104,7 @@ kubeadm init phase control-plane scheduler [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd.md index dc5227a34c..be2aef8c3b 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd.md @@ -1,3 +1,16 @@ + + + +Generate static Pod manifest file for local etcd ### Synopsis @@ -21,7 +34,7 @@ kubeadm init phase etcd [flags] -h, --help -help for etcd +

help for etcd

@@ -42,7 +55,7 @@ kubeadm init phase etcd [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd_local.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd_local.md index 0e4cb7181e..f5bc0a529b 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd_local.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_etcd_local.md @@ -1,3 +1,16 @@ + + + +Generate the static Pod manifest file for a local, single-node local etcd instance ### Synopsis @@ -33,35 +46,35 @@ kubeadm init phase etcd local [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. - - - ---experimental-patches string - - -Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically. +

Path to a kubeadm configuration file.

-h, --help -help for local +

help for local

--image-repository string     Default: "k8s.gcr.io" -Choose a container registry to pull control plane images from +

Choose a container registry to pull control plane images from

+ + + +--patches string + + +

Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "target" can be one of "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically.

@@ -82,7 +95,7 @@ kubeadm init phase etcd local [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig.md index b3a200a228..da4fde7ebc 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig.md @@ -1,3 +1,16 @@ + + + +Generate all kubeconfig files necessary to establish the control plane and the admin kubeconfig file ### Synopsis @@ -21,7 +34,7 @@ kubeadm init phase kubeconfig [flags] -h, --help -help for kubeconfig +

help for kubeconfig

@@ -42,7 +55,7 @@ kubeadm init phase kubeconfig [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_admin.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_admin.md index 85885559f7..a664e126ff 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_admin.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_admin.md @@ -1,3 +1,16 @@ + + + +Generate a kubeconfig file for the admin to use and for kubeadm itself ### Synopsis @@ -21,56 +34,56 @@ kubeadm init phase kubeconfig admin [flags] --apiserver-advertise-address string -The IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

The IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--apiserver-bind-port int32     Default: 6443 -Port for the API Server to bind to. +

Port for the API Server to bind to.

--cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--control-plane-endpoint string -Specify a stable IP address or DNS name for the control plane. +

Specify a stable IP address or DNS name for the control plane.

-h, --help -help for admin +

help for admin

--kubeconfig-dir string     Default: "/etc/kubernetes" -The path where to save the kubeconfig file. +

The path where to save the kubeconfig file.

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

@@ -91,7 +104,7 @@ kubeadm init phase kubeconfig admin [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_all.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_all.md index 9296e84a19..f1ebdbcf12 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_all.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_all.md @@ -1,3 +1,16 @@ + + + +Generate all kubeconfig files ### Synopsis @@ -21,63 +34,63 @@ kubeadm init phase kubeconfig all [flags] --apiserver-advertise-address string -The IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

The IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--apiserver-bind-port int32     Default: 6443 -Port for the API Server to bind to. +

Port for the API Server to bind to.

--cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--control-plane-endpoint string -Specify a stable IP address or DNS name for the control plane. +

Specify a stable IP address or DNS name for the control plane.

-h, --help -help for all +

help for all

--kubeconfig-dir string     Default: "/etc/kubernetes" -The path where to save the kubeconfig file. +

The path where to save the kubeconfig file.

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

--node-name string -Specify the node name. +

Specify the node name.

@@ -98,7 +111,7 @@ kubeadm init phase kubeconfig all [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_controller-manager.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_controller-manager.md index 295d7e57dc..c49ab4b6c4 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_controller-manager.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_controller-manager.md @@ -1,3 +1,16 @@ + + + +Generate a kubeconfig file for the controller manager to use ### Synopsis @@ -21,56 +34,56 @@ kubeadm init phase kubeconfig controller-manager [flags] --apiserver-advertise-address string -The IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

The IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--apiserver-bind-port int32     Default: 6443 -Port for the API Server to bind to. +

Port for the API Server to bind to.

--cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--control-plane-endpoint string -Specify a stable IP address or DNS name for the control plane. +

Specify a stable IP address or DNS name for the control plane.

-h, --help -help for controller-manager +

help for controller-manager

--kubeconfig-dir string     Default: "/etc/kubernetes" -The path where to save the kubeconfig file. +

The path where to save the kubeconfig file.

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

@@ -91,7 +104,7 @@ kubeadm init phase kubeconfig controller-manager [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_kubelet.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_kubelet.md index 9fd3145290..fd141ea0fc 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_kubelet.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_kubelet.md @@ -1,3 +1,16 @@ + + + +Generate a kubeconfig file for the kubelet to use *only* for cluster bootstrapping purposes ### Synopsis @@ -23,63 +36,63 @@ kubeadm init phase kubeconfig kubelet [flags] --apiserver-advertise-address string -The IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

The IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--apiserver-bind-port int32     Default: 6443 -Port for the API Server to bind to. +

Port for the API Server to bind to.

--cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--control-plane-endpoint string -Specify a stable IP address or DNS name for the control plane. +

Specify a stable IP address or DNS name for the control plane.

-h, --help -help for kubelet +

help for kubelet

--kubeconfig-dir string     Default: "/etc/kubernetes" -The path where to save the kubeconfig file. +

The path where to save the kubeconfig file.

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

--node-name string -Specify the node name. +

Specify the node name.

@@ -100,7 +113,7 @@ kubeadm init phase kubeconfig kubelet [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_scheduler.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_scheduler.md index c608732717..9618c2d874 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_scheduler.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubeconfig_scheduler.md @@ -1,3 +1,16 @@ + + + +Generate a kubeconfig file for the scheduler to use ### Synopsis @@ -21,56 +34,56 @@ kubeadm init phase kubeconfig scheduler [flags] --apiserver-advertise-address string -The IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

The IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--apiserver-bind-port int32     Default: 6443 -Port for the API Server to bind to. +

Port for the API Server to bind to.

--cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--control-plane-endpoint string -Specify a stable IP address or DNS name for the control plane. +

Specify a stable IP address or DNS name for the control plane.

-h, --help -help for scheduler +

help for scheduler

--kubeconfig-dir string     Default: "/etc/kubernetes" -The path where to save the kubeconfig file. +

The path where to save the kubeconfig file.

--kubernetes-version string     Default: "stable-1" -Choose a specific Kubernetes version for the control plane. +

Choose a specific Kubernetes version for the control plane.

@@ -91,7 +104,7 @@ kubeadm init phase kubeconfig scheduler [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize.md index 4e5febf638..d2eb7f0125 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize.md @@ -1,3 +1,16 @@ + + + +Updates settings relevant to the kubelet after TLS bootstrap ### Synopsis @@ -28,7 +41,7 @@ kubeadm init phase kubelet-finalize [flags] -h, --help -help for kubelet-finalize +

help for kubelet-finalize

@@ -49,7 +62,7 @@ kubeadm init phase kubelet-finalize [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize_all.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize_all.md index fce712fc45..70e4c634b0 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize_all.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize_all.md @@ -1,3 +1,16 @@ + + + +Run all kubelet-finalize phases ### Synopsis @@ -28,21 +41,21 @@ kubeadm init phase kubelet-finalize all [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for all +

help for all

@@ -63,7 +76,7 @@ kubeadm init phase kubelet-finalize all [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md index 2ace62929b..6ce904cc2b 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md @@ -1,3 +1,16 @@ + + + +Enable kubelet client certificate rotation ### Synopsis @@ -21,21 +34,21 @@ kubeadm init phase kubelet-finalize experimental-cert-rotation [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path where to save and store the certificates. +

The path where to save and store the certificates.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for experimental-cert-rotation +

help for experimental-cert-rotation

@@ -56,7 +69,7 @@ kubeadm init phase kubelet-finalize experimental-cert-rotation [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-start.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-start.md index f9898b58e0..11d2407499 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-start.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_kubelet-start.md @@ -1,3 +1,16 @@ + + + +Write kubelet settings and (re)start the kubelet ### Synopsis @@ -28,28 +41,28 @@ kubeadm init phase kubelet-start [flags] --config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--cri-socket string -Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket. +

Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket.

-h, --help -help for kubelet-start +

help for kubelet-start

--node-name string -Specify the node name. +

Specify the node name.

@@ -70,7 +83,7 @@ kubeadm init phase kubelet-start [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_mark-control-plane.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_mark-control-plane.md index 453783db52..6ba7e90479 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_mark-control-plane.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_mark-control-plane.md @@ -1,3 +1,16 @@ + + + +Mark a node as a control-plane ### Synopsis @@ -12,7 +25,7 @@ kubeadm init phase mark-control-plane [flags] ``` # Applies control-plane label and taint to the current node, functionally equivalent to what executed by kubeadm init. - kubeadm init phase mark-control-plane --config config.yml + kubeadm init phase mark-control-plane --config config.yaml # Applies control-plane label and taint to a specific node kubeadm init phase mark-control-plane --node-name myNode @@ -31,21 +44,21 @@ kubeadm init phase mark-control-plane [flags] --config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for mark-control-plane +

help for mark-control-plane

--node-name string -Specify the node name. +

Specify the node name.

@@ -66,7 +79,7 @@ kubeadm init phase mark-control-plane [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_preflight.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_preflight.md index 06d47e861c..345621f703 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_preflight.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_preflight.md @@ -1,3 +1,16 @@ + + + +Run pre-flight checks ### Synopsis @@ -12,7 +25,7 @@ kubeadm init phase preflight [flags] ``` # Run pre-flight checks for kubeadm init using a config file. - kubeadm init phase preflight --config kubeadm-config.yml + kubeadm init phase preflight --config kubeadm-config.yaml ``` ### Options @@ -28,21 +41,21 @@ kubeadm init phase preflight [flags] --config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for preflight +

help for preflight

---ignore-preflight-errors stringSlice +--ignore-preflight-errors strings -A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks. +

A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.

@@ -63,7 +76,7 @@ kubeadm init phase preflight [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-certs.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-certs.md index 404f62d725..515060a76c 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-certs.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-certs.md @@ -1,3 +1,16 @@ + + + +Upload certificates to kubeadm-certs ### Synopsis @@ -21,42 +34,42 @@ kubeadm init phase upload-certs [flags] --certificate-key string -Key used to encrypt the control-plane certificates in the kubeadm-certs Secret. +

Key used to encrypt the control-plane certificates in the kubeadm-certs Secret.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for upload-certs +

help for upload-certs

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--skip-certificate-key-print -Don't print the key used to encrypt the control-plane certificates. +

Don't print the key used to encrypt the control-plane certificates.

--upload-certs -Upload control-plane certificates to the kubeadm-certs Secret. +

Upload control-plane certificates to the kubeadm-certs Secret.

@@ -77,7 +90,7 @@ kubeadm init phase upload-certs [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config.md index c1b5c96092..7d007e7b56 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config.md @@ -1,3 +1,16 @@ + + + +Upload the kubeadm and kubelet configuration to a ConfigMap ### Synopsis @@ -21,7 +34,7 @@ kubeadm init phase upload-config [flags] -h, --help -help for upload-config +

help for upload-config

@@ -42,7 +55,7 @@ kubeadm init phase upload-config [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_all.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_all.md index 6370094df9..3c087368a7 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_all.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_all.md @@ -1,3 +1,16 @@ + + + +Upload all configuration to a config map ### Synopsis @@ -21,21 +34,21 @@ kubeadm init phase upload-config all [flags] --config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for all +

help for all

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -56,7 +69,7 @@ kubeadm init phase upload-config all [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_kubeadm.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_kubeadm.md index 030595466b..13e561f486 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_kubeadm.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_kubeadm.md @@ -1,3 +1,16 @@ + + + +Upload the kubeadm ClusterConfiguration to a ConfigMap ### Synopsis @@ -30,21 +43,21 @@ kubeadm init phase upload-config kubeadm [flags] --config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for kubeadm +

help for kubeadm

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -65,7 +78,7 @@ kubeadm init phase upload-config kubeadm [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_kubelet.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_kubelet.md index bd334e091c..ba27f728cb 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_kubelet.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_init_phase_upload-config_kubelet.md @@ -1,3 +1,16 @@ + + + +Upload the kubelet component config to a ConfigMap ### Synopsis @@ -28,21 +41,21 @@ kubeadm init phase upload-config kubelet [flags] --config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-h, --help -help for kubelet +

help for kubelet

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -63,7 +76,7 @@ kubeadm init phase upload-config kubelet [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join.md index 3a6f7299d6..145f0bc340 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join.md @@ -1,3 +1,16 @@ + + + +Run this on any machine you wish to join an existing cluster ### Synopsis @@ -56,7 +69,7 @@ control-plane-prepare Prepare the machine for serving a control plane kubelet-start Write kubelet settings, certificates and (re)start the kubelet control-plane-join Join a machine as a control plane instance /etcd Add a new local etcd member - /update-status Register the new control-plane node into the ClusterStatus maintained in the kubeadm-config ConfigMap + /update-status Register the new control-plane node into the ClusterStatus maintained in the kubeadm-config ConfigMap (DEPRECATED) /mark-control-plane Mark a node as a control-plane ``` @@ -78,119 +91,119 @@ kubeadm join [api-server-endpoint] [flags] --apiserver-advertise-address string -If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--apiserver-bind-port int32     Default: 6443 -If the node should host a new control plane instance, the port for the API Server to bind to. +

If the node should host a new control plane instance, the port for the API Server to bind to.

--certificate-key string -Use this key to decrypt the certificate secrets uploaded by init. +

Use this key to decrypt the certificate secrets uploaded by init.

--config string -Path to kubeadm config file. +

Path to kubeadm config file.

--control-plane -Create a new control plane instance on this node +

Create a new control plane instance on this node

--cri-socket string -Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket. +

Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket.

--discovery-file string -For file-based discovery, a file or URL from which to load cluster information. +

For file-based discovery, a file or URL from which to load cluster information.

--discovery-token string -For token-based discovery, the token used to validate cluster information fetched from the API server. +

For token-based discovery, the token used to validate cluster information fetched from the API server.

---discovery-token-ca-cert-hash stringSlice +--discovery-token-ca-cert-hash strings -For token-based discovery, validate that the root CA public key matches this hash (format: "<type>:<value>"). +

For token-based discovery, validate that the root CA public key matches this hash (format: "<type>:<value>").

--discovery-token-unsafe-skip-ca-verification -For token-based discovery, allow joining without --discovery-token-ca-cert-hash pinning. - - - ---experimental-patches string - - -Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically. +

For token-based discovery, allow joining without --discovery-token-ca-cert-hash pinning.

-h, --help -help for join +

help for join

---ignore-preflight-errors stringSlice +--ignore-preflight-errors strings -A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks. +

A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.

--node-name string -Specify the node name. +

Specify the node name.

---skip-phases stringSlice +--patches string -List of phases to be skipped +

Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "target" can be one of "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically.

+ + + +--skip-phases strings + + +

List of phases to be skipped

--tls-bootstrap-token string -Specify the token used to temporarily authenticate with the Kubernetes Control Plane while joining the node. +

Specify the token used to temporarily authenticate with the Kubernetes Control Plane while joining the node.

--token string -Use this token for both discovery-token and tls-bootstrap-token when those values are not provided. +

Use this token for both discovery-token and tls-bootstrap-token when those values are not provided.

@@ -211,7 +224,7 @@ kubeadm join [api-server-endpoint] [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase.md index 873f64aa16..b780de18cc 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase.md @@ -1,3 +1,16 @@ + + + +Use this command to invoke single phase of the join workflow ### Synopsis @@ -17,7 +30,7 @@ Use this command to invoke single phase of the join workflow -h, --help -help for phase +

help for phase

@@ -38,7 +51,7 @@ Use this command to invoke single phase of the join workflow --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join.md index 20170c783c..07768a16c6 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join.md @@ -1,3 +1,16 @@ + + + +Join a machine as a control plane instance ### Synopsis @@ -28,7 +41,7 @@ kubeadm join phase control-plane-join [flags] -h, --help -help for control-plane-join +

help for control-plane-join

@@ -49,7 +62,7 @@ kubeadm join phase control-plane-join [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_all.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_all.md index 9515d0dfe7..7a3517652d 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_all.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_all.md @@ -1,3 +1,16 @@ + + + +Join a machine as a control plane instance ### Synopsis @@ -21,35 +34,42 @@ kubeadm join phase control-plane-join all [flags] --apiserver-advertise-address string -If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--config string -Path to kubeadm config file. +

Path to kubeadm config file.

--control-plane -Create a new control plane instance on this node +

Create a new control plane instance on this node

-h, --help -help for all +

help for all

--node-name string -Specify the node name. +

Specify the node name.

+ + + +--patches string + + +

Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "target" can be one of "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically.

@@ -70,7 +90,7 @@ kubeadm join phase control-plane-join all [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_etcd.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_etcd.md index 4618107dd2..c06ddaae40 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_etcd.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_etcd.md @@ -1,3 +1,16 @@ + + + +Add a new local etcd member ### Synopsis @@ -21,42 +34,42 @@ kubeadm join phase control-plane-join etcd [flags] --apiserver-advertise-address string -If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--config string -Path to kubeadm config file. +

Path to kubeadm config file.

--control-plane -Create a new control plane instance on this node - - - ---experimental-patches string - - -Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically. +

Create a new control plane instance on this node

-h, --help -help for etcd +

help for etcd

--node-name string -Specify the node name. +

Specify the node name.

+ + + +--patches string + + +

Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "target" can be one of "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically.

@@ -77,7 +90,7 @@ kubeadm join phase control-plane-join etcd [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_mark-control-plane.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_mark-control-plane.md index 37bd9675b8..9e2d117ed9 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_mark-control-plane.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_mark-control-plane.md @@ -1,3 +1,16 @@ + + + +Mark a node as a control-plane ### Synopsis @@ -21,28 +34,28 @@ kubeadm join phase control-plane-join mark-control-plane [flags] --config string -Path to kubeadm config file. +

Path to kubeadm config file.

--control-plane -Create a new control plane instance on this node +

Create a new control plane instance on this node

-h, --help -help for mark-control-plane +

help for mark-control-plane

--node-name string -Specify the node name. +

Specify the node name.

@@ -63,7 +76,7 @@ kubeadm join phase control-plane-join mark-control-plane [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_update-status.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_update-status.md index 258210f303..af1aac985c 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_update-status.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-join_update-status.md @@ -1,8 +1,21 @@ + + + +Register the new control-plane node into the ClusterStatus maintained in the kubeadm-config ConfigMap (DEPRECATED) ### Synopsis -Register the new control-plane node into the ClusterStatus maintained in the kubeadm-config ConfigMap +Register the new control-plane node into the ClusterStatus maintained in the kubeadm-config ConfigMap (DEPRECATED) ``` kubeadm join phase control-plane-join update-status [flags] @@ -21,35 +34,35 @@ kubeadm join phase control-plane-join update-status [flags] --apiserver-advertise-address string -If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--config string -Path to kubeadm config file. +

Path to kubeadm config file.

--control-plane -Create a new control plane instance on this node +

Create a new control plane instance on this node

-h, --help -help for update-status +

help for update-status

--node-name string -Specify the node name. +

Specify the node name.

@@ -70,7 +83,7 @@ kubeadm join phase control-plane-join update-status [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare.md index 81a88bdaa5..6952dbca80 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare.md @@ -1,3 +1,16 @@ + + + +Prepare the machine for serving a control plane ### Synopsis @@ -28,7 +41,7 @@ kubeadm join phase control-plane-prepare [flags] -h, --help -help for control-plane-prepare +

help for control-plane-prepare

@@ -49,7 +62,7 @@ kubeadm join phase control-plane-prepare [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_all.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_all.md index 932ef5f27b..661edf597d 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_all.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_all.md @@ -1,3 +1,16 @@ + + + +Prepare the machine for serving a control plane ### Synopsis @@ -21,98 +34,98 @@ kubeadm join phase control-plane-prepare all [api-server-endpoint] [flags] --apiserver-advertise-address string -If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--apiserver-bind-port int32     Default: 6443 -If the node should host a new control plane instance, the port for the API Server to bind to. +

If the node should host a new control plane instance, the port for the API Server to bind to.

--certificate-key string -Use this key to decrypt the certificate secrets uploaded by init. +

Use this key to decrypt the certificate secrets uploaded by init.

--config string -Path to kubeadm config file. +

Path to kubeadm config file.

--control-plane -Create a new control plane instance on this node +

Create a new control plane instance on this node

--discovery-file string -For file-based discovery, a file or URL from which to load cluster information. +

For file-based discovery, a file or URL from which to load cluster information.

--discovery-token string -For token-based discovery, the token used to validate cluster information fetched from the API server. +

For token-based discovery, the token used to validate cluster information fetched from the API server.

---discovery-token-ca-cert-hash stringSlice +--discovery-token-ca-cert-hash strings -For token-based discovery, validate that the root CA public key matches this hash (format: "<type>:<value>"). +

For token-based discovery, validate that the root CA public key matches this hash (format: "<type>:<value>").

--discovery-token-unsafe-skip-ca-verification -For token-based discovery, allow joining without --discovery-token-ca-cert-hash pinning. - - - ---experimental-patches string - - -Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically. +

For token-based discovery, allow joining without --discovery-token-ca-cert-hash pinning.

-h, --help -help for all +

help for all

--node-name string -Specify the node name. +

Specify the node name.

+ + + +--patches string + + +

Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "target" can be one of "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically.

--tls-bootstrap-token string -Specify the token used to temporarily authenticate with the Kubernetes Control Plane while joining the node. +

Specify the token used to temporarily authenticate with the Kubernetes Control Plane while joining the node.

--token string -Use this token for both discovery-token and tls-bootstrap-token when those values are not provided. +

Use this token for both discovery-token and tls-bootstrap-token when those values are not provided.

@@ -133,7 +146,7 @@ kubeadm join phase control-plane-prepare all [api-server-endpoint] [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_certs.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_certs.md index c8d59d58eb..6475115940 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_certs.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_certs.md @@ -1,3 +1,16 @@ + + + +Generate the certificates for the new control plane components ### Synopsis @@ -21,77 +34,77 @@ kubeadm join phase control-plane-prepare certs [api-server-endpoint] [flags] --apiserver-advertise-address string -If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--config string -Path to kubeadm config file. +

Path to kubeadm config file.

--control-plane -Create a new control plane instance on this node +

Create a new control plane instance on this node

--discovery-file string -For file-based discovery, a file or URL from which to load cluster information. +

For file-based discovery, a file or URL from which to load cluster information.

--discovery-token string -For token-based discovery, the token used to validate cluster information fetched from the API server. +

For token-based discovery, the token used to validate cluster information fetched from the API server.

---discovery-token-ca-cert-hash stringSlice +--discovery-token-ca-cert-hash strings -For token-based discovery, validate that the root CA public key matches this hash (format: "<type>:<value>"). +

For token-based discovery, validate that the root CA public key matches this hash (format: "<type>:<value>").

--discovery-token-unsafe-skip-ca-verification -For token-based discovery, allow joining without --discovery-token-ca-cert-hash pinning. +

For token-based discovery, allow joining without --discovery-token-ca-cert-hash pinning.

-h, --help -help for certs +

help for certs

--node-name string -Specify the node name. +

Specify the node name.

--tls-bootstrap-token string -Specify the token used to temporarily authenticate with the Kubernetes Control Plane while joining the node. +

Specify the token used to temporarily authenticate with the Kubernetes Control Plane while joining the node.

--token string -Use this token for both discovery-token and tls-bootstrap-token when those values are not provided. +

Use this token for both discovery-token and tls-bootstrap-token when those values are not provided.

@@ -112,7 +125,7 @@ kubeadm join phase control-plane-prepare certs [api-server-endpoint] [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_control-plane.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_control-plane.md index 3e9a120c00..c9084c6e55 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_control-plane.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_control-plane.md @@ -1,3 +1,16 @@ + + + +Generate the manifests for the new control plane components ### Synopsis @@ -21,42 +34,42 @@ kubeadm join phase control-plane-prepare control-plane [flags] --apiserver-advertise-address string -If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--apiserver-bind-port int32     Default: 6443 -If the node should host a new control plane instance, the port for the API Server to bind to. +

If the node should host a new control plane instance, the port for the API Server to bind to.

--config string -Path to kubeadm config file. +

Path to kubeadm config file.

--control-plane -Create a new control plane instance on this node - - - ---experimental-patches string - - -Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically. +

Create a new control plane instance on this node

-h, --help -help for control-plane +

help for control-plane

+ + + +--patches string + + +

Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "target" can be one of "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically.

@@ -77,7 +90,7 @@ kubeadm join phase control-plane-prepare control-plane [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_download-certs.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_download-certs.md index 26e65cce87..1cfac530cd 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_download-certs.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_download-certs.md @@ -1,3 +1,16 @@ + + + +[EXPERIMENTAL] Download certificates shared among control-plane nodes from the kubeadm-certs Secret ### Synopsis @@ -21,70 +34,70 @@ kubeadm join phase control-plane-prepare download-certs [api-server-endpoint] [f --certificate-key string -Use this key to decrypt the certificate secrets uploaded by init. +

Use this key to decrypt the certificate secrets uploaded by init.

--config string -Path to kubeadm config file. +

Path to kubeadm config file.

--control-plane -Create a new control plane instance on this node +

Create a new control plane instance on this node

--discovery-file string -For file-based discovery, a file or URL from which to load cluster information. +

For file-based discovery, a file or URL from which to load cluster information.

--discovery-token string -For token-based discovery, the token used to validate cluster information fetched from the API server. +

For token-based discovery, the token used to validate cluster information fetched from the API server.

---discovery-token-ca-cert-hash stringSlice +--discovery-token-ca-cert-hash strings -For token-based discovery, validate that the root CA public key matches this hash (format: "<type>:<value>"). +

For token-based discovery, validate that the root CA public key matches this hash (format: "<type>:<value>").

--discovery-token-unsafe-skip-ca-verification -For token-based discovery, allow joining without --discovery-token-ca-cert-hash pinning. +

For token-based discovery, allow joining without --discovery-token-ca-cert-hash pinning.

-h, --help -help for download-certs +

help for download-certs

--tls-bootstrap-token string -Specify the token used to temporarily authenticate with the Kubernetes Control Plane while joining the node. +

Specify the token used to temporarily authenticate with the Kubernetes Control Plane while joining the node.

--token string -Use this token for both discovery-token and tls-bootstrap-token when those values are not provided. +

Use this token for both discovery-token and tls-bootstrap-token when those values are not provided.

@@ -105,7 +118,7 @@ kubeadm join phase control-plane-prepare download-certs [api-server-endpoint] [f --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_kubeconfig.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_kubeconfig.md index 722ec2263d..027837aeee 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_kubeconfig.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_control-plane-prepare_kubeconfig.md @@ -1,3 +1,16 @@ + + + +Generate the kubeconfig for the new control plane components ### Synopsis @@ -21,70 +34,70 @@ kubeadm join phase control-plane-prepare kubeconfig [api-server-endpoint] [flags --certificate-key string -Use this key to decrypt the certificate secrets uploaded by init. +

Use this key to decrypt the certificate secrets uploaded by init.

--config string -Path to kubeadm config file. +

Path to kubeadm config file.

--control-plane -Create a new control plane instance on this node +

Create a new control plane instance on this node

--discovery-file string -For file-based discovery, a file or URL from which to load cluster information. +

For file-based discovery, a file or URL from which to load cluster information.

--discovery-token string -For token-based discovery, the token used to validate cluster information fetched from the API server. +

For token-based discovery, the token used to validate cluster information fetched from the API server.

---discovery-token-ca-cert-hash stringSlice +--discovery-token-ca-cert-hash strings -For token-based discovery, validate that the root CA public key matches this hash (format: "<type>:<value>"). +

For token-based discovery, validate that the root CA public key matches this hash (format: "<type>:<value>").

--discovery-token-unsafe-skip-ca-verification -For token-based discovery, allow joining without --discovery-token-ca-cert-hash pinning. +

For token-based discovery, allow joining without --discovery-token-ca-cert-hash pinning.

-h, --help -help for kubeconfig +

help for kubeconfig

--tls-bootstrap-token string -Specify the token used to temporarily authenticate with the Kubernetes Control Plane while joining the node. +

Specify the token used to temporarily authenticate with the Kubernetes Control Plane while joining the node.

--token string -Use this token for both discovery-token and tls-bootstrap-token when those values are not provided. +

Use this token for both discovery-token and tls-bootstrap-token when those values are not provided.

@@ -105,7 +118,7 @@ kubeadm join phase control-plane-prepare kubeconfig [api-server-endpoint] [flags --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_kubelet-start.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_kubelet-start.md index 719700b9a0..5896b25337 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_kubelet-start.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_kubelet-start.md @@ -1,3 +1,16 @@ + + + +Write kubelet settings, certificates and (re)start the kubelet ### Synopsis @@ -21,70 +34,70 @@ kubeadm join phase kubelet-start [api-server-endpoint] [flags] --config string -Path to kubeadm config file. +

Path to kubeadm config file.

--cri-socket string -Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket. +

Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket.

--discovery-file string -For file-based discovery, a file or URL from which to load cluster information. +

For file-based discovery, a file or URL from which to load cluster information.

--discovery-token string -For token-based discovery, the token used to validate cluster information fetched from the API server. +

For token-based discovery, the token used to validate cluster information fetched from the API server.

---discovery-token-ca-cert-hash stringSlice +--discovery-token-ca-cert-hash strings -For token-based discovery, validate that the root CA public key matches this hash (format: "<type>:<value>"). +

For token-based discovery, validate that the root CA public key matches this hash (format: "<type>:<value>").

--discovery-token-unsafe-skip-ca-verification -For token-based discovery, allow joining without --discovery-token-ca-cert-hash pinning. +

For token-based discovery, allow joining without --discovery-token-ca-cert-hash pinning.

-h, --help -help for kubelet-start +

help for kubelet-start

--node-name string -Specify the node name. +

Specify the node name.

--tls-bootstrap-token string -Specify the token used to temporarily authenticate with the Kubernetes Control Plane while joining the node. +

Specify the token used to temporarily authenticate with the Kubernetes Control Plane while joining the node.

--token string -Use this token for both discovery-token and tls-bootstrap-token when those values are not provided. +

Use this token for both discovery-token and tls-bootstrap-token when those values are not provided.

@@ -105,7 +118,7 @@ kubeadm join phase kubelet-start [api-server-endpoint] [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_preflight.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_preflight.md index ca975f9d92..0f4b7c50cd 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_preflight.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_join_phase_preflight.md @@ -1,3 +1,16 @@ + + + +Run join pre-flight checks ### Synopsis @@ -12,7 +25,7 @@ kubeadm join phase preflight [api-server-endpoint] [flags] ``` # Run join pre-flight checks using a config file. - kubeadm join phase preflight --config kubeadm-config.yml + kubeadm join phase preflight --config kubeadm-config.yaml ``` ### Options @@ -28,105 +41,105 @@ kubeadm join phase preflight [api-server-endpoint] [flags] --apiserver-advertise-address string -If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used. +

If the node should host a new control plane instance, the IP address the API Server will advertise it's listening on. If not set the default network interface will be used.

--apiserver-bind-port int32     Default: 6443 -If the node should host a new control plane instance, the port for the API Server to bind to. +

If the node should host a new control plane instance, the port for the API Server to bind to.

--certificate-key string -Use this key to decrypt the certificate secrets uploaded by init. +

Use this key to decrypt the certificate secrets uploaded by init.

--config string -Path to kubeadm config file. +

Path to kubeadm config file.

--control-plane -Create a new control plane instance on this node +

Create a new control plane instance on this node

--cri-socket string -Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket. +

Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket.

--discovery-file string -For file-based discovery, a file or URL from which to load cluster information. +

For file-based discovery, a file or URL from which to load cluster information.

--discovery-token string -For token-based discovery, the token used to validate cluster information fetched from the API server. +

For token-based discovery, the token used to validate cluster information fetched from the API server.

---discovery-token-ca-cert-hash stringSlice +--discovery-token-ca-cert-hash strings -For token-based discovery, validate that the root CA public key matches this hash (format: "<type>:<value>"). +

For token-based discovery, validate that the root CA public key matches this hash (format: "<type>:<value>").

--discovery-token-unsafe-skip-ca-verification -For token-based discovery, allow joining without --discovery-token-ca-cert-hash pinning. +

For token-based discovery, allow joining without --discovery-token-ca-cert-hash pinning.

-h, --help -help for preflight +

help for preflight

---ignore-preflight-errors stringSlice +--ignore-preflight-errors strings -A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks. +

A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.

--node-name string -Specify the node name. +

Specify the node name.

--tls-bootstrap-token string -Specify the token used to temporarily authenticate with the Kubernetes Control Plane while joining the node. +

Specify the token used to temporarily authenticate with the Kubernetes Control Plane while joining the node.

--token string -Use this token for both discovery-token and tls-bootstrap-token when those values are not provided. +

Use this token for both discovery-token and tls-bootstrap-token when those values are not provided.

@@ -147,7 +160,7 @@ kubeadm join phase preflight [api-server-endpoint] [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_kubeconfig.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_kubeconfig.md new file mode 100644 index 0000000000..55177462d6 --- /dev/null +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_kubeconfig.md @@ -0,0 +1,61 @@ + + + +Kubeconfig file utilities + +### Synopsis + + +Kubeconfig file utilities. + +### Options + + ++++ + + + + + + + + + + +
-h, --help

help for kubeconfig

+ + + +### Options inherited from parent commands + + ++++ + + + + + + + + + + +
--rootfs string

[EXPERIMENTAL] The path to the 'real' host root filesystem.

+ + + diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_kubeconfig_user.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_kubeconfig_user.md new file mode 100644 index 0000000000..89315e27b8 --- /dev/null +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_kubeconfig_user.md @@ -0,0 +1,107 @@ + + + +Output a kubeconfig file for an additional user + +### Synopsis + + +Output a kubeconfig file for an additional user. + +``` +kubeadm kubeconfig user [flags] +``` + +### Examples + +``` + # Output a kubeconfig file for an additional user named foo using a kubeadm config file bar + kubeadm kubeconfig user --client-name=foo --config=bar +``` + +### Options + + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
--client-name string

The name of user. It will be used as the CN if client certificates are created

--config string

Path to a kubeadm configuration file.

-h, --help

help for user

--org strings

The orgnizations of the client certificate. It will be used as the O if client certificates are created

--token string

The token that should be used as the authentication mechanism for this kubeconfig, instead of client certificates

--validity-period duration     Default: 8760h0m0s

The validity period of the client certificate. It is an offset from the current time.

+ + + +### Options inherited from parent commands + + ++++ + + + + + + + + + + +
--rootfs string

[EXPERIMENTAL] The path to the 'real' host root filesystem.

+ + + diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset.md index 4cfa48be37..19bdbb417a 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset.md @@ -1,3 +1,16 @@ + + + +Performs a best effort revert of changes made to this host by 'kubeadm init' or 'kubeadm join' ### Synopsis @@ -7,7 +20,7 @@ Performs a best effort revert of changes made to this host by 'kubeadm init' or The "reset" command executes the following phases: ``` preflight Run reset pre-flight checks -update-cluster-status Remove this node from the ClusterStatus object. +update-cluster-status Remove this node from the ClusterStatus object (DEPRECATED). remove-etcd-member Remove a local etcd member. cleanup-node Run cleanup node. ``` @@ -30,49 +43,49 @@ kubeadm reset [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path to the directory where the certificates are stored. If specified, clean this directory. +

The path to the directory where the certificates are stored. If specified, clean this directory.

--cri-socket string -Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket. +

Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket.

-f, --force -Reset the node without prompting for confirmation. +

Reset the node without prompting for confirmation.

-h, --help -help for reset +

help for reset

---ignore-preflight-errors stringSlice +--ignore-preflight-errors strings -A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks. +

A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

---skip-phases stringSlice +--skip-phases strings -List of phases to be skipped +

List of phases to be skipped

@@ -93,7 +106,7 @@ kubeadm reset [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase.md index 498621b95d..e526dafa1f 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase.md @@ -1,3 +1,16 @@ + + + +Use this command to invoke single phase of the reset workflow ### Synopsis @@ -17,7 +30,7 @@ Use this command to invoke single phase of the reset workflow -h, --help -help for phase +

help for phase

@@ -38,7 +51,7 @@ Use this command to invoke single phase of the reset workflow --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_cleanup-node.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_cleanup-node.md index 84376e67b2..ceabd2045e 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_cleanup-node.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_cleanup-node.md @@ -1,3 +1,16 @@ + + + +Run cleanup node. ### Synopsis @@ -21,21 +34,21 @@ kubeadm reset phase cleanup-node [flags] --cert-dir string     Default: "/etc/kubernetes/pki" -The path to the directory where the certificates are stored. If specified, clean this directory. +

The path to the directory where the certificates are stored. If specified, clean this directory.

--cri-socket string -Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket. +

Path to the CRI socket to connect. If empty kubeadm will try to auto-detect this value; use this option only if you have more than one CRI installed or if you have non-standard CRI socket.

-h, --help -help for cleanup-node +

help for cleanup-node

@@ -56,7 +69,7 @@ kubeadm reset phase cleanup-node [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_preflight.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_preflight.md index 8f3537bc7c..b3d1502184 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_preflight.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_preflight.md @@ -1,3 +1,16 @@ + + + +Run reset pre-flight checks ### Synopsis @@ -21,21 +34,21 @@ kubeadm reset phase preflight [flags] -f, --force -Reset the node without prompting for confirmation. +

Reset the node without prompting for confirmation.

-h, --help -help for preflight +

help for preflight

---ignore-preflight-errors stringSlice +--ignore-preflight-errors strings -A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks. +

A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.

@@ -56,7 +69,7 @@ kubeadm reset phase preflight [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_remove-etcd-member.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_remove-etcd-member.md index c7350d27ca..d2c1060ff4 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_remove-etcd-member.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_remove-etcd-member.md @@ -1,3 +1,16 @@ + + + +Remove a local etcd member. ### Synopsis @@ -21,14 +34,14 @@ kubeadm reset phase remove-etcd-member [flags] -h, --help -help for remove-etcd-member +

help for remove-etcd-member

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -49,7 +62,7 @@ kubeadm reset phase remove-etcd-member [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_update-cluster-status.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_update-cluster-status.md index de4700032b..9d4b7af77f 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_update-cluster-status.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_reset_phase_update-cluster-status.md @@ -1,8 +1,21 @@ + + + +Remove this node from the ClusterStatus object (DEPRECATED). ### Synopsis -Remove this node from the ClusterStatus object if the node is a control plane node. +Remove this node from the ClusterStatus object (DEPRECATED). ``` kubeadm reset phase update-cluster-status [flags] @@ -21,7 +34,7 @@ kubeadm reset phase update-cluster-status [flags] -h, --help -help for update-cluster-status +

help for update-cluster-status

@@ -42,7 +55,7 @@ kubeadm reset phase update-cluster-status [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md index 2662497699..5384fc4d6c 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token.md @@ -1,3 +1,16 @@ + + + +Manage bootstrap tokens ### Synopsis @@ -38,21 +51,21 @@ kubeadm token [flags] --dry-run -Whether to enable dry-run mode or not +

Whether to enable dry-run mode or not

-h, --help -help for token +

help for token

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -73,7 +86,7 @@ kubeadm token [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md index b2212bba44..a2a217033c 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_create.md @@ -1,3 +1,16 @@ + + + +Create bootstrap tokens on the server ### Synopsis @@ -28,56 +41,56 @@ kubeadm token create [token] --certificate-key string -When used together with '--print-join-command', print the full 'kubeadm join' flag needed to join the cluster as a control-plane. To create a new certificate key you must use 'kubeadm init phase upload-certs --upload-certs'. +

When used together with '--print-join-command', print the full 'kubeadm join' flag needed to join the cluster as a control-plane. To create a new certificate key you must use 'kubeadm init phase upload-certs --upload-certs'.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--description string -A human friendly description of how this token is used. +

A human friendly description of how this token is used.

---groups stringSlice     Default: [system:bootstrappers:kubeadm:default-node-token] +--groups strings     Default: "system:bootstrappers:kubeadm:default-node-token" -Extra groups that this token will authenticate as when used for authentication. Must match "\\Asystem:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]\\z" +

Extra groups that this token will authenticate as when used for authentication. Must match "\Asystem:bootstrappers:[a-z0-9:-]{0,255}[a-z0-9]\z"

-h, --help -help for create +

help for create

--print-join-command -Instead of printing only the token, print the full 'kubeadm join' flag needed to join the cluster using the token. +

Instead of printing only the token, print the full 'kubeadm join' flag needed to join the cluster using the token.

--ttl duration     Default: 24h0m0s -The duration before the token is automatically deleted (e.g. 1s, 2m, 3h). If set to '0', the token will never expire +

The duration before the token is automatically deleted (e.g. 1s, 2m, 3h). If set to '0', the token will never expire

---usages stringSlice     Default: [signing,authentication] +--usages strings     Default: "signing,authentication" -Describes the ways in which this token can be used. You can pass --usages multiple times or provide a comma separated list of options. Valid options: [signing,authentication] +

Describes the ways in which this token can be used. You can pass --usages multiple times or provide a comma separated list of options. Valid options: [signing,authentication]

@@ -98,21 +111,21 @@ kubeadm token create [token] --dry-run -Whether to enable dry-run mode or not +

Whether to enable dry-run mode or not

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_delete.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_delete.md index d1ddd8bd2c..2040bd3f94 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_delete.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_delete.md @@ -1,3 +1,16 @@ + + + +Delete bootstrap tokens on the server ### Synopsis @@ -26,7 +39,7 @@ kubeadm token delete [token-value] ... -h, --help -help for delete +

help for delete

@@ -47,21 +60,21 @@ kubeadm token delete [token-value] ... --dry-run -Whether to enable dry-run mode or not +

Whether to enable dry-run mode or not

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_generate.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_generate.md index 72ca0220ee..60de389d6c 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_generate.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_generate.md @@ -1,3 +1,16 @@ + + + +Generate and print a bootstrap token, but do not create it on the server ### Synopsis @@ -31,7 +44,7 @@ kubeadm token generate [flags] -h, --help -help for generate +

help for generate

@@ -52,21 +65,21 @@ kubeadm token generate [flags] --dry-run -Whether to enable dry-run mode or not +

Whether to enable dry-run mode or not

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md index 20ba81f63f..089424492e 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_token_list.md @@ -1,3 +1,16 @@ + + + +List bootstrap tokens on the server ### Synopsis @@ -23,21 +36,28 @@ kubeadm token list [flags] --allow-missing-template-keys     Default: true -If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats. +

If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats.

-o, --experimental-output string     Default: "text" -Output format. One of: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file. +

Output format. One of: text|json|yaml|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file.

-h, --help -help for list +

help for list

+ + + +--show-managed-fields + + +

If true, keep the managedFields when printing objects in JSON or YAML format.

@@ -58,21 +78,21 @@ kubeadm token list [flags] --dry-run -Whether to enable dry-run mode or not +

Whether to enable dry-run mode or not

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md index b3fe44532b..0c2a465194 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade.md @@ -1,3 +1,16 @@ + + + +Upgrade your cluster smoothly to a newer version with this command ### Synopsis @@ -21,7 +34,7 @@ kubeadm upgrade [flags] -h, --help -help for upgrade +

help for upgrade

@@ -42,7 +55,7 @@ kubeadm upgrade [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_apply.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_apply.md index ed6896b0a7..3add5a98c2 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_apply.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_apply.md @@ -1,3 +1,16 @@ + + + +Upgrade your Kubernetes cluster to the specified version ### Synopsis @@ -21,98 +34,98 @@ kubeadm upgrade apply [version] --allow-experimental-upgrades -Show unstable versions of Kubernetes as an upgrade alternative and allow upgrading to an alpha/beta/release candidate versions of Kubernetes. +

Show unstable versions of Kubernetes as an upgrade alternative and allow upgrading to an alpha/beta/release candidate versions of Kubernetes.

--allow-release-candidate-upgrades -Show release candidate versions of Kubernetes as an upgrade alternative and allow upgrading to a release candidate versions of Kubernetes. +

Show release candidate versions of Kubernetes as an upgrade alternative and allow upgrading to a release candidate versions of Kubernetes.

--certificate-renewal     Default: true -Perform the renewal of certificates used by component changed during upgrades. +

Perform the renewal of certificates used by component changed during upgrades.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--dry-run -Do not change any state, just output what actions would be performed. +

Do not change any state, just output what actions would be performed.

--etcd-upgrade     Default: true -Perform the upgrade of etcd. - - - ---experimental-patches string - - -Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically. +

Perform the upgrade of etcd.

--feature-gates string -A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (ALPHA - default=false)
PublicKeysECDSA=true|false (ALPHA - default=false) +

A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (BETA - default=true)
PublicKeysECDSA=true|false (ALPHA - default=false)
RootlessControlPlane=true|false (ALPHA - default=false)

-f, --force -Force upgrading although some requirements might not be met. This also implies non-interactive mode. +

Force upgrading although some requirements might not be met. This also implies non-interactive mode.

-h, --help -help for apply +

help for apply

---ignore-preflight-errors stringSlice +--ignore-preflight-errors strings -A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks. +

A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

+ + + +--patches string + + +

Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "target" can be one of "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically.

--print-config -Specifies whether the configuration file that will be used in the upgrade should be printed or not. +

Specifies whether the configuration file that will be used in the upgrade should be printed or not.

-y, --yes -Perform the upgrade and do not prompt for confirmation (non-interactive mode). +

Perform the upgrade and do not prompt for confirmation (non-interactive mode).

@@ -133,7 +146,7 @@ kubeadm upgrade apply [version] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_diff.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_diff.md index c15b118075..eb5e3c4cac 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_diff.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_diff.md @@ -1,3 +1,16 @@ + + + +Show what differences would be applied to existing static pod manifests. See also: kubeadm upgrade apply --dry-run ### Synopsis @@ -21,49 +34,49 @@ kubeadm upgrade diff [version] [flags] --api-server-manifest string     Default: "/etc/kubernetes/manifests/kube-apiserver.yaml" -path to API server manifest +

path to API server manifest

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

-c, --context-lines int     Default: 3 -How many lines of context in the diff +

How many lines of context in the diff

--controller-manager-manifest string     Default: "/etc/kubernetes/manifests/kube-controller-manager.yaml" -path to controller manifest +

path to controller manifest

-h, --help -help for diff +

help for diff

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--scheduler-manifest string     Default: "/etc/kubernetes/manifests/kube-scheduler.yaml" -path to scheduler manifest +

path to scheduler manifest

@@ -84,7 +97,7 @@ kubeadm upgrade diff [version] [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node.md index b9198f77d7..a8a3138c88 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node.md @@ -1,3 +1,16 @@ + + + +Upgrade commands for a node in the cluster ### Synopsis @@ -29,56 +42,56 @@ kubeadm upgrade node [flags] --certificate-renewal     Default: true -Perform the renewal of certificates used by component changed during upgrades. +

Perform the renewal of certificates used by component changed during upgrades.

--dry-run -Do not change any state, just output the actions that would be performed. +

Do not change any state, just output the actions that would be performed.

--etcd-upgrade     Default: true -Perform the upgrade of etcd. - - - ---experimental-patches string - - -Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically. +

Perform the upgrade of etcd.

-h, --help -help for node +

help for node

---ignore-preflight-errors stringSlice +--ignore-preflight-errors strings -A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks. +

A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

---skip-phases stringSlice +--patches string -List of phases to be skipped +

Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "target" can be one of "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically.

+ + + +--skip-phases strings + + +

List of phases to be skipped

@@ -99,7 +112,7 @@ kubeadm upgrade node [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase.md index 39a2e05ab0..6b86c95054 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase.md @@ -1,3 +1,16 @@ + + + +Use this command to invoke single phase of the node workflow ### Synopsis @@ -17,7 +30,7 @@ Use this command to invoke single phase of the node workflow -h, --help -help for phase +

help for phase

@@ -38,7 +51,7 @@ Use this command to invoke single phase of the node workflow --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_control-plane.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_control-plane.md index 1ca65f50a7..58a6a672e3 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_control-plane.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_control-plane.md @@ -1,3 +1,16 @@ + + + +Upgrade the control plane instance deployed on this node, if any ### Synopsis @@ -21,42 +34,42 @@ kubeadm upgrade node phase control-plane [flags] --certificate-renewal     Default: true -Perform the renewal of certificates used by component changed during upgrades. +

Perform the renewal of certificates used by component changed during upgrades.

--dry-run -Do not change any state, just output the actions that would be performed. +

Do not change any state, just output the actions that would be performed.

--etcd-upgrade     Default: true -Perform the upgrade of etcd. - - - ---experimental-patches string - - -Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically. +

Perform the upgrade of etcd.

-h, --help -help for control-plane +

help for control-plane

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

+ + + +--patches string + + +

Path to a directory that contains files named "target[suffix][+patchtype].extension". For example, "kube-apiserver0+merge.yaml" or just "etcd.json". "target" can be one of "kube-apiserver", "kube-controller-manager", "kube-scheduler", "etcd". "patchtype" can be one of "strategic", "merge" or "json" and they match the patch formats supported by kubectl. The default "patchtype" is "strategic". "extension" must be either "json" or "yaml". "suffix" is an optional string that can be used to determine which patches are applied first alpha-numerically.

@@ -77,7 +90,7 @@ kubeadm upgrade node phase control-plane [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_kubelet-config.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_kubelet-config.md index a4f5ceeafb..d2b03974c2 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_kubelet-config.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_kubelet-config.md @@ -1,3 +1,16 @@ + + + +Upgrade the kubelet configuration for this node ### Synopsis @@ -21,21 +34,21 @@ kubeadm upgrade node phase kubelet-config [flags] --dry-run -Do not change any state, just output the actions that would be performed. +

Do not change any state, just output the actions that would be performed.

-h, --help -help for kubelet-config +

help for kubelet-config

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

@@ -56,7 +69,7 @@ kubeadm upgrade node phase kubelet-config [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_preflight.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_preflight.md index 943e05cb6e..d82a193898 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_preflight.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_node_phase_preflight.md @@ -1,3 +1,16 @@ + + + +Run upgrade node pre-flight checks ### Synopsis @@ -21,14 +34,14 @@ kubeadm upgrade node phase preflight [flags] -h, --help -help for preflight +

help for preflight

---ignore-preflight-errors stringSlice +--ignore-preflight-errors strings -A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks. +

A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.

@@ -49,7 +62,7 @@ kubeadm upgrade node phase preflight [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md index eaa58b588f..c3cc133169 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_upgrade_plan.md @@ -1,3 +1,16 @@ + + + +Check which versions are available to upgrade to and validate whether your current cluster is upgradeable. To skip the internet check, pass in the optional [version] parameter ### Synopsis @@ -21,56 +34,56 @@ kubeadm upgrade plan [version] [flags] --allow-experimental-upgrades -Show unstable versions of Kubernetes as an upgrade alternative and allow upgrading to an alpha/beta/release candidate versions of Kubernetes. +

Show unstable versions of Kubernetes as an upgrade alternative and allow upgrading to an alpha/beta/release candidate versions of Kubernetes.

--allow-release-candidate-upgrades -Show release candidate versions of Kubernetes as an upgrade alternative and allow upgrading to a release candidate versions of Kubernetes. +

Show release candidate versions of Kubernetes as an upgrade alternative and allow upgrading to a release candidate versions of Kubernetes.

--config string -Path to a kubeadm configuration file. +

Path to a kubeadm configuration file.

--feature-gates string -A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (ALPHA - default=false)
PublicKeysECDSA=true|false (ALPHA - default=false) +

A set of key=value pairs that describe feature gates for various features. Options are:
IPv6DualStack=true|false (BETA - default=true)
PublicKeysECDSA=true|false (ALPHA - default=false)
RootlessControlPlane=true|false (ALPHA - default=false)

-h, --help -help for plan +

help for plan

---ignore-preflight-errors stringSlice +--ignore-preflight-errors strings -A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks. +

A list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.

--kubeconfig string     Default: "/etc/kubernetes/admin.conf" -The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file. +

The kubeconfig file to use when talking to the cluster. If the flag is not set, a set of standard locations can be searched for an existing kubeconfig file.

--print-config -Specifies whether the configuration file that will be used in the upgrade should be printed or not. +

Specifies whether the configuration file that will be used in the upgrade should be printed or not.

@@ -91,7 +104,7 @@ kubeadm upgrade plan [version] [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_version.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_version.md index 658075c4ea..b86c725977 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_version.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_version.md @@ -1,3 +1,16 @@ + + + +Print the version of kubeadm ### Synopsis @@ -21,14 +34,14 @@ kubeadm version [flags] -h, --help -help for version +

help for version

-o, --output string -Output format; available options are 'yaml', 'json' and 'short' +

Output format; available options are 'yaml', 'json' and 'short'

@@ -49,7 +62,7 @@ kubeadm version [flags] --rootfs string -[EXPERIMENTAL] The path to the 'real' host root filesystem. +

[EXPERIMENTAL] The path to the 'real' host root filesystem.

diff --git a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md index 7159fc765d..6222685845 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md +++ b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md @@ -298,26 +298,6 @@ Please note that: 2. in case of kubeadm is executed in the `--dry-run` mode, the etcd static Pod manifest is written in a temporary folder 3. Static Pod manifest generation for local etcd can be invoked individually with the [`kubeadm init phase etcd local`](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-etcd) command -### Optional Dynamic Kubelet Configuration - -To use this functionality call `kubeadm alpha kubelet config enable-dynamic`. It writes the kubelet init configuration -into `/var/lib/kubelet/config/init/kubelet` file. - -The init configuration is used for starting the kubelet on this specific node, providing an alternative for the kubelet drop-in file; -such configuration will be replaced by the kubelet base configuration as described in following steps. -See [set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file) for additional information. - -Please note that: - -1. To make dynamic kubelet configuration work, flag `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` should be specified - in `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` -1. The kubelet configuration can be changed by passing a `KubeletConfiguration` object to `kubeadm init` or `kubeadm join` by using - a configuration file `--config some-file.yaml`. The `KubeletConfiguration` object can be separated from other objects such - as `InitConfiguration` using the `---` separator. For more details have a look at the `kubeadm config print-default` command. - -For more details about the `KubeletConfiguration` struct, take a look at the -[`KubeletConfiguration` reference](/docs/reference/config-api/kubelet-config.v1beta1/). - ### Wait for the control plane to come up kubeadm waits (upto 4m0s) until `localhost:6443/healthz` (kube-apiserver liveness) returns `ok`. However in order to detect @@ -327,17 +307,6 @@ deadlock conditions, kubeadm fails fast if `localhost:10255/healthz` (kubelet li kubeadm relies on the kubelet to pull the control plane images and run them properly as static Pods. After the control plane is up, kubeadm completes the tasks described in following paragraphs. -### (optional) Write base kubelet configuration - -{{< feature-state for_k8s_version="v1.11" state="beta" >}} - -If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`: - -1. Write the kubelet base configuration into the `kubelet-base-config-v1.9` ConfigMap in the `kube-system` namespace -2. Creates RBAC rules for granting read access to that ConfigMap to all bootstrap tokens and all kubelet instances - (that is `system:bootstrappers:kubeadm:default-node-token` and `system:nodes` groups) -3. Enable the dynamic kubelet configuration feature for the initial control-plane node by pointing `Node.spec.configSource` to the newly-created ConfigMap - ### Save the kubeadm ClusterConfiguration in a ConfigMap for later reference kubeadm saves the configuration passed to `kubeadm init` in a ConfigMap named `kubeadm-config` under `kube-system` namespace. @@ -440,12 +409,14 @@ A ServiceAccount for `kube-proxy` is created in the `kube-system` namespace; the #### DNS -- In Kubernetes version 1.18 kube-dns usage with kubeadm is deprecated and will be removed in a future release - The CoreDNS service is named `kube-dns`. This is done to prevent any interruption - in service when the user is switching the cluster DNS from kube-dns to CoreDNS or vice-versa - the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) -- A ServiceAccount for CoreDNS/kube-dns is created in the `kube-system` namespace. -- The `kube-dns` ServiceAccount is bound to the privileges in the `system:kube-dns` ClusterRole + in service when the user is switching the cluster DNS from kube-dns to CoreDNS + the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon). +- A ServiceAccount for CoreDNS is created in the `kube-system` namespace. +- The `coredns` ServiceAccount is bound to the privileges in the `system:coredns` ClusterRole + +In Kubernetes version 1.21, support for using `kube-dns` with kubeadm was removed. +You can use CoreDNS with kubeadm even when the related Service is named `kube-dns`. ## kubeadm join phases internal design @@ -518,18 +489,3 @@ Please note that: - The temporary authentication resolve to a user member of `system:bootstrappers:kubeadm:default-node-token` group which was granted access to CSR api during the `kubeadm init` process - The automatic CSR approval is managed by the csrapprover controller, according with configuration done the `kubeadm init` process - -### (optional) Write init kubelet configuration - -{{< feature-state for_k8s_version="v1.11" state="beta" >}} - -If kubeadm is invoked with `--feature-gates=DynamicKubeletConfig`: - -1. Read the kubelet base configuration from the `kubelet-base-config-v1.x` ConfigMap in the `kube-system` namespace using the - Bootstrap Token credentials, and write it to disk as kubelet init configuration file `/var/lib/kubelet/config/init/kubelet` -2. As soon as kubelet starts with the Node's own credential (`/etc/kubernetes/kubelet.conf`), update current node configuration - specifying that the source for the node/kubelet configuration is the above ConfigMap. - -Please note that: - -1. To make dynamic kubelet configuration work, flag `--dynamic-config-dir=/var/lib/kubelet/config/dynamic` should be specified in `/etc/systemd/system/kubelet.service.d/10-kubeadm.conf` diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md index eaef0f5140..dd946c9737 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-alpha.md @@ -9,34 +9,7 @@ weight: 90 from the community. Please try it out and give us feedback! {{< /caution >}} -## kubeadm alpha kubeconfig user {#cmd-phase-kubeconfig} - -The `user` subcommand can be used for the creation of kubeconfig files for additional users. - -{{< tabs name="tab-kubeconfig" >}} -{{< tab name="kubeconfig" include="generated/kubeadm_alpha_kubeconfig.md" />}} -{{< tab name="user" include="generated/kubeadm_alpha_kubeconfig_user.md" />}} -{{< /tabs >}} - -## kubeadm alpha kubelet config {#cmd-phase-kubelet} - -Use the following command to enable the DynamicKubeletConfiguration feature. - -{{< tabs name="tab-kubelet" >}} -{{< tab name="kubelet" include="generated/kubeadm_alpha_kubelet.md" />}} -{{< tab name="enable-dynamic" include="generated/kubeadm_alpha_kubelet_config_enable-dynamic.md" />}} -{{< /tabs >}} - -## kubeadm alpha selfhosting pivot {#cmd-selfhosting} - -The subcommand `pivot` can be used to convert a static Pod-hosted control plane into a self-hosted one. - -[Documentation](/docs/setup/production-environment/tools/kubeadm/self-hosting/) - -{{< tabs name="selfhosting" >}} -{{< tab name="selfhosting" include="generated/kubeadm_alpha_selfhosting.md" />}} -{{< tab name="pivot" include="generated/kubeadm_alpha_selfhosting_pivot.md" />}} -{{< /tabs >}} +Currently there are no experimental commands under `kubeadm alpha`. ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md index 23dff658e9..76d9921be1 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-config.md @@ -10,7 +10,7 @@ weight: 50 During `kubeadm init`, kubeadm uploads the `ClusterConfiguration` object to your cluster in a ConfigMap called `kubeadm-config` in the `kube-system` namespace. This configuration is then read during -`kubeadm join`, `kubeadm reset` and `kubeadm upgrade`. To view this ConfigMap call `kubeadm config view`. +`kubeadm join`, `kubeadm reset` and `kubeadm upgrade`. You can use `kubeadm config print` to print the default configuration and `kubeadm config migrate` to convert your old configuration files to a newer version. `kubeadm config images list` and @@ -20,14 +20,17 @@ For more information navigate to [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file) or [Using kubeadm join with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-join/#config-file). +You can also configure several kubelet-configuration options with `kubeadm init`. These options will be the same on any node in your cluster. +See [Configuring each kubelet in your cluster using kubeadm](/docs/setup/production-environment/tools/kubeadm/kubelet-integration/) for details. + In Kubernetes v1.13.0 and later to list/pull kube-dns images instead of the CoreDNS image the `--config` method described [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon) has to be used. -## kubeadm config view {#cmd-config-view} +## kubeadm config print {#cmd-config-print} -{{< include "generated/kubeadm_config_view.md" >}} +{{< include "generated/kubeadm_config_print.md" >}} ## kubeadm config print init-defaults {#cmd-config-print-init-defaults} diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md index 21ab7a863d..3f9812b260 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init-phase.md @@ -119,16 +119,16 @@ Use the following phase to configure bootstrap tokens. {{< tab name="bootstrap-token" include="generated/kubeadm_init_phase_bootstrap-token.md" />}} {{< /tabs >}} -## kubeadm init phase kubelet-finialize {#cmd-phase-kubelet-finalize-all} +## kubeadm init phase kubelet-finalize {#cmd-phase-kubelet-finalize-all} Use the following phase to update settings relevant to the kubelet after TLS bootstrap. You can use the `all` subcommand to run all `kubelet-finalize` phases. {{< tabs name="tab-kubelet-finalize" >}} -{{< tab name="kublet-finalize" include="generated/kubeadm_init_phase_kubelet-finalize.md" />}} -{{< tab name="kublet-finalize-all" include="generated/kubeadm_init_phase_kubelet-finalize_all.md" />}} -{{< tab name="kublet-finalize-cert-rotation" include="generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md" />}} +{{< tab name="kubelet-finalize" include="generated/kubeadm_init_phase_kubelet-finalize.md" />}} +{{< tab name="kubelet-finalize-all" include="generated/kubeadm_init_phase_kubelet-finalize_all.md" />}} +{{< tab name="kubelet-finalize-cert-rotation" include="generated/kubeadm_init_phase_kubelet-finalize_experimental-cert-rotation.md" />}} {{< /tabs >}} ## kubeadm init phase addon {#cmd-phase-addon} @@ -143,27 +143,8 @@ install them selectively. {{< tab name="kube-proxy" include="generated/kubeadm_init_phase_addon_kube-proxy.md" />}} {{< /tabs >}} -To use kube-dns instead of CoreDNS you have to pass a configuration file: - -```bash -# for installing a DNS addon only -kubeadm init phase addon coredns --config=someconfig.yaml -``` - -The file has to contain a [`dns`](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2#DNS) field in[`ClusterConfiguration`](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2#ClusterConfiguration) -and also a type for the addon - `kube-dns` (default value is `CoreDNS`). - -```yaml -apiVersion: kubeadm.k8s.io/v1beta2 -kind: ClusterConfiguration -dns: - type: "kube-dns" -``` - -Please note that kube-dns usage with kubeadm is deprecated as of v1.18 and will be removed in a future release. - -For more details on each field in the `v1beta2` configuration you can navigate to our -[API reference pages.] (https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) +For more details on each field in the `v1beta3` configuration you can navigate to our +[API reference pages.](/docs/reference/config-api/kubeadm-config.v1beta3/) ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md index c33a195120..3779ec2fdf 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md @@ -66,12 +66,10 @@ following steps: 1. Installs a DNS server (CoreDNS) and the kube-proxy addon components via the API server. In Kubernetes version 1.11 and later CoreDNS is the default DNS server. - To install kube-dns instead of CoreDNS, the DNS addon has to be configured in the kubeadm `ClusterConfiguration`. - For more information about the configuration see the section `Using kubeadm init with a configuration file` below. Please note that although the DNS server is deployed, it will not be scheduled until CNI is installed. {{< warning >}} - kube-dns usage with kubeadm is deprecated as of v1.18 and will be removed in a future release. + kube-dns usage with kubeadm is deprecated as of v1.18 and is removed in v1.21. {{< /warning >}} ### Using init phases with kubeadm {#init-phases} @@ -106,6 +104,10 @@ sudo kubeadm init --skip-phases=control-plane,etcd --config=configfile.yaml What this example would do is write the manifest files for the control plane and etcd in `/etc/kubernetes/manifests` based on the configuration in `configfile.yaml`. This allows you to modify the files and then skip these phases using `--skip-phases`. By calling the last command you will create a control plane node with the custom manifest files. +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +Alternatively, you can use the `skipPhases` field under `InitConfiguration`. + ### Using kubeadm init with a configuration file {#config-file} {{< caution >}} @@ -124,8 +126,8 @@ The default configuration can be printed out using the If your configuration is not using the latest version it is **recommended** that you migrate using the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command. -For more information on the fields and usage of the configuration you can navigate to our API reference -page and pick a version from [the list](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories). +For more information on the fields and usage of the configuration you can navigate to our +[API reference page](/docs/reference/config-api/kubeadm-config.v1beta2/). ### Adding kube-proxy parameters {#kube-proxy} @@ -144,7 +146,7 @@ For information about passing flags to control plane components see: By default, kubeadm pulls images from `k8s.gcr.io`. If the requested Kubernetes version is a CI label (such as `ci/latest`) -`gcr.io/kubernetes-ci-images` is used. +`gcr.io/k8s-staging-ci-images` is used. You can override this behavior by using [kubeadm with a configuration file](#config-file). Allowed customization are: diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md index 53ca4a789b..5ad349e66c 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md @@ -66,6 +66,10 @@ For example: sudo kubeadm join --skip-phases=preflight --config=config.yaml ``` +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +Alternatively, you can use the `skipPhases` field in `JoinConfiguration`. + ### Discovering what cluster CA to trust The kubeadm discovery has several options, each with security tradeoffs. @@ -282,8 +286,8 @@ The default configuration can be printed out using the If your configuration is not using the latest version it is **recommended** that you migrate using the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command. -For more information on the fields and usage of the configuration you can navigate to our API reference -page and pick a version from [the list](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories). +For more information on the fields and usage of the configuration you can navigate to our +[API reference](/docs/reference/config-api/kubeadm-config.v1beta2/). ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig.md new file mode 100644 index 0000000000..f912285f7d --- /dev/null +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig.md @@ -0,0 +1,21 @@ +--- +title: kubeadm kubeconfig +content_type: concept +weight: 90 +--- + +`kubeadm kubeconfig` provides utilities for managing kubeconfig files. + +## kubeadm kubeconfig {#cmd-kubeconfig} + +{{< tabs name="tab-kubeconfig" >}} +{{< tab name="overview" include="generated/kubeadm_kubeconfig.md" />}} +{{< /tabs >}} + +## kubeadm kubeconfig user {#cmd-kubeconfig-user} + +This command can be used to output a kubeconfig file for an additional user. + +{{< tabs name="tab-kubeconfig-user" >}} +{{< tab name="user" include="generated/kubeadm_kubeconfig_user.md" />}} +{{< /tabs >}} \ No newline at end of file diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md index 5796e7aec7..6a2c5f782f 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md @@ -20,8 +20,6 @@ For older versions of kubeadm, please refer to older documentation sets of the K You can use `kubeadm upgrade diff` to see the changes that would be applied to static pod manifests. -To use kube-dns with upgrades in Kubernetes v1.13.0 and later please follow [this guide](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase/#cmd-phase-addon). - In Kubernetes v1.15.0 and later, `kubeadm upgrade apply` and `kubeadm upgrade node` will also automatically renew the kubeadm managed certificates on this node, including those stored in kubeconfig files. To opt-out, it is possible to pass the flag `--certificate-renewal=false`. For more details about certificate diff --git a/content/en/docs/reference/tools/_index.md b/content/en/docs/reference/tools/_index.md index c8d42be352..f719515af7 100644 --- a/content/en/docs/reference/tools/_index.md +++ b/content/en/docs/reference/tools/_index.md @@ -10,9 +10,7 @@ no_list: true Kubernetes contains several tools to help you work with the Kubernetes system. - -{{% thirdparty-content %}} ## Minikube @@ -25,12 +23,13 @@ development and testing purposes. [`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/), the web-based user interface of Kubernetes, allows you to deploy containerized applications to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself. +{{% thirdparty-content %}} ## Helm -[`Kubernetes Helm`](https://github.com/kubernetes/helm) is a tool for managing packages of pre-configured -Kubernetes resources, aka Kubernetes charts. +[Helm](https://helm.sh/) is a tool for managing packages of pre-configured +Kubernetes resources. These packages are known as _Helm charts_. -Beware Helm is a third party managed tool for managing packages of pre-configured +Helm is a third party managed tool for managing packages of pre-configured Kubernetes resources, aka Kubernetes charts. Use Helm to: diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index e517a13d52..913d3db42e 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -49,7 +49,7 @@ Some resource types will have one or more sub-resources, represented as sub path * Cluster-scoped subresource: `GET /apis/GROUP/VERSION/RESOURCETYPE/NAME/SUBRESOURCE` * Namespace-scoped subresource: `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME/SUBRESOURCE` -The verbs supported for each subresource will differ depending on the object - see the API documentation more information. It is not possible to access sub-resources across multiple resources - generally a new virtual resource type would be used if that becomes necessary. +The verbs supported for each subresource will differ depending on the object - see the API documentation for more information. It is not possible to access sub-resources across multiple resources - generally a new virtual resource type would be used if that becomes necessary. ## Efficient detection of changes @@ -192,7 +192,92 @@ For example, if there are 1,253 pods on the cluster and the client wants to rece } ``` -Note that the `resourceVersion` of the list remains constant across each request, indicating the server is showing us a consistent snapshot of the pods. Pods that are created, updated, or deleted after version `10245` would not be shown unless the user makes a list request without the `continue` token. This allows clients to break large requests into smaller chunks and then perform a watch operation on the full set without missing any updates. +Note that the `resourceVersion` of the list remains constant across each request, +indicating the server is showing us a consistent snapshot of the pods. Pods that +are created, updated, or deleted after version `10245` would not be shown unless +the user makes a list request without the `continue` token. This allows clients +to break large requests into smaller chunks and then perform a watch operation +on the full set without missing any updates. + +`remainingItemCount` is the number of subsequent items in the list which are not +included in this list response. If the list request contained label or field selectors, +then the number of remaining items is unknown and the API server does not include +a `remainingItemCount` field in its response. If the list is complete (either +because it is not chunking or because this is the last chunk), then there are no +more remaining items and the API server does not include a `remainingItemCount` +field in its response. The intended use of the `remainingItemCount` is estimating +the size of a collection. + +## Lists + +There are dozens of list types (such as `PodList`, `ServiceList`, and `NodeList`) defined in the Kubernetes API. +You can get more information about each list type from the [Kubernetes API](/docs/reference/kubernetes-api/) documentation. + +When you query the API for a particular type, all items returned by that query are of that type. For example, when you +ask for a list of services, the list type is shown as `kind: ServiceList` and each item in that list represents a single Service. For example: + +```console + +GET /api/v1/services +--- +{ + "kind": "ServiceList", + "apiVersion": "v1", + "metadata": { + "resourceVersion": "2947301" + }, + "items": [ + { + "metadata": { + "name": "kubernetes", + "namespace": "default", +... + "metadata": { + "name": "kube-dns", + "namespace": "kube-system", +... +``` + +Some tools, such as `kubectl` provide another way to query the Kubernetes API. Because the output of `kubectl` might include multiple list types, the list of items is represented as `kind: List`. For example: + +```console + +$ kubectl get services -A -o yaml + +apiVersion: v1 +kind: List +metadata: + resourceVersion: "" + selfLink: "" +items: +- apiVersion: v1 + kind: Service + metadata: + creationTimestamp: "2021-06-03T14:54:12Z" + labels: + component: apiserver + provider: kubernetes + name: kubernetes + namespace: default +... +- apiVersion: v1 + kind: Service + metadata: + annotations: + prometheus.io/port: "9153" + prometheus.io/scrape: "true" + creationTimestamp: "2021-06-03T14:54:14Z" + labels: + k8s-app: kube-dns + kubernetes.io/cluster-service: "true" + kubernetes.io/name: CoreDNS + name: kube-dns + namespace: kube-system +``` + +{{< note >}} +Keep in mind that the Kubernetes API does not have a `kind: List` type. `kind: List` is an internal mechanism type for lists of mixed resources and should not be depended upon. +{{< /note >}} ## Receiving resources as Tables @@ -442,7 +527,7 @@ feature, see the section on ## Resource Versions -Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource version for equality (i.e. must not compare resource versions for greater-than or less-than relationships). +Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource versions for equality (i.e. must not compare resource versions for greater-than or less-than relationships). ### ResourceVersion in metadata @@ -454,7 +539,7 @@ Clients find resource versions in resources, including the resources in watch ev ### The ResourceVersion Parameter -The get, list and watch operations support the `resourceVersion` parameter. +The get, list, and watch operations support the `resourceVersion` parameter. The exact meaning of this parameter differs depending on the operation and the value of `resourceVersion`. diff --git a/content/en/docs/reference/using-api/client-libraries.md b/content/en/docs/reference/using-api/client-libraries.md index a484c8e74f..eed8169909 100644 --- a/content/en/docs/reference/using-api/client-libraries.md +++ b/content/en/docs/reference/using-api/client-libraries.md @@ -30,13 +30,12 @@ The following client libraries are officially maintained by | Language | Client Library | Sample Programs | |----------|----------------|-----------------| -| Go | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [browse](https://github.com/kubernetes/client-go/tree/master/examples) -| Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [browse](https://github.com/kubernetes-client/python/tree/master/examples) -| Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [browse](https://github.com/kubernetes-client/java#installation) | dotnet | [github.com/kubernetes-client/csharp](https://github.com/kubernetes-client/csharp) | [browse](https://github.com/kubernetes-client/csharp/tree/master/examples/simple) -| JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [browse](https://github.com/kubernetes-client/javascript/tree/master/examples) +| Go | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [browse](https://github.com/kubernetes/client-go/tree/master/examples) | Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | [browse](https://github.com/kubernetes-client/haskell/tree/master/kubernetes-client/example) - +| Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [browse](https://github.com/kubernetes-client/java#installation) +| JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [browse](https://github.com/kubernetes-client/javascript/tree/master/examples) +| Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [browse](https://github.com/kubernetes-client/python/tree/master/examples) ## Community-maintained client libraries @@ -48,6 +47,10 @@ their authors, not the Kubernetes team. | Language | Client Library | | -------------------- | ---------------------------------------- | | Clojure | [github.com/yanatan16/clj-kubernetes-api](https://github.com/yanatan16/clj-kubernetes-api) | +| DotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | +| DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | +| Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) | +| Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) | | Go | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) | | Java (OSGi) | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) | | Java (Fabric8, OSGi) | [github.com/fabric8io/kubernetes-client](https://github.com/fabric8io/kubernetes-client) | @@ -63,23 +66,16 @@ their authors, not the Kubernetes team. | PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) | | PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) | | PHP | [github.com/renoki-co/php-k8s](https://github.com/renoki-co/php-k8s) | -| Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) | | Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) | | Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) | | Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) | | Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) | | Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | | Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | +| Ruby | [github.com/k8s-ruby/k8s-ruby](https://github.com/k8s-ruby/k8s-ruby) | | Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) | | Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) | | Rust | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) | | Scala | [github.com/hagay3/skuber](https://github.com/hagay3/skuber) | | Scala | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) | | Swift | [github.com/swiftkube/client](https://github.com/swiftkube/client) | -| DotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | -| DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | -| Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) | -| Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) | - - - diff --git a/content/en/docs/reference/using-api/deprecation-guide.md b/content/en/docs/reference/using-api/deprecation-guide.md old mode 100755 new mode 100644 index a8ad3494bd..579e4c04ac --- a/content/en/docs/reference/using-api/deprecation-guide.md +++ b/content/en/docs/reference/using-api/deprecation-guide.md @@ -25,6 +25,25 @@ deprecated API versions to newer and more stable API versions. The **v1.25** release will stop serving the following deprecated API versions: +#### CronJob {#cronjob-v125} + +The **batch/v1beta1** API version of CronJob will no longer be served in v1.25. + +* Migrate manifests and API clients to use the **batch/v1** API version, available since v1.21. +* All existing persisted objects are accessible via the new API +* No notable changes + +#### EndpointSlice {#endpointslice-v125} + +The **discovery.k8s.io/v1beta1** API version of EndpointSlice will no longer be served in v1.25. + +* Migrate manifests and API clients to use the **discovery.k8s.io/v1** API version, available since v1.21. +* All existing persisted objects are accessible via the new API +* Notable changes in **discovery.k8s.io/v1**: + * use per Endpoint `nodeName` field instead of deprecated `topology["kubernetes.io/hostname"]` field + * use per Endpoint `zone` field instead of deprecated `topology["topology.kubernetes.io/zone"]` field + * `topology` is replaced with the `deprecatedTopology` field which is not writable in v1 + #### Event {#event-v125} The **events.k8s.io/v1beta1** API version of Event will no longer be served in v1.25. @@ -34,13 +53,29 @@ The **events.k8s.io/v1beta1** API version of Event will no longer be served in v * Notable changes in **events.k8s.io/v1**: * `type` is limited to `Normal` and `Warning` * `involvedObject` is renamed to `regarding` - * `action`, `reason`, `reportingComponent`, and `reportingInstance` are required when creating new **events.k8s.io/v1** Events + * `action`, `reason`, `reportingController`, and `reportingInstance` are required when creating new **events.k8s.io/v1** Events * use `eventTime` instead of the deprecated `firstTimestamp` field (which is renamed to `deprecatedFirstTimestamp` and not permitted in new **events.k8s.io/v1** Events) * use `series.lastObservedTime` instead of the deprecated `lastTimestamp` field (which is renamed to `deprecatedLastTimestamp` and not permitted in new **events.k8s.io/v1** Events) * use `series.count` instead of the deprecated `count` field (which is renamed to `deprecatedCount` and not permitted in new **events.k8s.io/v1** Events) - * use `reportingComponent` instead of the deprecated `source.component` field (which is renamed to `deprecatedSource.component` and not permitted in new **events.k8s.io/v1** Events) + * use `reportingController` instead of the deprecated `source.component` field (which is renamed to `deprecatedSource.component` and not permitted in new **events.k8s.io/v1** Events) * use `reportingInstance` instead of the deprecated `source.host` field (which is renamed to `deprecatedSource.host` and not permitted in new **events.k8s.io/v1** Events) +#### PodDisruptionBudget {#poddisruptionbudget-v125} + +The **policy/v1beta1** API version of PodDisruptionBudget will no longer be served in v1.25. + +* Migrate manifests and API clients to use the **policy/v1** API version, available since v1.21. +* All existing persisted objects are accessible via the new API +* Notable changes in **policy/v1**: + * an empty `spec.selector` (`{}`) written to a `policy/v1` PodDisruptionBudget selects all pods in the namespace (in `policy/v1beta1` an empty `spec.selector` selected no pods). An unset `spec.selector` selects no pods in either API version. + +#### PodSecurityPolicy {#psp-v125} + +PodSecurityPolicy in the **policy/v1beta1** API version will no longer be served in v1.25, and the PodSecurityPolicy admission controller will be removed. + +PodSecurityPolicy replacements are still under discussion, but current use can be migrated to +[3rd-party admission webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/) now. + #### RuntimeClass {#runtimeclass-v125} RuntimeClass in the **node.k8s.io/v1beta1** API version will no longer be served in v1.25. @@ -51,11 +86,11 @@ RuntimeClass in the **node.k8s.io/v1beta1** API version will no longer be served ### v1.22 -The **v1.22** release will stop serving the following deprecated API versions: +The **v1.22** release stopped serving the following deprecated API versions: #### Webhook resources {#webhook-resources-v122} -The **admissionregistration.k8s.io/v1beta1** API version of MutatingWebhookConfiguration and ValidatingWebhookConfiguration will no longer be served in v1.22. +The **admissionregistration.k8s.io/v1beta1** API version of MutatingWebhookConfiguration and ValidatingWebhookConfiguration is no longer served as of v1.22. * Migrate manifests and API clients to use the **admissionregistration.k8s.io/v1** API version, available since v1.16. * All existing persisted objects are accessible via the new APIs @@ -69,7 +104,7 @@ The **admissionregistration.k8s.io/v1beta1** API version of MutatingWebhookConfi #### CustomResourceDefinition {#customresourcedefinition-v122} -The **apiextensions.k8s.io/v1beta1** API version of CustomResourceDefinition will no longer be served in v1.22. +The **apiextensions.k8s.io/v1beta1** API version of CustomResourceDefinition is no longer served as of v1.22. * Migrate manifests and API clients to use the **apiextensions.k8s.io/v1** API version, available since v1.16. * All existing persisted objects are accessible via the new API @@ -87,7 +122,7 @@ The **apiextensions.k8s.io/v1beta1** API version of CustomResourceDefinition wil #### APIService {#apiservice-v122} -The **apiregistration.k8s.io/v1beta1** API version of APIService will no longer be served in v1.22. +The **apiregistration.k8s.io/v1beta1** API version of APIService is no longer served as of v1.22. * Migrate manifests and API clients to use the **apiregistration.k8s.io/v1** API version, available since v1.10. * All existing persisted objects are accessible via the new API @@ -95,14 +130,14 @@ The **apiregistration.k8s.io/v1beta1** API version of APIService will no longer #### TokenReview {#tokenreview-v122} -The **authentication.k8s.io/v1beta1** API version of TokenReview will no longer be served in v1.22. +The **authentication.k8s.io/v1beta1** API version of TokenReview is no longer served as of v1.22. * Migrate manifests and API clients to use the **authentication.k8s.io/v1** API version, available since v1.6. * No notable changes #### SubjectAccessReview resources {#subjectaccessreview-resources-v122} -The **authorization.k8s.io/v1beta1** API version of LocalSubjectAccessReview, SelfSubjectAccessReview, and SubjectAccessReview will no longer be served in v1.22. +The **authorization.k8s.io/v1beta1** API version of LocalSubjectAccessReview, SelfSubjectAccessReview, and SubjectAccessReview is no longer served as of v1.22. * Migrate manifests and API clients to use the **authorization.k8s.io/v1** API version, available since v1.6. * Notable changes: @@ -110,7 +145,7 @@ The **authorization.k8s.io/v1beta1** API version of LocalSubjectAccessReview, Se #### CertificateSigningRequest {#certificatesigningrequest-v122} -The **certificates.k8s.io/v1beta1** API version of CertificateSigningRequest will no longer be served in v1.22. +The **certificates.k8s.io/v1beta1** API version of CertificateSigningRequest is no longer served as of v1.22. * Migrate manifests and API clients to use the **certificates.k8s.io/v1** API version, available since v1.19. * All existing persisted objects are accessible via the new API @@ -125,7 +160,7 @@ The **certificates.k8s.io/v1beta1** API version of CertificateSigningRequest wil #### Lease {#lease-v122} -The **coordination.k8s.io/v1beta1** API version of Lease will no longer be served in v1.22. +The **coordination.k8s.io/v1beta1** API version of Lease is no longer served as of v1.22. * Migrate manifests and API clients to use the **coordination.k8s.io/v1** API version, available since v1.14. * All existing persisted objects are accessible via the new API @@ -133,7 +168,7 @@ The **coordination.k8s.io/v1beta1** API version of Lease will no longer be serve #### Ingress {#ingress-v122} -The **extensions/v1beta1** and **networking.k8s.io/v1beta1** API versions of Ingress will no longer be served in v1.22. +The **extensions/v1beta1** and **networking.k8s.io/v1beta1** API versions of Ingress is no longer served as of v1.22. * Migrate manifests and API clients to use the **networking.k8s.io/v1** API version, available since v1.19. * All existing persisted objects are accessible via the new API @@ -146,7 +181,7 @@ The **extensions/v1beta1** and **networking.k8s.io/v1beta1** API versions of Ing #### IngressClass {#ingressclass-v122} -The **networking.k8s.io/v1beta1** API version of IngressClass will no longer be served in v1.22. +The **networking.k8s.io/v1beta1** API version of IngressClass is no longer served as of v1.22. * Migrate manifests and API clients to use the **networking.k8s.io/v1** API version, available since v1.19. * All existing persisted objects are accessible via the new API @@ -154,7 +189,7 @@ The **networking.k8s.io/v1beta1** API version of IngressClass will no longer be #### RBAC resources {#rbac-resources-v122} -The **rbac.authorization.k8s.io/v1beta1** API version of ClusterRole, ClusterRoleBinding, Role, and RoleBinding will no longer be served in v1.22. +The **rbac.authorization.k8s.io/v1beta1** API version of ClusterRole, ClusterRoleBinding, Role, and RoleBinding is no longer served as of v1.22. * Migrate manifests and API clients to use the **rbac.authorization.k8s.io/v1** API version, available since v1.8. * All existing persisted objects are accessible via the new APIs @@ -162,7 +197,7 @@ The **rbac.authorization.k8s.io/v1beta1** API version of ClusterRole, ClusterRol #### PriorityClass {#priorityclass-v122} -The **scheduling.k8s.io/v1beta1** API version of PriorityClass will no longer be served in v1.22. +The **scheduling.k8s.io/v1beta1** API version of PriorityClass is no longer served as of v1.22. * Migrate manifests and API clients to use the **scheduling.k8s.io/v1** API version, available since v1.14. * All existing persisted objects are accessible via the new API @@ -170,7 +205,7 @@ The **scheduling.k8s.io/v1beta1** API version of PriorityClass will no longer be #### Storage resources {#storage-resources-v122} -The **storage.k8s.io/v1beta1** API version of CSIDriver, CSINode, StorageClass, and VolumeAttachment will no longer be served in v1.22. +The **storage.k8s.io/v1beta1** API version of CSIDriver, CSINode, StorageClass, and VolumeAttachment is no longer served as of v1.22. * Migrate manifests and API clients to use the **storage.k8s.io/v1** API version * CSIDriver is available in **storage.k8s.io/v1** since v1.19. @@ -234,6 +269,13 @@ The **extensions/v1beta1**, **apps/v1beta1**, and **apps/v1beta2** API versions * Notable changes: * `spec.selector` is now required and immutable after creation; use the existing template labels as the selector for seamless upgrades +#### PodSecurityPolicy {#psp-v116} + +The **extensions/v1beta1** API version of PodSecurityPolicy is no longer served as of v1.16. + +* Migrate manifests and API client to use the **policy/v1beta1** API version, available since v1.10. +* Note that the **policy/v1beta1** API version of PodSecurityPolicy will be removed in v1.25. + ## What to do ### Test with deprecated APIs disabled diff --git a/content/en/docs/reference/using-api/deprecation-policy.md b/content/en/docs/reference/using-api/deprecation-policy.md index 4de09ee82a..6bbd9be9e1 100644 --- a/content/en/docs/reference/using-api/deprecation-policy.md +++ b/content/en/docs/reference/using-api/deprecation-policy.md @@ -109,7 +109,7 @@ objects. All of this is best illustrated by examples. Imagine a Kubernetes release, version X, which introduces a new API group. A new Kubernetes release is made -every approximately 3 months (4 per year). The following table describes which +every approximately 4 months (3 per year). The following table describes which API versions are supported in a series of subsequent releases. @@ -301,7 +301,7 @@ Starting in Kubernetes v1.19, making an API request to a deprecated REST API end 1. Returns a `Warning` header (as defined in [RFC7234, Section 5.5](https://tools.ietf.org/html/rfc7234#section-5.5)) in the API response. 2. Adds a `"k8s.io/deprecated":"true"` annotation to the [audit event](/docs/tasks/debug-application-cluster/audit/) recorded for the request. -3. Sets an `apiserver_requested_deprecated_apis` gauge metric to `1` in the `kube-apiserver` +3. Sets an `apiserver_requested_deprecated_apis` gauge metric to `1` in the `kube-apiserver` process. The metric has labels for `group`, `version`, `resource`, `subresource` that can be joined to the `apiserver_request_total` metric, and a `removed_release` label that indicates the Kubernetes release in which the API will no longer be served. The following Prometheus query @@ -428,6 +428,46 @@ transitions a lifecycle stage as follows. Feature gates must function for no les is deprecated it must be documented in both in the release notes and the corresponding CLI help. Both warnings and documentation must indicate whether a feature gate is non-operational.** +## Deprecating a metric + +Each component of the Kubernetes control-plane exposes metrics (usually the +`/metrics` endpoint), which are typically ingested by cluster administrators. +Not all metrics are the same: some metrics are commonly used as SLIs or used +to determine SLOs, these tend to have greater import. Other metrics are more +experimental in nature or are used primarily in the Kubernetes development +process. + +Accordingly, metrics fall under two stability classes (`ALPHA` and `STABLE`); +this impacts removal of a metric during a Kubernetes release. These classes +are determined by the perceived importance of the metric. The rules for +deprecating and removing a metric are as follows: + +**Rule #9a: Metrics, for the corresponding stability class, must function for no less than:** + + * **STABLE: 4 releases or 12 months (whichever is longer)** + * **ALPHA: 0 releases** + +**Rule #9b: Metrics, after their _announced deprecation_, must function for no less than:** + + * **STABLE: 3 releases or 9 months (whichever is longer)** + * **ALPHA: 0 releases** + +Deprecated metrics will have their description text prefixed with a deprecation notice +string '(Deprecated from x.y)' and a warning log will be emitted during metric +registration. Like their stable undeprecated counterparts, deprecated metrics will +be automatically registered to the metrics endpoint and therefore visible. + +On a subsequent release (when the metric's `deprecatedVersion` is equal to +_current_kubernetes_version - 3_)), a deprecated metric will become a _hidden_ metric. +**_Unlike_** their deprecated counterparts, hidden metrics will _no longer_ be +automatically registered to the metrics endpoint (hence hidden). However, they +can be explicitly enabled through a command line flag on the binary +(`--show-hidden-metrics-for-version=`). This provides cluster admins an +escape hatch to properly migrate off of a deprecated metric, if they were not +able to react to the earlier deprecation warnings. Hidden metrics should be +deleted after one release. + + ## Exceptions No policy can cover every possible situation. This policy is a living @@ -438,4 +478,3 @@ leaders to find the best solutions for those specific cases, always bearing in mind that Kubernetes is committed to being a stable system that, as much as possible, never breaks users. Exceptions will always be announced in all relevant release notes. - diff --git a/content/en/docs/reference/using-api/health-checks.md b/content/en/docs/reference/using-api/health-checks.md index 2c315505db..e4ce50f30d 100644 --- a/content/en/docs/reference/using-api/health-checks.md +++ b/content/en/docs/reference/using-api/health-checks.md @@ -18,14 +18,14 @@ The Kubernetes API server provides 3 API endpoints (`healthz`, `livez` and `read The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should use the more specific `livez` and `readyz` endpoints instead. The `livez` endpoint can be used with the `--livez-grace-period` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) to specify the startup duration. For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint. -Machines that check the `health`/`livez`/`readyz` of the API server should rely on the HTTP status code. +Machines that check the `healthz`/`livez`/`readyz` of the API server should rely on the HTTP status code. A status code `200` indicates the API server is `healthy`/`live`/`ready`, depending of the called endpoint. The more verbose options shown below are intended to be used by human operators to debug their cluster or specially the state of the API server. The following examples will show how you can interact with the health API endpoints. For all endpoints you can use the `verbose` parameter to print out the checks and their status. -This can be useful for a human operator to debug the current status of the Api server, it is not intended to be consumed by a machine: +This can be useful for a human operator to debug the current status of the API server, it is not intended to be consumed by a machine: ```shell curl -k https://localhost:6443/livez?verbose @@ -93,7 +93,7 @@ The output show that the `etcd` check is excluded: {{< feature-state state="alpha" >}} -Each individual health check exposes an http endpoint and could can be checked individually. +Each individual health check exposes an HTTP endpoint and could can be checked individually. The schema for the individual health checks is `/livez/` where `livez` and `readyz` and be used to indicate if you want to check the liveness or the readiness of the API server. The `` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`. These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system: diff --git a/content/en/docs/reference/using-api/server-side-apply.md b/content/en/docs/reference/using-api/server-side-apply.md index 81afa5b567..60acb02f7d 100644 --- a/content/en/docs/reference/using-api/server-side-apply.md +++ b/content/en/docs/reference/using-api/server-side-apply.md @@ -12,7 +12,7 @@ min-kubernetes-server-version: 1.16 -{{< feature-state for_k8s_version="v1.16" state="beta" >}} +{{< feature-state for_k8s_version="v1.22" state="stable" >}} ## Introduction @@ -224,17 +224,75 @@ merging, see A number of markers were added in Kubernetes 1.16 and 1.17, to allow API developers to describe the merge strategy supported by lists, maps, and structs. These markers can be applied to objects of the respective type, -in Go files or in the OpenAPI schema definition of the +in Go files or in the OpenAPI schema definition of the [CRD](/docs/reference/generated/kubernetes-api/{{< param "version" >}}#jsonschemaprops-v1-apiextensions-k8s-io): | Golang marker | OpenAPI extension | Accepted values | Description | Introduced in | |---|---|---|---|---| -| `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | Applicable to lists. `atomic` and `set` apply to lists with scalar elements only. `map` applies to lists of nested types only. If configured as `atomic`, the entire list is replaced during merge; a single manager manages the list as a whole at any one time. If `set` or `map`, different managers can manage entries separately. | 1.16 | -| `//+listMapKey` | `x-kubernetes-list-map-keys` | Slice of map keys that uniquely identify entries for example `["port", "protocol"]` | Only applicable when `+listType=map`. A slice of strings whose values in combination must uniquely identify list entries. While there can be multiple keys, `listMapKey` is singular because keys need to be specified individually in the Go type. | 1.16 | +| `//+listType` | `x-kubernetes-list-type` | `atomic`/`set`/`map` | Applicable to lists. `set` applies to lists that include only scalar elements. These elements must be unique. `map` applies to lists of nested types only. The key values (see `listMapKey`) must be unique in the list. `atomic` can apply to any list. If configured as `atomic`, the entire list is replaced during merge. At any point in time, a single manager owns the list. If `set` or `map`, different managers can manage entries separately. | 1.16 | +| `//+listMapKey` | `x-kubernetes-list-map-keys` | List of field names, e.g. `["port", "protocol"]` | Only applicable when `+listType=map`. A list of field names whose values uniquely identify entries in the list. While there can be multiple keys, `listMapKey` is singular because keys need to be specified individually in the Go type. The key fields must be scalars. | 1.16 | | `//+mapType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to maps. `atomic` means that the map can only be entirely replaced by a single manager. `granular` means that the map supports separate managers updating individual fields. | 1.17 | | `//+structType` | `x-kubernetes-map-type` | `atomic`/`granular` | Applicable to structs; otherwise same usage and OpenAPI annotation as `//+mapType`.| 1.17 | -### Custom Resources +If `listType` is missing, the API server interprets a +`patchMergeStrategy=merge` marker as a `listType=map` and the +corresponding `patchMergeKey` marker as a `listMapKey`. + +The `atomic` list type is recursive. + +These markers are specified as comments and don't have to be repeated as +field tags. + +### Compatibility across topology changes + +On rare occurrences, a CRD or built-in type author may want to change the +specific topology of a field in their resource without incrementing its +version. Changing the topology of types, by upgrading the cluster or +updating the CRD, has different consequences when updating existing +objects. There are two categories of changes: when a field goes from +`map`/`set`/`granular` to `atomic` and the other way around. + +When the `listType`, `mapType`, or `structType` changes from +`map`/`set`/`granular` to `atomic`, the whole list, map, or struct of +existing objects will end-up being owned by actors who owned an element +of these types. This means that any further change to these objects +would cause a conflict. + +When a list, map, or struct changes from `atomic` to +`map`/`set`/`granular`, the API server won't be able to infer the new +ownership of these fields. Because of that, no conflict will be produced +when objects have these fields updated. For that reason, it is not +recommended to change a type from `atomic` to `map`/`set`/`granular`. + +Take for example, the custom resource: + +```yaml +apiVersion: example.com/v1 +kind: Foo +metadata: + name: foo-sample + managedFields: + - manager: manager-one + operation: Apply + apiVersion: example.com/v1 + fields: + f:spec: + f:data: {} +spec: + data: + key1: val1 + key2: val2 +``` + +Before `spec.data` gets changed from `atomic` to `granular`, +`manager-one` owns the field `spec.data`, and all the fields within it +(`key1` and `key2`). When the CRD gets changed to make `spec.data` +`granular`, `manager-one` continues to own the top-level field +`spec.data` (meaning no other managers can delete the map called `data` +without a conflict), but it no longer owns `key1` and `key2`, so another +manager can then modify or delete those fields without conflict. + +## Custom Resources By default, Server Side Apply treats custom resources as unstructured data. All keys are treated the same as struct fields, and all lists are considered atomic. @@ -245,14 +303,14 @@ that contains annotations as defined in the previous "Merge Strategy" section, these annotations will be used when merging objects of this type. -### Using Server-Side Apply in a controller +## Using Server-Side Apply in a controller As a developer of a controller, you can use server-side apply as a way to simplify the update logic of your controller. The main differences with a read-modify-write and/or patch are the following: * the applied object must contain all the fields that the controller cares about. -* there are no way to remove fields that haven't been applied by the controller +* there is no way to remove fields that haven't been applied by the controller before (controller can still send a PATCH/UPDATE for these use-cases). * the object doesn't have to be read beforehand, `resourceVersion` doesn't have to be specified. @@ -260,7 +318,7 @@ read-modify-write and/or patch are the following: It is strongly recommended for controllers to always "force" conflicts, since they might not be able to resolve or act on these conflicts. -### Transferring Ownership +## Transferring Ownership In addition to the concurrency controls provided by [conflict resolution](#conflicts), Server Side Apply provides ways to perform coordinated @@ -329,7 +387,7 @@ Note that whenever the HPA controller sets the `replicas` field to a new value, the temporary field manager will no longer own any fields and will be automatically deleted. No clean up is required. -## Transferring Ownership Between Users +### Transferring Ownership Between Users Users can transfer ownership of a field between each other by setting the field to the same value in both of their applied configs, causing them to share @@ -415,7 +473,7 @@ have an opinion about. ## Clearing ManagedFields It is possible to strip all managedFields from an object by overwriting them -using `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`, so every +using `MergePatch`, `StrategicMergePatch`, `JSONPatch`, or `Update`, so every non-apply operation. This can be done by overwriting the managedFields field with an empty entry. Two examples are: @@ -458,4 +516,3 @@ Server Side Apply is a beta feature, so it is enabled by default. To turn this you need to include the `--feature-gates ServerSideApply=false` flag when starting `kube-apiserver`. If you have multiple `kube-apiserver` replicas, all should have the same flag setting. - diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md index 59db384258..bb73375553 100644 --- a/content/en/docs/setup/_index.md +++ b/content/en/docs/setup/_index.md @@ -3,11 +3,11 @@ reviewers: - brendandburns - erictune - mikedanese -no_issue: true title: Getting started main_menu: true weight: 20 content_type: concept +no_list: true card: name: setup weight: 20 @@ -24,16 +24,40 @@ This section lists the different ways to set up and run Kubernetes. When you install Kubernetes, choose an installation type based on: ease of maintenance, security, control, available resources, and expertise required to operate and manage a cluster. -You can deploy a Kubernetes cluster on a local machine, cloud, on-prem datacenter, or choose a managed Kubernetes cluster. There are also custom solutions across a wide range of cloud providers, or bare metal environments. +You can [download Kubernetes](/releases/download/) to deploy a Kubernetes cluster +on a local machine, into the cloud, or for your own datacenter. + +If you don't want to manage a Kubernetes cluster yourself, you could pick a managed service, including +[certified platforms](/docs/setup/production-environment/turnkey-solutions/). +There are also other standardized and custom solutions across a wide range of cloud and +bare metal environments. ## Learning environment -If you're learning Kubernetes, use the tools supported by the Kubernetes community, or tools in the ecosystem to set up a Kubernetes cluster on a local machine. +If you're learning Kubernetes, use the tools supported by the Kubernetes community, +or tools in the ecosystem to set up a Kubernetes cluster on a local machine. +See [Install tools](/docs/tasks/tools/). ## Production environment -When evaluating a solution for a production environment, consider which aspects of operating a Kubernetes cluster (or _abstractions_) you want to manage yourself or offload to a provider. +When evaluating a solution for a +[production environment](/docs/setup/production-environment/), consider which aspects of +operating a Kubernetes cluster (or _abstractions_) you want to manage yourself and which you +prefer to hand off to a provider. -[Kubernetes Partners](https://kubernetes.io/partners/#conformance) includes a list of [Certified Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes) providers. +For a cluster you're managing yourself, the officially supported tool +for deploying Kubernetes is [kubeadm](/docs/setup/production-environment/tools/kubeadm/). + +## {{% heading "whatsnext" %}} + +- [Download Kubernetes](/releases/download/) +- Download and [install tools](/docs/tasks/tools/) including `kubectl` +- Select a [container runtime](/docs/setup/production-environment/container-runtimes/) for your new cluster +- Learn about [best practices](/docs/setup/best-practices/) for cluster setup + +Kubernetes is designed for its {{< glossary_tooltip term_id="control-plane" text="control plane" >}} to +run on Linux. Within your cluster you can run applications on Linux or other operating systems, including +Windows. +- Learn to [set up clusters with Windows nodes](/docs/setup/production-environment/windows/) diff --git a/content/en/docs/setup/best-practices/cluster-large.md b/content/en/docs/setup/best-practices/cluster-large.md index a75499a811..0f7fb0552e 100644 --- a/content/en/docs/setup/best-practices/cluster-large.md +++ b/content/en/docs/setup/best-practices/cluster-large.md @@ -12,7 +12,7 @@ or virtual machines) running Kubernetes agents, managed by the Kubernetes {{< param "version" >}} supports clusters with up to 5000 nodes. More specifically, Kubernetes is designed to accommodate configurations that meet *all* of the following criteria: -* No more than 100 pods per node +* No more than 110 pods per node * No more than 5000 nodes * No more than 150000 total pods * No more than 300000 total containers @@ -24,7 +24,7 @@ on how your cluster is deployed. To avoid running into cloud provider quota issues, when creating a cluster with many nodes, consider: -* Request a quota increase for cloud resources such as: +* Requesting a quota increase for cloud resources such as: * Computer instances * CPUs * Storage volumes @@ -33,7 +33,7 @@ consider: * Number of load balancers * Network subnets * Log streams -* Gate the cluster scaling actions to brings up new nodes in batches, with a pause +* Gating the cluster scaling actions to bring up new nodes in batches, with a pause between batches, because some cloud providers rate limit the creation of new instances. ## Control plane components @@ -66,6 +66,10 @@ When creating a cluster, you can (using custom tooling): * start and configure additional etcd instance * configure the {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} to use it for storing events +See [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) and +[Set up a High Availability etcd cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) +for details on configuring and managing etcd for a large cluster. + ## Addon resources Kubernetes [resource limits](/docs/concepts/configuration/manage-resources-containers/) @@ -120,3 +124,6 @@ components, including cluster-critical addons. The [cluster autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme) integrates with a number of cloud providers to help you run the right number of nodes for the level of resource demand in your cluster. + +The [addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme) +helps you in resizing the addons automatically as your cluster's scale changes. \ No newline at end of file diff --git a/content/en/docs/setup/best-practices/enforcing-pod-security-standards.md b/content/en/docs/setup/best-practices/enforcing-pod-security-standards.md new file mode 100644 index 0000000000..2b7ca6144e --- /dev/null +++ b/content/en/docs/setup/best-practices/enforcing-pod-security-standards.md @@ -0,0 +1,78 @@ +--- +reviewers: +- tallclair +- liggitt +title: Enforcing Pod Security Standards +weight: 40 +--- + + + +This page provides an overview of best practices when it comes to enforcing +[Pod Security Standards](/docs/concepts/security/pod-security-standards). + + + +## Using the built-in Pod Security Admission Controller + +{{< feature-state for_k8s_version="v1.22" state="alpha" >}} + +The [Pod Security Admission Controller](/docs/reference/access-authn-authz/admission-controllers/#podsecurity) +intends to replace the deprecated PodSecurityPolicies. + +### Configure all cluster namespaces + +Namespaces that lack any configuration at all should be considered significant gaps in your cluster +security model. We recommend taking the time to analyze the types of workloads occurring in each +namespace, and by referencing the Pod Security Standards, decide on an appropriate level for +each of them. Unlabeled namespaces should only indicate that they've yet to be evaluated. + +In the scenario that all workloads in all namespaces have the same security requirements, +we provide an [example](/docs/concepts/security/pod-security-admission/#applying-to-all-namespaces) +that illustrates how the PodSecurity labels can be applied in bulk. + +### Embrace the principle of least privilege + +In an ideal world, every pod in every namespace would meet the requirements of the `restricted` +policy. However, this is not possible nor practical, as some workloads will require elevated +privileges for legitimate reasons. + +- Namespaces allowing `privileged` workloads should establish and enforce appropriate access controls. +- For workloads running in those permissive namespaces, maintain documentation about their unique + security requirements. If at all possible, consider how those requirements could be further + constrained. + +### Adopt a multi-mode strategy + +The `audit` and `warn` modes of the Pod Security Standards admission controller make it easy to +collect important security insights about your pods without breaking existing workloads. + +It is good practice to enable these modes for all namespaces, setting them to the _desired_ level +and version you would eventually like to `enforce`. The warnings and audit annotations generated in +this phase can guide you toward that state. If you expect workload authors to make changes to fit +within the desired level, enable the `warn` mode. If you expect to use audit logs to monitor/drive +changes to fit within the desired level, enable the `audit` mode. + +When you have the `enforce` mode set to your desired value, these modes can still be useful in a +few different ways: + +- By setting `warn` to the same level as `enforce`, clients will receive warnings when attempting + to create Pods (or resources that have Pod templates) that do not pass validation. This will help + them update those resources to become compliant. +- In Namespaces that pin `enforce` to a specific non-latest version, setting the `audit` and `warn` + modes to the same level as `enforce`, but to the `latest` version, gives visibility into settings + that were allowed by previous versions but are not allowed per current best practices. + +## Third-party alternatives + +{{% thirdparty-content %}} + +Other alternatives for enforcing security profiles are being developed in the Kubernetes +ecosystem: + +- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper). + +The decision to go with a _built-in_ solution (e.g. PodSecurity admission controller) versus a +third-party tool is entirely dependent on your own situation. When evaluating any solution, +trust of your supply chain is crucial. Ultimately, using _any_ of the aforementioned approaches +will be better than doing nothing. \ No newline at end of file diff --git a/content/en/docs/setup/learning-environment/_index.md b/content/en/docs/setup/learning-environment/_index.md index 672bbd69ed..6abebc3976 100644 --- a/content/en/docs/setup/learning-environment/_index.md +++ b/content/en/docs/setup/learning-environment/_index.md @@ -11,7 +11,7 @@ weight: 20 {{/* If you're localizing this page, you only need to copy the front matter */}} {{/* and add a redirect into "/static/_redirects", for YOUR localization. */}} --> - + + diff --git a/content/en/docs/setup/production-environment/_index.md b/content/en/docs/setup/production-environment/_index.md index 346280893e..1611170ec9 100644 --- a/content/en/docs/setup/production-environment/_index.md +++ b/content/en/docs/setup/production-environment/_index.md @@ -1,4 +1,293 @@ --- -title: Production environment +title: "Production environment" +description: Create a production-quality Kubernetes cluster weight: 30 +no_list: true --- + + +A production-quality Kubernetes cluster requires planning and preparation. +If your Kubernetes cluster is to run critical workloads, it must be configured to be resilient. +This page explains steps you can take to set up a production-ready cluster, +or to promote an existing cluster for production use. +If you're already familiar with production setup and want the links, skip to +[What's next](#what-s-next). + + + +## Production considerations + +Typically, a production Kubernetes cluster environment has more requirements than a +personal learning, development, or test environment Kubernetes. A production environment may require +secure access by many users, consistent availability, and the resources to adapt +to changing demands. + +As you decide where you want your production Kubernetes environment to live +(on premises or in a cloud) and the amount of management you want to take +on or hand to others, consider how your requirements for a Kubernetes cluster +are influenced by the following issues: + +- *Availability*: A single-machine Kubernetes [learning environment](/docs/setup/#learning-environment) +has a single point of failure. Creating a highly available cluster means considering: + - Separating the control plane from the worker nodes. + - Replicating the control plane components on multiple nodes. + - Load balancing traffic to the cluster’s {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}}. + - Having enough worker nodes available, or able to quickly become available, as changing workloads warrant it. + +- *Scale*: If you expect your production Kubernetes environment to receive a stable amount of +demand, you might be able to set up for the capacity you need and be done. However, +if you expect demand to grow over time or change dramatically based on things like +season or special events, you need to plan how to scale to relieve increased +pressure from more requests to the control plane and worker nodes or scale down to reduce unused +resources. + +- *Security and access management*: You have full admin privileges on your own +Kubernetes learning cluster. But shared clusters with important workloads, and +more than one or two users, require a more refined approach to who and what can +access cluster resources. You can use role-based access control +([RBAC](/docs/reference/access-authn-authz/rbac/)) and other +security mechanisms to make sure that users and workloads can get access to the +resources they need, while keeping workloads, and the cluster itself, secure. +You can set limits on the resources that users and workloads can access +by managing [policies](/docs/concepts/policy/) and +[container resources](/docs/concepts/configuration/manage-resources-containers/). + +Before building a Kubernetes production environment on your own, consider +handing off some or all of this job to +[Turnkey Cloud Solutions](/docs/setup/production-environment/turnkey-solutions/) +providers or other [Kubernetes Partners](https://kubernetes.io/partners/). +Options include: + +- *Serverless*: Just run workloads on third-party equipment without managing +a cluster at all. You will be charged for things like CPU usage, memory, and +disk requests. +- *Managed control plane*: Let the provider manage the scale and availability +of the cluster's control plane, as well as handle patches and upgrades. +- *Managed worker nodes*: Configure pools of nodes to meet your needs, +then the provider makes sure those nodes are available and ready to implement +upgrades when needed. +- *Integration*: There are providers that integrate Kubernetes with other +services you may need, such as storage, container registries, authentication +methods, and development tools. + +Whether you build a production Kubernetes cluster yourself or work with +partners, review the following sections to evaluate your needs as they relate +to your cluster’s *control plane*, *worker nodes*, *user access*, and +*workload resources*. + +## Production cluster setup + +In a production-quality Kubernetes cluster, the control plane manages the +cluster from services that can be spread across multiple computers +in different ways. Each worker node, however, represents a single entity that +is configured to run Kubernetes pods. + +### Production control plane + +The simplest Kubernetes cluster has the entire control plane and worker node +services running on the same machine. You can grow that environment by adding +worker nodes, as reflected in the diagram illustrated in +[Kubernetes Components](/docs/concepts/overview/components/). +If the cluster is meant to be available for a short period of time, or can be +discarded if something goes seriously wrong, this might meet your needs. + +If you need a more permanent, highly available cluster, however, you should +consider ways of extending the control plane. By design, one-machine control +plane services running on a single machine are not highly available. +If keeping the cluster up and running +and ensuring that it can be repaired if something goes wrong is important, +consider these steps: + +- *Choose deployment tools*: You can deploy a control plane using tools such +as kubeadm, kops, and kubespray. See +[Installing Kubernetes with deployment tools](/docs/setup/production-environment/tools/) +to learn tips for production-quality deployments using each of those deployment +methods. Different [Container Runtimes](/docs/setup/production-environment/container-runtimes/) +are available to use with your deployments. +- *Manage certificates*: Secure communications between control plane services +are implemented using certificates. Certificates are automatically generated +during deployment or you can generate them using your own certificate authority. +See [PKI certificates and requirements](/docs/setup/best-practices/certificates/) for details. +- *Configure load balancer for apiserver*: Configure a load balancer +to distribute external API requests to the apiserver service instances running on different nodes. See +[Create an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/) +for details. +- *Separate and backup etcd service*: The etcd services can either run on the +same machines as other control plane services or run on separate machines, for +extra security and availability. Because etcd stores cluster configuration data, +backing up the etcd database should be done regularly to ensure that you can +repair that database if needed. +See the [etcd FAQ](https://etcd.io/docs/v3.4/faq/) for details on configuring and using etcd. +See [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) +and [Set up a High Availability etcd cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) +for details. +- *Create multiple control plane systems*: For high availability, the +control plane should not be limited to a single machine. If the control plane +services are run by an init service (such as systemd), each service should run on at +least three machines. However, running control plane services as pods in +Kubernetes ensures that the replicated number of services that you request +will always be available. +The scheduler should be fault tolerant, +but not highly available. Some deployment tools set up [Raft](https://raft.github.io/) +consensus algorithm to do leader election of Kubernetes services. If the +primary goes away, another service elects itself and take over. +- *Span multiple zones*: If keeping your cluster available at all times is +critical, consider creating a cluster that runs across multiple data centers, +referred to as zones in cloud environments. Groups of zones are referred to as regions. +By spreading a cluster across +multiple zones in the same region, it can improve the chances that your +cluster will continue to function even if one zone becomes unavailable. +See [Running in multiple zones](/docs/setup/best-practices/multiple-zones/) for details. +- *Manage on-going features*: If you plan to keep your cluster over time, +there are tasks you need to do to maintain its health and security. For example, +if you installed with kubeadm, there are instructions to help you with +[Certificate Management](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) +and [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). +See [Administer a Cluster](/docs/tasks/administer-cluster/) +for a longer list of Kubernetes administrative tasks. + +To learn about available options when you run control plane services, see +[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/), +[kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/), +and [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) +component pages. For highly available control plane examples, see +[Options for Highly Available topology](/docs/setup/production-environment/tools/kubeadm/ha-topology/), +[Creating Highly Available clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/), +and [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/). +See [Backing up an etcd cluster](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) +for information on making an etcd backup plan. + +### Production worker nodes + +Production-quality workloads need to be resilient and anything they rely +on needs to be resilient (such as CoreDNS). Whether you manage your own +control plane or have a cloud provider do it for you, you still need to +consider how you want to manage your worker nodes (also referred to +simply as *nodes*). + +- *Configure nodes*: Nodes can be physical or virtual machines. If you want to +create and manage your own nodes, you can install a supported operating system, +then add and run the appropriate +[Node services](/docs/concepts/overview/components/#node-components). Consider: + - The demands of your workloads when you set up nodes by having appropriate memory, CPU, and disk speed and storage capacity available. + - Whether generic computer systems will do or you have workloads that need GPU processors, Windows nodes, or VM isolation. +- *Validate nodes*: See [Valid node setup](/docs/setup/best-practices/node-conformance/) +for information on how to ensure that a node meets the requirements to join +a Kubernetes cluster. +- *Add nodes to the cluster*: If you are managing your own cluster you can +add nodes by setting up your own machines and either adding them manually or +having them register themselves to the cluster’s apiserver. See the +[Nodes](/docs/concepts/architecture/nodes/) section for information on how to set up Kubernetes to add nodes in these ways. +- *Add Windows nodes to the cluster*: Kubernetes offers support for Windows +worker nodes, allowing you to run workloads implemented in Windows containers. See +[Windows in Kubernetes](/docs/setup/production-environment/windows/) for details. +- *Scale nodes*: Have a plan for expanding the capacity your cluster will +eventually need. See [Considerations for large clusters](/docs/setup/best-practices/cluster-large/) +to help determine how many nodes you need, based on the number of pods and +containers you need to run. If you are managing nodes yourself, this can mean +purchasing and installing your own physical equipment. +- *Autoscale nodes*: Most cloud providers support +[Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme) +to replace unhealthy nodes or grow and shrink the number of nodes as demand requires. See the +[Frequently Asked Questions](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) +for how the autoscaler works and +[Deployment](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment) +for how it is implemented by different cloud providers. For on-premises, there +are some virtualization platforms that can be scripted to spin up new nodes +based on demand. +- *Set up node health checks*: For important workloads, you want to make sure +that the nodes and pods running on those nodes are healthy. Using the +[Node Problem Detector](/docs/tasks/debug-application-cluster/monitor-node-health/) +daemon, you can ensure your nodes are healthy. + +## Production user management + +In production, you may be moving from a model where you or a small group of +people are accessing the cluster to where there may potentially be dozens or +hundreds of people. In a learning environment or platform prototype, you might have a single +administrative account for everything you do. In production, you will want +more accounts with different levels of access to different namespaces. + +Taking on a production-quality cluster means deciding how you +want to selectively allow access by other users. In particular, you need to +select strategies for validating the identities of those who try to access your +cluster (authentication) and deciding if they have permissions to do what they +are asking (authorization): + +- *Authentication*: The apiserver can authenticate users using client +certificates, bearer tokens, an authenticating proxy, or HTTP basic auth. +You can choose which authentication methods you want to use. +Using plugins, the apiserver can leverage your organization’s existing +authentication methods, such as LDAP or Kerberos. See +[Authentication](/docs/reference/access-authn-authz/authentication/) +for a description of these different methods of authenticating Kubernetes users. +- *Authorization*: When you set out to authorize your regular users, you will probably choose between RBAC and ABAC authorization. See [Authorization Overview](/docs/reference/access-authn-authz/authorization/) to review different modes for authorizing user accounts (as well as service account access to your cluster): + - *Role-based access control* ([RBAC](/docs/reference/access-authn-authz/rbac/)): Lets you assign access to your cluster by allowing specific sets of permissions to authenticated users. Permissions can be assigned for a specific namespace (Role) or across the entire cluster (ClusterRole). Then using RoleBindings and ClusterRoleBindings, those permissions can be attached to particular users. + - *Attribute-based access control* ([ABAC](/docs/reference/access-authn-authz/abac/)): Lets you create policies based on resource attributes in the cluster and will allow or deny access based on those attributes. Each line of a policy file identifies versioning properties (apiVersion and kind) and a map of spec properties to match the subject (user or group), resource property, non-resource property (/version or /apis), and readonly. See [Examples](/docs/reference/access-authn-authz/abac/#examples) for details. + +As someone setting up authentication and authorization on your production Kubernetes cluster, here are some things to consider: + +- *Set the authorization mode*: When the Kubernetes API server +([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)) +starts, the supported authentication modes must be set using the *--authorization-mode* +flag. For example, that flag in the *kube-adminserver.yaml* file (in */etc/kubernetes/manifests*) +could be set to Node,RBAC. This would allow Node and RBAC authorization for authenticated requests. +- *Create user certificates and role bindings (RBAC)*: If you are using RBAC +authorization, users can create a CertificateSigningRequest (CSR) that can be +signed by the cluster CA. Then you can bind Roles and ClusterRoles to each user. +See [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/) +for details. +- *Create policies that combine attributes (ABAC)*: If you are using ABAC +authorization, you can assign combinations of attributes to form policies to +authorize selected users or groups to access particular resources (such as a +pod), namespace, or apiGroup. For more information, see +[Examples](/docs/reference/access-authn-authz/abac/#examples). +- *Consider Admission Controllers*: Additional forms of authorization for +requests that can come in through the API server include +[Webhook Token Authentication](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication). +Webhooks and other special authorization types need to be enabled by adding +[Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) +to the API server. + +## Set limits on workload resources + +Demands from production workloads can cause pressure both inside and outside +of the Kubernetes control plane. Consider these items when setting up for the +needs of your cluster's workloads: + +- *Set namespace limits*: Set per-namespace quotas on things like memory and CPU. See +[Manage Memory, CPU, and API Resources](/docs/tasks/administer-cluster/manage-resources/) +for details. You can also set +[Hierarchical Namespaces](/blog/2020/08/14/introducing-hierarchical-namespaces/) +for inheriting limits. +- *Prepare for DNS demand*: If you expect workloads to massively scale up, +your DNS service must be ready to scale up as well. See +[Autoscale the DNS service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). +- *Create additional service accounts*: User accounts determine what users can +do on a cluster, while a service account defines pod access within a particular +namespace. By default, a pod takes on the default service account from its namespace. +See [Managing Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/) +for information on creating a new service account. For example, you might want to: + - Add secrets that a pod could use to pull images from a particular container registry. See [Configure Service Accounts for Pods](/docs/tasks/configure-pod-container/configure-service-account/) for an example. + - Assign RBAC permissions to a service account. See [ServiceAccount permissions](/docs/reference/access-authn-authz/rbac/#service-account-permissions) for details. + +## {{% heading "whatsnext" %}} + +- Decide if you want to build your own production Kubernetes or obtain one from +available [Turnkey Cloud Solutions](/docs/setup/production-environment/turnkey-solutions/) +or [Kubernetes Partners](https://kubernetes.io/partners/). +- If you choose to build your own cluster, plan how you want to +handle [certificates](/docs/setup/best-practices/certificates/) +and set up high availability for features such as +[etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) +and the +[API server](/docs/setup/production-environment/tools/kubeadm/ha-topology/). +- Choose from [kubeadm](/docs/setup/production-environment/tools/kubeadm/), [kops](/docs/setup/production-environment/tools/kops/) or [Kubespray](/docs/setup/production-environment/tools/kubespray/) +deployment methods. +- Configure user management by determining your +[Authentication](/docs/reference/access-authn-authz/authentication/) and +[Authorization](/docs/reference/access-authn-authz/authorization/) methods. +- Prepare for application workloads by setting up +[resource limits](/docs/tasks/administer-cluster/manage-resources/), +[DNS autoscaling](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) +and [service accounts](/docs/reference/access-authn-authz/service-accounts-admin/). diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index ba6827d833..fa72d04ced 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -48,7 +48,7 @@ Changing the settings such that your container runtime and kubelet use `systemd` stabilized the system. To configure this for Docker, set `native.cgroupdriver=systemd`. {{< caution >}} -Changing the cgroup driver of a Node that has joined a cluster is strongly *not* recommended. +Changing the cgroup driver of a Node that has joined a cluster is a sensitive operation. If the kubelet has created Pods using the semantics of one cgroup driver, changing the container runtime to another cgroup driver can cause errors when trying to re-create the Pod sandbox for such existing Pods. Restarting the kubelet may not solve such errors. @@ -57,6 +57,43 @@ If you have automation that makes it feasible, replace the node with another usi configuration, or reinstall it using automation. {{< /caution >}} +## Cgroup v2 + +Cgroup v2 is the next version of the cgroup Linux API. Differently than cgroup v1, there is a single +hierarchy instead of a different one for each controller. + +The new version offers several improvements over cgroup v1, some of these improvements are: + +- cleaner and easier to use API +- safe sub-tree delegation to containers +- newer features like Pressure Stall Information + +Even if the kernel supports a hybrid configuration where some controllers are managed by cgroup v1 +and some others by cgroup v2, Kubernetes supports only the same cgroup version to manage all the +controllers. + +If systemd doesn't use cgroup v2 by default, you can configure the system to use it by adding +`systemd.unified_cgroup_hierarchy=1` to the kernel command line. + +```shell +# dnf install -y grubby && \ + sudo grubby \ + --update-kernel=ALL \ + --args=”systemd.unified_cgroup_hierarchy=1" +``` + +To apply the configuration, it is necessary to reboot the node. + +There should not be any noticeable difference in the user experience when switching to cgroup v2, unless +users are accessing the cgroup file system directly, either on the node or from within the containers. + +In order to use it, cgroup v2 must be supported by the CRI runtime as well. + +### Migrating to the `systemd` driver in kubeadm managed clusters + +Follow this [Migration guide](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/) +if you wish to migrate to the `systemd` cgroup driver in existing kubeadm managed clusters. + ## Container runtimes {{% thirdparty-content %}} @@ -94,7 +131,10 @@ Install containerd: {{< tabs name="tab-cri-containerd-installation" >}} {{% tab name="Linux" %}} -1. Install the `containerd.io` package from the official Docker repositories. Instructions for setting up the Docker repository for your respective Linux distribution and installing the `containerd.io` package can be found at [Install Docker Engine](https://docs.docker.com/engine/install/#server). +1. Install the `containerd.io` package from the official Docker repositories. +Instructions for setting up the Docker repository for your respective Linux distribution and +installing the `containerd.io` package can be found at +[Install Docker Engine](https://docs.docker.com/engine/install/#server). 2. Configure containerd: @@ -112,7 +152,8 @@ Install containerd: {{% /tab %}} {{% tab name="Windows (PowerShell)" %}} -Start a Powershell session, set `$Version` to the desired version (ex: `$Version=1.4.3`), and then run the following commands: +Start a Powershell session, set `$Version` to the desired version (ex: `$Version=1.4.3`), +and then run the following commands: 1. Download containerd: @@ -238,7 +279,8 @@ sudo apt-get install cri-o cri-o-runc {{% tab name="Ubuntu" %}} -To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table: +To install on the following operating systems, set the environment variable `OS` +to the appropriate field in the following table: | Operating system | `$OS` | | ---------------- | ----------------- | @@ -273,7 +315,8 @@ sudo apt-get install cri-o cri-o-runc {{% tab name="CentOS" %}} -To install on the following operating systems, set the environment variable `OS` to the appropriate field in the following table: +To install on the following operating systems, set the environment variable `OS` +to the appropriate field in the following table: | Operating system | `$OS` | | ---------------- | ----------------- | @@ -353,7 +396,10 @@ in sync. ### Docker -1. On each of your nodes, install the Docker for your Linux distribution as per [Install Docker Engine](https://docs.docker.com/engine/install/#server). You can find the latest validated version of Docker in this [dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file. +1. On each of your nodes, install the Docker for your Linux distribution as per +[Install Docker Engine](https://docs.docker.com/engine/install/#server). +You can find the latest validated version of Docker in this +[dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file. 2. Configure the Docker daemon, in particular to use systemd for the management of the container’s cgroups. @@ -372,7 +418,8 @@ in sync. ``` {{< note >}} - `overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, or RHEL or CentOS using version 3.10.0-514 and above. + `overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, + or RHEL or CentOS using version 3.10.0-514 and above. {{< /note >}} 3. Restart Docker and enable on boot: diff --git a/content/en/docs/setup/production-environment/tools/kops.md b/content/en/docs/setup/production-environment/tools/kops.md index 4afab697e4..cf5333a92d 100644 --- a/content/en/docs/setup/production-environment/tools/kops.md +++ b/content/en/docs/setup/production-environment/tools/kops.md @@ -56,10 +56,10 @@ To download a specific version, replace the following portion of the command wit $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4) ``` -For example, to download kops version v1.15.0 type: +For example, to download kops version v1.20.0 type: ```shell -curl -LO https://github.com/kubernetes/kops/releases/download/1.15.0/kops-darwin-amd64 +curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-darwin-amd64 ``` Make the kops binary executable. @@ -94,10 +94,10 @@ To download a specific version of kops, replace the following portion of the com $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4) ``` -For example, to download kops version v1.15.0 type: +For example, to download kops version v1.20.0 type: ```shell -curl -LO https://github.com/kubernetes/kops/releases/download/1.15.0/kops-linux-amd64 +curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-linux-amd64 ``` Make the kops binary executable diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index 1dd44e9b0b..ff1fedb9c0 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -1,86 +1,210 @@ --- reviewers: - sig-cluster-lifecycle -title: Customizing control plane configuration with kubeadm +title: Customizing components with the kubeadm API content_type: concept weight: 40 --- +This page covers how to customize the components that kubeadm deploys. For control plane components +you can use flags in the `ClusterConfiguration` structure or patches per-node. For the kubelet +and kube-proxy you can use `KubeletConfiguration` and `KubeProxyConfiguration`, accordingly. + +All of these options are possible via the kubeadm configuration API. +For more details on each field in the configuration you can navigate to our +[API reference pages](/docs/reference/config-api/kubeadm-config.v1beta3/). + +{{< note >}} +Customizing the CoreDNS deployment of kubeadm is currently not supported. You must manually +patch the `kube-system/coredns` {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} +and recreate the CoreDNS {{< glossary_tooltip text="Pods" term_id="pod" >}} after that. Alternatively, +you can skip the default CoreDNS deployment and deploy your own variant. +For more details on that see [Using init phases with kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases). +{{< /note >}} + + + {{< feature-state for_k8s_version="v1.12" state="stable" >}} -The kubeadm `ClusterConfiguration` object exposes the field `extraArgs` that can override the default flags passed to control plane -components such as the APIServer, ControllerManager and Scheduler. The components are defined using the following fields: +## Customizing the control plane with flags in `ClusterConfiguration` + +The kubeadm `ClusterConfiguration` object exposes a way for users to override the default +flags passed to control plane components such as the APIServer, ControllerManager, Scheduler and Etcd. +The components are defined using the following structures: - `apiServer` - `controllerManager` - `scheduler` +- `etcd` -The `extraArgs` field consist of `key: value` pairs. To override a flag for a control plane component: +These structures contain a common `extraArgs` field, that consists of `key: value` pairs. +To override a flag for a control plane component: -1. Add the appropriate fields to your configuration. -2. Add the flags to override to the field. +1. Add the appropriate `extraArgs` to your configuration. +2. Add flags to the `extraArgs` field. 3. Run `kubeadm init` with `--config `. -For more details on each field in the configuration you can navigate to our -[API reference pages](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2#ClusterConfiguration). - {{< note >}} -You can generate a `ClusterConfiguration` object with default values by running `kubeadm config print init-defaults` and saving the output to a file of your choice. +You can generate a `ClusterConfiguration` object with default values by running `kubeadm config print init-defaults` +and saving the output to a file of your choice. {{< /note >}} +{{< note >}} +The `ClusterConfiguration` object is currently global in kubeadm clusters. This means that any flags that you add, +will apply to all instances of the same component on different nodes. To apply individual configuration per component +on different nodes you can use [patches](#patches). +{{< /note >}} +{{< note >}} +Duplicate flags (keys), or passing the same flag `--foo` multiple times, is currently not supported. +To workaround that you must use [patches](#patches). +{{< /note >}} - - -## APIServer flags +### APIServer flags For details, see the [reference documentation for kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/). Example usage: + ```yaml -apiVersion: kubeadm.k8s.io/v1beta2 +apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration kubernetesVersion: v1.16.0 apiServer: extraArgs: - advertise-address: 192.168.0.103 anonymous-auth: "false" enable-admission-plugins: AlwaysPullImages,DefaultStorageClass audit-log-path: /home/johndoe/audit.log ``` -## ControllerManager flags +### ControllerManager flags For details, see the [reference documentation for kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/). Example usage: + ```yaml -apiVersion: kubeadm.k8s.io/v1beta2 +apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration kubernetesVersion: v1.16.0 controllerManager: extraArgs: cluster-signing-key-file: /home/johndoe/keys/ca.key - bind-address: 0.0.0.0 deployment-controller-sync-period: "50" ``` -## Scheduler flags +### Scheduler flags For details, see the [reference documentation for kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). Example usage: + ```yaml -apiVersion: kubeadm.k8s.io/v1beta2 +apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration kubernetesVersion: v1.16.0 scheduler: extraArgs: - bind-address: 0.0.0.0 - config: /home/johndoe/schedconfig.yaml - kubeconfig: /home/johndoe/kubeconfig.yaml + config: /etc/kubernetes/scheduler-config.yaml + extraVolumes: + - name: schedulerconfig + hostPath: /home/johndoe/schedconfig.yaml + mountPath: /etc/kubernetes/scheduler-config.yaml + readOnly: true + pathType: "File" ``` +### Etcd flags +For details, see the [etcd server documentation](https://etcd.io/docs/). + +Example usage: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +etcd: + local: + extraArgs: + election-timeout: 1000 +``` + +## Customizing the control plane with patches {#patches} + +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +Kubeadm allows you to pass a directory with patch files to `InitConfiguration` and `JoinConfiguration` +on individual nodes. These patches can be used as the last customization step before the control +plane component manifests are written to disk. + +You can pass this file to `kubeadm init` with `--config `: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: InitConfiguration +nodeRegistration: + patches: + directory: /home/user/somedir +``` + +{{< note >}} +For `kubeadm init` you can pass a file containing both a `ClusterConfiguration` and `InitConfiguration` +separated by `---`. +{{< /note >}} + +You can pass this file to `kubeadm join` with `--config `: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: JoinConfiguration +nodeRegistration: + patches: + directory: /home/user/somedir +``` + +The directory must contain files named `target[suffix][+patchtype].extension`. +For example, `kube-apiserver0+merge.yaml` or just `etcd.json`. + +- `target` can be one of `kube-apiserver`, `kube-controller-manager`, `kube-scheduler` and `etcd`. +- `patchtype` can be one of `strategic`, `merge` or `json` and these must match the patching formats +[supported by kubectl](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch). +The default `patchtype` is `strategic`. +- `extension` must be either `json` or `yaml`. +- `suffix` is an optional string that can be used to determine which patches are applied first +alpha-numerically. + +{{< note >}} +If you are using `kubeadm upgrade` to upgrade your kubeadm nodes you must again provide the same +patches, so that the customization is preserved after upgrade. To do that you can use the `--patches` +flag, which must point to the same directory. `kubeadm upgrade` currently does not support a configuration +API structure that can be used for the same purpose. +{{< /note >}} + +## Customizing the kubelet + +To customize the kubelet you can add a `KubeletConfiguration` next to the `ClusterConfiguration` or +`InitConfiguration` separated by `---` within the same configuration file. This file can then be passed to `kubeadm init`. + +{{< note >}} +kubeadm applies the same `KubeletConfiguration` to all nodes in the cluster. To apply node +specific settings you can use kubelet flags as overrides by passing them in the `nodeRegistration.kubeletExtraArgs` +field supported by both `InitConfiguration` and `JoinConfiguration`. Some kubelet flags are deprecated, +so check their status in the [kubelet reference documentation](/docs/reference/command-line-tools-reference/kubelet) +before using them. +{{< /note >}} + +For more details see [Configuring each kubelet in your cluster using kubeadm](/docs/setup/production-environment/tools/kubeadm/kubelet-integration) + +## Customizing kube-proxy + +To customize kube-proxy you can pass a `KubeProxyConfiguration` next your `ClusterConfiguration` or +`InitConfiguration` to `kubeadm init` separated by `---`. + +For more details you can navigate to our [API reference pages](/docs/reference/config-api/kubeadm-config.v1beta3/). + +{{< note >}} +kubeadm deploys kube-proxy as a {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}, which means +that the `KubeProxyConfiguration` would apply to all instances of kube-proxy in the cluster. +{{< /note >}} diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index a5cdecafd7..1f107bbc9a 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -8,9 +8,12 @@ weight: 30 -Using `kubeadm`, you can create a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the [Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). -`kubeadm` also supports other cluster -lifecycle functions, such as [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades. + +Using `kubeadm`, you can create a minimum viable Kubernetes cluster that conforms to best practices. +In fact, you can use `kubeadm` to set up a cluster that will pass the +[Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). +`kubeadm` also supports other cluster lifecycle functions, such as +[bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades. The `kubeadm` tool is good if you need: @@ -42,7 +45,8 @@ To follow this guide, you need: You also need to use a version of `kubeadm` that can deploy the version of Kubernetes that you want to use in your new cluster. -[Kubernetes' version and version skew support policy](/docs/setup/release/version-skew-policy/#supported-versions) applies to `kubeadm` as well as to Kubernetes overall. +[Kubernetes' version and version skew support policy](/docs/setup/release/version-skew-policy/#supported-versions) +applies to `kubeadm` as well as to Kubernetes overall. Check that policy to learn about what versions of Kubernetes and `kubeadm` are supported. This page is written for Kubernetes {{< param "version" >}}. @@ -97,7 +101,8 @@ a provider-specific value. See [Installing a Pod network add-on](#pod-network). 1. (Optional) Since version 1.14, `kubeadm` tries to detect the container runtime on Linux by using a list of well known domain socket paths. To use different container runtime or if there are more than one installed on the provisioned node, specify the `--cri-socket` -argument to `kubeadm init`. See [Installing runtime](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime). +argument to `kubeadm init`. See +[Installing a runtime](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime). 1. (Optional) Unless otherwise specified, `kubeadm` uses the network interface associated with the default gateway to set the advertise address for this particular control-plane node's API server. To use a different network interface, specify the `--apiserver-advertise-address=` argument @@ -139,9 +144,12 @@ is not supported by kubeadm. For more information about `kubeadm init` arguments, see the [kubeadm reference guide](/docs/reference/setup-tools/kubeadm/). -To configure `kubeadm init` with a configuration file see [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file). +To configure `kubeadm init` with a configuration file see +[Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file). -To customize control plane components, including optional IPv6 assignment to liveness probe for control plane components and etcd server, provide extra arguments to each component as documented in [custom arguments](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/). +To customize control plane components, including optional IPv6 assignment to liveness probe +for control plane components and etcd server, provide extra arguments to each component as documented in +[custom arguments](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/). To run `kubeadm init` again, you must first [tear down the cluster](#tear-down). @@ -187,6 +195,13 @@ Alternatively, if you are the `root` user, you can run: export KUBECONFIG=/etc/kubernetes/admin.conf ``` +{{< warning >}} +Kubeadm signs the certificate in the `admin.conf` to have `Subject: O = system:masters, CN = kubernetes-admin`. +`system:masters` is a break-glass, super user group that bypasses the authorization layer (e.g. RBAC). +Do not share the `admin.conf` file with anyone and instead grant users custom permissions by generating +them a kubeconfig file using the `kubeadm kubeconfig user` command. +{{< /warning >}} + Make a record of the `kubeadm join` command that `kubeadm init` outputs. You need this command to [join nodes to your cluster](#join-nodes). @@ -285,11 +300,13 @@ The nodes are where your workloads (containers and Pods, etc) run. To add new no * SSH to the machine * Become root (e.g. `sudo su -`) +* [Install a runtime](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-runtime) + if needed * Run the command that was output by `kubeadm init`. For example: -```bash -kubeadm join --token : --discovery-token-ca-cert-hash sha256: -``` + ```bash + kubeadm join --token : --discovery-token-ca-cert-hash sha256: + ``` If you do not have the token, you can get it by running the following command on the control-plane node: @@ -408,7 +425,7 @@ and make sure that the node is empty, then deconfigure the node. Talking to the control-plane node with the appropriate credentials, run: ```bash -kubectl drain --delete-local-data --force --ignore-daemonsets +kubectl drain --delete-emptydir-data --force --ignore-daemonsets ``` Before removing the node, reset the state installed by `kubeadm`: diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md b/content/en/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md new file mode 100644 index 0000000000..39930cca37 --- /dev/null +++ b/content/en/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md @@ -0,0 +1,153 @@ +--- +title: Dual-stack support with kubeadm +content_type: task +weight: 110 +min-kubernetes-server-version: 1.21 +--- + + + +{{< feature-state for_k8s_version="v1.21" state="beta" >}} + +Your Kubernetes cluster can run in [dual-stack](/docs/concepts/services-networking/dual-stack/) networking mode, which means that cluster networking lets you use either address family. In a dual-stack cluster, the control plane can assign both an IPv4 address and an IPv6 address to a single {{< glossary_tooltip text="Pod" term_id="pod" >}} or a {{< glossary_tooltip text="Service" term_id="service" >}}. + + + +## {{% heading "prerequisites" %}} + +You need to have installed the {{< glossary_tooltip text="kubeadm" term_id="kubeadm" >}} tool, following the steps from [Installing kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). + +For each server that you want to use as a {{< glossary_tooltip text="node" term_id="node" >}}, make sure it allows IPv6 forwarding. On Linux, you can set this by running run `sysctl -w net.ipv6.conf.all.forwarding=1` as the root user on each server. + +You need to have an IPv4 and and IPv6 address range to use. Cluster operators typically +use private address ranges for IPv4. For IPv6, a cluster operator typically chooses a global +unicast address block from within `2000::/3`, using a range that is assigned to the operator. +You don't have to route the cluster's IP address ranges to the public internet. + +The size of the IP address allocations should be suitable for the number of Pods and +Services that you are planning to run. + +{{< note >}} +If you are upgrading an existing cluster then, by default, the `kubeadm upgrade` command +changes the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) +`IPv6DualStack` to `true` if that is not already enabled. +However, `kubeadm` does not support making modifications to the pod IP address range +(“cluster CIDR”) nor to the cluster's Service address range (“Service CIDR”). +{{< /note >}} + +### Create a dual-stack cluster + +To create a dual-stack cluster with `kubeadm init` you can pass command line arguments +similar to the following example: + +```shell +# These address ranges are examples +kubeadm init --pod-network-cidr=10.244.0.0/16,2001:db8:42:0::/56 --service-cidr=10.96.0.0/16,2001:db8:42:1::/112 +``` + +To make things clearer, here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for the primary dual-stack control plane node. + +```yaml +--- +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +featureGates: + IPv6DualStack: true +networking: + podSubnet: 10.244.0.0/16,2001:db8:42:0::/56 + serviceSubnet: 10.96.0.0/16,2001:db8:42:1::/112 +--- +apiVersion: kubeadm.k8s.io/v1beta3 +kind: InitConfiguration +localAPIEndpoint: + advertiseAddress: "10.100.0.1" + bindPort: 6443 +nodeRegistration: + kubeletExtraArgs: + node-ip: 10.100.0.2,fd00:1:2:3::2 +``` + +`advertiseAddress` in InitConfiguration specifies the IP address that the API Server will advertise it is listening on. The value of `advertiseAddress` equals the `--apiserver-advertise-address` flag of `kubeadm init` + +Run kubeadm to initiate the dual-stack control plane node: + +```shell +kubeadm init --config=kubeadm-config.yaml +``` + +Currently, the kube-controller-manager flags `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` are being left with default values. See [enable IPv4/IPv6 dual stack](/docs/concepts/services-networking/dual-stack#enable-ipv4ipv6-dual-stack). + +{{< note >}} +The `--apiserver-advertise-address` flag does not support dual-stack. +{{< /note >}} + +### Join a node to dual-stack cluster + +Before joining a node, make sure that the node has IPv6 routable network interface and allows IPv6 forwarding. + +Here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for joining a worker node to the cluster. + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: JoinConfiguration +discovery: + bootstrapToken: + apiServerEndpoint: 10.100.0.1:6443 +nodeRegistration: + kubeletExtraArgs: + node-ip: 10.100.0.3,fd00:1:2:3::3 +``` + +Also, here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for joining another control plane node to the cluster. +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: JoinConfiguration +controlPlane: + localAPIEndpoint: + advertiseAddress: "10.100.0.2" + bindPort: 6443 +discovery: + bootstrapToken: + apiServerEndpoint: 10.100.0.1:6443 +nodeRegistration: + kubeletExtraArgs: + node-ip: 10.100.0.4,fd00:1:2:3::4 + +``` + +`advertiseAddress` in JoinConfiguration.controlPlane specifies the IP address that the API Server will advertise it is listening on. The value of `advertiseAddress` equals the `--apiserver-advertise-address` flag of `kubeadm join`. + +```shell +kubeadm join --config=kubeadm-config.yaml ... +``` + +### Create a single-stack cluster + +{{< note >}} +Enabling the dual-stack feature doesn't mean that you need to use dual-stack addressing. +You can deploy a single-stack cluster that has the dual-stack networking feature enabled. +{{< /note >}} + +In 1.21 the `IPv6DualStack` feature is Beta and the feature gate is defaulted to `true`. To disable the feature you must configure the feature gate to `false`. Note that once the feature is GA, the feature gate will be removed. + +```shell +kubeadm init --feature-gates IPv6DualStack=false +``` + +To make things more clear, here is an example kubeadm [configuration file](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) `kubeadm-config.yaml` for the single-stack control plane node. + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +featureGates: + IPv6DualStack: false +networking: + podSubnet: 10.244.0.0/16 + serviceSubnet: 10.96.0.0/16 +``` + +## {{% heading "whatsnext" %}} + +* [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking +* Read about [Dual-stack](/docs/concepts/services-networking/dual-stack/) cluster networking +* Learn more about the kubeadm [configuration format](/docs/reference/config-api/kubeadm-config.v1beta2/) diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md index e387e2d41c..5206529f5c 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md @@ -115,7 +115,7 @@ option. Your cluster requirements may need a different configuration. {{< note >}} The `kubeadm init` flags `--config` and `--certificate-key` cannot be mixed, therefore if you want - to use the [kubeadm configuration](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2) + to use the [kubeadm configuration](/docs/reference/config-api/kubeadm-config.v1beta3/) you must add the `certificateKey` field in the appropriate config locations (under `InitConfiguration` and `JoinConfiguration: controlPlane`). {{< /note >}} @@ -230,7 +230,7 @@ in the kubeadm config file. 1. Create a file called `kubeadm-config.yaml` with the following contents: - apiVersion: kubeadm.k8s.io/v1beta2 + apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration kubernetesVersion: stable controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index ea144e1dae..7c6a9dd8bf 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -10,8 +10,9 @@ card: -This page shows how to install the `kubeadm` toolbox. -For information how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page. + +This page shows how to install the `kubeadm` toolbox. +For information on how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page. @@ -66,31 +67,9 @@ sudo sysctl --system For more details please see the [Network Plugin Requirements](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) page. ## Check required ports - -### Control-plane node(s) - -| Protocol | Direction | Port Range | Purpose | Used By | -|----------|-----------|------------|-------------------------|---------------------------| -| TCP | Inbound | 6443\* | Kubernetes API server | All | -| TCP | Inbound | 2379-2380 | etcd server client API | kube-apiserver, etcd | -| TCP | Inbound | 10250 | kubelet API | Self, Control plane | -| TCP | Inbound | 10251 | kube-scheduler | Self | -| TCP | Inbound | 10252 | kube-controller-manager | Self | - -### Worker node(s) - -| Protocol | Direction | Port Range | Purpose | Used By | -|----------|-----------|-------------|-----------------------|-------------------------| -| TCP | Inbound | 10250 | kubelet API | Self, Control plane | -| TCP | Inbound | 30000-32767 | NodePort Services† | All | - -† Default port range for [NodePort Services](/docs/concepts/services-networking/service/). - -Any port numbers marked with * are overridable, so you will need to ensure any -custom ports you provide are also open. - -Although etcd ports are included in control-plane nodes, you can also host your own -etcd cluster externally or on custom ports. +These +[required ports](/docs/reference/ports-and-protocols/) +need to be open in order for Kubernetes components to communicate with each other. The pod network plugin you use (see below) may also require certain ports to be open. Since this differs with each pod network plugin, please see the @@ -240,11 +219,12 @@ Install CNI plugins (required for most pod network): ```bash CNI_VERSION="v0.8.2" +ARCH="amd64" sudo mkdir -p /opt/cni/bin -curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz +curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz ``` -Define the directory to download command files +Define the directory to download command files {{< note >}} The `DOWNLOAD_DIR` variable must be set to a writable directory. @@ -260,15 +240,17 @@ Install crictl (required for kubeadm / Kubelet Container Runtime Interface (CRI) ```bash CRICTL_VERSION="v1.17.0" -curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz +ARCH="amd64" +curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz ``` Install `kubeadm`, `kubelet`, `kubectl` and add a `kubelet` systemd service: ```bash RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)" +ARCH="amd64" cd $DOWNLOAD_DIR -sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl} +sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl} sudo chmod +x {kubeadm,kubelet,kubectl} RELEASE_VERSION="v0.4.0" @@ -295,33 +277,17 @@ See the [Kubeadm Troubleshooting guide](/docs/setup/production-environment/tools The kubelet is now restarting every few seconds, as it waits in a crashloop for kubeadm to tell it what to do. -## Configure cgroup driver used by kubelet on control-plane node +## Configuring a cgroup driver -When using Docker, kubeadm will automatically detect the cgroup driver for the kubelet -and set it in the `/var/lib/kubelet/config.yaml` file during runtime. +Both the container runtime and the kubelet have a property called +["cgroup driver"](/docs/setup/production-environment/container-runtimes/), which is important +for the management of cgroups on Linux machines. -If you are using a different CRI, you must pass your `cgroupDriver` value to `kubeadm init`, like so: +{{< warning >}} +Matching the container runtime and kubelet cgroup drivers is required or otherwise the kubelet process will fail. -```yaml -apiVersion: kubelet.config.k8s.io/v1beta1 -kind: KubeletConfiguration -cgroupDriver: -``` - -For further details, please read [Using kubeadm init with a configuration file](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file) -and the [`KubeletConfiguration` reference](/docs/reference/config-api/kubelet-config.v1beta1/) - -Please mind, that you **only** have to do that if the cgroup driver of your CRI -is not `cgroupfs`, because that is the default value in the kubelet already. - -{{< note >}} -Since `--cgroup-driver` flag has been deprecated by the kubelet, if you have that in `/var/lib/kubelet/kubeadm-flags.env` -or `/etc/default/kubelet`(`/etc/sysconfig/kubelet` for RPMs), please remove it and use the KubeletConfiguration instead -(stored in `/var/lib/kubelet/config.yaml` by default). -{{< /note >}} - -The automatic detection of cgroup driver for other container runtimes -like CRI-O and containerd is work in progress. +See [Configuring a cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/) for more details. +{{< /warning >}} ## Troubleshooting @@ -330,4 +296,3 @@ If you are running into difficulties with kubeadm, please consult our [troublesh ## {{% heading "whatsnext" %}} * [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) - diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md deleted file mode 100644 index d860a88bdd..0000000000 --- a/content/en/docs/setup/production-environment/tools/kubeadm/self-hosting.md +++ /dev/null @@ -1,68 +0,0 @@ ---- -reviewers: -- sig-cluster-lifecycle -title: Configuring your kubernetes cluster to self-host the control plane -content_type: concept -weight: 100 ---- - - - -### Self-hosting the Kubernetes control plane {#self-hosting} - -kubeadm allows you to experimentally create a _self-hosted_ Kubernetes control -plane. This means that key components such as the API server, controller -manager, and scheduler run as [DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/) -configured via the Kubernetes API instead of [static pods](/docs/tasks/configure-pod-container/static-pod/) -configured in the kubelet via static files. - -To create a self-hosted cluster see the -[kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) command. - - - -#### Caveats - -{{< caution >}} -This feature pivots your cluster into an unsupported state, rendering kubeadm unable -to manage you cluster any longer. This includes `kubeadm upgrade`. -{{< /caution >}} - -1. Self-hosting in 1.8 and later has some important limitations. In particular, a - self-hosted cluster _cannot recover from a reboot of the control-plane node_ - without manual intervention. - -1. By default, self-hosted control plane Pods rely on credentials loaded from - [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - volumes. Except for initial creation, these credentials are not managed by - kubeadm. - -1. The self-hosted portion of the control plane does not include etcd, - which still runs as a static Pod. - -#### Process - -The self-hosting bootstrap process is documented in the [kubeadm design -document](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting). - -In summary, `kubeadm alpha selfhosting` works as follows: - - 1. Waits for this bootstrap static control plane to be running and - healthy. This is identical to the `kubeadm init` process without self-hosting. - - 1. Uses the static control plane Pod manifests to construct a set of - DaemonSet manifests that will run the self-hosted control plane. - It also modifies these manifests where necessary, for example adding new volumes - for secrets. - - 1. Creates DaemonSets in the `kube-system` namespace and waits for the - resulting Pods to be running. - - 1. Once self-hosted Pods are operational, their associated static Pods are deleted - and kubeadm moves on to install the next component. This triggers kubelet to - stop those static Pods. - - 1. When the original static control plane stops, the new self-hosted control - plane is able to bind to listening ports and become active. - - diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md index 6f62a051ad..0319ee17fc 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md @@ -95,7 +95,7 @@ this example. HOST=${ETCDHOSTS[$i]} NAME=${NAMES[$i]} cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml - apiVersion: "kubeadm.k8s.io/v1beta2" + apiVersion: "kubeadm.k8s.io/v1beta3" kind: ClusterConfiguration etcd: local: @@ -246,8 +246,8 @@ this example. ```sh root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml - root@HOST1 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml - root@HOST2 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml + root@HOST1 $ kubeadm init phase etcd local --config=/tmp/${HOST1}/kubeadmcfg.yaml + root@HOST2 $ kubeadm init phase etcd local --config=/tmp/${HOST2}/kubeadmcfg.yaml ``` 1. Optional: Check the cluster health diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md index 58f4f4652a..8baf5e9dd6 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md @@ -89,23 +89,11 @@ If you notice that `kubeadm init` hangs after printing out the following line: This may be caused by a number of problems. The most common are: - network connection problems. Check that your machine has full network connectivity before continuing. -- the default cgroup driver configuration for the kubelet differs from that used by Docker. - Check the system log file (e.g. `/var/log/message`) or examine the output from `journalctl -u kubelet`. If you see something like the following: - - ```shell - error: failed to run Kubelet: failed to create kubelet: - misconfiguration: kubelet cgroup driver: "systemd" is different from docker cgroup driver: "cgroupfs" - ``` - - There are two common ways to fix the cgroup driver problem: - - 1. Install Docker again following instructions - [here](/docs/setup/production-environment/container-runtimes/#docker). - - 1. Change the kubelet config to match the Docker cgroup driver manually, you can refer to - [Configure cgroup driver used by kubelet on control-plane node](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node) - -- control plane Docker containers are crashlooping or hanging. You can check this by running `docker ps` and investigating each container by running `docker logs`. +- the cgroup driver of the container runtime differs from that of the kubelet. To understand how to +configure it properly see [Configuring a cgroup driver](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/). +- control plane containers are crashlooping or hanging. You can check this by running `docker ps` +and investigating each container by running `docker logs`. For other container runtime see +[Debugging Kubernetes nodes with crictl](/docs/tasks/debug-application-cluster/crictl/). ## kubeadm blocks when removing managed containers @@ -153,7 +141,7 @@ Right after `kubeadm init` there should not be any pods in these states. MountFlags can interfere with volumes mounted by Kubernetes, and put the Pods in `CrashLoopBackOff` state. The error happens when Kubernetes does not find `var/run/secrets/kubernetes.io/serviceaccount` files. -## `coredns` (or `kube-dns`) is stuck in the `Pending` state +## `coredns` is stuck in the `Pending` state This is **expected** and part of the design. kubeadm is network provider-agnostic, so the admin should [install the pod network add-on](/docs/concepts/cluster-administration/addons/) @@ -175,7 +163,7 @@ services](/docs/concepts/services-networking/service/#nodeport) or use `HostNetw ## Pods are not accessible via their Service IP -- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip) +- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-fails-to-reach-itself-via-the-service-ip) which allows pods to access themselves via their Service IP. This is an issue related to [CNI](https://github.com/containernetworking/cni/issues/476). Please contact the network add-on provider to get the latest status of their support for hairpin mode. @@ -220,6 +208,25 @@ Unable to connect to the server: x509: certificate signed by unknown authority ( sudo chown $(id -u):$(id -g) $HOME/.kube/config ``` +## Kubelet client certificate rotation fails {#kubelet-client-cert} + +By default, kubeadm configures a kubelet with automatic rotation of client certificates by using the `/var/lib/kubelet/pki/kubelet-client-current.pem` symlink specified in `/etc/kubernetes/kubelet.conf`. +If this rotation process fails you might see errors such as `x509: certificate has expired or is not yet valid` +in kube-apiserver logs. To fix the issue you must follow these steps: + +1. Backup and delete `/etc/kubernetes/kubelet.conf` and `/var/lib/kubelet/pki/kubelet-client*` from the failed node. +1. From a working control plane node in the cluster that has `/etc/kubernetes/pki/ca.key` execute +`kubeadm kubeconfig user --org system:nodes --client-name system:node:$NODE > kubelet.conf`. +`$NODE` must be set to the name of the existing failed node in the cluster. +Modify the resulted `kubelet.conf` manually to adjust the cluster name and server endpoint, +or pass `kubeconfig user --config` (it accepts `InitConfiguration`). If your cluster does not have +the `ca.key` you must sign the embedded certificates in the `kubelet.conf` externally. +1. Copy this resulted `kubelet.conf` to `/etc/kubernetes/kubelet.conf` on the failed node. +1. Restart the kubelet (`systemctl restart kubelet`) on the failed node and wait for +`/var/lib/kubelet/pki/kubelet-client-current.pem` to be recreated. +1. Run `kubeadm init phase kubelet-finalize all` on the failed node. This will make the new +`kubelet.conf` file use `/var/lib/kubelet/pki/kubelet-client-current.pem` and will restart the kubelet. +1. Make sure the node becomes `Ready`. ## Default NIC When using flannel as the pod network in Vagrant The following error might indicate that something was wrong in the pod network: @@ -251,7 +258,12 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6 curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address ``` - The workaround is to tell `kubelet` which IP to use using `--node-ip`. When using DigitalOcean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this. + The workaround is to tell `kubelet` which IP to use using `--node-ip`. + When using DigitalOcean, it can be the public one (assigned to `eth0`) or + the private one (assigned to `eth1`) should you want to use the optional + private network. The `kubeletExtraArgs` section of the kubeadm + [`NodeRegistrationOptions` structure](/docs/reference/config-api/kubeadm-config.v1beta2/#kubeadm-k8s-io-v1beta2-NodeRegistrationOptions) + can be used for this. Then restart `kubelet`: @@ -324,7 +336,7 @@ Alternatively, you can try separating the `key=value` pairs like so: `--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"` but this will result in the key `enable-admission-plugins` only having the value of `NamespaceExists`. -A known workaround is to use the kubeadm [configuration file](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags). +A known workaround is to use the kubeadm [configuration file](/docs/reference/config-api/kubeadm-config.v1beta2/). ## kube-proxy scheduled before node is initialized by cloud-controller-manager @@ -348,23 +360,6 @@ kubectl -n kube-system patch ds kube-proxy -p='{ "spec": { "template": { "spec": The tracking issue for this problem is [here](https://github.com/kubernetes/kubeadm/issues/1027). -## The NodeRegistration.Taints field is omitted when marshalling kubeadm configuration - -*Note: This [issue](https://github.com/kubernetes/kubeadm/issues/1358) only applies to tools that marshal kubeadm types (e.g. to a YAML configuration file). It will be fixed in kubeadm API v1beta2.* - -By default, kubeadm applies the `node-role.kubernetes.io/master:NoSchedule` taint to control-plane nodes. -If you prefer kubeadm to not taint the control-plane node, and set `InitConfiguration.NodeRegistration.Taints` to an empty slice, -the field will be omitted when marshalling. When the field is omitted, kubeadm applies the default taint. - -There are at least two workarounds: - -1. Use the `node-role.kubernetes.io/master:PreferNoSchedule` taint instead of an empty slice. [Pods will get scheduled on masters](/docs/concepts/scheduling-eviction/taint-and-toleration/), unless other nodes have capacity. - -2. Remove the taint after kubeadm init exits: -```bash -kubectl taint nodes NODE_NAME node-role.kubernetes.io/master:NoSchedule- -``` - ## `/usr` is mounted read-only on nodes {#usr-mounted-read-only} On Linux distributions such as Fedora CoreOS or Flatcar Container Linux, the directory `/usr` is mounted as a read-only filesystem. @@ -374,19 +369,19 @@ Kubernetes components like the kubelet and kube-controller-manager use the defau for the feature to work. To workaround this issue you can configure the flex-volume directory using the kubeadm -[configuration file](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2). +[configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/). On the primary control-plane Node (created using `kubeadm init`) pass the following file using `--config`: ```yaml -apiVersion: kubeadm.k8s.io/v1beta2 +apiVersion: kubeadm.k8s.io/v1beta3 kind: InitConfiguration nodeRegistration: kubeletExtraArgs: volume-plugin-dir: "/opt/libexec/kubernetes/kubelet-plugins/volume/exec/" --- -apiVersion: kubeadm.k8s.io/v1beta2 +apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration controllerManager: extraArgs: @@ -396,7 +391,7 @@ controllerManager: On joining Nodes: ```yaml -apiVersion: kubeadm.k8s.io/v1beta2 +apiVersion: kubeadm.k8s.io/v1beta3 kind: JoinConfiguration nodeRegistration: kubeletExtraArgs: @@ -408,7 +403,7 @@ be advised that this is modifying a design principle of the Linux distribution. ## `kubeadm upgrade plan` prints out `context deadline exceeded` error message -This error message is shown when upgrading a Kubernetes cluster with `kubeadm` in the case of running an external etcd. This is not a critical bug and happens because older versions of kubeadm perform a version check on the external etcd cluster. You can proceed with `kubeadm upgrade apply ...`. +This error message is shown when upgrading a Kubernetes cluster with `kubeadm` in the case of running an external etcd. This is not a critical bug and happens because older versions of kubeadm perform a version check on the external etcd cluster. You can proceed with `kubeadm upgrade apply ...`. This issue is fixed as of version 1.19. @@ -420,3 +415,20 @@ To workaround the issue, re-mount the `/var/lib/kubelet` directory after perform This is a regression introduced in kubeadm 1.15. The issue is fixed in 1.20. +## Cannot use the metrics-server securely in a kubeadm cluster + +In a kubeadm cluster, the [metrics-server](https://github.com/kubernetes-sigs/metrics-server) +can be used insecurely by passing the `--kubelet-insecure-tls` to it. This is not recommended for production clusters. + +If you want to use TLS between the metrics-server and the kubelet there is a problem, +since kubeadm deploys a self-signed serving certificate for the kubelet. This can cause the following errors +on the side of the metrics-server: +``` +x509: certificate signed by unknown authority +x509: certificate is valid for IP-foo not IP-bar +``` + +See [Enabling signed kubelet serving certificates](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#kubelet-serving-certs) +to understand how to configure the kubelets in a kubeadm cluster to have properly signed serving certificates. + +Also see [How to run the metrics-server securely](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md#how-to-run-metrics-server-securely). diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md index c4300b53a2..08893370cf 100644 --- a/content/en/docs/setup/production-environment/tools/kubespray.md +++ b/content/en/docs/setup/production-environment/tools/kubespray.md @@ -50,7 +50,7 @@ Kubespray provides the following utilities to help provision your environment: ### (2/5) Compose an inventory file -After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". +After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/latest/network/getting_started/first_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". ### (3/5) Plan your cluster deployment diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index b8d5cd3c9b..c3757824c5 100644 --- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -1,33 +1,58 @@ --- +title: Intro to Windows support in Kubernetes +content_type: concept +weight: 65 reviewers: - jayunit100 - jsturtevant - marosset - perithompson -title: Intro to Windows support in Kubernetes -content_type: concept -weight: 65 --- -Windows applications constitute a large portion of the services and applications that run in many organizations. [Windows containers](https://aka.ms/windowscontainers) provide a modern way to encapsulate processes and package dependencies, making it easier to use DevOps practices and follow cloud native patterns for Windows applications. Kubernetes has become the defacto standard container orchestrator, and the release of Kubernetes 1.14 includes production support for scheduling Windows containers on Windows nodes in a Kubernetes cluster, enabling a vast ecosystem of Windows applications to leverage the power of Kubernetes. Organizations with investments in Windows-based applications and Linux-based applications don't have to look for separate orchestrators to manage their workloads, leading to increased operational efficiencies across their deployments, regardless of operating system. +Windows applications constitute a large portion of the services and +applications that run in many organizations. +[Windows containers](https://aka.ms/windowscontainers) provide a modern way to +encapsulate processes and package dependencies, making it easier to use DevOps +practices and follow cloud native patterns for Windows applications. +Kubernetes has become the defacto standard container orchestrator, and the +release of Kubernetes 1.14 includes production support for scheduling Windows +containers on Windows nodes in a Kubernetes cluster, enabling a vast ecosystem +of Windows applications to leverage the power of Kubernetes. Organizations +with investments in Windows-based applications and Linux-based applications +don't have to look for separate orchestrators to manage their workloads, +leading to increased operational efficiencies across their deployments, +regardless of operating system. ## Windows containers in Kubernetes -To enable the orchestration of Windows containers in Kubernetes, include Windows nodes in your existing Linux cluster. Scheduling Windows containers in {{< glossary_tooltip text="Pods" term_id="pod" >}} on Kubernetes is similar to scheduling Linux-based containers. +To enable the orchestration of Windows containers in Kubernetes, include +Windows nodes in your existing Linux cluster. Scheduling Windows containers in +{{< glossary_tooltip text="Pods" term_id="pod" >}} on Kubernetes is similar to +scheduling Linux-based containers. -In order to run Windows containers, your Kubernetes cluster must include multiple operating systems, with control plane nodes running Linux and workers running either Windows or Linux depending on your workload needs. Windows Server 2019 is the only Windows operating system supported, enabling [Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) on Windows (including kubelet, [container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd), and kube-proxy). For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19). +In order to run Windows containers, your Kubernetes cluster must include +multiple operating systems, with control plane nodes running Linux and workers +running either Windows or Linux depending on your workload needs. Windows +Server 2019 is the only Windows operating system supported, enabling +[Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) +on Windows (including kubelet, +[container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd), +and kube-proxy). For a detailed explanation of Windows distribution channels +see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19). -{{< note >}} -The Kubernetes control plane, including the [master components](/docs/concepts/overview/components/), continues to run on Linux. There are no plans to have a Windows-only Kubernetes cluster. -{{< /note >}} +The Kubernetes control plane, including the +[master components](/docs/concepts/overview/components/), +continues to run on Linux. +There are no plans to have a Windows-only Kubernetes cluster. -{{< note >}} -In this document, when we talk about Windows containers we mean Windows containers with process isolation. Windows containers with [Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) is planned for a future release. -{{< /note >}} +In this document, when we talk about Windows containers we mean Windows +containers with process isolation. Windows containers with +[Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container) +is planned for a future release. ## Supported Functionality and Limitations @@ -35,41 +60,73 @@ In this document, when we talk about Windows containers we mean Windows containe #### Windows OS Version Support -Refer to the following table for Windows operating system support in Kubernetes. A single heterogeneous Kubernetes cluster can have both Windows and Linux worker nodes. Windows containers have to be scheduled on Windows nodes and Linux containers on Linux nodes. +Refer to the following table for Windows operating system support in +Kubernetes. A single heterogeneous Kubernetes cluster can have both Windows +and Linux worker nodes. Windows containers have to be scheduled on Windows +nodes and Linux containers on Linux nodes. | Kubernetes version | Windows Server LTSC releases | Windows Server SAC releases | | --- | --- | --- | --- | -| *Kubernetes v1.17* | Windows Server 2019 | Windows Server ver 1809 | -| *Kubernetes v1.18* | Windows Server 2019 | Windows Server ver 1809, Windows Server ver 1903, Windows Server ver 1909 | -| *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 | | *Kubernetes v1.20* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 | +| *Kubernetes v1.21* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 | +| *Kubernetes v1.22* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 | -{{< note >}} -Information on the different Windows Server servicing channels including their support models can be found at [Windows Server servicing channels](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19). -{{< /note >}} -{{< note >}} -We don't expect all Windows customers to update the operating system for their apps frequently. Upgrading your applications is what dictates and necessitates upgrading or introducing new nodes to the cluster. For the customers that chose to upgrade their operating system for containers running on Kubernetes, we will offer guidance and step-by-step instructions when we add support for a new operating system version. This guidance will include recommended upgrade procedures for upgrading user applications together with cluster nodes. Windows nodes adhere to Kubernetes [version-skew policy](/docs/setup/release/version-skew-policy/) (node to control plane versioning) the same way as Linux nodes do today. -{{< /note >}} -{{< note >}} -The Windows Server Host Operating System is subject to the [Windows Server ](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) licensing. The Windows Container images are subject to the [Supplemental License Terms for Windows containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula). -{{< /note >}} -{{< note >}} -Windows containers with process isolation have strict compatibility rules, [where the host OS version must match the container base image OS version](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility). Once we support Windows containers with Hyper-V isolation in Kubernetes, the limitation and compatibility rules will change. -{{< /note >}} +Information on the different Windows Server servicing channels including their +support models can be found at +[Windows Server servicing channels](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19). + +We don't expect all Windows customers to update the operating system for their +apps frequently. Upgrading your applications is what dictates and necessitates +upgrading or introducing new nodes to the cluster. For the customers that +chose to upgrade their operating system for containers running on Kubernetes, +we will offer guidance and step-by-step instructions when we add support for a +new operating system version. This guidance will include recommended upgrade +procedures for upgrading user applications together with cluster nodes. +Windows nodes adhere to Kubernetes +[version-skew policy](/docs/setup/release/version-skew-policy/) (node to control plane +versioning) the same way as Linux nodes do today. + + +The Windows Server Host Operating System is subject to the +[Windows Server ](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing) +licensing. The Windows Container images are subject to the +[Supplemental License Terms for Windows containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula). + +Windows containers with process isolation have strict compatibility rules, +[where the host OS version must match the container base image OS version](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility). +Once we support Windows containers with Hyper-V isolation in Kubernetes, the +limitation and compatibility rules will change. #### Pause Image -Microsoft maintains a Windows pause infrastructure container at `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`. +Kubernetes maintains a multi-architecture image that includes support for Windows. +For Kubernetes v1.22 the recommended pause image is `k8s.gcr.io/pause:3.5`. +The [source code](https://github.com/kubernetes/kubernetes/tree/master/build/pause) +is available on GitHub. + +Microsoft maintains a multi-architecture image with Linux and Windows amd64 support at `mcr.microsoft.com/oss/kubernetes/pause:3.5`. +This image is built from the same source as the Kubernetes maintained image but all of the Windows binaries are [authenticode signed](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode) by Microsoft. +The Microsoft maintained image is recommended for production environments when signed binaries are required. #### Compute -From an API and kubectl perspective, Windows containers behave in much the same way as Linux-based containers. However, there are some notable differences in key functionality which are outlined in the [limitation section](#limitations). +From an API and kubectl perspective, Windows containers behave in much the +same way as Linux-based containers. However, there are some notable +differences in key functionality which are outlined in the +[limitation section](#limitations). -Key Kubernetes elements work the same way in Windows as they do in Linux. In this section, we talk about some of the key workload enablers and how they map to Windows. +Key Kubernetes elements work the same way in Windows as they do in Linux. In +this section, we talk about some of the key workload enablers and how they map +to Windows. * [Pods](/docs/concepts/workloads/pods/) - A Pod is the basic building block of Kubernetes–the smallest and simplest unit in the Kubernetes object model that you create or deploy. You may not deploy Windows and Linux containers in the same Pod. All containers in a Pod are scheduled onto a single Node where each Node represents a specific platform and architecture. The following Pod capabilities, properties and events are supported with Windows containers: + A Pod is the basic building block of Kubernetes–the smallest and simplest + unit in the Kubernetes object model that you create or deploy. You may not + deploy Windows and Linux containers in the same Pod. All containers in a Pod + are scheduled onto a single Node where each Node represents a specific + platform and architecture. The following Pod capabilities, properties and + events are supported with Windows containers: * Single or multiple containers per Pod with process isolation and volume sharing * Pod status fields @@ -81,7 +138,8 @@ Key Kubernetes elements work the same way in Windows as they do in Linux. In thi * Resource limits * [Controllers](/docs/concepts/workloads/controllers/) - Kubernetes controllers handle the desired state of Pods. The following workload controllers are supported with Windows containers: + Kubernetes controllers handle the desired state of Pods. The following + workload controllers are supported with Windows containers: * ReplicaSet * ReplicationController @@ -90,9 +148,13 @@ Key Kubernetes elements work the same way in Windows as they do in Linux. In thi * DaemonSet * Job * CronJob + * [Services](/docs/concepts/services-networking/service/) - A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them - sometimes called a micro-service. You can use services for cross-operating system connectivity. In Windows, services can utilize the following types, properties and capabilities: + A Kubernetes Service is an abstraction which defines a logical set of Pods + and a policy by which to access them - sometimes called a micro-service. You + can use services for cross-operating system connectivity. In Windows, services + can utilize the following types, properties and capabilities: * Service Environment variables * NodePort @@ -101,7 +163,10 @@ Key Kubernetes elements work the same way in Windows as they do in Linux. In thi * ExternalName * Headless services -Pods, Controllers and Services are critical elements to managing Windows workloads on Kubernetes. However, on their own they are not enough to enable the proper lifecycle management of Windows workloads in a dynamic cloud native environment. We added support for the following features: +Pods, Controllers and Services are critical elements to managing Windows +workloads on Kubernetes. However, on their own they are not enough to enable +the proper lifecycle management of Windows workloads in a dynamic cloud native +environment. We added support for the following features: * Pod and container metrics * Horizontal Pod Autoscaler support @@ -115,27 +180,42 @@ Pods, Controllers and Services are critical elements to managing Windows workloa {{< feature-state for_k8s_version="v1.14" state="stable" >}} -Docker EE-basic 19.03+ is the recommended container runtime for all Windows Server versions. This works with the dockershim code included in the kubelet. +Docker EE-basic 19.03+ is the recommended container runtime for all Windows +Server versions. This works with the dockershim code included in the kubelet. ##### CRI-ContainerD {{< feature-state for_k8s_version="v1.20" state="stable" >}} -{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+ can also be used as the container runtime for Windows Kubernetes nodes. +{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+ can +also be used as the container runtime for Windows Kubernetes nodes. -Learn how to [install ContainerD on a Windows](/docs/setup/production-environment/container-runtimes/#install-containerd). - -{{< caution >}} -There is a [known limitation](/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations) when using GMSA with ContainerD to access Windows network shares which requires a kernel patch. Updates to address this limitation are currently available for Windows Server, Version 2004 and will be available for Windows Server 2019 in early 2021. Check for updates on the [Microsoft Windows Containers issue tracker](https://github.com/microsoft/Windows-Containers/issues/44). -{{< /caution >}} +Learn how to +[install ContainerD on a Windows](/docs/setup/production-environment/container-runtimes/#install-containerd). #### Persistent Storage -Kubernetes [volumes](/docs/concepts/storage/volumes/) enable complex applications, with data persistence and Pod volume sharing requirements, to be deployed on Kubernetes. Management of persistent volumes associated with a specific storage back-end or protocol includes actions such as: provisioning/de-provisioning/resizing of volumes, attaching/detaching a volume to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod that needs to persist data. The code implementing these volume management actions for a specific storage back-end or protocol is shipped in the form of a Kubernetes volume [plugin](/docs/concepts/storage/volumes/#types-of-volumes). The following broad classes of Kubernetes volume plugins are supported on Windows: +Kubernetes [volumes](/docs/concepts/storage/volumes/) enable complex +applications, with data persistence and Pod volume sharing requirements, to be +deployed on Kubernetes. Management of persistent volumes associated with a +specific storage back-end or protocol includes actions such as: +provisioning/de-provisioning/resizing of volumes, attaching/detaching a volume +to/from a Kubernetes node and mounting/dismounting a volume to/from individual +containers in a pod that needs to persist data. The code implementing these +volume management actions for a specific storage back-end or protocol is +shipped in the form of a Kubernetes volume +[plugin](/docs/concepts/storage/volumes/#types-of-volumes). The following +broad classes of Kubernetes volume plugins are supported on Windows: ##### In-tree Volume Plugins -Code associated with in-tree volume plugins ship as part of the core Kubernetes code base. Deployment of in-tree volume plugins do not require installation of additional scripts or deployment of separate containerized plugin components. These plugins can handle: provisioning/de-provisioning and resizing of volumes in the storage backend, attaching/detaching of volumes to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod. The following in-tree plugins support Windows nodes: +Code associated with in-tree volume plugins ship as part of the core +Kubernetes code base. Deployment of in-tree volume plugins do not require +installation of additional scripts or deployment of separate containerized +plugin components. These plugins can handle: provisioning/de-provisioning and +resizing of volumes in the storage backend, attaching/detaching of volumes +to/from a Kubernetes node and mounting/dismounting a volume to/from individual +containers in a pod. The following in-tree plugins support Windows nodes: * [awsElasticBlockStore](/docs/concepts/storage/volumes/#awselasticblockstore) * [azureDisk](/docs/concepts/storage/volumes/#azuredisk) @@ -145,22 +225,52 @@ Code associated with in-tree volume plugins ship as part of the core Kubernetes ##### FlexVolume Plugins -Code associated with [FlexVolume](/docs/concepts/storage/volumes/#flexVolume) plugins ship as out-of-tree scripts or binaries that need to be deployed directly on the host. FlexVolume plugins handle attaching/detaching of volumes to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod. Provisioning/De-provisioning of persistent volumes associated with FlexVolume plugins may be handled through an external provisioner that is typically separate from the FlexVolume plugins. The following FlexVolume [plugins](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows), deployed as powershell scripts on the host, support Windows nodes: +Code associated with [FlexVolume](/docs/concepts/storage/volumes/#flexVolume) +plugins ship as out-of-tree scripts or binaries that need to be deployed +directly on the host. FlexVolume plugins handle attaching/detaching of volumes +to/from a Kubernetes node and mounting/dismounting a volume to/from individual +containers in a pod. Provisioning/De-provisioning of persistent volumes +associated with FlexVolume plugins may be handled through an external +provisioner that is typically separate from the FlexVolume plugins. The +following FlexVolume +[plugins](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows), +deployed as powershell scripts on the host, support Windows nodes: * [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd) * [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd) ##### CSI Plugins -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.22" state="stable" >}} -Code associated with {{< glossary_tooltip text="CSI" term_id="csi" >}} plugins ship as out-of-tree scripts and binaries that are typically distributed as container images and deployed using standard Kubernetes constructs like DaemonSets and StatefulSets. CSI plugins handle a wide range of volume management actions in Kubernetes: provisioning/de-provisioning/resizing of volumes, attaching/detaching of volumes to/from a Kubernetes node and mounting/dismounting a volume to/from individual containers in a pod, backup/restore of persistent data using snapshots and cloning. CSI plugins typically consist of node plugins (that run on each node as a DaemonSet) and controller plugins. +Code associated with {{< glossary_tooltip text="CSI" term_id="csi" >}} plugins +ship as out-of-tree scripts and binaries that are typically distributed as +container images and deployed using standard Kubernetes constructs like +DaemonSets and StatefulSets. CSI plugins handle a wide range of volume +management actions in Kubernetes: provisioning/de-provisioning/resizing of +volumes, attaching/detaching of volumes to/from a Kubernetes node and +mounting/dismounting a volume to/from individual containers in a pod, +backup/restore of persistent data using snapshots and cloning. -CSI node plugins (especially those associated with persistent volumes exposed as either block devices or over a shared file-system) need to perform various privileged operations like scanning of disk devices, mounting of file systems, etc. These operations differ for each host operating system. For Linux worker nodes, containerized CSI node plugins are typically deployed as privileged containers. For Windows worker nodes, privileged operations for containerized CSI node plugins is supported using [csi-proxy](https://github.com/kubernetes-csi/csi-proxy), a community-managed, stand-alone binary that needs to be pre-installed on each Windows node. Please refer to the deployment guide of the CSI plugin you wish to deploy for further details. +CSI plugins communicate with a CSI node plugin which performs the local storage operations. +On Windows nodes CSI node plugins typically call APIs exposed by the community-managed +[csi-proxy](https://github.com/kubernetes-csi/csi-proxy) which handles the local storage operations. + +Please refer to the deployment guide of the environment where you wish to deploy a Windows CSI plugin +for further details around installation. +You may also refer to the following [installation steps](https://github.com/kubernetes-csi/csi-proxy#installation). #### Networking -Networking for Windows containers is exposed through [CNI plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Windows containers function similarly to virtual machines in regards to networking. Each container has a virtual network adapter (vNIC) which is connected to a Hyper-V virtual switch (vSwitch). The Host Networking Service (HNS) and the Host Compute Service (HCS) work together to create containers and attach container vNICs to networks. HCS is responsible for the management of containers whereas HNS is responsible for the management of networking resources such as: +Networking for Windows containers is exposed through +[CNI plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). +Windows containers function similarly to virtual machines in regards to +networking. Each container has a virtual network adapter (vNIC) which is +connected to a Hyper-V virtual switch (vSwitch). The Host Networking Service +(HNS) and the Host Compute Service (HCS) work together to create containers +and attach container vNICs to networks. HCS is responsible for the management +of containers whereas HNS is responsible for the management of networking +resources such as: * Virtual networks (including creation of vSwitches) * Endpoints / vNICs @@ -176,19 +286,155 @@ The following service spec types are supported: ##### Network modes -Windows supports five different networking drivers/modes: L2bridge, L2tunnel, Overlay, Transparent, and NAT. In a heterogeneous cluster with Windows and Linux worker nodes, you need to select a networking solution that is compatible on both Windows and Linux. The following out-of-tree plugins are supported on Windows, with recommendations on when to use each CNI: +Windows supports five different networking drivers/modes: L2bridge, L2tunnel, +Overlay, Transparent, and NAT. In a heterogeneous cluster with Windows and +Linux worker nodes, you need to select a networking solution that is +compatible on both Windows and Linux. The following out-of-tree plugins are +supported on Windows, with recommendations on when to use each CNI: -| Network Driver | Description | Container Packet Modifications | Network Plugins | Network Plugin Characteristics | -| -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ | -| L2bridge | Containers are attached to an external vSwitch. Containers are attached to the underlay network, although the physical network doesn't need to learn the container MACs because they are rewritten on ingress/egress. | MAC is rewritten to host MAC, IP may be rewritten to host IP using HNS OutboundNAT policy. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel host-gateway uses win-bridge | win-bridge uses L2bridge network mode, connects containers to the underlay of hosts, offering best performance. Requires user-defined routes (UDR) for inter-node connectivity. | -| L2Tunnel | This is a special case of l2bridge, but only used on Azure. All packets are sent to the virtualization host where SDN policy is applied. | MAC rewritten, IP visible on the underlay network | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI allows integration of containers with Azure vNET, and allows them to leverage the set of capabilities that [Azure Virtual Network provides](https://azure.microsoft.com/en-us/services/virtual-network/). For example, securely connect to Azure services or use Azure NSGs. See [azure-cni for some examples](https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-cni-advanced-networking) | -| Overlay (Overlay networking for Windows in Kubernetes is in *alpha* stage) | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header. | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags) if you are restricted on IPs in your datacenter. This option requires [KB4489899](https://support.microsoft.com/help/4489899) on Windows Server 2019. | -| Transparent (special use case for [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)) | Requires an external vSwitch. Containers are attached to an external vSwitch which enables intra-pod communication via logical networks (logical switches and routers). | Packet is encapsulated either via [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) or [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) tunneling to reach pods which are not on the same host.
Packets are forwarded or dropped via the tunnel metadata information supplied by the ovn network controller.
NAT is done for north-south communication. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [Deploy via ansible](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib). Distributed ACLs can be applied via Kubernetes policies. IPAM support. Load-balancing can be achieved without kube-proxy. NATing is done without using iptables/netsh. | -| NAT (*not used in Kubernetes*) | Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is provided using an internal component called [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/) | MAC and IP is rewritten to host MAC/IP. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | Included here for completeness | +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Network DriverDescriptionContainer Packet ModificationsNetwork PluginsNetwork Plugin Characteristics
L2bridgeContainers are attached to an external vSwitch. Containers are attached + to the underlay network, although the physical network doesn't need to learn + the container. MACs because they are rewritten on ingress/egress. + + MAC is rewritten to host MAC, IP may be rewritten to host IP using HNS + OutboundNAT policy. + + win-bridge, + Azure-CNI, + Flannel host-gateway uses win-bridge + + win-bridge uses L2bridge network mode, + connects containers to the underlay of hosts, offering best performance. + Requires user-defined routes (UDR) for inter-node connectivity. +
L2Tunnel + This is a special case of l2bridge, but only used on Azure. All packets + are sent to the virtualization host where SDN policy is applied. + + MAC rewritten, IP visible on the underlay network + + Azure-CNI + + Azure-CNI allows integration of containers with Azure vNET, and allows them + to leverage the set of capabilities that + Azure Virtual Network + provides. For example, securely connect to Azure services or use Azure NSGs. + See azure-cni + for some examples. +
Overlay (Overlay networking for Windows in Kubernetes is in Alpha stage) + Containers are given a vNIC connected to an external vSwitch. Each overlay + network gets its own IP subnet, defined by a custom IP prefix.The overlay + network driver uses VXLAN encapsulation. + + Encapsulated with an outer header. + + Win-overlay, + Flannel VXLAN (uses win-overlay) + + win-overlay should be used when virtual container networks are desired to + be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs + to be re-used for different overlay networks (which have different VNID tags) + if you are restricted on IPs in your datacenter. This option requires + KB4489899 on Windows Server + 2019. +
+ Transparent (special use case for ovn-kubernetes) + + Requires an external vSwitch. Containers are attached to an external + vSwitch which enables intra-pod communication via logical networks (logical + switches and routers). + + Packet is encapsulated either via + GENEVE, + STT tunneling to reach + pods which are not on the same host.
Packets are forwarded or dropped + via the tunnel metadata information supplied by the ovn network controller. +
+ NAT is done for north-south communication. + 		+ ovn-kubernetes + + Deploy via Ansible. + Distributed ACLs can be applied via Kubernetes policies. IPAM support. + Load-balancing can be achieved without kube-proxy. NATing is done without + using iptables/netsh. +
NAT (not used in Kubernetes) + Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is + provided using an internal component called + WinNAT. + + MAC and IP is rewritten to host MAC/IP. + + nat + + Included here for completeness +
-As outlined above, the [Flannel](https://github.com/coreos/flannel) CNI [meta plugin](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel) is also supported on [Windows](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental) via the [VXLAN network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) (**alpha support** ; delegates to win-overlay) and [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (stable support; delegates to win-bridge). This plugin supports delegating to one of the reference CNI plugins (win-overlay, win-bridge), to work in conjunction with Flannel daemon on Windows (Flanneld) for automatic node subnet lease assignment and HNS network creation. This plugin reads in its own configuration file (cni.conf), and aggregates it with the environment variables from the FlannelD generated subnet.env file. It then delegates to one of the reference CNI plugins for network plumbing, and sends the correct configuration containing the node-assigned subnet to the IPAM plugin (e.g. host-local). +As outlined above, the [Flannel](https://github.com/coreos/flannel) CNI +[meta plugin](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel) +is also supported on +[Windows](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental) +via the [VXLAN network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) +(**alpha support** ; delegates to win-overlay) and +[host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) +(stable support; delegates to win-bridge). This plugin supports delegating to +one of the reference CNI plugins (win-overlay, win-bridge), to work in +conjunction with Flannel daemon on Windows (Flanneld) for automatic node +subnet lease assignment and HNS network creation. This plugin reads in its own +configuration file (cni.conf), and aggregates it with the environment +variables from the FlannelD generated subnet.env file. It then delegates to +one of the reference CNI plugins for network plumbing, and sends the correct +configuration containing the node-assigned subnet to the IPAM plugin (e.g. +host-local). -For the node, pod, and service objects, the following network flows are supported for TCP/UDP traffic: +For the node, pod, and service objects, the following network flows are +supported for TCP/UDP traffic: * Pod -> Pod (IP) * Pod -> Pod (Name) @@ -210,86 +456,229 @@ The following IPAM options are supported on Windows: ##### Load balancing and Services -On Windows, you can use the following settings to configure Services and load balancing behavior: +On Windows, you can use the following settings to configure Services and load +balancing behavior: {{< table caption="Windows Service Settings" >}} -| Feature | Description | Supported Kubernetes version | Supported Windows OS build | How to enable | -| ------- | ----------- | ----------------------------- | -------------------------- | ------------- | -| Session affinity | Ensures that connections from a particular client are passed to the same Pod each time. | v1.19+ | [Windows Server vNext Insider Preview Build 19551](https://blogs.windows.com/windowsexperience/2020/01/28/announcing-windows-server-vnext-insider-preview-build-19551/) (or higher) | Set `service.spec.sessionAffinity` to "ClientIP" | -| Direct Server Return | Load balancing mode where the IP address fixups and the LBNAT occurs at the container vSwitch port directly; service traffic arrives with the source IP set as the originating pod IP. Promises lower latency and scalability. | v1.15+ | Windows Server, version 2004 | Set the following flags in kube-proxy: `--feature-gates="WinDSR=true" --enable-dsr=true` | -| Preserve-Destination | Skips DNAT of service traffic, thereby preserving the virtual IP of the target service in packets reaching the backend Pod. This setting will also ensure that the client IP of incoming packets get preserved. | v1.15+ | Windows Server, version 1903 (or higher) | Set `"preserve-destination": "true"` in service annotations and enable DSR flags in kube-proxy. | -| IPv4/IPv6 dual-stack networking | Native IPv4-to-IPv4 in parallel with IPv6-to-IPv6 communications to, from, and within a cluster | v1.19+ | Windows Server vNext Insider Preview Build 19603 (or higher) | See [IPv4/IPv6 dual-stack](#ipv4ipv6-dual-stack) | + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FeatureDescriptionSupported Kubernetes versionSupported Windows OS buildHow to enable
Session affinity + Ensures that connections from a particular client are passed to the same + Pod each time. + v1.20+ + Windows Server vNext Insider Preview Build 19551 (or higher) + + Set service.spec.sessionAffinity to "ClientIP" +
Direct Server Return (DSR) + Load balancing mode where the IP address fixups and the LBNAT occurs at + the container vSwitch port directly; service traffic arrives with the source + IP set as the originating pod IP. + v1.20+ + Windows Server 2019 + + Set the following flags in kube-proxy: + --feature-gates="WinDSR=true" --enable-dsr=true +
Preserve-Destination + Skips DNAT of service traffic, thereby preserving the virtual IP of the target + service in packets reaching the backend Pod. Also disables node-node forwarding. + v1.20+Windows Server, version 1903 (or higher) + Set "preserve-destination": "true" in service annotations + and enable DSR in kube-proxy. +
IPv4/IPv6 dual-stack networking + Native IPv4-to-IPv4 in parallel with IPv6-to-IPv6 communications to, from, + and within a cluster + v1.19+Windows Server, version 2004 (or higher) + See IPv4/IPv6 dual-stack +
Client IP preservation + Ensures that source IP of incoming ingress traffic gets preserved. Also + disables node-node forwarding. + v1.20+Windows Server, version 2019 (or higher) + Set service.spec.externalTrafficPolicy to "Local" and enable + DSR in kube-proxy. +
+ {{< /table >}} #### IPv4/IPv6 dual-stack -You can enable IPv4/IPv6 dual-stack networking for `l2bridge` networks using the `IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/). See [enable IPv4/IPv6 dual stack](/docs/concepts/services-networking/dual-stack#enable-ipv4ipv6-dual-stack) for more details. +You can enable IPv4/IPv6 dual-stack networking for `l2bridge` networks using +the `IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/). See +[enable IPv4/IPv6 dual stack](/docs/concepts/services-networking/dual-stack#enable-ipv4ipv6-dual-stack) +for more details. -{{< note >}} -On Windows, using IPv6 with Kubernetes require Windows Server, version 2004 (kernel version 10.0.19041.610) or later. -{{< /note >}} +On Windows, using IPv6 with Kubernetes require Windows Server, version 2004 +(kernel version 10.0.19041.610) or later. -{{< note >}} Overlay (VXLAN) networks on Windows do not support dual-stack networking today. -{{< /note >}} ### Limitations -Windows is only supported as a worker node in the Kubernetes architecture and component matrix. This means that a Kubernetes cluster must always include Linux master nodes, zero or more Linux worker nodes, and zero or more Windows worker nodes. - +Windows is only supported as a worker node in the Kubernetes architecture and +component matrix. This means that a Kubernetes cluster must always include +Linux master nodes, zero or more Linux worker nodes, and zero or more Windows +worker nodes. #### Resource Handling - Linux cgroups are used as a pod boundary for resource controls in Linux. Containers are created within that boundary for network, process and file system isolation. The cgroups APIs can be used to gather cpu/io/memory stats. In contrast, Windows uses a Job object per container with a system namespace filter to contain all processes in a container and provide logical isolation from the host. There is no way to run a Windows container without the namespace filtering in place. This means that system privileges cannot be asserted in the context of the host, and thus privileged containers are not available on Windows. Containers cannot assume an identity from the host because the Security Account Manager (SAM) is separate. +Linux cgroups are used as a pod boundary for resource controls in Linux. +Containers are created within that boundary for network, process and file +system isolation. The cgroups APIs can be used to gather cpu/io/memory stats. +In contrast, Windows uses a Job object per container with a system namespace +filter to contain all processes in a container and provide logical isolation +from the host. There is no way to run a Windows container without the +namespace filtering in place. This means that system privileges cannot be +asserted in the context of the host, and thus privileged containers are not +available on Windows. Containers cannot assume an identity from the host +because the Security Account Manager (SAM) is separate. #### Resource Reservations ##### Memory Reservations -Windows does not have an out-of-memory process killer as Linux does. Windows always treats all user-mode memory allocations as virtual, and pagefiles are mandatory. The net effect is that Windows won't reach out of memory conditions the same way Linux does, and processes page to disk instead of being subject to out of memory (OOM) termination. If memory is over-provisioned and all physical memory is exhausted, then paging can slow down performance. -Keeping memory usage within reasonable bounds is possible using the kubelet parameters `--kubelet-reserve` and/or `--system-reserve` to account for memory usage on the node (outside of containers). This reduces [NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). +Windows does not have an out-of-memory process killer as Linux does. Windows +always treats all user-mode memory allocations as virtual, and pagefiles are +mandatory. The net effect is that Windows won't reach out of memory conditions +the same way Linux does, and processes page to disk instead of being subject +to out of memory (OOM) termination. If memory is over-provisioned and all +physical memory is exhausted, then paging can slow down performance. -{{< note >}} -As you deploy workloads, use resource limits (must set only limits or limits must equal requests) on containers. This also subtracts from NodeAllocatable and prevents the scheduler from adding more pods once a node is full. -{{< /note >}} +Keeping memory usage within reasonable bounds is possible using the kubelet +parameters `--kubelet-reserve` and/or `--system-reserve` to account for memory +usage on the node (outside of containers). This reduces +[NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). -A best practice to avoid over-provisioning is to configure the kubelet with a system reserved memory of at least 2GB to account for Windows, Docker, and Kubernetes processes. +As you deploy workloads, use resource limits (must set only limits or limits +must equal requests) on containers. This also subtracts from NodeAllocatable +and prevents the scheduler from adding more pods once a node is full. + +A best practice to avoid over-provisioning is to configure the kubelet with a +system reserved memory of at least 2GB to account for Windows, Docker, and +Kubernetes processes. ##### CPU Reservations -To account for Windows, Docker and other Kubernetes host processes it is recommended to reserve a percentage of CPU so they are able to respond to events. This value needs to be scaled based on the number of CPU cores available on the Windows node.To determine this percentage a user should identify the maximum pod density for each of their nodes and monitor the CPU usage of the system services choosing a value that meets their workload needs. -Keeping CPU usage within reasonable bounds is possible using the kubelet parameters `--kubelet-reserve` and/or `--system-reserve` to account for CPU usage on the node (outside of containers). This reduces [NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). +To account for Windows, Docker and other Kubernetes host processes it is +recommended to reserve a percentage of CPU so they are able to respond to +events. This value needs to be scaled based on the number of CPU cores +available on the Windows node.To determine this percentage a user should +identify the maximum pod density for each of their nodes and monitor the CPU +usage of the system services choosing a value that meets their workload needs. + +Keeping CPU usage within reasonable bounds is possible using the kubelet +parameters `--kubelet-reserve` and/or `--system-reserve` to account for CPU +usage on the node (outside of containers). This reduces +[NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). #### Feature Restrictions + * TerminationGracePeriod: not implemented * Single file mapping: to be implemented with CRI-ContainerD * Termination message: to be implemented with CRI-ContainerD * Privileged Containers: not currently supported in Windows containers * HugePages: not currently supported in Windows containers -* The existing node problem detector is Linux-only and requires privileged containers. In general, we don't expect this to be used on Windows because privileged containers are not supported -* Not all features of shared namespaces are supported (see API section for more details) +* The existing node problem detector is Linux-only and requires privileged + containers. In general, we don't expect this to be used on Windows because + privileged containers are not supported +* Not all features of shared namespaces are supported (see API section for + more details) #### Difference in behavior of flags when compared to Linux + The behavior of the following kubelet flags is different on Windows nodes as described below: -* `--kubelet-reserve`, `--system-reserve` , and `--eviction-hard` flags update Node Allocatable -* Eviction by using `--enforce-node-allocable` is not implemented -* Eviction by using `--eviction-hard` and `--eviction-soft` are not implemented -* MemoryPressure Condition is not implemented -* There are no OOM eviction actions taken by the kubelet -* Kubelet running on the windows node does not have memory restrictions. `--kubelet-reserve` and `--system-reserve` do not set limits on kubelet or processes running on the host. This means kubelet or a process on the host could cause memory resource starvation outside the node-allocatable and scheduler -* An additional flag to set the priority of the kubelet process is available on the Windows nodes called `--windows-priorityclass`. This flag allows kubelet process to get more CPU time slices when compared to other processes running on the Windows host. More information on the allowable values and their meaning is available at [Windows Priority Classes](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class). In order for kubelet to always have enough CPU cycles it is recommended to set this flag to `ABOVE_NORMAL_PRIORITY_CLASS` and above +* `--kubelet-reserve`, `--system-reserve` , and `--eviction-hard` flags update + Node Allocatable + +* Eviction by using `--enforce-node-allocable` is not implemented. + +* Eviction by using `--eviction-hard` and `--eviction-soft` are not implemented. + +* `MemoryPressure` Condition is not implemented. + +* There are no OOM eviction actions taken by the kubelet. + +* Kubelet running on the windows node does not have memory restrictions. + `--kubelet-reserve` and `--system-reserve` do not set limits on kubelet or + processes running on the host. This means kubelet or a process on the host + could cause memory resource starvation outside the node-allocatable and + scheduler + +* An additional flag to set the priority of the kubelet process is available + on the Windows nodes called `--windows-priorityclass`. This flag allows + kubelet process to get more CPU time slices when compared to other processes + running on the Windows host. More information on the allowable values and + their meaning is available at + [Windows Priority Classes](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class). + In order for kubelet to always have enough CPU cycles it is recommended to set + this flag to `ABOVE_NORMAL_PRIORITY_CLASS` and above. #### Storage -Windows has a layered filesystem driver to mount container layers and create a copy filesystem based on NTFS. All file paths in the container are resolved only within the context of that container. +Windows has a layered filesystem driver to mount container layers and create a +copy filesystem based on NTFS. All file paths in the container are resolved +only within the context of that container. -* With Docker Volume mounts can only target a directory in the container, and not an individual file. This limitation does not exist with CRI-containerD. -* Volume mounts cannot project files or directories back to the host filesystem -* Read-only filesystems are not supported because write access is always required for the Windows registry and SAM database. However, read-only volumes are supported -* Volume user-masks and permissions are not available. Because the SAM is not shared between the host & container, there's no mapping between them. All permissions are resolved within the context of the container +* With Docker Volume mounts can only target a directory in the container, and + not an individual file. This limitation does not exist with CRI-containerD. -As a result, the following storage functionality is not supported on Windows nodes +* Volume mounts cannot project files or directories back to the host + filesystem + +* Read-only filesystems are not supported because write access is always + required for the Windows registry and SAM database. However, read-only + volumes are supported + +* Volume user-masks and permissions are not available. Because the SAM is not + shared between the host & container, there's no mapping between them. All + permissions are resolved within the context of the container + +As a result, the following storage functionality is not supported on Windows nodes: * Volume subpath mounts. Only the entire volume can be mounted in a Windows container. * Subpath volume mounting for Secrets @@ -304,24 +693,61 @@ As a result, the following storage functionality is not supported on Windows nod #### Networking {#networking-limitations} -Windows Container Networking differs in some important ways from Linux networking. The [Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) contains additional details and background. +Windows Container Networking differs in some important ways from Linux +networking. The [Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) +contains additional details and background. -The Windows host networking service and virtual switch implement namespacing and can create virtual NICs as needed for a pod or container. However, many configurations such as DNS, routes, and metrics are stored in the Windows registry database rather than /etc/... files as they are on Linux. The Windows registry for the container is separate from that of the host, so concepts like mapping /etc/resolv.conf from the host into a container don't have the same effect they would on Linux. These must be configured using Windows APIs run in the context of that container. Therefore CNI implementations need to call the HNS instead of relying on file mappings to pass network details into the pod or container. +The Windows host networking service and virtual switch implement namespacing +and can create virtual NICs as needed for a pod or container. However, many +configurations such as DNS, routes, and metrics are stored in the Windows +registry database rather than /etc/... files as they are on Linux. The Windows +registry for the container is separate from that of the host, so concepts like +mapping /etc/resolv.conf from the host into a container don't have the same +effect they would on Linux. These must be configured using Windows APIs run in +the context of that container. Therefore CNI implementations need to call the +HNS instead of relying on file mappings to pass network details into the pod +or container. The following networking functionality is not supported on Windows nodes -* Host networking mode is not available for Windows pods -* Local NodePort access from the node itself fails (works for other nodes or external clients) -* Accessing service VIPs from nodes will be available with a future release of Windows Server -* A single service can only support up to 64 backend pods / unique destination IPs -* Overlay networking support in kube-proxy is an alpha release. In addition, it requires [KB4482887](https://support.microsoft.com/en-us/help/4482887/windows-10-update-kb4482887) to be installed on Windows Server 2019 -* Local Traffic Policy and DSR mode -* Windows containers connected to l2bridge, l2tunnel, or overlay networks do not support communicating over the IPv6 stack. There is outstanding Windows platform work required to enable these network drivers to consume IPv6 addresses and subsequent Kubernetes work in kubelet, kube-proxy, and CNI plugins. -* Outbound communication using the ICMP protocol via the win-overlay, win-bridge, and Azure-CNI plugin. Specifically, the Windows data plane ([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/)) doesn't support ICMP packet transpositions. This means: - * ICMP packets directed to destinations within the same network (e.g. pod to pod communication via ping) work as expected and without any limitations +* Host networking mode is not available for Windows pods. + +* Local NodePort access from the node itself fails (works for other nodes or + external clients). + +* Accessing service VIPs from nodes will be available with a future release of + Windows Server. + +* A single service can only support up to 64 backend pods / unique destination IPs. + +* Overlay networking support in kube-proxy is a beta feature. In addition, it + requires [KB4482887](https://support.microsoft.com/en-us/help/4482887/windows-10-update-kb4482887) + to be installed on Windows Server 2019. + +* Local Traffic Policy in non-DSR mode. + +* Windows containers connected to overlay networks do not support + communicating over the IPv6 stack. There is outstanding Windows platform + work required to enable this network driver to consume IPv6 addresses and + subsequent Kubernetes work in kubelet, kube-proxy, and CNI plugins. + +* Outbound communication using the ICMP protocol via the win-overlay, + win-bridge, and Azure-CNI plugin. Specifically, the Windows data plane + ([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/)) + doesn't support ICMP packet transpositions. This means: + + * ICMP packets directed to destinations within the same network (e.g. pod to + pod communication via ping) work as expected and without any limitations + * TCP/UDP packets work as expected and without any limitations - * ICMP packets directed to pass through a remote network (e.g. pod to external internet communication via ping) cannot be transposed and thus will not be routed back to their source - * Since TCP/UDP packets can still be transposed, one can substitute `ping ` with `curl ` to be able to debug connectivity to the outside world. + + * ICMP packets directed to pass through a remote network (e.g. pod to + external internet communication via ping) cannot be transposed and thus + will not be routed back to their source + + * Since TCP/UDP packets can still be transposed, one can substitute + `ping ` with `curl ` to be able to debug connectivity + to the outside world. These features were added in Kubernetes v1.15: @@ -329,334 +755,581 @@ These features were added in Kubernetes v1.15: ##### CNI Plugins -* Windows reference network plugins win-bridge and win-overlay do not currently implement [CNI spec](https://github.com/containernetworking/cni/blob/master/SPEC.md) v0.4.0 due to missing "CHECK" implementation. +* Windows reference network plugins `win-bridge` and `win-overlay` do not + currently implement [CNI spec](https://github.com/containernetworking/cni/blob/master/SPEC.md) + v0.4.0 due to missing "CHECK" implementation. + * The Flannel VXLAN CNI has the following limitations on Windows: -1. Node-pod connectivity isn't possible by design. It's only possible for local pods with Flannel v0.12.0 (or higher). -2. We are restricted to using VNI 4096 and UDP port 4789. The VNI limitation is being worked on and will be overcome in a future release (open-source flannel changes). See the official [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) backend docs for more details on these parameters. + 1. Node-pod connectivity isn't possible by design. It's only possible for + local pods with Flannel v0.12.0 (or higher). + + 1. We are restricted to using VNI 4096 and UDP port 4789. The VNI limitation + is being worked on and will be overcome in a future release (open-source + flannel changes). See the official + [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) + backend docs for more details on these parameters. ##### DNS {#dns-limitations} -* ClusterFirstWithHostNet is not supported for DNS. Windows treats all names with a '.' as a FQDN and skips PQDN resolution -* On Linux, you have a DNS suffix list, which is used when trying to resolve PQDNs. On Windows, we only have 1 DNS suffix, which is the DNS suffix associated with that pod's namespace (mydns.svc.cluster.local for example). Windows can resolve FQDNs and services or names resolvable with only that suffix. For example, a pod spawned in the default namespace, will have the DNS suffix **default.svc.cluster.local**. On a Windows pod, you can resolve both **kubernetes.default.svc.cluster.local** and **kubernetes**, but not the in-betweens, like **kubernetes.default** or **kubernetes.default.svc**. -* On Windows, there are multiple DNS resolvers that can be used. As these come with slightly different behaviors, using the `Resolve-DNSName` utility for name query resolutions is recommended. +* ClusterFirstWithHostNet is not supported for DNS. Windows treats all names + with a '.' as a FQDN and skips PQDN resolution + +* On Linux, you have a DNS suffix list, which is used when trying to resolve + PQDNs. On Windows, we only have 1 DNS suffix, which is the DNS suffix + associated with that pod's namespace (mydns.svc.cluster.local for example). + Windows can resolve FQDNs and services or names resolvable with only that + suffix. For example, a pod spawned in the default namespace, will have the DNS + suffix `default.svc.cluster.local`. On a Windows pod, you can resolve both + `kubernetes.default.svc.cluster.local` and `kubernetes`, but not the + in-betweens, like `kubernetes.default` or `kubernetes.default.svc`. + +* On Windows, there are multiple DNS resolvers that can be used. As these come + with slightly different behaviors, using the `Resolve-DNSName` utility for + name query resolutions is recommended. ##### IPv6 -Kubernetes on Windows does not support single-stack "IPv6-only" networking. However,dual-stack IPv4/IPv6 networking for pods and nodes with single-family services is supported. See [IPv4/IPv6 dual-stack networking](#ipv4ipv6-dual-stack) for more details. +Kubernetes on Windows does not support single-stack "IPv6-only" networking. +However,dual-stack IPv4/IPv6 networking for pods and nodes with single-family +services is supported. +See [IPv4/IPv6 dual-stack networking](#ipv4ipv6-dual-stack) for more details. ##### Session affinity -Setting the maximum session sticky time for Windows services using `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` is not supported. +Setting the maximum session sticky time for Windows services using +`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` is not supported. ##### Security -Secrets are written in clear text on the node's volume (as compared to tmpfs/in-memory on linux). This means customers have to do two things +Secrets are written in clear text on the node's volume (as compared to +tmpfs/in-memory on linux). This means customers have to do two things: 1. Use file ACLs to secure the secrets file location -2. Use volume-level encryption using [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server) +1. Use volume-level encryption using + [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server) -[RunAsUsername](/docs/tasks/configure-pod-container/configure-runasusername) can be specified for Windows Pod's or Container's to execute the Container processes as a node-default user. This is roughly equivalent to [RunAsUser](/docs/concepts/policy/pod-security-policy/#users-and-groups). +[RunAsUsername](/docs/tasks/configure-pod-container/configure-runasusername) +can be specified for Windows Pod's or Container's to execute the Container +processes as a node-default user. This is roughly equivalent to +[RunAsUser](/docs/concepts/policy/pod-security-policy/#users-and-groups). -Linux specific pod security context privileges such as SELinux, AppArmor, Seccomp, Capabilities (POSIX Capabilities), and others are not supported. +Linux specific pod security context privileges such as SELinux, AppArmor, +Seccomp, Capabilities (POSIX Capabilities), and others are not supported. -In addition, as mentioned already, privileged containers are not supported on Windows. +In addition, as mentioned already, privileged containers are not supported on +Windows. #### API -There are no differences in how most of the Kubernetes APIs work for Windows. The subtleties around what's different come down to differences in the OS and container runtime. In certain situations, some properties on workload APIs such as Pod or Container were designed with an assumption that they are implemented on Linux, failing to run on Windows. +There are no differences in how most of the Kubernetes APIs work for Windows. +The subtleties around what's different come down to differences in the OS and +container runtime. In certain situations, some properties on workload APIs +such as Pod or Container were designed with an assumption that they are +implemented on Linux, failing to run on Windows. At a high level, these OS concepts are different: -* Identity - Linux uses userID (UID) and groupID (GID) which are represented as integer types. User and group names are not canonical - they are an alias in `/etc/groups` or `/etc/passwd` back to UID+GID. Windows uses a larger binary security identifier (SID) which is stored in the Windows Security Access Manager (SAM) database. This database is not shared between the host and containers, or between containers. -* File permissions - Windows uses an access control list based on SIDs, rather than a bitmask of permissions and UID+GID -* File paths - convention on Windows is to use `\` instead of `/`. The Go IO libraries accept both types of file path separators. However, when you're setting a path or command line that's interpreted inside a container, `\` may be needed. -* Signals - Windows interactive apps handle termination differently, and can implement one or more of these: - * A UI thread handles well-defined messages including WM_CLOSE - * Console apps handle ctrl-c or ctrl-break using a Control Handler - * Services register a Service Control Handler function that can accept SERVICE_CONTROL_STOP control codes +* Identity - Linux uses userID (UID) and groupID (GID) which are represented + as integer types. User and group names are not canonical - they are an alias + in `/etc/groups` or `/etc/passwd` back to UID+GID. Windows uses a larger + binary security identifier (SID) which is stored in the Windows Security + Access Manager (SAM) database. This database is not shared between the host + and containers, or between containers. -Exit Codes follow the same convention where 0 is success, nonzero is failure. The specific error codes may differ across Windows and Linux. However, exit codes passed from the Kubernetes components (kubelet, kube-proxy) are unchanged. +* File permissions - Windows uses an access control list based on SIDs, rather + than a bitmask of permissions and UID+GID + +* File paths - convention on Windows is to use `\` instead of `/`. The Go IO + libraries accept both types of file path separators. However, when you're + setting a path or command line that's interpreted inside a container, `\` may + be needed. + +* Signals - Windows interactive apps handle termination differently, and can + implement one or more of these: + + * A UI thread handles well-defined messages including `WM_CLOSE` + + * Console apps handle ctrl-c or ctrl-break using a Control Handler + + * Services register a Service Control Handler function that can accept + `SERVICE_CONTROL_STOP` control codes + +Exit Codes follow the same convention where 0 is success, nonzero is failure. +The specific error codes may differ across Windows and Linux. However, exit +codes passed from the Kubernetes components (kubelet, kube-proxy) are +unchanged. ##### V1.Container -* V1.Container.ResourceRequirements.limits.cpu and V1.Container.ResourceRequirements.limits.memory - Windows doesn't use hard limits for CPU allocations. Instead, a share system is used. The existing fields based on millicores are scaled into relative shares that are followed by the Windows scheduler. [see: kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go), [see: resource controls in Microsoft docs](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/resource-controls) - * Huge pages are not implemented in the Windows container runtime, and are not available. They require [asserting a user privilege](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support) that's not configurable for containers. -* V1.Container.ResourceRequirements.requests.cpu and V1.Container.ResourceRequirements.requests.memory - Requests are subtracted from node available resources, so they can be used to avoid overprovisioning a node. However, they cannot be used to guarantee resources in an overprovisioned node. They should be applied to all containers as a best practice if the operator wants to avoid overprovisioning entirely. -* V1.Container.SecurityContext.allowPrivilegeEscalation - not possible on Windows, none of the capabilities are hooked up -* V1.Container.SecurityContext.Capabilities - POSIX capabilities are not implemented on Windows -* V1.Container.SecurityContext.privileged - Windows doesn't support privileged containers +* V1.Container.ResourceRequirements.limits.cpu and + V1.Container.ResourceRequirements.limits.memory - Windows doesn't use hard + limits for CPU allocations. Instead, a share system is used. The existing + fields based on millicores are scaled into relative shares that are followed + by the Windows scheduler. + See [kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go), + and [resource controls in Microsoft docs](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/resource-controls) + + * Huge pages are not implemented in the Windows container runtime, and are + not available. They require + [asserting a user privilege](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support) + that's not configurable for containers. + +* V1.Container.ResourceRequirements.requests.cpu and + V1.Container.ResourceRequirements.requests.memory - Requests are subtracted + from node available resources, so they can be used to avoid overprovisioning a + node. However, they cannot be used to guarantee resources in an + overprovisioned node. They should be applied to all containers as a best + practice if the operator wants to avoid overprovisioning entirely. + +* V1.Container.SecurityContext.allowPrivilegeEscalation - not possible on + Windows, none of the capabilities are hooked up + +* V1.Container.SecurityContext.Capabilities - POSIX capabilities are not + implemented on Windows + +* V1.Container.SecurityContext.privileged - Windows doesn't support privileged + containers + * V1.Container.SecurityContext.procMount - Windows doesn't have a /proc filesystem -* V1.Container.SecurityContext.readOnlyRootFilesystem - not possible on Windows, write access is required for registry & system processes to run inside the container + +* V1.Container.SecurityContext.readOnlyRootFilesystem - not possible on + Windows, write access is required for registry & system processes to run + inside the container + * V1.Container.SecurityContext.runAsGroup - not possible on Windows, no GID support -* V1.Container.SecurityContext.runAsNonRoot - Windows does not have a root user. The closest equivalent is ContainerAdministrator which is an identity that doesn't exist on the node. -* V1.Container.SecurityContext.runAsUser - not possible on Windows, no UID support as int. + +* V1.Container.SecurityContext.runAsNonRoot - Windows does not have a root + user. The closest equivalent is ContainerAdministrator which is an identity + that doesn't exist on the node. + +* V1.Container.SecurityContext.runAsUser - not possible on Windows, no UID + support as int. + * V1.Container.SecurityContext.seLinuxOptions - not possible on Windows, no SELinux -* V1.Container.terminationMessagePath - this has some limitations in that Windows doesn't support mapping single files. The default value is /dev/termination-log, which does work because it does not exist on Windows by default. + +* V1.Container.terminationMessagePath - this has some limitations in that + Windows doesn't support mapping single files. The default value is + `/dev/termination-log`, which does work because it does not exist on Windows by + default. ##### V1.Pod * V1.Pod.hostIPC, v1.pod.hostpid - host namespace sharing is not possible on Windows + * V1.Pod.hostNetwork - There is no Windows OS support to share the host network -* V1.Pod.dnsPolicy - ClusterFirstWithHostNet - is not supported because Host Networking is not supported on Windows. + +* V1.Pod.dnsPolicy - `ClusterFirstWithHostNet` is not supported because Host + Networking is not supported on Windows. + * V1.Pod.podSecurityContext - see V1.PodSecurityContext below -* V1.Pod.shareProcessNamespace - this is a beta feature, and depends on Linux namespaces which are not implemented on Windows. Windows cannot share process namespaces or the container's root filesystem. Only the network can be shared. -* V1.Pod.terminationGracePeriodSeconds - this is not fully implemented in Docker on Windows, see: [reference](https://github.com/moby/moby/issues/25982). The behavior today is that the ENTRYPOINT process is sent CTRL_SHUTDOWN_EVENT, then Windows waits 5 seconds by default, and finally shuts down all processes using the normal Windows shutdown behavior. The 5 second default is actually in the Windows registry [inside the container](https://github.com/moby/moby/issues/25982#issuecomment-426441183), so it can be overridden when the container is built. -* V1.Pod.volumeDevices - this is a beta feature, and is not implemented on Windows. Windows cannot attach raw block devices to pods. -* V1.Pod.volumes - EmptyDir, Secret, ConfigMap, HostPath - all work and have tests in TestGrid - * V1.emptyDirVolumeSource - the Node default medium is disk on Windows. Memory is not supported, as Windows does not have a built-in RAM disk. + +* V1.Pod.shareProcessNamespace - this is a beta feature, and depends on Linux + namespaces which are not implemented on Windows. Windows cannot share + process namespaces or the container's root filesystem. Only the network can be + shared. + +* V1.Pod.terminationGracePeriodSeconds - this is not fully implemented in + Docker on Windows, see: + [reference](https://github.com/moby/moby/issues/25982). The behavior today is + that the `ENTRYPOINT` process is sent `CTRL_SHUTDOWN_EVENT`, then Windows waits 5 + seconds by default, and finally shuts down all processes using the normal + Windows shutdown behavior. The 5 second default is actually in the Windows + registry [inside the container](https://github.com/moby/moby/issues/25982#issuecomment-426441183), + so it can be overridden when the container is built. + +* V1.Pod.volumeDevices - this is a beta feature, and is not implemented on + Windows. Windows cannot attach raw block devices to pods. + +* V1.Pod.volumes - EmptyDir, Secret, ConfigMap, HostPath - all work and have + tests in TestGrid + + * V1.emptyDirVolumeSource - the Node default medium is disk on Windows. + Memory is not supported, as Windows does not have a built-in RAM disk. + * V1.VolumeMount.mountPropagation - mount propagation is not supported on Windows. ##### V1.PodSecurityContext -None of the PodSecurityContext fields work on Windows. They're listed here for reference. +None of the PodSecurityContext fields work on Windows. They're listed here for +reference. * V1.PodSecurityContext.SELinuxOptions - SELinux is not available on Windows + * V1.PodSecurityContext.RunAsUser - provides a UID, not available on Windows + * V1.PodSecurityContext.RunAsGroup - provides a GID, not available on Windows -* V1.PodSecurityContext.RunAsNonRoot - Windows does not have a root user. The closest equivalent is ContainerAdministrator which is an identity that doesn't exist on the node. + +* V1.PodSecurityContext.RunAsNonRoot - Windows does not have a root user. The + closest equivalent is ContainerAdministrator which is an identity that + doesn't exist on the node. + * V1.PodSecurityContext.SupplementalGroups - provides GID, not available on Windows -* V1.PodSecurityContext.Sysctls - these are part of the Linux sysctl interface. There's no equivalent on Windows. + +* V1.PodSecurityContext.Sysctls - these are part of the Linux sysctl + interface. There's no equivalent on Windows. #### Operating System Version Restrictions -Windows has strict compatibility rules, where the host OS version must match the container base image OS version. Only Windows containers with a container operating system of Windows Server 2019 are supported. Hyper-V isolation of containers, enabling some backward compatibility of Windows container image versions, is planned for a future release. +Windows has strict compatibility rules, where the host OS version must match +the container base image OS version. Only Windows containers with a container +operating system of Windows Server 2019 are supported. Hyper-V isolation of +containers, enabling some backward compatibility of Windows container image +versions, is planned for a future release. ## Getting Help and Troubleshooting {#troubleshooting} -Your main source of help for troubleshooting your Kubernetes cluster should start with this [section](/docs/tasks/debug-application-cluster/troubleshooting/). Some additional, Windows-specific troubleshooting help is included in this section. Logs are an important element of troubleshooting issues in Kubernetes. Make sure to include them any time you seek troubleshooting assistance from other contributors. Follow the instructions in the SIG-Windows [contributing guide on gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs). +Your main source of help for troubleshooting your Kubernetes cluster should +start with this +[section](/docs/tasks/debug-application-cluster/troubleshooting/). Some +additional, Windows-specific troubleshooting help is included in this section. +Logs are an important element of troubleshooting issues in Kubernetes. Make +sure to include them any time you seek troubleshooting assistance from other +contributors. Follow the instructions in the SIG-Windows +[contributing guide on gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs). -1. How do I know start.ps1 completed successfully? +* How do I know start.ps1 completed successfully? - You should see kubelet, kube-proxy, and (if you chose Flannel as your networking solution) flanneld host-agent processes running on your node, with running logs being displayed in separate PowerShell windows. In addition to this, your Windows node should be listed as "Ready" in your Kubernetes cluster. + You should see kubelet, kube-proxy, and (if you chose Flannel as your + networking solution) flanneld host-agent processes running on your node, with + running logs being displayed in separate PowerShell windows. In addition to + this, your Windows node should be listed as "Ready" in your Kubernetes + cluster. -1. Can I configure the Kubernetes node processes to run in the background as services? +* Can I configure the Kubernetes node processes to run in the background as services? - Kubelet and kube-proxy are already configured to run as native Windows Services, offering resiliency by re-starting the services automatically in the event of failure (for example a process crash). You have two options for configuring these node components as services. + Kubelet and kube-proxy are already configured to run as native Windows + Services, offering resiliency by re-starting the services automatically in the + event of failure (for example a process crash). You have two options for + configuring these node components as services. - 1. As native Windows Services + * As native Windows Services - Kubelet & kube-proxy can be run as native Windows Services using `sc.exe`. - - ```powershell - # Create the services for kubelet and kube-proxy in two separate commands - sc.exe create binPath= " --service " - - # Please note that if the arguments contain spaces, they must be escaped. - sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' " - - # Start the services - Start-Service kubelet - Start-Service kube-proxy - - # Stop the service - Stop-Service kubelet (-Force) - Stop-Service kube-proxy (-Force) - - # Query the service status - Get-Service kubelet - Get-Service kube-proxy - ``` - - 1. Using nssm.exe - - You can also always use alternative service managers like [nssm.exe](https://nssm.cc/) to run these processes (flanneld, kubelet & kube-proxy) in the background for you. You can use this [sample script](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1), leveraging nssm.exe to register kubelet, kube-proxy, and flanneld.exe to run as Windows services in the background. - - ```powershell - register-svc.ps1 -NetworkMode -ManagementIP -ClusterCIDR -KubeDnsServiceIP -LogDir - - # NetworkMode = The network mode l2bridge (flannel host-gw, also the default value) or overlay (flannel vxlan) chosen as a network solution - # ManagementIP = The IP address assigned to the Windows node. You can use ipconfig to find this - # ClusterCIDR = The cluster subnet range. (Default value 10.244.0.0/16) - # KubeDnsServiceIP = The Kubernetes DNS service IP (Default value 10.96.0.10) - # LogDir = The directory where kubelet and kube-proxy logs are redirected into their respective output files (Default value C:\k) - ``` - - If the above referenced script is not suitable, you can manually configure nssm.exe using the following examples. - - ```powershell - # Register flanneld.exe - nssm install flanneld C:\flannel\flanneld.exe - nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 - nssm set flanneld AppEnvironmentExtra NODE_NAME= - nssm set flanneld AppDirectory C:\flannel - nssm start flanneld - - # Register kubelet.exe - # Microsoft releases the pause infrastructure container at mcr.microsoft.com/oss/kubernetes/pause:1.4.1 - nssm install kubelet C:\k\kubelet.exe - nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=mcr.microsoft.com/oss/kubernetes/pause:1.4.1 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config - nssm set kubelet AppDirectory C:\k - nssm start kubelet - - # Register kube-proxy.exe (l2bridge / host-gw) - nssm install kube-proxy C:\k\kube-proxy.exe - nssm set kube-proxy AppDirectory c:\k - nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=--kubeconfig=c:\k\config --enable-dsr=false --log-dir= --logtostderr=false - nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0 - nssm set kube-proxy DependOnService kubelet - nssm start kube-proxy - - # Register kube-proxy.exe (overlay / vxlan) - nssm install kube-proxy C:\k\kube-proxy.exe - nssm set kube-proxy AppDirectory c:\k - nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override= --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip= --enable-dsr=false --log-dir= --logtostderr=false - nssm set kube-proxy DependOnService kubelet - nssm start kube-proxy - ``` - - For initial troubleshooting, you can use the following flags in [nssm.exe](https://nssm.cc/) to redirect stdout and stderr to a output file: - - ```powershell - nssm set AppStdout C:\k\mysvc.log - nssm set AppStderr C:\k\mysvc.log - ``` - - For additional details, see official [nssm usage](https://nssm.cc/usage) docs. - -1. My Windows Pods do not have network connectivity - - If you are using virtual machines, ensure that MAC spoofing is enabled on all the VM network adapter(s). - -1. My Windows Pods cannot ping external resources - - Windows Pods do not have outbound rules programmed for the ICMP protocol today. However, TCP/UDP is supported. When trying to demonstrate connectivity to resources outside of the cluster, please substitute `ping ` with corresponding `curl ` commands. - - If you are still facing problems, most likely your network configuration in [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf) deserves some extra attention. You can always edit this static file. The configuration update will apply to any newly created Kubernetes resources. - - One of the Kubernetes networking requirements (see [Kubernetes model](/docs/concepts/cluster-administration/networking/)) is for cluster communication to occur without NAT internally. To honor this requirement, there is an [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20) for all the communication where we do not want outbound NAT to occur. However, this also means that you need to exclude the external IP you are trying to query from the ExceptionList. Only then will the traffic originating from your Windows pods be SNAT'ed correctly to receive a response from the outside world. In this regard, your ExceptionList in `cni.conf` should look as follows: - - ```conf - "ExceptionList": [ - "10.244.0.0/16", # Cluster subnet - "10.96.0.0/12", # Service subnet - "10.127.130.0/24" # Management (host) subnet - ] - ``` - -1. My Windows node cannot access NodePort service - - Local NodePort access from the node itself fails. This is a known limitation. NodePort access works from other nodes or external clients. - -1. vNICs and HNS endpoints of containers are being deleted - - This issue can be caused when the `hostname-override` parameter is not passed to [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/). To resolve it, users need to pass the hostname to kube-proxy as follows: + Kubelet & kube-proxy can be run as native Windows Services using `sc.exe`. ```powershell - C:\k\kube-proxy.exe --hostname-override=$(hostname) + # Create the services for kubelet and kube-proxy in two separate commands + sc.exe create binPath= " --service " + + # Please note that if the arguments contain spaces, they must be escaped. + sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' " + + # Start the services + Start-Service kubelet + Start-Service kube-proxy + + # Stop the service + Stop-Service kubelet (-Force) + Stop-Service kube-proxy (-Force) + + # Query the service status + Get-Service kubelet + Get-Service kube-proxy ``` -1. With flannel my nodes are having issues after rejoining a cluster + * Using nssm.exe - Whenever a previously deleted node is being re-joined to the cluster, flannelD tries to assign a new pod subnet to the node. Users should remove the old pod subnet configuration files in the following paths: + You can also always use alternative service managers like + [`nssm.exe`](https://nssm.cc/) to run these processes (flanneld, kubelet & + kube-proxy) in the background for you. You can use this + [sample script](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1), + leveraging `nssm.exe` to register kubelet, kube-proxy, and `flanneld.exe` + to run as Windows services in the background. ```powershell - Remove-Item C:\k\SourceVip.json - Remove-Item C:\k\SourceVipRequest.json + register-svc.ps1 -NetworkMode -ManagementIP -ClusterCIDR -KubeDnsServiceIP -LogDir ``` -1. After launching `start.ps1`, flanneld is stuck in "Waiting for the Network to be created" + The parameters are explained below: - There are numerous reports of this [issue](https://github.com/coreos/flannel/issues/1066); most likely it is a timing issue for when the management IP of the flannel network is set. A workaround is to relaunch start.ps1 or relaunch it manually as follows: + - `NetworkMode`: The network mode l2bridge (flannel host-gw, also the + default value) or overlay (flannel vxlan) chosen as a network solution + - `ManagementIP`: The IP address assigned to the Windows node. You can use + `ipconfig` to find this. + - `ClusterCIDR`: The cluster subnet range. (Default: 10.244.0.0/16) + - `KubeDnsServiceIP`: The Kubernetes DNS service IP. (Default: 10.96.0.10) + - `LogDir`: The directory where kubelet and kube-proxy logs are redirected + into their respective output files. (Default value C:\k) + + If the above referenced script is not suitable, you can manually configure + `nssm.exe` using the following examples. + + Register flanneld.exe: ```powershell - PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "") - PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 + nssm install flanneld C:\flannel\flanneld.exe + nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 + nssm set flanneld AppEnvironmentExtra NODE_NAME= + nssm set flanneld AppDirectory C:\flannel + nssm start flanneld ``` -1. My Windows Pods cannot launch because of missing `/run/flannel/subnet.env` - - This indicates that Flannel didn't launch correctly. You can either try to restart flanneld.exe or you can copy the files over manually from `/run/flannel/subnet.env` on the Kubernetes master to `C:\run\flannel\subnet.env` on the Windows worker node and modify the `FLANNEL_SUBNET` row to a different number. For example, if node subnet 10.244.4.1/24 is desired: - - ```env - FLANNEL_NETWORK=10.244.0.0/16 - FLANNEL_SUBNET=10.244.4.1/24 - FLANNEL_MTU=1500 - FLANNEL_IPMASQ=true - ``` - -1. My Windows node cannot access my services using the service IP - - This is a known limitation of the current networking stack on Windows. Windows Pods are able to access the service IP however. - -1. No network adapter is found when starting kubelet - - The Windows networking stack needs a virtual adapter for Kubernetes networking to work. If the following commands return no results (in an admin shell), virtual network creation — a necessary prerequisite for Kubelet to work — has failed: + Register kubelet.exe: ```powershell - Get-HnsNetwork | ? Name -ieq "cbr0" - Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*" + nssm install kubelet C:\k\kubelet.exe + nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=k8s.gcr.io/pause:3.5 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config + nssm set kubelet AppDirectory C:\k + nssm start kubelet ``` - Often it is worthwhile to modify the [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation. + Register kube-proxy.exe (l2bridge / host-gw): -1. My Pods are stuck at "Container Creating" or restarting over and over - - Check that your pause image is compatible with your OS version. The [instructions](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources) assume that both the OS and the containers are version 1803. If you have a later version of Windows, such as an Insider build, you need to adjust the images accordingly. Please refer to the Microsoft's [Docker repository](https://hub.docker.com/u/microsoft/) for images. Regardless, both the pause image Dockerfile and the sample service expect the image to be tagged as :latest. - -1. DNS resolution is not properly working - - Check the DNS limitations for Windows in this [section](#dns-limitations). - -1. `kubectl port-forward` fails with "unable to do port forwarding: wincat not found" - - This was implemented in Kubernetes 1.15 by including wincat.exe in the pause infrastructure container `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`. Be sure to use these versions or newer ones. - If you would like to build your own pause infrastructure container be sure to include [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat). - -1. My Kubernetes installation is failing because my Windows Server node is behind a proxy - - If you are behind a proxy, the following PowerShell environment variables must be defined: - - ```PowerShell - [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) - [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) + ```powershell + nssm install kube-proxy C:\k\kube-proxy.exe + nssm set kube-proxy AppDirectory c:\k + nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=--kubeconfig=c:\k\config --enable-dsr=false --log-dir= --logtostderr=false + nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0 + nssm set kube-proxy DependOnService kubelet + nssm start kube-proxy ``` -1. What is a `pause` container? + Register kube-proxy.exe (overlay / vxlan): - In a Kubernetes Pod, an infrastructure or "pause" container is first created to host the container endpoint. Containers that belong to the same pod, including infrastructure and worker containers, share a common network namespace and endpoint (same IP and port space). Pause containers are needed to accommodate worker containers crashing or restarting without losing any of the networking configuration. + ```powershell + nssm install kube-proxy C:\k\kube-proxy.exe + nssm set kube-proxy AppDirectory c:\k + nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override= --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip= --enable-dsr=false --log-dir= --logtostderr=false + nssm set kube-proxy DependOnService kubelet + nssm start kube-proxy + ``` - The "pause" (infrastructure) image is hosted on Microsoft Container Registry (MCR). You can access it using `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`. For more details, see the [DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile). + For initial troubleshooting, you can use the following flags in + [`nssm.exe`](https://nssm.cc/) to redirect stdout and stderr to a output file: + + ```powershell + nssm set AppStdout C:\k\mysvc.log + nssm set AppStderr C:\k\mysvc.log + ``` + + For additional details, see official [nssm usage](https://nssm.cc/usage) docs. + +* My Windows Pods do not have network connectivity + + If you are using virtual machines, ensure that MAC spoofing is enabled on + all the VM network adapter(s). + +* My Windows Pods cannot ping external resources + + Windows Pods do not have outbound rules programmed for the ICMP protocol + today. However, TCP/UDP is supported. When trying to demonstrate connectivity + to resources outside of the cluster, please substitute `ping ` with + corresponding `curl ` commands. + + If you are still facing problems, most likely your network configuration in + [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf) + deserves some extra attention. You can always edit this static file. The + configuration update will apply to any newly created Kubernetes resources. + + One of the Kubernetes networking requirements (see + [Kubernetes network model](/docs/concepts/cluster-administration/networking/)) + is for cluster communication to occur without NAT internally. To honor this + requirement, there is an + [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20) + for all the communication where we do not want outbound NAT to occur. However, + this also means that you need to exclude the external IP you are trying to + query from the ExceptionList. Only then will the traffic originating from your + Windows pods be SNAT'ed correctly to receive a response from the outside + world. In this regard, your ExceptionList in `cni.conf` should look as + follows: + + ```conf + "ExceptionList": [ + "10.244.0.0/16", # Cluster subnet + "10.96.0.0/12", # Service subnet + "10.127.130.0/24" # Management (host) subnet + ] + ``` + +* My Windows node cannot access NodePort service + + Local NodePort access from the node itself fails. This is a known + limitation. NodePort access works from other nodes or external clients. + +* vNICs and HNS endpoints of containers are being deleted + + This issue can be caused when the `hostname-override` parameter is not + passed to + [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/). + To resolve it, users need to pass the hostname to kube-proxy as follows: + + ```powershell + C:\k\kube-proxy.exe --hostname-override=$(hostname) + ``` + +* With flannel my nodes are having issues after rejoining a cluster + + Whenever a previously deleted node is being re-joined to the cluster, + flannelD tries to assign a new pod subnet to the node. Users should remove the + old pod subnet configuration files in the following paths: + + ```powershell + Remove-Item C:\k\SourceVip.json + Remove-Item C:\k\SourceVipRequest.json + ``` + +* After launching `start.ps1`, flanneld is stuck in "Waiting for the Network + to be created" + + There are numerous reports of this + [issue](https://github.com/coreos/flannel/issues/1066); most likely it is a + timing issue for when the management IP of the flannel network is set. A + workaround is to relaunch start.ps1 or relaunch it manually as follows: + + ```powershell + PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "") + PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 + ``` + +* My Windows Pods cannot launch because of missing `/run/flannel/subnet.env` + + This indicates that Flannel didn't launch correctly. You can either try to + restart flanneld.exe or you can copy the files over manually from + `/run/flannel/subnet.env` on the Kubernetes master to + `C:\run\flannel\subnet.env` on the Windows worker node and modify the + `FLANNEL_SUBNET` row to a different number. For example, if node subnet + 10.244.4.1/24 is desired: + + ```none + FLANNEL_NETWORK=10.244.0.0/16 + FLANNEL_SUBNET=10.244.4.1/24 + FLANNEL_MTU=1500 + FLANNEL_IPMASQ=true + ``` + +* My Windows node cannot access my services using the service IP + + This is a known limitation of the current networking stack on Windows. + Windows Pods are able to access the service IP however. + +* No network adapter is found when starting kubelet + + The Windows networking stack needs a virtual adapter for Kubernetes + networking to work. If the following commands return no results (in an admin + shell), virtual network creation — a necessary prerequisite for Kubelet to + work — has failed: + + ```powershell + Get-HnsNetwork | ? Name -ieq "cbr0" + Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*" + ``` + + Often it is worthwhile to modify the + [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) + parameter of the start.ps1 script, in cases where the host's network adapter + isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` + script to see if there are errors during virtual network creation. + +* My Pods are stuck at "Container Creating" or restarting over and over + + Check that your pause image is compatible with your OS version. The + [instructions](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources) + assume that both the OS and the containers are version 1803. If you have a + later version of Windows, such as an Insider build, you need to adjust the + images accordingly. Please refer to the Microsoft's + [Docker repository](https://hub.docker.com/u/microsoft/) for images. + Regardless, both the pause image Dockerfile and the sample service expect + the image to be tagged as :latest. + +* DNS resolution is not properly working + + Check the [DNS limitations for Windows](#dns-limitations). + +* `kubectl port-forward` fails with "unable to do port forwarding: wincat not found" + + Port forwarding support for Windows requires wincat.exe to be available in the + [pause infrastructure container](#pause-image). + Ensure you are using a supported image that is compatable with your Windows OS version. + If you would like to build your own pause infrastructure container be sure to include + [wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat). + +* My Kubernetes installation is failing because my Windows Server node is + behind a proxy + + If you are behind a proxy, the following PowerShell environment variables + must be defined: + + ```PowerShell + [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) + [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) + ``` + +* What is a `pause` container? + + In a Kubernetes Pod, an infrastructure or "pause" container is first created + to host the container endpoint. Containers that belong to the same pod, + including infrastructure and worker containers, share a common network + namespace and endpoint (same IP and port space). Pause containers are needed + to accommodate worker containers crashing or restarting without losing any of + the networking configuration. + + Refer to the [pause image](#pause-image) section to find the recommended version + of the pause image. ### Further investigation -If these steps don't resolve your problem, you can get help running Windows containers on Windows nodes in Kubernetes through: +If these steps don't resolve your problem, you can get help running Windows +containers on Windows nodes in Kubernetes through: * StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container) topic + * Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io/) + * Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows) ## Reporting Issues and Feature Requests -If you have what looks like a bug, or you would like to make a feature request, please use the [GitHub issue tracking system](https://github.com/kubernetes/kubernetes/issues). You can open issues on [GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose) and assign them to SIG-Windows. You should first search the list of issues in case it was reported previously and comment with your experience on the issue and add additional logs. SIG-Windows Slack is also a great avenue to get some initial support and troubleshooting ideas prior to creating a ticket. +If you have what looks like a bug, or you would like to make a feature +request, please use the +[GitHub issue tracking system](https://github.com/kubernetes/kubernetes/issues). +You can open issues on +[GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose) and +assign them to SIG-Windows. You should first search the list of issues in case +it was reported previously and comment with your experience on the issue and +add additional logs. SIG-Windows Slack is also a great avenue to get some +initial support and troubleshooting ideas prior to creating a ticket. -If filing a bug, please include detailed information about how to reproduce the problem, such as: +If filing a bug, please include detailed information about how to reproduce +the problem, such as: * Kubernetes version: kubectl version -* Environment details: Cloud provider, OS distro, networking choice and configuration, and Docker version +* Environment details: Cloud provider, OS distro, networking choice and + configuration, and Docker version * Detailed steps to reproduce the problem * [Relevant logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) -* Tag the issue sig/windows by commenting on the issue with `/sig windows` to bring it to a SIG-Windows member's attention +* Tag the issue sig/windows by commenting on the issue with `/sig windows` to + bring it to a SIG-Windows member's attention ## {{% heading "whatsnext" %}} -We have a lot of features in our roadmap. An abbreviated high level list is included below, but we encourage you to view our [roadmap project](https://github.com/orgs/kubernetes/projects/8) and help us make Windows support better by [contributing](https://github.com/kubernetes/community/blob/master/sig-windows/). +We have a lot of features in our roadmap. An abbreviated high level list is +included below, but we encourage you to view our +[roadmap project](https://github.com/orgs/kubernetes/projects/8) and help us make +Windows support better by +[contributing](https://github.com/kubernetes/community/blob/master/sig-windows/). ### Hyper-V isolation -Hyper-V isolation is required to enable the following use cases for Windows containers in Kubernetes: +Hyper-V isolation is required to enable the following use cases for Windows +containers in Kubernetes: * Hypervisor-based isolation between pods for additional security -* Backwards compatibility allowing a node to run a newer Windows Server version without requiring containers to be rebuilt + +* Backwards compatibility allowing a node to run a newer Windows Server + version without requiring containers to be rebuilt + * Specific CPU/NUMA settings for a pod + * Memory isolation and reservations -Hyper-V isolation support will be added in a later release and will require CRI-Containerd. +Hyper-V isolation support will be added in a later release and will require +CRI-Containerd. ### Deployment with kubeadm and cluster API Kubeadm is becoming the de facto standard for users to deploy a Kubernetes cluster. Windows node support in kubeadm is currently a work-in-progress but a -guide is available [here](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/). -We are also making investments in cluster API to ensure Windows nodes are -properly provisioned. +guide is available +[here](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/). We are +also making investments in cluster API to ensure Windows nodes are properly +provisioned. diff --git a/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md index ce7aee8a89..ec47f5637a 100644 --- a/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -11,7 +11,8 @@ weight: 75 -Windows applications constitute a large portion of the services and applications that run in many organizations. This guide walks you through the steps to configure and deploy a Windows container in Kubernetes. +Windows applications constitute a large portion of the services and applications that run in many organizations. +This guide walks you through the steps to configure and deploy a Windows container in Kubernetes. @@ -24,12 +25,18 @@ Windows applications constitute a large portion of the services and applications ## Before you begin -* Create a Kubernetes cluster that includes a [master and a worker node running Windows Server](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes) -* It is important to note that creating and deploying services and workloads on Kubernetes behaves in much the same way for Linux and Windows containers. [Kubectl commands](/docs/reference/kubectl/overview/) to interface with the cluster are identical. The example in the section below is provided to jumpstart your experience with Windows containers. +* Create a Kubernetes cluster that includes a +control plane and a [worker node running Windows Server](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/) +* It is important to note that creating and deploying services and workloads on Kubernetes +behaves in much the same way for Linux and Windows containers. +[Kubectl commands](/docs/reference/kubectl/overview/) to interface with the cluster are identical. +The example in the section below is provided to jumpstart your experience with Windows containers. ## Getting Started: Deploying a Windows container -To deploy a Windows container on Kubernetes, you must first create an example application. The example YAML file below creates a simple webserver application. Create a service spec named `win-webserver.yaml` with the contents below: +To deploy a Windows container on Kubernetes, you must first create an example application. +The example YAML file below creates a simple webserver application. +Create a service spec named `win-webserver.yaml` with the contents below: ```yaml apiVersion: v1 @@ -76,7 +83,8 @@ spec: ``` {{< note >}} -Port mapping is also supported, but for simplicity in this example the container port 80 is exposed directly to the service. +Port mapping is also supported, but for simplicity in this example +the container port 80 is exposed directly to the service. {{< /note >}} 1. Check that all nodes are healthy: @@ -97,52 +105,86 @@ Port mapping is also supported, but for simplicity in this example the container 1. Check that the deployment succeeded. To verify: * Two containers per pod on the Windows node, use `docker ps` - * Two pods listed from the Linux master, use `kubectl get pods` - * Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux master to check for a web server response - * Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node) using docker exec or kubectl exec - * Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`) from the Linux master and from individual pods + * Two pods listed from the Linux control plane node, use `kubectl get pods` + * Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux control plane node + to check for a web server response + * Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node) + using docker exec or kubectl exec + * Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`) + from the Linux control plane node and from individual pods * Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/docs/concepts/services-networking/dns-pod-service/#services) - * Inbound connectivity, `curl` the NodePort from the Linux master or machines outside of the cluster + * Inbound connectivity, `curl` the NodePort from the Linux control plane node or machines outside of the cluster * Outbound connectivity, `curl` external IPs from inside the pod using kubectl exec {{< note >}} -Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack. Only Windows pods are able to access service IPs. +Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack. +Only Windows pods are able to access service IPs. {{< /note >}} ## Observability ### Capturing logs from workloads -Logs are an important element of observability; they enable users to gain insights into the operational aspect of workloads and are a key ingredient to troubleshooting issues. Because Windows containers and workloads inside Windows containers behave differently from Linux containers, users had a hard time collecting logs, limiting operational visibility. Windows workloads for example are usually configured to log to ETW (Event Tracing for Windows) or push entries to the application event log. [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor), an open source tool by Microsoft, is the recommended way to monitor configured log sources inside a Windows container. LogMonitor supports monitoring event logs, ETW providers, and custom application logs, piping them to STDOUT for consumption by `kubectl logs `. +Logs are an important element of observability; they enable users to gain insights +into the operational aspect of workloads and are a key ingredient to troubleshooting issues. +Because Windows containers and workloads inside Windows containers behave differently from Linux containers, +users had a hard time collecting logs, limiting operational visibility. +Windows workloads for example are usually configured to log to ETW (Event Tracing for Windows) +or push entries to the application event log. +[LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor), an open source tool by Microsoft, +is the recommended way to monitor configured log sources inside a Windows container. +LogMonitor supports monitoring event logs, ETW providers, and custom application logs, +piping them to STDOUT for consumption by `kubectl logs `. -Follow the instructions in the LogMonitor GitHub page to copy its binaries and configuration files to all your containers and add the necessary entrypoints for LogMonitor to push your logs to STDOUT. +Follow the instructions in the LogMonitor GitHub page to copy its binaries and configuration files +to all your containers and add the necessary entrypoints for LogMonitor to push your logs to STDOUT. ## Using configurable Container usernames -Starting with Kubernetes v1.16, Windows containers can be configured to run their entrypoints and processes with different usernames than the image defaults. The way this is achieved is a bit different from the way it is done for Linux containers. Learn more about it [here](/docs/tasks/configure-pod-container/configure-runasusername/). +Starting with Kubernetes v1.16, Windows containers can be configured to run their entrypoints and processes +with different usernames than the image defaults. +The way this is achieved is a bit different from the way it is done for Linux containers. +Learn more about it [here](/docs/tasks/configure-pod-container/configure-runasusername/). ## Managing Workload Identity with Group Managed Service Accounts -Starting with Kubernetes v1.14, Windows container workloads can be configured to use Group Managed Service Accounts (GMSA). Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA. Learn more about configuring and using GMSA for Windows containers [here](/docs/tasks/configure-pod-container/configure-gmsa/). +Starting with Kubernetes v1.14, Windows container workloads can be configured to use Group Managed Service Accounts (GMSA). +Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, +simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. +Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA. +Learn more about configuring and using GMSA for Windows containers [here](/docs/tasks/configure-pod-container/configure-gmsa/). ## Taints and Tolerations -Users today need to use some combination of taints and node selectors in order to keep Linux and Windows workloads on their respective OS-specific nodes. This likely imposes a burden only on Windows users. The recommended approach is outlined below, with one of its main goals being that this approach should not break compatibility for existing Linux workloads. +Users today need to use some combination of taints and node selectors in order to +keep Linux and Windows workloads on their respective OS-specific nodes. +This likely imposes a burden only on Windows users. The recommended approach is outlined below, +with one of its main goals being that this approach should not break compatibility for existing Linux workloads. ### Ensuring OS-specific workloads land on the appropriate container host -Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations. All Kubernetes nodes today have the following default labels: +Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations. +All Kubernetes nodes today have the following default labels: * kubernetes.io/os = [windows|linux] * kubernetes.io/arch = [amd64|arm64|...] -If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`, it is possible the Pod can be scheduled on any host, Windows or Linux. This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector. +If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`, +it is possible the Pod can be scheduled on any host, Windows or Linux. +This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. +The best practice is to use a nodeSelector. -However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. In those situations, you may be hesitant to make the configuration change to add nodeSelectors. The alternative is to use Taints. Because the kubelet can set Taints during registration, it could easily be modified to automatically add a taint when running on Windows only. +However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, +as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. +In those situations, you may be hesitant to make the configuration change to add nodeSelectors. +The alternative is to use Taints. Because the kubelet can set Taints during registration, +it could easily be modified to automatically add a taint when running on Windows only. For example: `--register-with-taints='os=windows:NoSchedule'` -By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). In order for a Windows Pod to be scheduled on a Windows node, it would need both the nodeSelector to choose Windows, and the appropriate matching toleration. +By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). +In order for a Windows Pod to be scheduled on a Windows node, +it would need both the nodeSelector and the appropriate matching toleration to choose Windows. ```yaml nodeSelector: @@ -160,9 +202,11 @@ tolerations: The Windows Server version used by each pod must match that of the node. If you want to use multiple Windows Server versions in the same cluster, then you should set additional node labels and nodeSelectors. -Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this. If you're running an older version, then it's recommended to add this label manually to Windows nodes. +Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this. +If you're running an older version, then it's recommended to add this label manually to Windows nodes. -This label reflects the Windows major, minor, and build number that need to match for compatibility. Here are values used today for each Windows Server version. +This label reflects the Windows major, minor, and build number that need to match for compatibility. +Here are values used today for each Windows Server version. | Product Name | Build Number(s) | |--------------------------------------|------------------------| @@ -173,10 +217,12 @@ This label reflects the Windows major, minor, and build number that need to matc ### Simplifying with RuntimeClass -[RuntimeClass] can be used to simplify the process of using taints and tolerations. A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations. +[RuntimeClass] can be used to simplify the process of using taints and tolerations. +A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations. -1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector` for the Windows OS, architecture, and version. +1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector` +for the Windows OS, architecture, and version. ```yaml apiVersion: node.k8s.io/v1 diff --git a/content/en/docs/setup/release/_index.md b/content/en/docs/setup/release/_index.md deleted file mode 100755 index e6d5944331..0000000000 --- a/content/en/docs/setup/release/_index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: "Release notes and version skew" -weight: 10 ---- diff --git a/content/en/docs/setup/release/notes.md b/content/en/docs/setup/release/notes.md deleted file mode 100644 index 54146007a0..0000000000 --- a/content/en/docs/setup/release/notes.md +++ /dev/null @@ -1,2141 +0,0 @@ ---- -title: v1.20 Release Notes -weight: 10 -card: - name: release-notes - weight: 20 - anchors: - - anchor: "#" - title: Current Release Notes - - anchor: "#urgent-upgrade-notes" - title: Urgent Upgrade Notes ---- - - - -# v1.20.0 - -[Documentation](https://docs.k8s.io) - -## Downloads for v1.20.0 - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes.tar.gz) | `ebfe49552bbda02807034488967b3b62bf9e3e507d56245e298c4c19090387136572c1fca789e772a5e8a19535531d01dcedb61980e42ca7b0461d3864df2c14` -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-src.tar.gz) | `bcbd67ed0bb77840828c08c6118ad0c9bf2bcda16763afaafd8731fd6ce735be654feef61e554bcc34c77c65b02a25dae565adc5e1dc49a2daaa0d115bf1efe6` - -### Client Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-darwin-amd64.tar.gz) | `3609f6483f4244676162232b3294d7a2dc40ae5bdd86a842a05aa768f5223b8f50e1d6420fd8afb2d0ce19de06e1d38e5e5b10154ba0cb71a74233e6dc94d5a0` -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-linux-386.tar.gz) | `e06c08016a08137d39804383fdc33a40bb2567aa77d88a5c3fd5b9d93f5b581c635b2c4faaa718ed3bb2d120cb14fe91649ed4469ba72c3a3dda1e343db545ed` -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-linux-amd64.tar.gz) | `081472833601aa4fa78e79239f67833aa4efcb4efe714426cd01d4ddf6f36fbf304ef7e1f5373bff0fdff44a845f7560165c093c108bd359b5ab4189f36b1f2f` -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-linux-arm.tar.gz) | `037f84a2f29fe62d266cab38ac5600d058cce12cbc4851bcf062fafba796c1fbe23a0c2939cd15784854ca7cd92383e5b96a11474fc71fb614b47dbf98a477d9` -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-linux-arm64.tar.gz) | `275727e1796791ca3cbe52aaa713a2660404eab6209466fdc1cfa8559c9b361fe55c64c6bcecbdeba536b6d56213ddf726e58adc60f959b6f77e4017834c5622` -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-linux-ppc64le.tar.gz) | `7a9965293029e9fcdb2b7387467f022d2026953b8461e6c84182abf35c28b7822d2389a6d8e4d8e532d2ea5d5d67c6fee5fb6c351363cb44c599dc8800649b04` -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-linux-s390x.tar.gz) | `85fc449ce1980f5f030cc32e8c8e2198c1cc91a448e04b15d27debc3ca56aa85d283f44b4f4e5fed26ac96904cc12808fa3e9af3d8bf823fc928befb9950d6f5` -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-windows-386.tar.gz) | `4c0a27dba1077aaee943e0eb7a787239dd697e1d968e78d1933c1e60b02d5d233d58541d5beec59807a4ffe3351d5152359e11da120bf64cacb3ee29fbc242e6` -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-windows-amd64.tar.gz) | `29336faf7c596539b8329afbbdceeddc843162501de4afee44a40616278fa1f284d8fc48c241fc7d52c65dab70f76280cc33cec419c8c5dbc2625d9175534af8` - -### Server Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-server-linux-amd64.tar.gz) | `fb56486a55dbf7dbacb53b1aaa690bae18d33d244c72a1e2dc95fb0fcce45108c44ba79f8fa04f12383801c46813dc33d2d0eb2203035cdce1078871595e446e` -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-server-linux-arm.tar.gz) | `735ed9993071fe35b292bf06930ee3c0f889e3c7edb983195b1c8e4d7113047c12c0f8281fe71879fc2fcd871e1ee587f03b695a03c8512c873abad444997a19` -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-server-linux-arm64.tar.gz) | `ffab155531d5a9b82487ee1abf4f6ef49626ea58b2de340656a762e46cf3e0f470bdbe7821210901fe1114224957c44c1d9cc1e32efb5ee24e51fe63990785b2` -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-server-linux-ppc64le.tar.gz) | `9d5730d35c4ddfb4c5483173629fe55df35d1e535d96f02459468220ac2c97dc01b995f577432a6e4d1548b6edbfdc90828dc9c1f7cf7464481af6ae10aaf118` -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-server-linux-s390x.tar.gz) | `6e4c165306940e8b99dd6e590f8542e31aed23d2c7a6808af0357fa425cec1a57016dd66169cf2a95f8eb8ef70e1f29e2d500533aae889e2e3d9290d04ab8721` - -### Node Binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-node-linux-amd64.tar.gz) | `3e6c90561dd1c27fa1dff6953c503251c36001f7e0f8eff3ec918c74ae2d9aa25917d8ac87d5b4224b8229f620b1830442e6dce3b2a497043f8497eee3705696` -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-node-linux-arm.tar.gz) | `26db385d9ae9a97a1051a638e7e3de22c4bbff389d5a419fe40d5893f9e4fa85c8b60a2bd1d370fd381b60c3ca33c5d72d4767c90898caa9dbd4df6bd116a247` -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-node-linux-arm64.tar.gz) | `5b8b63f617e248432b7eb913285a8ef8ba028255216332c05db949666c3f9e9cb9f4c393bbd68d00369bda77abf9bfa2da254a5c9fe0d79ffdad855a77a9d8ed` -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-node-linux-ppc64le.tar.gz) | `60da7715996b4865e390640525d6e98593ba3cd45c6caeea763aa5355a7f989926da54f58cc5f657f614c8134f97cd3894b899f8b467d100dca48bc22dd4ff63` -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-node-linux-s390x.tar.gz) | `9407dc55412bd04633f84fcefe3a1074f3eaa772a7cb9302242b8768d6189b75d37677a959f91130e8ad9dc590f9ba8408ba6700a0ceff6827315226dd5ee1e6` -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-node-windows-amd64.tar.gz) | `9d4261af343cc330e6359582f80dbd6efb57d41f882747a94bbf47b4f93292d43dd19a86214d4944d268941622dfbc96847585e6fec15fddc4dbd93d17015fa8` - -## Changelog since v1.19.0 - -## What's New (Major Themes) - -### Dockershim deprecation - -Docker as an underlying runtime is being deprecated. Docker-produced images will continue to work in your cluster with all runtimes, as they always have. -The Kubernetes community [has written a blog post about this in detail](https://blog.k8s.io/2020/12/02/dont-panic-kubernetes-and-docker/) with [a dedicated FAQ page for it](https://blog.k8s.io/2020/12/02/dockershim-faq/). - -### External credential provider for client-go - -The client-go credential plugins can now be passed in the current cluster information via the `KUBERNETES_EXEC_INFO` environment variable. Learn more about this on [client-go credential plugins documentation](https://docs.k8s.io/reference/access-authn-authz/authentication/#client-go-credential-plugins/). - -### CronJob controller v2 is available through feature gate - -An alternative implementation of `CronJob` controller is now available as an alpha feature in this release, which has experimental performance improvement by using informers instead of polling. While this will be the default behavior in the future, you can [try them in this release through a feature gate](https://docs.k8s.io/concepts/workloads/controllers/cron-jobs/). - -### PID Limits graduates to General Availability - -PID Limits features are now generally available on both `SupportNodePidsLimit` (node-to-pod PID isolation) and `SupportPodPidsLimit` (ability to limit PIDs per pod), after being enabled-by-default in beta stage for a year. - -### API Priority and Fairness graduates to Beta - -Initially introduced in 1.18, Kubernetes 1.20 now enables API Priority and Fairness (APF) by default. This allows `kube-apiserver` to [categorize incoming requests by priority levels](https://docs.k8s.io/concepts/cluster-administration/flow-control/). - -### IPv4/IPv6 run - -IPv4/IPv6 dual-stack has been reimplemented for 1.20 to support dual-stack Services, based on user and community feedback. If your cluster has dual-stack enabled, you can create Services which can use IPv4, IPv6, or both, and you can change this setting for existing Services. Details are available in updated [IPv4/IPv6 dual-stack docs](https://docs.k8s.io/concepts/services-networking/dual-stack/), which cover the nuanced array of options. - -We expect this implementation to progress from alpha to beta and GA in coming releases, so we’re eager to have you comment about your dual-stack experiences in [#k8s-dual-stack](https://kubernetes.slack.com/messages/k8s-dual-stack) or in [enhancements #563](https://features.k8s.io/563). - -### go1.15.5 - -go1.15.5 has been integrated to Kubernetes project as of this release, [including other infrastructure related updates on this effort](https://github.com/kubernetes/kubernetes/pull/95776). - -### CSI Volume Snapshot graduates to General Availability - -CSI Volume Snapshot moves to GA in the 1.20 release. This feature provides a standard way to trigger volume snapshot operations in Kubernetes and allows Kubernetes users to incorporate snapshot operations in a portable manner on any Kubernetes environment regardless of supporting underlying storage providers. -Additionally, these Kubernetes snapshot primitives act as basic building blocks that unlock the ability to develop advanced, enterprise grade, storage administration features for Kubernetes: including application or cluster level backup solutions. -Note that snapshot support will require Kubernetes distributors to bundle the Snapshot controller, Snapshot CRDs, and validation webhook. In addition, a CSI driver supporting the snapshot functionality must also be deployed on the cluster. - -### Non-recursive Volume Ownership (FSGroup) graduates to Beta - -By default, the `fsgroup` setting, if specified, recursively updates permissions for every file in a volume on every mount. This can make mount, and pod startup, very slow if the volume has many files. -This setting enables a pod to specify a `PodFSGroupChangePolicy` that indicates that volume ownership and permissions will be changed only when permission and ownership of the root directory does not match with expected permissions on the volume. - -### CSIDriver policy for FSGroup graduates to Beta - -The FSGroup's CSIDriver Policy is now beta in 1.20. This allows CSIDrivers to explicitly indicate if they want Kubernetes to manage permissions and ownership for their volumes via `fsgroup`. - -### Security Improvements for CSI Drivers (Alpha) - -In 1.20, we introduce a new alpha feature `CSIServiceAccountToken`. This feature allows CSI drivers to impersonate the pods that they mount the volumes for. This improves the security posture in the mounting process where the volumes are ACL’ed on the pods’ service account without handing out unnecessary permissions to the CSI drivers’ service account. This feature is especially important for secret-handling CSI drivers, such as the secrets-store-csi-driver. Since these tokens can be rotated and short-lived, this feature also provides a knob for CSI drivers to receive `NodePublishVolume` RPC calls periodically with the new token. This knob is also useful when volumes are short-lived, e.g. certificates. - -### Introducing Graceful Node Shutdown (Alpha) - -The `GracefulNodeShutdown` feature is now in Alpha. This allows kubelet to be aware of node system shutdowns, enabling graceful termination of pods during a system shutdown. This feature can be [enabled through feature gate](https://docs.k8s.io/concepts/architecture/nodes/#graceful-node-shutdown). - -### Runtime log sanitation - -Logs can now be configured to use runtime protection from leaking sensitive data. [Details for this experimental feature is available in documentation](https://docs.k8s.io/concepts/cluster-administration/system-logs/#log-sanitization). - -### Pod resource metrics - -On-demand metrics calculation is now available through `/metrics/resources`. [When enabled]( -https://docs.k8s.io/concepts/cluster-administration/system-metrics#kube-scheduler-metrics), the endpoint will report the requested resources and the desired limits of all running pods. - -### Introducing `RootCAConfigMap` - -`RootCAConfigMap` graduates to Beta, seperating from `BoundServiceAccountTokenVolume`. The `kube-root-ca.crt` ConfigMap is now available to every namespace, by default. It contains the Certificate Authority bundle for verify kube-apiserver connections. - -### `kubectl debug` graduates to Beta - -`kubectl alpha debug` graduates from alpha to beta in 1.20, becoming `kubectl debug`. -`kubectl debug` provides support for common debugging workflows directly from kubectl. Troubleshooting scenarios supported in this release of `kubectl` include: -Troubleshoot workloads that crash on startup by creating a copy of the pod that uses a different container image or command. -Troubleshoot distroless containers by adding a new container with debugging tools, either in a new copy of the pod or using an ephemeral container. (Ephemeral containers are an alpha feature that are not enabled by default.) -Troubleshoot on a node by creating a container running in the host namespaces and with access to the host’s filesystem. -Note that as a new builtin command, `kubectl debug` takes priority over any `kubectl` plugin named “debug”. You will need to rename the affected plugin. -Invocations using `kubectl alpha debug` are now deprecated and will be removed in a subsequent release. Update your scripts to use `kubectl debug` instead of `kubectl alpha debug`! -For more information about kubectl debug, see Debugging Running Pods on the Kubernetes website, kubectl help debug, or reach out to SIG CLI by visiting #sig-cli or commenting on [enhancement #1441](https://features.k8s.io/1441). - -### Removing deprecated flags in kubeadm - -`kubeadm` applies a number of deprecations and removals of deprecated features in this release. More details are available in the Urgent Upgrade Notes and Kind / Deprecation sections. - -### Pod Hostname as FQDN graduates to Beta - -Previously introduced in 1.19 behind a feature gate, `SetHostnameAsFQDN` is now enabled by default. More details on this behavior is available in [documentation for DNS for Services and Pods](https://docs.k8s.io/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field) - -### `TokenRequest` / `TokenRequestProjection` graduates to General Availability - -Service account tokens bound to pod is now a stable feature. The feature gates will be removed in 1.21 release. For more information, refer to notes below on the changelogs. - -### RuntimeClass feature graduates to General Availability. - -The `node.k8s.io` API groups are promoted from `v1beta1` to `v1`. `v1beta1` is now deprecated and will be removed in a future release, please start using `v1`. ([#95718](https://github.com/kubernetes/kubernetes/pull/95718), [@SergeyKanzhelev](https://github.com/SergeyKanzhelev)) [SIG Apps, Auth, Node, Scheduling and Testing] - -### Cloud Controller Manager now exclusively shipped by Cloud Provider - -Kubernetes will no longer ship an instance of the Cloud Controller Manager binary. Each Cloud Provider is expected to ship their own instance of this binary. Details for a Cloud Provider to create an instance of such a binary can be found under [here](https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/cloud-provider/sample). Anyone with questions on building a Cloud Controller Manager should reach out to SIG Cloud Provider. Questions about the Cloud Controller Manager on a Managed Kubernetes solution should go to the relevant Cloud Provider. Questions about the Cloud Controller Manager on a non managed solution can be brought up with SIG Cloud Provider. - -## Known Issues - -### Summary API in kubelet doesn't have accelerator metrics -Currently, cadvisor_stats_provider provides AcceleratorStats but cri_stats_provider does not. As a result, when using cri_stats_provider, kubelet's Summary API does not have accelerator metrics. [There is an open work in progress to fix this](https://github.com/kubernetes/kubernetes/pull/96873). - -## Urgent Upgrade Notes - -### (No, really, you MUST read this before you upgrade) - -- A bug was fixed in kubelet where exec probe timeouts were not respected. This may result in unexpected behavior since the default timeout (if not specified) is `1s` which may be too small for some exec probes. Ensure that pods relying on this behavior are updated to correctly handle probe timeouts. See [configure probe](https://docs.k8s.io/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes) section of the documentation for more details. - - - This change in behavior may be unexpected for some clusters and can be disabled by turning off the `ExecProbeTimeout` feature gate. This gate will be locked and removed in future releases so that exec probe timeouts are always respected. ([#94115](https://github.com/kubernetes/kubernetes/pull/94115), [@andrewsykim](https://github.com/andrewsykim)) [SIG Node and Testing] -- RuntimeClass feature graduates to General Availability. Promote `node.k8s.io` API groups from `v1beta1` to `v1`. `v1beta1` is now deprecated and will be removed in a future release, please start using `v1`. ([#95718](https://github.com/kubernetes/kubernetes/pull/95718), [@SergeyKanzhelev](https://github.com/SergeyKanzhelev)) [SIG Apps, Auth, Node, Scheduling and Testing] -- API priority and fairness graduated to beta. 1.19 servers with APF turned on should not be run in a multi-server cluster with 1.20+ servers. ([#96527](https://github.com/kubernetes/kubernetes/pull/96527), [@adtac](https://github.com/adtac)) [SIG API Machinery and Testing] -- For CSI drivers, kubelet no longer creates the target_path for NodePublishVolume in accordance with the CSI spec. Kubelet also no longer checks if staging and target paths are mounts or corrupted. CSI drivers need to be idempotent and do any necessary mount verification. ([#88759](https://github.com/kubernetes/kubernetes/pull/88759), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage] -- Kubeadm: http://git.k8s.io/enhancements/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint/README.md ([#95382](https://github.com/kubernetes/kubernetes/pull/95382), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] - - The label applied to control-plane nodes "node-role.kubernetes.io/master" is now deprecated and will be removed in a future release after a GA deprecation period. - - Introduce a new label "node-role.kubernetes.io/control-plane" that will be applied in parallel to "node-role.kubernetes.io/master" until the removal of the "node-role.kubernetes.io/master" label. - - Make "kubeadm upgrade apply" add the "node-role.kubernetes.io/control-plane" label on existing nodes that only have the "node-role.kubernetes.io/master" label during upgrade. - - Please adapt your tooling built on top of kubeadm to use the "node-role.kubernetes.io/control-plane" label. - - The taint applied to control-plane nodes "node-role.kubernetes.io/master:NoSchedule" is now deprecated and will be removed in a future release after a GA deprecation period. - - Apply toleration for a new, future taint "node-role.kubernetes.io/control-plane:NoSchedule" to the kubeadm CoreDNS / kube-dns managed manifests. Note that this taint is not yet applied to kubeadm control-plane nodes. - - Please adapt your workloads to tolerate the same future taint preemptively. - -- Kubeadm: improve the validation of serviceSubnet and podSubnet. - ServiceSubnet has to be limited in size, due to implementation details, and the mask can not allocate more than 20 bits. - PodSubnet validates against the corresponding cluster "--node-cidr-mask-size" of the kube-controller-manager, it fail if the values are not compatible. - kubeadm no longer sets the node-mask automatically on IPv6 deployments, you must check that your IPv6 service subnet mask is compatible with the default node mask /64 or set it accordenly. - Previously, for IPv6, if the podSubnet had a mask lower than /112, kubeadm calculated a node-mask to be multiple of eight and splitting the available bits to maximise the number used for nodes. ([#95723](https://github.com/kubernetes/kubernetes/pull/95723), [@aojea](https://github.com/aojea)) [SIG Cluster Lifecycle] -- The deprecated flag --experimental-kustomize is now removed from kubeadm commands. Use --experimental-patches instead, which was introduced in 1.19. Migration information available in --help description for --experimental-patches. ([#94871](https://github.com/kubernetes/kubernetes/pull/94871), [@neolit123](https://github.com/neolit123)) -- Windows hyper-v container featuregate is deprecated in 1.20 and will be removed in 1.21 ([#95505](https://github.com/kubernetes/kubernetes/pull/95505), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] -- The kube-apiserver ability to serve on an insecure port, deprecated since v1.10, has been removed. The insecure address flags `--address` and `--insecure-bind-address` have no effect in kube-apiserver and will be removed in v1.24. The insecure port flags `--port` and `--insecure-port` may only be set to 0 and will be removed in v1.24. ([#95856](https://github.com/kubernetes/kubernetes/pull/95856), [@knight42](https://github.com/knight42), [SIG API Machinery, Node, Testing]) -- Add dual-stack Services (alpha). This is a BREAKING CHANGE to an alpha API. - It changes the dual-stack API wrt Service from a single ipFamily field to 3 - fields: ipFamilyPolicy (SingleStack, PreferDualStack, RequireDualStack), - ipFamilies (a list of families assigned), and clusterIPs (inclusive of - clusterIP). Most users do not need to set anything at all, defaulting will - handle it for them. Services are single-stack unless the user asks for - dual-stack. This is all gated by the "IPv6DualStack" feature gate. ([#91824](https://github.com/kubernetes/kubernetes/pull/91824), [@khenidak](https://github.com/khenidak)) [SIG API Machinery, Apps, CLI, Network, Node, Scheduling and Testing] -- `TokenRequest` and `TokenRequestProjection` are now GA features. The following flags are required by the API server: - - `--service-account-issuer`, should be set to a URL identifying the API server that will be stable over the cluster lifetime. - - `--service-account-key-file`, set to one or more files containing one or more public keys used to verify tokens. - - `--service-account-signing-key-file`, set to a file containing a private key to use to sign service account tokens. Can be the same file given to `kube-controller-manager` with `--service-account-private-key-file`. ([#95896](https://github.com/kubernetes/kubernetes/pull/95896), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Auth, Cluster Lifecycle] -- kubeadm: make the command "kubeadm alpha kubeconfig user" accept a "--config" flag and remove the following flags: - - apiserver-advertise-address / apiserver-bind-port: use either localAPIEndpoint from InitConfiguration or controlPlaneEndpoint from ClusterConfiguration. - - cluster-name: use clusterName from ClusterConfiguration - - cert-dir: use certificatesDir from ClusterConfiguration ([#94879](https://github.com/kubernetes/kubernetes/pull/94879), [@knight42](https://github.com/knight42)) [SIG Cluster Lifecycle] -- Resolves non-deterministic behavior of the garbage collection controller when ownerReferences with incorrect data are encountered. Events with a reason of `OwnerRefInvalidNamespace` are recorded when namespace mismatches between child and owner objects are detected. The [kubectl-check-ownerreferences](https://github.com/kubernetes-sigs/kubectl-check-ownerreferences) tool can be run prior to upgrading to locate existing objects with invalid ownerReferences. - - A namespaced object with an ownerReference referencing a uid of a namespaced kind which does not exist in the same namespace is now consistently treated as though that owner does not exist, and the child object is deleted. - - A cluster-scoped object with an ownerReference referencing a uid of a namespaced kind is now consistently treated as though that owner is not resolvable, and the child object is ignored by the garbage collector. ([#92743](https://github.com/kubernetes/kubernetes/pull/92743), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Testing] - - -## Changes by Kind - -### Deprecation - -- Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. ([#94624](https://github.com/kubernetes/kubernetes/pull/94624), [@dims](https://github.com/dims)) [SIG Node] -- Kubeadm: deprecate self-hosting support. The experimental command "kubeadm alpha self-hosting" is now deprecated and will be removed in a future release. ([#95125](https://github.com/kubernetes/kubernetes/pull/95125), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: graduate the "kubeadm alpha certs" command to a parent command "kubeadm certs". The command "kubeadm alpha certs" is deprecated and will be removed in a future release. Please migrate. ([#94938](https://github.com/kubernetes/kubernetes/pull/94938), [@yagonobre](https://github.com/yagonobre)) [SIG Cluster Lifecycle] -- Kubeadm: remove the deprecated "kubeadm alpha kubelet config enable-dynamic" command. To continue using the feature please defer to the guide for "Dynamic Kubelet Configuration" at k8s.io. This change also removes the parent command "kubeadm alpha kubelet" as there are no more sub-commands under it for the time being. ([#94668](https://github.com/kubernetes/kubernetes/pull/94668), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: remove the deprecated --kubelet-config flag for the command "kubeadm upgrade node" ([#94869](https://github.com/kubernetes/kubernetes/pull/94869), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubectl: deprecate --delete-local-data ([#95076](https://github.com/kubernetes/kubernetes/pull/95076), [@dougsland](https://github.com/dougsland)) [SIG CLI, Cloud Provider and Scalability] -- Kubelet's deprecated endpoint `metrics/resource/v1alpha1` has been removed, please adopt `metrics/resource`. ([#94272](https://github.com/kubernetes/kubernetes/pull/94272), [@RainbowMango](https://github.com/RainbowMango)) [SIG Instrumentation and Node] -- Removes deprecated scheduler metrics DeprecatedSchedulingDuration, DeprecatedSchedulingAlgorithmPredicateEvaluationSecondsDuration, DeprecatedSchedulingAlgorithmPriorityEvaluationSecondsDuration ([#94884](https://github.com/kubernetes/kubernetes/pull/94884), [@arghya88](https://github.com/arghya88)) [SIG Instrumentation and Scheduling] -- Scheduler alpha metrics binding_duration_seconds and scheduling_algorithm_preemption_evaluation_seconds are deprecated, Both of those metrics are now covered as part of framework_extension_point_duration_seconds, the former as a PostFilter the latter and a Bind plugin. The plan is to remove both in 1.21 ([#95001](https://github.com/kubernetes/kubernetes/pull/95001), [@arghya88](https://github.com/arghya88)) [SIG Instrumentation and Scheduling] -- Support 'controlplane' as a valid EgressSelection type in the EgressSelectorConfiguration API. 'Master' is deprecated and will be removed in v1.22. ([#95235](https://github.com/kubernetes/kubernetes/pull/95235), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery] -- The v1alpha1 PodPreset API and admission plugin has been removed with no built-in replacement. Admission webhooks can be used to modify pods on creation. ([#94090](https://github.com/kubernetes/kubernetes/pull/94090), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Apps, CLI, Cloud Provider, Scalability and Testing] - - -### API Change - -- `TokenRequest` and `TokenRequestProjection` features have been promoted to GA. This feature allows generating service account tokens that are not visible in Secret objects and are tied to the lifetime of a Pod object. See https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection for details on configuring and using this feature. The `TokenRequest` and `TokenRequestProjection` feature gates will be removed in v1.21. - - kubeadm's kube-apiserver Pod manifest now includes the following flags by default "--service-account-key-file", "--service-account-signing-key-file", "--service-account-issuer". ([#93258](https://github.com/kubernetes/kubernetes/pull/93258), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Auth, Cluster Lifecycle, Storage and Testing] -- A new `nofuzz` go build tag now disables gofuzz support. Release binaries enable this. ([#92491](https://github.com/kubernetes/kubernetes/pull/92491), [@BenTheElder](https://github.com/BenTheElder)) [SIG API Machinery] -- Add WindowsContainerResources and Annotations to CRI-API UpdateContainerResourcesRequest ([#95741](https://github.com/kubernetes/kubernetes/pull/95741), [@katiewasnothere](https://github.com/katiewasnothere)) [SIG Node] -- Add a `serving` and `terminating` condition to the EndpointSlice API. - `serving` tracks the readiness of endpoints regardless of their terminating state. This is distinct from `ready` since `ready` is only true when pods are not terminating. - `terminating` is true when an endpoint is terminating. For pods this is any endpoint with a deletion timestamp. ([#92968](https://github.com/kubernetes/kubernetes/pull/92968), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network] -- Add dual-stack Services (alpha). This is a BREAKING CHANGE to an alpha API. - It changes the dual-stack API wrt Service from a single ipFamily field to 3 - fields: ipFamilyPolicy (SingleStack, PreferDualStack, RequireDualStack), - ipFamilies (a list of families assigned), and clusterIPs (inclusive of - clusterIP). Most users do not need to set anything at all, defaulting will - handle it for them. Services are single-stack unless the user asks for - dual-stack. This is all gated by the "IPv6DualStack" feature gate. ([#91824](https://github.com/kubernetes/kubernetes/pull/91824), [@khenidak](https://github.com/khenidak)) [SIG API Machinery, Apps, CLI, Network, Node, Scheduling and Testing] -- Add support for hugepages to downward API ([#86102](https://github.com/kubernetes/kubernetes/pull/86102), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG API Machinery, Apps, CLI, Network, Node, Scheduling and Testing] -- Adds kubelet alpha feature, `GracefulNodeShutdown` which makes kubelet aware of node system shutdowns and result in graceful termination of pods during a system shutdown. ([#96129](https://github.com/kubernetes/kubernetes/pull/96129), [@bobbypage](https://github.com/bobbypage)) [SIG Node] -- AppProtocol is now GA for Endpoints and Services. The ServiceAppProtocol feature gate will be deprecated in 1.21. ([#96327](https://github.com/kubernetes/kubernetes/pull/96327), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- Automatic allocation of NodePorts for services with type LoadBalancer can now be disabled by setting the (new) parameter - Service.spec.allocateLoadBalancerNodePorts=false. The default is to allocate NodePorts for services with type LoadBalancer which is the existing behavior. ([#92744](https://github.com/kubernetes/kubernetes/pull/92744), [@uablrek](https://github.com/uablrek)) [SIG Apps and Network] -- Certain fields on Service objects will be automatically cleared when changing the service's `type` to a mode that does not need those fields. For example, changing from type=LoadBalancer to type=ClusterIP will clear the NodePort assignments, rather than forcing the user to clear them. ([#95196](https://github.com/kubernetes/kubernetes/pull/95196), [@thockin](https://github.com/thockin)) [SIG API Machinery, Apps, Network and Testing] -- Document that ServiceTopology feature is required to use `service.spec.topologyKeys`. ([#96528](https://github.com/kubernetes/kubernetes/pull/96528), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps] -- EndpointSlice has a new NodeName field guarded by the EndpointSliceNodeName feature gate. - - EndpointSlice topology field will be deprecated in an upcoming release. - - EndpointSlice "IP" address type is formally removed after being deprecated in Kubernetes 1.17. - - The discovery.k8s.io/v1alpha1 API is deprecated and will be removed in Kubernetes 1.21. ([#96440](https://github.com/kubernetes/kubernetes/pull/96440), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps and Network] -- External facing API podresources is now available under k8s.io/kubelet/pkg/apis/ ([#92632](https://github.com/kubernetes/kubernetes/pull/92632), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Node and Testing] -- Fewer candidates are enumerated for preemption to improve performance in large clusters. ([#94814](https://github.com/kubernetes/kubernetes/pull/94814), [@adtac](https://github.com/adtac)) -- Fix conversions for custom metrics. ([#94481](https://github.com/kubernetes/kubernetes/pull/94481), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Instrumentation] -- GPU metrics provided by kubelet are now disabled by default. ([#95184](https://github.com/kubernetes/kubernetes/pull/95184), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) -- If BoundServiceAccountTokenVolume is enabled, cluster admins can use metric `serviceaccount_stale_tokens_total` to monitor workloads that are depending on the extended tokens. If there are no such workloads, turn off extended tokens by starting `kube-apiserver` with flag `--service-account-extend-token-expiration=false` ([#96273](https://github.com/kubernetes/kubernetes/pull/96273), [@zshihang](https://github.com/zshihang)) [SIG API Machinery and Auth] -- Introduce alpha support for exec-based container registry credential provider plugins in the kubelet. ([#94196](https://github.com/kubernetes/kubernetes/pull/94196), [@andrewsykim](https://github.com/andrewsykim)) [SIG Node and Release] -- Introduces a metric source for HPAs which allows scaling based on container resource usage. ([#90691](https://github.com/kubernetes/kubernetes/pull/90691), [@arjunrn](https://github.com/arjunrn)) [SIG API Machinery, Apps, Autoscaling and CLI] -- Kube-apiserver now deletes expired kube-apiserver Lease objects: - - The feature is under feature gate `APIServerIdentity`. - - A flag is added to kube-apiserver: `identity-lease-garbage-collection-check-period-seconds` ([#95895](https://github.com/kubernetes/kubernetes/pull/95895), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery, Apps, Auth and Testing] -- Kube-controller-manager: volume plugins can be restricted from contacting local and loopback addresses by setting `--volume-host-allow-local-loopback=false`, or from contacting specific CIDR ranges by setting `--volume-host-cidr-denylist` (for example, `--volume-host-cidr-denylist=127.0.0.1/28,feed::/16`) ([#91785](https://github.com/kubernetes/kubernetes/pull/91785), [@mattcary](https://github.com/mattcary)) [SIG API Machinery, Apps, Auth, CLI, Network, Node, Storage and Testing] -- Migrate scheduler, controller-manager and cloud-controller-manager to use LeaseLock ([#94603](https://github.com/kubernetes/kubernetes/pull/94603), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, Apps, Cloud Provider and Scheduling] -- Modify DNS-1123 error messages to indicate that RFC 1123 is not followed exactly ([#94182](https://github.com/kubernetes/kubernetes/pull/94182), [@mattfenwick](https://github.com/mattfenwick)) [SIG API Machinery, Apps, Auth, Network and Node] -- Move configurable fsgroup change policy for pods to beta ([#96376](https://github.com/kubernetes/kubernetes/pull/96376), [@gnufied](https://github.com/gnufied)) [SIG Apps and Storage] -- New flag is introduced, i.e. --topology-manager-scope=container|pod. - The default value is the "container" scope. ([#92967](https://github.com/kubernetes/kubernetes/pull/92967), [@cezaryzukowski](https://github.com/cezaryzukowski)) [SIG Instrumentation, Node and Testing] -- New parameter `defaultingType` for `PodTopologySpread` plugin allows to use k8s defined or user provided default constraints ([#95048](https://github.com/kubernetes/kubernetes/pull/95048), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- NodeAffinity plugin can be configured with AddedAffinity. ([#96202](https://github.com/kubernetes/kubernetes/pull/96202), [@alculquicondor](https://github.com/alculquicondor)) [SIG Node, Scheduling and Testing] -- Promote RuntimeClass feature to GA. - Promote node.k8s.io API groups from v1beta1 to v1. ([#95718](https://github.com/kubernetes/kubernetes/pull/95718), [@SergeyKanzhelev](https://github.com/SergeyKanzhelev)) [SIG Apps, Auth, Node, Scheduling and Testing] -- Reminder: The labels "failure-domain.beta.kubernetes.io/zone" and "failure-domain.beta.kubernetes.io/region" are deprecated in favor of "topology.kubernetes.io/zone" and "topology.kubernetes.io/region" respectively. All users of the "failure-domain.beta..." labels should switch to the "topology..." equivalents. ([#96033](https://github.com/kubernetes/kubernetes/pull/96033), [@thockin](https://github.com/thockin)) [SIG API Machinery, Apps, CLI, Cloud Provider, Network, Node, Scheduling, Storage and Testing] -- Server Side Apply now treats LabelSelector fields as atomic (meaning the entire selector is managed by a single writer and updated together), since they contain interrelated and inseparable fields that do not merge in intuitive ways. ([#93901](https://github.com/kubernetes/kubernetes/pull/93901), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Storage and Testing] -- Services will now have a `clusterIPs` field to go with `clusterIP`. `clusterIPs[0]` is a synonym for `clusterIP` and will be syncronized on create and update operations. ([#95894](https://github.com/kubernetes/kubernetes/pull/95894), [@thockin](https://github.com/thockin)) [SIG Network] -- The ServiceAccountIssuerDiscovery feature gate is now Beta and enabled by default. ([#91921](https://github.com/kubernetes/kubernetes/pull/91921), [@mtaufen](https://github.com/mtaufen)) [SIG Auth] -- The status of v1beta1 CRDs without "preserveUnknownFields:false" now shows a violation, "spec.preserveUnknownFields: Invalid value: true: must be false". ([#93078](https://github.com/kubernetes/kubernetes/pull/93078), [@vareti](https://github.com/vareti)) -- The usage of mixed protocol values in the same LoadBalancer Service is possible if the new feature gate MixedProtocolLBService is enabled. The feature gate is disabled by default. The user has to enable it for the API Server. ([#94028](https://github.com/kubernetes/kubernetes/pull/94028), [@janosi](https://github.com/janosi)) [SIG API Machinery and Apps] -- This PR will introduce a feature gate CSIServiceAccountToken with two additional fields in `CSIDriverSpec`. ([#93130](https://github.com/kubernetes/kubernetes/pull/93130), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Apps, Auth, CLI, Network, Node, Storage and Testing] -- Users can try the cronjob controller v2 using the feature gate. This will be the default controller in future releases. ([#93370](https://github.com/kubernetes/kubernetes/pull/93370), [@alaypatel07](https://github.com/alaypatel07)) [SIG API Machinery, Apps, Auth and Testing] -- VolumeSnapshotDataSource moves to GA in 1.20 release ([#95282](https://github.com/kubernetes/kubernetes/pull/95282), [@xing-yang](https://github.com/xing-yang)) [SIG Apps] -- WinOverlay feature graduated to beta ([#94807](https://github.com/kubernetes/kubernetes/pull/94807), [@ksubrmnn](https://github.com/ksubrmnn)) [SIG Windows] - -### Feature - -- **Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.**: -- A new metric `apiserver_request_filter_duration_seconds` has been introduced that - measures request filter latency in seconds. ([#95207](https://github.com/kubernetes/kubernetes/pull/95207), [@tkashem](https://github.com/tkashem)) [SIG API Machinery and Instrumentation] -- A new set of alpha metrics are reported by the Kubernetes scheduler under the `/metrics/resources` endpoint that allow administrators to easily see the resource consumption (requests and limits for all resources on the pods) and compare it to actual pod usage or node capacity. ([#94866](https://github.com/kubernetes/kubernetes/pull/94866), [@smarterclayton](https://github.com/smarterclayton)) [SIG API Machinery, Instrumentation, Node and Scheduling] -- Add --experimental-logging-sanitization flag enabling runtime protection from leaking sensitive data in logs ([#96370](https://github.com/kubernetes/kubernetes/pull/96370), [@serathius](https://github.com/serathius)) [SIG API Machinery, Cluster Lifecycle and Instrumentation] -- Add a StorageVersionAPI feature gate that makes API server update storageversions before serving certain write requests. - This feature allows the storage migrator to manage storage migration for built-in resources. - Enabling internal.apiserver.k8s.io/v1alpha1 API and APIServerIdentity feature gate are required to use this feature. ([#93873](https://github.com/kubernetes/kubernetes/pull/93873), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery, Auth and Testing] -- Add a metric for time taken to perform recursive permission change ([#95866](https://github.com/kubernetes/kubernetes/pull/95866), [@JornShen](https://github.com/JornShen)) [SIG Instrumentation and Storage] -- Add a new `vSphere` metric: `cloudprovider_vsphere_vcenter_versions`. It's content show `vCenter` hostnames with the associated server version. ([#94526](https://github.com/kubernetes/kubernetes/pull/94526), [@Danil-Grigorev](https://github.com/Danil-Grigorev)) [SIG Cloud Provider and Instrumentation] -- Add a new flag to set priority for the kubelet on Windows nodes so that workloads cannot overwhelm the node there by disrupting kubelet process. ([#96051](https://github.com/kubernetes/kubernetes/pull/96051), [@ravisantoshgudimetla](https://github.com/ravisantoshgudimetla)) [SIG Node and Windows] -- Add feature to size memory backed volumes ([#94444](https://github.com/kubernetes/kubernetes/pull/94444), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG Storage and Testing] -- Add foreground cascading deletion to kubectl with the new `kubectl delete foreground|background|orphan` option. ([#93384](https://github.com/kubernetes/kubernetes/pull/93384), [@zhouya0](https://github.com/zhouya0)) -- Add metrics for azure service operations (route and loadbalancer). ([#94124](https://github.com/kubernetes/kubernetes/pull/94124), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider and Instrumentation] -- Add network rule support in Azure account creation. ([#94239](https://github.com/kubernetes/kubernetes/pull/94239), [@andyzhangx](https://github.com/andyzhangx)) -- Add node_authorizer_actions_duration_seconds metric that can be used to estimate load to node authorizer. ([#92466](https://github.com/kubernetes/kubernetes/pull/92466), [@mborsz](https://github.com/mborsz)) [SIG API Machinery, Auth and Instrumentation] -- Add pod_ based CPU and memory metrics to Kubelet's /metrics/resource endpoint ([#95839](https://github.com/kubernetes/kubernetes/pull/95839), [@egernst](https://github.com/egernst)) [SIG Instrumentation, Node and Testing] -- Added `get-users` and `delete-user` to the `kubectl config` subcommand ([#89840](https://github.com/kubernetes/kubernetes/pull/89840), [@eddiezane](https://github.com/eddiezane)) [SIG CLI] -- Added counter metric "apiserver_request_self" to count API server self-requests with labels for verb, resource, and subresource. ([#94288](https://github.com/kubernetes/kubernetes/pull/94288), [@LogicalShark](https://github.com/LogicalShark)) [SIG API Machinery, Auth, Instrumentation and Scheduling] -- Added new k8s.io/component-helpers repository providing shared helper code for (core) components. ([#92507](https://github.com/kubernetes/kubernetes/pull/92507), [@ingvagabund](https://github.com/ingvagabund)) [SIG Apps, Node, Release and Scheduling] -- Adds `create ingress` command to `kubectl` ([#78153](https://github.com/kubernetes/kubernetes/pull/78153), [@amimof](https://github.com/amimof)) [SIG CLI and Network] -- Adds a headless service on node-local-cache addon. ([#88412](https://github.com/kubernetes/kubernetes/pull/88412), [@stafot](https://github.com/stafot)) [SIG Cloud Provider and Network] -- Allow cross compilation of kubernetes on different platforms. ([#94403](https://github.com/kubernetes/kubernetes/pull/94403), [@bnrjee](https://github.com/bnrjee)) [SIG Release] -- Azure: Support multiple services sharing one IP address ([#94991](https://github.com/kubernetes/kubernetes/pull/94991), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- CRDs: For structural schemas, non-nullable null map fields will now be dropped and defaulted if a default is available. null items in list will continue being preserved, and fail validation if not nullable. ([#95423](https://github.com/kubernetes/kubernetes/pull/95423), [@apelisse](https://github.com/apelisse)) [SIG API Machinery] -- Changed: default "Accept: */*" header added to HTTP probes. See https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#http-probes (https://github.com/kubernetes/website/pull/24756) ([#95641](https://github.com/kubernetes/kubernetes/pull/95641), [@fonsecas72](https://github.com/fonsecas72)) [SIG Network and Node] -- Client-go credential plugins can now be passed in the current cluster information via the KUBERNETES_EXEC_INFO environment variable. ([#95489](https://github.com/kubernetes/kubernetes/pull/95489), [@ankeesler](https://github.com/ankeesler)) [SIG API Machinery and Auth] -- Command to start network proxy changes from 'KUBE_ENABLE_EGRESS_VIA_KONNECTIVITY_SERVICE ./cluster/kube-up.sh' to 'KUBE_ENABLE_KONNECTIVITY_SERVICE=true ./hack/kube-up.sh' ([#92669](https://github.com/kubernetes/kubernetes/pull/92669), [@Jefftree](https://github.com/Jefftree)) [SIG Cloud Provider] -- Configure AWS LoadBalancer health check protocol via service annotations. ([#94546](https://github.com/kubernetes/kubernetes/pull/94546), [@kishorj](https://github.com/kishorj)) -- DefaultPodTopologySpread graduated to Beta. The feature gate is enabled by default. ([#95631](https://github.com/kubernetes/kubernetes/pull/95631), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling and Testing] -- E2e test for PodFsGroupChangePolicy ([#96247](https://github.com/kubernetes/kubernetes/pull/96247), [@saikat-royc](https://github.com/saikat-royc)) [SIG Storage and Testing] -- Ephemeral containers now apply the same API defaults as initContainers and containers ([#94896](https://github.com/kubernetes/kubernetes/pull/94896), [@wawa0210](https://github.com/wawa0210)) [SIG Apps and CLI] -- Gradudate the Pod Resources API to G.A - Introduces the pod_resources_endpoint_requests_total metric which tracks the total number of requests to the pod resources API ([#92165](https://github.com/kubernetes/kubernetes/pull/92165), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Instrumentation, Node and Testing] -- In dual-stack bare-metal clusters, you can now pass dual-stack IPs to `kubelet --node-ip`. - eg: `kubelet --node-ip 10.1.0.5,fd01::0005`. This is not yet supported for non-bare-metal - clusters. - - In dual-stack clusters where nodes have dual-stack addresses, hostNetwork pods - will now get dual-stack PodIPs. ([#95239](https://github.com/kubernetes/kubernetes/pull/95239), [@danwinship](https://github.com/danwinship)) [SIG Network and Node] -- Introduce api-extensions category which will return: mutating admission configs, validating admission configs, CRDs and APIServices when used in kubectl get, for example. ([#95603](https://github.com/kubernetes/kubernetes/pull/95603), [@soltysh](https://github.com/soltysh)) [SIG API Machinery] -- Introduces a new GCE specific cluster creation variable KUBE_PROXY_DISABLE. When set to true, this will skip over the creation of kube-proxy (whether the daemonset or static pod). This can be used to control the lifecycle of kube-proxy separately from the lifecycle of the nodes. ([#91977](https://github.com/kubernetes/kubernetes/pull/91977), [@varunmar](https://github.com/varunmar)) [SIG Cloud Provider] -- Kube-apiserver now maintains a Lease object to identify itself: - - The feature is under feature gate `APIServerIdentity`. - - Two flags are added to kube-apiserver: `identity-lease-duration-seconds`, `identity-lease-renew-interval-seconds` ([#95533](https://github.com/kubernetes/kubernetes/pull/95533), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery] -- Kube-apiserver: The timeout used when making health check calls to etcd can now be configured with `--etcd-healthcheck-timeout`. The default timeout is 2 seconds, matching the previous behavior. ([#93244](https://github.com/kubernetes/kubernetes/pull/93244), [@Sh4d1](https://github.com/Sh4d1)) [SIG API Machinery] -- Kube-apiserver: added support for compressing rotated audit log files with `--audit-log-compress` ([#94066](https://github.com/kubernetes/kubernetes/pull/94066), [@lojies](https://github.com/lojies)) [SIG API Machinery and Auth] -- Kubeadm now prints warnings instead of throwing errors if the current system time is outside of the NotBefore and NotAfter bounds of a loaded certificate. ([#94504](https://github.com/kubernetes/kubernetes/pull/94504), [@neolit123](https://github.com/neolit123)) -- Kubeadm: Add a preflight check that the control-plane node has at least 1700MB of RAM ([#93275](https://github.com/kubernetes/kubernetes/pull/93275), [@xlgao-zju](https://github.com/xlgao-zju)) [SIG Cluster Lifecycle] -- Kubeadm: add the "--cluster-name" flag to the "kubeadm alpha kubeconfig user" to allow configuring the cluster name in the generated kubeconfig file ([#93992](https://github.com/kubernetes/kubernetes/pull/93992), [@prabhu43](https://github.com/prabhu43)) [SIG Cluster Lifecycle] -- Kubeadm: add the "--kubeconfig" flag to the "kubeadm init phase upload-certs" command to allow users to pass a custom location for a kubeconfig file. ([#94765](https://github.com/kubernetes/kubernetes/pull/94765), [@zhanw15](https://github.com/zhanw15)) [SIG Cluster Lifecycle] -- Kubeadm: make etcd pod request 100m CPU, 100Mi memory and 100Mi ephemeral_storage by default ([#94479](https://github.com/kubernetes/kubernetes/pull/94479), [@knight42](https://github.com/knight42)) [SIG Cluster Lifecycle] -- Kubeadm: make the command "kubeadm alpha kubeconfig user" accept a "--config" flag and remove the following flags: - - apiserver-advertise-address / apiserver-bind-port: use either localAPIEndpoint from InitConfiguration or controlPlaneEndpoint from ClusterConfiguration. - - cluster-name: use clusterName from ClusterConfiguration - - cert-dir: use certificatesDir from ClusterConfiguration ([#94879](https://github.com/kubernetes/kubernetes/pull/94879), [@knight42](https://github.com/knight42)) [SIG Cluster Lifecycle] -- Kubectl create now supports creating ingress objects. ([#94327](https://github.com/kubernetes/kubernetes/pull/94327), [@rikatz](https://github.com/rikatz)) [SIG CLI and Network] -- Kubectl rollout history sts/sts-name --revision=some-revision will start showing the detailed view of the sts on that specified revision ([#86506](https://github.com/kubernetes/kubernetes/pull/86506), [@dineshba](https://github.com/dineshba)) [SIG CLI] -- Kubectl: Previously users cannot provide arguments to a external diff tool via KUBECTL_EXTERNAL_DIFF env. This release now allow users to specify args to KUBECTL_EXTERNAL_DIFF env. ([#95292](https://github.com/kubernetes/kubernetes/pull/95292), [@dougsland](https://github.com/dougsland)) [SIG CLI] -- Kubemark now supports both real and hollow nodes in a single cluster. ([#93201](https://github.com/kubernetes/kubernetes/pull/93201), [@ellistarn](https://github.com/ellistarn)) [SIG Scalability] -- Kubernetes E2E test image manifest lists now contain Windows images. ([#77398](https://github.com/kubernetes/kubernetes/pull/77398), [@claudiubelu](https://github.com/claudiubelu)) [SIG Testing and Windows] -- Kubernetes is now built using go1.15.2 - - build: Update to k/repo-infra@v0.1.1 (supports go1.15.2) - - build: Use go-runner:buster-v2.0.1 (built using go1.15.1) - - bazel: Replace --features with Starlark build settings flag - - hack/lib/util.sh: some bash cleanups - - - switched one spot to use kube::logging - - make kube::util::find-binary return an error when it doesn't find - anything so that hack scripts fail fast instead of with '' binary not - found errors. - - this required deleting some genfeddoc stuff. the binary no longer - exists in k/k repo since we removed federation/, and I don't see it - in https://github.com/kubernetes-sigs/kubefed/ either. I'm assuming - that it's gone for good now. - - - bazel: output go_binary rule directly from go_binary_conditional_pure - - From: [@mikedanese](https://github.com/mikedanese): - Instead of aliasing. Aliases are annoying in a number of ways. This is - specifically bugging me now because they make the action graph harder to - analyze programmatically. By using aliases here, we would need to handle - potentially aliased go_binary targets and dereference to the effective - target. - - The comment references an issue with `pure = select(...)` which appears - to be resolved considering this now builds. - - - make kube::util::find-binary not dependent on bazel-out/ structure - - Implement an aspect that outputs go_build_mode metadata for go binaries, - and use that during binary selection. ([#94449](https://github.com/kubernetes/kubernetes/pull/94449), [@justaugustus](https://github.com/justaugustus)) [SIG Architecture, CLI, Cluster Lifecycle, Node, Release and Testing] -- Kubernetes is now built using go1.15.5 - - build: Update to k/repo-infra@v0.1.2 (supports go1.15.5) ([#95776](https://github.com/kubernetes/kubernetes/pull/95776), [@justaugustus](https://github.com/justaugustus)) [SIG Cloud Provider, Instrumentation, Release and Testing] -- New default scheduling plugins order reduces scheduling and preemption latency when taints and node affinity are used ([#95539](https://github.com/kubernetes/kubernetes/pull/95539), [@soulxu](https://github.com/soulxu)) [SIG Scheduling] -- Only update Azure data disks when attach/detach ([#94265](https://github.com/kubernetes/kubernetes/pull/94265), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Promote SupportNodePidsLimit to GA to provide node-to-pod PID isolation. - Promote SupportPodPidsLimit to GA to provide ability to limit PIDs per pod. ([#94140](https://github.com/kubernetes/kubernetes/pull/94140), [@derekwaynecarr](https://github.com/derekwaynecarr)) -- SCTP support in API objects (Pod, Service, NetworkPolicy) is now GA. - Note that this has no effect on whether SCTP is enabled on nodes at the kernel level, - and note that some cloud platforms and network plugins do not support SCTP traffic. ([#95566](https://github.com/kubernetes/kubernetes/pull/95566), [@danwinship](https://github.com/danwinship)) [SIG Apps and Network] -- Scheduler now ignores Pod update events if the resourceVersion of old and new Pods are identical. ([#96071](https://github.com/kubernetes/kubernetes/pull/96071), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling] -- Scheduling Framework: expose Run[Pre]ScorePlugins functions to PreemptionHandle which can be used in PostFilter extention point. ([#93534](https://github.com/kubernetes/kubernetes/pull/93534), [@everpeace](https://github.com/everpeace)) [SIG Scheduling and Testing] -- SelectorSpreadPriority maps to PodTopologySpread plugin when DefaultPodTopologySpread feature is enabled ([#95448](https://github.com/kubernetes/kubernetes/pull/95448), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- Send GCE node startup scripts logs to console and journal. ([#95311](https://github.com/kubernetes/kubernetes/pull/95311), [@karan](https://github.com/karan)) -- SetHostnameAsFQDN has been graduated to Beta and therefore it is enabled by default. ([#95267](https://github.com/kubernetes/kubernetes/pull/95267), [@javidiaz](https://github.com/javidiaz)) [SIG Node] -- Support [service.beta.kubernetes.io/azure-pip-ip-tags] annotations to allow customers to specify ip-tags to influence public-ip creation in Azure [Tag1=Value1, Tag2=Value2, etc.] ([#94114](https://github.com/kubernetes/kubernetes/pull/94114), [@MarcPow](https://github.com/MarcPow)) [SIG Cloud Provider] -- Support custom tags for cloud provider managed resources ([#96450](https://github.com/kubernetes/kubernetes/pull/96450), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Support customize load balancer health probe protocol and request path ([#96338](https://github.com/kubernetes/kubernetes/pull/96338), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Support for Windows container images (OS Versions: 1809, 1903, 1909, 2004) was added the pause:3.4 image. ([#91452](https://github.com/kubernetes/kubernetes/pull/91452), [@claudiubelu](https://github.com/claudiubelu)) [SIG Node, Release and Windows] -- Support multiple standard load balancers in one cluster ([#96111](https://github.com/kubernetes/kubernetes/pull/96111), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- The beta `RootCAConfigMap` feature gate is enabled by default and causes kube-controller-manager to publish a "kube-root-ca.crt" ConfigMap to every namespace. This ConfigMap contains a CA bundle used for verifying connections to the kube-apiserver. ([#96197](https://github.com/kubernetes/kubernetes/pull/96197), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Apps, Auth and Testing] -- The kubelet_runtime_operations_duration_seconds metric buckets were set to 0.005 0.0125 0.03125 0.078125 0.1953125 0.48828125 1.220703125 3.0517578125 7.62939453125 19.073486328125 47.6837158203125 119.20928955078125 298.0232238769531 and 745.0580596923828 seconds ([#96054](https://github.com/kubernetes/kubernetes/pull/96054), [@alvaroaleman](https://github.com/alvaroaleman)) [SIG Instrumentation and Node] -- There is a new pv_collector_total_pv_count metric that counts persistent volumes by the volume plugin name and volume mode. ([#95719](https://github.com/kubernetes/kubernetes/pull/95719), [@tsmetana](https://github.com/tsmetana)) [SIG Apps, Instrumentation, Storage and Testing] -- Volume snapshot e2e test to validate PVC and VolumeSnapshotContent finalizer ([#95863](https://github.com/kubernetes/kubernetes/pull/95863), [@RaunakShah](https://github.com/RaunakShah)) [SIG Cloud Provider, Storage and Testing] -- Warns user when executing kubectl apply/diff to resource currently being deleted. ([#95544](https://github.com/kubernetes/kubernetes/pull/95544), [@SaiHarshaK](https://github.com/SaiHarshaK)) [SIG CLI] -- `kubectl alpha debug` has graduated to beta and is now `kubectl debug`. ([#96138](https://github.com/kubernetes/kubernetes/pull/96138), [@verb](https://github.com/verb)) [SIG CLI and Testing] -- `kubectl debug` gains support for changing container images when copying a pod for debugging, similar to how `kubectl set image` works. See `kubectl help debug` for more information. ([#96058](https://github.com/kubernetes/kubernetes/pull/96058), [@verb](https://github.com/verb)) [SIG CLI] - -### Documentation - -- Fake dynamic client: document that List does not preserve TypeMeta in UnstructuredList ([#95117](https://github.com/kubernetes/kubernetes/pull/95117), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery] -- Kubelet: remove alpha warnings for CNI flags. ([#94508](https://github.com/kubernetes/kubernetes/pull/94508), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network and Node] -- Updates docs and guidance on cloud provider InstancesV2 and Zones interface for external cloud providers: - - removes experimental warning for InstancesV2 - - document that implementation of InstancesV2 will disable calls to Zones - - deprecate Zones in favor of InstancesV2 ([#96397](https://github.com/kubernetes/kubernetes/pull/96397), [@andrewsykim](https://github.com/andrewsykim)) [SIG Cloud Provider] - -### Failing Test - -- Resolves an issue running Ingress conformance tests on clusters which use finalizers on Ingress objects to manage releasing load balancer resources ([#96742](https://github.com/kubernetes/kubernetes/pull/96742), [@spencerhance](https://github.com/spencerhance)) [SIG Network and Testing] -- The Conformance test "validates that there is no conflict between pods with same hostPort but different hostIP and protocol" now validates the connectivity to each hostPort, in addition to the functionality. ([#96627](https://github.com/kubernetes/kubernetes/pull/96627), [@aojea](https://github.com/aojea)) [SIG Scheduling and Testing] - -### Bug or Regression - -- Add kubectl wait --ignore-not-found flag ([#90969](https://github.com/kubernetes/kubernetes/pull/90969), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] -- Added support to kube-proxy for externalTrafficPolicy=Local setting via Direct Server Return (DSR) load balancers on Windows. ([#93166](https://github.com/kubernetes/kubernetes/pull/93166), [@elweb9858](https://github.com/elweb9858)) [SIG Network] -- Alter wording to describe pods using a pvc ([#95635](https://github.com/kubernetes/kubernetes/pull/95635), [@RaunakShah](https://github.com/RaunakShah)) [SIG CLI] -- An issues preventing volume expand controller to annotate the PVC with `volume.kubernetes.io/storage-resizer` when the PVC StorageClass is already updated to the out-of-tree provisioner is now fixed. ([#94489](https://github.com/kubernetes/kubernetes/pull/94489), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG API Machinery, Apps and Storage] -- Azure ARM client: don't segfault on empty response and http error ([#94078](https://github.com/kubernetes/kubernetes/pull/94078), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider] -- Azure armclient backoff step defaults to 1 (no retry). ([#94180](https://github.com/kubernetes/kubernetes/pull/94180), [@feiskyer](https://github.com/feiskyer)) -- Azure: fix a bug that kube-controller-manager would panic if wrong Azure VMSS name is configured ([#94306](https://github.com/kubernetes/kubernetes/pull/94306), [@knight42](https://github.com/knight42)) [SIG Cloud Provider] -- Both apiserver_request_duration_seconds metrics and RequestReceivedTimestamp fields of an audit event now take into account the time a request spends in the apiserver request filters. ([#94903](https://github.com/kubernetes/kubernetes/pull/94903), [@tkashem](https://github.com/tkashem)) -- Build/lib/release: Explicitly use '--platform' in building server images - - When we switched to go-runner for building the apiserver, - controller-manager, and scheduler server components, we no longer - reference the individual architectures in the image names, specifically - in the 'FROM' directive of the server image Dockerfiles. - - As a result, server images for non-amd64 images copy in the go-runner - amd64 binary instead of the go-runner that matches that architecture. - - This commit explicitly sets the '--platform=linux/${arch}' to ensure - we're pulling the correct go-runner arch from the manifest list. - - Before: - `FROM ${base_image}` - - After: - `FROM --platform=linux/${arch} ${base_image}` ([#94552](https://github.com/kubernetes/kubernetes/pull/94552), [@justaugustus](https://github.com/justaugustus)) [SIG Release] -- Bump node-problem-detector version to v0.8.5 to fix OOM detection in with Linux kernels 5.1+ ([#96716](https://github.com/kubernetes/kubernetes/pull/96716), [@tosi3k](https://github.com/tosi3k)) [SIG Cloud Provider, Scalability and Testing] -- CSIDriver object can be deployed during volume attachment. ([#93710](https://github.com/kubernetes/kubernetes/pull/93710), [@Jiawei0227](https://github.com/Jiawei0227)) [SIG Apps, Node, Storage and Testing] -- Ceph RBD volume expansion now works even when ceph.conf was not provided. ([#92027](https://github.com/kubernetes/kubernetes/pull/92027), [@juliantaylor](https://github.com/juliantaylor)) -- Change plugin name in fsgroupapplymetrics of csi and flexvolume to distinguish different driver ([#95892](https://github.com/kubernetes/kubernetes/pull/95892), [@JornShen](https://github.com/JornShen)) [SIG Instrumentation, Storage and Testing] -- Change the calculation of pod UIDs so that static pods get a unique value - will cause all containers to be killed and recreated after in-place upgrade. ([#87461](https://github.com/kubernetes/kubernetes/pull/87461), [@bboreham](https://github.com/bboreham)) [SIG Node] -- Change the mount way from systemd to normal mount except ceph and glusterfs intree-volume. ([#94916](https://github.com/kubernetes/kubernetes/pull/94916), [@smileusd](https://github.com/smileusd)) [SIG Apps, Cloud Provider, Network, Node, Storage and Testing] -- Changes to timeout parameter handling in 1.20.0-beta.2 have been reverted to avoid breaking backwards compatibility with existing clients. ([#96727](https://github.com/kubernetes/kubernetes/pull/96727), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Testing] -- Clear UDP conntrack entry on endpoint changes when using nodeport ([#71573](https://github.com/kubernetes/kubernetes/pull/71573), [@JacobTanenbaum](https://github.com/JacobTanenbaum)) [SIG Network] -- Cloud node controller: handle empty providerID from getProviderID ([#95342](https://github.com/kubernetes/kubernetes/pull/95342), [@nicolehanjing](https://github.com/nicolehanjing)) [SIG Cloud Provider] -- Disable watchcache for events ([#96052](https://github.com/kubernetes/kubernetes/pull/96052), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery] -- Disabled `LocalStorageCapacityIsolation` feature gate is honored during scheduling. ([#96092](https://github.com/kubernetes/kubernetes/pull/96092), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling] -- Do not fail sorting empty elements. ([#94666](https://github.com/kubernetes/kubernetes/pull/94666), [@soltysh](https://github.com/soltysh)) [SIG CLI] -- Dual-stack: make nodeipam compatible with existing single-stack clusters when dual-stack feature gate become enabled by default ([#90439](https://github.com/kubernetes/kubernetes/pull/90439), [@SataQiu](https://github.com/SataQiu)) [SIG API Machinery] -- Duplicate owner reference entries in create/update/patch requests now get deduplicated by the API server. The client sending the request now receives a warning header in the API response. Clients should stop sending requests with duplicate owner references. The API server may reject such requests as early as 1.24. ([#96185](https://github.com/kubernetes/kubernetes/pull/96185), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery and Testing] -- Endpoint slice controller now mirrors parent's service label to its corresponding endpoint slices. ([#94443](https://github.com/kubernetes/kubernetes/pull/94443), [@aojea](https://github.com/aojea)) -- Ensure getPrimaryInterfaceID not panic when network interfaces for Azure VMSS are null ([#94355](https://github.com/kubernetes/kubernetes/pull/94355), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Exposes and sets a default timeout for the SubjectAccessReview client for DelegatingAuthorizationOptions ([#95725](https://github.com/kubernetes/kubernetes/pull/95725), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery and Cloud Provider] -- Exposes and sets a default timeout for the TokenReview client for DelegatingAuthenticationOptions ([#96217](https://github.com/kubernetes/kubernetes/pull/96217), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery and Cloud Provider] -- Fix CVE-2020-8555 for Quobyte client connections. ([#95206](https://github.com/kubernetes/kubernetes/pull/95206), [@misterikkit](https://github.com/misterikkit)) [SIG Storage] -- Fix IP fragmentation of UDP and TCP packets not supported issues on LoadBalancer rules ([#96464](https://github.com/kubernetes/kubernetes/pull/96464), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Fix a bug that DefaultPreemption plugin is disabled when using (legacy) scheduler policy. ([#96439](https://github.com/kubernetes/kubernetes/pull/96439), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing] -- Fix a bug where loadbalancer deletion gets stuck because of missing resource group. ([#93962](https://github.com/kubernetes/kubernetes/pull/93962), [@phiphi282](https://github.com/phiphi282)) -- Fix a concurrent map writes error in kubelet ([#93773](https://github.com/kubernetes/kubernetes/pull/93773), [@knight42](https://github.com/knight42)) [SIG Node] -- Fix a panic in `kubectl debug` when a pod has multiple init or ephemeral containers. ([#94580](https://github.com/kubernetes/kubernetes/pull/94580), [@kiyoshim55](https://github.com/kiyoshim55)) -- Fix a regression where kubeadm bails out with a fatal error when an optional version command line argument is supplied to the "kubeadm upgrade plan" command ([#94421](https://github.com/kubernetes/kubernetes/pull/94421), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle] -- Fix azure disk attach failure for disk size bigger than 4TB ([#95463](https://github.com/kubernetes/kubernetes/pull/95463), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix azure disk data loss issue on Windows when unmount disk ([#95456](https://github.com/kubernetes/kubernetes/pull/95456), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fix azure file migration panic ([#94853](https://github.com/kubernetes/kubernetes/pull/94853), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix bug in JSON path parser where an error occurs when a range is empty ([#95933](https://github.com/kubernetes/kubernetes/pull/95933), [@brianpursley](https://github.com/brianpursley)) [SIG API Machinery] -- Fix client-go prometheus metrics to correctly present the API path accessed in some environments. ([#74363](https://github.com/kubernetes/kubernetes/pull/74363), [@aanm](https://github.com/aanm)) [SIG API Machinery] -- Fix detach azure disk issue when vm not exist ([#95177](https://github.com/kubernetes/kubernetes/pull/95177), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix etcd_object_counts metric reported by kube-apiserver ([#94773](https://github.com/kubernetes/kubernetes/pull/94773), [@tkashem](https://github.com/tkashem)) [SIG API Machinery] -- Fix incorrectly reported verbs for kube-apiserver metrics for CRD objects ([#93523](https://github.com/kubernetes/kubernetes/pull/93523), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Instrumentation] -- Fix k8s.io/apimachinery/pkg/api/meta.SetStatusCondition to update ObservedGeneration ([#95961](https://github.com/kubernetes/kubernetes/pull/95961), [@KnicKnic](https://github.com/KnicKnic)) [SIG API Machinery] -- Fix kubectl SchemaError on CRDs with schema using x-kubernetes-preserve-unknown-fields on array types. ([#94888](https://github.com/kubernetes/kubernetes/pull/94888), [@sttts](https://github.com/sttts)) [SIG API Machinery] -- Fix memory leak in kube-apiserver when underlying time goes forth and back. ([#96266](https://github.com/kubernetes/kubernetes/pull/96266), [@chenyw1990](https://github.com/chenyw1990)) [SIG API Machinery] -- Fix missing csi annotations on node during parallel csinode update. ([#94389](https://github.com/kubernetes/kubernetes/pull/94389), [@pacoxu](https://github.com/pacoxu)) [SIG Storage] -- Fix network_programming_latency metric reporting for Endpoints/EndpointSlice deletions, where we don't have correct timestamp ([#95363](https://github.com/kubernetes/kubernetes/pull/95363), [@wojtek-t](https://github.com/wojtek-t)) [SIG Network and Scalability] -- Fix paging issues when Azure API returns empty values with non-empty nextLink ([#96211](https://github.com/kubernetes/kubernetes/pull/96211), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Fix pull image error from multiple ACRs using azure managed identity ([#96355](https://github.com/kubernetes/kubernetes/pull/96355), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix race condition on timeCache locks. ([#94751](https://github.com/kubernetes/kubernetes/pull/94751), [@auxten](https://github.com/auxten)) -- Fix regression on `kubectl portforward` when TCP and UCP services were configured on the same port. ([#94728](https://github.com/kubernetes/kubernetes/pull/94728), [@amorenoz](https://github.com/amorenoz)) -- Fix scheduler cache snapshot when a Node is deleted before its Pods ([#95130](https://github.com/kubernetes/kubernetes/pull/95130), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- Fix the `cloudprovider_azure_api_request_duration_seconds` metric buckets to correctly capture the latency metrics. Previously, the majority of the calls would fall in the "+Inf" bucket. ([#94873](https://github.com/kubernetes/kubernetes/pull/94873), [@marwanad](https://github.com/marwanad)) [SIG Cloud Provider and Instrumentation] -- Fix vSphere volumes that could be erroneously attached to wrong node ([#96224](https://github.com/kubernetes/kubernetes/pull/96224), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage] -- Fix verb & scope reporting for kube-apiserver metrics (LIST reported instead of GET) ([#95562](https://github.com/kubernetes/kubernetes/pull/95562), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Testing] -- Fix vsphere detach failure for static PVs ([#95447](https://github.com/kubernetes/kubernetes/pull/95447), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage] -- Fix: azure disk resize error if source does not exist ([#93011](https://github.com/kubernetes/kubernetes/pull/93011), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix: detach azure disk broken on Azure Stack ([#94885](https://github.com/kubernetes/kubernetes/pull/94885), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix: resize Azure disk issue when it's in attached state ([#96705](https://github.com/kubernetes/kubernetes/pull/96705), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix: smb valid path error ([#95583](https://github.com/kubernetes/kubernetes/pull/95583), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage] -- Fix: use sensitiveOptions on Windows mount ([#94126](https://github.com/kubernetes/kubernetes/pull/94126), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fixed a bug causing incorrect formatting of `kubectl describe ingress`. ([#94985](https://github.com/kubernetes/kubernetes/pull/94985), [@howardjohn](https://github.com/howardjohn)) [SIG CLI and Network] -- Fixed a bug in client-go where new clients with customized `Dial`, `Proxy`, `GetCert` config may get stale HTTP transports. ([#95427](https://github.com/kubernetes/kubernetes/pull/95427), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery] -- Fixed a bug that prevents kubectl to validate CRDs with schema using x-kubernetes-preserve-unknown-fields on object fields. ([#96369](https://github.com/kubernetes/kubernetes/pull/96369), [@gautierdelorme](https://github.com/gautierdelorme)) [SIG API Machinery and Testing] -- Fixed a bug that prevents the use of ephemeral containers in the presence of a validating admission webhook. ([#94685](https://github.com/kubernetes/kubernetes/pull/94685), [@verb](https://github.com/verb)) [SIG Node and Testing] -- Fixed a bug where aggregator_unavailable_apiservice metrics were reported for deleted apiservices. ([#96421](https://github.com/kubernetes/kubernetes/pull/96421), [@dgrisonnet](https://github.com/dgrisonnet)) [SIG API Machinery and Instrumentation] -- Fixed a bug where improper storage and comparison of endpoints led to excessive API traffic from the endpoints controller ([#94112](https://github.com/kubernetes/kubernetes/pull/94112), [@damemi](https://github.com/damemi)) [SIG Apps, Network and Testing] -- Fixed a regression which prevented pods with `docker/default` seccomp annotations from being created in 1.19 if a PodSecurityPolicy was in place which did not allow `runtime/default` seccomp profiles. ([#95985](https://github.com/kubernetes/kubernetes/pull/95985), [@saschagrunert](https://github.com/saschagrunert)) [SIG Auth] -- Fixed bug in reflector that couldn't recover from "Too large resource version" errors with API servers 1.17.0-1.18.5 ([#94316](https://github.com/kubernetes/kubernetes/pull/94316), [@janeczku](https://github.com/janeczku)) [SIG API Machinery] -- Fixed bug where kubectl top pod output is not sorted when --sort-by and --containers flags are used together ([#93692](https://github.com/kubernetes/kubernetes/pull/93692), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] -- Fixed kubelet creating extra sandbox for pods with RestartPolicyOnFailure after all containers succeeded ([#92614](https://github.com/kubernetes/kubernetes/pull/92614), [@tnqn](https://github.com/tnqn)) [SIG Node and Testing] -- Fixes an issue proxying to ipv6 pods without specifying a port ([#94834](https://github.com/kubernetes/kubernetes/pull/94834), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Network] -- Fixes code generation for non-namespaced create subresources fake client test. ([#96586](https://github.com/kubernetes/kubernetes/pull/96586), [@Doude](https://github.com/Doude)) [SIG API Machinery] -- Fixes high CPU usage in kubectl drain ([#95260](https://github.com/kubernetes/kubernetes/pull/95260), [@amandahla](https://github.com/amandahla)) [SIG CLI] -- For vSphere Cloud Provider, If VM of worker node is deleted, the node will also be deleted by node controller ([#92608](https://github.com/kubernetes/kubernetes/pull/92608), [@lubronzhan](https://github.com/lubronzhan)) [SIG Cloud Provider] -- Gracefully delete nodes when their parent scale set went missing ([#95289](https://github.com/kubernetes/kubernetes/pull/95289), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider] -- HTTP/2 connection health check is enabled by default in all Kubernetes clients. The feature should work out-of-the-box. If needed, users can tune the feature via the HTTP2_READ_IDLE_TIMEOUT_SECONDS and HTTP2_PING_TIMEOUT_SECONDS environment variables. The feature is disabled if HTTP2_READ_IDLE_TIMEOUT_SECONDS is set to 0. ([#95981](https://github.com/kubernetes/kubernetes/pull/95981), [@caesarxuchao](https://github.com/caesarxuchao)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node] -- If the user specifies an invalid timeout in the request URL, the request will be aborted with an HTTP 400. - - If the user specifies a timeout in the request URL that exceeds the maximum request deadline allowed by the apiserver, the request will be aborted with an HTTP 400. ([#96061](https://github.com/kubernetes/kubernetes/pull/96061), [@tkashem](https://github.com/tkashem)) [SIG API Machinery, Network and Testing] -- If we set SelectPolicy MinPolicySelect on scaleUp behavior or scaleDown behavior,Horizontal Pod Autoscaler doesn`t automatically scale the number of pods correctly ([#95647](https://github.com/kubernetes/kubernetes/pull/95647), [@JoshuaAndrew](https://github.com/JoshuaAndrew)) [SIG Apps and Autoscaling] -- Ignore apparmor for non-linux operating systems ([#93220](https://github.com/kubernetes/kubernetes/pull/93220), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] -- Ignore root user check when windows pod starts ([#92355](https://github.com/kubernetes/kubernetes/pull/92355), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] -- Improve error messages related to nodePort endpoint changes conntrack entries cleanup. ([#96251](https://github.com/kubernetes/kubernetes/pull/96251), [@ravens](https://github.com/ravens)) [SIG Network] -- In dual-stack clusters, kubelet will now set up both IPv4 and IPv6 iptables rules, which may - fix some problems, eg with HostPorts. ([#94474](https://github.com/kubernetes/kubernetes/pull/94474), [@danwinship](https://github.com/danwinship)) [SIG Network and Node] -- Increase maximum IOPS of AWS EBS io1 volume to current maximum (64,000). ([#90014](https://github.com/kubernetes/kubernetes/pull/90014), [@jacobmarble](https://github.com/jacobmarble)) -- Ipvs: ensure selected scheduler kernel modules are loaded ([#93040](https://github.com/kubernetes/kubernetes/pull/93040), [@cmluciano](https://github.com/cmluciano)) [SIG Network] -- K8s.io/apimachinery: runtime.DefaultUnstructuredConverter.FromUnstructured now handles converting integer fields to typed float values ([#93250](https://github.com/kubernetes/kubernetes/pull/93250), [@liggitt](https://github.com/liggitt)) [SIG API Machinery] -- Kube-proxy now trims extra spaces found in loadBalancerSourceRanges to match Service validation. ([#94107](https://github.com/kubernetes/kubernetes/pull/94107), [@robscott](https://github.com/robscott)) [SIG Network] -- Kubeadm ensures "kubeadm reset" does not unmount the root "/var/lib/kubelet" directory if it is mounted by the user. ([#93702](https://github.com/kubernetes/kubernetes/pull/93702), [@thtanaka](https://github.com/thtanaka)) -- Kubeadm now makes sure the etcd manifest is regenerated upon upgrade even when no etcd version change takes place ([#94395](https://github.com/kubernetes/kubernetes/pull/94395), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle] -- Kubeadm now warns (instead of error out) on missing "ca.key" files for root CA, front-proxy CA and etcd CA, during "kubeadm join --control-plane" if the user has provided all certificates, keys and kubeconfig files which require signing with the given CA keys. ([#94988](https://github.com/kubernetes/kubernetes/pull/94988), [@neolit123](https://github.com/neolit123)) -- Kubeadm: add missing "--experimental-patches" flag to "kubeadm init phase control-plane" ([#95786](https://github.com/kubernetes/kubernetes/pull/95786), [@Sh4d1](https://github.com/Sh4d1)) [SIG Cluster Lifecycle] -- Kubeadm: avoid a panic when determining if the running version of CoreDNS is supported during upgrades ([#94299](https://github.com/kubernetes/kubernetes/pull/94299), [@zouyee](https://github.com/zouyee)) [SIG Cluster Lifecycle] -- Kubeadm: ensure the etcd data directory is created with 0700 permissions during control-plane init and join ([#94102](https://github.com/kubernetes/kubernetes/pull/94102), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: fix coredns migration should be triggered when there are newdefault configs during kubeadm upgrade ([#96907](https://github.com/kubernetes/kubernetes/pull/96907), [@pacoxu](https://github.com/pacoxu)) [SIG Cluster Lifecycle] -- Kubeadm: fix the bug that kubeadm tries to call 'docker info' even if the CRI socket was for another CR ([#94555](https://github.com/kubernetes/kubernetes/pull/94555), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] -- Kubeadm: for Docker as the container runtime, make the "kubeadm reset" command stop containers before removing them ([#94586](https://github.com/kubernetes/kubernetes/pull/94586), [@BedivereZero](https://github.com/BedivereZero)) [SIG Cluster Lifecycle] -- Kubeadm: make the kubeconfig files for the kube-controller-manager and kube-scheduler use the LocalAPIEndpoint instead of the ControlPlaneEndpoint. This makes kubeadm clusters more reseliant to version skew problems during immutable upgrades: https://kubernetes.io/docs/setup/release/version-skew-policy/#kube-controller-manager-kube-scheduler-and-cloud-controller-manager ([#94398](https://github.com/kubernetes/kubernetes/pull/94398), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: relax the validation of kubeconfig server URLs. Allow the user to define custom kubeconfig server URLs without erroring out during validation of existing kubeconfig files (e.g. when using external CA mode). ([#94816](https://github.com/kubernetes/kubernetes/pull/94816), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubectl: print error if users place flags before plugin name ([#92343](https://github.com/kubernetes/kubernetes/pull/92343), [@knight42](https://github.com/knight42)) [SIG CLI] -- Kubelet: assume that swap is disabled when `/proc/swaps` does not exist ([#93931](https://github.com/kubernetes/kubernetes/pull/93931), [@SataQiu](https://github.com/SataQiu)) [SIG Node] -- New Azure instance types do now have correct max data disk count information. ([#94340](https://github.com/kubernetes/kubernetes/pull/94340), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Cloud Provider and Storage] -- Port mapping now allows the same `containerPort` of different containers to different `hostPort` without naming the mapping explicitly. ([#94494](https://github.com/kubernetes/kubernetes/pull/94494), [@SergeyKanzhelev](https://github.com/SergeyKanzhelev)) -- Print go stack traces at -v=4 and not -v=2 ([#94663](https://github.com/kubernetes/kubernetes/pull/94663), [@soltysh](https://github.com/soltysh)) [SIG CLI] -- Recreate EndpointSlices on rapid Service creation. ([#94730](https://github.com/kubernetes/kubernetes/pull/94730), [@robscott](https://github.com/robscott)) -- Reduce volume name length for vsphere volumes ([#96533](https://github.com/kubernetes/kubernetes/pull/96533), [@gnufied](https://github.com/gnufied)) [SIG Storage] -- Remove ready file and its directory (which is created during volume SetUp) during emptyDir volume TearDown. ([#95770](https://github.com/kubernetes/kubernetes/pull/95770), [@jingxu97](https://github.com/jingxu97)) [SIG Storage] -- Reorganized iptables rules to fix a performance issue ([#95252](https://github.com/kubernetes/kubernetes/pull/95252), [@tssurya](https://github.com/tssurya)) [SIG Network] -- Require feature flag CustomCPUCFSQuotaPeriod if setting a non-default cpuCFSQuotaPeriod in kubelet config. ([#94687](https://github.com/kubernetes/kubernetes/pull/94687), [@karan](https://github.com/karan)) [SIG Node] -- Resolves a regression in 1.19+ with workloads targeting deprecated beta os/arch labels getting stuck in NodeAffinity status on node startup. ([#96810](https://github.com/kubernetes/kubernetes/pull/96810), [@liggitt](https://github.com/liggitt)) [SIG Node] -- Resolves non-deterministic behavior of the garbage collection controller when ownerReferences with incorrect data are encountered. Events with a reason of `OwnerRefInvalidNamespace` are recorded when namespace mismatches between child and owner objects are detected. The [kubectl-check-ownerreferences](https://github.com/kubernetes-sigs/kubectl-check-ownerreferences) tool can be run prior to upgrading to locate existing objects with invalid ownerReferences. - - A namespaced object with an ownerReference referencing a uid of a namespaced kind which does not exist in the same namespace is now consistently treated as though that owner does not exist, and the child object is deleted. - - A cluster-scoped object with an ownerReference referencing a uid of a namespaced kind is now consistently treated as though that owner is not resolvable, and the child object is ignored by the garbage collector. ([#92743](https://github.com/kubernetes/kubernetes/pull/92743), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Testing] -- Skip [k8s.io/kubernetes@v1.19.0/test/e2e/storage/testsuites/base.go:162]: Driver azure-disk doesn't support snapshot type DynamicSnapshot -- skipping - skip [k8s.io/kubernetes@v1.19.0/test/e2e/storage/testsuites/base.go:185]: Driver azure-disk doesn't support ntfs -- skipping ([#96144](https://github.com/kubernetes/kubernetes/pull/96144), [@qinpingli](https://github.com/qinpingli)) [SIG Storage and Testing] -- StatefulSet Controller now waits for PersistentVolumeClaim deletion before creating pods. ([#93457](https://github.com/kubernetes/kubernetes/pull/93457), [@ymmt2005](https://github.com/ymmt2005)) -- StreamWatcher now calls HandleCrash at appropriate sequence. ([#93108](https://github.com/kubernetes/kubernetes/pull/93108), [@lixiaobing1](https://github.com/lixiaobing1)) -- Support the node label `node.kubernetes.io/exclude-from-external-load-balancers` ([#95542](https://github.com/kubernetes/kubernetes/pull/95542), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- The AWS network load balancer attributes can now be specified during service creation ([#95247](https://github.com/kubernetes/kubernetes/pull/95247), [@kishorj](https://github.com/kishorj)) [SIG Cloud Provider] -- The `/debug/api_priority_and_fairness/dump_requests` path at an apiserver will no longer return a phantom line for each exempt priority level. ([#93406](https://github.com/kubernetes/kubernetes/pull/93406), [@MikeSpreitzer](https://github.com/MikeSpreitzer)) [SIG API Machinery] -- The kube-apiserver will no longer serve APIs that should have been deleted in GA non-alpha levels. Alpha levels will continue to serve the removed APIs so that CI doesn't immediately break. ([#96525](https://github.com/kubernetes/kubernetes/pull/96525), [@deads2k](https://github.com/deads2k)) [SIG API Machinery] -- The kubelet recognizes the --containerd-namespace flag to configure the namespace used by cadvisor. ([#87054](https://github.com/kubernetes/kubernetes/pull/87054), [@changyaowei](https://github.com/changyaowei)) [SIG Node] -- Unhealthy pods covered by PDBs can be successfully evicted if enough healthy pods are available. ([#94381](https://github.com/kubernetes/kubernetes/pull/94381), [@michaelgugino](https://github.com/michaelgugino)) [SIG Apps] -- Update Calico to v3.15.2 ([#94241](https://github.com/kubernetes/kubernetes/pull/94241), [@lmm](https://github.com/lmm)) [SIG Cloud Provider] -- Update default etcd server version to 3.4.13 ([#94287](https://github.com/kubernetes/kubernetes/pull/94287), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cloud Provider, Cluster Lifecycle and Testing] -- Update max azure data disk count map ([#96308](https://github.com/kubernetes/kubernetes/pull/96308), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Update the PIP when it is not in the Succeeded provisioning state during the LB update. ([#95748](https://github.com/kubernetes/kubernetes/pull/95748), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Update the frontend IP config when the service's `pipName` annotation is changed ([#95813](https://github.com/kubernetes/kubernetes/pull/95813), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Update the route table tag in the route reconcile loop ([#96545](https://github.com/kubernetes/kubernetes/pull/96545), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Use NLB Subnet CIDRs instead of VPC CIDRs in Health Check SG Rules ([#93515](https://github.com/kubernetes/kubernetes/pull/93515), [@t0rr3sp3dr0](https://github.com/t0rr3sp3dr0)) [SIG Cloud Provider] -- Users will see increase in time for deletion of pods and also guarantee that removal of pod from api server would mean deletion of all the resources from container runtime. ([#92817](https://github.com/kubernetes/kubernetes/pull/92817), [@kmala](https://github.com/kmala)) [SIG Node] -- Very large patches may now be specified to `kubectl patch` with the `--patch-file` flag instead of including them directly on the command line. The `--patch` and `--patch-file` flags are mutually exclusive. ([#93548](https://github.com/kubernetes/kubernetes/pull/93548), [@smarterclayton](https://github.com/smarterclayton)) [SIG CLI] -- Volume binding: report UnschedulableAndUnresolvable status instead of an error when bound PVs not found ([#95541](https://github.com/kubernetes/kubernetes/pull/95541), [@cofyc](https://github.com/cofyc)) [SIG Apps, Scheduling and Storage] -- Warn instead of fail when creating Roles and ClusterRoles with custom verbs via kubectl ([#92492](https://github.com/kubernetes/kubernetes/pull/92492), [@eddiezane](https://github.com/eddiezane)) [SIG CLI] -- When creating a PVC with the volume.beta.kubernetes.io/storage-provisioner annotation already set, the PV controller might have incorrectly deleted the newly provisioned PV instead of binding it to the PVC, depending on timing and system load. ([#95909](https://github.com/kubernetes/kubernetes/pull/95909), [@pohly](https://github.com/pohly)) [SIG Apps and Storage] -- [kubectl] Fail when local source file doesn't exist ([#90333](https://github.com/kubernetes/kubernetes/pull/90333), [@bamarni](https://github.com/bamarni)) [SIG CLI] - -### Other (Cleanup or Flake) - -- **Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.**: - - ([#96443](https://github.com/kubernetes/kubernetes/pull/96443), [@alaypatel07](https://github.com/alaypatel07)) [SIG Apps] -- --redirect-container-streaming is no longer functional. The flag will be removed in v1.22 ([#95935](https://github.com/kubernetes/kubernetes/pull/95935), [@tallclair](https://github.com/tallclair)) [SIG Node] -- A new metric `requestAbortsTotal` has been introduced that counts aborted requests for each `group`, `version`, `verb`, `resource`, `subresource` and `scope`. ([#95002](https://github.com/kubernetes/kubernetes/pull/95002), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery, Cloud Provider, Instrumentation and Scheduling] -- API priority and fairness metrics use snake_case in label names ([#96236](https://github.com/kubernetes/kubernetes/pull/96236), [@adtac](https://github.com/adtac)) [SIG API Machinery, Cluster Lifecycle, Instrumentation and Testing] -- Add fine grained debugging to intra-pod conformance test to troubleshoot networking issues for potentially unhealthy nodes when running conformance or sonobuoy tests. ([#93837](https://github.com/kubernetes/kubernetes/pull/93837), [@jayunit100](https://github.com/jayunit100)) -- Add the following metrics: - - network_plugin_operations_total - - network_plugin_operations_errors_total ([#93066](https://github.com/kubernetes/kubernetes/pull/93066), [@AnishShah](https://github.com/AnishShah)) -- Adds a bootstrapping ClusterRole, ClusterRoleBinding and group for /metrics, /livez/*, /readyz/*, & /healthz/- endpoints. ([#93311](https://github.com/kubernetes/kubernetes/pull/93311), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery, Auth, Cloud Provider and Instrumentation] -- AdmissionReview objects sent for the creation of Namespace API objects now populate the `namespace` attribute consistently (previously the `namespace` attribute was empty for Namespace creation via POST requests, and populated for Namespace creation via server-side-apply PATCH requests) ([#95012](https://github.com/kubernetes/kubernetes/pull/95012), [@nodo](https://github.com/nodo)) [SIG API Machinery and Testing] -- Applies translations on all command descriptions ([#95439](https://github.com/kubernetes/kubernetes/pull/95439), [@HerrNaN](https://github.com/HerrNaN)) [SIG CLI] -- Base-images: Update to debian-iptables:buster-v1.3.0 - - Uses iptables 1.8.5 - - base-images: Update to debian-base:buster-v1.2.0 - - cluster/images/etcd: Build etcd:3.4.13-1 image - - Uses debian-base:buster-v1.2.0 ([#94733](https://github.com/kubernetes/kubernetes/pull/94733), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Release and Testing] -- Changed: default "Accept-Encoding" header removed from HTTP probes. See https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#http-probes ([#96127](https://github.com/kubernetes/kubernetes/pull/96127), [@fonsecas72](https://github.com/fonsecas72)) [SIG Network and Node] -- Client-go header logging (at verbosity levels >= 9) now masks `Authorization` header contents ([#95316](https://github.com/kubernetes/kubernetes/pull/95316), [@sfowl](https://github.com/sfowl)) [SIG API Machinery] -- Decrease warning message frequency on setting volume ownership for configmap/secret. ([#92878](https://github.com/kubernetes/kubernetes/pull/92878), [@jvanz](https://github.com/jvanz)) -- Enhance log information of verifyRunAsNonRoot, add pod, container information ([#94911](https://github.com/kubernetes/kubernetes/pull/94911), [@wawa0210](https://github.com/wawa0210)) [SIG Node] -- Fix func name NewCreateCreateDeploymentOptions ([#91931](https://github.com/kubernetes/kubernetes/pull/91931), [@lixiaobing1](https://github.com/lixiaobing1)) [SIG CLI] -- Fix kubelet to properly log when a container is started. Previously, kubelet may log that container is dead and was restarted when it was actually started for the first time. This behavior only happened on pods with initContainers and regular containers. ([#91469](https://github.com/kubernetes/kubernetes/pull/91469), [@rata](https://github.com/rata)) -- Fixes the message about no auth for metrics in scheduler. ([#94035](https://github.com/kubernetes/kubernetes/pull/94035), [@zhouya0](https://github.com/zhouya0)) [SIG Scheduling] -- Generators for services are removed from kubectl ([#95256](https://github.com/kubernetes/kubernetes/pull/95256), [@Git-Jiro](https://github.com/Git-Jiro)) [SIG CLI] -- Introduce kubectl-convert plugin. ([#96190](https://github.com/kubernetes/kubernetes/pull/96190), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing] -- Kube-scheduler now logs processed component config at startup ([#96426](https://github.com/kubernetes/kubernetes/pull/96426), [@damemi](https://github.com/damemi)) [SIG Scheduling] -- Kubeadm: Separate argument key/value in log msg ([#94016](https://github.com/kubernetes/kubernetes/pull/94016), [@mrueg](https://github.com/mrueg)) [SIG Cluster Lifecycle] -- Kubeadm: remove the CoreDNS check for known image digests when applying the addon ([#94506](https://github.com/kubernetes/kubernetes/pull/94506), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: update the default pause image version to 1.4.0 on Windows. With this update the image supports Windows versions 1809 (2019LTS), 1903, 1909, 2004 ([#95419](https://github.com/kubernetes/kubernetes/pull/95419), [@jsturtevant](https://github.com/jsturtevant)) [SIG Cluster Lifecycle and Windows] -- Kubectl: the `generator` flag of `kubectl autoscale` has been deprecated and has no effect, it will be removed in a feature release ([#92998](https://github.com/kubernetes/kubernetes/pull/92998), [@SataQiu](https://github.com/SataQiu)) [SIG CLI] -- Lock ExternalPolicyForExternalIP to default, this feature gate will be removed in 1.22. ([#94581](https://github.com/kubernetes/kubernetes/pull/94581), [@knabben](https://github.com/knabben)) [SIG Network] -- Mask ceph RBD adminSecrets in logs when logLevel >= 4. ([#95245](https://github.com/kubernetes/kubernetes/pull/95245), [@sfowl](https://github.com/sfowl)) -- Remove offensive words from kubectl cluster-info command. ([#95202](https://github.com/kubernetes/kubernetes/pull/95202), [@rikatz](https://github.com/rikatz)) -- Remove support for "ci/k8s-master" version label in kubeadm, use "ci/latest" instead. See [kubernetes/test-infra#18517](https://github.com/kubernetes/test-infra/pull/18517). ([#93626](https://github.com/kubernetes/kubernetes/pull/93626), [@vikkyomkar](https://github.com/vikkyomkar)) -- Remove the dependency of csi-translation-lib module on apiserver/cloud-provider/controller-manager ([#95543](https://github.com/kubernetes/kubernetes/pull/95543), [@wawa0210](https://github.com/wawa0210)) [SIG Release] -- Scheduler framework interface moved from pkg/scheduler/framework/v1alpha to pkg/scheduler/framework ([#95069](https://github.com/kubernetes/kubernetes/pull/95069), [@farah](https://github.com/farah)) [SIG Scheduling, Storage and Testing] -- Service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset is removed. All Standard load balancers will always enable tcp resets. ([#94297](https://github.com/kubernetes/kubernetes/pull/94297), [@MarcPow](https://github.com/MarcPow)) [SIG Cloud Provider] -- Stop propagating SelfLink (deprecated in 1.16) in kube-apiserver ([#94397](https://github.com/kubernetes/kubernetes/pull/94397), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Testing] -- Strip unnecessary security contexts on Windows ([#93475](https://github.com/kubernetes/kubernetes/pull/93475), [@ravisantoshgudimetla](https://github.com/ravisantoshgudimetla)) [SIG Node, Testing and Windows] -- To ensure the code be strong, add unit test for GetAddressAndDialer ([#93180](https://github.com/kubernetes/kubernetes/pull/93180), [@FreeZhang61](https://github.com/FreeZhang61)) [SIG Node] -- UDP and SCTP protocols can left stale connections that need to be cleared to avoid services disruption, but they can cause problems that are hard to debug. - Kubernetes components using a loglevel greater or equal than 4 will log the conntrack operations and its output, to show the entries that were deleted. ([#95694](https://github.com/kubernetes/kubernetes/pull/95694), [@aojea](https://github.com/aojea)) [SIG Network] -- Update CNI plugins to v0.8.7 ([#94367](https://github.com/kubernetes/kubernetes/pull/94367), [@justaugustus](https://github.com/justaugustus)) [SIG Cloud Provider, Network, Node, Release and Testing] -- Update cri-tools to [v1.19.0](https://github.com/kubernetes-sigs/cri-tools/releases/tag/v1.19.0) ([#94307](https://github.com/kubernetes/kubernetes/pull/94307), [@xmudrii](https://github.com/xmudrii)) [SIG Cloud Provider] -- Update etcd client side to v3.4.13 ([#94259](https://github.com/kubernetes/kubernetes/pull/94259), [@jingyih](https://github.com/jingyih)) [SIG API Machinery and Cloud Provider] -- Users will now be able to configure all supported values for AWS NLB health check interval and thresholds for new resources. ([#96312](https://github.com/kubernetes/kubernetes/pull/96312), [@kishorj](https://github.com/kishorj)) [SIG Cloud Provider] -- V1helpers.MatchNodeSelectorTerms now accepts just a Node and a list of Terms ([#95871](https://github.com/kubernetes/kubernetes/pull/95871), [@damemi](https://github.com/damemi)) [SIG Apps, Scheduling and Storage] -- Vsphere: improve logging message on node cache refresh event ([#95236](https://github.com/kubernetes/kubernetes/pull/95236), [@andrewsykim](https://github.com/andrewsykim)) [SIG Cloud Provider] -- `MatchNodeSelectorTerms` function moved to `k8s.io/component-helpers` ([#95531](https://github.com/kubernetes/kubernetes/pull/95531), [@damemi](https://github.com/damemi)) [SIG Apps, Scheduling and Storage] -- `kubectl api-resources` now prints the API version (as 'API group/version', same as output of `kubectl api-versions`). The column APIGROUP is now APIVERSION ([#95253](https://github.com/kubernetes/kubernetes/pull/95253), [@sallyom](https://github.com/sallyom)) [SIG CLI] -- `kubectl get ingress` now prefers the `networking.k8s.io/v1` over `extensions/v1beta1` (deprecated since v1.14). To explicitly request the deprecated version, use `kubectl get ingress.v1beta1.extensions`. ([#94309](https://github.com/kubernetes/kubernetes/pull/94309), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and CLI] - -## Dependencies - -### Added -- cloud.google.com/go/firestore: v1.1.0 -- github.com/Azure/go-autorest: [v14.2.0+incompatible](https://github.com/Azure/go-autorest/tree/v14.2.0) -- github.com/armon/go-metrics: [f0300d1](https://github.com/armon/go-metrics/tree/f0300d1) -- github.com/armon/go-radix: [7fddfc3](https://github.com/armon/go-radix/tree/7fddfc3) -- github.com/bketelsen/crypt: [5cbc8cc](https://github.com/bketelsen/crypt/tree/5cbc8cc) -- github.com/form3tech-oss/jwt-go: [v3.2.2+incompatible](https://github.com/form3tech-oss/jwt-go/tree/v3.2.2) -- github.com/fvbommel/sortorder: [v1.0.1](https://github.com/fvbommel/sortorder/tree/v1.0.1) -- github.com/hashicorp/consul/api: [v1.1.0](https://github.com/hashicorp/consul/api/tree/v1.1.0) -- github.com/hashicorp/consul/sdk: [v0.1.1](https://github.com/hashicorp/consul/sdk/tree/v0.1.1) -- github.com/hashicorp/errwrap: [v1.0.0](https://github.com/hashicorp/errwrap/tree/v1.0.0) -- github.com/hashicorp/go-cleanhttp: [v0.5.1](https://github.com/hashicorp/go-cleanhttp/tree/v0.5.1) -- github.com/hashicorp/go-immutable-radix: [v1.0.0](https://github.com/hashicorp/go-immutable-radix/tree/v1.0.0) -- github.com/hashicorp/go-msgpack: [v0.5.3](https://github.com/hashicorp/go-msgpack/tree/v0.5.3) -- github.com/hashicorp/go-multierror: [v1.0.0](https://github.com/hashicorp/go-multierror/tree/v1.0.0) -- github.com/hashicorp/go-rootcerts: [v1.0.0](https://github.com/hashicorp/go-rootcerts/tree/v1.0.0) -- github.com/hashicorp/go-sockaddr: [v1.0.0](https://github.com/hashicorp/go-sockaddr/tree/v1.0.0) -- github.com/hashicorp/go-uuid: [v1.0.1](https://github.com/hashicorp/go-uuid/tree/v1.0.1) -- github.com/hashicorp/go.net: [v0.0.1](https://github.com/hashicorp/go.net/tree/v0.0.1) -- github.com/hashicorp/logutils: [v1.0.0](https://github.com/hashicorp/logutils/tree/v1.0.0) -- github.com/hashicorp/mdns: [v1.0.0](https://github.com/hashicorp/mdns/tree/v1.0.0) -- github.com/hashicorp/memberlist: [v0.1.3](https://github.com/hashicorp/memberlist/tree/v0.1.3) -- github.com/hashicorp/serf: [v0.8.2](https://github.com/hashicorp/serf/tree/v0.8.2) -- github.com/jmespath/go-jmespath/internal/testify: [v1.5.1](https://github.com/jmespath/go-jmespath/internal/testify/tree/v1.5.1) -- github.com/mitchellh/cli: [v1.0.0](https://github.com/mitchellh/cli/tree/v1.0.0) -- github.com/mitchellh/go-testing-interface: [v1.0.0](https://github.com/mitchellh/go-testing-interface/tree/v1.0.0) -- github.com/mitchellh/gox: [v0.4.0](https://github.com/mitchellh/gox/tree/v0.4.0) -- github.com/mitchellh/iochan: [v1.0.0](https://github.com/mitchellh/iochan/tree/v1.0.0) -- github.com/pascaldekloe/goe: [57f6aae](https://github.com/pascaldekloe/goe/tree/57f6aae) -- github.com/posener/complete: [v1.1.1](https://github.com/posener/complete/tree/v1.1.1) -- github.com/ryanuber/columnize: [9b3edd6](https://github.com/ryanuber/columnize/tree/9b3edd6) -- github.com/sean-/seed: [e2103e2](https://github.com/sean-/seed/tree/e2103e2) -- github.com/subosito/gotenv: [v1.2.0](https://github.com/subosito/gotenv/tree/v1.2.0) -- github.com/willf/bitset: [d5bec33](https://github.com/willf/bitset/tree/d5bec33) -- gopkg.in/ini.v1: v1.51.0 -- gopkg.in/yaml.v3: 9f266ea -- rsc.io/quote/v3: v3.1.0 -- rsc.io/sampler: v1.3.0 - -### Changed -- cloud.google.com/go/bigquery: v1.0.1 → v1.4.0 -- cloud.google.com/go/datastore: v1.0.0 → v1.1.0 -- cloud.google.com/go/pubsub: v1.0.1 → v1.2.0 -- cloud.google.com/go/storage: v1.0.0 → v1.6.0 -- cloud.google.com/go: v0.51.0 → v0.54.0 -- github.com/Azure/go-autorest/autorest/adal: [v0.8.2 → v0.9.5](https://github.com/Azure/go-autorest/autorest/adal/compare/v0.8.2...v0.9.5) -- github.com/Azure/go-autorest/autorest/date: [v0.2.0 → v0.3.0](https://github.com/Azure/go-autorest/autorest/date/compare/v0.2.0...v0.3.0) -- github.com/Azure/go-autorest/autorest/mocks: [v0.3.0 → v0.4.1](https://github.com/Azure/go-autorest/autorest/mocks/compare/v0.3.0...v0.4.1) -- github.com/Azure/go-autorest/autorest: [v0.9.6 → v0.11.1](https://github.com/Azure/go-autorest/autorest/compare/v0.9.6...v0.11.1) -- github.com/Azure/go-autorest/logger: [v0.1.0 → v0.2.0](https://github.com/Azure/go-autorest/logger/compare/v0.1.0...v0.2.0) -- github.com/Azure/go-autorest/tracing: [v0.5.0 → v0.6.0](https://github.com/Azure/go-autorest/tracing/compare/v0.5.0...v0.6.0) -- github.com/Microsoft/go-winio: [fc70bd9 → v0.4.15](https://github.com/Microsoft/go-winio/compare/fc70bd9...v0.4.15) -- github.com/aws/aws-sdk-go: [v1.28.2 → v1.35.24](https://github.com/aws/aws-sdk-go/compare/v1.28.2...v1.35.24) -- github.com/blang/semver: [v3.5.0+incompatible → v3.5.1+incompatible](https://github.com/blang/semver/compare/v3.5.0...v3.5.1) -- github.com/checkpoint-restore/go-criu/v4: [v4.0.2 → v4.1.0](https://github.com/checkpoint-restore/go-criu/v4/compare/v4.0.2...v4.1.0) -- github.com/containerd/containerd: [v1.3.3 → v1.4.1](https://github.com/containerd/containerd/compare/v1.3.3...v1.4.1) -- github.com/containerd/ttrpc: [v1.0.0 → v1.0.2](https://github.com/containerd/ttrpc/compare/v1.0.0...v1.0.2) -- github.com/containerd/typeurl: [v1.0.0 → v1.0.1](https://github.com/containerd/typeurl/compare/v1.0.0...v1.0.1) -- github.com/coreos/etcd: [v3.3.10+incompatible → v3.3.13+incompatible](https://github.com/coreos/etcd/compare/v3.3.10...v3.3.13) -- github.com/docker/docker: [aa6a989 → bd33bbf](https://github.com/docker/docker/compare/aa6a989...bd33bbf) -- github.com/go-gl/glfw/v3.3/glfw: [12ad95a → 6f7a984](https://github.com/go-gl/glfw/v3.3/glfw/compare/12ad95a...6f7a984) -- github.com/golang/groupcache: [215e871 → 8c9f03a](https://github.com/golang/groupcache/compare/215e871...8c9f03a) -- github.com/golang/mock: [v1.3.1 → v1.4.1](https://github.com/golang/mock/compare/v1.3.1...v1.4.1) -- github.com/golang/protobuf: [v1.4.2 → v1.4.3](https://github.com/golang/protobuf/compare/v1.4.2...v1.4.3) -- github.com/google/cadvisor: [v0.37.0 → v0.38.5](https://github.com/google/cadvisor/compare/v0.37.0...v0.38.5) -- github.com/google/go-cmp: [v0.4.0 → v0.5.2](https://github.com/google/go-cmp/compare/v0.4.0...v0.5.2) -- github.com/google/pprof: [d4f498a → 1ebb73c](https://github.com/google/pprof/compare/d4f498a...1ebb73c) -- github.com/google/uuid: [v1.1.1 → v1.1.2](https://github.com/google/uuid/compare/v1.1.1...v1.1.2) -- github.com/gorilla/mux: [v1.7.3 → v1.8.0](https://github.com/gorilla/mux/compare/v1.7.3...v1.8.0) -- github.com/gorilla/websocket: [v1.4.0 → v1.4.2](https://github.com/gorilla/websocket/compare/v1.4.0...v1.4.2) -- github.com/jmespath/go-jmespath: [c2b33e8 → v0.4.0](https://github.com/jmespath/go-jmespath/compare/c2b33e8...v0.4.0) -- github.com/karrick/godirwalk: [v1.7.5 → v1.16.1](https://github.com/karrick/godirwalk/compare/v1.7.5...v1.16.1) -- github.com/opencontainers/go-digest: [v1.0.0-rc1 → v1.0.0](https://github.com/opencontainers/go-digest/compare/v1.0.0-rc1...v1.0.0) -- github.com/opencontainers/runc: [819fcc6 → v1.0.0-rc92](https://github.com/opencontainers/runc/compare/819fcc6...v1.0.0-rc92) -- github.com/opencontainers/runtime-spec: [237cc4f → 4d89ac9](https://github.com/opencontainers/runtime-spec/compare/237cc4f...4d89ac9) -- github.com/opencontainers/selinux: [v1.5.2 → v1.6.0](https://github.com/opencontainers/selinux/compare/v1.5.2...v1.6.0) -- github.com/prometheus/procfs: [v0.1.3 → v0.2.0](https://github.com/prometheus/procfs/compare/v0.1.3...v0.2.0) -- github.com/quobyte/api: [v0.1.2 → v0.1.8](https://github.com/quobyte/api/compare/v0.1.2...v0.1.8) -- github.com/spf13/cobra: [v1.0.0 → v1.1.1](https://github.com/spf13/cobra/compare/v1.0.0...v1.1.1) -- github.com/spf13/viper: [v1.4.0 → v1.7.0](https://github.com/spf13/viper/compare/v1.4.0...v1.7.0) -- github.com/storageos/go-api: [343b3ef → v2.2.0+incompatible](https://github.com/storageos/go-api/compare/343b3ef...v2.2.0) -- github.com/stretchr/testify: [v1.4.0 → v1.6.1](https://github.com/stretchr/testify/compare/v1.4.0...v1.6.1) -- github.com/vishvananda/netns: [52d707b → db3c7e5](https://github.com/vishvananda/netns/compare/52d707b...db3c7e5) -- go.etcd.io/etcd: 17cef6e → dd1b699 -- go.opencensus.io: v0.22.2 → v0.22.3 -- golang.org/x/crypto: 75b2880 → 7f63de1 -- golang.org/x/exp: da58074 → 6cc2880 -- golang.org/x/lint: fdd1cda → 738671d -- golang.org/x/net: ab34263 → 69a7880 -- golang.org/x/oauth2: 858c2ad → bf48bf1 -- golang.org/x/sys: ed371f2 → 5cba982 -- golang.org/x/text: v0.3.3 → v0.3.4 -- golang.org/x/time: 555d28b → 3af7569 -- golang.org/x/xerrors: 9bdfabe → 5ec99f8 -- google.golang.org/api: v0.15.1 → v0.20.0 -- google.golang.org/genproto: cb27e3a → 8816d57 -- google.golang.org/grpc: v1.27.0 → v1.27.1 -- google.golang.org/protobuf: v1.24.0 → v1.25.0 -- honnef.co/go/tools: v0.0.1-2019.2.3 → v0.0.1-2020.1.3 -- k8s.io/gengo: 8167cfd → 83324d8 -- k8s.io/klog/v2: v2.2.0 → v2.4.0 -- k8s.io/kube-openapi: 6aeccd4 → d219536 -- k8s.io/system-validators: v1.1.2 → v1.2.0 -- k8s.io/utils: d5654de → 67b214c -- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.9 → v0.0.14 -- sigs.k8s.io/structured-merge-diff/v4: v4.0.1 → v4.0.2 - -### Removed -- github.com/armon/consul-api: [eb2c6b5](https://github.com/armon/consul-api/tree/eb2c6b5) -- github.com/go-ini/ini: [v1.9.0](https://github.com/go-ini/ini/tree/v1.9.0) -- github.com/ugorji/go: [v1.1.4](https://github.com/ugorji/go/tree/v1.1.4) -- github.com/xlab/handysort: [fb3537e](https://github.com/xlab/handysort/tree/fb3537e) -- github.com/xordataexchange/crypt: [b2862e3](https://github.com/xordataexchange/crypt/tree/b2862e3) -- vbom.ml/util: db5cfe1 - - -## Dependencies - -### Added -- cloud.google.com/go/firestore: v1.1.0 -- github.com/Azure/go-autorest: [v14.2.0+incompatible](https://github.com/Azure/go-autorest/tree/v14.2.0) -- github.com/armon/go-metrics: [f0300d1](https://github.com/armon/go-metrics/tree/f0300d1) -- github.com/armon/go-radix: [7fddfc3](https://github.com/armon/go-radix/tree/7fddfc3) -- github.com/bketelsen/crypt: [5cbc8cc](https://github.com/bketelsen/crypt/tree/5cbc8cc) -- github.com/form3tech-oss/jwt-go: [v3.2.2+incompatible](https://github.com/form3tech-oss/jwt-go/tree/v3.2.2) -- github.com/fvbommel/sortorder: [v1.0.1](https://github.com/fvbommel/sortorder/tree/v1.0.1) -- github.com/hashicorp/consul/api: [v1.1.0](https://github.com/hashicorp/consul/api/tree/v1.1.0) -- github.com/hashicorp/consul/sdk: [v0.1.1](https://github.com/hashicorp/consul/sdk/tree/v0.1.1) -- github.com/hashicorp/errwrap: [v1.0.0](https://github.com/hashicorp/errwrap/tree/v1.0.0) -- github.com/hashicorp/go-cleanhttp: [v0.5.1](https://github.com/hashicorp/go-cleanhttp/tree/v0.5.1) -- github.com/hashicorp/go-immutable-radix: [v1.0.0](https://github.com/hashicorp/go-immutable-radix/tree/v1.0.0) -- github.com/hashicorp/go-msgpack: [v0.5.3](https://github.com/hashicorp/go-msgpack/tree/v0.5.3) -- github.com/hashicorp/go-multierror: [v1.0.0](https://github.com/hashicorp/go-multierror/tree/v1.0.0) -- github.com/hashicorp/go-rootcerts: [v1.0.0](https://github.com/hashicorp/go-rootcerts/tree/v1.0.0) -- github.com/hashicorp/go-sockaddr: [v1.0.0](https://github.com/hashicorp/go-sockaddr/tree/v1.0.0) -- github.com/hashicorp/go-uuid: [v1.0.1](https://github.com/hashicorp/go-uuid/tree/v1.0.1) -- github.com/hashicorp/go.net: [v0.0.1](https://github.com/hashicorp/go.net/tree/v0.0.1) -- github.com/hashicorp/logutils: [v1.0.0](https://github.com/hashicorp/logutils/tree/v1.0.0) -- github.com/hashicorp/mdns: [v1.0.0](https://github.com/hashicorp/mdns/tree/v1.0.0) -- github.com/hashicorp/memberlist: [v0.1.3](https://github.com/hashicorp/memberlist/tree/v0.1.3) -- github.com/hashicorp/serf: [v0.8.2](https://github.com/hashicorp/serf/tree/v0.8.2) -- github.com/jmespath/go-jmespath/internal/testify: [v1.5.1](https://github.com/jmespath/go-jmespath/internal/testify/tree/v1.5.1) -- github.com/mitchellh/cli: [v1.0.0](https://github.com/mitchellh/cli/tree/v1.0.0) -- github.com/mitchellh/go-testing-interface: [v1.0.0](https://github.com/mitchellh/go-testing-interface/tree/v1.0.0) -- github.com/mitchellh/gox: [v0.4.0](https://github.com/mitchellh/gox/tree/v0.4.0) -- github.com/mitchellh/iochan: [v1.0.0](https://github.com/mitchellh/iochan/tree/v1.0.0) -- github.com/pascaldekloe/goe: [57f6aae](https://github.com/pascaldekloe/goe/tree/57f6aae) -- github.com/posener/complete: [v1.1.1](https://github.com/posener/complete/tree/v1.1.1) -- github.com/ryanuber/columnize: [9b3edd6](https://github.com/ryanuber/columnize/tree/9b3edd6) -- github.com/sean-/seed: [e2103e2](https://github.com/sean-/seed/tree/e2103e2) -- github.com/subosito/gotenv: [v1.2.0](https://github.com/subosito/gotenv/tree/v1.2.0) -- github.com/willf/bitset: [d5bec33](https://github.com/willf/bitset/tree/d5bec33) -- gopkg.in/ini.v1: v1.51.0 -- gopkg.in/yaml.v3: 9f266ea -- rsc.io/quote/v3: v3.1.0 -- rsc.io/sampler: v1.3.0 - -### Changed -- cloud.google.com/go/bigquery: v1.0.1 → v1.4.0 -- cloud.google.com/go/datastore: v1.0.0 → v1.1.0 -- cloud.google.com/go/pubsub: v1.0.1 → v1.2.0 -- cloud.google.com/go/storage: v1.0.0 → v1.6.0 -- cloud.google.com/go: v0.51.0 → v0.54.0 -- github.com/Azure/go-autorest/autorest/adal: [v0.8.2 → v0.9.5](https://github.com/Azure/go-autorest/autorest/adal/compare/v0.8.2...v0.9.5) -- github.com/Azure/go-autorest/autorest/date: [v0.2.0 → v0.3.0](https://github.com/Azure/go-autorest/autorest/date/compare/v0.2.0...v0.3.0) -- github.com/Azure/go-autorest/autorest/mocks: [v0.3.0 → v0.4.1](https://github.com/Azure/go-autorest/autorest/mocks/compare/v0.3.0...v0.4.1) -- github.com/Azure/go-autorest/autorest: [v0.9.6 → v0.11.1](https://github.com/Azure/go-autorest/autorest/compare/v0.9.6...v0.11.1) -- github.com/Azure/go-autorest/logger: [v0.1.0 → v0.2.0](https://github.com/Azure/go-autorest/logger/compare/v0.1.0...v0.2.0) -- github.com/Azure/go-autorest/tracing: [v0.5.0 → v0.6.0](https://github.com/Azure/go-autorest/tracing/compare/v0.5.0...v0.6.0) -- github.com/Microsoft/go-winio: [fc70bd9 → v0.4.15](https://github.com/Microsoft/go-winio/compare/fc70bd9...v0.4.15) -- github.com/aws/aws-sdk-go: [v1.28.2 → v1.35.24](https://github.com/aws/aws-sdk-go/compare/v1.28.2...v1.35.24) -- github.com/blang/semver: [v3.5.0+incompatible → v3.5.1+incompatible](https://github.com/blang/semver/compare/v3.5.0...v3.5.1) -- github.com/checkpoint-restore/go-criu/v4: [v4.0.2 → v4.1.0](https://github.com/checkpoint-restore/go-criu/v4/compare/v4.0.2...v4.1.0) -- github.com/containerd/containerd: [v1.3.3 → v1.4.1](https://github.com/containerd/containerd/compare/v1.3.3...v1.4.1) -- github.com/containerd/ttrpc: [v1.0.0 → v1.0.2](https://github.com/containerd/ttrpc/compare/v1.0.0...v1.0.2) -- github.com/containerd/typeurl: [v1.0.0 → v1.0.1](https://github.com/containerd/typeurl/compare/v1.0.0...v1.0.1) -- github.com/coreos/etcd: [v3.3.10+incompatible → v3.3.13+incompatible](https://github.com/coreos/etcd/compare/v3.3.10...v3.3.13) -- github.com/docker/docker: [aa6a989 → bd33bbf](https://github.com/docker/docker/compare/aa6a989...bd33bbf) -- github.com/go-gl/glfw/v3.3/glfw: [12ad95a → 6f7a984](https://github.com/go-gl/glfw/v3.3/glfw/compare/12ad95a...6f7a984) -- github.com/golang/groupcache: [215e871 → 8c9f03a](https://github.com/golang/groupcache/compare/215e871...8c9f03a) -- github.com/golang/mock: [v1.3.1 → v1.4.1](https://github.com/golang/mock/compare/v1.3.1...v1.4.1) -- github.com/golang/protobuf: [v1.4.2 → v1.4.3](https://github.com/golang/protobuf/compare/v1.4.2...v1.4.3) -- github.com/google/cadvisor: [v0.37.0 → v0.38.5](https://github.com/google/cadvisor/compare/v0.37.0...v0.38.5) -- github.com/google/go-cmp: [v0.4.0 → v0.5.2](https://github.com/google/go-cmp/compare/v0.4.0...v0.5.2) -- github.com/google/pprof: [d4f498a → 1ebb73c](https://github.com/google/pprof/compare/d4f498a...1ebb73c) -- github.com/google/uuid: [v1.1.1 → v1.1.2](https://github.com/google/uuid/compare/v1.1.1...v1.1.2) -- github.com/gorilla/mux: [v1.7.3 → v1.8.0](https://github.com/gorilla/mux/compare/v1.7.3...v1.8.0) -- github.com/gorilla/websocket: [v1.4.0 → v1.4.2](https://github.com/gorilla/websocket/compare/v1.4.0...v1.4.2) -- github.com/jmespath/go-jmespath: [c2b33e8 → v0.4.0](https://github.com/jmespath/go-jmespath/compare/c2b33e8...v0.4.0) -- github.com/karrick/godirwalk: [v1.7.5 → v1.16.1](https://github.com/karrick/godirwalk/compare/v1.7.5...v1.16.1) -- github.com/opencontainers/go-digest: [v1.0.0-rc1 → v1.0.0](https://github.com/opencontainers/go-digest/compare/v1.0.0-rc1...v1.0.0) -- github.com/opencontainers/runc: [819fcc6 → v1.0.0-rc92](https://github.com/opencontainers/runc/compare/819fcc6...v1.0.0-rc92) -- github.com/opencontainers/runtime-spec: [237cc4f → 4d89ac9](https://github.com/opencontainers/runtime-spec/compare/237cc4f...4d89ac9) -- github.com/opencontainers/selinux: [v1.5.2 → v1.6.0](https://github.com/opencontainers/selinux/compare/v1.5.2...v1.6.0) -- github.com/prometheus/procfs: [v0.1.3 → v0.2.0](https://github.com/prometheus/procfs/compare/v0.1.3...v0.2.0) -- github.com/quobyte/api: [v0.1.2 → v0.1.8](https://github.com/quobyte/api/compare/v0.1.2...v0.1.8) -- github.com/spf13/cobra: [v1.0.0 → v1.1.1](https://github.com/spf13/cobra/compare/v1.0.0...v1.1.1) -- github.com/spf13/viper: [v1.4.0 → v1.7.0](https://github.com/spf13/viper/compare/v1.4.0...v1.7.0) -- github.com/storageos/go-api: [343b3ef → v2.2.0+incompatible](https://github.com/storageos/go-api/compare/343b3ef...v2.2.0) -- github.com/stretchr/testify: [v1.4.0 → v1.6.1](https://github.com/stretchr/testify/compare/v1.4.0...v1.6.1) -- github.com/vishvananda/netns: [52d707b → db3c7e5](https://github.com/vishvananda/netns/compare/52d707b...db3c7e5) -- go.etcd.io/etcd: 17cef6e → dd1b699 -- go.opencensus.io: v0.22.2 → v0.22.3 -- golang.org/x/crypto: 75b2880 → 7f63de1 -- golang.org/x/exp: da58074 → 6cc2880 -- golang.org/x/lint: fdd1cda → 738671d -- golang.org/x/net: ab34263 → 69a7880 -- golang.org/x/oauth2: 858c2ad → bf48bf1 -- golang.org/x/sys: ed371f2 → 5cba982 -- golang.org/x/text: v0.3.3 → v0.3.4 -- golang.org/x/time: 555d28b → 3af7569 -- golang.org/x/xerrors: 9bdfabe → 5ec99f8 -- google.golang.org/api: v0.15.1 → v0.20.0 -- google.golang.org/genproto: cb27e3a → 8816d57 -- google.golang.org/grpc: v1.27.0 → v1.27.1 -- google.golang.org/protobuf: v1.24.0 → v1.25.0 -- honnef.co/go/tools: v0.0.1-2019.2.3 → v0.0.1-2020.1.3 -- k8s.io/gengo: 8167cfd → 83324d8 -- k8s.io/klog/v2: v2.2.0 → v2.4.0 -- k8s.io/kube-openapi: 6aeccd4 → d219536 -- k8s.io/system-validators: v1.1.2 → v1.2.0 -- k8s.io/utils: d5654de → 67b214c -- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.9 → v0.0.14 -- sigs.k8s.io/structured-merge-diff/v4: v4.0.1 → v4.0.2 - -### Removed -- github.com/armon/consul-api: [eb2c6b5](https://github.com/armon/consul-api/tree/eb2c6b5) -- github.com/go-ini/ini: [v1.9.0](https://github.com/go-ini/ini/tree/v1.9.0) -- github.com/ugorji/go: [v1.1.4](https://github.com/ugorji/go/tree/v1.1.4) -- github.com/xlab/handysort: [fb3537e](https://github.com/xlab/handysort/tree/fb3537e) -- github.com/xordataexchange/crypt: [b2862e3](https://github.com/xordataexchange/crypt/tree/b2862e3) -- vbom.ml/util: db5cfe1 - - - -# v1.20.0-rc.0 - - -## Downloads for v1.20.0-rc.0 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes.tar.gz) | acfee8658831f9503fccda0904798405434f17be7064a361a9f34c6ed04f1c0f685e79ca40cef5fcf34e3193bacbf467665e8dc277e0562ebdc929170034b5ae -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-src.tar.gz) | 9d962f8845e1fa221649cf0c0e178f0f03808486c49ea15ab5ec67861ec5aa948cf18bc0ee9b2067643c8332227973dd592e6a4457456a9d9d80e8ef28d5f7c3 - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-darwin-amd64.tar.gz) | 062b57f1a450fe01d6184f104d81d376bdf5720010412821e315fd9b1b622a400ac91f996540daa66cee172006f3efade4eccc19265494f1a1d7cc9450f0b50a -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-linux-386.tar.gz) | 86e96d2c2046c5e62e02bef30a6643f25e01f1b3eba256cab7dd61252908540c26cb058490e9cecc5a9bad97d2b577f5968884e9f1a90237e302419f39e068bc -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-linux-amd64.tar.gz) | 619d3afb9ce902368390e71633396010e88e87c5fd848e3adc71571d1d4a25be002588415e5f83afee82460f8a7c9e0bd968335277cb8f8cb51e58d4bb43e64e -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-linux-arm.tar.gz) | 60965150a60ab3d05a248339786e0c7da4b89a04539c3719737b13d71302bac1dd9bcaa427d8a1f84a7b42d0c67801dce2de0005e9e47d21122868b32ac3d40f -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-linux-arm64.tar.gz) | 688e064f4ef6a17189dbb5af468c279b9de35e215c40500fb97b1d46692d222747023f9e07a7f7ba006400f9532a8912e69d7c5143f956b1dadca144c67ee711 -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-linux-ppc64le.tar.gz) | 47b8abc02b42b3b1de67da184921b5801d7e3cb09befac840c85913193fc5ac4e5e3ecfcb57da6b686ff21af9a3bd42ae6949d4744dbe6ad976794340e328b83 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-linux-s390x.tar.gz) | 971b41d3169f30e6c412e0254c180636abb7ccc8dcee6641b0e9877b69752fc61aa30b76c19c108969df654fe385da3cb3a44dd59d3c28dc45561392d7e08874 -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-windows-386.tar.gz) | 2d34e8387e31531d9aca5655f2f0d18e75b01825dc1c39b7beb73a7b7b610e2ba429e5ca97d5c41a71b67e75e7096c86ab63fda9baab4c0878c1ccb3a1aefac8 -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-windows-amd64.tar.gz) | f909640f4140693bb871936f10a40e79b43502105d0adb318b35bb7a64a770ad9d05a3a732368ccd3d15d496d75454789165bd1f5c2571da9a00569b3e6c007c - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-server-linux-amd64.tar.gz) | 0ea4458ae34108c633b4d48f1f128c6274dbc82b613492e78b3e0a2f656ac0df0bb9a75124e15d67c8e81850adcecf19f4ab0234c17247ee7ddf84f2df3e5eaa -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-server-linux-arm.tar.gz) | aef6a4d457faa29936603370f29a8523bb274211c3cb5101bd31aaf469c91ba6bd149ea99a4ccdd83352cf37e4d6508c5ee475ec10292bccd2f77ceea31e1c28 -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-server-linux-arm64.tar.gz) | 4829f473e9d60f9929ad17c70fdc2b6b6509ed75418be0b23a75b28580949736cb5b0bd6382070f93aa0a2a8863f0b1596daf965186ca749996c29d03ef7d8b8 -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-server-linux-ppc64le.tar.gz) | 9ab0790d382a3e28df1c013762c09da0085449cfd09d176d80be932806c24a715ea829be0075c3e221a2ad9cf06e726b4c39ab41987c1fb0fee2563e48206763 -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-server-linux-s390x.tar.gz) | 98670b587e299856dd9821b7517a35f9a65835b915b153de08b66c54d82160438b66f774bf5306c07bc956d70ff709860bc23162225da5e89f995d3fdc1f0122 - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-node-linux-amd64.tar.gz) | 699e9c8d1837198312eade8eb6fec390f6a2fea9e08207d2f58e8bb6e3e799028aca69e4670aac0a4ba7cf0af683aee2c158bf78cc520c80edc876c8d94d521a -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-node-linux-arm.tar.gz) | f3b5eab0669490e3cd7e802693daf3555d08323dfff6e73a881fce00fed4690e8bdaf1610278d9de74036ca37631016075e5695a02158b7d3e7582b20ef7fa35 -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-node-linux-arm64.tar.gz) | e5012f77363561a609aaf791baaa17d09009819c4085a57132e5feb5366275a54640094e6ed1cba527f42b586c6d62999c2a5435edf5665ff0e114db4423c2ae -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-node-linux-ppc64le.tar.gz) | 2a6d6501620b1a9838dff05c66a40260cc22154a28027813346eb16e18c386bc3865298a46a0f08da71cd55149c5e7d07c4c4c431b4fd231486dd9d716548adb -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-node-linux-s390x.tar.gz) | 5eca02777519e31428a1e5842fe540b813fb8c929c341bbc71dcfd60d98deb89060f8f37352e8977020e21e053379eead6478eb2d54ced66fb9d38d5f3142bf0 -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-node-windows-amd64.tar.gz) | 8ace02e7623dff894e863a2e0fa7dfb916368431d1723170713fe82e334c0ae0481b370855b71e2561de0fb64fed124281be604761ec08607230b66fb9ed1c03 - -## Changelog since v1.20.0-beta.2 - -## Changes by Kind - -### Feature - -- Kubernetes is now built using go1.15.5 - - build: Update to k/repo-infra@v0.1.2 (supports go1.15.5) ([#95776](https://github.com/kubernetes/kubernetes/pull/95776), [@justaugustus](https://github.com/justaugustus)) [SIG Cloud Provider, Instrumentation, Release and Testing] - -### Failing Test - -- Resolves an issue running Ingress conformance tests on clusters which use finalizers on Ingress objects to manage releasing load balancer resources ([#96742](https://github.com/kubernetes/kubernetes/pull/96742), [@spencerhance](https://github.com/spencerhance)) [SIG Network and Testing] -- The Conformance test "validates that there is no conflict between pods with same hostPort but different hostIP and protocol" now validates the connectivity to each hostPort, in addition to the functionality. ([#96627](https://github.com/kubernetes/kubernetes/pull/96627), [@aojea](https://github.com/aojea)) [SIG Scheduling and Testing] - -### Bug or Regression - -- Bump node-problem-detector version to v0.8.5 to fix OOM detection in with Linux kernels 5.1+ ([#96716](https://github.com/kubernetes/kubernetes/pull/96716), [@tosi3k](https://github.com/tosi3k)) [SIG Cloud Provider, Scalability and Testing] -- Changes to timeout parameter handling in 1.20.0-beta.2 have been reverted to avoid breaking backwards compatibility with existing clients. ([#96727](https://github.com/kubernetes/kubernetes/pull/96727), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Testing] -- Duplicate owner reference entries in create/update/patch requests now get deduplicated by the API server. The client sending the request now receives a warning header in the API response. Clients should stop sending requests with duplicate owner references. The API server may reject such requests as early as 1.24. ([#96185](https://github.com/kubernetes/kubernetes/pull/96185), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery and Testing] -- Fix: resize Azure disk issue when it's in attached state ([#96705](https://github.com/kubernetes/kubernetes/pull/96705), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fixed a bug where aggregator_unavailable_apiservice metrics were reported for deleted apiservices. ([#96421](https://github.com/kubernetes/kubernetes/pull/96421), [@dgrisonnet](https://github.com/dgrisonnet)) [SIG API Machinery and Instrumentation] -- Fixes code generation for non-namespaced create subresources fake client test. ([#96586](https://github.com/kubernetes/kubernetes/pull/96586), [@Doude](https://github.com/Doude)) [SIG API Machinery] -- HTTP/2 connection health check is enabled by default in all Kubernetes clients. The feature should work out-of-the-box. If needed, users can tune the feature via the HTTP2_READ_IDLE_TIMEOUT_SECONDS and HTTP2_PING_TIMEOUT_SECONDS environment variables. The feature is disabled if HTTP2_READ_IDLE_TIMEOUT_SECONDS is set to 0. ([#95981](https://github.com/kubernetes/kubernetes/pull/95981), [@caesarxuchao](https://github.com/caesarxuchao)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node] -- Kubeadm: fix coredns migration should be triggered when there are newdefault configs during kubeadm upgrade ([#96907](https://github.com/kubernetes/kubernetes/pull/96907), [@pacoxu](https://github.com/pacoxu)) [SIG Cluster Lifecycle] -- Reduce volume name length for vsphere volumes ([#96533](https://github.com/kubernetes/kubernetes/pull/96533), [@gnufied](https://github.com/gnufied)) [SIG Storage] -- Resolves a regression in 1.19+ with workloads targeting deprecated beta os/arch labels getting stuck in NodeAffinity status on node startup. ([#96810](https://github.com/kubernetes/kubernetes/pull/96810), [@liggitt](https://github.com/liggitt)) [SIG Node] - -## Dependencies - -### Added -_Nothing has changed._ - -### Changed -- github.com/google/cadvisor: [v0.38.4 → v0.38.5](https://github.com/google/cadvisor/compare/v0.38.4...v0.38.5) - -### Removed -_Nothing has changed._ - - - -# v1.20.0-beta.2 - - -## Downloads for v1.20.0-beta.2 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes.tar.gz) | fe769280aa623802a949b6a35fbddadbba1d6f9933a54132a35625683719595ecf58096a9aa0f7456f8d4931774df21bfa98e148bc3d85913f1da915134f77bd -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-src.tar.gz) | ce1c8d97c52e5189af335d673bd7e99c564816f6adebf249838f7e3f0e920f323b4e398a5d163ea767091497012ec38843c59ff14e6fdd07683b682135eed645 - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-darwin-amd64.tar.gz) | d6c14bd0f6702f4bbdf14a6abdfa4e5936de5b4efee38aa86c2bd7272967ec6d7868b88fc00ad4a7c3a20717a35e6be2b84e56dec04154fd702315f641409f7c -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-linux-386.tar.gz) | b923c44cb0acb91a8f6fd442c2168aa6166c848f5d037ce50a7cb11502be3698db65836b373c916f75b648d6ac8d9158807a050eecc4e1c77cffa25b386c8cdb -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-linux-amd64.tar.gz) | 8cae14146a9034dcd4e9d69d5d700f195a77aac35f629a148960ae028ed8b4fe12213993fe3e6e464b4b3e111adebe6f3dd7ca0accc70c738ed5cfd8993edd7c -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-linux-arm.tar.gz) | 1f54e5262a0432945ead57fcb924e6bfedd9ea76db1dd9ebd946787a2923c247cf16e10505307b47e365905a1b398678dac5af0f433c439c158a33e08362d97b -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-linux-arm64.tar.gz) | 31cf79c01e4878a231b4881fe3ed5ef790bd5fb5419388438d3f8c6a2129e655aba9e00b8e1d77e0bc5d05ecc75cf4ae02cf8266788822d0306c49c85ee584ed -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-linux-ppc64le.tar.gz) | 2527948c40be2e16724d939316ad5363f15aa22ebf42d59359d8b6f757d30cfef6447434cc93bc5caa5a23a6a00a2da8d8191b6441e06bba469d9d4375989a97 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-linux-s390x.tar.gz) | b777ad764b3a46651ecb0846e5b7f860bb2c1c4bd4d0fcc468c6ccffb7d3b8dcb6dcdd73b13c16ded7219f91bba9f1e92f9258527fd3bb162b54d7901ac303ff -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-windows-386.tar.gz) | 8a2f58aaab01be9fe298e4d01456536047cbdd39a37d3e325c1f69ceab3a0504998be41a9f41a894735dfc4ed22bed02591eea5f3c75ce12d9e95ba134e72ec5 -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-windows-amd64.tar.gz) | 2f69cda177a178df149f5de66b7dba7f5ce14c1ffeb7c8d7dc4130c701b47d89bb2fbe74e7a262f573e4d21dee2c92414d050d7829e7c6fc3637a9d6b0b9c5c1 - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-server-linux-amd64.tar.gz) | 3ecaac0213d369eab691ac55376821a80df5013cb12e1263f18d1c236a9e49d42b3cea422175556d8f929cdf3109b22c0b6212ac0f2e80cc7a5f4afa3aba5f24 -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-server-linux-arm.tar.gz) | 580030b57ff207e177208fec0801a43389cae10cc2c9306327d354e7be6a055390184531d54b6742e0983550b7a76693cc4a705c2d2f4ac30495cf63cef26b9b -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-server-linux-arm64.tar.gz) | 3e3286bd54671549fbef0dfdaaf1da99bc5c3efb32cc8d1e1985d9926520cea0c43bcf7cbcbbc8b1c1a95eab961255693008af3bb1ba743362998b5f0017d6d7 -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-server-linux-ppc64le.tar.gz) | 9fa051e7e97648e97e26b09ab6d26be247b41b1a5938d2189204c9e6688e455afe76612bbcdd994ed5692935d0d960bd96dc222bce4b83f61d62557752b9d75b -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-server-linux-s390x.tar.gz) | fa85d432eff586f30975c95664ac130b9f5ae02dc52b97613ed7a41324496631ea11d1a267daba564cf2485a9e49707814d86bbd3175486c7efc8b58a9314af5 - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-node-linux-amd64.tar.gz) | 86e631f95fe670b467ead2b88d34e0364eaa275935af433d27cc378d82dcaa22041ccce40f5fa9561b9656dadaa578dc018ad458a59b1690d35f86dca4776b5c -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-node-linux-arm.tar.gz) | a8754ff58a0e902397056b8615ab49af07aca347ba7cc4a812c238e3812234862270f25106b6a94753b157bb153b8eae8b39a01ed67384774d798598c243583b -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-node-linux-arm64.tar.gz) | 28d727d7d08e2c856c9b4a574ef2dbf9e37236a0555f7ec5258b4284fa0582fb94b06783aaf50bf661f7503d101fbd70808aba6de02a2f0af94db7d065d25947 -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-node-linux-ppc64le.tar.gz) | a1283449f1a0b155c11449275e9371add544d0bdd4609d6dc737ed5f7dd228e84e24ff249613a2a153691627368dd894ad64f4e6c0010eecc6efd2c13d4fb133 -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-node-linux-s390x.tar.gz) | 5806028ba15a6a9c54a34f90117bc3181428dbb0e7ced30874c9f4a953ea5a0e9b2c73e6b1e2545e1b4e5253e9c7691588538b44cdfa666ce6865964b92d2fa8 -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-node-windows-amd64.tar.gz) | d5327e3b7916c78777b9b69ba0f3758c3a8645c67af80114a0ae52babd7af27bb504febbaf51b1bfe5bd2d74c8c5c573471e1cb449f2429453f4b1be9d5e682a - -## Changelog since v1.20.0-beta.1 - -## Urgent Upgrade Notes - -### (No, really, you MUST read this before you upgrade) - - - A bug was fixed in kubelet where exec probe timeouts were not respected. Ensure that pods relying on this behavior are updated to correctly handle probe timeouts. - - This change in behavior may be unexpected for some clusters and can be disabled by turning off the ExecProbeTimeout feature gate. This gate will be locked and removed in future releases so that exec probe timeouts are always respected. ([#94115](https://github.com/kubernetes/kubernetes/pull/94115), [@andrewsykim](https://github.com/andrewsykim)) [SIG Node and Testing] - - For CSI drivers, kubelet no longer creates the target_path for NodePublishVolume in accordance with the CSI spec. Kubelet also no longer checks if staging and target paths are mounts or corrupted. CSI drivers need to be idempotent and do any necessary mount verification. ([#88759](https://github.com/kubernetes/kubernetes/pull/88759), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage] - - Kubeadm: - - The label applied to control-plane nodes "node-role.kubernetes.io/master" is now deprecated and will be removed in a future release after a GA deprecation period. - - Introduce a new label "node-role.kubernetes.io/control-plane" that will be applied in parallel to "node-role.kubernetes.io/master" until the removal of the "node-role.kubernetes.io/master" label. - - Make "kubeadm upgrade apply" add the "node-role.kubernetes.io/control-plane" label on existing nodes that only have the "node-role.kubernetes.io/master" label during upgrade. - - Please adapt your tooling built on top of kubeadm to use the "node-role.kubernetes.io/control-plane" label. - - - The taint applied to control-plane nodes "node-role.kubernetes.io/master:NoSchedule" is now deprecated and will be removed in a future release after a GA deprecation period. - - Apply toleration for a new, future taint "node-role.kubernetes.io/control-plane:NoSchedule" to the kubeadm CoreDNS / kube-dns managed manifests. Note that this taint is not yet applied to kubeadm control-plane nodes. - - Please adapt your workloads to tolerate the same future taint preemptively. - - For more details see: http://git.k8s.io/enhancements/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint/README.md ([#95382](https://github.com/kubernetes/kubernetes/pull/95382), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] - -## Changes by Kind - -### Deprecation - -- Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. ([#94624](https://github.com/kubernetes/kubernetes/pull/94624), [@dims](https://github.com/dims)) [SIG Node] -- Kubectl: deprecate --delete-local-data ([#95076](https://github.com/kubernetes/kubernetes/pull/95076), [@dougsland](https://github.com/dougsland)) [SIG CLI, Cloud Provider and Scalability] - -### API Change - -- API priority and fairness graduated to beta - 1.19 servers with APF turned on should not be run in a multi-server cluster with 1.20+ servers. ([#96527](https://github.com/kubernetes/kubernetes/pull/96527), [@adtac](https://github.com/adtac)) [SIG API Machinery and Testing] -- Add LoadBalancerIPMode feature gate ([#92312](https://github.com/kubernetes/kubernetes/pull/92312), [@Sh4d1](https://github.com/Sh4d1)) [SIG Apps, CLI, Cloud Provider and Network] -- Add WindowsContainerResources and Annotations to CRI-API UpdateContainerResourcesRequest ([#95741](https://github.com/kubernetes/kubernetes/pull/95741), [@katiewasnothere](https://github.com/katiewasnothere)) [SIG Node] -- Add a 'serving' and `terminating` condition to the EndpointSlice API. - - `serving` tracks the readiness of endpoints regardless of their terminating state. This is distinct from `ready` since `ready` is only true when pods are not terminating. - `terminating` is true when an endpoint is terminating. For pods this is any endpoint with a deletion timestamp. ([#92968](https://github.com/kubernetes/kubernetes/pull/92968), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network] -- Add support for hugepages to downward API ([#86102](https://github.com/kubernetes/kubernetes/pull/86102), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG API Machinery, Apps, CLI, Network, Node, Scheduling and Testing] -- Adds kubelet alpha feature, `GracefulNodeShutdown` which makes kubelet aware of node system shutdowns and result in graceful termination of pods during a system shutdown. ([#96129](https://github.com/kubernetes/kubernetes/pull/96129), [@bobbypage](https://github.com/bobbypage)) [SIG Node] -- AppProtocol is now GA for Endpoints and Services. The ServiceAppProtocol feature gate will be deprecated in 1.21. ([#96327](https://github.com/kubernetes/kubernetes/pull/96327), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- Automatic allocation of NodePorts for services with type LoadBalancer can now be disabled by setting the (new) parameter - Service.spec.allocateLoadBalancerNodePorts=false. The default is to allocate NodePorts for services with type LoadBalancer which is the existing behavior. ([#92744](https://github.com/kubernetes/kubernetes/pull/92744), [@uablrek](https://github.com/uablrek)) [SIG Apps and Network] -- Document that ServiceTopology feature is required to use `service.spec.topologyKeys`. ([#96528](https://github.com/kubernetes/kubernetes/pull/96528), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps] -- EndpointSlice has a new NodeName field guarded by the EndpointSliceNodeName feature gate. - - EndpointSlice topology field will be deprecated in an upcoming release. - - EndpointSlice "IP" address type is formally removed after being deprecated in Kubernetes 1.17. - - The discovery.k8s.io/v1alpha1 API is deprecated and will be removed in Kubernetes 1.21. ([#96440](https://github.com/kubernetes/kubernetes/pull/96440), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps and Network] -- Fewer candidates are enumerated for preemption to improve performance in large clusters ([#94814](https://github.com/kubernetes/kubernetes/pull/94814), [@adtac](https://github.com/adtac)) [SIG Scheduling] -- If BoundServiceAccountTokenVolume is enabled, cluster admins can use metric `serviceaccount_stale_tokens_total` to monitor workloads that are depending on the extended tokens. If there are no such workloads, turn off extended tokens by starting `kube-apiserver` with flag `--service-account-extend-token-expiration=false` ([#96273](https://github.com/kubernetes/kubernetes/pull/96273), [@zshihang](https://github.com/zshihang)) [SIG API Machinery and Auth] -- Introduce alpha support for exec-based container registry credential provider plugins in the kubelet. ([#94196](https://github.com/kubernetes/kubernetes/pull/94196), [@andrewsykim](https://github.com/andrewsykim)) [SIG Node and Release] -- Kube-apiserver now deletes expired kube-apiserver Lease objects: - - The feature is under feature gate `APIServerIdentity`. - - A flag is added to kube-apiserver: `identity-lease-garbage-collection-check-period-seconds` ([#95895](https://github.com/kubernetes/kubernetes/pull/95895), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery, Apps, Auth and Testing] -- Move configurable fsgroup change policy for pods to beta ([#96376](https://github.com/kubernetes/kubernetes/pull/96376), [@gnufied](https://github.com/gnufied)) [SIG Apps and Storage] -- New flag is introduced, i.e. --topology-manager-scope=container|pod. - The default value is the "container" scope. ([#92967](https://github.com/kubernetes/kubernetes/pull/92967), [@cezaryzukowski](https://github.com/cezaryzukowski)) [SIG Instrumentation, Node and Testing] -- NodeAffinity plugin can be configured with AddedAffinity. ([#96202](https://github.com/kubernetes/kubernetes/pull/96202), [@alculquicondor](https://github.com/alculquicondor)) [SIG Node, Scheduling and Testing] -- Promote RuntimeClass feature to GA. - Promote node.k8s.io API groups from v1beta1 to v1. ([#95718](https://github.com/kubernetes/kubernetes/pull/95718), [@SergeyKanzhelev](https://github.com/SergeyKanzhelev)) [SIG Apps, Auth, Node, Scheduling and Testing] -- Reminder: The labels "failure-domain.beta.kubernetes.io/zone" and "failure-domain.beta.kubernetes.io/region" are deprecated in favor of "topology.kubernetes.io/zone" and "topology.kubernetes.io/region" respectively. All users of the "failure-domain.beta..." labels should switch to the "topology..." equivalents. ([#96033](https://github.com/kubernetes/kubernetes/pull/96033), [@thockin](https://github.com/thockin)) [SIG API Machinery, Apps, CLI, Cloud Provider, Network, Node, Scheduling, Storage and Testing] -- The usage of mixed protocol values in the same LoadBalancer Service is possible if the new feature gate MixedProtocolLBSVC is enabled. - "action required" - The feature gate is disabled by default. The user has to enable it for the API Server. ([#94028](https://github.com/kubernetes/kubernetes/pull/94028), [@janosi](https://github.com/janosi)) [SIG API Machinery and Apps] -- This PR will introduce a feature gate CSIServiceAccountToken with two additional fields in `CSIDriverSpec`. ([#93130](https://github.com/kubernetes/kubernetes/pull/93130), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Apps, Auth, CLI, Network, Node, Storage and Testing] -- Users can try the cronjob controller v2 using the feature gate. This will be the default controller in future releases. ([#93370](https://github.com/kubernetes/kubernetes/pull/93370), [@alaypatel07](https://github.com/alaypatel07)) [SIG API Machinery, Apps, Auth and Testing] -- VolumeSnapshotDataSource moves to GA in 1.20 release ([#95282](https://github.com/kubernetes/kubernetes/pull/95282), [@xing-yang](https://github.com/xing-yang)) [SIG Apps] - -### Feature - -- **Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.**: ([#95896](https://github.com/kubernetes/kubernetes/pull/95896), [@zshihang](https://github.com/zshihang)) [SIG API Machinery and Cluster Lifecycle] -- A new set of alpha metrics are reported by the Kubernetes scheduler under the `/metrics/resources` endpoint that allow administrators to easily see the resource consumption (requests and limits for all resources on the pods) and compare it to actual pod usage or node capacity. ([#94866](https://github.com/kubernetes/kubernetes/pull/94866), [@smarterclayton](https://github.com/smarterclayton)) [SIG API Machinery, Instrumentation, Node and Scheduling] -- Add --experimental-logging-sanitization flag enabling runtime protection from leaking sensitive data in logs ([#96370](https://github.com/kubernetes/kubernetes/pull/96370), [@serathius](https://github.com/serathius)) [SIG API Machinery, Cluster Lifecycle and Instrumentation] -- Add a StorageVersionAPI feature gate that makes API server update storageversions before serving certain write requests. - This feature allows the storage migrator to manage storage migration for built-in resources. - Enabling internal.apiserver.k8s.io/v1alpha1 API and APIServerIdentity feature gate are required to use this feature. ([#93873](https://github.com/kubernetes/kubernetes/pull/93873), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery, Auth and Testing] -- Add a new `vSphere` metric: `cloudprovider_vsphere_vcenter_versions`. It's content show `vCenter` hostnames with the associated server version. ([#94526](https://github.com/kubernetes/kubernetes/pull/94526), [@Danil-Grigorev](https://github.com/Danil-Grigorev)) [SIG Cloud Provider and Instrumentation] -- Add feature to size memory backed volumes ([#94444](https://github.com/kubernetes/kubernetes/pull/94444), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG Storage and Testing] -- Add node_authorizer_actions_duration_seconds metric that can be used to estimate load to node authorizer. ([#92466](https://github.com/kubernetes/kubernetes/pull/92466), [@mborsz](https://github.com/mborsz)) [SIG API Machinery, Auth and Instrumentation] -- Add pod_ based CPU and memory metrics to Kubelet's /metrics/resource endpoint ([#95839](https://github.com/kubernetes/kubernetes/pull/95839), [@egernst](https://github.com/egernst)) [SIG Instrumentation, Node and Testing] -- Adds a headless service on node-local-cache addon. ([#88412](https://github.com/kubernetes/kubernetes/pull/88412), [@stafot](https://github.com/stafot)) [SIG Cloud Provider and Network] -- CRDs: For structural schemas, non-nullable null map fields will now be dropped and defaulted if a default is available. null items in list will continue being preserved, and fail validation if not nullable. ([#95423](https://github.com/kubernetes/kubernetes/pull/95423), [@apelisse](https://github.com/apelisse)) [SIG API Machinery] -- E2e test for PodFsGroupChangePolicy ([#96247](https://github.com/kubernetes/kubernetes/pull/96247), [@saikat-royc](https://github.com/saikat-royc)) [SIG Storage and Testing] -- Gradudate the Pod Resources API to G.A - Introduces the pod_resources_endpoint_requests_total metric which tracks the total number of requests to the pod resources API ([#92165](https://github.com/kubernetes/kubernetes/pull/92165), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Instrumentation, Node and Testing] -- Introduce api-extensions category which will return: mutating admission configs, validating admission configs, CRDs and APIServices when used in kubectl get, for example. ([#95603](https://github.com/kubernetes/kubernetes/pull/95603), [@soltysh](https://github.com/soltysh)) [SIG API Machinery] -- Kube-apiserver now maintains a Lease object to identify itself: - - The feature is under feature gate `APIServerIdentity`. - - Two flags are added to kube-apiserver: `identity-lease-duration-seconds`, `identity-lease-renew-interval-seconds` ([#95533](https://github.com/kubernetes/kubernetes/pull/95533), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery] -- Kube-apiserver: The timeout used when making health check calls to etcd can now be configured with `--etcd-healthcheck-timeout`. The default timeout is 2 seconds, matching the previous behavior. ([#93244](https://github.com/kubernetes/kubernetes/pull/93244), [@Sh4d1](https://github.com/Sh4d1)) [SIG API Machinery] -- Kubectl: Previously users cannot provide arguments to a external diff tool via KUBECTL_EXTERNAL_DIFF env. This release now allow users to specify args to KUBECTL_EXTERNAL_DIFF env. ([#95292](https://github.com/kubernetes/kubernetes/pull/95292), [@dougsland](https://github.com/dougsland)) [SIG CLI] -- Scheduler now ignores Pod update events if the resourceVersion of old and new Pods are identical. ([#96071](https://github.com/kubernetes/kubernetes/pull/96071), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling] -- Support custom tags for cloud provider managed resources ([#96450](https://github.com/kubernetes/kubernetes/pull/96450), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Support customize load balancer health probe protocol and request path ([#96338](https://github.com/kubernetes/kubernetes/pull/96338), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Support multiple standard load balancers in one cluster ([#96111](https://github.com/kubernetes/kubernetes/pull/96111), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- The beta `RootCAConfigMap` feature gate is enabled by default and causes kube-controller-manager to publish a "kube-root-ca.crt" ConfigMap to every namespace. This ConfigMap contains a CA bundle used for verifying connections to the kube-apiserver. ([#96197](https://github.com/kubernetes/kubernetes/pull/96197), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Apps, Auth and Testing] -- The kubelet_runtime_operations_duration_seconds metric got additional buckets of 60, 300, 600, 900 and 1200 seconds ([#96054](https://github.com/kubernetes/kubernetes/pull/96054), [@alvaroaleman](https://github.com/alvaroaleman)) [SIG Instrumentation and Node] -- There is a new pv_collector_total_pv_count metric that counts persistent volumes by the volume plugin name and volume mode. ([#95719](https://github.com/kubernetes/kubernetes/pull/95719), [@tsmetana](https://github.com/tsmetana)) [SIG Apps, Instrumentation, Storage and Testing] -- Volume snapshot e2e test to validate PVC and VolumeSnapshotContent finalizer ([#95863](https://github.com/kubernetes/kubernetes/pull/95863), [@RaunakShah](https://github.com/RaunakShah)) [SIG Cloud Provider, Storage and Testing] -- Warns user when executing kubectl apply/diff to resource currently being deleted. ([#95544](https://github.com/kubernetes/kubernetes/pull/95544), [@SaiHarshaK](https://github.com/SaiHarshaK)) [SIG CLI] -- `kubectl alpha debug` has graduated to beta and is now `kubectl debug`. ([#96138](https://github.com/kubernetes/kubernetes/pull/96138), [@verb](https://github.com/verb)) [SIG CLI and Testing] -- `kubectl debug` gains support for changing container images when copying a pod for debugging, similar to how `kubectl set image` works. See `kubectl help debug` for more information. ([#96058](https://github.com/kubernetes/kubernetes/pull/96058), [@verb](https://github.com/verb)) [SIG CLI] - -### Documentation - -- Updates docs and guidance on cloud provider InstancesV2 and Zones interface for external cloud providers: - - removes experimental warning for InstancesV2 - - document that implementation of InstancesV2 will disable calls to Zones - - deprecate Zones in favor of InstancesV2 ([#96397](https://github.com/kubernetes/kubernetes/pull/96397), [@andrewsykim](https://github.com/andrewsykim)) [SIG Cloud Provider] - -### Bug or Regression - -- Change plugin name in fsgroupapplymetrics of csi and flexvolume to distinguish different driver ([#95892](https://github.com/kubernetes/kubernetes/pull/95892), [@JornShen](https://github.com/JornShen)) [SIG Instrumentation, Storage and Testing] -- Clear UDP conntrack entry on endpoint changes when using nodeport ([#71573](https://github.com/kubernetes/kubernetes/pull/71573), [@JacobTanenbaum](https://github.com/JacobTanenbaum)) [SIG Network] -- Exposes and sets a default timeout for the TokenReview client for DelegatingAuthenticationOptions ([#96217](https://github.com/kubernetes/kubernetes/pull/96217), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery and Cloud Provider] -- Fix CVE-2020-8555 for Quobyte client connections. ([#95206](https://github.com/kubernetes/kubernetes/pull/95206), [@misterikkit](https://github.com/misterikkit)) [SIG Storage] -- Fix IP fragmentation of UDP and TCP packets not supported issues on LoadBalancer rules ([#96464](https://github.com/kubernetes/kubernetes/pull/96464), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Fix a bug that DefaultPreemption plugin is disabled when using (legacy) scheduler policy. ([#96439](https://github.com/kubernetes/kubernetes/pull/96439), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing] -- Fix bug in JSON path parser where an error occurs when a range is empty ([#95933](https://github.com/kubernetes/kubernetes/pull/95933), [@brianpursley](https://github.com/brianpursley)) [SIG API Machinery] -- Fix client-go prometheus metrics to correctly present the API path accessed in some environments. ([#74363](https://github.com/kubernetes/kubernetes/pull/74363), [@aanm](https://github.com/aanm)) [SIG API Machinery] -- Fix memory leak in kube-apiserver when underlying time goes forth and back. ([#96266](https://github.com/kubernetes/kubernetes/pull/96266), [@chenyw1990](https://github.com/chenyw1990)) [SIG API Machinery] -- Fix paging issues when Azure API returns empty values with non-empty nextLink ([#96211](https://github.com/kubernetes/kubernetes/pull/96211), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Fix pull image error from multiple ACRs using azure managed identity ([#96355](https://github.com/kubernetes/kubernetes/pull/96355), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix vSphere volumes that could be erroneously attached to wrong node ([#96224](https://github.com/kubernetes/kubernetes/pull/96224), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage] -- Fixed a bug that prevents kubectl to validate CRDs with schema using x-kubernetes-preserve-unknown-fields on object fields. ([#96369](https://github.com/kubernetes/kubernetes/pull/96369), [@gautierdelorme](https://github.com/gautierdelorme)) [SIG API Machinery and Testing] -- For vSphere Cloud Provider, If VM of worker node is deleted, the node will also be deleted by node controller ([#92608](https://github.com/kubernetes/kubernetes/pull/92608), [@lubronzhan](https://github.com/lubronzhan)) [SIG Cloud Provider] -- HTTP/2 connection health check is enabled by default in all Kubernetes clients. The feature should work out-of-the-box. If needed, users can tune the feature via the HTTP2_READ_IDLE_TIMEOUT_SECONDS and HTTP2_PING_TIMEOUT_SECONDS environment variables. The feature is disabled if HTTP2_READ_IDLE_TIMEOUT_SECONDS is set to 0. ([#95981](https://github.com/kubernetes/kubernetes/pull/95981), [@caesarxuchao](https://github.com/caesarxuchao)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node] -- If the user specifies an invalid timeout in the request URL, the request will be aborted with an HTTP 400. - - If the user specifies a timeout in the request URL that exceeds the maximum request deadline allowed by the apiserver, the request will be aborted with an HTTP 400. ([#96061](https://github.com/kubernetes/kubernetes/pull/96061), [@tkashem](https://github.com/tkashem)) [SIG API Machinery, Network and Testing] -- Improve error messages related to nodePort endpoint changes conntrack entries cleanup. ([#96251](https://github.com/kubernetes/kubernetes/pull/96251), [@ravens](https://github.com/ravens)) [SIG Network] -- Print go stack traces at -v=4 and not -v=2 ([#94663](https://github.com/kubernetes/kubernetes/pull/94663), [@soltysh](https://github.com/soltysh)) [SIG CLI] -- Remove ready file and its directory (which is created during volume SetUp) during emptyDir volume TearDown. ([#95770](https://github.com/kubernetes/kubernetes/pull/95770), [@jingxu97](https://github.com/jingxu97)) [SIG Storage] -- Resolves non-deterministic behavior of the garbage collection controller when ownerReferences with incorrect data are encountered. Events with a reason of `OwnerRefInvalidNamespace` are recorded when namespace mismatches between child and owner objects are detected. - - A namespaced object with an ownerReference referencing a uid of a namespaced kind which does not exist in the same namespace is now consistently treated as though that owner does not exist, and the child object is deleted. - - A cluster-scoped object with an ownerReference referencing a uid of a namespaced kind is now consistently treated as though that owner is not resolvable, and the child object is ignored by the garbage collector. ([#92743](https://github.com/kubernetes/kubernetes/pull/92743), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Testing] -- Skip [k8s.io/kubernetes@v1.19.0/test/e2e/storage/testsuites/base.go:162]: Driver azure-disk doesn't support snapshot type DynamicSnapshot -- skipping - skip [k8s.io/kubernetes@v1.19.0/test/e2e/storage/testsuites/base.go:185]: Driver azure-disk doesn't support ntfs -- skipping ([#96144](https://github.com/kubernetes/kubernetes/pull/96144), [@qinpingli](https://github.com/qinpingli)) [SIG Storage and Testing] -- The AWS network load balancer attributes can now be specified during service creation ([#95247](https://github.com/kubernetes/kubernetes/pull/95247), [@kishorj](https://github.com/kishorj)) [SIG Cloud Provider] -- The kube-apiserver will no longer serve APIs that should have been deleted in GA non-alpha levels. Alpha levels will continue to serve the removed APIs so that CI doesn't immediately break. ([#96525](https://github.com/kubernetes/kubernetes/pull/96525), [@deads2k](https://github.com/deads2k)) [SIG API Machinery] -- Update max azure data disk count map ([#96308](https://github.com/kubernetes/kubernetes/pull/96308), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Update the route table tag in the route reconcile loop ([#96545](https://github.com/kubernetes/kubernetes/pull/96545), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Volume binding: report UnschedulableAndUnresolvable status instead of an error when bound PVs not found ([#95541](https://github.com/kubernetes/kubernetes/pull/95541), [@cofyc](https://github.com/cofyc)) [SIG Apps, Scheduling and Storage] -- [kubectl] Fail when local source file doesn't exist ([#90333](https://github.com/kubernetes/kubernetes/pull/90333), [@bamarni](https://github.com/bamarni)) [SIG CLI] - -### Other (Cleanup or Flake) - -- Handle slow cronjob lister in cronjob controller v2 and improve memory footprint. ([#96443](https://github.com/kubernetes/kubernetes/pull/96443), [@alaypatel07](https://github.com/alaypatel07)) [SIG Apps] -- --redirect-container-streaming is no longer functional. The flag will be removed in v1.22 ([#95935](https://github.com/kubernetes/kubernetes/pull/95935), [@tallclair](https://github.com/tallclair)) [SIG Node] -- A new metric `requestAbortsTotal` has been introduced that counts aborted requests for each `group`, `version`, `verb`, `resource`, `subresource` and `scope`. ([#95002](https://github.com/kubernetes/kubernetes/pull/95002), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery, Cloud Provider, Instrumentation and Scheduling] -- API priority and fairness metrics use snake_case in label names ([#96236](https://github.com/kubernetes/kubernetes/pull/96236), [@adtac](https://github.com/adtac)) [SIG API Machinery, Cluster Lifecycle, Instrumentation and Testing] -- Applies translations on all command descriptions ([#95439](https://github.com/kubernetes/kubernetes/pull/95439), [@HerrNaN](https://github.com/HerrNaN)) [SIG CLI] -- Changed: default "Accept-Encoding" header removed from HTTP probes. See https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#http-probes ([#96127](https://github.com/kubernetes/kubernetes/pull/96127), [@fonsecas72](https://github.com/fonsecas72)) [SIG Network and Node] -- Generators for services are removed from kubectl ([#95256](https://github.com/kubernetes/kubernetes/pull/95256), [@Git-Jiro](https://github.com/Git-Jiro)) [SIG CLI] -- Introduce kubectl-convert plugin. ([#96190](https://github.com/kubernetes/kubernetes/pull/96190), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing] -- Kube-scheduler now logs processed component config at startup ([#96426](https://github.com/kubernetes/kubernetes/pull/96426), [@damemi](https://github.com/damemi)) [SIG Scheduling] -- NONE ([#96179](https://github.com/kubernetes/kubernetes/pull/96179), [@bbyrne5](https://github.com/bbyrne5)) [SIG Network] -- Users will now be able to configure all supported values for AWS NLB health check interval and thresholds for new resources. ([#96312](https://github.com/kubernetes/kubernetes/pull/96312), [@kishorj](https://github.com/kishorj)) [SIG Cloud Provider] - -## Dependencies - -### Added -- cloud.google.com/go/firestore: v1.1.0 -- github.com/armon/go-metrics: [f0300d1](https://github.com/armon/go-metrics/tree/f0300d1) -- github.com/armon/go-radix: [7fddfc3](https://github.com/armon/go-radix/tree/7fddfc3) -- github.com/bketelsen/crypt: [5cbc8cc](https://github.com/bketelsen/crypt/tree/5cbc8cc) -- github.com/hashicorp/consul/api: [v1.1.0](https://github.com/hashicorp/consul/api/tree/v1.1.0) -- github.com/hashicorp/consul/sdk: [v0.1.1](https://github.com/hashicorp/consul/sdk/tree/v0.1.1) -- github.com/hashicorp/errwrap: [v1.0.0](https://github.com/hashicorp/errwrap/tree/v1.0.0) -- github.com/hashicorp/go-cleanhttp: [v0.5.1](https://github.com/hashicorp/go-cleanhttp/tree/v0.5.1) -- github.com/hashicorp/go-immutable-radix: [v1.0.0](https://github.com/hashicorp/go-immutable-radix/tree/v1.0.0) -- github.com/hashicorp/go-msgpack: [v0.5.3](https://github.com/hashicorp/go-msgpack/tree/v0.5.3) -- github.com/hashicorp/go-multierror: [v1.0.0](https://github.com/hashicorp/go-multierror/tree/v1.0.0) -- github.com/hashicorp/go-rootcerts: [v1.0.0](https://github.com/hashicorp/go-rootcerts/tree/v1.0.0) -- github.com/hashicorp/go-sockaddr: [v1.0.0](https://github.com/hashicorp/go-sockaddr/tree/v1.0.0) -- github.com/hashicorp/go-uuid: [v1.0.1](https://github.com/hashicorp/go-uuid/tree/v1.0.1) -- github.com/hashicorp/go.net: [v0.0.1](https://github.com/hashicorp/go.net/tree/v0.0.1) -- github.com/hashicorp/logutils: [v1.0.0](https://github.com/hashicorp/logutils/tree/v1.0.0) -- github.com/hashicorp/mdns: [v1.0.0](https://github.com/hashicorp/mdns/tree/v1.0.0) -- github.com/hashicorp/memberlist: [v0.1.3](https://github.com/hashicorp/memberlist/tree/v0.1.3) -- github.com/hashicorp/serf: [v0.8.2](https://github.com/hashicorp/serf/tree/v0.8.2) -- github.com/mitchellh/cli: [v1.0.0](https://github.com/mitchellh/cli/tree/v1.0.0) -- github.com/mitchellh/go-testing-interface: [v1.0.0](https://github.com/mitchellh/go-testing-interface/tree/v1.0.0) -- github.com/mitchellh/gox: [v0.4.0](https://github.com/mitchellh/gox/tree/v0.4.0) -- github.com/mitchellh/iochan: [v1.0.0](https://github.com/mitchellh/iochan/tree/v1.0.0) -- github.com/pascaldekloe/goe: [57f6aae](https://github.com/pascaldekloe/goe/tree/57f6aae) -- github.com/posener/complete: [v1.1.1](https://github.com/posener/complete/tree/v1.1.1) -- github.com/ryanuber/columnize: [9b3edd6](https://github.com/ryanuber/columnize/tree/9b3edd6) -- github.com/sean-/seed: [e2103e2](https://github.com/sean-/seed/tree/e2103e2) -- github.com/subosito/gotenv: [v1.2.0](https://github.com/subosito/gotenv/tree/v1.2.0) -- github.com/willf/bitset: [d5bec33](https://github.com/willf/bitset/tree/d5bec33) -- gopkg.in/ini.v1: v1.51.0 -- gopkg.in/yaml.v3: 9f266ea -- rsc.io/quote/v3: v3.1.0 -- rsc.io/sampler: v1.3.0 - -### Changed -- cloud.google.com/go/bigquery: v1.0.1 → v1.4.0 -- cloud.google.com/go/datastore: v1.0.0 → v1.1.0 -- cloud.google.com/go/pubsub: v1.0.1 → v1.2.0 -- cloud.google.com/go/storage: v1.0.0 → v1.6.0 -- cloud.google.com/go: v0.51.0 → v0.54.0 -- github.com/Microsoft/go-winio: [fc70bd9 → v0.4.15](https://github.com/Microsoft/go-winio/compare/fc70bd9...v0.4.15) -- github.com/aws/aws-sdk-go: [v1.35.5 → v1.35.24](https://github.com/aws/aws-sdk-go/compare/v1.35.5...v1.35.24) -- github.com/blang/semver: [v3.5.0+incompatible → v3.5.1+incompatible](https://github.com/blang/semver/compare/v3.5.0...v3.5.1) -- github.com/checkpoint-restore/go-criu/v4: [v4.0.2 → v4.1.0](https://github.com/checkpoint-restore/go-criu/v4/compare/v4.0.2...v4.1.0) -- github.com/containerd/containerd: [v1.3.3 → v1.4.1](https://github.com/containerd/containerd/compare/v1.3.3...v1.4.1) -- github.com/containerd/ttrpc: [v1.0.0 → v1.0.2](https://github.com/containerd/ttrpc/compare/v1.0.0...v1.0.2) -- github.com/containerd/typeurl: [v1.0.0 → v1.0.1](https://github.com/containerd/typeurl/compare/v1.0.0...v1.0.1) -- github.com/coreos/etcd: [v3.3.10+incompatible → v3.3.13+incompatible](https://github.com/coreos/etcd/compare/v3.3.10...v3.3.13) -- github.com/docker/docker: [aa6a989 → bd33bbf](https://github.com/docker/docker/compare/aa6a989...bd33bbf) -- github.com/go-gl/glfw/v3.3/glfw: [12ad95a → 6f7a984](https://github.com/go-gl/glfw/v3.3/glfw/compare/12ad95a...6f7a984) -- github.com/golang/groupcache: [215e871 → 8c9f03a](https://github.com/golang/groupcache/compare/215e871...8c9f03a) -- github.com/golang/mock: [v1.3.1 → v1.4.1](https://github.com/golang/mock/compare/v1.3.1...v1.4.1) -- github.com/golang/protobuf: [v1.4.2 → v1.4.3](https://github.com/golang/protobuf/compare/v1.4.2...v1.4.3) -- github.com/google/cadvisor: [v0.37.0 → v0.38.4](https://github.com/google/cadvisor/compare/v0.37.0...v0.38.4) -- github.com/google/go-cmp: [v0.4.0 → v0.5.2](https://github.com/google/go-cmp/compare/v0.4.0...v0.5.2) -- github.com/google/pprof: [d4f498a → 1ebb73c](https://github.com/google/pprof/compare/d4f498a...1ebb73c) -- github.com/google/uuid: [v1.1.1 → v1.1.2](https://github.com/google/uuid/compare/v1.1.1...v1.1.2) -- github.com/gorilla/mux: [v1.7.3 → v1.8.0](https://github.com/gorilla/mux/compare/v1.7.3...v1.8.0) -- github.com/gorilla/websocket: [v1.4.0 → v1.4.2](https://github.com/gorilla/websocket/compare/v1.4.0...v1.4.2) -- github.com/karrick/godirwalk: [v1.7.5 → v1.16.1](https://github.com/karrick/godirwalk/compare/v1.7.5...v1.16.1) -- github.com/opencontainers/runc: [819fcc6 → v1.0.0-rc92](https://github.com/opencontainers/runc/compare/819fcc6...v1.0.0-rc92) -- github.com/opencontainers/runtime-spec: [237cc4f → 4d89ac9](https://github.com/opencontainers/runtime-spec/compare/237cc4f...4d89ac9) -- github.com/opencontainers/selinux: [v1.5.2 → v1.6.0](https://github.com/opencontainers/selinux/compare/v1.5.2...v1.6.0) -- github.com/prometheus/procfs: [v0.1.3 → v0.2.0](https://github.com/prometheus/procfs/compare/v0.1.3...v0.2.0) -- github.com/quobyte/api: [v0.1.2 → v0.1.8](https://github.com/quobyte/api/compare/v0.1.2...v0.1.8) -- github.com/spf13/cobra: [v1.0.0 → v1.1.1](https://github.com/spf13/cobra/compare/v1.0.0...v1.1.1) -- github.com/spf13/viper: [v1.4.0 → v1.7.0](https://github.com/spf13/viper/compare/v1.4.0...v1.7.0) -- github.com/stretchr/testify: [v1.4.0 → v1.6.1](https://github.com/stretchr/testify/compare/v1.4.0...v1.6.1) -- github.com/vishvananda/netns: [52d707b → db3c7e5](https://github.com/vishvananda/netns/compare/52d707b...db3c7e5) -- go.opencensus.io: v0.22.2 → v0.22.3 -- golang.org/x/exp: da58074 → 6cc2880 -- golang.org/x/lint: fdd1cda → 738671d -- golang.org/x/net: ab34263 → 69a7880 -- golang.org/x/oauth2: 858c2ad → bf48bf1 -- golang.org/x/sys: ed371f2 → 5cba982 -- golang.org/x/text: v0.3.3 → v0.3.4 -- golang.org/x/time: 555d28b → 3af7569 -- golang.org/x/xerrors: 9bdfabe → 5ec99f8 -- google.golang.org/api: v0.15.1 → v0.20.0 -- google.golang.org/genproto: cb27e3a → 8816d57 -- google.golang.org/grpc: v1.27.0 → v1.27.1 -- google.golang.org/protobuf: v1.24.0 → v1.25.0 -- honnef.co/go/tools: v0.0.1-2019.2.3 → v0.0.1-2020.1.3 -- k8s.io/gengo: 8167cfd → 83324d8 -- k8s.io/klog/v2: v2.2.0 → v2.4.0 -- k8s.io/kube-openapi: 8b50664 → d219536 -- k8s.io/utils: d5654de → 67b214c -- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.12 → v0.0.14 -- sigs.k8s.io/structured-merge-diff/v4: b3cf1e8 → v4.0.2 - -### Removed -- github.com/armon/consul-api: [eb2c6b5](https://github.com/armon/consul-api/tree/eb2c6b5) -- github.com/go-ini/ini: [v1.9.0](https://github.com/go-ini/ini/tree/v1.9.0) -- github.com/ugorji/go: [v1.1.4](https://github.com/ugorji/go/tree/v1.1.4) -- github.com/xordataexchange/crypt: [b2862e3](https://github.com/xordataexchange/crypt/tree/b2862e3) - - - -# v1.20.0-beta.1 - - -## Downloads for v1.20.0-beta.1 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes.tar.gz) | 4eddf4850c2d57751696f352d0667309339090aeb30ff93e8db8a22c6cdebf74cb2d5dc78d4ae384c4e25491efc39413e2e420a804b76b421a9ad934e56b0667 -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-src.tar.gz) | 59de5221162e9b6d88f5abbdb99765cb2b2e501498ea853fb65f2abe390211e28d9f21e0d87be3ade550a5ea6395d04552cf093d2ce2f99fd45ad46545dd13cb - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-darwin-amd64.tar.gz) | d69ffed19b034a4221fc084e43ac293cf392e98febf5bf580f8d92307a8421d8b3aab18f9ca70608937e836b42c7a34e829f88eba6e040218a4486986e2fca21 -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-linux-386.tar.gz) | 1b542e165860c4adcd4550adc19b86c3db8cd75d2a1b8db17becc752da78b730ee48f1b0aaf8068d7bfbb1d8e023741ec293543bc3dd0f4037172a6917db8169 -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-linux-amd64.tar.gz) | 90ad52785eecb43a6f9035b92b6ba39fc84e67f8bc91cf098e70f8cfdd405c4b9d5c02dccb21022f21bb5b6ce92fdef304def1da0a7255c308e2c5fb3a9cdaab -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-linux-arm.tar.gz) | d0cb3322b056e1821679afa70728ffc0d3375e8f3326dabbe8185be2e60f665ab8985b13a1a432e10281b84a929e0f036960253ac0dd6e0b44677d539e98e61b -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-linux-arm64.tar.gz) | 3aecc8197e0aa368408624add28a2dd5e73f0d8a48e5e33c19edf91d5323071d16a27353a6f3e22df4f66ed7bfbae8e56e0a9050f7bbdf927ce6aeb29bba6374 -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-linux-ppc64le.tar.gz) | 6ff145058f62d478b98f1e418e272555bfb5c7861834fbbf10a8fb334cc7ff09b32f2666a54b230932ba71d2fc7d3b1c1f5e99e6fe6d6ec83926a9b931cd2474 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-linux-s390x.tar.gz) | ff7b8bb894076e05a3524f6327a4a6353b990466f3292e84c92826cb64b5c82b3855f48b8e297ccadc8bcc15552bc056419ff6ff8725fc4e640828af9cc1331b -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-windows-386.tar.gz) | 6c6dcac9c725605763a130b5a975f2b560aa976a5c809d4e0887900701b707baccb9ca1aebc10a03cfa7338a6f42922bbf838ccf6800fc2a3e231686a72568b6 -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-windows-amd64.tar.gz) | d12e3a29c960f0ddd1b9aabf5426ac1259863ac6c8f2be1736ebeb57ddca6b1c747ee2c363be19e059e38cf71488c5ea3509ad4d0e67fd5087282a5ad0ae9a48 - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-server-linux-amd64.tar.gz) | 904e8c049179e071c6caa65f525f465260bb4d4318a6dd9cc05be2172f39f7cfc69d1672736e01d926045764fe8872e806444e3af77ffef823ede769537b7d20 -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-server-linux-arm.tar.gz) | 5934959374868aed8d4294de84411972660bca7b2e952201a9403f37e40c60a5c53eaea8001344d0bf4a00c8cd27de6324d88161388de27f263a5761357cb82b -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-server-linux-arm64.tar.gz) | 4c884585970f80dc5462d9a734d7d5be9558b36c6e326a8a3139423efbd7284fa9f53fb077983647e17e19f03f5cb9bf26201450c78daecf10afa5a1ab5f9efc -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-server-linux-ppc64le.tar.gz) | 235b78b08440350dcb9f13b63f7722bd090c672d8e724ca5d409256e5a5d4f46d431652a1aa908c3affc5b1e162318471de443d38b93286113e79e7f90501a9b -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-server-linux-s390x.tar.gz) | 220fc9351702b3ecdcf79089892ceb26753a8a1deaf46922ffb3d3b62b999c93fef89440e779ca6043372b963081891b3a966d1a5df0cf261bdd44395fd28dce - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-node-linux-amd64.tar.gz) | fe59d3a1f21c47bab126f689687657f77fbcb46a2caeef48eecd073b2b22879f997a466911b5c5c829e9cf27e68a36ecdf18686d42714839d4b97d6c7281578d -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-node-linux-arm.tar.gz) | 93e545aa963cfd11e0b2c6d47669b5ef70c5a86ef80c3353c1a074396bff1e8e7371dda25c39d78c7a9e761f2607b8b5ab843fa0c10b8ff9663098fae8d25725 -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-node-linux-arm64.tar.gz) | 5e0f177f9bec406a668d4b37e69b191208551fdf289c82b5ec898959da4f8a00a2b0695cbf1d2de5acb809321c6e5604f5483d33556543d92b96dcf80e814dd3 -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-node-linux-ppc64le.tar.gz) | 574412059e4d257eb904cd4892a075b6a2cde27adfa4976ee64c46d6768facece338475f1b652ad94c8df7cfcbb70ebdf0113be109c7099ab76ffdb6f023eefd -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-node-linux-s390x.tar.gz) | b1ffaa6d7f77d89885c642663cb14a86f3e2ec2afd223e3bb2000962758cf0f15320969ffc4be93b5826ff22d54fdbae0dbea09f9d8228eda6da50b6fdc88758 -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-node-windows-amd64.tar.gz) | 388983765213cf3bdc1f8b27103ed79e39028767e5f1571e35ed1f91ed100e49f3027f7b7ff19b53fab7fbb6d723c0439f21fc6ed62be64532c25f5bfa7ee265 - -## Changelog since v1.20.0-beta.0 - -## Changes by Kind - -### Deprecation - -- ACTION REQUIRED: The kube-apiserver ability to serve on an insecure port, deprecated since v1.10, has been removed. The insecure address flags `--address` and `--insecure-bind-address` have no effect in kube-apiserver and will be removed in v1.24. The insecure port flags `--port` and `--insecure-port` may only be set to 0 and will be removed in v1.24. ([#95856](https://github.com/kubernetes/kubernetes/pull/95856), [@knight42](https://github.com/knight42)) [SIG API Machinery, Node and Testing] - -### API Change - -- + `TokenRequest` and `TokenRequestProjection` features have been promoted to GA. This feature allows generating service account tokens that are not visible in Secret objects and are tied to the lifetime of a Pod object. See https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection for details on configuring and using this feature. The `TokenRequest` and `TokenRequestProjection` feature gates will be removed in v1.21. - + kubeadm's kube-apiserver Pod manifest now includes the following flags by default "--service-account-key-file", "--service-account-signing-key-file", "--service-account-issuer". ([#93258](https://github.com/kubernetes/kubernetes/pull/93258), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Auth, Cluster Lifecycle, Storage and Testing] -- Certain fields on Service objects will be automatically cleared when changing the service's `type` to a mode that does not need those fields. For example, changing from type=LoadBalancer to type=ClusterIP will clear the NodePort assignments, rather than forcing the user to clear them. ([#95196](https://github.com/kubernetes/kubernetes/pull/95196), [@thockin](https://github.com/thockin)) [SIG API Machinery, Apps, Network and Testing] -- Services will now have a `clusterIPs` field to go with `clusterIP`. `clusterIPs[0]` is a synonym for `clusterIP` and will be syncronized on create and update operations. ([#95894](https://github.com/kubernetes/kubernetes/pull/95894), [@thockin](https://github.com/thockin)) [SIG Network] - -### Feature - -- A new metric `apiserver_request_filter_duration_seconds` has been introduced that - measures request filter latency in seconds. ([#95207](https://github.com/kubernetes/kubernetes/pull/95207), [@tkashem](https://github.com/tkashem)) [SIG API Machinery and Instrumentation] -- Add a new flag to set priority for the kubelet on Windows nodes so that workloads cannot overwhelm the node there by disrupting kubelet process. ([#96051](https://github.com/kubernetes/kubernetes/pull/96051), [@ravisantoshgudimetla](https://github.com/ravisantoshgudimetla)) [SIG Node and Windows] -- Changed: default "Accept: */*" header added to HTTP probes. See https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#http-probes (https://github.com/kubernetes/website/pull/24756) ([#95641](https://github.com/kubernetes/kubernetes/pull/95641), [@fonsecas72](https://github.com/fonsecas72)) [SIG Network and Node] -- Client-go credential plugins can now be passed in the current cluster information via the KUBERNETES_EXEC_INFO environment variable. ([#95489](https://github.com/kubernetes/kubernetes/pull/95489), [@ankeesler](https://github.com/ankeesler)) [SIG API Machinery and Auth] -- Kube-apiserver: added support for compressing rotated audit log files with `--audit-log-compress` ([#94066](https://github.com/kubernetes/kubernetes/pull/94066), [@lojies](https://github.com/lojies)) [SIG API Machinery and Auth] - -### Documentation - -- Fake dynamic client: document that List does not preserve TypeMeta in UnstructuredList ([#95117](https://github.com/kubernetes/kubernetes/pull/95117), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery] - -### Bug or Regression - -- Added support to kube-proxy for externalTrafficPolicy=Local setting via Direct Server Return (DSR) load balancers on Windows. ([#93166](https://github.com/kubernetes/kubernetes/pull/93166), [@elweb9858](https://github.com/elweb9858)) [SIG Network] -- Disable watchcache for events ([#96052](https://github.com/kubernetes/kubernetes/pull/96052), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery] -- Disabled `LocalStorageCapacityIsolation` feature gate is honored during scheduling. ([#96092](https://github.com/kubernetes/kubernetes/pull/96092), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling] -- Fix bug in JSON path parser where an error occurs when a range is empty ([#95933](https://github.com/kubernetes/kubernetes/pull/95933), [@brianpursley](https://github.com/brianpursley)) [SIG API Machinery] -- Fix k8s.io/apimachinery/pkg/api/meta.SetStatusCondition to update ObservedGeneration ([#95961](https://github.com/kubernetes/kubernetes/pull/95961), [@KnicKnic](https://github.com/KnicKnic)) [SIG API Machinery] -- Fixed a regression which prevented pods with `docker/default` seccomp annotations from being created in 1.19 if a PodSecurityPolicy was in place which did not allow `runtime/default` seccomp profiles. ([#95985](https://github.com/kubernetes/kubernetes/pull/95985), [@saschagrunert](https://github.com/saschagrunert)) [SIG Auth] -- Kubectl: print error if users place flags before plugin name ([#92343](https://github.com/kubernetes/kubernetes/pull/92343), [@knight42](https://github.com/knight42)) [SIG CLI] -- When creating a PVC with the volume.beta.kubernetes.io/storage-provisioner annotation already set, the PV controller might have incorrectly deleted the newly provisioned PV instead of binding it to the PVC, depending on timing and system load. ([#95909](https://github.com/kubernetes/kubernetes/pull/95909), [@pohly](https://github.com/pohly)) [SIG Apps and Storage] - -### Other (Cleanup or Flake) - -- Kubectl: the `generator` flag of `kubectl autoscale` has been deprecated and has no effect, it will be removed in a feature release ([#92998](https://github.com/kubernetes/kubernetes/pull/92998), [@SataQiu](https://github.com/SataQiu)) [SIG CLI] -- V1helpers.MatchNodeSelectorTerms now accepts just a Node and a list of Terms ([#95871](https://github.com/kubernetes/kubernetes/pull/95871), [@damemi](https://github.com/damemi)) [SIG Apps, Scheduling and Storage] -- `MatchNodeSelectorTerms` function moved to `k8s.io/component-helpers` ([#95531](https://github.com/kubernetes/kubernetes/pull/95531), [@damemi](https://github.com/damemi)) [SIG Apps, Scheduling and Storage] - -## Dependencies - -### Added -_Nothing has changed._ - -### Changed -_Nothing has changed._ - -### Removed -_Nothing has changed._ - - - -# v1.20.0-beta.0 - - -## Downloads for v1.20.0-beta.0 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes.tar.gz) | 385e49e32bbd6996f07bcadbf42285755b8a8ef9826ee1ba42bd82c65827cf13f63e5634b834451b263a93b708299cbb4b4b0b8ddbc688433deaf6bec240aa67 -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-src.tar.gz) | 842e80f6dcad461426fb699de8a55fde8621d76a94e54288fe9939cc1a3bbd0f4799abadac2c59bcf3f91d743726dbd17e1755312ae7fec482ef560f336dbcbb - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-darwin-amd64.tar.gz) | bde5e7d9ee3e79d1e69465a3ddb4bb36819a4f281b5c01a7976816d7c784410812dde133cdf941c47e5434e9520701b9c5e8b94d61dca77c172f87488dfaeb26 -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-linux-386.tar.gz) | 721bb8444c9e0d7a9f8461e3f5428882d76fcb3def6eb11b8e8e08fae7f7383630699248660d69d4f6a774124d6437888666e1fa81298d5b5518bc4a6a6b2c92 -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-linux-amd64.tar.gz) | 71e4edc41afbd65f813e7ecbc22b27c95f248446f005e288d758138dc4cc708735be7218af51bcf15e8b9893a3598c45d6a685f605b46f50af3762b02c32ed76 -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-linux-arm.tar.gz) | bbefc749156f63898973f2f7c7a6f1467481329fb430d641fe659b497e64d679886482d557ebdddb95932b93de8d1e3e365c91d4bf9f110b68bd94b0ba702ded -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-linux-arm64.tar.gz) | 9803190685058b4b64d002c2fbfb313308bcea4734ed53a8c340cfdae4894d8cb13b3e819ae64051bafe0fbf8b6ecab53a6c1dcf661c57640c75b0eb60041113 -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-linux-ppc64le.tar.gz) | bcdceea64cba1ae38ea2bab50d8fd77c53f6d673de12566050b0e3c204334610e6c19e4ace763e68b5e48ab9e811521208b852b1741627be30a2b17324fc1daf -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-linux-s390x.tar.gz) | 41e36d00867e90012d5d5adfabfaae8d9f5a9fd32f290811e3c368e11822916b973afaaf43961081197f2cbab234090d97d89774e674aeadc1da61f7a64708a9 -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-windows-386.tar.gz) | c50fec5aec2d0e742f851f25c236cb73e76f8fc73b0908049a10ae736c0205b8fff83eb3d29b1748412edd942da00dd738195d9003f25b577d6af8359d84fb2f -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-windows-amd64.tar.gz) | 0fd6777c349908b6d627e849ea2d34c048b8de41f7df8a19898623f597e6debd35b7bcbf8e1d43a1be3a9abb45e4810bc498a0963cf780b109e93211659e9c7e - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-server-linux-amd64.tar.gz) | 30d982424ca64bf0923503ae8195b2e2a59497096b2d9e58dfd491cd6639633027acfa9750bc7bccf34e1dc116d29d2f87cbd7ae713db4210ce9ac16182f0576 -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-server-linux-arm.tar.gz) | f08b62be9bc6f0745f820b0083c7a31eedb2ce370a037c768459a59192107b944c8f4345d0bb88fc975f2e7a803ac692c9ac3e16d4a659249d4600e84ff75d9e -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-server-linux-arm64.tar.gz) | e3472b5b3dfae0a56e5363d52062b1e4a9fc227a05e0cf5ece38233b2c442f427970aab94a52377fb87e583663c120760d154bc1c4ac22dca1f4d0d1ebb96088 -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-server-linux-ppc64le.tar.gz) | 06c254e0a62f755d31bc40093d86c44974f0a60308716cc3214a6b3c249a4d74534d909b82f8a3dd3a3c9720e61465b45d2bb3a327ef85d3caba865750020dfb -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-server-linux-s390x.tar.gz) | 2edeb4411c26a0de057a66787091ab1044f71774a464aed898ffee26634a40127181c2edddb38e786b6757cca878fd0c3a885880eec6c3448b93c645770abb12 - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-node-linux-amd64.tar.gz) | cc1d5b94b86070b5e7746d7aaeaeac3b3a5e5ebbff1ec33885f7eeab270a6177d593cb1975b2e56f4430b7859ad42da76f266629f9313e0f688571691ac448ed -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-node-linux-arm.tar.gz) | 75e82c7c9122add3b24695b94dcb0723c52420c3956abf47511e37785aa48a1fa8257db090c6601010c4475a325ccfff13eb3352b65e3aa1774f104b09b766b0 -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-node-linux-arm64.tar.gz) | 16ef27c40bf4d678a55fcd3d3f7d09f1597eec2cc58f9950946f0901e52b82287be397ad7f65e8d162d8a9cdb4a34a610b6db8b5d0462be8e27c4b6eb5d6e5e7 -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-node-linux-ppc64le.tar.gz) | 939865f2c4cb6a8934f22a06223e416dec5f768ffc1010314586149470420a1d62aef97527c34d8a636621c9669d6489908ce1caf96f109e8d073cee1c030b50 -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-node-linux-s390x.tar.gz) | bbfdd844075fb816079af7b73d99bc1a78f41717cdbadb043f6f5872b4dc47bc619f7f95e2680d4b516146db492c630c17424e36879edb45e40c91bc2ae4493c -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-node-windows-amd64.tar.gz) | a2b3ea40086fd71aed71a4858fd3fc79fd1907bc9ea8048ff3c82ec56477b0a791b724e5a52d79b3b36338c7fbd93dfd3d03b00ccea9042bda0d270fc891e4ec - -## Changelog since v1.20.0-alpha.3 - -## Urgent Upgrade Notes - -### (No, really, you MUST read this before you upgrade) - - - Kubeadm: improve the validation of serviceSubnet and podSubnet. - ServiceSubnet has to be limited in size, due to implementation details, and the mask can not allocate more than 20 bits. - PodSubnet validates against the corresponding cluster "--node-cidr-mask-size" of the kube-controller-manager, it fail if the values are not compatible. - kubeadm no longer sets the node-mask automatically on IPv6 deployments, you must check that your IPv6 service subnet mask is compatible with the default node mask /64 or set it accordenly. - Previously, for IPv6, if the podSubnet had a mask lower than /112, kubeadm calculated a node-mask to be multiple of eight and splitting the available bits to maximise the number used for nodes. ([#95723](https://github.com/kubernetes/kubernetes/pull/95723), [@aojea](https://github.com/aojea)) [SIG Cluster Lifecycle] - - Windows hyper-v container featuregate is deprecated in 1.20 and will be removed in 1.21 ([#95505](https://github.com/kubernetes/kubernetes/pull/95505), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] - -## Changes by Kind - -### Deprecation - -- Support 'controlplane' as a valid EgressSelection type in the EgressSelectorConfiguration API. 'Master' is deprecated and will be removed in v1.22. ([#95235](https://github.com/kubernetes/kubernetes/pull/95235), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery] - -### API Change - -- Add dual-stack Services (alpha). This is a BREAKING CHANGE to an alpha API. - It changes the dual-stack API wrt Service from a single ipFamily field to 3 - fields: ipFamilyPolicy (SingleStack, PreferDualStack, RequireDualStack), - ipFamilies (a list of families assigned), and clusterIPs (inclusive of - clusterIP). Most users do not need to set anything at all, defaulting will - handle it for them. Services are single-stack unless the user asks for - dual-stack. This is all gated by the "IPv6DualStack" feature gate. ([#91824](https://github.com/kubernetes/kubernetes/pull/91824), [@khenidak](https://github.com/khenidak)) [SIG API Machinery, Apps, CLI, Network, Node, Scheduling and Testing] -- Introduces a metric source for HPAs which allows scaling based on container resource usage. ([#90691](https://github.com/kubernetes/kubernetes/pull/90691), [@arjunrn](https://github.com/arjunrn)) [SIG API Machinery, Apps, Autoscaling and CLI] - -### Feature - -- Add a metric for time taken to perform recursive permission change ([#95866](https://github.com/kubernetes/kubernetes/pull/95866), [@JornShen](https://github.com/JornShen)) [SIG Instrumentation and Storage] -- Allow cross compilation of kubernetes on different platforms. ([#94403](https://github.com/kubernetes/kubernetes/pull/94403), [@bnrjee](https://github.com/bnrjee)) [SIG Release] -- Command to start network proxy changes from 'KUBE_ENABLE_EGRESS_VIA_KONNECTIVITY_SERVICE ./cluster/kube-up.sh' to 'KUBE_ENABLE_KONNECTIVITY_SERVICE=true ./hack/kube-up.sh' ([#92669](https://github.com/kubernetes/kubernetes/pull/92669), [@Jefftree](https://github.com/Jefftree)) [SIG Cloud Provider] -- DefaultPodTopologySpread graduated to Beta. The feature gate is enabled by default. ([#95631](https://github.com/kubernetes/kubernetes/pull/95631), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling and Testing] -- Kubernetes E2E test image manifest lists now contain Windows images. ([#77398](https://github.com/kubernetes/kubernetes/pull/77398), [@claudiubelu](https://github.com/claudiubelu)) [SIG Testing and Windows] -- Support for Windows container images (OS Versions: 1809, 1903, 1909, 2004) was added the pause:3.4 image. ([#91452](https://github.com/kubernetes/kubernetes/pull/91452), [@claudiubelu](https://github.com/claudiubelu)) [SIG Node, Release and Windows] - -### Documentation - -- Fake dynamic client: document that List does not preserve TypeMeta in UnstructuredList ([#95117](https://github.com/kubernetes/kubernetes/pull/95117), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery] - -### Bug or Regression - -- Exposes and sets a default timeout for the SubjectAccessReview client for DelegatingAuthorizationOptions. ([#95725](https://github.com/kubernetes/kubernetes/pull/95725), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery and Cloud Provider] -- Alter wording to describe pods using a pvc ([#95635](https://github.com/kubernetes/kubernetes/pull/95635), [@RaunakShah](https://github.com/RaunakShah)) [SIG CLI] -- If we set SelectPolicy MinPolicySelect on scaleUp behavior or scaleDown behavior,Horizontal Pod Autoscaler doesn`t automatically scale the number of pods correctly ([#95647](https://github.com/kubernetes/kubernetes/pull/95647), [@JoshuaAndrew](https://github.com/JoshuaAndrew)) [SIG Apps and Autoscaling] -- Ignore apparmor for non-linux operating systems ([#93220](https://github.com/kubernetes/kubernetes/pull/93220), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] -- Ipvs: ensure selected scheduler kernel modules are loaded ([#93040](https://github.com/kubernetes/kubernetes/pull/93040), [@cmluciano](https://github.com/cmluciano)) [SIG Network] -- Kubeadm: add missing "--experimental-patches" flag to "kubeadm init phase control-plane" ([#95786](https://github.com/kubernetes/kubernetes/pull/95786), [@Sh4d1](https://github.com/Sh4d1)) [SIG Cluster Lifecycle] -- Reorganized iptables rules to fix a performance issue ([#95252](https://github.com/kubernetes/kubernetes/pull/95252), [@tssurya](https://github.com/tssurya)) [SIG Network] -- Unhealthy pods covered by PDBs can be successfully evicted if enough healthy pods are available. ([#94381](https://github.com/kubernetes/kubernetes/pull/94381), [@michaelgugino](https://github.com/michaelgugino)) [SIG Apps] -- Update the PIP when it is not in the Succeeded provisioning state during the LB update. ([#95748](https://github.com/kubernetes/kubernetes/pull/95748), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Update the frontend IP config when the service's `pipName` annotation is changed ([#95813](https://github.com/kubernetes/kubernetes/pull/95813), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] - -### Other (Cleanup or Flake) - -- NO ([#95690](https://github.com/kubernetes/kubernetes/pull/95690), [@nikhita](https://github.com/nikhita)) [SIG Release] - -## Dependencies - -### Added -- github.com/form3tech-oss/jwt-go: [v3.2.2+incompatible](https://github.com/form3tech-oss/jwt-go/tree/v3.2.2) - -### Changed -- github.com/Azure/go-autorest/autorest/adal: [v0.9.0 → v0.9.5](https://github.com/Azure/go-autorest/autorest/adal/compare/v0.9.0...v0.9.5) -- github.com/Azure/go-autorest/autorest/mocks: [v0.4.0 → v0.4.1](https://github.com/Azure/go-autorest/autorest/mocks/compare/v0.4.0...v0.4.1) -- golang.org/x/crypto: 75b2880 → 7f63de1 - -### Removed -_Nothing has changed._ - - - -# v1.20.0-alpha.3 - - -## Downloads for v1.20.0-alpha.3 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes.tar.gz) | 542cc9e0cd97732020491456402b6e2b4f54f2714007ee1374a7d363663a1b41e82b50886176a5313aaccfbfd4df2bc611d6b32d19961cdc98b5821b75d6b17c -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-src.tar.gz) | 5e5d725294e552fd1d14fd6716d013222827ac2d4e2d11a7a1fdefb77b3459bbeb69931f38e1597de205dd32a1c9763ab524c2af1551faef4f502ef0890f7fbf - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-darwin-amd64.tar.gz) | 60004939727c75d0f06adc4449e16b43303941937c0e9ea9aca7d947e93a5aed5d11e53d1fc94caeb988be66d39acab118d406dc2d6cead61181e1ced6d2be1a -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-linux-386.tar.gz) | 7edba9c4f1bf38fdf1fa5bff2856c05c0e127333ce19b17edf3119dc9b80462c027404a1f58a5eabf1de73a8f2f20aced043dda1fafd893619db1a188cda550c -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-linux-amd64.tar.gz) | db1818aa82d072cb3e32a2a988e66d76ecf7cebc6b8a29845fa2d6ec27f14a36e4b9839b1b7ed8c43d2da9cde00215eb672a7e8ee235d2e3107bc93c22e58d38 -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-linux-arm.tar.gz) | d2922e70d22364b1f5a1e94a0c115f849fe2575b231b1ba268f73a9d86fc0a9fbb78dc713446839a2593acf1341cb5a115992f350870f13c1a472bb107b75af7 -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-linux-arm64.tar.gz) | 2e3ae20e554c7d4fc3a8afdfcafe6bbc81d4c5e9aea036357baac7a3fdc2e8098aa8a8c3dded3951667d57f667ce3fbf37ec5ae5ceb2009a569dc9002d3a92f9 -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-linux-ppc64le.tar.gz) | b54a34e572e6a86221577de376e6f7f9fcd82327f7fe94f2fc8d21f35d302db8a0f3d51e60dc89693999f5df37c96d0c3649a29f07f095efcdd59923ae285c95 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-linux-s390x.tar.gz) | 5be1b70dc437d3ba88cb0b89cd1bc555f79896c3f5b5f4fa0fb046a0d09d758b994d622ebe5cef8e65bba938c5ae945b81dc297f9dfa0d98f82ea75f344a3a0d -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-windows-386.tar.gz) | 88cf3f66168ef3bf9a5d3d2275b7f33799406e8205f2c202997ebec23d449aa4bb48b010356ab1cf52ff7b527b8df7c8b9947a43a82ebe060df83c3d21b7223a -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-windows-amd64.tar.gz) | 87d2d4ea1829da8cfa1a705a03ea26c759a03bd1c4d8b96f2c93264c4d172bb63a91d9ddda65cdc5478b627c30ae8993db5baf8be262c157d83bffcebe85474e - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-server-linux-amd64.tar.gz) | 7af691fc0b13a937797912374e3b3eeb88d5262e4eb7d4ebe92a3b64b3c226cb049aedfd7e39f639f6990444f7bcf2fe58699cf0c29039daebe100d7eebf60de -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-server-linux-arm.tar.gz) | 557c47870ecf5c2090b2694c8f0c8e3b4ca23df5455a37945bd037bc6fb5b8f417bf737bb66e6336b285112cb52de0345240fdb2f3ce1c4fb335ca7ef1197f99 -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-server-linux-arm64.tar.gz) | 981de6cf7679d743cdeef1e894314357b68090133814801870504ef30564e32b5675e270db20961e9a731e35241ad9b037bdaf749da87b6c4ce8889eeb1c5855 -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-server-linux-ppc64le.tar.gz) | 506578a21601ccff609ae757a55e68634c15cbfecbf13de972c96b32a155ded29bd71aee069c77f5f721416672c7a7ac0b8274de22bfd28e1ecae306313d96c5 -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-server-linux-s390x.tar.gz) | af0cdcd4a77a7cc8060a076641615730a802f1f02dab084e41926023489efec6102d37681c70ab0dbe7440cd3e72ea0443719a365467985360152b9aae657375 - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-node-linux-amd64.tar.gz) | 2d92c61596296279de1efae23b2b707415565d9d50cd61a7231b8d10325732b059bcb90f3afb36bef2575d203938c265572721e38df408e8792d3949523bd5d9 -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-node-linux-arm.tar.gz) | c298de9b5ac1b8778729a2d8e2793ff86743033254fbc27014333880b03c519de81691caf03aa418c729297ee8942ce9ec89d11b0e34a80576b9936015dc1519 -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-node-linux-arm64.tar.gz) | daa3c65afda6d7aff206c1494390bbcc205c2c6f8db04c10ca967a690578a01c49d49c6902b85e7158f79fd4d2a87c5d397d56524a75991c9d7db85ac53059a7 -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-node-linux-ppc64le.tar.gz) | 05661908bb73bfcaf9c2eae96e9a6a793db5a7a100bce6df9e057985dd53a7a5248d72e81b6d13496bd38b9326c17cdb2edaf0e982b6437507245fb846e1efc6 -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-node-linux-s390x.tar.gz) | 845e518e2c4ef0cef2c3b58f0b9ea5b5fe9b8a249717f789607752484c424c26ae854b263b7c0a004a8426feb9aa3683c177a9ed2567e6c3521f4835ea08c24a -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-node-windows-amd64.tar.gz) | 530e536574ed2c3e5973d3c0f0fdd2b4d48ef681a7a7c02db13e605001669eeb4f4b8a856fc08fc21436658c27b377f5d04dbcb3aae438098abc953b6eaf5712 - -## Changelog since v1.20.0-alpha.2 - -## Changes by Kind - -### API Change - -- New parameter `defaultingType` for `PodTopologySpread` plugin allows to use k8s defined or user provided default constraints ([#95048](https://github.com/kubernetes/kubernetes/pull/95048), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] - -### Feature - -- Added new k8s.io/component-helpers repository providing shared helper code for (core) components. ([#92507](https://github.com/kubernetes/kubernetes/pull/92507), [@ingvagabund](https://github.com/ingvagabund)) [SIG Apps, Node, Release and Scheduling] -- Adds `create ingress` command to `kubectl` ([#78153](https://github.com/kubernetes/kubernetes/pull/78153), [@amimof](https://github.com/amimof)) [SIG CLI and Network] -- Kubectl create now supports creating ingress objects. ([#94327](https://github.com/kubernetes/kubernetes/pull/94327), [@rikatz](https://github.com/rikatz)) [SIG CLI and Network] -- New default scheduling plugins order reduces scheduling and preemption latency when taints and node affinity are used ([#95539](https://github.com/kubernetes/kubernetes/pull/95539), [@soulxu](https://github.com/soulxu)) [SIG Scheduling] -- SCTP support in API objects (Pod, Service, NetworkPolicy) is now GA. - Note that this has no effect on whether SCTP is enabled on nodes at the kernel level, - and note that some cloud platforms and network plugins do not support SCTP traffic. ([#95566](https://github.com/kubernetes/kubernetes/pull/95566), [@danwinship](https://github.com/danwinship)) [SIG Apps and Network] -- Scheduling Framework: expose Run[Pre]ScorePlugins functions to PreemptionHandle which can be used in PostFilter extention point. ([#93534](https://github.com/kubernetes/kubernetes/pull/93534), [@everpeace](https://github.com/everpeace)) [SIG Scheduling and Testing] -- SelectorSpreadPriority maps to PodTopologySpread plugin when DefaultPodTopologySpread feature is enabled ([#95448](https://github.com/kubernetes/kubernetes/pull/95448), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- SetHostnameAsFQDN has been graduated to Beta and therefore it is enabled by default. ([#95267](https://github.com/kubernetes/kubernetes/pull/95267), [@javidiaz](https://github.com/javidiaz)) [SIG Node] - -### Bug or Regression - -- An issues preventing volume expand controller to annotate the PVC with `volume.kubernetes.io/storage-resizer` when the PVC StorageClass is already updated to the out-of-tree provisioner is now fixed. ([#94489](https://github.com/kubernetes/kubernetes/pull/94489), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG API Machinery, Apps and Storage] -- Change the mount way from systemd to normal mount except ceph and glusterfs intree-volume. ([#94916](https://github.com/kubernetes/kubernetes/pull/94916), [@smileusd](https://github.com/smileusd)) [SIG Apps, Cloud Provider, Network, Node, Storage and Testing] -- Fix azure disk attach failure for disk size bigger than 4TB ([#95463](https://github.com/kubernetes/kubernetes/pull/95463), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix azure disk data loss issue on Windows when unmount disk ([#95456](https://github.com/kubernetes/kubernetes/pull/95456), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fix verb & scope reporting for kube-apiserver metrics (LIST reported instead of GET) ([#95562](https://github.com/kubernetes/kubernetes/pull/95562), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Testing] -- Fix vsphere detach failure for static PVs ([#95447](https://github.com/kubernetes/kubernetes/pull/95447), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage] -- Fix: smb valid path error ([#95583](https://github.com/kubernetes/kubernetes/pull/95583), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage] -- Fixed a bug causing incorrect formatting of `kubectl describe ingress`. ([#94985](https://github.com/kubernetes/kubernetes/pull/94985), [@howardjohn](https://github.com/howardjohn)) [SIG CLI and Network] -- Fixed a bug in client-go where new clients with customized `Dial`, `Proxy`, `GetCert` config may get stale HTTP transports. ([#95427](https://github.com/kubernetes/kubernetes/pull/95427), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery] -- Fixes high CPU usage in kubectl drain ([#95260](https://github.com/kubernetes/kubernetes/pull/95260), [@amandahla](https://github.com/amandahla)) [SIG CLI] -- Support the node label `node.kubernetes.io/exclude-from-external-load-balancers` ([#95542](https://github.com/kubernetes/kubernetes/pull/95542), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] - -### Other (Cleanup or Flake) - -- Fix func name NewCreateCreateDeploymentOptions ([#91931](https://github.com/kubernetes/kubernetes/pull/91931), [@lixiaobing1](https://github.com/lixiaobing1)) [SIG CLI] -- Kubeadm: update the default pause image version to 1.4.0 on Windows. With this update the image supports Windows versions 1809 (2019LTS), 1903, 1909, 2004 ([#95419](https://github.com/kubernetes/kubernetes/pull/95419), [@jsturtevant](https://github.com/jsturtevant)) [SIG Cluster Lifecycle and Windows] -- Upgrade snapshot controller to 3.0.0 ([#95412](https://github.com/kubernetes/kubernetes/pull/95412), [@saikat-royc](https://github.com/saikat-royc)) [SIG Cloud Provider] -- Remove the dependency of csi-translation-lib module on apiserver/cloud-provider/controller-manager ([#95543](https://github.com/kubernetes/kubernetes/pull/95543), [@wawa0210](https://github.com/wawa0210)) [SIG Release] -- Scheduler framework interface moved from pkg/scheduler/framework/v1alpha to pkg/scheduler/framework ([#95069](https://github.com/kubernetes/kubernetes/pull/95069), [@farah](https://github.com/farah)) [SIG Scheduling, Storage and Testing] -- UDP and SCTP protocols can left stale connections that need to be cleared to avoid services disruption, but they can cause problems that are hard to debug. - Kubernetes components using a loglevel greater or equal than 4 will log the conntrack operations and its output, to show the entries that were deleted. ([#95694](https://github.com/kubernetes/kubernetes/pull/95694), [@aojea](https://github.com/aojea)) [SIG Network] - -## Dependencies - -### Added -_Nothing has changed._ - -### Changed -_Nothing has changed._ - -### Removed -_Nothing has changed._ - - - -# v1.20.0-alpha.2 - - -## Downloads for v1.20.0-alpha.2 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes.tar.gz) | 45089a4d26d56a5d613ecbea64e356869ac738eca3cc71d16b74ea8ae1b4527bcc32f1dc35ff7aa8927e138083c7936603faf063121d965a2f0f8ba28fa128d8 -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-src.tar.gz) | 646edd890d6df5858b90aaf68cc6e1b4589b8db09396ae921b5c400f2188234999e6c9633906692add08c6e8b4b09f12b2099132b0a7533443fb2a01cfc2bf81 - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-darwin-amd64.tar.gz) | c136273883e24a2a50b5093b9654f01cdfe57b97461d34885af4a68c2c4d108c07583c02b1cdf7f57f82e91306e542ce8f3bddb12fcce72b744458bc4796f8eb -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-linux-386.tar.gz) | 6ec59f1ed30569fa64ddb2d0de32b1ae04cda4ffe13f339050a7c9d7c63d425ee6f6d963dcf82c17281c4474da3eaf32c08117669052872a8c81bdce2c8a5415 -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-linux-amd64.tar.gz) | 7b40a4c087e2ea7f8d055f297fcd39a3f1cb6c866e7a3981a9408c3c3eb5363c648613491aad11bc7d44d5530b20832f8f96f6ceff43deede911fb74aafad35f -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-linux-arm.tar.gz) | cda9955feebea5acb8f2b5b87895d24894bbbbde47041453b1f926ebdf47a258ce0496aa27d06bcbf365b5615ce68a20d659b64410c54227216726e2ee432fca -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-linux-arm64.tar.gz) | f65bd9241c7eb88a4886a285330f732448570aea4ededaebeabcf70d17ea185f51bf8a7218f146ee09fb1adceca7ee71fb3c3683834f2c415163add820fba96e -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-linux-ppc64le.tar.gz) | 1e377599af100a81d027d9199365fb8208d443a8e0a97affff1a79dc18796e14b78cb53d6e245c1c1e8defd0e050e37bf5f2a23c8a3ff45a6d18d03619709bf5 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-linux-s390x.tar.gz) | 1cdee81478246aa7e7b80ae4efc7f070a5b058083ae278f59fad088b75a8052761b0e15ab261a6e667ddafd6a69fb424fc307072ed47941cad89a85af7aee93d -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-windows-386.tar.gz) | d8774167c87b6844c348aa15e92d5033c528d6ab9e95d08a7cb22da68bafd8e46d442cf57a5f6affad62f674c10ae6947d524b94108b5e450ca78f92656d63c0 -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-windows-amd64.tar.gz) | f664b47d8daa6036f8154c1dc1f881bfe683bf57c39d9b491de3848c03d051c50c6644d681baf7f9685eae45f9ce62e4c6dfea2853763cfe8256a61bdd59d894 - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-server-linux-amd64.tar.gz) | d6fcb4600be0beb9de222a8da64c35fe22798a0da82d41401d34d0f0fc7e2817512169524c281423d8f4a007cd77452d966317d5a1b67d2717a05ff346e8aa7d -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-server-linux-arm.tar.gz) | 022a76cf10801f8afbabb509572479b68fdb4e683526fa0799cdbd9bab4d3f6ecb76d1d63d0eafee93e3edf6c12892d84b9c771ef2325663b95347728fa3d6c0 -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-server-linux-arm64.tar.gz) | 0679aadd60bbf6f607e5befad74b5267eb2d4c1b55985cc25a97e0f4c5efb7acbb3ede91bfa6a5a5713dae4d7a302f6faaf678fd6b359284c33d9a6aca2a08bb -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-server-linux-ppc64le.tar.gz) | 9f2cfeed543b515eafb60d9765a3afff4f3d323c0a5c8a0d75e3de25985b2627817bfcbe59a9a61d969e026e2b861adb974a09eae75b58372ed736ceaaed2a82 -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-server-linux-s390x.tar.gz) | 937258704d7b9dcd91f35f2d34ee9dd38c18d9d4e867408c05281bfbbb919ad012c95880bee84d2674761aa44cc617fb2fae1124cf63b689289286d6eac1c407 - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-node-linux-amd64.tar.gz) | 076165d745d47879de68f4404eaf432920884be48277eb409e84bf2c61759633bf3575f46b0995f1fc693023d76c0921ed22a01432e756d7f8d9e246a243b126 -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-node-linux-arm.tar.gz) | 1ff2e2e3e43af41118cdfb70c778e15035bbb1aca833ffd2db83c4bcd44f55693e956deb9e65017ebf3c553f2820ad5cd05f5baa33f3d63f3e00ed980ea4dfed -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-node-linux-arm64.tar.gz) | b232c7359b8c635126899beee76998078eec7a1ef6758d92bcdebe8013b0b1e4d7b33ecbf35e3f82824fe29493400845257e70ed63c1635bfa36c8b3b4969f6f -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-node-linux-ppc64le.tar.gz) | 51d415a068f554840f4c78d11a4fedebd7cb03c686b0ec864509b24f7a8667ebf54bb0a25debcf2b70f38be1e345e743f520695b11806539a55a3620ce21946f -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-node-linux-s390x.tar.gz) | b51c082d8af358233a088b632cf2f6c8cfe5421471c27f5dc9ba4839ae6ea75df25d84298f2042770097554c01742bb7686694b331ad9bafc93c86317b867728 -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-node-windows-amd64.tar.gz) | 91b9d26620a2dde67a0edead0039814efccbdfd54594dda3597aaced6d89140dc92612ed0727bc21d63468efeef77c845e640153b09e39d8b736062e6eee0c76 - -## Changelog since v1.20.0-alpha.1 - -## Changes by Kind - -### Deprecation - -- Action-required: kubeadm: graduate the "kubeadm alpha certs" command to a parent command "kubeadm certs". The command "kubeadm alpha certs" is deprecated and will be removed in a future release. Please migrate. ([#94938](https://github.com/kubernetes/kubernetes/pull/94938), [@yagonobre](https://github.com/yagonobre)) [SIG Cluster Lifecycle] -- Action-required: kubeadm: remove the deprecated feature --experimental-kustomize from kubeadm commands. The feature was replaced with --experimental-patches in 1.19. To migrate see the --help description for the --experimental-patches flag. ([#94871](https://github.com/kubernetes/kubernetes/pull/94871), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: deprecate self-hosting support. The experimental command "kubeadm alpha self-hosting" is now deprecated and will be removed in a future release. ([#95125](https://github.com/kubernetes/kubernetes/pull/95125), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Removes deprecated scheduler metrics DeprecatedSchedulingDuration, DeprecatedSchedulingAlgorithmPredicateEvaluationSecondsDuration, DeprecatedSchedulingAlgorithmPriorityEvaluationSecondsDuration ([#94884](https://github.com/kubernetes/kubernetes/pull/94884), [@arghya88](https://github.com/arghya88)) [SIG Instrumentation and Scheduling] -- Scheduler alpha metrics binding_duration_seconds and scheduling_algorithm_preemption_evaluation_seconds are deprecated, Both of those metrics are now covered as part of framework_extension_point_duration_seconds, the former as a PostFilter the latter and a Bind plugin. The plan is to remove both in 1.21 ([#95001](https://github.com/kubernetes/kubernetes/pull/95001), [@arghya88](https://github.com/arghya88)) [SIG Instrumentation and Scheduling] - -### API Change - -- GPU metrics provided by kubelet are now disabled by default ([#95184](https://github.com/kubernetes/kubernetes/pull/95184), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Node] -- New parameter `defaultingType` for `PodTopologySpread` plugin allows to use k8s defined or user provided default constraints ([#95048](https://github.com/kubernetes/kubernetes/pull/95048), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- Server Side Apply now treats LabelSelector fields as atomic (meaning the entire selector is managed by a single writer and updated together), since they contain interrelated and inseparable fields that do not merge in intuitive ways. ([#93901](https://github.com/kubernetes/kubernetes/pull/93901), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Storage and Testing] -- Status of v1beta1 CRDs without "preserveUnknownFields:false" will show violation "spec.preserveUnknownFields: Invalid value: true: must be false" ([#93078](https://github.com/kubernetes/kubernetes/pull/93078), [@vareti](https://github.com/vareti)) [SIG API Machinery] - -### Feature - -- Added `get-users` and `delete-user` to the `kubectl config` subcommand ([#89840](https://github.com/kubernetes/kubernetes/pull/89840), [@eddiezane](https://github.com/eddiezane)) [SIG CLI] -- Added counter metric "apiserver_request_self" to count API server self-requests with labels for verb, resource, and subresource. ([#94288](https://github.com/kubernetes/kubernetes/pull/94288), [@LogicalShark](https://github.com/LogicalShark)) [SIG API Machinery, Auth, Instrumentation and Scheduling] -- Added new k8s.io/component-helpers repository providing shared helper code for (core) components. ([#92507](https://github.com/kubernetes/kubernetes/pull/92507), [@ingvagabund](https://github.com/ingvagabund)) [SIG Apps, Node, Release and Scheduling] -- Adds `create ingress` command to `kubectl` ([#78153](https://github.com/kubernetes/kubernetes/pull/78153), [@amimof](https://github.com/amimof)) [SIG CLI and Network] -- Allow configuring AWS LoadBalancer health check protocol via service annotations ([#94546](https://github.com/kubernetes/kubernetes/pull/94546), [@kishorj](https://github.com/kishorj)) [SIG Cloud Provider] -- Azure: Support multiple services sharing one IP address ([#94991](https://github.com/kubernetes/kubernetes/pull/94991), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Ephemeral containers now apply the same API defaults as initContainers and containers ([#94896](https://github.com/kubernetes/kubernetes/pull/94896), [@wawa0210](https://github.com/wawa0210)) [SIG Apps and CLI] -- In dual-stack bare-metal clusters, you can now pass dual-stack IPs to `kubelet --node-ip`. - eg: `kubelet --node-ip 10.1.0.5,fd01::0005`. This is not yet supported for non-bare-metal - clusters. - - In dual-stack clusters where nodes have dual-stack addresses, hostNetwork pods - will now get dual-stack PodIPs. ([#95239](https://github.com/kubernetes/kubernetes/pull/95239), [@danwinship](https://github.com/danwinship)) [SIG Network and Node] -- Introduces a new GCE specific cluster creation variable KUBE_PROXY_DISABLE. When set to true, this will skip over the creation of kube-proxy (whether the daemonset or static pod). This can be used to control the lifecycle of kube-proxy separately from the lifecycle of the nodes. ([#91977](https://github.com/kubernetes/kubernetes/pull/91977), [@varunmar](https://github.com/varunmar)) [SIG Cloud Provider] -- Kubeadm: do not throw errors if the current system time is outside of the NotBefore and NotAfter bounds of a loaded certificate. Print warnings instead. ([#94504](https://github.com/kubernetes/kubernetes/pull/94504), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: make the command "kubeadm alpha kubeconfig user" accept a "--config" flag and remove the following flags: - - apiserver-advertise-address / apiserver-bind-port: use either localAPIEndpoint from InitConfiguration or controlPlaneEndpoint from ClusterConfiguration. - - cluster-name: use clusterName from ClusterConfiguration - - cert-dir: use certificatesDir from ClusterConfiguration ([#94879](https://github.com/kubernetes/kubernetes/pull/94879), [@knight42](https://github.com/knight42)) [SIG Cluster Lifecycle] -- Kubectl rollout history sts/sts-name --revision=some-revision will start showing the detailed view of the sts on that specified revision ([#86506](https://github.com/kubernetes/kubernetes/pull/86506), [@dineshba](https://github.com/dineshba)) [SIG CLI] -- Scheduling Framework: expose Run[Pre]ScorePlugins functions to PreemptionHandle which can be used in PostFilter extention point. ([#93534](https://github.com/kubernetes/kubernetes/pull/93534), [@everpeace](https://github.com/everpeace)) [SIG Scheduling and Testing] -- Send gce node startup scripts logs to console and journal ([#95311](https://github.com/kubernetes/kubernetes/pull/95311), [@karan](https://github.com/karan)) [SIG Cloud Provider and Node] -- Support kubectl delete orphan/foreground/background options ([#93384](https://github.com/kubernetes/kubernetes/pull/93384), [@zhouya0](https://github.com/zhouya0)) [SIG CLI and Testing] - -### Bug or Regression - -- Change the mount way from systemd to normal mount except ceph and glusterfs intree-volume. ([#94916](https://github.com/kubernetes/kubernetes/pull/94916), [@smileusd](https://github.com/smileusd)) [SIG Apps, Cloud Provider, Network, Node, Storage and Testing] -- Cloud node controller: handle empty providerID from getProviderID ([#95342](https://github.com/kubernetes/kubernetes/pull/95342), [@nicolehanjing](https://github.com/nicolehanjing)) [SIG Cloud Provider] -- Fix a bug where the endpoint slice controller was not mirroring the parent service labels to its corresponding endpoint slices ([#94443](https://github.com/kubernetes/kubernetes/pull/94443), [@aojea](https://github.com/aojea)) [SIG Apps and Network] -- Fix azure disk attach failure for disk size bigger than 4TB ([#95463](https://github.com/kubernetes/kubernetes/pull/95463), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix azure disk data loss issue on Windows when unmount disk ([#95456](https://github.com/kubernetes/kubernetes/pull/95456), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fix detach azure disk issue when vm not exist ([#95177](https://github.com/kubernetes/kubernetes/pull/95177), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix network_programming_latency metric reporting for Endpoints/EndpointSlice deletions, where we don't have correct timestamp ([#95363](https://github.com/kubernetes/kubernetes/pull/95363), [@wojtek-t](https://github.com/wojtek-t)) [SIG Network and Scalability] -- Fix scheduler cache snapshot when a Node is deleted before its Pods ([#95130](https://github.com/kubernetes/kubernetes/pull/95130), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- Fix vsphere detach failure for static PVs ([#95447](https://github.com/kubernetes/kubernetes/pull/95447), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage] -- Fixed a bug that prevents the use of ephemeral containers in the presence of a validating admission webhook. ([#94685](https://github.com/kubernetes/kubernetes/pull/94685), [@verb](https://github.com/verb)) [SIG Node and Testing] -- Gracefully delete nodes when their parent scale set went missing ([#95289](https://github.com/kubernetes/kubernetes/pull/95289), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider] -- In dual-stack clusters, kubelet will now set up both IPv4 and IPv6 iptables rules, which may - fix some problems, eg with HostPorts. ([#94474](https://github.com/kubernetes/kubernetes/pull/94474), [@danwinship](https://github.com/danwinship)) [SIG Network and Node] -- Kubeadm: for Docker as the container runtime, make the "kubeadm reset" command stop containers before removing them ([#94586](https://github.com/kubernetes/kubernetes/pull/94586), [@BedivereZero](https://github.com/BedivereZero)) [SIG Cluster Lifecycle] -- Kubeadm: warn but do not error out on missing "ca.key" files for root CA, front-proxy CA and etcd CA, during "kubeadm join --control-plane" if the user has provided all certificates, keys and kubeconfig files which require signing with the given CA keys. ([#94988](https://github.com/kubernetes/kubernetes/pull/94988), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Port mapping allows to map the same `containerPort` to multiple `hostPort` without naming the mapping explicitly. ([#94494](https://github.com/kubernetes/kubernetes/pull/94494), [@SergeyKanzhelev](https://github.com/SergeyKanzhelev)) [SIG Network and Node] -- Warn instead of fail when creating Roles and ClusterRoles with custom verbs via kubectl ([#92492](https://github.com/kubernetes/kubernetes/pull/92492), [@eddiezane](https://github.com/eddiezane)) [SIG CLI] - -### Other (Cleanup or Flake) - -- Added fine grained debugging to the intra-pod conformance test for helping easily resolve networking issues for nodes that might be unhealthy when running conformance or sonobuoy tests. ([#93837](https://github.com/kubernetes/kubernetes/pull/93837), [@jayunit100](https://github.com/jayunit100)) [SIG Network and Testing] -- AdmissionReview objects sent for the creation of Namespace API objects now populate the `namespace` attribute consistently (previously the `namespace` attribute was empty for Namespace creation via POST requests, and populated for Namespace creation via server-side-apply PATCH requests) ([#95012](https://github.com/kubernetes/kubernetes/pull/95012), [@nodo](https://github.com/nodo)) [SIG API Machinery and Testing] -- Client-go header logging (at verbosity levels >= 9) now masks `Authorization` header contents ([#95316](https://github.com/kubernetes/kubernetes/pull/95316), [@sfowl](https://github.com/sfowl)) [SIG API Machinery] -- Enhance log information of verifyRunAsNonRoot, add pod, container information ([#94911](https://github.com/kubernetes/kubernetes/pull/94911), [@wawa0210](https://github.com/wawa0210)) [SIG Node] -- Errors from staticcheck: - vendor/k8s.io/client-go/discovery/cached/memory/memcache_test.go:94:2: this value of g is never used (SA4006) ([#95098](https://github.com/kubernetes/kubernetes/pull/95098), [@phunziker](https://github.com/phunziker)) [SIG API Machinery] -- Kubeadm: update the default pause image version to 1.4.0 on Windows. With this update the image supports Windows versions 1809 (2019LTS), 1903, 1909, 2004 ([#95419](https://github.com/kubernetes/kubernetes/pull/95419), [@jsturtevant](https://github.com/jsturtevant)) [SIG Cluster Lifecycle and Windows] -- Masks ceph RBD adminSecrets in logs when logLevel >= 4 ([#95245](https://github.com/kubernetes/kubernetes/pull/95245), [@sfowl](https://github.com/sfowl)) [SIG Storage] -- Upgrade snapshot controller to 3.0.0 ([#95412](https://github.com/kubernetes/kubernetes/pull/95412), [@saikat-royc](https://github.com/saikat-royc)) [SIG Cloud Provider] -- Remove offensive words from kubectl cluster-info command ([#95202](https://github.com/kubernetes/kubernetes/pull/95202), [@rikatz](https://github.com/rikatz)) [SIG Architecture, CLI and Testing] -- The following new metrics are available. - - network_plugin_operations_total - - network_plugin_operations_errors_total ([#93066](https://github.com/kubernetes/kubernetes/pull/93066), [@AnishShah](https://github.com/AnishShah)) [SIG Instrumentation, Network and Node] -- Vsphere: improve logging message on node cache refresh event ([#95236](https://github.com/kubernetes/kubernetes/pull/95236), [@andrewsykim](https://github.com/andrewsykim)) [SIG Cloud Provider] -- `kubectl api-resources` now prints the API version (as 'API group/version', same as output of `kubectl api-versions`). The column APIGROUP is now APIVERSION ([#95253](https://github.com/kubernetes/kubernetes/pull/95253), [@sallyom](https://github.com/sallyom)) [SIG CLI] - -## Dependencies - -### Added -- github.com/jmespath/go-jmespath/internal/testify: [v1.5.1](https://github.com/jmespath/go-jmespath/internal/testify/tree/v1.5.1) - -### Changed -- github.com/aws/aws-sdk-go: [v1.28.2 → v1.35.5](https://github.com/aws/aws-sdk-go/compare/v1.28.2...v1.35.5) -- github.com/jmespath/go-jmespath: [c2b33e8 → v0.4.0](https://github.com/jmespath/go-jmespath/compare/c2b33e8...v0.4.0) -- k8s.io/kube-openapi: 6aeccd4 → 8b50664 -- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.9 → v0.0.12 -- sigs.k8s.io/structured-merge-diff/v4: v4.0.1 → b3cf1e8 - -### Removed -_Nothing has changed._ - - - -# v1.20.0-alpha.1 - - -## Downloads for v1.20.0-alpha.1 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes.tar.gz) | e7daed6502ea07816274f2371f96fe1a446d0d7917df4454b722d9eb3b5ff6163bfbbd5b92dfe7a0c1d07328b8c09c4ae966e482310d6b36de8813aaf87380b5 -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-src.tar.gz) | e91213a0919647a1215d4691a63b12d89a3e74055463a8ebd71dc1a4cabf4006b3660881067af0189960c8dab74f4a7faf86f594df69021901213ee5b56550ea - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-darwin-amd64.tar.gz) | 1f3add5f826fa989820d715ca38e8864b66f30b59c1abeacbb4bfb96b4e9c694eac6b3f4c1c81e0ee3451082d44828cb7515315d91ad68116959a5efbdaef1e1 -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-linux-386.tar.gz) | c62acdc8993b0a950d4b0ce0b45473bf96373d501ce61c88adf4007afb15c1d53da8d53b778a7eccac6c1624f7fdda322be9f3a8bc2d80aaad7b4237c39f5eaf -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-linux-amd64.tar.gz) | 1203ababfe00f9bc5be5c059324c17160a96530c1379a152db33564bbe644ccdb94b30eea15a0655bd652efb17895a46c31bbba19d4f5f473c2a0ff62f6e551f -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-linux-arm.tar.gz) | 31860088596e12d739c7aed94556c2d1e217971699b950c8417a3cea1bed4e78c9ff1717b9f3943354b75b4641d4b906cd910890dbf4278287c0d224837d9a7d -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-linux-arm64.tar.gz) | 8d469f37fe20d6e15b5debc13cce4c22e8b7a4f6a4ac787006b96507a85ce761f63b28140d692c54b5f7deb08697f8d5ddb9bbfa8f5ac0d9241fc7de3a3fe3cd -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-linux-ppc64le.tar.gz) | 0d62ee1729cd5884946b6c73701ad3a570fa4d642190ca0fe5c1db0fb0cba9da3ac86a948788d915b9432d28ab8cc499e28aadc64530b7d549ee752a6ed93ec1 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-linux-s390x.tar.gz) | 0fc0420e134ec0b8e0ab2654e1e102cebec47b48179703f1e1b79d51ee0d6da55a4e7304d8773d3cf830341ac2fe3cede1e6b0460fd88f7595534e0730422d5a -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-windows-386.tar.gz) | 3fb53b5260f4888c77c0e4ff602bbcf6bf38c364d2769850afe2b8d8e8b95f7024807c15e2b0d5603e787c46af8ac53492be9e88c530f578b8a389e3bd50c099 -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-windows-amd64.tar.gz) | 2f44c93463d6b5244ce0c82f147e7f32ec2233d0e29c64c3c5759e23533aebd12671bf63e986c0861e9736f9b5259bb8d138574a7c8c8efc822e35cd637416c0 - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-server-linux-amd64.tar.gz) | ae82d14b1214e4100f0cc2c988308b3e1edd040a65267d0eddb9082409f79644e55387889e3c0904a12c710f91206e9383edf510990bee8c9ea2e297b6472551 -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-server-linux-arm.tar.gz) | 9a2a5828b7d1ddb16cc19d573e99a4af642f84129408e6203eeeb0558e7b8db77f3269593b5770b6a976fe9df4a64240ed27ad05a4bd43719e55fce1db0abf58 -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-server-linux-arm64.tar.gz) | ed700dd226c999354ce05b73927388d36d08474c15333ae689427de15de27c84feb6b23c463afd9dd81993315f31eb8265938cfc7ecf6f750247aa42b9b33fa9 -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-server-linux-ppc64le.tar.gz) | abb7a9d726538be3ccf5057a0c63ff9732b616e213c6ebb81363f0c49f1e168ce8068b870061ad7cba7ba1d49252f94cf00a5f68cec0f38dc8fce4e24edc5ca6 -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-server-linux-s390x.tar.gz) | 3a51888af1bfdd2d5b0101d173ee589c1f39240e4428165f5f85c610344db219625faa42f00a49a83ce943fb079be873b1a114a62003fae2f328f9bf9d1227a4 - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-node-linux-amd64.tar.gz) | d0f28e3c38ca59a7ff1bfecb48a1ce97116520355d9286afdca1200d346c10018f5bbdf890f130a388654635a2e83e908b263ed45f8a88defca52a7c1d0a7984 -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-node-linux-arm.tar.gz) | ed9d3f13028beb3be39bce980c966f82c4b39dc73beaae38cc075fea5be30b0309e555cb2af8196014f2cc9f0df823354213c314b4d6545ff6e30dd2d00ec90e -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-node-linux-arm64.tar.gz) | ad5b3268db365dcdded9a9a4bffc90c7df0f844000349accdf2b8fb5f1081e553de9b9e9fb25d5e8a4ef7252d51fa94ef94d36d2ab31d157854e164136f662c2 -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-node-linux-ppc64le.tar.gz) | c4de2524e513996def5eeba7b83f7b406f17eaf89d4d557833a93bd035348c81fa9375dcd5c27cfcc55d73995449fc8ee504be1b3bd7b9f108b0b2f153cb05ae -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-node-linux-s390x.tar.gz) | 9157b44e3e7bd5478af9f72014e54d1afa5cd19b984b4cd8b348b312c385016bb77f29db47f44aea08b58abf47d8a396b92a2d0e03f2fe8acdd30f4f9466cbdb -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-node-windows-amd64.tar.gz) | 8b40a43c5e6447379ad2ee8aac06e8028555e1b370a995f6001018a62411abe5fbbca6060b3d1682c5cadc07a27d49edd3204e797af46368800d55f4ca8aa1de - -## Changelog since v1.20.0-alpha.0 - -## Urgent Upgrade Notes - -### (No, really, you MUST read this before you upgrade) - - - Azure blob disk feature(`kind`: `Shared`, `Dedicated`) has been deprecated, you should use `kind`: `Managed` in `kubernetes.io/azure-disk` storage class. ([#92905](https://github.com/kubernetes/kubernetes/pull/92905), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] - - CVE-2020-8559 (Medium): Privilege escalation from compromised node to cluster. See https://github.com/kubernetes/kubernetes/issues/92914 for more details. - The API Server will no longer proxy non-101 responses for upgrade requests. This could break proxied backends (such as an extension API server) that respond to upgrade requests with a non-101 response code. ([#92941](https://github.com/kubernetes/kubernetes/pull/92941), [@tallclair](https://github.com/tallclair)) [SIG API Machinery] - -## Changes by Kind - -### Deprecation - -- Kube-apiserver: the componentstatus API is deprecated. This API provided status of etcd, kube-scheduler, and kube-controller-manager components, but only worked when those components were local to the API server, and when kube-scheduler and kube-controller-manager exposed unsecured health endpoints. Instead of this API, etcd health is included in the kube-apiserver health check and kube-scheduler/kube-controller-manager health checks can be made directly against those components' health endpoints. ([#93570](https://github.com/kubernetes/kubernetes/pull/93570), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Cluster Lifecycle] -- Kubeadm: deprecate the "kubeadm alpha kubelet config enable-dynamic" command. To continue using the feature please defer to the guide for "Dynamic Kubelet Configuration" at k8s.io. ([#92881](https://github.com/kubernetes/kubernetes/pull/92881), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: remove the deprecated "kubeadm alpha kubelet config enable-dynamic" command. To continue using the feature please defer to the guide for "Dynamic Kubelet Configuration" at k8s.io. This change also removes the parent command "kubeadm alpha kubelet" as there are no more sub-commands under it for the time being. ([#94668](https://github.com/kubernetes/kubernetes/pull/94668), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: remove the deprecated --kubelet-config flag for the command "kubeadm upgrade node" ([#94869](https://github.com/kubernetes/kubernetes/pull/94869), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubelet's deprecated endpoint `metrics/resource/v1alpha1` has been removed, please adopt to `metrics/resource`. ([#94272](https://github.com/kubernetes/kubernetes/pull/94272), [@RainbowMango](https://github.com/RainbowMango)) [SIG Instrumentation and Node] -- The v1alpha1 PodPreset API and admission plugin has been removed with no built-in replacement. Admission webhooks can be used to modify pods on creation. ([#94090](https://github.com/kubernetes/kubernetes/pull/94090), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Apps, CLI, Cloud Provider, Scalability and Testing] - -### API Change - -- A new `nofuzz` go build tag now disables gofuzz support. Release binaries enable this. ([#92491](https://github.com/kubernetes/kubernetes/pull/92491), [@BenTheElder](https://github.com/BenTheElder)) [SIG API Machinery] -- A new alpha-level field, `SupportsFsGroup`, has been introduced for CSIDrivers to allow them to specify whether they support volume ownership and permission modifications. The `CSIVolumeSupportFSGroup` feature gate must be enabled to allow this field to be used. ([#92001](https://github.com/kubernetes/kubernetes/pull/92001), [@huffmanca](https://github.com/huffmanca)) [SIG API Machinery, CLI and Storage] -- Added pod version skew strategy for seccomp profile to synchronize the deprecated annotations with the new API Server fields. Please see the corresponding section [in the KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md#version-skew-strategy) for more detailed explanations. ([#91408](https://github.com/kubernetes/kubernetes/pull/91408), [@saschagrunert](https://github.com/saschagrunert)) [SIG Apps, Auth, CLI and Node] -- Adds the ability to disable Accelerator/GPU metrics collected by Kubelet ([#91930](https://github.com/kubernetes/kubernetes/pull/91930), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Node] -- Custom Endpoints are now mirrored to EndpointSlices by a new EndpointSliceMirroring controller. ([#91637](https://github.com/kubernetes/kubernetes/pull/91637), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, Auth, Cloud Provider, Instrumentation, Network and Testing] -- External facing API podresources is now available under k8s.io/kubelet/pkg/apis/ ([#92632](https://github.com/kubernetes/kubernetes/pull/92632), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Node and Testing] -- Fix conversions for custom metrics. ([#94481](https://github.com/kubernetes/kubernetes/pull/94481), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Instrumentation] -- Generic ephemeral volumes, a new alpha feature under the `GenericEphemeralVolume` feature gate, provide a more flexible alternative to `EmptyDir` volumes: as with `EmptyDir`, volumes are created and deleted for each pod automatically by Kubernetes. But because the normal provisioning process is used (`PersistentVolumeClaim`), storage can be provided by third-party storage vendors and all of the usual volume features work. Volumes don't need to be empt; for example, restoring from snapshot is supported. ([#92784](https://github.com/kubernetes/kubernetes/pull/92784), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Auth, CLI, Instrumentation, Node, Scheduling, Storage and Testing] -- Kube-controller-manager: volume plugins can be restricted from contacting local and loopback addresses by setting `--volume-host-allow-local-loopback=false`, or from contacting specific CIDR ranges by setting `--volume-host-cidr-denylist` (for example, `--volume-host-cidr-denylist=127.0.0.1/28,feed::/16`) ([#91785](https://github.com/kubernetes/kubernetes/pull/91785), [@mattcary](https://github.com/mattcary)) [SIG API Machinery, Apps, Auth, CLI, Network, Node, Storage and Testing] -- Kubernetes is now built with golang 1.15.0-rc.1. - - The deprecated, legacy behavior of treating the CommonName field on X.509 serving certificates as a host name when no Subject Alternative Names are present is now disabled by default. It can be temporarily re-enabled by adding the value x509ignoreCN=0 to the GODEBUG environment variable. ([#93264](https://github.com/kubernetes/kubernetes/pull/93264), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Release, Scalability, Storage and Testing] -- Migrate scheduler, controller-manager and cloud-controller-manager to use LeaseLock ([#94603](https://github.com/kubernetes/kubernetes/pull/94603), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, Apps, Cloud Provider and Scheduling] -- Modify DNS-1123 error messages to indicate that RFC 1123 is not followed exactly ([#94182](https://github.com/kubernetes/kubernetes/pull/94182), [@mattfenwick](https://github.com/mattfenwick)) [SIG API Machinery, Apps, Auth, Network and Node] -- The ServiceAccountIssuerDiscovery feature gate is now Beta and enabled by default. ([#91921](https://github.com/kubernetes/kubernetes/pull/91921), [@mtaufen](https://github.com/mtaufen)) [SIG Auth] -- The kube-controller-manager managed signers can now have distinct signing certificates and keys. See the help about `--cluster-signing-[signer-name]-{cert,key}-file`. `--cluster-signing-{cert,key}-file` is still the default. ([#90822](https://github.com/kubernetes/kubernetes/pull/90822), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Apps and Auth] -- When creating a networking.k8s.io/v1 Ingress API object, `spec.tls[*].secretName` values are required to pass validation rules for Secret API object names. ([#93929](https://github.com/kubernetes/kubernetes/pull/93929), [@liggitt](https://github.com/liggitt)) [SIG Network] -- WinOverlay feature graduated to beta ([#94807](https://github.com/kubernetes/kubernetes/pull/94807), [@ksubrmnn](https://github.com/ksubrmnn)) [SIG Windows] - -### Feature - -- ACTION REQUIRED : In CoreDNS v1.7.0, [metrics names have been changed](https://github.com/coredns/coredns/blob/master/notes/coredns-1.7.0.md#metric-changes) which will be backward incompatible with existing reporting formulas that use the old metrics' names. Adjust your formulas to the new names before upgrading. - - Kubeadm now includes CoreDNS version v1.7.0. Some of the major changes include: - - Fixed a bug that could cause CoreDNS to stop updating service records. - - Fixed a bug in the forward plugin where only the first upstream server is always selected no matter which policy is set. - - Remove already deprecated options `resyncperiod` and `upstream` in the Kubernetes plugin. - - Includes Prometheus metrics name changes (to bring them in line with standard Prometheus metrics naming convention). They will be backward incompatible with existing reporting formulas that use the old metrics' names. - - The federation plugin (allows for v1 Kubernetes federation) has been removed. - More details are available in https://coredns.io/2020/06/15/coredns-1.7.0-release/ ([#92651](https://github.com/kubernetes/kubernetes/pull/92651), [@rajansandeep](https://github.com/rajansandeep)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation] -- Add metrics for azure service operations (route and loadbalancer). ([#94124](https://github.com/kubernetes/kubernetes/pull/94124), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider and Instrumentation] -- Add network rule support in Azure account creation ([#94239](https://github.com/kubernetes/kubernetes/pull/94239), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Add tags support for Azure File Driver ([#92825](https://github.com/kubernetes/kubernetes/pull/92825), [@ZeroMagic](https://github.com/ZeroMagic)) [SIG Cloud Provider and Storage] -- Added kube-apiserver metrics: apiserver_current_inflight_request_measures and, when API Priority and Fairness is enable, windowed_request_stats. ([#91177](https://github.com/kubernetes/kubernetes/pull/91177), [@MikeSpreitzer](https://github.com/MikeSpreitzer)) [SIG API Machinery, Instrumentation and Testing] -- Audit events for API requests to deprecated API versions now include a `"k8s.io/deprecated": "true"` audit annotation. If a target removal release is identified, the audit event includes a `"k8s.io/removal-release": "."` audit annotation as well. ([#92842](https://github.com/kubernetes/kubernetes/pull/92842), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Instrumentation] -- Cloud node-controller use InstancesV2 ([#91319](https://github.com/kubernetes/kubernetes/pull/91319), [@gongguan](https://github.com/gongguan)) [SIG Apps, Cloud Provider, Scalability and Storage] -- Kubeadm: Add a preflight check that the control-plane node has at least 1700MB of RAM ([#93275](https://github.com/kubernetes/kubernetes/pull/93275), [@xlgao-zju](https://github.com/xlgao-zju)) [SIG Cluster Lifecycle] -- Kubeadm: add the "--cluster-name" flag to the "kubeadm alpha kubeconfig user" to allow configuring the cluster name in the generated kubeconfig file ([#93992](https://github.com/kubernetes/kubernetes/pull/93992), [@prabhu43](https://github.com/prabhu43)) [SIG Cluster Lifecycle] -- Kubeadm: add the "--kubeconfig" flag to the "kubeadm init phase upload-certs" command to allow users to pass a custom location for a kubeconfig file. ([#94765](https://github.com/kubernetes/kubernetes/pull/94765), [@zhanw15](https://github.com/zhanw15)) [SIG Cluster Lifecycle] -- Kubeadm: deprecate the "--csr-only" and "--csr-dir" flags of the "kubeadm init phase certs" subcommands. Please use "kubeadm alpha certs generate-csr" instead. This new command allows you to generate new private keys and certificate signing requests for all the control-plane components, so that the certificates can be signed by an external CA. ([#92183](https://github.com/kubernetes/kubernetes/pull/92183), [@wallrj](https://github.com/wallrj)) [SIG Cluster Lifecycle] -- Kubeadm: make etcd pod request 100m CPU, 100Mi memory and 100Mi ephemeral_storage by default ([#94479](https://github.com/kubernetes/kubernetes/pull/94479), [@knight42](https://github.com/knight42)) [SIG Cluster Lifecycle] -- Kubemark now supports both real and hollow nodes in a single cluster. ([#93201](https://github.com/kubernetes/kubernetes/pull/93201), [@ellistarn](https://github.com/ellistarn)) [SIG Scalability] -- Kubernetes is now built using go1.15.2 - - build: Update to k/repo-infra@v0.1.1 (supports go1.15.2) - - build: Use go-runner:buster-v2.0.1 (built using go1.15.1) - - bazel: Replace --features with Starlark build settings flag - - hack/lib/util.sh: some bash cleanups - - - switched one spot to use kube::logging - - make kube::util::find-binary return an error when it doesn't find - anything so that hack scripts fail fast instead of with '' binary not - found errors. - - this required deleting some genfeddoc stuff. the binary no longer - exists in k/k repo since we removed federation/, and I don't see it - in https://github.com/kubernetes-sigs/kubefed/ either. I'm assuming - that it's gone for good now. - - - bazel: output go_binary rule directly from go_binary_conditional_pure - - From: @mikedanese: - Instead of aliasing. Aliases are annoying in a number of ways. This is - specifically bugging me now because they make the action graph harder to - analyze programmatically. By using aliases here, we would need to handle - potentially aliased go_binary targets and dereference to the effective - target. - - The comment references an issue with `pure = select(...)` which appears - to be resolved considering this now builds. - - - make kube::util::find-binary not dependent on bazel-out/ structure - - Implement an aspect that outputs go_build_mode metadata for go binaries, - and use that during binary selection. ([#94449](https://github.com/kubernetes/kubernetes/pull/94449), [@justaugustus](https://github.com/justaugustus)) [SIG Architecture, CLI, Cluster Lifecycle, Node, Release and Testing] -- Only update Azure data disks when attach/detach ([#94265](https://github.com/kubernetes/kubernetes/pull/94265), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Promote SupportNodePidsLimit to GA to provide node to pod pid isolation - Promote SupportPodPidsLimit to GA to provide ability to limit pids per pod ([#94140](https://github.com/kubernetes/kubernetes/pull/94140), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG Node and Testing] -- Rename pod_preemption_metrics to preemption_metrics. ([#93256](https://github.com/kubernetes/kubernetes/pull/93256), [@ahg-g](https://github.com/ahg-g)) [SIG Instrumentation and Scheduling] -- Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a `replicas` field from a user to an HPA without resetting to the default value are documented in [Transferring Ownership](/docs/reference/using-api/server-side-apply/#transferring-ownership) ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing] -- Set CSIMigrationvSphere feature gates to beta. - Users should enable CSIMigration + CSIMigrationvSphere features and install the vSphere CSI Driver (https://github.com/kubernetes-sigs/vsphere-csi-driver) to move workload from the in-tree vSphere plugin "kubernetes.io/vsphere-volume" to vSphere CSI Driver. - - Requires: vSphere vCenter/ESXi Version: 7.0u1, HW Version: VM version 15 ([#92816](https://github.com/kubernetes/kubernetes/pull/92816), [@divyenpatel](https://github.com/divyenpatel)) [SIG Cloud Provider and Storage] -- Support [service.beta.kubernetes.io/azure-pip-ip-tags] annotations to allow customers to specify ip-tags to influence public-ip creation in Azure [Tag1=Value1, Tag2=Value2, etc.] ([#94114](https://github.com/kubernetes/kubernetes/pull/94114), [@MarcPow](https://github.com/MarcPow)) [SIG Cloud Provider] -- Support a smooth upgrade from client-side apply to server-side apply without conflicts, as well as support the corresponding downgrade. ([#90187](https://github.com/kubernetes/kubernetes/pull/90187), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery and Testing] -- Trace output in apiserver logs is more organized and comprehensive. Traces are nested, and for all non-long running request endpoints, the entire filter chain is instrumented (e.g. authentication check is included). ([#88936](https://github.com/kubernetes/kubernetes/pull/88936), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Scheduling] -- `kubectl alpha debug` now supports debugging nodes by creating a debugging container running in the node's host namespaces. ([#92310](https://github.com/kubernetes/kubernetes/pull/92310), [@verb](https://github.com/verb)) [SIG CLI] - -### Documentation - -- Kubelet: remove alpha warnings for CNI flags. ([#94508](https://github.com/kubernetes/kubernetes/pull/94508), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network and Node] - -### Failing Test - -- Kube-proxy iptables min-sync-period defaults to 1 sec. Previously, it was 0. ([#92836](https://github.com/kubernetes/kubernetes/pull/92836), [@aojea](https://github.com/aojea)) [SIG Network] - -### Bug or Regression - -- A panic in the apiserver caused by the `informer-sync` health checker is now fixed. ([#93600](https://github.com/kubernetes/kubernetes/pull/93600), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG API Machinery] -- Add kubectl wait --ignore-not-found flag ([#90969](https://github.com/kubernetes/kubernetes/pull/90969), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] -- Adding fix to the statefulset controller to wait for pvc deletion before creating pods. ([#93457](https://github.com/kubernetes/kubernetes/pull/93457), [@ymmt2005](https://github.com/ymmt2005)) [SIG Apps] -- Azure ARM client: don't segfault on empty response and http error ([#94078](https://github.com/kubernetes/kubernetes/pull/94078), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider] -- Azure: fix a bug that kube-controller-manager would panic if wrong Azure VMSS name is configured ([#94306](https://github.com/kubernetes/kubernetes/pull/94306), [@knight42](https://github.com/knight42)) [SIG Cloud Provider] -- Azure: per VMSS VMSS VMs cache to prevent throttling on clusters having many attached VMSS ([#93107](https://github.com/kubernetes/kubernetes/pull/93107), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider] -- Both apiserver_request_duration_seconds metrics and RequestReceivedTimestamp field of an audit event take - into account the time a request spends in the apiserver request filters. ([#94903](https://github.com/kubernetes/kubernetes/pull/94903), [@tkashem](https://github.com/tkashem)) [SIG API Machinery, Auth and Instrumentation] -- Build/lib/release: Explicitly use '--platform' in building server images - - When we switched to go-runner for building the apiserver, - controller-manager, and scheduler server components, we no longer - reference the individual architectures in the image names, specifically - in the 'FROM' directive of the server image Dockerfiles. - - As a result, server images for non-amd64 images copy in the go-runner - amd64 binary instead of the go-runner that matches that architecture. - - This commit explicitly sets the '--platform=linux/${arch}' to ensure - we're pulling the correct go-runner arch from the manifest list. - - Before: - `FROM ${base_image}` - - After: - `FROM --platform=linux/${arch} ${base_image}` ([#94552](https://github.com/kubernetes/kubernetes/pull/94552), [@justaugustus](https://github.com/justaugustus)) [SIG Release] -- CSIDriver object can be deployed during volume attachment. ([#93710](https://github.com/kubernetes/kubernetes/pull/93710), [@Jiawei0227](https://github.com/Jiawei0227)) [SIG Apps, Node, Storage and Testing] -- CVE-2020-8557 (Medium): Node-local denial of service via container /etc/hosts file. See https://github.com/kubernetes/kubernetes/issues/93032 for more details. ([#92916](https://github.com/kubernetes/kubernetes/pull/92916), [@joelsmith](https://github.com/joelsmith)) [SIG Node] -- Do not add nodes labeled with kubernetes.azure.com/managed=false to backend pool of load balancer. ([#93034](https://github.com/kubernetes/kubernetes/pull/93034), [@matthias50](https://github.com/matthias50)) [SIG Cloud Provider] -- Do not fail sorting empty elements. ([#94666](https://github.com/kubernetes/kubernetes/pull/94666), [@soltysh](https://github.com/soltysh)) [SIG CLI] -- Do not retry volume expansion if CSI driver returns FailedPrecondition error ([#92986](https://github.com/kubernetes/kubernetes/pull/92986), [@gnufied](https://github.com/gnufied)) [SIG Node and Storage] -- Dockershim security: pod sandbox now always run with `no-new-privileges` and `runtime/default` seccomp profile - dockershim seccomp: custom profiles can now have smaller seccomp profiles when set at pod level ([#90948](https://github.com/kubernetes/kubernetes/pull/90948), [@pjbgf](https://github.com/pjbgf)) [SIG Node] -- Dual-stack: make nodeipam compatible with existing single-stack clusters when dual-stack feature gate become enabled by default ([#90439](https://github.com/kubernetes/kubernetes/pull/90439), [@SataQiu](https://github.com/SataQiu)) [SIG API Machinery] -- Endpoint controller requeues service after an endpoint deletion event occurs to confirm that deleted endpoints are undesired to mitigate the effects of an out of sync endpoint cache. ([#93030](https://github.com/kubernetes/kubernetes/pull/93030), [@swetharepakula](https://github.com/swetharepakula)) [SIG Apps and Network] -- EndpointSlice controllers now return immediately if they encounter an error creating, updating, or deleting resources. ([#93908](https://github.com/kubernetes/kubernetes/pull/93908), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- EndpointSliceMirroring controller now copies labels from Endpoints to EndpointSlices. ([#93442](https://github.com/kubernetes/kubernetes/pull/93442), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- EndpointSliceMirroring controller now mirrors Endpoints that do not have a Service associated with them. ([#94171](https://github.com/kubernetes/kubernetes/pull/94171), [@robscott](https://github.com/robscott)) [SIG Apps, Network and Testing] -- Ensure backoff step is set to 1 for Azure armclient. ([#94180](https://github.com/kubernetes/kubernetes/pull/94180), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Ensure getPrimaryInterfaceID not panic when network interfaces for Azure VMSS are null ([#94355](https://github.com/kubernetes/kubernetes/pull/94355), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Eviction requests for pods that have a non-zero DeletionTimestamp will always succeed ([#91342](https://github.com/kubernetes/kubernetes/pull/91342), [@michaelgugino](https://github.com/michaelgugino)) [SIG Apps] -- Extended DSR loadbalancer feature in winkernel kube-proxy to HNS versions 9.3-9.max, 10.2+ ([#93080](https://github.com/kubernetes/kubernetes/pull/93080), [@elweb9858](https://github.com/elweb9858)) [SIG Network] -- Fix HandleCrash order ([#93108](https://github.com/kubernetes/kubernetes/pull/93108), [@lixiaobing1](https://github.com/lixiaobing1)) [SIG API Machinery] -- Fix a concurrent map writes error in kubelet ([#93773](https://github.com/kubernetes/kubernetes/pull/93773), [@knight42](https://github.com/knight42)) [SIG Node] -- Fix a regression where kubeadm bails out with a fatal error when an optional version command line argument is supplied to the "kubeadm upgrade plan" command ([#94421](https://github.com/kubernetes/kubernetes/pull/94421), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle] -- Fix azure file migration panic ([#94853](https://github.com/kubernetes/kubernetes/pull/94853), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix bug where loadbalancer deletion gets stuck because of missing resource group #75198 ([#93962](https://github.com/kubernetes/kubernetes/pull/93962), [@phiphi282](https://github.com/phiphi282)) [SIG Cloud Provider] -- Fix calling AttachDisk on a previously attached EBS volume ([#93567](https://github.com/kubernetes/kubernetes/pull/93567), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider, Storage and Testing] -- Fix detection of image filesystem, disk metrics for devicemapper, detection of OOM Kills on 5.0+ linux kernels. ([#92919](https://github.com/kubernetes/kubernetes/pull/92919), [@dashpole](https://github.com/dashpole)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node] -- Fix etcd_object_counts metric reported by kube-apiserver ([#94773](https://github.com/kubernetes/kubernetes/pull/94773), [@tkashem](https://github.com/tkashem)) [SIG API Machinery] -- Fix incorrectly reported verbs for kube-apiserver metrics for CRD objects ([#93523](https://github.com/kubernetes/kubernetes/pull/93523), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Instrumentation] -- Fix instance not found issues when an Azure Node is recreated in a short time ([#93316](https://github.com/kubernetes/kubernetes/pull/93316), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Fix kube-apiserver /readyz to contain "informer-sync" check ensuring that internal informers are synced. ([#93670](https://github.com/kubernetes/kubernetes/pull/93670), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Testing] -- Fix kubectl SchemaError on CRDs with schema using x-kubernetes-preserve-unknown-fields on array types. ([#94888](https://github.com/kubernetes/kubernetes/pull/94888), [@sttts](https://github.com/sttts)) [SIG API Machinery] -- Fix memory leak in EndpointSliceTracker for EndpointSliceMirroring controller. ([#93441](https://github.com/kubernetes/kubernetes/pull/93441), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- Fix missing csi annotations on node during parallel csinode update. ([#94389](https://github.com/kubernetes/kubernetes/pull/94389), [@pacoxu](https://github.com/pacoxu)) [SIG Storage] -- Fix the `cloudprovider_azure_api_request_duration_seconds` metric buckets to correctly capture the latency metrics. Previously, the majority of the calls would fall in the "+Inf" bucket. ([#94873](https://github.com/kubernetes/kubernetes/pull/94873), [@marwanad](https://github.com/marwanad)) [SIG Cloud Provider and Instrumentation] -- Fix: azure disk resize error if source does not exist ([#93011](https://github.com/kubernetes/kubernetes/pull/93011), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix: detach azure disk broken on Azure Stack ([#94885](https://github.com/kubernetes/kubernetes/pull/94885), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix: determine the correct ip config based on ip family ([#93043](https://github.com/kubernetes/kubernetes/pull/93043), [@aramase](https://github.com/aramase)) [SIG Cloud Provider] -- Fix: initial delay in mounting azure disk & file ([#93052](https://github.com/kubernetes/kubernetes/pull/93052), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fix: use sensitiveOptions on Windows mount ([#94126](https://github.com/kubernetes/kubernetes/pull/94126), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fixed Ceph RBD volume expansion when no ceph.conf exists ([#92027](https://github.com/kubernetes/kubernetes/pull/92027), [@juliantaylor](https://github.com/juliantaylor)) [SIG Storage] -- Fixed a bug where improper storage and comparison of endpoints led to excessive API traffic from the endpoints controller ([#94112](https://github.com/kubernetes/kubernetes/pull/94112), [@damemi](https://github.com/damemi)) [SIG Apps, Network and Testing] -- Fixed a bug whereby the allocation of reusable CPUs and devices was not being honored when the TopologyManager was enabled ([#93189](https://github.com/kubernetes/kubernetes/pull/93189), [@klueska](https://github.com/klueska)) [SIG Node] -- Fixed a panic in kubectl debug when pod has multiple init containers or ephemeral containers ([#94580](https://github.com/kubernetes/kubernetes/pull/94580), [@kiyoshim55](https://github.com/kiyoshim55)) [SIG CLI] -- Fixed a regression that sometimes prevented `kubectl portforward` to work when TCP and UDP services were configured on the same port ([#94728](https://github.com/kubernetes/kubernetes/pull/94728), [@amorenoz](https://github.com/amorenoz)) [SIG CLI] -- Fixed bug in reflector that couldn't recover from "Too large resource version" errors with API servers 1.17.0-1.18.5 ([#94316](https://github.com/kubernetes/kubernetes/pull/94316), [@janeczku](https://github.com/janeczku)) [SIG API Machinery] -- Fixed bug where kubectl top pod output is not sorted when --sort-by and --containers flags are used together ([#93692](https://github.com/kubernetes/kubernetes/pull/93692), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] -- Fixed kubelet creating extra sandbox for pods with RestartPolicyOnFailure after all containers succeeded ([#92614](https://github.com/kubernetes/kubernetes/pull/92614), [@tnqn](https://github.com/tnqn)) [SIG Node and Testing] -- Fixed memory leak in endpointSliceTracker ([#92838](https://github.com/kubernetes/kubernetes/pull/92838), [@tnqn](https://github.com/tnqn)) [SIG Apps and Network] -- Fixed node data lost in kube-scheduler for clusters with imbalance on number of nodes across zones ([#93355](https://github.com/kubernetes/kubernetes/pull/93355), [@maelk](https://github.com/maelk)) [SIG Scheduling] -- Fixed the EndpointSliceController to correctly create endpoints for IPv6-only pods. - - Fixed the EndpointController to allow IPv6 headless services, if the IPv6DualStack - feature gate is enabled, by specifying `ipFamily: IPv6` on the service. (This already - worked with the EndpointSliceController.) ([#91399](https://github.com/kubernetes/kubernetes/pull/91399), [@danwinship](https://github.com/danwinship)) [SIG Apps and Network] -- Fixes a bug evicting pods after a taint with a limited tolerationSeconds toleration is removed from a node ([#93722](https://github.com/kubernetes/kubernetes/pull/93722), [@liggitt](https://github.com/liggitt)) [SIG Apps and Node] -- Fixes a bug where EndpointSlices would not be recreated after rapid Service recreation. ([#94730](https://github.com/kubernetes/kubernetes/pull/94730), [@robscott](https://github.com/robscott)) [SIG Apps, Network and Testing] -- Fixes a race condition in kubelet pod handling ([#94751](https://github.com/kubernetes/kubernetes/pull/94751), [@auxten](https://github.com/auxten)) [SIG Node] -- Fixes an issue proxying to ipv6 pods without specifying a port ([#94834](https://github.com/kubernetes/kubernetes/pull/94834), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Network] -- Fixes an issue that can result in namespaced custom resources being orphaned when their namespace is deleted, if the CRD defining the custom resource is removed concurrently with namespaces being deleted, then recreated. ([#93790](https://github.com/kubernetes/kubernetes/pull/93790), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Apps] -- Ignore root user check when windows pod starts ([#92355](https://github.com/kubernetes/kubernetes/pull/92355), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] -- Increased maximum IOPS of AWS EBS io1 volumes to 64,000 (current AWS maximum). ([#90014](https://github.com/kubernetes/kubernetes/pull/90014), [@jacobmarble](https://github.com/jacobmarble)) [SIG Cloud Provider and Storage] -- K8s.io/apimachinery: runtime.DefaultUnstructuredConverter.FromUnstructured now handles converting integer fields to typed float values ([#93250](https://github.com/kubernetes/kubernetes/pull/93250), [@liggitt](https://github.com/liggitt)) [SIG API Machinery] -- Kube-aggregator certificates are dynamically loaded on change from disk ([#92791](https://github.com/kubernetes/kubernetes/pull/92791), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery] -- Kube-apiserver: fixed a bug returning inconsistent results from list requests which set a field or label selector and set a paging limit ([#94002](https://github.com/kubernetes/kubernetes/pull/94002), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery] -- Kube-apiserver: jsonpath expressions with consecutive recursive descent operators are no longer evaluated for custom resource printer columns ([#93408](https://github.com/kubernetes/kubernetes/pull/93408), [@joelsmith](https://github.com/joelsmith)) [SIG API Machinery] -- Kube-proxy now trims extra spaces found in loadBalancerSourceRanges to match Service validation. ([#94107](https://github.com/kubernetes/kubernetes/pull/94107), [@robscott](https://github.com/robscott)) [SIG Network] -- Kube-up now includes CoreDNS version v1.7.0. Some of the major changes include: - - Fixed a bug that could cause CoreDNS to stop updating service records. - - Fixed a bug in the forward plugin where only the first upstream server is always selected no matter which policy is set. - - Remove already deprecated options `resyncperiod` and `upstream` in the Kubernetes plugin. - - Includes Prometheus metrics name changes (to bring them in line with standard Prometheus metrics naming convention). They will be backward incompatible with existing reporting formulas that use the old metrics' names. - - The federation plugin (allows for v1 Kubernetes federation) has been removed. - More details are available in https://coredns.io/2020/06/15/coredns-1.7.0-release/ ([#92718](https://github.com/kubernetes/kubernetes/pull/92718), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cloud Provider] -- Kubeadm now makes sure the etcd manifest is regenerated upon upgrade even when no etcd version change takes place ([#94395](https://github.com/kubernetes/kubernetes/pull/94395), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle] -- Kubeadm: avoid a panic when determining if the running version of CoreDNS is supported during upgrades ([#94299](https://github.com/kubernetes/kubernetes/pull/94299), [@zouyee](https://github.com/zouyee)) [SIG Cluster Lifecycle] -- Kubeadm: ensure "kubeadm reset" does not unmount the root "/var/lib/kubelet" directory if it is mounted by the user ([#93702](https://github.com/kubernetes/kubernetes/pull/93702), [@thtanaka](https://github.com/thtanaka)) [SIG Cluster Lifecycle] -- Kubeadm: ensure the etcd data directory is created with 0700 permissions during control-plane init and join ([#94102](https://github.com/kubernetes/kubernetes/pull/94102), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: fix the bug that kubeadm tries to call 'docker info' even if the CRI socket was for another CR ([#94555](https://github.com/kubernetes/kubernetes/pull/94555), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] -- Kubeadm: make the kubeconfig files for the kube-controller-manager and kube-scheduler use the LocalAPIEndpoint instead of the ControlPlaneEndpoint. This makes kubeadm clusters more reseliant to version skew problems during immutable upgrades: https://kubernetes.io/docs/setup/release/version-skew-policy/#kube-controller-manager-kube-scheduler-and-cloud-controller-manager ([#94398](https://github.com/kubernetes/kubernetes/pull/94398), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: relax the validation of kubeconfig server URLs. Allow the user to define custom kubeconfig server URLs without erroring out during validation of existing kubeconfig files (e.g. when using external CA mode). ([#94816](https://github.com/kubernetes/kubernetes/pull/94816), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: remove duplicate DNS names and IP addresses from generated certificates ([#92753](https://github.com/kubernetes/kubernetes/pull/92753), [@QianChenglong](https://github.com/QianChenglong)) [SIG Cluster Lifecycle] -- Kubelet: assume that swap is disabled when `/proc/swaps` does not exist ([#93931](https://github.com/kubernetes/kubernetes/pull/93931), [@SataQiu](https://github.com/SataQiu)) [SIG Node] -- Kubelet: fix race condition in pluginWatcher ([#93622](https://github.com/kubernetes/kubernetes/pull/93622), [@knight42](https://github.com/knight42)) [SIG Node] -- Kuberuntime security: pod sandbox now always runs with `runtime/default` seccomp profile - kuberuntime seccomp: custom profiles can now have smaller seccomp profiles when set at pod level ([#90949](https://github.com/kubernetes/kubernetes/pull/90949), [@pjbgf](https://github.com/pjbgf)) [SIG Node] -- NONE ([#71269](https://github.com/kubernetes/kubernetes/pull/71269), [@DeliangFan](https://github.com/DeliangFan)) [SIG Node] -- New Azure instance types do now have correct max data disk count information. ([#94340](https://github.com/kubernetes/kubernetes/pull/94340), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Cloud Provider and Storage] -- Pods with invalid Affinity/AntiAffinity LabelSelectors will now fail scheduling when these plugins are enabled ([#93660](https://github.com/kubernetes/kubernetes/pull/93660), [@damemi](https://github.com/damemi)) [SIG Scheduling] -- Require feature flag CustomCPUCFSQuotaPeriod if setting a non-default cpuCFSQuotaPeriod in kubelet config. ([#94687](https://github.com/kubernetes/kubernetes/pull/94687), [@karan](https://github.com/karan)) [SIG Node] -- Reverted devicemanager for Windows node added in 1.19rc1. ([#93263](https://github.com/kubernetes/kubernetes/pull/93263), [@liggitt](https://github.com/liggitt)) [SIG Node and Windows] -- Scheduler bugfix: Scheduler doesn't lose pod information when nodes are quickly recreated. This could happen when nodes are restarted or quickly recreated reusing a nodename. ([#93938](https://github.com/kubernetes/kubernetes/pull/93938), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scalability, Scheduling and Testing] -- The EndpointSlice controller now waits for EndpointSlice and Node caches to be synced before starting. ([#94086](https://github.com/kubernetes/kubernetes/pull/94086), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- The `/debug/api_priority_and_fairness/dump_requests` path at an apiserver will no longer return a phantom line for each exempt priority level. ([#93406](https://github.com/kubernetes/kubernetes/pull/93406), [@MikeSpreitzer](https://github.com/MikeSpreitzer)) [SIG API Machinery] -- The kubelet recognizes the --containerd-namespace flag to configure the namespace used by cadvisor. ([#87054](https://github.com/kubernetes/kubernetes/pull/87054), [@changyaowei](https://github.com/changyaowei)) [SIG Node] -- The terminationGracePeriodSeconds from pod spec is respected for the mirror pod. ([#92442](https://github.com/kubernetes/kubernetes/pull/92442), [@tedyu](https://github.com/tedyu)) [SIG Node and Testing] -- Update Calico to v3.15.2 ([#94241](https://github.com/kubernetes/kubernetes/pull/94241), [@lmm](https://github.com/lmm)) [SIG Cloud Provider] -- Update default etcd server version to 3.4.13 ([#94287](https://github.com/kubernetes/kubernetes/pull/94287), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cloud Provider, Cluster Lifecycle and Testing] -- Updated Cluster Autoscaler to 1.19.0; ([#93577](https://github.com/kubernetes/kubernetes/pull/93577), [@vivekbagade](https://github.com/vivekbagade)) [SIG Autoscaling and Cloud Provider] -- Use NLB Subnet CIDRs instead of VPC CIDRs in Health Check SG Rules ([#93515](https://github.com/kubernetes/kubernetes/pull/93515), [@t0rr3sp3dr0](https://github.com/t0rr3sp3dr0)) [SIG Cloud Provider] -- Users will see increase in time for deletion of pods and also guarantee that removal of pod from api server would mean deletion of all the resources from container runtime. ([#92817](https://github.com/kubernetes/kubernetes/pull/92817), [@kmala](https://github.com/kmala)) [SIG Node] -- Very large patches may now be specified to `kubectl patch` with the `--patch-file` flag instead of including them directly on the command line. The `--patch` and `--patch-file` flags are mutually exclusive. ([#93548](https://github.com/kubernetes/kubernetes/pull/93548), [@smarterclayton](https://github.com/smarterclayton)) [SIG CLI] -- When creating a networking.k8s.io/v1 Ingress API object, `spec.rules[*].http` values are now validated consistently when the `host` field contains a wildcard. ([#93954](https://github.com/kubernetes/kubernetes/pull/93954), [@Miciah](https://github.com/Miciah)) [SIG CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Storage and Testing] - -### Other (Cleanup or Flake) - -- --cache-dir sets cache directory for both http and discovery, defaults to $HOME/.kube/cache ([#92910](https://github.com/kubernetes/kubernetes/pull/92910), [@soltysh](https://github.com/soltysh)) [SIG API Machinery and CLI] -- Adds a bootstrapping ClusterRole, ClusterRoleBinding and group for /metrics, /livez/*, /readyz/*, & /healthz/- endpoints. ([#93311](https://github.com/kubernetes/kubernetes/pull/93311), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery, Auth, Cloud Provider and Instrumentation] -- Base-images: Update to debian-iptables:buster-v1.3.0 - - Uses iptables 1.8.5 - - base-images: Update to debian-base:buster-v1.2.0 - - cluster/images/etcd: Build etcd:3.4.13-1 image - - Uses debian-base:buster-v1.2.0 ([#94733](https://github.com/kubernetes/kubernetes/pull/94733), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Release and Testing] -- Build: Update to debian-base@v2.1.2 and debian-iptables@v12.1.1 ([#93667](https://github.com/kubernetes/kubernetes/pull/93667), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Release and Testing] -- Build: Update to debian-base@v2.1.3 and debian-iptables@v12.1.2 ([#93916](https://github.com/kubernetes/kubernetes/pull/93916), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Release and Testing] -- Build: Update to go-runner:buster-v2.0.0 ([#94167](https://github.com/kubernetes/kubernetes/pull/94167), [@justaugustus](https://github.com/justaugustus)) [SIG Release] -- Fix kubelet to properly log when a container is started. Before, sometimes the log said that a container is dead and was restarted when it was started for the first time. This only happened when using pods with initContainers and regular containers. ([#91469](https://github.com/kubernetes/kubernetes/pull/91469), [@rata](https://github.com/rata)) [SIG Node] -- Fix: license issue in blob disk feature ([#92824](https://github.com/kubernetes/kubernetes/pull/92824), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fixes the flooding warning messages about setting volume ownership for configmap/secret volumes ([#92878](https://github.com/kubernetes/kubernetes/pull/92878), [@jvanz](https://github.com/jvanz)) [SIG Instrumentation, Node and Storage] -- Fixes the message about no auth for metrics in scheduler. ([#94035](https://github.com/kubernetes/kubernetes/pull/94035), [@zhouya0](https://github.com/zhouya0)) [SIG Scheduling] -- Kube-up: defaults to limiting critical pods to the kube-system namespace to match behavior prior to 1.17 ([#93121](https://github.com/kubernetes/kubernetes/pull/93121), [@liggitt](https://github.com/liggitt)) [SIG Cloud Provider and Scheduling] -- Kubeadm: Separate argument key/value in log msg ([#94016](https://github.com/kubernetes/kubernetes/pull/94016), [@mrueg](https://github.com/mrueg)) [SIG Cluster Lifecycle] -- Kubeadm: remove support for the "ci/k8s-master" version label. This label has been removed in the Kubernetes CI release process and would no longer work in kubeadm. You can use the "ci/latest" version label instead. See kubernetes/test-infra#18517 ([#93626](https://github.com/kubernetes/kubernetes/pull/93626), [@vikkyomkar](https://github.com/vikkyomkar)) [SIG Cluster Lifecycle] -- Kubeadm: remove the CoreDNS check for known image digests when applying the addon ([#94506](https://github.com/kubernetes/kubernetes/pull/94506), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubernetes is now built with go1.15.0 ([#93939](https://github.com/kubernetes/kubernetes/pull/93939), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing] -- Kubernetes is now built with go1.15.0-rc.2 ([#93827](https://github.com/kubernetes/kubernetes/pull/93827), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Node, Release and Testing] -- Lock ExternalPolicyForExternalIP to default, this feature gate will be removed in 1.22. ([#94581](https://github.com/kubernetes/kubernetes/pull/94581), [@knabben](https://github.com/knabben)) [SIG Network] -- Service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset is removed. All Standard load balancers will always enable tcp resets. ([#94297](https://github.com/kubernetes/kubernetes/pull/94297), [@MarcPow](https://github.com/MarcPow)) [SIG Cloud Provider] -- Stop propagating SelfLink (deprecated in 1.16) in kube-apiserver ([#94397](https://github.com/kubernetes/kubernetes/pull/94397), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Testing] -- Strip unnecessary security contexts on Windows ([#93475](https://github.com/kubernetes/kubernetes/pull/93475), [@ravisantoshgudimetla](https://github.com/ravisantoshgudimetla)) [SIG Node, Testing and Windows] -- To ensure the code be strong, add unit test for GetAddressAndDialer ([#93180](https://github.com/kubernetes/kubernetes/pull/93180), [@FreeZhang61](https://github.com/FreeZhang61)) [SIG Node] -- Update CNI plugins to v0.8.7 ([#94367](https://github.com/kubernetes/kubernetes/pull/94367), [@justaugustus](https://github.com/justaugustus)) [SIG Cloud Provider, Network, Node, Release and Testing] -- Update Golang to v1.14.5 - - Update repo-infra to 0.0.7 (to support go1.14.5 and go1.13.13) - - Includes: - - bazelbuild/bazel-toolchains@3.3.2 - - bazelbuild/rules_go@v0.22.7 ([#93088](https://github.com/kubernetes/kubernetes/pull/93088), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing] -- Update Golang to v1.14.6 - - Update repo-infra to 0.0.8 (to support go1.14.6 and go1.13.14) - - Includes: - - bazelbuild/bazel-toolchains@3.4.0 - - bazelbuild/rules_go@v0.22.8 ([#93198](https://github.com/kubernetes/kubernetes/pull/93198), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing] -- Update cri-tools to [v1.19.0](https://github.com/kubernetes-sigs/cri-tools/releases/tag/v1.19.0) ([#94307](https://github.com/kubernetes/kubernetes/pull/94307), [@xmudrii](https://github.com/xmudrii)) [SIG Cloud Provider] -- Update default etcd server version to 3.4.9 ([#92349](https://github.com/kubernetes/kubernetes/pull/92349), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cloud Provider, Cluster Lifecycle and Testing] -- Update etcd client side to v3.4.13 ([#94259](https://github.com/kubernetes/kubernetes/pull/94259), [@jingyih](https://github.com/jingyih)) [SIG API Machinery and Cloud Provider] -- `kubectl get ingress` now prefers the `networking.k8s.io/v1` over `extensions/v1beta1` (deprecated since v1.14). To explicitly request the deprecated version, use `kubectl get ingress.v1beta1.extensions`. ([#94309](https://github.com/kubernetes/kubernetes/pull/94309), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and CLI] - -## Dependencies - -### Added -- github.com/Azure/go-autorest: [v14.2.0+incompatible](https://github.com/Azure/go-autorest/tree/v14.2.0) -- github.com/fvbommel/sortorder: [v1.0.1](https://github.com/fvbommel/sortorder/tree/v1.0.1) -- github.com/yuin/goldmark: [v1.1.27](https://github.com/yuin/goldmark/tree/v1.1.27) -- sigs.k8s.io/structured-merge-diff/v4: v4.0.1 - -### Changed -- github.com/Azure/go-autorest/autorest/adal: [v0.8.2 → v0.9.0](https://github.com/Azure/go-autorest/autorest/adal/compare/v0.8.2...v0.9.0) -- github.com/Azure/go-autorest/autorest/date: [v0.2.0 → v0.3.0](https://github.com/Azure/go-autorest/autorest/date/compare/v0.2.0...v0.3.0) -- github.com/Azure/go-autorest/autorest/mocks: [v0.3.0 → v0.4.0](https://github.com/Azure/go-autorest/autorest/mocks/compare/v0.3.0...v0.4.0) -- github.com/Azure/go-autorest/autorest: [v0.9.6 → v0.11.1](https://github.com/Azure/go-autorest/autorest/compare/v0.9.6...v0.11.1) -- github.com/Azure/go-autorest/logger: [v0.1.0 → v0.2.0](https://github.com/Azure/go-autorest/logger/compare/v0.1.0...v0.2.0) -- github.com/Azure/go-autorest/tracing: [v0.5.0 → v0.6.0](https://github.com/Azure/go-autorest/tracing/compare/v0.5.0...v0.6.0) -- github.com/Microsoft/hcsshim: [v0.8.9 → 5eafd15](https://github.com/Microsoft/hcsshim/compare/v0.8.9...5eafd15) -- github.com/cilium/ebpf: [9f1617e → 1c8d4c9](https://github.com/cilium/ebpf/compare/9f1617e...1c8d4c9) -- github.com/containerd/cgroups: [bf292b2 → 0dbf7f0](https://github.com/containerd/cgroups/compare/bf292b2...0dbf7f0) -- github.com/coredns/corefile-migration: [v1.0.8 → v1.0.10](https://github.com/coredns/corefile-migration/compare/v1.0.8...v1.0.10) -- github.com/evanphx/json-patch: [e83c0a1 → v4.9.0+incompatible](https://github.com/evanphx/json-patch/compare/e83c0a1...v4.9.0) -- github.com/google/cadvisor: [8450c56 → v0.37.0](https://github.com/google/cadvisor/compare/8450c56...v0.37.0) -- github.com/json-iterator/go: [v1.1.9 → v1.1.10](https://github.com/json-iterator/go/compare/v1.1.9...v1.1.10) -- github.com/opencontainers/go-digest: [v1.0.0-rc1 → v1.0.0](https://github.com/opencontainers/go-digest/compare/v1.0.0-rc1...v1.0.0) -- github.com/opencontainers/runc: [1b94395 → 819fcc6](https://github.com/opencontainers/runc/compare/1b94395...819fcc6) -- github.com/prometheus/client_golang: [v1.6.0 → v1.7.1](https://github.com/prometheus/client_golang/compare/v1.6.0...v1.7.1) -- github.com/prometheus/common: [v0.9.1 → v0.10.0](https://github.com/prometheus/common/compare/v0.9.1...v0.10.0) -- github.com/prometheus/procfs: [v0.0.11 → v0.1.3](https://github.com/prometheus/procfs/compare/v0.0.11...v0.1.3) -- github.com/rubiojr/go-vhd: [0bfd3b3 → 02e2102](https://github.com/rubiojr/go-vhd/compare/0bfd3b3...02e2102) -- github.com/storageos/go-api: [343b3ef → v2.2.0+incompatible](https://github.com/storageos/go-api/compare/343b3ef...v2.2.0) -- github.com/urfave/cli: [v1.22.1 → v1.22.2](https://github.com/urfave/cli/compare/v1.22.1...v1.22.2) -- go.etcd.io/etcd: 54ba958 → dd1b699 -- golang.org/x/crypto: bac4c82 → 75b2880 -- golang.org/x/mod: v0.1.0 → v0.3.0 -- golang.org/x/net: d3edc99 → ab34263 -- golang.org/x/tools: c00d67e → c1934b7 -- k8s.io/kube-openapi: 656914f → 6aeccd4 -- k8s.io/system-validators: v1.1.2 → v1.2.0 -- k8s.io/utils: 6e3d28b → d5654de - -### Removed -- github.com/godbus/dbus: [ade71ed](https://github.com/godbus/dbus/tree/ade71ed) -- github.com/xlab/handysort: [fb3537e](https://github.com/xlab/handysort/tree/fb3537e) -- sigs.k8s.io/structured-merge-diff/v3: v3.0.0 -- vbom.ml/util: db5cfe1 diff --git a/content/en/docs/tasks/access-application-cluster/_index.md b/content/en/docs/tasks/access-application-cluster/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index e32a6ba02c..8b79d7042f 100644 --- a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -7,7 +7,6 @@ card: weight: 40 --- - This page shows how to configure access to multiple clusters by using @@ -22,19 +21,21 @@ It does not mean that there is a file named `kubeconfig`. {{< /note >}} +{{< warning >}} +Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure. +If you must use an untrusted kubeconfig file, inspect it carefully first, much as you would a shell script. +{{< /warning>}} + ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} To check that {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} is installed, run `kubectl version --client`. The kubectl version should be -[within one minor version](/docs/setup/release/version-skew-policy/#kubectl) of your +[within one minor version](/releases/version-skew-policy/#kubectl) of your cluster's API server. - - ## Define clusters, users, and contexts @@ -186,7 +187,7 @@ kubectl config --kubeconfig=config-demo view --minify The output shows configuration information associated with the `dev-frontend` context: -```shell +```yaml apiVersion: v1 clusters: - cluster: @@ -238,7 +239,6 @@ kubectl config --kubeconfig=config-demo use-context dev-storage View configuration associated with the new current context, `dev-storage`. - ```shell kubectl config --kubeconfig=config-demo view --minify ``` @@ -247,7 +247,7 @@ kubectl config --kubeconfig=config-demo view --minify In your `config-exercise` directory, create a file named `config-demo-2` with this content: -```shell +```yaml apiVersion: v1 kind: Config preferences: {} @@ -269,13 +269,17 @@ current value of your `KUBECONFIG` environment variable, so you can restore it l For example: ### Linux + ```shell export KUBECONFIG_SAVED=$KUBECONFIG ``` + ### Windows PowerShell -```shell + +```powershell $Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG ``` + The `KUBECONFIG` environment variable is a list of paths to configuration files. The list is colon-delimited for Linux and Mac, and semicolon-delimited for Windows. If you have a `KUBECONFIG` environment variable, familiarize yourself with the configuration files @@ -284,11 +288,14 @@ in the list. Temporarily append two paths to your `KUBECONFIG` environment variable. For example: ### Linux + ```shell export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2 ``` + ### Windows PowerShell -```shell + +```powershell $Env:KUBECONFIG=("config-demo;config-demo-2") ``` @@ -303,7 +310,7 @@ environment variable. In particular, notice that the merged information has the `dev-ramp-up` context from the `config-demo-2` file and the three contexts from the `config-demo` file: -```shell +```yaml contexts: - context: cluster: development @@ -347,11 +354,14 @@ If you have a `$HOME/.kube/config` file, and it's not already listed in your For example: ### Linux + ```shell export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config ``` + ### Windows Powershell -```shell + +```powershell $Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config" ``` @@ -367,23 +377,19 @@ kubectl config view Return your `KUBECONFIG` environment variable to its original value. For example:
### Linux + ```shell export KUBECONFIG=$KUBECONFIG_SAVED ``` + ### Windows PowerShell -```shell + +```powershell $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED ``` - - ## {{% heading "whatsnext" %}} - * [Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) * [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) - - - - diff --git a/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md b/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md index 7dcc613232..23f6f91a2c 100644 --- a/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md +++ b/content/en/docs/tasks/access-application-cluster/create-external-load-balancer.md @@ -4,47 +4,44 @@ content_type: task weight: 80 --- - -This page shows how to create an External Load Balancer. +This page shows how to create an external load balancer. -{{< note >}} -This feature is only available for cloud providers or environments which support external load balancers. -{{< /note >}} - -When creating a service, you have the option of automatically creating a -cloud network load balancer. This provides an externally-accessible IP address -that sends traffic to the correct port on your cluster nodes +When creating a {{< glossary_tooltip text="Service" term_id="service" >}}, you have +the option of automatically creating a cloud load balancer. This provides an +externally-accessible IP address that sends traffic to the correct port on your cluster +nodes, _provided your cluster runs in a supported environment and is configured with the correct cloud load balancer provider package_. -For information on provisioning and using an Ingress resource that can give -services externally-reachable URLs, load balance the traffic, terminate SSL etc., -please check the [Ingress](/docs/concepts/services-networking/ingress/) +You can also use an {{< glossary_tooltip term_id="ingress" >}} in place of Service. +For more information, check the [Ingress](/docs/concepts/services-networking/ingress/) documentation. - - ## {{% heading "prerequisites" %}} -* {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} +Your cluster must be running in a cloud or other environment that already has support +for configuring external load balancers. -## Configuration file +## Create a Service + +### Create a Service from a manifest To create an external load balancer, add the following line to your -[service configuration file](/docs/concepts/services-networking/service/#loadbalancer): +Service manifest: ```yaml type: LoadBalancer ``` -Your configuration file might look like: +Your manifest might then look like: ```yaml apiVersion: v1 @@ -60,19 +57,19 @@ spec: type: LoadBalancer ``` -## Using kubectl +### Create a Service using kubectl You can alternatively create the service with the `kubectl expose` command and its `--type=LoadBalancer` flag: ```bash -kubectl expose rc example --port=8765 --target-port=9376 \ +kubectl expose deployment example --port=8765 --target-port=9376 \ --name=example-service --type=LoadBalancer ``` -This command creates a new service using the same selectors as the referenced -resource (in the case of the example above, a replication controller named -`example`). +This command creates a new Service using the same selectors as the referenced +resource (in the case of the example above, a +{{< glossary_tooltip text="Deployment" term_id="deployment" >}} named `example`). For more information, including optional flags, refer to the [`kubectl expose` reference](/docs/reference/generated/kubectl/kubectl-commands/#expose). @@ -86,59 +83,63 @@ information through `kubectl`: kubectl describe services example-service ``` -which should produce output like this: +which should produce output similar to: -```bash - Name: example-service - Namespace: default - Labels: - Annotations: - Selector: app=example - Type: LoadBalancer - IP: 10.67.252.103 - LoadBalancer Ingress: 192.0.2.89 - Port: 80/TCP - NodePort: 32445/TCP - Endpoints: 10.64.0.4:80,10.64.1.5:80,10.64.2.4:80 - Session Affinity: None - Events: +``` +Name: example-service +Namespace: default +Labels: app=example +Annotations: +Selector: app=example +Type: LoadBalancer +IP Families: +IP: 10.3.22.96 +IPs: 10.3.22.96 +LoadBalancer Ingress: 192.0.2.89 +Port: 8765/TCP +TargetPort: 9376/TCP +NodePort: 30593/TCP +Endpoints: 172.17.0.3:9376 +Session Affinity: None +External Traffic Policy: Cluster +Events: ``` -The IP address is listed next to `LoadBalancer Ingress`. +The load balancer's IP address is listed next to `LoadBalancer Ingress`. {{< note >}} If you are running your service on Minikube, you can find the assigned IP address and port with: -{{< /note >}} ```bash minikube service example-service --url ``` +{{< /note >}} ## Preserving the client source IP -Due to the implementation of this feature, the source IP seen in the target -container is *not the original source IP* of the client. To enable -preservation of the client IP, the following fields can be configured in the -service spec (supported in GCE/Google Kubernetes Engine environments): +By default, the source IP seen in the target container is *not the original +source IP* of the client. To enable preservation of the client IP, the following +fields can be configured in the `.spec` of the Service: -* `service.spec.externalTrafficPolicy` - denotes if this Service desires to route -external traffic to node-local or cluster-wide endpoints. There are two available -options: Cluster (default) and Local. Cluster obscures the client source -IP and may cause a second hop to another node, but should have good overall -load-spreading. Local preserves the client source IP and avoids a second hop -for LoadBalancer and NodePort type services, but risks potentially imbalanced -traffic spreading. -* `service.spec.healthCheckNodePort` - specifies the health check node port -(numeric port number) for the service. If `healthCheckNodePort` isn't specified, -the service controller allocates a port from your cluster's NodePort range. You -can configure that range by setting an API server command line option, -`--service-node-port-range`. It will use the -user-specified `healthCheckNodePort` value if specified by the client. It only has an -effect when `type` is set to LoadBalancer and `externalTrafficPolicy` is set -to Local. +* `.spec.externalTrafficPolicy` - denotes if this Service desires to route + external traffic to node-local or cluster-wide endpoints. There are two available + options: `Cluster` (default) and `Local`. `Cluster` obscures the client source + IP and may cause a second hop to another node, but should have good overall + load-spreading. `Local` preserves the client source IP and avoids a second hop + for LoadBalancer and NodePort type Services, but risks potentially imbalanced + traffic spreading. +* `.spec.healthCheckNodePort` - specifies the health check node port + (numeric port number) for the service. If you don't specify + `healthCheckNodePort`, the service controller allocates a port from your + cluster's NodePort range. + You can configure that range by setting an API server command line option, + `--service-node-port-range`. The Service will use the user-specified + `healthCheckNodePort` value if you specify it, provided that the + Service `type` is set to LoadBalancer and `externalTrafficPolicy` is set + to `Local`. -Setting `externalTrafficPolicy` to Local in the Service configuration file -activates this feature. +Setting `externalTrafficPolicy` to Local in the Service manifest +activates this feature. For example: ```yaml apiVersion: v1 @@ -155,7 +156,20 @@ spec: type: LoadBalancer ``` -## Garbage Collecting Load Balancers +### Caveats and limitations when preserving source IPs + +Load balancing services from some cloud providers do not let you configure different weights for each target. + +With each target weighted equally in terms of sending traffic to Nodes, external +traffic is not equally load balanced across different Pods. The external load balancer +is unaware of the number of Pods on each node that are used as a target. + +Where `NumServicePods << _NumNodes` or `NumServicePods >> NumNodes`, a fairly close-to-equal +distribution will be seen, even without weights. + +Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods. + +## Garbage collecting load balancers {{< feature-state for_k8s_version="v1.17" state="stable" >}} @@ -172,32 +186,18 @@ The finalizer will only be removed after the load balancer resource is cleaned u This prevents dangling load balancer resources even in corner cases such as the service controller crashing. -## External Load Balancer Providers +## External load balancer providers It is important to note that the datapath for this functionality is provided by a load balancer external to the Kubernetes cluster. When the Service `type` is set to LoadBalancer, Kubernetes provides functionality equivalent to `type` equals ClusterIP to pods -within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the Kubernetes -pods. The Kubernetes service controller automates the creation of the external load balancer, health checks (if needed), -firewall rules (if needed) and retrieves the external IP allocated by the cloud provider and populates it in the service -object. - -## Caveats and Limitations when preserving source IPs - -GCE/AWS load balancers do not provide weights for their target pools. This was not an issue with the old LB -kube-proxy rules which would correctly balance across all endpoints. - -With the new functionality, the external traffic is not equally load balanced across pods, but rather -equally balanced at the node level (because GCE/AWS and other external LB implementations do not have the ability -for specifying the weight per node, they balance equally across all target nodes, disregarding the number of -pods on each node). - -We can, however, state that for NumServicePods << NumNodes or NumServicePods >> NumNodes, a fairly close-to-equal -distribution will be seen, even without weights. - -Once the external load balancers provide weights, this functionality can be added to the LB programming path. -*Future Work: No support for weights is provided for the 1.4 release, but may be added at a future date* - -Internal pod to pod traffic should behave similar to ClusterIP services, with equal probability across all pods. +within the cluster and extends it by programming the (external to Kubernetes) load balancer with entries for the nodes +hosting the relevant Kubernetes pods. The Kubernetes control plane automates the creation of the external load balancer, +health checks (if needed), and packet filtering rules (if needed). Once the cloud provider allocates an IP address for the load +balancer, the control plane looks up that external IP address and populates it into the Service object. +## {{% heading "whatsnext" %}} +* Read about [Service](/docs/concepts/services-networking/service/) +* Read about [Ingress](/docs/concepts/services-networking/ingress/) +* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md index 5b3fd114b0..65249e8fc8 100644 --- a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md +++ b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md @@ -44,8 +44,48 @@ This page shows you how to set up a simple Ingress which routes requests to Serv 1. Verify that the NGINX Ingress controller is running + + {{< tabs name="tab_with_md" >}} + {{% tab name="minikube v1.19 or later" %}} +```shell +kubectl get pods -n ingress-nginx +``` + {{< note >}}This can take up to a minute.{{< /note >}} + +Output: + +``` +NAME READY STATUS RESTARTS AGE +ingress-nginx-admission-create-g9g49 0/1 Completed 0 11m +ingress-nginx-admission-patch-rqp78 0/1 Completed 1 11m +ingress-nginx-controller-59b45fb494-26npt 1/1 Running 0 11m +``` + {{% /tab %}} + + {{% tab name="minikube v1.18.1 or earlier" %}} +```shell +kubectl get pods -n kube-system +``` +{{< note >}}This can take up to a minute.{{< /note >}} + +Output: + +``` +NAME READY STATUS RESTARTS AGE +default-http-backend-59868b7dd6-xb8tq 1/1 Running 0 1m +kube-addon-manager-minikube 1/1 Running 0 3m +kube-dns-6dcb57bcc8-n4xd4 3/3 Running 0 2m +kubernetes-dashboard-5498ccf677-b8p5h 1/1 Running 0 2m +nginx-ingress-controller-5984b97644-rnkrg 1/1 Running 0 1m +storage-provisioner 1/1 Running 0 2m +``` + {{% /tab %}} + {{< /tabs >}} + + + ```shell - kubectl get pods -n kube-system + kubectl get pods -n ingress-nginx ``` {{< note >}}This can take up to a minute.{{< /note >}} @@ -53,15 +93,13 @@ This page shows you how to set up a simple Ingress which routes requests to Serv Output: ```shell - NAME READY STATUS RESTARTS AGE - default-http-backend-59868b7dd6-xb8tq 1/1 Running 0 1m - kube-addon-manager-minikube 1/1 Running 0 3m - kube-dns-6dcb57bcc8-n4xd4 3/3 Running 0 2m - kubernetes-dashboard-5498ccf677-b8p5h 1/1 Running 0 2m - nginx-ingress-controller-5984b97644-rnkrg 1/1 Running 0 1m - storage-provisioner 1/1 Running 0 2m + NAME READY STATUS RESTARTS AGE + ingress-nginx-admission-create-2tgrf 0/1 Completed 0 3m28s + ingress-nginx-admission-patch-68b98 0/1 Completed 0 3m28s + ingress-nginx-controller-59b45fb494-lzmw2 1/1 Running 0 3m28s ``` + ## Deploy a hello, world app 1. Create a Deployment using the following command: diff --git a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md index 3a8983eec8..133eae902b 100644 --- a/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/en/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -23,7 +23,7 @@ of Containers for each. - Fetch all Pods in all namespaces using `kubectl get pods --all-namespaces` - Format the output to include only the list of Container image names - using `-o jsonpath={..image}`. This will recursively parse out the + using `-o jsonpath={.items[*].spec.containers[*].image}`. This will recursively parse out the `image` field from the returned json. - See the [jsonpath reference](/docs/reference/kubectl/jsonpath/) for further information on how to use jsonpath. @@ -33,7 +33,7 @@ of Containers for each. - Use `uniq` to aggregate image counts ```shell -kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\ tr -s '[[:space:]]' '\n' |\ sort |\ uniq -c @@ -80,7 +80,7 @@ To target only Pods matching a specific label, use the -l flag. The following matches only Pods with labels matching `app=nginx`. ```shell -kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx +kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx ``` ## List Container images filtering by Pod namespace @@ -89,7 +89,7 @@ To target only pods in a specific namespace, use the namespace flag. The following matches only Pods in the `kube-system` namespace. ```shell -kubectl get pods --namespace kube-system -o jsonpath="{..image}" +kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}" ``` ## List Container images using a go-template instead of jsonpath diff --git a/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md index 0a6d352d2c..ba8f7b1244 100644 --- a/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md +++ b/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md @@ -31,7 +31,7 @@ for database debugging. 1. Create a Deployment that runs MongoDB: ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml + kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml ``` The output of a successful command verifies that the deployment was created: @@ -84,7 +84,7 @@ for database debugging. 2. Create a Service to expose MongoDB on the network: ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml + kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml ``` The output of a successful command verifies that the Service was created: @@ -196,13 +196,6 @@ the slightly simpler syntax: kubectl port-forward deployment/mongo :27017 ``` -The output is similar to this: - -``` -Forwarding from 127.0.0.1:63753 -> 27017 -Forwarding from [::1]:63753 -> 27017 -``` - The `kubectl` tool finds a local port number that is not in use (avoiding low ports numbers, because these might be used by other applications). The output is similar to: diff --git a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md index 47cec90f26..0182bbad73 100644 --- a/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/en/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -2,8 +2,9 @@ reviewers: - bryk - mikedanese -- rf232 -title: Web UI (Dashboard) +title: Deploy and Access the Kubernetes Dashboard +description: >- + Deploy the web UI (Kubernetes Dashboard) and access it. content_type: concept weight: 10 card: @@ -34,7 +35,7 @@ Dashboard also provides information on the state of Kubernetes resources in your The Dashboard UI is not deployed by default. To deploy it, run the following command: ``` -kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.3.1/aio/deploy/recommended.yaml ``` ## Accessing the Dashboard UI @@ -49,7 +50,9 @@ The sample user created in the tutorial will have administrative privileges and {{< /warning >}} ### Command line proxy -You can access Dashboard using the kubectl command-line tool by running the following command: + +You can enable access to the Dashboard using the `kubectl` command-line tool, +by running the following command: ``` kubectl proxy @@ -60,7 +63,8 @@ Kubectl will make Dashboard available at [http://localhost:8001/api/v1/namespace The UI can _only_ be accessed from the machine where the command is executed. See `kubectl proxy --help` for more options. {{< note >}} -Kubeconfig Authentication method does NOT support external identity providers or x509 certificate-based authentication. +The kubeconfig authentication method does **not** support external identity providers +or X.509 certificate-based authentication. {{< /note >}} ## Welcome view @@ -75,7 +79,7 @@ In addition, you can view which system applications are running by default in th ## Deploying containerized applications Dashboard lets you create and deploy a containerized application as a Deployment and optional Service with a simple wizard. -You can either manually specify application details, or upload a YAML or JSON file containing application configuration. +You can either manually specify application details, or upload a YAML or JSON _manifest_ file containing application configuration. Click the **CREATE** button in the upper right corner of any page to begin. @@ -186,13 +190,14 @@ If needed, you can expand the **Advanced options** section where you can specify ### Uploading a YAML or JSON file Kubernetes supports declarative configuration. -In this style, all configuration is stored in YAML or JSON configuration files -using the Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas. +In this style, all configuration is stored in manifests (YAML or JSON configuration files). +The manifests use Kubernetes [API](/docs/concepts/overview/kubernetes-api/) resource schemas. As an alternative to specifying application details in the deploy wizard, -you can define your application in YAML or JSON files, and upload the files using Dashboard. +you can define your application in one or more manifests, and upload the files using Dashboard. ## Using Dashboard + Following sections describe views of the Kubernetes Dashboard UI; what they provide and how can they be used. ### Navigation @@ -203,8 +208,9 @@ this can be changed using the namespace selector located in the navigation menu. Dashboard shows most Kubernetes object kinds and groups them in a few menu categories. -#### Admin Overview -For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and Persistent Volumes and has detail views for them. +#### Admin overview + +For cluster and namespace administrators, Dashboard lists Nodes, Namespaces and PersistentVolumes and has detail views for them. Node list view contains CPU and memory usage metrics aggregated across all Nodes. The details view shows the metrics for a Node, its specification, status, allocated resources, events and pods running on the node. @@ -212,14 +218,14 @@ allocated resources, events and pods running on the node. #### Workloads Shows all applications running in the selected namespace. -The view lists applications by workload kind (e.g., Deployments, Replica Sets, Stateful Sets, etc.) +The view lists applications by workload kind (for example: Deployments, ReplicaSets, StatefulSets). and each workload kind can be viewed separately. The lists summarize actionable information about the workloads, -such as the number of ready pods for a Replica Set or current memory usage for a Pod. +such as the number of ready pods for a ReplicaSet or current memory usage for a Pod. Detail views for workloads show status and specification information and surface relationships between objects. -For example, Pods that Replica Set is controlling or New Replica Sets and Horizontal Pod Autoscalers for Deployments. +For example, Pods that ReplicaSet is controlling or new ReplicaSets and HorizontalPodAutoscalers for Deployments. #### Services @@ -230,9 +236,9 @@ internal endpoints for cluster connections and external endpoints for external u #### Storage -Storage view shows Persistent Volume Claim resources which are used by applications for storing data. +Storage view shows PersistentVolumeClaim resources which are used by applications for storing data. -#### Config Maps and Secrets +#### ConfigMaps and Secrets {#config-maps-and-secrets} Shows all Kubernetes resources that are used for live configuration of applications running in clusters. The view allows for editing and managing config objects and displays secrets hidden by default. diff --git a/content/en/docs/tasks/administer-cluster/_index.md b/content/en/docs/tasks/administer-cluster/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tasks/administer-cluster/access-cluster-api.md b/content/en/docs/tasks/administer-cluster/access-cluster-api.md index 0275cadabf..827cb50f7c 100644 --- a/content/en/docs/tasks/administer-cluster/access-cluster-api.md +++ b/content/en/docs/tasks/administer-cluster/access-cluster-api.md @@ -30,7 +30,7 @@ Check the location and credentials that kubectl knows about with this command: kubectl config view ``` -Many of the [examples](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/) provide an introduction to using +Many of the [examples](https://github.com/kubernetes/examples/tree/master/) provide an introduction to using kubectl. Complete documentation is found in the [kubectl manual](/docs/reference/kubectl/overview/). ### Directly accessing the REST API diff --git a/content/en/docs/tasks/administer-cluster/certificates.md b/content/en/docs/tasks/administer-cluster/certificates.md index 6361b20d16..2338b0cdc7 100644 --- a/content/en/docs/tasks/administer-cluster/certificates.md +++ b/content/en/docs/tasks/administer-cluster/certificates.md @@ -116,6 +116,9 @@ manually through `easyrsa`, `openssl` or `cfssl`. openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ -CAcreateserial -out server.crt -days 10000 \ -extensions v3_ext -extfile csr.conf +1. View the certificate signing request: + + openssl req -noout -text -in ./server.csr 1. View the certificate: openssl x509 -noout -text -in ./server.crt diff --git a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md index be7cbf2673..6a11b4f2d3 100644 --- a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md +++ b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md @@ -26,7 +26,7 @@ volume is automatically deleted when a user deletes the corresponding PersistentVolumeClaim. This automatic behavior might be inappropriate if the volume contains precious data. In that case, it is more appropriate to use the "Retain" policy. With the "Retain" policy, if a user deletes a PersistentVolumeClaim, -the corresponding PersistentVolume is not be deleted. Instead, it is moved to the +the corresponding PersistentVolume will not be deleted. Instead, it is moved to the Released phase, where all of its data can be manually recovered. ## Changing the reclaim policy of a PersistentVolume diff --git a/content/en/docs/tasks/administer-cluster/controller-manager-leader-migration.md b/content/en/docs/tasks/administer-cluster/controller-manager-leader-migration.md new file mode 100644 index 0000000000..ddfa8e592e --- /dev/null +++ b/content/en/docs/tasks/administer-cluster/controller-manager-leader-migration.md @@ -0,0 +1,126 @@ +--- +reviewers: +- jpbetz +- cheftako +title: "Migrate Replicated Control Plane To Use Cloud Controller Manager" +linkTitle: "Migrate Replicated Control Plane To Use Cloud Controller Manager" +content_type: task +--- + + + + +{{< feature-state state="beta" for_k8s_version="v1.22" >}} + +{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="The cloud-controller-manager is">}} + +## Background + +As part of the [cloud provider extraction effort](https://kubernetes.io/blog/2019/04/17/the-future-of-cloud-providers-in-kubernetes/), all cloud specific controllers must be moved out of the `kube-controller-manager`. All existing clusters that run cloud controllers in the `kube-controller-manager` must migrate to instead run the controllers in a cloud provider specific `cloud-controller-manager`. + +Leader Migration provides a mechanism in which HA clusters can safely migrate "cloud specific" controllers between the `kube-controller-manager` and the `cloud-controller-manager` via a shared resource lock between the two components while upgrading the replicated control plane. For a single-node control plane, or if unavailability of controller managers can be tolerated during the upgrade, Leader Migration is not needed and this guide can be ignored. + +Leader Migration can be enabled by setting `--enable-leader-migration` on `kube-controller-manager` or `cloud-controller-manager`. Leader Migration only applies during the upgrade and can be safely disabled or left enabled after the upgrade is complete. + +This guide walks you through the manual process of upgrading the control plane from `kube-controller-manager` with built-in cloud provider to running both `kube-controller-manager` and `cloud-controller-manager`. If you use a tool to administrator the cluster, please refer to the documentation of the tool and the cloud provider for more details. + +## {{% heading "prerequisites" %}} + +It is assumed that the control plane is running Kubernetes version N and to be upgraded to version N + 1. Although it is possible to migrate within the same version, ideally the migration should be performed as part of an upgrade so that changes of configuration can be aligned to each release. The exact versions of N and N + 1 depend on each cloud provider. For example, if a cloud provider builds a `cloud-controller-manager` to work with Kubernetes 1.22, then N can be 1.21 and N + 1 can be 1.22. + +The control plane nodes should run `kube-controller-manager` with Leader Election enabled through `--leader-elect=true`. As of version N, an in-tree cloud privider must be set with `--cloud-provider` flag and `cloud-controller-manager` should not yet be deployed. + +The out-of-tree cloud provider must have built a `cloud-controller-manager` with Leader Migration implementation. If the cloud provider imports `k8s.io/cloud-provider` and `k8s.io/controller-manager` of version v0.21.0 or later, Leader Migration will be available. However, for version before v0.22.0, Leader Migration is alpha and requires feature gate `ControllerManagerLeaderMigration` to be enabled. + +This guide assumes that kubelet of each control plane node starts `kube-controller-manager` and `cloud-controller-manager` as static pods defined by their manifests. If the components run in a different setting, please adjust the steps accordingly. + +For authorization, this guide assumes that the cluster uses RBAC. If another authorization mode grants permissions to `kube-controller-manager` and `cloud-controller-manager` components, please grant the needed access in a way that matches the mode. + + + +### Grant access to Migration Lease + +The default permissions of the controller manager allow only accesses to their main Lease. In order for the migration to work, accesses to another Lease are required. + +You can grant `kube-controller-manager` full access to the leases API by modifying the `system::leader-locking-kube-controller-manager` role. This task guide assumes that the name of the migration lease is `cloud-provider-extraction-migration`. + +`kubectl patch -n kube-system role 'system::leader-locking-kube-controller-manager' -p '{"rules": [ {"apiGroups":[ "coordination.k8s.io"], "resources": ["leases"], "resourceNames": ["cloud-provider-extraction-migration"], "verbs": ["create", "list", "get", "update"] } ]}' --type=merge` + +Do the same to the `system::leader-locking-cloud-controller-manager` role. + +`kubectl patch -n kube-system role 'system::leader-locking-cloud-controller-manager' -p '{"rules": [ {"apiGroups":[ "coordination.k8s.io"], "resources": ["leases"], "resourceNames": ["cloud-provider-extraction-migration"], "verbs": ["create", "list", "get", "update"] } ]}' --type=merge` + +### Initial Leader Migration configuration + +Leader Migration optionally takes a configuration file representing the state of controller-to-manager assignment. At this moment, with in-tree cloud provider, `kube-controller-manager` runs `route`, `service`, and `cloud-node-lifecycle`. The following example configuration shows the assignment. + +Leader Migration can be enabled without a configuration. Please see [Default Configuration](#default-configuration) for details. + +```yaml +kind: LeaderMigrationConfiguration +apiVersion: controllermanager.config.k8s.io/v1beta1 +leaderName: cloud-provider-extraction-migration +resourceLock: leases +controllerLeaders: + - name: route + component: kube-controller-manager + - name: service + component: kube-controller-manager + - name: cloud-node-lifecycle + component: kube-controller-manager +``` + +On each control plane node, save the content to `/etc/leadermigration.conf`, and update the manifest of `kube-controller-manager` so that the file is mounted inside the container at the same location. Also, update the same manifest to add the following arguments: + +- `--enable-leader-migration` to enable Leader Migration on the controller manager +- `--leader-migration-config=/etc/leadermigration.conf` to set configuration file + +Restart `kube-controller-manager` on each node. At this moment, `kube-controller-manager` has leader migration enabled and is ready for the migration. + +### Deploy Cloud Controller Manager + +In version N + 1, the desired state of controller-to-manager assignment can be represented by a new configuration file, shown as follows. Please note `component` field of each `controllerLeaders` changing from `kube-controller-manager` to `cloud-controller-manager`. + +```yaml +kind: LeaderMigrationConfiguration +apiVersion: controllermanager.config.k8s.io/v1beta1 +leaderName: cloud-provider-extraction-migration +resourceLock: leases +controllerLeaders: + - name: route + component: cloud-controller-manager + - name: service + component: cloud-controller-manager + - name: cloud-node-lifecycle + component: cloud-controller-manager +``` + +When creating control plane nodes of version N + 1, the content should be deploy to `/etc/leadermigration.conf`. The manifest of `cloud-controller-manager` should be updated to mount the configuration file in the same manner as `kube-controller-manager` of version N. Similarly, add `--feature-gates=ControllerManagerLeaderMigration=true`,`--enable-leader-migration`, and `--leader-migration-config=/etc/leadermigration.conf` to the arguments of `cloud-controller-manager`. + +Create a new control plane node of version N + 1 with the updated `cloud-controller-manager` manifest, and with the `--cloud-provider` flag unset for `kube-controller-manager`. `kube-controller-manager` of version N + 1 MUST NOT have Leader Migration enabled because, with an external cloud provider, it does not run the migrated controllers anymore and thus it is not involved in the migration. + +Please refer to [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/) for more detail on how to deploy `cloud-controller-manager`. + +### Upgrade Control Plane + +The control plane now contains nodes of both version N and N + 1. The nodes of version N run `kube-controller-manager` only, and these of version N + 1 run both `kube-controller-manager` and `cloud-controller-manager`. The migrated controllers, as specified in the configuration, are running under either `kube-controller-manager` of version N or `cloud-controller-manager` of version N + 1 depending on which controller manager holds the migration lease. No controller will ever be running under both controller managers at any time. + +In a rolling manner, create a new control plane node of version N + 1 and bring down one of version N + 1 until the control plane contains only nodes of version N + 1. +If a rollback from version N + 1 to N is required, add nodes of version N with Leader Migration enabled for `kube-controller-manager` back to the control plane, replacing one of version N + 1 each time until there are only nodes of version N. + +### (Optional) Disable Leader Migration {#disable-leader-migration} + +Now that the control plane has been upgraded to run both `kube-controller-manager` and `cloud-controller-manager` of version N + 1, Leader Migration has finished its job and can be safely disabled to save one Lease resource. It is safe to re-enable Leader Migration for the rollback in the future. + +In a rolling manager, update manifest of `cloud-controller-manager` to unset both `--enable-leader-migration` and `--leader-migration-config=` flag, also remove the mount of `/etc/leadermigration.conf`, and finally remove `/etc/leadermigration.conf`. To re-enable Leader Migration, recreate the configuration file and add its mount and the flags that enable Leader Migration back to `cloud-controller-manager`. + +### Default Configuration + +Starting Kubernetes 1.22, Leader Migration provides a default configuration suitable for the default controller-to-manager assignment. +The default configuration can be enabled by setting `--enable-leader-migration` but without `--leader-migration-config=`. + +For `kube-controller-manager` and `cloud-controller-manager`, if there are no flags that enable any in-tree cloud provider or change ownership of controllers, the default configuration can be used to avoid manual creation of the configuration file. + +## {{% heading "whatsnext" %}} + +- Read the [Controller Manager Leader Migration](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cloud-provider/2436-controller-manager-leader-migration) enhancement proposal diff --git a/content/en/docs/tasks/administer-cluster/coredns.md b/content/en/docs/tasks/administer-cluster/coredns.md index 32d4f7d7ec..54163058c8 100644 --- a/content/en/docs/tasks/administer-cluster/coredns.md +++ b/content/en/docs/tasks/administer-cluster/coredns.md @@ -36,7 +36,7 @@ For manual deployment or replacement of kube-dns, see the documentation at the In Kubernetes version 1.10 and later, you can also move to CoreDNS when you use `kubeadm` to upgrade a cluster that is using `kube-dns`. In this case, `kubeadm` will generate the CoreDNS configuration -("Corefile") based upon the `kube-dns` ConfigMap, preserving configurations for federation, +("Corefile") based upon the `kube-dns` ConfigMap, preserving configurations for stub domains, and upstream name server. If you are moving from kube-dns to CoreDNS, make sure to set the `CoreDNS` feature gate to `true` @@ -46,8 +46,7 @@ kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true ``` In Kubernetes version 1.13 and later the `CoreDNS` feature gate is removed and CoreDNS -is used by default. Follow the guide outlined [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon) if you want -your upgraded cluster to use kube-dns. +is used by default. In versions prior to 1.11 the Corefile will be **overwritten** by the one created during upgrade. **You should save your existing ConfigMap if you have customized it.** You may re-apply your @@ -56,26 +55,7 @@ customizations after the new ConfigMap is up and running. If you are running CoreDNS in Kubernetes version 1.11 and later, during upgrade, your existing Corefile will be retained. - -### Installing kube-dns instead of CoreDNS with kubeadm - -{{< note >}} -In Kubernetes 1.11, CoreDNS has graduated to General Availability (GA) -and is installed by default. -{{< /note >}} - -{{< warning >}} -In Kubernetes 1.18, kube-dns usage with kubeadm has been deprecated and will be removed in a future version. -{{< /warning >}} - -To install kube-dns on versions prior to 1.13, set the `CoreDNS` feature gate -value to `false`: - -``` -kubeadm init --feature-gates=CoreDNS=false -``` - -For versions 1.13 and later, follow the guide outlined [here](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon). +In Kubernetes version 1.21, support for `kube-dns` is removed from kubeadm. ## Upgrading CoreDNS diff --git a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md index 5ffc40781a..9eb7d7febb 100644 --- a/content/en/docs/tasks/administer-cluster/cpu-management-policies.md +++ b/content/en/docs/tasks/administer-cluster/cpu-management-policies.md @@ -58,12 +58,16 @@ frequency is set through a new Kubelet configuration value `--cpu-manager-reconcile-period`. If not specified, it defaults to the same duration as `--node-status-update-frequency`. +The behavior of the static policy can be fine-tuned using the `--cpu-manager-policy-options` flag. +The flag takes a comma-separated list of `key=value` policy options. + ### None policy The `none` policy explicitly enables the existing default CPU affinity scheme, providing no affinity beyond what the OS scheduler does automatically.  Limits on CPU usage for -[Guaranteed pods](/docs/tasks/configure-pod-container/quality-service-pod/) +[Guaranteed pods](/docs/tasks/configure-pod-container/quality-service-pod/) and +[Burstable pods](/docs/tasks/configure-pod-container/quality-service-pod/) are enforced using CFS quota. ### Static policy @@ -212,4 +216,14 @@ and `requests` are set equal to `limits` when not explicitly specified. And the container's resource limit for the CPU resource is an integer greater than or equal to one. The `nginx` container is granted 2 exclusive CPUs. +#### Static policy options +If the `full-pcpus-only` policy option is specified, the static policy will always allocate full physical cores. +You can enable this option by adding `full-pcups-only=true` to the CPUManager policy options. +By default, without this option, the static policy allocates CPUs using a topology-aware best-fit allocation. +On SMT enabled systems, the policy can allocate individual virtual cores, which correspond to hardware threads. +This can lead to different containers sharing the same physical cores; this behaviour in turn contributes +to the [noisy neighbours problem](https://en.wikipedia.org/wiki/Cloud_computing_issues#Performance_interference_and_noisy_neighbors). +With the option enabled, the pod will be admitted by the kubelet only if the CPU request of all its containers +can be fulfilled by allocating full physical cores. +If the pod does not pass the admission, it will be put in Failed state with the message `SMTAlignmentError`. diff --git a/content/en/docs/tasks/administer-cluster/declare-network-policy.md b/content/en/docs/tasks/administer-cluster/declare-network-policy.md index fed4a77f9d..7acbaa9e7d 100644 --- a/content/en/docs/tasks/administer-cluster/declare-network-policy.md +++ b/content/en/docs/tasks/administer-cluster/declare-network-policy.md @@ -18,6 +18,7 @@ This document helps you get started using the Kubernetes [NetworkPolicy API](/do Make sure you've configured a network provider with network policy support. There are a number of network providers that support NetworkPolicy, including: +* [Antrea](/docs/tasks/administer-cluster/network-policy-provider/antrea-network-policy/) * [Calico](/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy/) * [Cilium](/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/) * [Kube-router](/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/) diff --git a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md index 06de85b305..bd2fb3684c 100644 --- a/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md +++ b/content/en/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -28,13 +28,13 @@ explains how to use `kubeadm` to migrate from `kube-dns`. DNS is a built-in Kubernetes service launched automatically using the _addon manager_ -[cluster add-on](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md). +[cluster add-on](http://releases.k8s.io/master/cluster/addons/README.md). As of Kubernetes v1.12, CoreDNS is the recommended DNS Server, replacing kube-dns. If your cluster originally used kube-dns, you may still have `kube-dns` deployed rather than CoreDNS. {{< note >}} -Both the CoreDNS and kube-dns Service are named `kube-dns` in the `metadata.name` field. +The CoreDNS Service is named `kube-dns` in the `metadata.name` field. This is so that there is greater interoperability with workloads that relied on the legacy `kube-dns` Service name to resolve addresses internal to the cluster. Using a Service named `kube-dns` abstracts away the implementation detail of which DNS provider is running behind that common name. {{< /note >}} @@ -179,17 +179,14 @@ During translation, all FQDN nameservers will be omitted from the CoreDNS config CoreDNS supports the features of kube-dns and more. A ConfigMap created for kube-dns to support `StubDomains`and `upstreamNameservers` translates to the `forward` plugin in CoreDNS. -Similarly, the `Federations` plugin in kube-dns translates to the `federation` plugin in CoreDNS. ### Example -This example ConfigMap for kube-dns specifies federations, stubdomains and upstreamnameservers: +This example ConfigMap for kube-dns specifies stubdomains and upstreamnameservers: ```yaml apiVersion: v1 data: - federations: | - {"foo" : "foo.feddomain.com"} stubDomains: | {"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]} upstreamNameservers: | @@ -199,13 +196,6 @@ kind: ConfigMap The equivalent configuration in CoreDNS creates a Corefile: -* For federations: -``` -federation cluster.local { - foo foo.feddomain.com -} -``` - * For stubDomains: ```yaml abc.com:53 { diff --git a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md index faed4e1cb1..6bc41d2170 100644 --- a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md +++ b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md @@ -288,6 +288,13 @@ This should probably be implemented eventually. Linux's libc (a.k.a. glibc) has a limit for the DNS `nameserver` records to 3 by default. What's more, for the glibc versions which are older than glibc-2.17-222 ([the new versions update see this issue](https://access.redhat.com/solutions/58028)), the allowed number of DNS `search` records has been limited to 6 ([see this bug from 2005](https://bugzilla.redhat.com/show_bug.cgi?id=168253)). Kubernetes needs to consume 1 `nameserver` record and 3 `search` records. This means that if a local installation already uses 3 `nameserver`s or uses more than 3 `search`es while your glibc version is in the affected list, some of those settings will be lost. To work around the DNS `nameserver` records limit, the node can run `dnsmasq`, which will provide more `nameserver` entries. You can also use kubelet's `--resolv-conf` flag. To fix the DNS `search` records limit, consider upgrading your linux distribution or upgrading to an unaffected version of glibc. +{{< note >}} + +With [Expanded DNS Configuration](/docs/concepts/services-networking/dns-pod-service/#expanded-dns-configuration), +Kubernetes allows more DNS `search` records. + +{{< /note >}} + If you are using Alpine version 3.3 or earlier as your base image, DNS may not work properly due to a known issue with Alpine. Kubernetes [issue 30215](https://github.com/kubernetes/kubernetes/issues/30215) diff --git a/content/en/docs/tasks/administer-cluster/enabling-endpointslices.md b/content/en/docs/tasks/administer-cluster/enabling-endpointslices.md deleted file mode 100644 index d984652de8..0000000000 --- a/content/en/docs/tasks/administer-cluster/enabling-endpointslices.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -reviewers: -- bowei -- freehan -title: Enabling EndpointSlices -content_type: task ---- - - -This page provides an overview of enabling EndpointSlices in Kubernetes. - - - -## {{% heading "prerequisites" %}} - - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - - -## Introduction - -EndpointSlices provide a scalable and extensible alternative to Endpoints in -Kubernetes. They build on top of the base of functionality provided by Endpoints -and extend that in a scalable way. When Services have a large number (>100) of -network endpoints, they will be split into multiple smaller EndpointSlice -resources instead of a single large Endpoints resource. - -## Enabling EndpointSlices - -{{< feature-state for_k8s_version="v1.17" state="beta" >}} - -{{< note >}} -The EndpointSlice resource was designed to address shortcomings in a earlier -resource: Endpoints. Some Kubernetes components and third-party applications -continue to use and rely on Endpoints. Whilst that remains the case, -EndpointSlices should be seen as an addition to Endpoints in a cluster, not as -an outright replacement. -{{< /note >}} - -EndpointSlice functionality in Kubernetes is made up of several different -components, most are enabled by default: -* _The EndpointSlice API_: EndpointSlices are part of the - `discovery.k8s.io/v1beta1` API. This is beta and enabled by default since - Kubernetes 1.17. All components listed below are dependent on this API being - enabled. -* _The EndpointSlice Controller_: This {{< glossary_tooltip text="controller" - term_id="controller" >}} maintains EndpointSlices for Services and the Pods - they reference. This is controlled by the `EndpointSlice` feature gate. It has - been enabled by default since Kubernetes 1.18. -* _The EndpointSliceMirroring Controller_: This {{< glossary_tooltip - text="controller" term_id="controller" >}} mirrors custom Endpoints to - EndpointSlices. This is controlled by the `EndpointSlice` feature gate. It has - been enabled by default since Kubernetes 1.19. -* _Kube-Proxy_: When {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy">}} - is configured to use EndpointSlices, it can support higher numbers of Service - endpoints. This is controlled by the `EndpointSliceProxying` feature gate on - Linux and `WindowsEndpointSliceProxying` on Windows. It has been enabled by - default on Linux since Kubernetes 1.19. It is not enabled by default for - Windows nodes. To configure kube-proxy to use EndpointSlices on Windows, you - can enable the `WindowsEndpointSliceProxying` [feature - gate](/docs/reference/command-line-tools-reference/feature-gates/) on - kube-proxy. - - -## API fields - -Some fields in the EndpointSlice API are feature-gated. - -- The `EndpointSliceNodeName` feature gate controls access to the `nodeName` - field. This is an alpha feature that is disabled by default. -- The `EndpointSliceTerminating` feature gate controls access to the `serving` - and `terminating` condition fields. This is an alpha feature that is disabled - by default. - -## Using EndpointSlices - -With EndpointSlices fully enabled in your cluster, you should see corresponding -EndpointSlice resources for each Endpoints resource. In addition to supporting -existing Endpoints functionality, EndpointSlices will allow for greater -scalability and extensibility of network endpoints in your cluster. - -## {{% heading "whatsnext" %}} - - -* Read about [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) -* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) - - diff --git a/content/en/docs/tasks/administer-cluster/enabling-service-topology.md b/content/en/docs/tasks/administer-cluster/enabling-service-topology.md index 998bb8b2e5..8fd39a7e50 100644 --- a/content/en/docs/tasks/administer-cluster/enabling-service-topology.md +++ b/content/en/docs/tasks/administer-cluster/enabling-service-topology.md @@ -5,52 +5,51 @@ reviewers: - imroc title: Enabling Service Topology content_type: task +min-kubernetes-server-version: 1.17 --- -This page provides an overview of enabling Service Topology in Kubernetes. +{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} +This feature, specifically the alpha `topologyKeys` field, is deprecated since +Kubernetes v1.21. +[Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints/), +introduced in Kubernetes v1.21, provide similar functionality. +_Service Topology_ enables a {{< glossary_tooltip term_id="service">}} to route traffic based upon the Node +topology of the cluster. For example, a service can specify that traffic be +preferentially routed to endpoints that are on the same Node as the client, or +in the same availability zone. ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - -## Introduction - -_Service Topology_ enables a service to route traffic based upon the Node -topology of the cluster. For example, a service can specify that traffic be -preferentially routed to endpoints that are on the same Node as the client, or -in the same availability zone. - -## Prerequisites - The following prerequisites are needed in order to enable topology aware service routing: - * Kubernetes 1.17 or later - * {{< glossary_tooltip text="Kube-proxy" term_id="kube-proxy" >}} running in iptables mode or IPVS mode - * Enable [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/) + * Kubernetes v1.17 or later + * Configure {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} to run in iptables mode or IPVS mode + + + ## Enable Service Topology -{{< feature-state for_k8s_version="v1.17" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} -To enable service topology, enable the `ServiceTopology` and `EndpointSlice` feature gate for all Kubernetes components: +To enable service topology, enable the `ServiceTopology` +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for all Kubernetes components: ``` ---feature-gates="ServiceTopology=true,EndpointSlice=true" +--feature-gates="ServiceTopology=true` ``` - ## {{% heading "whatsnext" %}} - -* Read about the [Service Topology](/docs/concepts/services-networking/service-topology) concept -* Read about [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices) +* Read about [Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints/), the replacement for the `topologyKeys` field. +* Read about [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/) +* Read about the [Service Topology](/docs/concepts/services-networking/service-topology/) concept * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/en/docs/tasks/administer-cluster/enabling-topology-aware-hints.md b/content/en/docs/tasks/administer-cluster/enabling-topology-aware-hints.md new file mode 100644 index 0000000000..dadc653f4e --- /dev/null +++ b/content/en/docs/tasks/administer-cluster/enabling-topology-aware-hints.md @@ -0,0 +1,40 @@ +--- +reviewers: +- robscott +title: Enabling Topology Aware Hints +content_type: task +min-kubernetes-server-version: 1.21 +--- + + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +_Topology Aware Hints_ enable topology aware routing with topology hints +included in {{< glossary_tooltip text="EndpointSlices" term_id="endpoint-slice" >}}. +This approach tries to keep traffic close to where it originated from; +you might do this to reduce costs, or to improve network performance. + +## {{% heading "prerequisites" %}} + + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +The following prerequisite is needed in order to enable topology aware hints: + +* Configure the {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}} to run in + iptables mode or IPVS mode +* Ensure that you have not disabled EndpointSlices + +## Enable Topology Aware Hints + +To enable service topology hints, enable the `TopologyAwareHints` [feature +gate](/docs/reference/command-line-tools-reference/feature-gates/) for the +kube-apiserver, kube-controller-manager, and kube-proxy: + +``` +--feature-gates="TopologyAwareHints=true" +``` + +## {{% heading "whatsnext" %}} + +* Read about [Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints) for Services +* Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/en/docs/tasks/administer-cluster/encrypt-data.md b/content/en/docs/tasks/administer-cluster/encrypt-data.md index 8499855bb0..66427133b2 100644 --- a/content/en/docs/tasks/administer-cluster/encrypt-data.md +++ b/content/en/docs/tasks/administer-cluster/encrypt-data.md @@ -157,7 +157,7 @@ program to retrieve the contents of your secret. kubectl describe secret secret1 -n default ``` - should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](/docs/concepts/configuration/secret#decoding-a-secret) to + should match `mykey: bXlkYXRh`, mydata is encoded, check [decoding a secret](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret) to completely decode the secret. diff --git a/content/en/docs/tasks/administer-cluster/highly-available-master.md b/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md similarity index 52% rename from content/en/docs/tasks/administer-cluster/highly-available-master.md rename to content/en/docs/tasks/administer-cluster/highly-available-control-plane.md index 141b4ee9cd..6f57b441e7 100644 --- a/content/en/docs/tasks/administer-cluster/highly-available-master.md +++ b/content/en/docs/tasks/administer-cluster/highly-available-control-plane.md @@ -1,16 +1,17 @@ --- reviewers: - jszczepkowski -title: Set up High-Availability Kubernetes Masters +title: Set up a High-Availability Control Plane content_type: task +aliases: [ '/docs/tasks/administer-cluster/highly-available-master/' ] --- {{< feature-state for_k8s_version="v1.5" state="alpha" >}} -You can replicate Kubernetes masters in `kube-up` or `kube-down` scripts for Google Compute Engine. -This document describes how to use kube-up/down scripts to manage highly available (HA) masters and how HA masters are implemented for use with GCE. +You can replicate Kubernetes control plane nodes in `kube-up` or `kube-down` scripts for Google Compute Engine. However this scripts are not suitable for any sort of production use, it's widely used in the project's CI. +This document describes how to use kube-up/down scripts to manage a highly available (HA) control plane and how HA control planes are implemented for use with GCE. @@ -28,17 +29,17 @@ This document describes how to use kube-up/down scripts to manage highly availab To create a new HA-compatible cluster, you must set the following flags in your `kube-up` script: -* `MULTIZONE=true` - to prevent removal of master replicas kubelets from zones different than server's default zone. -Required if you want to run master replicas in different zones, which is recommended. +* `MULTIZONE=true` - to prevent removal of control plane kubelets from zones different than server's default zone. +Required if you want to run control plane nodes in different zones, which is recommended. * `ENABLE_ETCD_QUORUM_READ=true` - to ensure that reads from all API servers will return most up-to-date data. If true, reads will be directed to leader etcd replica. Setting this value to true is optional: reads will be more reliable but will also be slower. -Optionally, you can specify a GCE zone where the first master replica is to be created. +Optionally, you can specify a GCE zone where the first control plane node is to be created. Set the following flag: -* `KUBE_GCE_ZONE=zone` - zone where the first master replica will run. +* `KUBE_GCE_ZONE=zone` - zone where the first control plane node will run. The following sample command sets up a HA-compatible cluster in the GCE zone europe-west1-b: @@ -46,50 +47,52 @@ The following sample command sets up a HA-compatible cluster in the GCE zone eur MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh ``` -Note that the commands above create a cluster with one master; -however, you can add new master replicas to the cluster with subsequent commands. +Note that the commands above create a cluster with one control plane node; +however, you can add new control plane nodes to the cluster with subsequent commands. -## Adding a new master replica +## Adding a new control plane node -After you have created an HA-compatible cluster, you can add master replicas to it. -You add master replicas by using a `kube-up` script with the following flags: +After you have created an HA-compatible cluster, you can add control plane nodes to it. +You add control plane nodes by using a `kube-up` script with the following flags: -* `KUBE_REPLICATE_EXISTING_MASTER=true` - to create a replica of an existing -master. +* `KUBE_REPLICATE_EXISTING_MASTER=true` - to create a replica of an existing control plane +node. -* `KUBE_GCE_ZONE=zone` - zone where the master replica will run. -Must be in the same region as other replicas' zones. +* `KUBE_GCE_ZONE=zone` - zone where the control plane node will run. +Must be in the same region as other control plane nodes' zones. You don't need to set the `MULTIZONE` or `ENABLE_ETCD_QUORUM_READS` flags, as those are inherited from when you started your HA-compatible cluster. -The following sample command replicates the master on an existing HA-compatible cluster: +The following sample command replicates the control plane node on an existing +HA-compatible cluster: ```shell KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh ``` -## Removing a master replica +## Removing a control plane node -You can remove a master replica from an HA cluster by using a `kube-down` script with the following flags: +You can remove a control plane node from an HA cluster by using a `kube-down` script with the following flags: * `KUBE_DELETE_NODES=false` - to restrain deletion of kubelets. -* `KUBE_GCE_ZONE=zone` - the zone from where master replica will be removed. +* `KUBE_GCE_ZONE=zone` - the zone from where the control plane node will be removed. -* `KUBE_REPLICA_NAME=replica_name` - (optional) the name of master replica to remove. -If empty: any replica from the given zone will be removed. +* `KUBE_REPLICA_NAME=replica_name` - (optional) the name of control plane node to +remove. If empty: any replica from the given zone will be removed. -The following sample command removes a master replica from an existing HA cluster: +The following sample command removes a control plane node from an existing HA cluster: ```shell KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh ``` -## Handling master replica failures +## Handling control plane node failures -If one of the master replicas in your HA cluster fails, -the best practice is to remove the replica from your cluster and add a new replica in the same zone. +If one of the control plane nodes in your HA cluster fails, +the best practice is to remove the node from your cluster and add a new control plane +node in the same zone. The following sample commands demonstrate this process: 1. Remove the broken replica: @@ -98,26 +101,31 @@ The following sample commands demonstrate this process: KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh ``` -
  1. Add a new replica in place of the old one:
+
  1. Add a new node in place of the old one:
```shell KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh ``` -## Best practices for replicating masters for HA clusters +## Best practices for replicating control plane nodes for HA clusters -* Try to place master replicas in different zones. During a zone failure, all masters placed inside the zone will fail. +* Try to place control plane nodes in different zones. During a zone failure, all +control plane nodes placed inside the zone will fail. To survive zone failure, also place nodes in multiple zones (see [multiple-zones](/docs/setup/best-practices/multiple-zones/) for details). -* Do not use a cluster with two master replicas. Consensus on a two-replica cluster requires both replicas running when changing persistent state. -As a result, both replicas are needed and a failure of any replica turns cluster into majority failure state. -A two-replica cluster is thus inferior, in terms of HA, to a single replica cluster. +* Do not use a cluster with two control plane nodes. Consensus on a two-node +control plane requires both nodes running when changing persistent state. +As a result, both nodes are needed and a failure of any node turns the cluster +into majority failure state. +A two-node control plane is thus inferior, in terms of HA, to a cluster with +one control plane node. -* When you add a master replica, cluster state (etcd) is copied to a new instance. +* When you add a control plane node, cluster state (etcd) is copied to a new instance. If the cluster is large, it may take a long time to duplicate its state. -This operation may be sped up by migrating etcd data directory, as described [here](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration) -(we are considering adding support for etcd data dir migration in future). +This operation may be sped up by migrating the etcd data directory, as described in +the [etcd administration guide](https://etcd.io/docs/v2.3/admin_guide/#member-migration) +(we are considering adding support for etcd data dir migration in the future). @@ -125,11 +133,19 @@ This operation may be sped up by migrating etcd data directory, as described [he ## Implementation notes -![ha-master-gce](/images/docs/ha-master-gce.png) +![ha-control-plane](/docs/images/ha-control-plane.svg) ### Overview +The figure above illustrates three control plane nodes and their components in a highly available cluster. The control plane node’s components employ the following methods: -Each of master replicas will run the following components in the following mode: +- etcd: instances are clustered together using consensus. + +- Controllers, scheduler and cluster auto-scaler: only one instance of each will be active in a cluster using a lease mechanism. + +- Add-on manager: each works independently to keep add-ons in sync. + +In addition, a load balancer operating in front of the API servers routes external and internal traffic to the control plane nodes. +Each of the control plane nodes will run the following components in the following mode: * etcd instance: all instances will be clustered together using consensus; @@ -143,27 +159,27 @@ In addition, there will be a load balancer in front of API servers that will rou ### Load balancing -When starting the second master replica, a load balancer containing the two replicas will be created +When starting the second control plane node, a load balancer containing the two replicas will be created and the IP address of the first replica will be promoted to IP address of load balancer. -Similarly, after removal of the penultimate master replica, the load balancer will be removed and its IP address will be assigned to the last remaining replica. +Similarly, after removal of the penultimate control plane node, the load balancer will be removed and its IP address will be assigned to the last remaining replica. Please note that creation and removal of load balancer are complex operations and it may take some time (~20 minutes) for them to propagate. -### Master service & kubelets +### Control plane service & kubelets Instead of trying to keep an up-to-date list of Kubernetes apiserver in the Kubernetes service, the system directs all traffic to the external IP: -* in one master cluster the IP points to the single master, +* in case of a single node control plane, the IP points to the control plane node, -* in multi-master cluster the IP points to the load balancer in-front of the masters. +* in case of an HA control plane, the IP points to the load balancer in-front of the control plane nodes. -Similarly, the external IP will be used by kubelets to communicate with master. +Similarly, the external IP will be used by kubelets to communicate with the control plane. -### Master certificates +### Control plane node certificates -Kubernetes generates Master TLS certificates for the external public IP and local IP for each replica. -There are no certificates for the ephemeral public IP for replicas; -to access a replica via its ephemeral public IP, you must skip TLS verification. +Kubernetes generates TLS certificates for the external public IP and local IP for each control plane node. +There are no certificates for the ephemeral public IP for control plane nodes; +to access a control plane node via its ephemeral public IP, you must skip TLS verification. ### Clustering etcd @@ -172,7 +188,7 @@ To make such deployment secure, communication between etcd instances is authoriz ### API server identity -{{< feature-state state="alpha" for_k8s_version="v1.20" >}} +{{< feature-state state="alpha" for_k8s_version="v1.20" >}} The API Server Identity feature is controlled by a [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) @@ -207,4 +223,3 @@ server coordination (for example, the `StorageVersionAPI` feature gate). [Automated HA master deployment - design doc](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md) - diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/_index.md b/content/en/docs/tasks/administer-cluster/kubeadm/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index aad5f13909..56af353f89 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -163,7 +163,7 @@ Instructions to do so are available at [Install Docker Engine - Enterprise on Wi #### Install wins, kubelet, and kubeadm ```PowerShell -curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1 +curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1 .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} ``` @@ -188,7 +188,7 @@ To install a specific version of containerD specify the version with -ContainerD ```powershell # Example -.\Install-Containerd.ps1 -ContainerDVersion v1.4.1 +.\Install-Containerd.ps1 -ContainerDVersion 1.4.1 ``` {{< /note >}} @@ -206,7 +206,7 @@ If you're using a different interface rather than Ethernet (i.e. "Ethernet0 2") #### Install wins, kubelet, and kubeadm ```PowerShell -curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1 +curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1 .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD ``` diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md b/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md new file mode 100644 index 0000000000..31a9ff0e33 --- /dev/null +++ b/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md @@ -0,0 +1,125 @@ +--- +title: Configuring a cgroup driver +content_type: task +weight: 10 +--- + + + +This page explains how to configure the kubelet cgroup driver to match the container +runtime cgroup driver for kubeadm clusters. + +## {{% heading "prerequisites" %}} + +You should be familiar with the Kubernetes +[container runtime requirements](/docs/setup/production-environment/container-runtimes). + + + +## Configuring the container runtime cgroup driver + +The [Container runtimes](/docs/setup/production-environment/container-runtimes) page +explains that the `systemd` driver is recommended for kubeadm based setups instead +of the `cgroupfs` driver, because kubeadm manages the kubelet as a systemd service. + +The page also provides details on how to setup a number of different container runtimes with the +`systemd` driver by default. + +## Configuring the kubelet cgroup driver + +kubeadm allows you to pass a `KubeletConfiguration` structure during `kubeadm init`. +This `KubeletConfiguration` can include the `cgroupDriver` field which controls the cgroup +driver of the kubelet. + +{{< note >}} + +In v1.22, if the user is not setting the `cgroupDriver` field under `KubeletConfiguration`, +`kubeadm` will default it to `systemd`. +{{< /note >}} + +A minimal example of configuring the field explicitly: + +```yaml +# kubeadm-config.yaml +kind: ClusterConfiguration +apiVersion: kubeadm.k8s.io/v1beta3 +kubernetesVersion: v1.21.0 +--- +kind: KubeletConfiguration +apiVersion: kubelet.config.k8s.io/v1beta1 +cgroupDriver: systemd +``` + +Such a configuration file can then be passed to the kubeadm command: + +```shell +kubeadm init --config kubeadm-config.yaml +``` + +{{< note >}} +Kubeadm uses the same `KubeletConfiguration` for all nodes in the cluster. +The `KubeletConfiguration` is stored in a [ConfigMap](/docs/concepts/configuration/configmap) +object under the `kube-system` namespace. + +Executing the sub commands `init`, `join` and `upgrade` would result in kubeadm +writing the `KubeletConfiguration` as a file under `/var/lib/kubelet/config.yaml` +and passing it to the local node kubelet. +{{< /note >}} + +## Using the `cgroupfs` driver + +As this guide explains using the `cgroupfs` driver with kubeadm is not recommended. + +To continue using `cgroupfs` and to prevent `kubeadm upgrade` from modifying the +`KubeletConfiguration` cgroup driver on existing setups, you must be explicit +about its value. This applies to a case where you do not wish future versions +of kubeadm to apply the `systemd` driver by default. + +See the below section on "Modify the kubelet ConfigMap" for details on +how to be explicit about the value. + +If you wish to configure a container runtime to use the `cgroupfs` driver, +you must refer to the documentation of the container runtime of your choice. + +## Migrating to the `systemd` driver + +To change the cgroup driver of an existing kubeadm cluster to `systemd` in-place, +a similar procedure to a kubelet upgrade is required. This must include both +steps outlined below. + +{{< note >}} +Alternatively, it is possible to replace the old nodes in the cluster with new ones +that use the `systemd` driver. This requires executing only the first step below +before joining the new nodes and ensuring the workloads can safely move to the new +nodes before deleting the old nodes. +{{< /note >}} + +### Modify the kubelet ConfigMap + +- Find the kubelet ConfigMap name using `kubectl get cm -n kube-system | grep kubelet-config`. +- Call `kubectl edit cm kubelet-config-x.yy -n kube-system` (replace `x.yy` with +the Kubernetes version). +- Either modify the existing `cgroupDriver` value or add a new field that looks like this: + + ```yaml + cgroupDriver: systemd + ``` + This field must be present under the `kubelet:` section of the ConfigMap. + +### Update the cgroup driver on all nodes + +For each node in the cluster: + +- [Drain the node](/docs/tasks/administer-cluster/safely-drain-node) using `kubectl drain --ignore-daemonsets` +- Stop the kubelet using `systemctl stop kubelet` +- Stop the container runtime +- Modify the container runtime cgroup driver to `systemd` +- Set `cgroupDriver: systemd` in `/var/lib/kubelet/config.yaml` +- Start the container runtime +- Start the kubelet using `systemctl start kubelet` +- [Uncordon the node](/docs/tasks/administer-cluster/safely-drain-node) using `kubectl uncordon ` + +Execute these steps on nodes one at a time to ensure workloads +have sufficient time to schedule on different nodes. + +Once the process is complete ensure that all nodes and workloads are healthy. diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index dc7af4a329..3d4959b536 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -85,7 +85,11 @@ Additionally, kubeadm informs the user if the certificate is externally managed; {{< /warning >}} {{< note >}} -`kubelet.conf` is not included in the list above because kubeadm configures kubelet for automatic certificate renewal. +`kubelet.conf` is not included in the list above because kubeadm configures kubelet +for [automatic certificate renewal](/docs/tasks/tls/certificate-rotation/) +with rotatable certificates under `/var/lib/kubelet/pki`. +To repair an expired kubelet client certificate see +[Kubelet client certificate rotation fails](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#kubelet-client-cert). {{< /note >}} {{< warning >}} @@ -122,7 +126,17 @@ command. In that case, you should explicitly set `--certificate-renewal=true`. You can renew your certificates manually at any time with the `kubeadm certs renew` command. -This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`. +This command performs the renewal using CA (or front-proxy-CA) certificate and key stored in `/etc/kubernetes/pki`. + +After running the command you should restart the control plane Pods. This is required since +dynamic certificate reload is currently not supported for all components and certificates. +[Static Pods](/docs/tasks/configure-pod-container/static-pod/) are managed by the local kubelet +and not by the API Server, thus kubectl cannot be used to delete and restart them. +To restart a static Pod you can temporarily remove its manifest file from `/etc/kubernetes/manifests/` +and wait for 20 seconds (see the `fileCheckFrequency` value in [KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/). +The kubelet will terminate the Pod if it's no longer in the manifest directory. +You can then move the file back and after another `fileCheckFrequency` period, the kubelet will recreate +the Pod and the certificate renewal for the component can complete. {{< warning >}} If you are running an HA cluster, this command needs to be executed on all the control-plane nodes. @@ -142,7 +156,7 @@ The Kubernetes certificates normally reach their expiration date after one year. ## Renew certificates with the Kubernetes certificates API -This section provide more details about how to execute manual certificate renewal using the Kubernetes certificates API. +This section provides more details about how to execute manual certificate renewal using the Kubernetes certificates API. {{< caution >}} These are advanced topics for users who need to integrate their organization's certificate infrastructure into a kubeadm-built cluster. If the default kubeadm configuration satisfies your needs, you should let kubeadm manage certificates instead. @@ -157,10 +171,10 @@ The built-in signer is part of [`kube-controller-manager`](/docs/reference/comma To activate the built-in signer, you must pass the `--cluster-signing-cert-file` and `--cluster-signing-key-file` flags. -If you're creating a new cluster, you can use a kubeadm [configuration file](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2): +If you're creating a new cluster, you can use a kubeadm [configuration file](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3): ```yaml -apiVersion: kubeadm.k8s.io/v1beta2 +apiVersion: kubeadm.k8s.io/v1beta3 kind: ClusterConfiguration controllerManager: extraArgs: @@ -207,3 +221,71 @@ After a certificate is signed using your preferred method, the certificate and t Kubeadm does not support rotation or replacement of CA certificates out of the box. For more information about manual rotation or replacement of CA, see [manual rotation of CA certificates](/docs/tasks/tls/manual-rotation-of-ca-certificates/). + +## Enabling signed kubelet serving certificates {#kubelet-serving-certs} + +By default the kubelet serving certificate deployed by kubeadm is self-signed. +This means a connection from external services like the +[metrics-server](https://github.com/kubernetes-sigs/metrics-server) to a +kubelet cannot be secured with TLS. + +To configure the kubelets in a new kubeadm cluster to obtain properly signed serving +certificates you must pass the following minimal configuration to `kubeadm init`: + +```yaml +apiVersion: kubeadm.k8s.io/v1beta3 +kind: ClusterConfiguration +--- +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +serverTLSBootstrap: true +``` + +If you have already created the cluster you must adapt it by doing the following: + - Find and edit the `kubelet-config-{{< skew latestVersion >}}` ConfigMap in the `kube-system` namespace. +In that ConfigMap, the `kubelet` key has a +[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) +document as its value. Edit the KubeletConfiguration document to set `serverTLSBootstrap: true`. +- On each node, add the `serverTLSBootstrap: true` field in `/var/lib/kubelet/config.yaml` +and restart the kubelet with `systemctl restart kubelet` + +The field `serverTLSBootstrap: true` will enable the bootstrap of kubelet serving +certificates by requesting them from the `certificates.k8s.io` API. One known limitation +is that the CSRs (Certificate Signing Requests) for these certificates cannot be automatically +approved by the default signer in the kube-controller-manager - +[`kubernetes.io/kubelet-serving`](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers). +This will require action from the user or a third party controller. + +These CSRs can be viewed using: + +```shell +kubectl get csr +NAME AGE SIGNERNAME REQUESTOR CONDITION +csr-9wvgt 112s kubernetes.io/kubelet-serving system:node:worker-1 Pending +csr-lz97v 1m58s kubernetes.io/kubelet-serving system:node:control-plane-1 Pending +``` + +To approve them you can do the following: +```shell +kubectl certificate approve +``` + +By default, these serving certificate will expire after one year. Kubeadm sets the +`KubeletConfiguration` field `rotateCertificates` to `true`, which means that close +to expiration a new set of CSRs for the serving certificates will be created and must +be approved to complete the rotation. To understand more see +[Certificate Rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#certificate-rotation). + +If you are looking for a solution for automatic approval of these CSRs it is recommended +that you contact your cloud provider and ask if they have a CSR signer that verifies +the node identity with an out of band mechanism. + +{{% thirdparty-content %}} + +Third party custom controllers can be used: +- [kubelet-rubber-stamp](https://github.com/kontena/kubelet-rubber-stamp) + +Such a controller is not a secure mechanism unless it not only verifies the CommonName +in the CSR but also verifies the requested IPs and domain names. This would prevent +a malicious actor that has access to a kubelet client certificate to create +CSRs requesting serving certificates for any IP or domain name. diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 47ea403e9a..0b0139151a 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -9,17 +9,17 @@ weight: 20 This page explains how to upgrade a Kubernetes cluster created with kubeadm from version -{{< skew latestVersionAddMinor -1 >}}.x to version {{< skew latestVersion >}}.x, and from version -{{< skew latestVersion >}}.x to {{< skew latestVersion >}}.y (where `y > x`). Skipping MINOR versions +{{< skew currentVersionAddMinor -1 >}}.x to version {{< skew currentVersion >}}.x, and from version +{{< skew currentVersion >}}.x to {{< skew currentVersion >}}.y (where `y > x`). Skipping MINOR versions when upgrading is unsupported. To see information about upgrading clusters created using older versions of kubeadm, please refer to following pages instead: -- [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -2 >}} to {{< skew latestVersionAddMinor -1 >}}](https://v{{< skew latestVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) -- [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -3 >}} to {{< skew latestVersionAddMinor -2 >}}](https://v{{< skew latestVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) -- [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -4 >}} to {{< skew latestVersionAddMinor -3 >}}](https://v{{< skew latestVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) -- [Upgrading a kubeadm cluster from {{< skew latestVersionAddMinor -5 >}} to {{< skew latestVersionAddMinor -4 >}}](https://v{{< skew latestVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -2 >}} to {{< skew currentVersionAddMinor -1 >}}](https://v{{< skew currentVersionAddMinor -1 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -3 >}} to {{< skew currentVersionAddMinor -2 >}}](https://v{{< skew currentVersionAddMinor -2 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -4 >}} to {{< skew currentVersionAddMinor -3 >}}](https://v{{< skew currentVersionAddMinor -3 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) +- [Upgrading a kubeadm cluster from {{< skew currentVersionAddMinor -5 >}} to {{< skew currentVersionAddMinor -4 >}}](https://v{{< skew currentVersionAddMinor -4 "-" >}}.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) The upgrade workflow at high level is the following: @@ -45,19 +45,19 @@ The upgrade workflow at high level is the following: ## Determine which version to upgrade to -Find the latest stable {{< skew latestVersion >}} version using the OS package manager: +Find the latest patch release for Kubernetes {{< skew currentVersion >}} using the OS package manager: {{< tabs name="k8s_install_versions" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} apt update apt-cache madison kubeadm - # find the latest {{< skew latestVersion >}} version in the list - # it should look like {{< skew latestVersion >}}.x-00, where x is the latest patch + # find the latest {{< skew currentVersion >}} version in the list + # it should look like {{< skew currentVersion >}}.x-00, where x is the latest patch {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} yum list --showduplicates kubeadm --disableexcludes=kubernetes - # find the latest {{< skew latestVersion >}} version in the list - # it should look like {{< skew latestVersion >}}.x-0, where x is the latest patch + # find the latest {{< skew currentVersion >}} version in the list + # it should look like {{< skew currentVersion >}}.x-0, where x is the latest patch {{% /tab %}} {{< /tabs >}} @@ -74,20 +74,21 @@ Pick a control plane node that you wish to upgrade first. It must have the `/etc {{< tabs name="k8s_install_kubeadm_first_cp" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} - # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version + # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \ + apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubeadm - # since apt-get version 1.1 you can also use the following method apt-get update && \ - apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00 + apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} - # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version - yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes + # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version + yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes {{% /tab %}} {{< /tabs >}} +
- Verify that the download works and has the expected version: @@ -120,13 +121,13 @@ Failing to do so will cause `kubeadm upgrade apply` to exit with an error and no ```shell # replace x with the patch version you picked for this upgrade - sudo kubeadm upgrade apply v{{< skew latestVersion >}}.x + sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x ``` Once the command finishes you should see: ``` - [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew latestVersion >}}.x". Enjoy! + [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy! [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. ``` @@ -166,28 +167,25 @@ Also calling `kubeadm upgrade plan` and upgrading the CNI provider plugin is no ### Upgrade kubelet and kubectl -- Upgrade the kubelet and kubectl +- Upgrade the kubelet and kubectl: {{< tabs name="k8s_install_kubelet" >}} -{{< tab name="Ubuntu, Debian or HypriotOS" >}} - 
-    # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version
+{{% tab name="Ubuntu, Debian or HypriotOS" %}}
+    # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version
     apt-mark unhold kubelet kubectl && \
-    apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \
+    apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
     apt-mark hold kubelet kubectl
     -
     # since apt-get version 1.1 you can also use the following method
     apt-get update && \
-    apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00
-
-{{< /tab >}} -{{< tab name="CentOS, RHEL or Fedora" >}} - 
-    # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version
-    yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes
-
-{{< /tab >}} + apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 +{{% /tab %}} +{{% tab name="CentOS, RHEL or Fedora" %}} + # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version + yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes +{{% /tab %}} {{< /tabs >}} +
- Restart the kubelet: @@ -216,18 +214,18 @@ without compromising the minimum required capacity for running your workloads. {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} - # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version + # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm={{< skew latestVersion >}}.x-00 && \ + apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubeadm - # since apt-get version 1.1 you can also use the following method apt-get update && \ - apt-get install -y --allow-change-held-packages kubeadm={{< skew latestVersion >}}.x-00 + apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} - # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version - yum install -y kubeadm-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes + # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version + yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes {{% /tab %}} {{< /tabs >}} @@ -254,20 +252,21 @@ without compromising the minimum required capacity for running your workloads. {{< tabs name="k8s_kubelet_and_kubectl" >}} {{% tab name="Ubuntu, Debian or HypriotOS" %}} - # replace x in {{< skew latestVersion >}}.x-00 with the latest patch version + # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version apt-mark unhold kubelet kubectl && \ - apt-get update && apt-get install -y kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 && \ + apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ apt-mark hold kubelet kubectl - # since apt-get version 1.1 you can also use the following method apt-get update && \ - apt-get install -y --allow-change-held-packages kubelet={{< skew latestVersion >}}.x-00 kubectl={{< skew latestVersion >}}.x-00 + apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 {{% /tab %}} {{% tab name="CentOS, RHEL or Fedora" %}} - # replace x in {{< skew latestVersion >}}.x-0 with the latest patch version - yum install -y kubelet-{{< skew latestVersion >}}.x-0 kubectl-{{< skew latestVersion >}}.x-0 --disableexcludes=kubernetes + # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version + yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes {{% /tab %}} {{< /tabs >}} +
- Restart the kubelet: @@ -328,7 +327,7 @@ and post-upgrade manifest file for a certain component, a backup file for it wil - Makes sure the control plane images are available or available to pull to the machine. - Generates replacements and/or uses user supplied overwrites if component configs require version upgrades. - Upgrades the control plane components or rollbacks if any of them fails to come up. -- Applies the new `kube-dns` and `kube-proxy` manifests and makes sure that all necessary RBAC rules are created. +- Applies the new `CoreDNS` and `kube-proxy` manifests and makes sure that all necessary RBAC rules are created. - Creates new certificate and key files of the API server and backs up old files if they're about to expire in 180 days. `kubeadm upgrade node` does the following on additional control plane nodes: diff --git a/content/en/docs/tasks/administer-cluster/kubelet-config-file.md b/content/en/docs/tasks/administer-cluster/kubelet-config-file.md index b49c84220a..668f4532a5 100644 --- a/content/en/docs/tasks/administer-cluster/kubelet-config-file.md +++ b/content/en/docs/tasks/administer-cluster/kubelet-config-file.md @@ -30,17 +30,18 @@ Here is an example of what this file might look like: ``` apiVersion: kubelet.config.k8s.io/v1beta1 kind: KubeletConfiguration +address: "192.168.0.8", +port: 20250, +serializeImagePulls: false, evictionHard: memory.available: "200Mi" ``` -In the example, the Kubelet is configured to evict Pods when available memory drops below 200Mi. +In the example, the Kubelet is configured to serve on IP address 192.168.0.8 and port 20250, pull images in parallel, +and evict Pods when available memory drops below 200Mi. All other Kubelet configuration values are left at their built-in defaults, unless overridden by flags. Command line flags which target the same value as a config file will override that value. -For a trick to generate a configuration file from a live node, see -[Reconfigure a Node's Kubelet in a Live Cluster](/docs/tasks/administer-cluster/reconfigure-kubelet). - ## Start a Kubelet process configured via the config file {{< note >}} @@ -65,12 +66,6 @@ In the above example, this version is `kubelet.config.k8s.io/v1beta1`. -## Relationship to Dynamic Kubelet Config - -If you are using the [Dynamic Kubelet Configuration](/docs/tasks/administer-cluster/reconfigure-kubelet) -feature, the combination of configuration provided via `--config` and any flags which override these values -is considered the default "last known good" configuration by the automatic rollback mechanism. - ## {{% heading "whatsnext" %}} - Learn more about kubelet configuration by checking the diff --git a/content/en/docs/tasks/administer-cluster/kubelet-in-userns.md b/content/en/docs/tasks/administer-cluster/kubelet-in-userns.md new file mode 100644 index 0000000000..bed842b6a4 --- /dev/null +++ b/content/en/docs/tasks/administer-cluster/kubelet-in-userns.md @@ -0,0 +1,259 @@ +--- +title: Running Kubernetes Node Components as a Non-root User +content_type: task +min-kubernetes-server-version: 1.22 +--- + + + +{{< feature-state for_k8s_version="v1.22" state="alpha" >}} + +This document describes how to run Kubernetes Node components such as kubelet, CRI, OCI, and CNI +without root privileges, by using a {{< glossary_tooltip text="user namespace" term_id="userns" >}}. + +This technique is also known as _rootless mode_. + +{{< note >}} +This document describes how to run Kubernetes Node components (and hence pods) a non-root user. + +If you are just looking for how to run a pod as a non-root user, see [SecurityContext](/docs/tasks/configure-pod-container/security-context/). +{{< /note >}} + +## {{% heading "prerequisites" %}} + +{{% version-check %}} + +* [Enable Cgroup v2](https://rootlesscontaine.rs/getting-started/common/cgroup2/) +* [Enable systemd with user session](https://rootlesscontaine.rs/getting-started/common/login/) +* [Configure several sysctl values, depending on host Linux distribution](https://rootlesscontaine.rs/getting-started/common/sysctl/) +* [Ensure that your unprivileged user is listed in `/etc/subuid` and `/etc/subgid`](https://rootlesscontaine.rs/getting-started/common/subuid/) + +* `KubeletInUserNamespace` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) + + + +## Running Kubernetes inside Rootless Docker/Podman + +### kind + +[kind](https://kind.sigs.k8s.io/) supports running Kubernetes inside Rootless Docker or Rootless Podman. + +See [Running kind with Rootless Docker](https://kind.sigs.k8s.io/docs/user/rootless/). + +### minikube + +[minikube](https://minikube.sigs.k8s.io/) also supports running Kubernetes inside Rootless Docker. + +See the page about the [docker](https://minikube.sigs.k8s.io/docs/drivers/docker/) driver in the Minikube documentation. + +Rootless Podman is not supported. + + + +## Running Rootless Kubernetes directly on a host + +{{% thirdparty-content %}} + +### K3s + +[K3s](https://k3s.io/) experimentally supports rootless mode. + +See [Running K3s with Rootless mode](https://rancher.com/docs/k3s/latest/en/advanced/#running-k3s-with-rootless-mode-experimental) for the usage. + +### Usernetes +[Usernetes](https://github.com/rootless-containers/usernetes) is a reference distribution of Kubernetes that can be installed under `$HOME` directory without the root privilege. + +Usernetes supports both containerd and CRI-O as CRI runtimes. +Usernetes supports multi-node clusters using Flannel (VXLAN). + +See [the Usernetes repo](https://github.com/rootless-containers/usernetes) for the usage. + +## Manually deploy a node that runs the kubelet in a user namespace {#userns-the-hard-way} + +This section provides hints for running Kubernetes in a user namespace manually. + +{{< note >}} +This section is intended to be read by developers of Kubernetes distributions, not by end users. +{{< /note >}} + +### Creating a user namespace + +The first step is to create a {{< glossary_tooltip text="user namespace" term_id="userns" >}}. + +If you are trying to run Kubernetes in a user-namespaced container such as +Rootless Docker/Podman or LXC/LXD, you are all set, and you can go to the next subsection. + +Otherwise you have to create a user namespace by yourself, by calling `unshare(2)` with `CLONE_NEWUSER`. + +A user namespace can be also unshared by using command line tools such as: +- [RootlessKit](https://github.com/rootless-containers/rootlesskit) +- [become-root](https://github.com/giuseppe/become-root) +- [`unshare(1)`](https://man7.org/linux/man-pages/man1/unshare.1.html) + +After unsharing the user namespace, you will also have to unshare other namespaces such as mount namespace. + +You do *not* need to call `chroot()` nor `pivot_root()` after unsharing the mount namespace, +however, you have to mount writable filesystems on several directories *in* the namespace. + +At least, the following directories need to be writable *in* the namespace (not *outside* the namespace): + +- `/etc` +- `/run` +- `/var/logs` +- `/var/lib/kubelet` +- `/var/lib/cni` +- `/var/lib/containerd` (for containerd) +- `/var/lib/containers` (for CRI-O) + +### Creating a delegated cgroup tree + +In addition to the user namespace, you also need to have a writable cgroup tree with cgroup v2. + +{{< note >}} +Kubernetes support for running Node components in user namespaces requires cgroup v2. +Cgroup v1 is not supported. +{{< /note >}} + +If you are trying to run Kubernetes in Rootless Docker/Podman or LXC/LXD on a systemd-based host, you are all set. + +Otherwise you have to create a systemd unit with `Delegate=yes` property to delegate a cgroup tree with writable permission. + +On your node, systemd must already be configured to allow delegation; for more details, see +[cgroup v2](https://rootlesscontaine.rs/getting-started/common/cgroup2/) in the Rootless +Containers documentation. + +### Configuring network +{{% thirdparty-content %}} + +The network namespace of the Node components has to have a non-loopback interface, which can be for example configured with +slirp4netns, VPNKit, or lxc-user-nic. + +The network namespaces of the Pods can be configured with regular CNI plugins. +For multi-node networking, Flannel (VXLAN, 8472/UDP) is known to work. + +Ports such as the kubelet port (10250/TCP) and `NodePort` service ports have to be exposed from the Node network namespace to +the host with an external port forwarder, such as RootlessKit, slirp4netns, or socat. + +You can use the port forwarder from K3s; see https://github.com/k3s-io/k3s/blob/v1.21.2+k3s1/pkg/rootlessports/controller.go + +### Configuring CRI + +The kubelet relies on a container runtime. You should deploy a container runtime such as containerd or CRI-O and ensure that it is running within the user namespace before the kubelet starts. + +{{< tabs name="cri" >}} +{{% tab name="containerd" %}} + +Running CRI plugin of containerd in a user namespace is supported since containerd 1.4. + +Running containerd within a user namespace requires the following configuration: + +```toml +version = 2 + +[plugins."io.containerd.grpc.v1.cri"] +# Disable AppArmor + disable_apparmor = true +# Ignore an error during setting oom_score_adj + restrict_oom_score_adj = true +# Disable hugetlb cgroup v2 controller (because systemd does not support delegating hugetlb controller) + disable_hugetlb_controller = true + +[plugins."io.containerd.grpc.v1.cri".containerd] +# Using non-fuse overlayfs is also possible for kernel >= 5.11, but requires SELinux to be disabled + snapshotter = "fuse-overlayfs" + +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] +# We use cgroupfs that is delegated by systemd, so we do not use SystemdCgroup driver +# (unless you run another systemd in the namespace) + SystemdCgroup = false +``` + +{{% /tab %}} +{{% tab name="CRI-O" %}} + +Running CRI-O in a user namespace is supported since CRI-O 1.22. + +CRI-O requires an environment variable `_CRIO_ROOTLESS=1` to be set. + +The following configuration is also recommended: + +```toml +[crio] + storage_driver = "overlay" +# Using non-fuse overlayfs is also possible for kernel >= 5.11, but requires SELinux to be disabled + storage_option = ["overlay.mount_program=/usr/local/bin/fuse-overlayfs"] + +[crio.runtime] +# We use cgroupfs that is delegated by systemd, so we do not use "systemd" driver +# (unless you run another systemd in the namespace) + cgroup_manager = "cgroupfs" +``` + +{{% /tab %}} +{{< /tabs >}} + +### Configuring kubelet + +Running kubelet in a user namespace requires the following configuration: + +```yaml +kind: KubeletConfiguration +apiVersion: kubelet.config.k8s.io/v1beta1 +featureGates: + KubeletInUserNamespace: true +# We use cgroupfs that is delegated by systemd, so we do not use "systemd" driver +# (unless you run another systemd in the namespace) +cgroupDriver: "cgroupfs" +``` + +When the `KubeletInUserNamespace` feature gate is enabled, kubelet ignores errors that may happen during setting the following sysctl values: +- `vm.overcommit_memory` +- `vm.panic_on_oom` +- `kernel.panic` +- `kernel.panic_on_oops` +- `kernel.keys.root_maxkeys` +- `kernel.keys.root_maxbytes`. + (these are sysctl values for the host, not for the containers). + +Within a user namespace, the kubelet also ignores any error raised from trying to open `/dev/kmsg`. +This feature gate also allows kube-proxy to ignore an error during setting `RLIMIT_NOFILE`. + +The `KubeletInUserNamespace` feature gate was introduced in Kubernetes v1.22 with "alpha" status. + +Running kubelet in a user namespace without using this feature gate is also possible by mounting a specially crafted proc filesystem, +but not officially supported. + +### Configuring kube-proxy + +Running kube-proxy in a user namespace requires the following configuration: + +```yaml +apiVersion: kubeproxy.config.k8s.io/v1alpha1 +kind: KubeProxyConfiguration +mode: "iptables" # or "userspace" +conntrack: +# Skip setting sysctl value "net.netfilter.nf_conntrack_max" + maxPerCore: 0 +# Skip setting "net.netfilter.nf_conntrack_tcp_timeout_established" + tcpEstablishedTimeout: 0s +# Skip setting "net.netfilter.nf_conntrack_tcp_timeout_close" + tcpCloseWaitTimeout: 0s +``` + +## Caveats + +- Most of "non-local" volume drivers such as `nfs` and `iscsi` do not work. + Local volumes like `local`, `hostPath`, `emptyDir`, `configMap`, `secret`, and `downwardAPI` are known to work. + +- Some CNI plugins may not work. Flannel (VXLAN) is known to work. + +For more on this, see the [Caveats and Future work](https://rootlesscontaine.rs/caveats/) page +on the rootlesscontaine.rs website. + +## {{% heading "seealso" %}} +- [rootlesscontaine.rs](https://rootlesscontaine.rs/) +- [Rootless Containers 2020 (KubeCon NA 2020)](https://www.slideshare.net/AkihiroSuda/kubecon-na-2020-containerd-rootless-containers-2020) +- [Running kind with Rootless Docker](https://kind.sigs.k8s.io/docs/user/rootless/) +- [Usernetes](https://github.com/rootless-containers/usernetes) +- [Running K3s with rootless mode](https://rancher.com/docs/k3s/latest/en/advanced/#running-k3s-with-rootless-mode-experimental) +- [KEP-2033: Kubelet-in-UserNS (aka Rootless mode)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2033-kubelet-in-userns-aka-rootless) diff --git a/content/en/docs/tasks/administer-cluster/memory-manager.md b/content/en/docs/tasks/administer-cluster/memory-manager.md new file mode 100644 index 0000000000..27a0ed2405 --- /dev/null +++ b/content/en/docs/tasks/administer-cluster/memory-manager.md @@ -0,0 +1,390 @@ +--- +title: Utilizing the NUMA-aware Memory Manager + +reviewers: +- klueska +- derekwaynecarr + +content_type: task +min-kubernetes-server-version: v1.21 +--- + + + +{{< feature-state state="beta" for_k8s_version="v1.22" >}} + +The Kubernetes *Memory Manager* enables the feature of guaranteed memory (and hugepages) allocation for pods in the `Guaranteed` {{< glossary_tooltip text="QoS class" term_id="qos-class" >}}. + +The Memory Manager employs hint generation protocol to yield the most suitable NUMA affinity for a pod. The Memory Manager feeds the central manager (*Topology Manager*) with these affinity hints. Based on both the hints and Topology Manager policy, the pod is rejected or admitted to the node. + +Moreover, the Memory Manager ensures that the memory which a pod requests is allocated from a minimum number of NUMA nodes. + +The Memory Manager is only pertinent to Linux based hosts. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +To align memory resources with other requested resources in a Pod Spec: +- the CPU Manager should be enabled and proper CPU Manager policy should be configured on a Node. See [control CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/); +- the Topology Manager should be enabled and proper Topology Manager policy should be configured on a Node. See [control Topology Management Policies](/docs/tasks/administer-cluster/topology-manager/). + +Starting from v1.22, the Memory Manager is enabled by default through `MemoryManager` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/). + +Preceding v1.22, the `kubelet` must be started with the following flag: + +`--feature-gates=MemoryManager=true` + +in order to enable the Memory Manager feature. + +## How Memory Manager Operates? + +The Memory Manager currently offers the guaranteed memory (and hugepages) allocation for Pods in Guaranteed QoS class. To immediately put the Memory Manager into operation follow the guidelines in the section [Memory Manager configuration](#memory-manager-configuration), and subsequently, prepare and deploy a `Guaranteed` pod as illustrated in the section [Placing a Pod in the Guaranteed QoS class](#placing-a-pod-in-the-guaranteed-qos-class). + +The Memory Manager is a Hint Provider, and it provides topology hints for the Topology Manager which then aligns the requested resources according to these topology hints. It also enforces `cgroups` (i.e. `cpuset.mems`) for pods. The complete flow diagram concerning pod admission and deployment process is illustrated in [Memory Manager KEP: Design Overview][4] and below: + +![Memory Manager in the pod admission and deployment process](/images/docs/memory-manager-diagram.svg) + +During this process, the Memory Manager updates its internal counters stored in [Node Map and Memory Maps][2] to manage guaranteed memory allocation. + +The Memory Manager updates the Node Map during the startup and runtime as follows. + +### Startup + +This occurs once a node administrator employs `--reserved-memory` (section [Reserved memory flag](#reserved-memory-flag)). In this case, the Node Map becomes updated to reflect this reservation as illustrated in [Memory Manager KEP: Memory Maps at start-up (with examples)][5]. + +The administrator must provide `--reserved-memory` flag when `Static` policy is configured. + +### Runtime + +Reference [Memory Manager KEP: Memory Maps at runtime (with examples)][6] illustrates how a successful pod deployment affects the Node Map, and it also relates to how potential Out-of-Memory (OOM) situations are handled further by Kubernetes or operating system. + +Important topic in the context of Memory Manager operation is the management of NUMA groups. Each time pod's memory request is in excess of single NUMA node capacity, the Memory Manager attempts to create a group that comprises several NUMA nodes and features extend memory capacity. The problem has been solved as elaborated in [Memory Manager KEP: How to enable the guaranteed memory allocation over many NUMA nodes?][3]. Also, reference [Memory Manager KEP: Simulation - how the Memory Manager works? (by examples)][1] illustrates how the management of groups occurs. + +## Memory Manager configuration + +Other Managers should be first pre-configured (section [Pre-configuration](#pre-configuration)). Next, the Memory Manger feature should be enabled (section [Enable the Memory Manager feature](#enable-the-memory-manager-feature)) and be run with `Static` policy (section [Static policy](#static-policy)). Optionally, some amount of memory can be reserved for system or kubelet processes to increase node stability (section [Reserved memory flag](#reserved-memory-flag)). + +### Policies + +Memory Manager supports two policies. You can select a policy via a `kubelet` flag `--memory-manager-policy`. + +Two policies can be selected: + +* `None` (default) +* `Static` + +#### None policy {#policy-none} + +This is the default policy and does not affect the memory allocation in any way. +It acts the same as if the Memory Manager is not present at all. + +The `None` policy returns default topology hint. This special hint denotes that Hint Provider (Memory Manger in this case) has no preference for NUMA affinity with any resource. + +#### Static policy {#policy-static} + +In the case of the `Guaranteed` pod, the `Static` Memory Manger policy returns topology hints relating to the set of NUMA nodes where the memory can be guaranteed, and reserves the memory through updating the internal [NodeMap][2] object. + +In the case of the `BestEffort` or `Burstable` pod, the `Static` Memory Manager policy sends back the default topology hint as there is no request for the guaranteed memory, and does not reserve the memory in the internal [NodeMap][2] object. + +### Reserved memory flag + +The [Node Allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/) mechanism is commonly used by node administrators to reserve K8S node system resources for the kubelet or operating system processes in order to enhance the node stability. A dedicated set of flags can be used for this purpose to set the total amount of reserved memory for a node. This pre-configured value is subsequently utilized to calculate the real amount of node's "allocatable" memory available to pods. + +The Kubernetes scheduler incorporates "allocatable" to optimise pod scheduling process. The foregoing flags include `--kube-reserved`, `--system-reserved` and `--eviction-threshold`. The sum of their values will account for the total amount of reserved memory. + + +A new `--reserved-memory` flag was added to Memory Manager to allow for this total reserved memory to be split (by a node administrator) and accordingly reserved across many NUMA nodes. + +The flag specifies a comma-separated list of memory reservations per NUMA node. +This parameter is only useful in the context of the Memory Manager feature. +The Memory Manager will not use this reserved memory for the allocation of container workloads. + +For example, if you have a NUMA node "NUMA0" with `10Gi` of memory available, and the `--reserved-memory` was specified to reserve `1Gi` of memory at "NUMA0", the Memory Manager assumes that only `9Gi` is available for containers. + +You can omit this parameter, however, you should be aware that the quantity of reserved memory from all NUMA nodes should be equal to the quantity of memory specified by the [Node Allocatable feature](/docs/tasks/administer-cluster/reserve-compute-resources/). If at least one node allocatable parameter is non-zero, you will need to specify `--reserved-memory` for at least one NUMA node. In fact, `eviction-hard` threshold value is equal to `100Mi` by default, so if `Static` policy is used, `--reserved-memory` is obligatory. + +Also, avoid the following configurations: +1. duplicates, i.e. the same NUMA node or memory type, but with a different value; +2. setting zero limit for any of memory types; +3. NUMA node IDs that do not exist in the machine hardware; +4. memory type names different than `memory` or `hugepages-` (hugepages of particular `` should also exist). + +Syntax: + +`--reserved-memory N:memory-type1=value1,memory-type2=value2,...` +* `N` (integer) - NUMA node index, e.g. `0` +* `memory-type` (string) - represents memory type: + * `memory` - conventional memory + * `hugepages-2Mi` or `hugepages-1Gi` - hugepages +* `value` (string) - the quantity of reserved memory, e.g. `1Gi` + +Example usage: + +`--reserved-memory 0:memory=1Gi,hugepages-1Gi=2Gi` + +or + +`--reserved-memory 0:memory=1Gi --reserved-memory 1:memory=2Gi` + +When you specify values for `--reserved-memory` flag, you must comply with the setting that you prior provided via Node Allocatable Feature flags. That is, the following rule must be obeyed for each memory type: + +`sum(reserved-memory(i)) = kube-reserved + system-reserved + eviction-threshold`, + +where `i` is an index of a NUMA node. + +If you do not follow the formula above, the Memory Manager will show an error on startup. + +In other words, the example above illustrates that for the conventional memory (`type=memory`), we reserve `3Gi` in total, i.e.: + +`sum(reserved-memory(i)) = reserved-memory(0) + reserved-memory(1) = 1Gi + 2Gi = 3Gi` + +An example of kubelet command-line arguments relevant to the node Allocatable configuration: +* `--kube-reserved=cpu=500m,memory=50Mi` +* `--system-reserved=cpu=123m,memory=333Mi` +* `--eviction-hard=memory.available<500Mi` + +{{< note >}} +The default hard eviction threshold is 100MiB, and **not** zero. Remember to increase the quantity of memory that you reserve by setting `--reserved-memory` by that hard eviction threshold. Otherwise, the kubelet will not start Memory Manager and display an error. +{{< /note >}} + +Here is an example of a correct configuration: + +```shell +--feature-gates=MemoryManager=true +--kube-reserved=cpu=4,memory=4Gi +--system-reserved=cpu=1,memory=1Gi +--memory-manager-policy=Static +--reserved-memory 0:memory=3Gi --reserved-memory 1:memory=2148Mi +``` +Let us validate the configuration above: +1. `kube-reserved + system-reserved + eviction-hard(default) = reserved-memory(0) + reserved-memory(1)` +2. `4GiB + 1GiB + 100MiB = 3GiB + 2148MiB` +3. `5120MiB + 100MiB = 3072MiB + 2148MiB` +4. `5220MiB = 5220MiB` (which is correct) + +## Placing a Pod in the Guaranteed QoS class + +If the selected policy is anything other than `None`, the Memory Manager identifies pods that are in the `Guaranteed` QoS class. The Memory Manager provides specific topology hints to the Topology Manager for each `Guaranteed` pod. For pods in a QoS class other than `Guaranteed`, the Memory Manager provides default topology hints to the Topology Manager. + +The following excerpts from pod manifests assign a pod to the `Guaranteed` QoS class. + +Pod with integer CPU(s) runs in the `Guaranteed` QoS class, when `requests` are equal to `limits`: + +```yaml +spec: + containers: + - name: nginx + image: nginx + resources: + limits: + memory: "200Mi" + cpu: "2" + example.com/device: "1" + requests: + memory: "200Mi" + cpu: "2" + example.com/device: "1" +``` + +Also, a pod sharing CPU(s) runs in the `Guaranteed` QoS class, when `requests` are equal to `limits`. + +```yaml +spec: + containers: + - name: nginx + image: nginx + resources: + limits: + memory: "200Mi" + cpu: "300m" + example.com/device: "1" + requests: + memory: "200Mi" + cpu: "300m" + example.com/device: "1" +``` + +Notice that both CPU and memory requests must be specified for a Pod to lend it to Guaranteed QoS class. + +## Troubleshooting + +The following means can be used to troubleshoot the reason why a pod could not be deployed or became rejected at a node: +- pod status - indicates topology affinity errors +- system logs - include valuable information for debugging, e.g., about generated hints +- state file - the dump of internal state of the Memory Manager (includes [Node Map and Memory Maps][2]) +- starting from v1.22, the [device plugin resource API](#device-plugin-resource-api) can be used + to retrieve information about the memory reserved for containers + + + +### Pod status (TopologyAffinityError) {#TopologyAffinityError} + +This error typically occurs in the following situations: +* a node has not enough resources available to satisfy the pod's request +* the pod's request is rejected due to particular Topology Manager policy constraints + +The error appears in the status of a pod: +```shell +# kubectl get pods +NAME READY STATUS RESTARTS AGE +guaranteed 0/1 TopologyAffinityError 0 113s +``` + +Use `kubectl describe pod ` or `kubectl get events` to obtain detailed error message: +```shell +Warning TopologyAffinityError 10m kubelet, dell8 Resources cannot be allocated with Topology locality +``` + +### System logs + +Search system logs with respect to a particular pod. + +The set of hints that Memory Manager generated for the pod can be found in the logs. +Also, the set of hints generated by CPU Manager should be present in the logs. + +Topology Manager merges these hints to calculate a single best hint. +The best hint should be also present in the logs. + +The best hint indicates where to allocate all the resources. Topology Manager tests this hint against its current policy, and based on the verdict, it either admits the pod to the node or rejects it. + +Also, search the logs for occurrences associated with the Memory Manager, e.g. to find out information about `cgroups` and `cpuset.mems` updates. + +### Examine the memory manager state on a node + +Let us first deploy a sample `Guaranteed` pod whose specification is as follows: +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: guaranteed +spec: + containers: + - name: guaranteed + image: consumer + imagePullPolicy: Never + resources: + limits: + cpu: "2" + memory: 150Gi + requests: + cpu: "2" + memory: 150Gi + command: ["sleep","infinity"] +``` + +Next, let us log into the node where it was deployed and examine the state file in `/var/lib/kubelet/memory_manager_state`: +```json +{ + "policyName":"Static", + "machineState":{ + "0":{ + "numberOfAssignments":1, + "memoryMap":{ + "hugepages-1Gi":{ + "total":0, + "systemReserved":0, + "allocatable":0, + "reserved":0, + "free":0 + }, + "memory":{ + "total":134987354112, + "systemReserved":3221225472, + "allocatable":131766128640, + "reserved":131766128640, + "free":0 + } + }, + "nodes":[ + 0, + 1 + ] + }, + "1":{ + "numberOfAssignments":1, + "memoryMap":{ + "hugepages-1Gi":{ + "total":0, + "systemReserved":0, + "allocatable":0, + "reserved":0, + "free":0 + }, + "memory":{ + "total":135286722560, + "systemReserved":2252341248, + "allocatable":133034381312, + "reserved":29295144960, + "free":103739236352 + } + }, + "nodes":[ + 0, + 1 + ] + } + }, + "entries":{ + "fa9bdd38-6df9-4cf9-aa67-8c4814da37a8":{ + "guaranteed":[ + { + "numaAffinity":[ + 0, + 1 + ], + "type":"memory", + "size":161061273600 + } + ] + } + }, + "checksum":4142013182 +} +``` + +It can be deduced from the state file that the pod was pinned to both NUMA nodes, i.e.: + +```json +"numaAffinity":[ + 0, + 1 +], +``` + +Pinned term means that pod's memory consumption is constrained (through `cgroups` configuration) to these NUMA nodes. + +This automatically implies that Memory Manager instantiated a new group that comprises these two NUMA nodes, i.e. `0` and `1` indexed NUMA nodes. + +Notice that the management of groups is handled in a relatively complex manner, and further elaboration is provided in Memory Manager KEP in [this][1] and [this][3] sections. + +In order to analyse memory resources available in a group, the corresponding entries from NUMA nodes belonging to the group must be added up. + +For example, the total amount of free "conventional" memory in the group can be computed by adding up the free memory available at every NUMA node in the group, i.e., in the `"memory"` section of NUMA node `0` (`"free":0`) and NUMA node `1` (`"free":103739236352`). So, the total amount of free "conventional" memory in this group is equal to `0 + 103739236352` bytes. + +The line `"systemReserved":3221225472` indicates that the administrator of this node reserved `3221225472` bytes (i.e. `3Gi`) to serve kubelet and system processes at NUMA node `0`, by using `--reserved-memory` flag. + +### Device plugin resource API + +By employing the [API](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/), the information about reserved memory for each container can be retrieved, which is contained in protobuf `ContainerMemory` message. This information can be retrieved solely for pods in Guaranteed QoS class. + +## {{% heading "whatsnext" %}} + +- [Memory Manager KEP: Design Overview][4] + +- [Memory Manager KEP: Memory Maps at start-up (with examples)][5] + +- [Memory Manager KEP: Memory Maps at runtime (with examples)][6] + +- [Memory Manager KEP: Simulation - how the Memory Manager works? (by examples)][1] + +- [Memory Manager KEP: The Concept of Node Map and Memory Maps][2] + +- [Memory Manager KEP: How to enable the guaranteed memory allocation over many NUMA nodes?][3] + +[1]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1769-memory-manager#simulation---how-the-memory-manager-works-by-examples +[2]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1769-memory-manager#the-concept-of-node-map-and-memory-maps +[3]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1769-memory-manager#how-to-enable-the-guaranteed-memory-allocation-over-many-numa-nodes +[4]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1769-memory-manager#design-overview +[5]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1769-memory-manager#memory-maps-at-start-up-with-examples +[6]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1769-memory-manager#memory-maps-at-runtime-with-examples diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md index dd813754e4..ddfefb6f49 100644 --- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md +++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md @@ -78,3 +78,4 @@ telemetry agents on the node, make sure to check with the vendor of the agent wh We keep the work in progress version of migration instructions for various telemetry and security agent vendors in [Google doc](https://docs.google.com/document/d/1ZFi4uKit63ga5sxEiZblfb-c23lFhvy6RXVPikS8wf0/edit#). Please contact the vendor to get up to date instructions for migrating from dockershim. + diff --git a/content/en/docs/tasks/administer-cluster/namespaces.md b/content/en/docs/tasks/administer-cluster/namespaces.md index 2934e1c0f7..231de37e26 100644 --- a/content/en/docs/tasks/administer-cluster/namespaces.md +++ b/content/en/docs/tasks/administer-cluster/namespaces.md @@ -78,7 +78,8 @@ A namespace can be in one of two phases: * `Active` the namespace is in use * `Terminating` the namespace is being deleted, and can not be used for new objects -See the [design doc](https://git.k8s.io/community/contributors/design-proposals/architecture/namespaces.md#phases) for more details. +For more details, see [Namespace](/docs/reference/kubernetes-api/cluster-resources/namespace-v1/) +in the API reference. ## Creating a new namespace @@ -313,7 +314,7 @@ across namespaces, you need to use the fully qualified domain name (FQDN). * Learn more about [setting the namespace preference](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-preference). * Learn more about [setting the namespace for a request](/docs/concepts/overview/working-with-objects/namespaces/#setting-the-namespace-for-a-request) -* See [namespaces design](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/architecture/namespaces.md). +* See [namespaces design](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/namespaces.md). diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/antrea-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/antrea-network-policy.md new file mode 100644 index 0000000000..36da1839e9 --- /dev/null +++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/antrea-network-policy.md @@ -0,0 +1,24 @@ +--- +title: Use Antrea for NetworkPolicy +content_type: task +weight: 10 +--- + + +This page shows how to install and use Antrea CNI plugin on Kubernetes. +For background on Project Antrea, read the [Introduction to Antrea](https://antrea.io/docs/). + +## {{% heading "prerequisites" %}} + +You need to have a Kubernetes cluster. Follow the +[kubeadm getting started guide](/docs/reference/setup-tools/kubeadm/) to bootstrap one. + + + +## Deploying Antrea with kubeadm + +Follow [Getting Started](https://github.com/vmware-tanzu/antrea/blob/main/docs/getting-started.md) guide to deploy Antrea for kubeadm. + +## {{% heading "whatsnext" %}} + +Once your cluster is running, you can follow the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network-policy/) to try out Kubernetes NetworkPolicy. diff --git a/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md index 948893d3ea..74b8d2182e 100644 --- a/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md +++ b/content/en/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md @@ -24,45 +24,59 @@ For background on Cilium, read the [Introduction to Cilium](https://docs.cilium. ## Deploying Cilium on Minikube for Basic Testing To get familiar with Cilium easily you can follow the -[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/stable/gettingstarted/minikube/) +[Cilium Kubernetes Getting Started Guide](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/) to perform a basic DaemonSet installation of Cilium in minikube. -To start minikube, minimal version required is >= v1.3.1, run the with the +To start minikube, minimal version required is >= v1.5.2, run the with the following arguments: ```shell minikube version ``` ``` -minikube version: v1.3.1 +minikube version: v1.5.2 ``` ```shell -minikube start --network-plugin=cni --memory=4096 +minikube start --network-plugin=cni ``` -Mount the BPF filesystem: +For minikube you can install Cilium using its CLI tool. Cilium will +automatically detect the cluster configuration and will install the appropriate +components for a successful installation: ```shell -minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf -``` - -For minikube you can deploy this simple ''all-in-one'' YAML file that includes -DaemonSet configurations for Cilium as well as appropriate RBAC settings: - -```shell -kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml +curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz +sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin +rm cilium-linux-amd64.tar.gz +cilium install ``` ``` -configmap/cilium-config created -serviceaccount/cilium created -serviceaccount/cilium-operator created -clusterrole.rbac.authorization.k8s.io/cilium created -clusterrole.rbac.authorization.k8s.io/cilium-operator created -clusterrolebinding.rbac.authorization.k8s.io/cilium created -clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created -daemonset.apps/cilium create -deployment.apps/cilium-operator created +🔮 Auto-detected Kubernetes kind: minikube +✨ Running "minikube" validation checks +✅ Detected minikube version "1.20.0" +ℹ️ Cilium version not set, using default version "v1.10.0" +🔮 Auto-detected cluster name: minikube +🔮 Auto-detected IPAM mode: cluster-pool +🔮 Auto-detected datapath mode: tunnel +🔑 Generating CA... +2021/05/27 02:54:44 [INFO] generate received request +2021/05/27 02:54:44 [INFO] received CSR +2021/05/27 02:54:44 [INFO] generating key: ecdsa-256 +2021/05/27 02:54:44 [INFO] encoded CSR +2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642 +🔑 Generating certificates for Hubble... +2021/05/27 02:54:44 [INFO] generate received request +2021/05/27 02:54:44 [INFO] received CSR +2021/05/27 02:54:44 [INFO] generating key: ecdsa-256 +2021/05/27 02:54:44 [INFO] encoded CSR +2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574 +🚀 Creating Service accounts... +🚀 Creating Cluster roles... +🚀 Creating ConfigMap... +🚀 Creating Agent DaemonSet... +🚀 Creating Operator Deployment... +⌛ Waiting for Cilium to be installed... ``` The remainder of the Getting Started Guide explains how to enforce both L3/L4 @@ -85,14 +99,14 @@ Deploying a cluster with Cilium adds Pods to the `kube-system` namespace. To see this list of Pods run: ```shell -kubectl get pods --namespace=kube-system +kubectl get pods --namespace=kube-system -l k8s-app=cilium ``` You'll see a list of Pods similar to this: ```console -NAME READY STATUS RESTARTS AGE -cilium-6rxbd 1/1 Running 0 1m +NAME READY STATUS RESTARTS AGE +cilium-kkdhz 1/1 Running 0 3m23s ... ``` diff --git a/content/en/docs/tasks/administer-cluster/nodelocaldns.md b/content/en/docs/tasks/administer-cluster/nodelocaldns.md index b0f0596599..33417b00ad 100644 --- a/content/en/docs/tasks/administer-cluster/nodelocaldns.md +++ b/content/en/docs/tasks/administer-cluster/nodelocaldns.md @@ -79,7 +79,7 @@ If you are using the sample manifest from the previous point, this will require * If kube-proxy is running in IPVS mode: ``` bash - sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml + sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/,__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml ``` In this mode, node-local-dns pods listen only on ``. The node-local-dns interface cannot bind the kube-dns cluster IP since the interface used for IPVS loadbalancing already uses this address. `__PILLAR__UPSTREAM__SERVERS__` will be populated by the node-local-dns pods. diff --git a/content/en/docs/tasks/administer-cluster/out-of-resource.md b/content/en/docs/tasks/administer-cluster/out-of-resource.md deleted file mode 100644 index f750dd2585..0000000000 --- a/content/en/docs/tasks/administer-cluster/out-of-resource.md +++ /dev/null @@ -1,354 +0,0 @@ ---- -reviewers: -- derekwaynecarr -- vishh -- timstclair -title: Configure Out of Resource Handling -content_type: concept ---- - - - -This page explains how to configure out of resource handling with `kubelet`. - -The `kubelet` needs to preserve node stability when available compute resources -are low. This is especially important when dealing with incompressible -compute resources, such as memory or disk space. If such resources are exhausted, -nodes become unstable. - - - -### Eviction Signals - -The `kubelet` supports eviction decisions based on the signals described in the following -table. The value of each signal is described in the Description column, which is based on -the `kubelet` summary API. - -| Eviction Signal | Description | -|----------------------|---------------------------------------------------------------------------------------| -| `memory.available` | `memory.available` := `node.status.capacity[memory]` - `node.stats.memory.workingSet` | -| `nodefs.available` | `nodefs.available` := `node.stats.fs.available` | -| `nodefs.inodesFree` | `nodefs.inodesFree` := `node.stats.fs.inodesFree` | -| `imagefs.available` | `imagefs.available` := `node.stats.runtime.imagefs.available` | -| `imagefs.inodesFree` | `imagefs.inodesFree` := `node.stats.runtime.imagefs.inodesFree` | -| `pid.available` | `pid.available` := `node.stats.rlimit.maxpid` - `node.stats.rlimit.curproc` | - -Each of the above signals supports either a literal or percentage based value. -The percentage based value is calculated relative to the total capacity -associated with each signal. - -The value for `memory.available` is derived from the cgroupfs instead of tools -like `free -m`. This is important because `free -m` does not work in a -container, and if users use the [node -allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) feature, out of resource decisions -are made local to the end user Pod part of the cgroup hierarchy as well as the -root node. This [script](/examples/admin/resource/memory-available.sh) -reproduces the same set of steps that the `kubelet` performs to calculate -`memory.available`. The `kubelet` excludes inactive_file (i.e. # of bytes of -file-backed memory on inactive LRU list) from its calculation as it assumes that -memory is reclaimable under pressure. - -`kubelet` supports only two filesystem partitions. - -1. The `nodefs` filesystem that kubelet uses for volumes, daemon logs, etc. -1. The `imagefs` filesystem that container runtimes uses for storing images and - container writable layers. - -`imagefs` is optional. `kubelet` auto-discovers these filesystems using -cAdvisor. `kubelet` does not care about any other filesystems. Any other types -of configurations are not currently supported by the kubelet. For example, it is -_not OK_ to store volumes and logs in a dedicated `filesystem`. - -In future releases, the `kubelet` will deprecate the existing [garbage -collection](/docs/concepts/cluster-administration/kubelet-garbage-collection/) -support in favor of eviction in response to disk pressure. - -### Eviction Thresholds - -The `kubelet` supports the ability to specify eviction thresholds that trigger the `kubelet` to reclaim resources. - -Each threshold has the following form: - -`[eviction-signal][operator][quantity]` - -where: - -* `eviction-signal` is an eviction signal token as defined in the previous table. -* `operator` is the desired relational operator, such as `<` (less than). -* `quantity` is the eviction threshold quantity, such as `1Gi`. These tokens must match the quantity representation used by Kubernetes. An eviction threshold can also be expressed as a percentage using the `%` token. - -For example, if a node has `10Gi` of total memory and you want trigger eviction if -the available memory falls below `1Gi`, you can define the eviction threshold as -either `memory.available<10%` or `memory.available<1Gi`. You cannot use both. - -#### Soft Eviction Thresholds - -A soft eviction threshold pairs an eviction threshold with a required -administrator-specified grace period. No action is taken by the `kubelet` -to reclaim resources associated with the eviction signal until that grace -period has been exceeded. If no grace period is provided, the `kubelet` -returns an error on startup. - -In addition, if a soft eviction threshold has been met, an operator can -specify a maximum allowed Pod termination grace period to use when evicting -pods from the node. If specified, the `kubelet` uses the lesser value among -the `pod.Spec.TerminationGracePeriodSeconds` and the max allowed grace period. -If not specified, the `kubelet` kills Pods immediately with no graceful -termination. - -To configure soft eviction thresholds, the following flags are supported: - -* `eviction-soft` describes a set of eviction thresholds (e.g. `memory.available<1.5Gi`) that if met over a corresponding grace period would trigger a Pod eviction. -* `eviction-soft-grace-period` describes a set of eviction grace periods (e.g. `memory.available=1m30s`) that correspond to how long a soft eviction threshold must hold before triggering a Pod eviction. -* `eviction-max-pod-grace-period` describes the maximum allowed grace period (in seconds) to use when terminating pods in response to a soft eviction threshold being met. - -#### Hard Eviction Thresholds - -A hard eviction threshold has no grace period, and if observed, the `kubelet` -will take immediate action to reclaim the associated starved resource. If a -hard eviction threshold is met, the `kubelet` kills the Pod immediately -with no graceful termination. - -To configure hard eviction thresholds, the following flag is supported: - -* `eviction-hard` describes a set of eviction thresholds (e.g. `memory.available<1Gi`) that if met would trigger a Pod eviction. - -The `kubelet` has the following default hard eviction threshold: - -* `memory.available<100Mi` -* `nodefs.available<10%` -* `imagefs.available<15%` - -On a Linux node, the default value also includes `nodefs.inodesFree<5%`. - -### Eviction Monitoring Interval - -The `kubelet` evaluates eviction thresholds per its configured housekeeping interval. - -* `housekeeping-interval` is the interval between container housekeepings which defaults to `10s`. - -### Node Conditions - -The `kubelet` maps one or more eviction signals to a corresponding node condition. - -If a hard eviction threshold has been met, or a soft eviction threshold has been met -independent of its associated grace period, the `kubelet` reports a condition that -reflects the node is under pressure. - -The following node conditions are defined that correspond to the specified eviction signal. - -| Node Condition | Eviction Signal | Description | -|-------------------|---------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------| -| `MemoryPressure` | `memory.available` | Available memory on the node has satisfied an eviction threshold | -| `DiskPressure` | `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, or `imagefs.inodesFree` | Available disk space and inodes on either the node's root filesystem or image filesystem has satisfied an eviction threshold | -| `PIDPressure` | `pid.available` | Available processes identifiers on the (Linux) node has fallen below an eviction threshold | | - -The `kubelet` continues to report node status updates at the frequency specified by -`--node-status-update-frequency` which defaults to `10s`. - -### Oscillation of node conditions - -If a node is oscillating above and below a soft eviction threshold, but not exceeding -its associated grace period, it would cause the corresponding node condition to -constantly oscillate between true and false, and could cause poor scheduling decisions -as a consequence. - -To protect against this oscillation, the following flag is defined to control how -long the `kubelet` must wait before transitioning out of a pressure condition. - -* `eviction-pressure-transition-period` is the duration for which the `kubelet` has to wait before transitioning out of an eviction pressure condition. - -The `kubelet` would ensure that it has not observed an eviction threshold being met -for the specified pressure condition for the period specified before toggling the -condition back to `false`. - -### Reclaiming node level resources - -If an eviction threshold has been met and the grace period has passed, -the `kubelet` initiates the process of reclaiming the pressured resource -until it has observed the signal has gone below its defined threshold. - -The `kubelet` attempts to reclaim node level resources prior to evicting end-user Pods. If -disk pressure is observed, the `kubelet` reclaims node level resources differently if the -machine has a dedicated `imagefs` configured for the container runtime. - -#### With `imagefs` - -If `nodefs` filesystem has met eviction thresholds, `kubelet` frees up disk space by deleting the dead Pods and their containers. - -If `imagefs` filesystem has met eviction thresholds, `kubelet` frees up disk space by deleting all unused images. - -#### Without `imagefs` - -If `nodefs` filesystem has met eviction thresholds, `kubelet` frees up disk space in the following order: - -1. Delete dead Pods and their containers -1. Delete all unused images - -### Evicting end-user Pods - -If the `kubelet` is unable to reclaim sufficient resource on the node, `kubelet` begins evicting Pods. - -The `kubelet` ranks Pods for eviction first by whether or not their usage of the starved resource exceeds requests, -then by [Priority](/docs/concepts/configuration/pod-priority-preemption/), and then by the consumption of the starved compute resource relative to the Pods' scheduling requests. - -As a result, `kubelet` ranks and evicts Pods in the following order: - -* `BestEffort` or `Burstable` Pods whose usage of a starved resource exceeds its request. Such pods are ranked by Priority, and then usage above request. -* `Guaranteed` pods and `Burstable` pods whose usage is beneath requests are evicted last. `Guaranteed` Pods are guaranteed only when requests and limits are specified for all the containers and they are equal. Such pods are guaranteed to never be evicted because of another Pod's resource consumption. If a system daemon (such as `kubelet`, `docker`, and `journald`) is consuming more resources than were reserved via `system-reserved` or `kube-reserved` allocations, and the node only has `Guaranteed` or `Burstable` Pods using less than requests remaining, then the node must choose to evict such a Pod in order to preserve node stability and to limit the impact of the unexpected consumption to other Pods. In this case, it will choose to evict pods of Lowest Priority first. - -If necessary, `kubelet` evicts Pods one at a time to reclaim disk when `DiskPressure` -is encountered. If the `kubelet` is responding to `inode` starvation, it reclaims -`inodes` by evicting Pods with the lowest quality of service first. If the `kubelet` -is responding to lack of available disk, it ranks Pods within a quality of service -that consumes the largest amount of disk and kills those first. - -#### With `imagefs` - -If `nodefs` is triggering evictions, `kubelet` sorts Pods based on the usage on `nodefs` - -- local volumes + logs of all its containers. - -If `imagefs` is triggering evictions, `kubelet` sorts Pods based on the writable layer usage of all its containers. - -#### Without `imagefs` - -If `nodefs` is triggering evictions, `kubelet` sorts Pods based on their total disk usage - -- local volumes + logs & writable layer of all its containers. - -### Minimum eviction reclaim - -In certain scenarios, eviction of Pods could result in reclamation of small amount of resources. This can result in -`kubelet` hitting eviction thresholds in repeated successions. In addition to that, eviction of resources like `disk`, is time consuming. - -To mitigate these issues, `kubelet` can have a per-resource `minimum-reclaim`. Whenever `kubelet` observes -resource pressure, `kubelet` attempts to reclaim at least `minimum-reclaim` amount of resource below -the configured eviction threshold. - -For example, with the following configuration: - -``` ---eviction-hard=memory.available<500Mi,nodefs.available<1Gi,imagefs.available<100Gi ---eviction-minimum-reclaim="memory.available=0Mi,nodefs.available=500Mi,imagefs.available=2Gi"` -``` - -If an eviction threshold is triggered for `memory.available`, the `kubelet` works to ensure -that `memory.available` is at least `500Mi`. For `nodefs.available`, the `kubelet` works -to ensure that `nodefs.available` is at least `1.5Gi`, and for `imagefs.available` it -works to ensure that `imagefs.available` is at least `102Gi` before no longer reporting pressure -on their associated resources. - -The default `eviction-minimum-reclaim` is `0` for all resources. - -### Scheduler - -The node reports a condition when a compute resource is under pressure. The -scheduler views that condition as a signal to dissuade placing additional -pods on the node. - -| Node Condition | Scheduler Behavior | -| ------------------| ----------------------------------------------------| -| `MemoryPressure` | No new `BestEffort` Pods are scheduled to the node. | -| `DiskPressure` | No new Pods are scheduled to the node. | - -## Node OOM Behavior - -If the node experiences a system OOM (out of memory) event prior to the `kubelet` being able to reclaim memory, -the node depends on the [oom_killer](https://lwn.net/Articles/391222/) to respond. - -The `kubelet` sets a `oom_score_adj` value for each container based on the quality of service for the Pod. - -| Quality of Service | oom_score_adj | -|--------------------|-----------------------------------------------------------------------------------| -| `Guaranteed` | -998 | -| `BestEffort` | 1000 | -| `Burstable` | min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) | - -If the `kubelet` is unable to reclaim memory prior to a node experiencing system OOM, the `oom_killer` calculates -an `oom_score` based on the percentage of memory it's using on the node, and then add the `oom_score_adj` to get an -effective `oom_score` for the container, and then kills the container with the highest score. - -The intended behavior should be that containers with the lowest quality of service that -are consuming the largest amount of memory relative to the scheduling request should be killed first in order -to reclaim memory. - -Unlike Pod eviction, if a Pod container is OOM killed, it may be restarted by the `kubelet` based on its `RestartPolicy`. - -## Best Practices - -The following sections describe best practices for out of resource handling. - -### Schedulable resources and eviction policies - -Consider the following scenario: - -* Node memory capacity: `10Gi` -* Operator wants to reserve 10% of memory capacity for system daemons (kernel, `kubelet`, etc.) -* Operator wants to evict Pods at 95% memory utilization to reduce incidence of system OOM. - -To facilitate this scenario, the `kubelet` would be launched as follows: - -``` ---eviction-hard=memory.available<500Mi ---system-reserved=memory=1.5Gi -``` - -Implicit in this configuration is the understanding that "System reserved" should include the amount of memory -covered by the eviction threshold. - -To reach that capacity, either some Pod is using more than its request, or the system is using more than `1.5Gi - 500Mi = 1Gi`. - -This configuration ensures that the scheduler does not place Pods on a node that immediately induce memory pressure -and trigger eviction assuming those Pods use less than their configured request. - -### DaemonSet - -As `Priority` is a key factor in the eviction strategy, if you do not want pods belonging to a `DaemonSet` to be evicted, specify a sufficiently high priorityClass in the pod spec template. If you want pods belonging to a `DaemonSet` to run only if there are sufficient resources, specify a lower or default priorityClass. - - -## Deprecation of existing feature flags to reclaim disk - -`kubelet` has been freeing up disk space on demand to keep the node stable. - -As disk based eviction matures, the following `kubelet` flags are marked for deprecation -in favor of the simpler configuration supported around eviction. - -| Existing Flag | New Flag | -| ------------------------------------------ | ----------------------------------------| -| `--image-gc-high-threshold` | `--eviction-hard` or `eviction-soft` | -| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | -| `--maximum-dead-containers` | deprecated | -| `--maximum-dead-containers-per-container` | deprecated | -| `--minimum-container-ttl-duration` | deprecated | -| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | -| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | - -## Known issues - -The following sections describe known issues related to out of resource handling. - -### kubelet may not observe memory pressure right away - -The `kubelet` currently polls `cAdvisor` to collect memory usage stats at a regular interval. If memory usage -increases within that window rapidly, the `kubelet` may not observe `MemoryPressure` fast enough, and the `OOMKiller` -will still be invoked. We intend to integrate with the `memcg` notification API in a future release to reduce this -latency, and instead have the kernel tell us when a threshold has been crossed immediately. - -If you are not trying to achieve extreme utilization, but a sensible measure of overcommit, a viable workaround for -this issue is to set eviction thresholds at approximately 75% capacity. This increases the ability of this feature -to prevent system OOMs, and promote eviction of workloads so cluster state can rebalance. - -### kubelet may evict more Pods than needed - -The Pod eviction may evict more Pods than needed due to stats collection timing gap. This can be mitigated by adding -the ability to get root container stats on an on-demand basis [(https://github.com/google/cadvisor/issues/1247)](https://github.com/google/cadvisor/issues/1247) in the future. - -### active_file memory is not considered as available memory - -On Linux, the kernel tracks the number of bytes of file-backed memory on active LRU list as the `active_file` statistic. The kubelet treats `active_file` memory areas as not reclaimable. For workloads that make intensive use of block-backed local storage, including ephemeral local storage, kernel-level caches of file and block data means that many recently accessed cache pages are likely to be counted as `active_file`. If enough of these kernel block buffers are on the active LRU list, the kubelet is liable to observe this as high resource use and taint the node as experiencing memory pressure - triggering Pod eviction. - -For more more details, see [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916) - -You can work around that behavior by setting the memory limit and memory request the same for containers likely to perform intensive I/O activity. You will need to estimate or measure an optimal memory limit value for that container. - diff --git a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md index 4ec3b428d0..466910f30f 100644 --- a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md +++ b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md @@ -8,7 +8,14 @@ min-kubernetes-server-version: v1.11 --- -{{< feature-state for_k8s_version="v1.11" state="beta" >}} +{{< feature-state for_k8s_version="v1.22" state="deprecated" >}} + +{{< caution >}} +[Dynamic Kubelet Configuration](https://github.com/kubernetes/enhancements/issues/281) +feature is deprecated and should not be used. +Please switch to alternative means distributing configuration to the Nodes of your cluster. +{{< /caution >}} + [Dynamic Kubelet Configuration](https://github.com/kubernetes/enhancements/issues/281) allows you to change the configuration of each diff --git a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md index a5661263f2..d4cce14870 100644 --- a/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md +++ b/content/en/docs/tasks/administer-cluster/reserve-compute-resources.md @@ -17,33 +17,27 @@ itself. Unless resources are set aside for these system daemons, pods and system daemons compete for resources and lead to resource starvation issues on the node. -The `kubelet` exposes a feature named `Node Allocatable` that helps to reserve +The `kubelet` exposes a feature named 'Node Allocatable' that helps to reserve compute resources for system daemons. Kubernetes recommends cluster -administrators to configure `Node Allocatable` based on their workload density +administrators to configure 'Node Allocatable' based on their workload density on each node. - - - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} Your Kubernetes server must be at or later than version 1.17 to use the kubelet command line option `--reserved-cpus` to set an [explicitly reserved CPU list](#explicitly-reserved-cpu-list). - - ## Node Allocatable ![node capacity](/images/docs/node-capacity.svg) -`Allocatable` on a Kubernetes node is defined as the amount of compute resources +'Allocatable' on a Kubernetes node is defined as the amount of compute resources that are available for pods. The scheduler does not over-subscribe -`Allocatable`. `CPU`, `memory` and `ephemeral-storage` are supported as of now. +'Allocatable'. 'CPU', 'memory' and 'ephemeral-storage' are supported as of now. Node Allocatable is exposed as part of `v1.Node` object in the API and as part of `kubectl describe node` in the CLI. @@ -97,8 +91,7 @@ flag. It is recommended that the kubernetes system daemons are placed under a top level control group (`runtime.slice` on systemd machines for example). Each system daemon should ideally run within its own child control group. Refer to -[this -doc](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup) +[the design proposal](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup) for more details on recommended control group hierarchy. Note that Kubelet **does not** create `--kube-reserved-cgroup` if it doesn't @@ -109,7 +102,6 @@ exist. Kubelet will fail if an invalid cgroup is specified. - **Kubelet Flag**: `--system-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]` - **Kubelet Flag**: `--system-reserved-cgroup=` - `system-reserved` is meant to capture resource reservation for OS system daemons like `sshd`, `udev`, etc. `system-reserved` should reserve `memory` for the `kernel` too since `kernel` memory is not accounted to pods in Kubernetes at this time. @@ -127,13 +119,14 @@ kubelet flag. It is recommended that the OS system daemons are placed under a top level control group (`system.slice` on systemd machines for example). -Note that Kubelet **does not** create `--system-reserved-cgroup` if it doesn't -exist. Kubelet will fail if an invalid cgroup is specified. +Note that `kubelet` **does not** create `--system-reserved-cgroup` if it doesn't +exist. `kubelet` will fail if an invalid cgroup is specified. ### Explicitly Reserved CPU List + {{< feature-state for_k8s_version="v1.17" state="stable" >}} -- **Kubelet Flag**: `--reserved-cpus=0-3` +**Kubelet Flag**: `--reserved-cpus=0-3` `reserved-cpus` is meant to define an explicit CPU set for OS system daemons and kubernetes system daemons. `reserved-cpus` is for systems that do not intend to @@ -154,14 +147,15 @@ For example: in Centos, you can do this using the tuned toolset. ### Eviction Thresholds -- **Kubelet Flag**: `--eviction-hard=[memory.available<500Mi]` +**Kubelet Flag**: `--eviction-hard=[memory.available<500Mi]` Memory pressure at the node level leads to System OOMs which affects the entire node and all pods running on it. Nodes can go offline temporarily until memory has been reclaimed. To avoid (or reduce the probability of) system OOMs kubelet -provides [`Out of Resource`](/docs/tasks/administer-cluster/out-of-resource/) management. Evictions are +provides [out of resource](/docs/concepts/scheduling-eviction/node-pressure-eviction/) +management. Evictions are supported for `memory` and `ephemeral-storage` only. By reserving some memory via -`--eviction-hard` flag, the `kubelet` attempts to `evict` pods whenever memory +`--eviction-hard` flag, the `kubelet` attempts to evict pods whenever memory availability on the node drops below the reserved value. Hypothetically, if system daemons did not exist on a node, pods cannot use more than `capacity - eviction-hard`. For this reason, resources reserved for evictions are not @@ -169,17 +163,17 @@ available for pods. ### Enforcing Node Allocatable -- **Kubelet Flag**: `--enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]` +**Kubelet Flag**: `--enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]` -The scheduler treats `Allocatable` as the available `capacity` for pods. +The scheduler treats 'Allocatable' as the available `capacity` for pods. -`kubelet` enforce `Allocatable` across pods by default. Enforcement is performed +`kubelet` enforce 'Allocatable' across pods by default. Enforcement is performed by evicting pods whenever the overall usage across all pods exceeds -`Allocatable`. More details on eviction policy can be found -[here](/docs/tasks/administer-cluster/out-of-resource/#eviction-policy). This enforcement is controlled by +'Allocatable'. More details on eviction policy can be found +on the [node pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) +page. This enforcement is controlled by specifying `pods` value to the kubelet flag `--enforce-node-allocatable`. - Optionally, `kubelet` can be made to enforce `kube-reserved` and `system-reserved` by specifying `kube-reserved` & `system-reserved` values in the same flag. Note that to enforce `kube-reserved` or `system-reserved`, @@ -188,10 +182,10 @@ respectively. ## General Guidelines -System daemons are expected to be treated similar to `Guaranteed` pods. System +System daemons are expected to be treated similar to 'Guaranteed' pods. System daemons can burst within their bounding control groups and this behavior needs to be managed as part of kubernetes deployments. For example, `kubelet` should -have its own control group and share `Kube-reserved` resources with the +have its own control group and share `kube-reserved` resources with the container runtime. However, Kubelet cannot burst and use up all available Node resources if `kube-reserved` is enforced. @@ -200,9 +194,9 @@ to critical system services being CPU starved, OOM killed, or unable to fork on the node. The recommendation is to enforce `system-reserved` only if a user has profiled their nodes exhaustively to come up with precise estimates and is confident in their -ability to recover if any process in that group is oom_killed. +ability to recover if any process in that group is oom-killed. -* To begin with enforce `Allocatable` on `pods`. +* To begin with enforce 'Allocatable' on `pods`. * Once adequate monitoring and alerting is in place to track kube system daemons, attempt to enforce `kube-reserved` based on usage heuristics. * If absolutely necessary, enforce `system-reserved` over time. @@ -212,8 +206,6 @@ more features are added. Over time, kubernetes project will attempt to bring down utilization of node system daemons, but that is not a priority as of now. So expect a drop in `Allocatable` capacity in future releases. - - ## Example Scenario @@ -225,15 +217,15 @@ Here is an example to illustrate Node Allocatable computation: * `--system-reserved` is set to `cpu=500m,memory=1Gi,ephemeral-storage=1Gi` * `--eviction-hard` is set to `memory.available<500Mi,nodefs.available<10%` -Under this scenario, `Allocatable` will be `14.5 CPUs`, `28.5Gi` of memory and +Under this scenario, 'Allocatable' will be 14.5 CPUs, 28.5Gi of memory and `88Gi` of local storage. Scheduler ensures that the total memory `requests` across all pods on this node does -not exceed `28.5Gi` and storage doesn't exceed `88Gi`. -Kubelet evicts pods whenever the overall memory usage across pods exceeds `28.5Gi`, -or if overall disk usage exceeds `88Gi` If all processes on the node consume as -much CPU as they can, pods together cannot consume more than `14.5 CPUs`. +not exceed 28.5Gi and storage doesn't exceed 88Gi. +Kubelet evicts pods whenever the overall memory usage across pods exceeds 28.5Gi, +or if overall disk usage exceeds 88Gi If all processes on the node consume as +much CPU as they can, pods together cannot consume more than 14.5 CPUs. If `kube-reserved` and/or `system-reserved` is not enforced and system daemons exceed their reservation, `kubelet` evicts pods whenever the overall node memory -usage is higher than `31.5Gi` or `storage` is greater than `90Gi` +usage is higher than 31.5Gi or `storage` is greater than 90Gi. diff --git a/content/en/docs/tasks/administer-cluster/safely-drain-node.md b/content/en/docs/tasks/administer-cluster/safely-drain-node.md index 0fc0a97ffc..04c908c592 100644 --- a/content/en/docs/tasks/administer-cluster/safely-drain-node.md +++ b/content/en/docs/tasks/administer-cluster/safely-drain-node.md @@ -29,7 +29,7 @@ This task also assumes that you have met the following prerequisites: ## (Optional) Configure a disruption budget {#configure-poddisruptionbudget} -To endure that your workloads remain available during maintenance, you can +To ensure that your workloads remain available during maintenance, you can configure a [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/). If availability is important for any applications that run or could run on the node(s) @@ -109,6 +109,28 @@ Pod can be thought of as a kind of policy-controlled DELETE operation on the Pod itself. To attempt an eviction (more precisely: to attempt to *create* an Eviction), you POST an attempted operation. Here's an example: +{{< tabs name="Eviction_example" >}} +{{% tab name="policy/v1" %}} +{{< note >}} +`policy/v1` Eviction is available in v1.22+. Use `policy/v1beta1` with prior releases. +{{< /note >}} + +```json +{ + "apiVersion": "policy/v1", + "kind": "Eviction", + "metadata": { + "name": "quux", + "namespace": "default" + } +} +``` +{{% /tab %}} +{{% tab name="policy/v1beta1" %}} +{{< note >}} +Deprecated in v1.22 in favor of `policy/v1` +{{< /note >}} + ```json { "apiVersion": "policy/v1beta1", @@ -119,6 +141,8 @@ itself. To attempt an eviction (more precisely: to attempt to } } ``` +{{% /tab %}} +{{< /tabs >}} You can attempt an eviction using `curl`: diff --git a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md index 090e292966..ba820cbe0a 100644 --- a/content/en/docs/tasks/administer-cluster/securing-a-cluster.md +++ b/content/en/docs/tasks/administer-cluster/securing-a-cluster.md @@ -26,7 +26,7 @@ and provides recommendations on overall security. ## Controlling access to the Kubernetes API -As Kubernetes is entirely API driven, controlling and limiting who can access the cluster and what actions +As Kubernetes is entirely API-driven, controlling and limiting who can access the cluster and what actions they are allowed to perform is the first line of defense. ### Use Transport Layer Security (TLS) for all API traffic @@ -40,7 +40,7 @@ potentially unsecured traffic. ### API Authentication Choose an authentication mechanism for the API servers to use that matches the common access patterns -when you install a cluster. For instance, small single user clusters may wish to use a simple certificate +when you install a cluster. For instance, small, single-user clusters may wish to use a simple certificate or static Bearer token approach. Larger clusters may wish to integrate an existing OIDC or LDAP server that allow users to be subdivided into groups. @@ -54,7 +54,7 @@ Consult the [authentication reference document](/docs/reference/access-authn-aut Once authenticated, every API call is also expected to pass an authorization check. Kubernetes ships an integrated [Role-Based Access Control (RBAC)](/docs/reference/access-authn-authz/rbac/) component that matches an incoming user or group to a set of permissions bundled into roles. These permissions combine verbs (get, create, delete) with -resources (pods, services, nodes) and can be namespace or cluster scoped. A set of out of the box +resources (pods, services, nodes) and can be namespace-scoped or cluster-scoped. A set of out-of-the-box roles are provided that offer reasonable default separation of responsibility depending on what actions a client might want to perform. It is recommended that you use the [Node](/docs/reference/access-authn-authz/node/) and @@ -69,8 +69,8 @@ With authorization, it is important to understand how updates on one object may other places. For instance, a user may not be able to create pods directly, but allowing them to create a deployment, which creates pods on their behalf, will let them create those pods indirectly. Likewise, deleting a node from the API will result in the pods scheduled to that node -being terminated and recreated on other nodes. The out of the box roles represent a balance -between flexibility and the common use cases, but more limited roles should be carefully reviewed +being terminated and recreated on other nodes. The out-of-the box roles represent a balance +between flexibility and common use cases, but more limited roles should be carefully reviewed to prevent accidental escalation. You can make roles specific to your use case if the out-of-box ones don't meet your needs. Consult the [authorization reference section](/docs/reference/access-authn-authz/authorization/) for more information. @@ -104,7 +104,7 @@ reserved resources like memory, or to provide default limits when none are speci ### Controlling what privileges containers run with A pod definition contains a [security context](/docs/tasks/configure-pod-container/security-context/) -that allows it to request access to running as a specific Linux user on a node (like root), +that allows it to request access to run as a specific Linux user on a node (like root), access to run privileged or access the host network, and other controls that would otherwise allow it to run unfettered on a hosting node. [Pod security policies](/docs/concepts/policy/pod-security-policy/) can limit which users or service accounts can provide dangerous security context settings. For example, pod security policies can limit volume mounts, especially `hostPath`, which are aspects of a pod that should be controlled. @@ -155,10 +155,10 @@ within their namespaces. Many of the supported [Kubernetes networking providers] now respect network policy. Quota and limit ranges can also be used to control whether users may request node ports or -load balanced services, which on many clusters can control whether those users applications +load-balanced services, which on many clusters can control whether those users applications are visible outside of the cluster. -Additional protections may be available that control network rules on a per plugin or per +Additional protections may be available that control network rules on a per-plugin or per- environment basis, such as per-node firewalls, physically separating cluster nodes to prevent cross talk, or advanced networking policy. @@ -169,7 +169,7 @@ By default these APIs are accessible by pods running on an instance and can cont credentials for that node, or provisioning data such as kubelet credentials. These credentials can be used to escalate within the cluster or to other cloud services under the same account. -When running Kubernetes on a cloud platform limit permissions given to instance credentials, use +When running Kubernetes on a cloud platform, limit permissions given to instance credentials, use [network policies](/docs/tasks/administer-cluster/declare-network-policy/) to restrict pod access to the metadata API, and avoid using provisioning data to deliver secrets. @@ -177,7 +177,7 @@ to the metadata API, and avoid using provisioning data to deliver secrets. By default, there are no restrictions on which nodes may run a pod. Kubernetes offers a [rich set of policies for controlling placement of pods onto nodes](/docs/concepts/scheduling-eviction/assign-pod-node/) -and the [taint based pod placement and eviction](/docs/concepts/scheduling-eviction/taint-and-toleration/) +and the [taint-based pod placement and eviction](/docs/concepts/scheduling-eviction/taint-and-toleration/) that are available to end users. For many clusters use of these policies to separate workloads can be a convention that authors adopt or enforce via tooling. @@ -223,8 +223,9 @@ do not use. The shorter the lifetime of a secret or credential the harder it is for an attacker to make use of that credential. Set short lifetimes on certificates and automate their rotation. Use an authentication provider that can control how long issued tokens are available and use short -lifetimes where possible. If you use service account tokens in external integrations, plan to -rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap token used for setting up nodes should be revoked or its authorization removed. +lifetimes where possible. If you use service-account tokens in external integrations, plan to +rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap +token used for setting up nodes should be revoked or its authorization removed. ### Review third party integrations before enabling them @@ -246,7 +247,8 @@ and may grant an attacker significant visibility into the state of your cluster. your backups using a well reviewed backup and encryption solution, and consider using full disk encryption where possible. -Kubernetes supports [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/), a feature introduced in 1.7, and beta since 1.13. This will encrypt `Secret` resources in etcd, preventing +Kubernetes supports [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/), a feature +introduced in 1.7, and beta since 1.13. This will encrypt `Secret` resources in etcd, preventing parties that gain access to your etcd backups from viewing the content of those secrets. While this feature is currently beta, it offers an additional level of defense when backups are not encrypted or an attacker gains read access to etcd. diff --git a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md index 60af560e30..f81623982f 100644 --- a/content/en/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/en/docs/tasks/administer-cluster/sysctl-cluster.md @@ -6,19 +6,20 @@ content_type: task --- -{{< feature-state for_k8s_version="v1.12" state="beta" >}} + +{{< feature-state for_k8s_version="v1.21" state="stable" >}} This document describes how to configure and use kernel parameters within a Kubernetes cluster using the {{< glossary_tooltip term_id="sysctl" >}} interface. - - ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} +For some steps, you also need to be able to reconfigure the command line +options for the kubelets running on your cluster. @@ -166,6 +167,8 @@ to schedule those pods onto the right nodes. ## PodSecurityPolicy +{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} + You can further control which sysctls can be set in pods by specifying lists of sysctls or sysctl patterns in the `forbiddenSysctls` and/or `allowedUnsafeSysctls` fields of the PodSecurityPolicy. A sysctl pattern ends diff --git a/content/en/docs/tasks/administer-cluster/topology-manager.md b/content/en/docs/tasks/administer-cluster/topology-manager.md index 7d3f017940..e8d2e7c19d 100644 --- a/content/en/docs/tasks/administer-cluster/topology-manager.md +++ b/content/en/docs/tasks/administer-cluster/topology-manager.md @@ -69,6 +69,10 @@ Details on the various `scopes` and `policies` available today can be found belo To align CPU resources with other requested resources in a Pod Spec, the CPU Manager should be enabled and proper CPU Manager policy should be configured on a Node. See [control CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/). {{< /note >}} +{{< note >}} +To align memory (and hugepages) resources with other requested resources in a Pod Spec, the Memory Manager should be enabled and proper Memory Manager policy should be configured on a Node. Examine [Memory Manager](/docs/tasks/administer-cluster/memory-manager/) documentation. +{{< /note >}} + ### Topology Manager Scopes The Topology Manager can deal with the alignment of resources in a couple of distinct scopes: @@ -263,8 +267,4 @@ Using this information the Topology Manager calculates the optimal hint for the ### Known Limitations 1. The maximum number of NUMA nodes that Topology Manager allows is 8. With more than 8 NUMA nodes there will be a state explosion when trying to enumerate the possible NUMA affinities and generating their hints. -2. The scheduler is not topology-aware, so it is possible to be scheduled on a node and then fail on the node due to the Topology Manager. - -3. The Device Manager and the CPU Manager are the only components to adopt the Topology Manager's HintProvider interface. This means that NUMA alignment can only be achieved for resources managed by the CPU Manager and the Device Manager. Memory or Hugepages are not considered by the Topology Manager for NUMA alignment. - - +2. The scheduler is not topology-aware, so it is possible to be scheduled on a node and then fail on the node due to the Topology Manager. \ No newline at end of file diff --git a/content/en/docs/tasks/administer-cluster/use-cascading-deletion.md b/content/en/docs/tasks/administer-cluster/use-cascading-deletion.md new file mode 100644 index 0000000000..977278ae60 --- /dev/null +++ b/content/en/docs/tasks/administer-cluster/use-cascading-deletion.md @@ -0,0 +1,352 @@ +--- +title: Use Cascading Deletion in a Cluster +content_type: task +--- + + + +This page shows you how to specify the type of [cascading deletion](/docs/concepts/workloads/controllers/garbage-collection/#cascading-deletion) +to use in your cluster during {{}}. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + +You also need to [create a sample Deployment](/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment) +to experiment with the different types of cascading deletion. You will need to +recreate the Deployment for each type. + +## Check owner references on your pods + +Check that the `ownerReferences` field is present on your pods: + +```shell +kubectl get pods -l app=nginx --output=yaml +``` + +The output has an `ownerReferences` field similar to this: + +``` +apiVersion: v1 + ... + ownerReferences: + - apiVersion: apps/v1 + blockOwnerDeletion: true + controller: true + kind: ReplicaSet + name: nginx-deployment-6b474476c4 + uid: 4fdcd81c-bd5d-41f7-97af-3a3b759af9a7 + ... +``` + +## Use foreground cascading deletion {#use-foreground-cascading-deletion} + +By default, Kubernetes uses [background cascading deletion](/docs/concepts/workloads/controllers/garbage-collection/#background-deletion) +to delete dependents of an object. You can switch to foreground cascading deletion +using either `kubectl` or the Kubernetes API, depending on the Kubernetes +version your cluster runs. {{}} + +{{}} +{{% tab name="Kubernetes 1.20.x and later" %}} +You can delete objects using foreground cascading deletion using `kubectl` or the +Kubernetes API. + +**Using kubectl** + +Run the following command: + + +```shell +kubectl delete deployment nginx-deployment --cascade=foreground +``` + +**Using the Kubernetes API** + +1. Start a local proxy session: + + ```shell + kubectl proxy --port=8080 + ``` + +1. Use `curl` to trigger deletion: + + ```shell + curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \ + -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ + -H "Content-Type: application/json" + ``` + + The output contains a `foregroundDeletion` {{}} + like this: + + ``` + "kind": "Deployment", + "apiVersion": "apps/v1", + "metadata": { + "name": "nginx-deployment", + "namespace": "default", + "uid": "d1ce1b02-cae8-4288-8a53-30e84d8fa505", + "resourceVersion": "1363097", + "creationTimestamp": "2021-07-08T20:24:37Z", + "deletionTimestamp": "2021-07-08T20:27:39Z", + "finalizers": [ + "foregroundDeletion" + ] + ... + ``` + +{{% /tab %}} +{{% tab name="Versions prior to Kubernetes 1.20.x" %}} +You can delete objects using foreground cascading deletion by calling the +Kubernetes API. + +For details, read the [documentation for your Kubernetes version](/docs/home/supported-doc-versions/). + +1. Start a local proxy session: + + ```shell + kubectl proxy --port=8080 + ``` + +1. Use `curl` to trigger deletion: + + ```shell + curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \ + -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ + -H "Content-Type: application/json" + ``` + + The output contains a `foregroundDeletion` {{}} + like this: + + ``` + "kind": "Deployment", + "apiVersion": "apps/v1", + "metadata": { + "name": "nginx-deployment", + "namespace": "default", + "uid": "d1ce1b02-cae8-4288-8a53-30e84d8fa505", + "resourceVersion": "1363097", + "creationTimestamp": "2021-07-08T20:24:37Z", + "deletionTimestamp": "2021-07-08T20:27:39Z", + "finalizers": [ + "foregroundDeletion" + ] + ... + ``` +{{% /tab %}} +{{}} + +## Use background cascading deletion {#use-background-cascading-deletion} + +1. [Create a sample Deployment](/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment). +1. Use either `kubectl` or the Kubernetes API to delete the Deployment, + depending on the Kubernetes version your cluster runs. {{}} + +{{}} +{{% tab name="Kubernetes version 1.20.x and later" %}} + +You can delete objects using background cascading deletion using `kubectl` +or the Kubernetes API. + +Kubernetes uses background cascading deletion by default, and does so +even if you run the following commands without the `--cascade` flag or the +`propagationPolicy` argument. + +**Using kubectl** + +Run the following command: + +```shell +kubectl delete deployment nginx-deployment --cascade=background +``` + +**Using the Kubernetes API** + +1. Start a local proxy session: + + ```shell + kubectl proxy --port=8080 + ``` + +1. Use `curl` to trigger deletion: + + ```shell + curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \ + -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \ + -H "Content-Type: application/json" + ``` + + The output is similar to this: + + ``` + "kind": "Status", + "apiVersion": "v1", + ... + "status": "Success", + "details": { + "name": "nginx-deployment", + "group": "apps", + "kind": "deployments", + "uid": "cc9eefb9-2d49-4445-b1c1-d261c9396456" + } + ``` +{{% /tab %}} +{{% tab name="Versions prior to Kubernetes 1.20.x" %}} +Kubernetes uses background cascading deletion by default, and does so +even if you run the following commands without the `--cascade` flag or the +`propagationPolicy: Background` argument. + +For details, read the [documentation for your Kubernetes version](/docs/home/supported-doc-versions/). + +**Using kubectl** + +Run the following command: + +```shell +kubectl delete deployment nginx-deployment --cascade=true +``` + +**Using the Kubernetes API** + +1. Start a local proxy session: + + ```shell + kubectl proxy --port=8080 + ``` + +1. Use `curl` to trigger deletion: + + ```shell + curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \ + -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \ + -H "Content-Type: application/json" + ``` + + The output is similar to this: + + ``` + "kind": "Status", + "apiVersion": "v1", + ... + "status": "Success", + "details": { + "name": "nginx-deployment", + "group": "apps", + "kind": "deployments", + "uid": "cc9eefb9-2d49-4445-b1c1-d261c9396456" + } + ``` +{{% /tab %}} +{{}} + + +## Delete owner objects and orphan dependents {#set-orphan-deletion-policy} + +By default, when you tell Kubernetes to delete an object, the +{{}} also deletes +dependent objects. You can make Kubernetes *orphan* these dependents using +`kubectl` or the Kubernetes API, depending on the Kubernetes version your +cluster runs. {{}} + +{{}} +{{% tab name="Kubernetes version 1.20.x and later" %}} + +**Using kubectl** + +Run the following command: + +```shell +kubectl delete deployment nginx-deployment --cascade=orphan +``` + +**Using the Kubernetes API** + +1. Start a local proxy session: + + ```shell + kubectl proxy --port=8080 + ``` + +1. Use `curl` to trigger deletion: + + ```shell + curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \ + -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ + -H "Content-Type: application/json" + ``` + + The output contains `orphan` in the `finalizers` field, similar to this: + + ``` + "kind": "Deployment", + "apiVersion": "apps/v1", + "namespace": "default", + "uid": "6f577034-42a0-479d-be21-78018c466f1f", + "creationTimestamp": "2021-07-09T16:46:37Z", + "deletionTimestamp": "2021-07-09T16:47:08Z", + "deletionGracePeriodSeconds": 0, + "finalizers": [ + "orphan" + ], + ... + ``` + +{{% /tab %}} +{{% tab name="Versions prior to Kubernetes 1.20.x" %}} + +For details, read the [documentation for your Kubernetes version](/docs/home/supported-doc-versions/). + +**Using kubectl** + +Run the following command: + +```shell +kubectl delete deployment nginx-deployment --cascade=orphan +``` + +**Using the Kubernetes API** + +1. Start a local proxy session: + + ```shell + kubectl proxy --port=8080 + ``` + +1. Use `curl` to trigger deletion: + + ```shell + curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \ + -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \ + -H "Content-Type: application/json" + ``` + + The output contains `orphan` in the `finalizers` field, similar to this: + + ``` + "kind": "Deployment", + "apiVersion": "apps/v1", + "namespace": "default", + "uid": "6f577034-42a0-479d-be21-78018c466f1f", + "creationTimestamp": "2021-07-09T16:46:37Z", + "deletionTimestamp": "2021-07-09T16:47:08Z", + "deletionGracePeriodSeconds": 0, + "finalizers": [ + "orphan" + ], + ... + ``` +{{% /tab %}} +{{}} + +You can check that the Pods managed by the Deployment are still running: + +```shell +kubectl get pods -l app=nginx +``` + +## {{% heading "whatsnext" %}} + +* Learn about [owners and dependents](/docs/concepts/overview/working-with-objects/owners-dependents/) in Kubernetes. +* Learn about Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/). +* Learn about [garbage collection](/docs/concepts/workloads/controllers/garbage-collection/). \ No newline at end of file diff --git a/content/en/docs/tasks/configmap-secret/_index.md b/content/en/docs/tasks/configmap-secret/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tasks/configmap-secret/managing-secret-using-config-file.md b/content/en/docs/tasks/configmap-secret/managing-secret-using-config-file.md index b405d57baf..6fb5cdca3d 100644 --- a/content/en/docs/tasks/configmap-secret/managing-secret-using-config-file.md +++ b/content/en/docs/tasks/configmap-secret/managing-secret-using-config-file.md @@ -1,5 +1,5 @@ --- -title: Managing Secret using Configuration File +title: Managing Secrets using Configuration File content_type: task weight: 20 description: Creating Secret objects using resource configuration file. @@ -131,6 +131,8 @@ The output is similar to: ```yaml apiVersion: v1 +data: + config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19 kind: Secret metadata: creationTimestamp: 2018-11-15T20:40:59Z @@ -139,8 +141,6 @@ metadata: resourceVersion: "7225" uid: c280ad2e-e916-11e8-98f2-025000000001 type: Opaque -data: - config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19 ``` The commands `kubectl get` and `kubectl describe` avoid showing the contents of a `Secret` by @@ -168,6 +168,8 @@ Results in the following Secret: ```yaml apiVersion: v1 +data: + username: YWRtaW5pc3RyYXRvcg== kind: Secret metadata: creationTimestamp: 2018-11-15T20:46:46Z @@ -176,8 +178,6 @@ metadata: resourceVersion: "7579" uid: 91460ecb-e917-11e8-98f2-025000000001 type: Opaque -data: - username: YWRtaW5pc3RyYXRvcg== ``` Where `YWRtaW5pc3RyYXRvcg==` decodes to `administrator`. @@ -193,6 +193,6 @@ kubectl delete secret mysecret ## {{% heading "whatsnext" %}} - Read more about the [Secret concept](/docs/concepts/configuration/secret/) -- Learn how to [manage Secret with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) -- Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- Learn how to [manage Secrets with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- Learn how to [manage Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) diff --git a/content/en/docs/tasks/configmap-secret/managing-secret-using-kubectl.md b/content/en/docs/tasks/configmap-secret/managing-secret-using-kubectl.md index 293915736e..dad86e36df 100644 --- a/content/en/docs/tasks/configmap-secret/managing-secret-using-kubectl.md +++ b/content/en/docs/tasks/configmap-secret/managing-secret-using-kubectl.md @@ -1,5 +1,5 @@ --- -title: Managing Secret using kubectl +title: Managing Secrets using kubectl content_type: task weight: 10 description: Creating Secret objects using kubectl command line. @@ -15,7 +15,7 @@ description: Creating Secret objects using kubectl command line. ## Create a Secret -A `Secret` can contain user credentials required by Pods to access a database. +A `Secret` can contain user credentials required by pods to access a database. For example, a database connection string consists of a username and password. You can store the username in a file `./username.txt` and the password in a file `./password.txt` on your local machine. @@ -24,11 +24,10 @@ file `./password.txt` on your local machine. echo -n 'admin' > ./username.txt echo -n '1f2d1e2e67df' > ./password.txt ``` - -The `-n` flag in the above two commands ensures that the generated files will -not contain an extra newline character at the end of the text. This is -important because when `kubectl` reads a file and encode the content into -base64 string, the extra newline character gets encoded too. +In these commands, the `-n` flag ensures that the generated files do not have +an extra newline character at the end of the text. This is important because +when `kubectl` reads a file and encodes the content into a base64 string, the +extra newline character gets encoded too. The `kubectl create secret` command packages these files into a Secret and creates the object on the API server. @@ -45,7 +44,7 @@ The output is similar to: secret/db-user-pass created ``` -Default key name is the filename. You may optionally set the key name using +The default key name is the filename. You can optionally set the key name using `--from-file=[key=]source`. For example: ```shell @@ -54,27 +53,28 @@ kubectl create secret generic db-user-pass \ --from-file=password=./password.txt ``` -You do not need to escape special characters in passwords from files -(`--from-file`). +You do not need to escape special characters in password strings that you +include in a file. You can also provide Secret data using the `--from-literal==` tag. This tag can be specified more than once to provide multiple key-value pairs. Note that special characters such as `$`, `\`, `*`, `=`, and `!` will be interpreted by your [shell](https://en.wikipedia.org/wiki/Shell_(computing)) and require escaping. + In most shells, the easiest way to escape the password is to surround it with -single quotes (`'`). For example, if your actual password is `S!B\*d$zDsb=`, -you should execute the command this way: +single quotes (`'`). For example, if your password is `S!B\*d$zDsb=`, +run the following command: ```shell -kubectl create secret generic dev-db-secret \ +kubectl create secret generic db-user-pass \ --from-literal=username=devuser \ --from-literal=password='S!B\*d$zDsb=' ``` ## Verify the Secret -You can check that the secret was created: +Check that the Secret was created: ```shell kubectl get secrets @@ -111,7 +111,7 @@ username: 5 bytes The commands `kubectl get` and `kubectl describe` avoid showing the contents of a `Secret` by default. This is to protect the `Secret` from being exposed -accidentally to an onlooker, or from being stored in a terminal log. +accidentally, or from being stored in a terminal log. ## Decoding the Secret {#decoding-secret} @@ -141,7 +141,7 @@ The output is similar to: ## Clean Up -To delete the Secret you have created: +Delete the Secret you created: ```shell kubectl delete secret db-user-pass @@ -152,5 +152,5 @@ kubectl delete secret db-user-pass ## {{% heading "whatsnext" %}} - Read more about the [Secret concept](/docs/concepts/configuration/secret/) -- Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/) -- Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- Learn how to [manage Secrets using config files](/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- Learn how to [manage Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) diff --git a/content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md b/content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md index fb257a6026..db9f5b40f3 100644 --- a/content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md +++ b/content/en/docs/tasks/configmap-secret/managing-secret-using-kustomize.md @@ -1,5 +1,5 @@ --- -title: Managing Secret using Kustomize +title: Managing Secrets using Kustomize content_type: task weight: 30 description: Creating Secret objects using kustomization.yaml file. @@ -48,7 +48,19 @@ secretGenerator: - password=1f2d1e2e67df ``` -Note that in both cases, you don't need to base64 encode the values. +You can also define the `secretGenerator` in the `kustomization.yaml` +file by providing `.env` files. +For example, the following `kustomization.yaml` file pulls in data from +`.env.secret` file: + +```yaml +secretGenerator: +- name: db-user-pass + envs: + - .env.secret +``` + +Note that in all cases, you don't need to base64 encode the values. ## Create the Secret @@ -123,6 +135,6 @@ kubectl delete secret db-user-pass-96mffmfh4k ## {{% heading "whatsnext" %}} - Read more about the [Secret concept](/docs/concepts/configuration/secret/) -- Learn how to [manage Secret with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) -- Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- Learn how to [manage Secrets with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- Learn how to [manage Secrets using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/) diff --git a/content/en/docs/tasks/configure-pod-container/_index.md b/content/en/docs/tasks/configure-pod-container/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md index 360deada02..0073feea24 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md +++ b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md @@ -197,21 +197,70 @@ As Pod specs with GMSA fields populated (as described above) are applied in a cl 1. The container runtime configures each Windows container with the specified GMSA credential spec so that the container can assume the identity of the GMSA in Active Directory and access services in the domain using that identity. +## Containerd + +On Windows Server 2019, in order to use GMSA with containerd, you must be running OS Build 17763.1817 (or later) which can be installed using the patch [KB5000822](https://support.microsoft.com/en-us/topic/march-9-2021-kb5000822-os-build-17763-1817-2eb6197f-e3b1-4f42-ab51-84345e063564). + +There is also a known issue with containerd that occurs when trying to connect to SMB shares from Pods. Once you have configured GMSA, the pod will be unable to connect to the share using the hostname or FQDN, but connecting to the share using an IP address works as expected. + +```PowerShell +ping adserver.ad.local +``` +and correctly resolves the hostname to an IPv4 address. The output is similar to: + +``` +Pinging adserver.ad.local [192.168.111.18] with 32 bytes of data: +Reply from 192.168.111.18: bytes=32 time=6ms TTL=124 +Reply from 192.168.111.18: bytes=32 time=5ms TTL=124 +Reply from 192.168.111.18: bytes=32 time=5ms TTL=124 +Reply from 192.168.111.18: bytes=32 time=5ms TTL=124 +``` + +However, when attempting to browse the directory using the hostname + +```PowerShell +cd \\adserver.ad.local\test +``` + +you see an error that implies the target share doesn't exist: + +``` +cd : Cannot find path '\\adserver.ad.local\test' because it does not exist. +At line:1 char:1 ++ cd \\adserver.ad.local\test ++ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + CategoryInfo : ObjectNotFound: (\\adserver.ad.local\test:String) [Set-Location], ItemNotFoundException + + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommand +``` + +but you notice that the error disappears if you browse to the share using its IPv4 address instead; for example: + +```PowerShell +cd \\192.168.111.18\test +``` + +After you change into a directory within the share, you see a prompt similar to: + +``` +Microsoft.PowerShell.Core\FileSystem::\\192.168.111.18\test> +``` + +To correct the behaviour you must run the following on the node `reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1` to add the required registry key. This node change will only take effect in newly created pods, meaning you must now recreate any running pods which require access to SMB shares. + ## Troubleshooting If you are having difficulties getting GMSA to work in your environment, there are a few troubleshooting steps you can take. -First, make sure the credspec has been passed to the Pod. To do this you will need to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command. In the example below the Pod did not get the credspec correctly: +First, make sure the credspec has been passed to the Pod. To do this you will need to `exec` into one of your Pods and check the output of the `nltest.exe /parentdomain` command. -```shell +In the example below the Pod did not get the credspec correctly: + +```PowerShell kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe - -Windows PowerShell -Copyright (C) Microsoft Corporation. All rights reserved. - -PS C:\> nltest.exe /parentdomain +``` +nltest.exe /parentdomain` results in the following error: +``` Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE -PS C:\> ``` If your Pod did get the credspec correctly, then next check communication with the domain. First, from inside of your Pod, quickly do an nslookup to find the root of your domain. @@ -224,23 +273,30 @@ This will tell us 3 things: If the DNS and communication test passes, next you will need to check if the Pod has established secure channel communication with the domain. To do this, again, `exec` into your Pod and run the `nltest.exe /query` command. -```shell -PS C:\> nltest.exe /query +```PowerShell +nltest.exe /query +``` + +Results in the following output: +``` I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE ``` -This tells us that for some reason, the Pod was unable to logon to the domain using the account specified in the credspec. You can try to repair the secure channel by running the `nltest.exe /sc_reset:domain.example` command. +This tells us that for some reason, the Pod was unable to logon to the domain using the account specified in the credspec. You can try to repair the secure channel by running the following: -```shell -PS C:\> nltest /sc_reset:domain.example +```PowerShell +nltest /sc_reset:domain.example +``` + +If the command is successful you will see and output similar to this: +``` Flags: 30 HAS_IP HAS_TIMESERV Trusted DC Name \\dc10.domain.example Trusted DC Connection Status Status = 0 0x0 NERR_Success The command completed successfully -PS C:\> ``` -If the above command corrects the error, you can automate the step by adding the following lifecycle hook to your Pod spec. If it did not correct the error, you will need to examine your credspec again and confirm that it is correct and complete. +If the above corrects the error, you can automate the step by adding the following lifecycle hook to your Pod spec. If it did not correct the error, you will need to examine your credspec again and confirm that it is correct and complete. ```yaml image: registry.domain.example/iis-auth:1809v1 @@ -252,6 +308,3 @@ If the above command corrects the error, you can automate the step by adding the ``` If you add the `lifecycle` section show above to your Pod spec, the Pod will execute the commands listed to restart the `netlogon` service until the `nltest.exe /query` command exits without error. - -## GMSA limitations -When using the [ContainerD runtime for Windows](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#cri-containerd) accessing restricted network shares via the GMSA domain identity fails. The container will receive the identity of and calls from `nltest.exe /query` will work. It is recommended to use the [Docker EE runtime](/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#docker-ee) if access to network shares is required. The Windows Server team is working on resolving the issue in the Windows Kernel and will release a patch to resolve this issue in the future. Look for updates on the [Microsoft Windows Containers issue tracker](https://github.com/microsoft/Windows-Containers/issues/44). diff --git a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 918a5bf33e..d9ab2056da 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -30,7 +30,7 @@ getting killed by the kubelet before they are up and running. ## {{% heading "prerequisites" %}} -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} +{{< include "task-tutorial-prereqs.md" >}} @@ -145,7 +145,7 @@ Any code greater than or equal to 200 and less than 400 indicates success. Any other code indicates failure. You can see the source code for the server in -[server.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/test/images/agnhost/liveness/server.go). +[server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go). For the first 10 seconds that the container is alive, the `/healthz` handler returns a status of 200. After that, the handler returns a status of 500. @@ -427,7 +427,63 @@ For a TCP probe, the kubelet makes the probe connection at the node, not in the means that you can not use a service name in the `host` parameter since the kubelet is unable to resolve it. +### Probe-level `terminationGracePeriodSeconds` +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +Prior to release 1.21, the pod-level `terminationGracePeriodSeconds` was used +for terminating a container that failed its liveness or startup probe. This +coupling was unintended and may have resulted in failed containers taking an +unusually long time to restart when a pod-level `terminationGracePeriodSeconds` +was set. + +In 1.21 and beyond, when the feature gate `ProbeTerminationGracePeriod` is +enabled, users can specify a probe-level `terminationGracePeriodSeconds` as +part of the probe specification. When the feature gate is enabled, and both a +pod- and probe-level `terminationGracePeriodSeconds` are set, the kubelet will +use the probe-level value. + +{{< note >}} +As of Kubernetes 1.22, the `ProbeTerminationGracePeriod` feature gate is only +available on the API Server. The kubelet always honors the probe-level +`terminationGracePeriodSeconds` field if it is present on a Pod. + +If you have existing Pods where the `terminationGracePeriodSeconds` field is set and +you no longer wish to use per-probe termination grace periods, you must delete +those existing Pods. + +When you (or the control plane, or some other component) create replacement +Pods, and the feature gate `ProbeTerminationGracePeriod` is disabled, then the +API server ignores the Pod-level `terminationGracePeriodSeconds` field, even if +a Pod or pod template specifies it. +{{< /note >}} + +For example, + +```yaml +spec: + terminationGracePeriodSeconds: 3600 # pod-level + containers: + - name: test + image: ... + + ports: + - name: liveness-port + containerPort: 8080 + hostPort: 8080 + + livenessProbe: + httpGet: + path: /healthz + port: liveness-port + failureThreshold: 1 + periodSeconds: 60 + # Override pod-level terminationGracePeriodSeconds # + terminationGracePeriodSeconds: 60 +``` + +Probe-level `terminationGracePeriodSeconds` cannot be set for readiness probes. +It will be rejected by the API server. ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md index 40987152e8..d52a4acc66 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -624,9 +624,20 @@ Like before, all previous files in the `/etc/config/` directory will be deleted. You can project keys to specific paths and specific permissions on a per-file basis. The [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) user guide explains the syntax. +### Optional References + +A ConfigMap reference may be marked "optional". If the ConfigMap is non-existent, the mounted volume will be empty. If the ConfigMap exists, but the referenced +key is non-existent the path will be absent beneath the mount point. + ### Mounted ConfigMaps are updated automatically -When a ConfigMap already being consumed in a volume is updated, projected keys are eventually updated as well. Kubelet is checking whether the mounted ConfigMap is fresh on every periodic sync. However, it is using its local ttl-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period (1 minute by default) + ttl of ConfigMaps cache (1 minute by default) in kubelet. You can trigger an immediate refresh by updating one of the pod's annotations. +When a mounted ConfigMap is updated, the projected content is eventually updated too. This applies in the case where an optionally referenced ConfigMap comes into +existence after a pod has started. + +Kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, it uses its local TTL-based cache for getting the current value of the +ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as +kubelet sync period (1 minute by default) + TTL of ConfigMaps cache (1 minute by default) in kubelet. You can trigger an immediate refresh by updating one of +the pod's annotations. {{< note >}} A container using a ConfigMap as a [subPath](/docs/concepts/storage/volumes/#using-subpath) volume will not receive ConfigMap updates. diff --git a/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md b/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md index ad99a05c27..ca71e7a721 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md +++ b/content/en/docs/tasks/configure-pod-container/configure-projected-volume-storage.md @@ -83,5 +83,5 @@ kubectl delete secret user pass ## {{% heading "whatsnext" %}} * Learn more about [`projected`](/docs/concepts/storage/volumes/#projected) volumes. -* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md) design document. +* Read the [all-in-one volume](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md) design document. diff --git a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md index 12c10a9ddf..9ddcac270f 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md +++ b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md @@ -23,7 +23,7 @@ You need to have a Kubernetes cluster and the kubectl command-line tool must be ## Set the Username for a Pod -To specify the username with which to execute the Pod's container processes, include the `securityContext` field ([PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core) in the Pod specification, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core) field containing the `runAsUserName` field. +To specify the username with which to execute the Pod's container processes, include the `securityContext` field ([PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)) in the Pod specification, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)) field containing the `runAsUserName` field. The Windows security context options that you specify for a Pod apply to all Containers and init Containers in the Pod. @@ -63,7 +63,7 @@ ContainerUser ## Set the Username for a Container -To specify the username with which to execute a Container's processes, include the `securityContext` field ([SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)) in the Container manifest, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core) field containing the `runAsUserName` field. +To specify the username with which to execute a Container's processes, include the `securityContext` field ([SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)) in the Container manifest, and within it, the `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)) field containing the `runAsUserName` field. The Windows security context options that you specify for a Container apply only to that individual Container, and they override the settings made at the Pod level. diff --git a/content/en/docs/tasks/configure-pod-container/configure-service-account.md b/content/en/docs/tasks/configure-pod-container/configure-service-account.md index d96a5c8270..e5a0e26ea0 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/en/docs/tasks/configure-pod-container/configure-service-account.md @@ -167,8 +167,8 @@ The output is similar to this: Name: build-robot-secret Namespace: default Labels: -Annotations: kubernetes.io/service-account.name=build-robot - kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da +Annotations: kubernetes.io/service-account.name: build-robot + kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da Type: kubernetes.io/service-account-token @@ -323,11 +323,10 @@ The application is responsible for reloading the token when it rotates. Periodic ## Service Account Issuer Discovery -{{< feature-state for_k8s_version="v1.20" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} -The Service Account Issuer Discovery feature is enabled by enabling the -`ServiceAccountIssuerDiscovery` [feature gate](/docs/reference/command-line-tools-reference/feature-gates) -and then enabling the Service Account Token Projection feature as described +The Service Account Issuer Discovery feature is enabled when the Service Account +Token Projection feature is enabled, as described [above](#service-account-token-volume-projection). {{< note >}} @@ -349,9 +348,12 @@ Configuration document at `/.well-known/openid-configuration` and the associated JSON Web Key Set (JWKS) at `/openid/v1/jwks`. The OpenID Provider Configuration is sometimes referred to as the _discovery document_. -When enabled, the cluster is also configured with a default RBAC ClusterRole -called `system:service-account-issuer-discovery`. No role bindings are provided -by default. Administrators may, for example, choose whether to bind the role to +Clusters include a default RBAC ClusterRole called +`system:service-account-issuer-discovery`. A default RBAC ClusterRoleBinding +assigns this role to the `system:serviceaccounts` group, which all service +accounts implicitly belong to. This allows pods running on the cluster to access +the service account discovery document via their mounted service account token. +Administrators may, additionally, choose to bind the role to `system:authenticated` or `system:unauthenticated` depending on their security requirements and which external systems they intend to federate with. @@ -381,5 +383,5 @@ JWKS URI is required to use the `https` scheme. See also: - [Cluster Admin Guide to Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/) -- [Service Account Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/20190730-oidc-discovery.md) +- [Service Account Signing Key Retrieval KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1393-oidc-discovery) - [OIDC Discovery Spec](https://openid.net/specs/openid-connect-discovery-1_0.html) diff --git a/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md b/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md new file mode 100644 index 0000000000..2ab2bd3661 --- /dev/null +++ b/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md @@ -0,0 +1,214 @@ +--- +title: Create a Windows HostProcess Pod +content_type: task +weight: 20 +min-kubernetes-server-version: 1.22 +--- + + + +{{< feature-state for_k8s_version="v1.22" state="alpha" >}} + +Windows HostProcess containers enable you to run containerized +workloads on a Windows host. These containers operate as +normal processes but have access to the host network namespace, +storage, and devices when given the appropriate user privileges. +HostProcess containers can be used to deploy network plugins, +storage configurations, device plugins, kube-proxy, and other +components to Windows nodes without the need for dedicated proxies or +the direct installation of host services. + +Administrative tasks such as installation of security patches, event +log collection, and more can be performed without requiring cluster operators to +log onto each Window node. HostProcess containers can run as any user that is +available on the host or is in the domain of the host machine, allowing administrators +to restrict resource access through user permissions. While neither filesystem or process +isolation are supported, a new volume is created on the host upon starting the container +to give it a clean and consolidated workspace. HostProcess containers can also be built on +top of existing Windows base images and do not inherit the same +[compatibility requirements](https://docs.microsoft.com/virtualization/windowscontainers/deploy-containers/version-compatibility) +as Windows server containers, meaning that the version of the base images does not need +to match that of the host. HostProcess containers also support +[volume mounts](./create-hostprocess-pod#volume-mounts) within the container volume. + +### When should I use a Windows HostProcess container? + +- When you need to perform tasks which require the networking namespace of the host. +HostProcess containers have access to the host's network interfaces and IP addresses. +- You need access to resources on the host such as the filesystem, event logs, etc. +- Installation of specific device drivers or Windows services. +- Consolidation of administrative tasks and security policies. This reduces the degree of +privileges needed by Windows nodes. + + +## {{% heading "prerequisites" %}} + +{{% version-check %}} + +To enable HostProcess containers while in Alpha you need to pass the following feature gate flag to +**kubelet** and **kube-apiserver**. +See [Features Gates](/docs/reference/command-line-tools-reference/feature-gates/#overview) +documentation for more details. + +``` +--feature-gates=WindowsHostProcessContainers=true +``` + +You can use the latest version of Containerd (v1.5.4+) with the following settings using the containerd +v2 configuration. Add these annotations to any runtime configurations were you wish to enable the +HostProcess container feature. + + +``` +[plugins] + [plugins."io.containerd.grpc.v1.cri"] + [plugins."io.containerd.grpc.v1.cri".containerd] + [plugins."io.containerd.grpc.v1.cri".containerd.default_runtime] + container_annotations = ["microsoft.com/hostprocess-container"] + pod_annotations = ["microsoft.com/hostprocess-container"] + [plugins."io.containerd.grpc.v1.cri".containerd.runtimes] + [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runhcs-wcow-process] + container_annotations = ["microsoft.com/hostprocess-container"] + pod_annotations = ["microsoft.com/hostprocess-container"] +``` + +The current versions of containerd ship with a version of hcsshim that does not have support. +You will need to build a version of hcsshim from the main branch following the +[instructions in hcsshim](https://github.com/Microsoft/hcsshim/#containerd-shim). +Once the containerd shim is built you can replace the file in your contianerd installation. +For example if you followed the instructions to +[install containerd](/docs/setup/production-environment/container-runtimes/#containerd) +replace the `containerd-shim-runhcs-v1.exe` is installed at `$Env:ProgramFiles\containerd` with the newly built shim. + +## Limitations + +- HostProcess containers require version 1.5.4 or higher of the containerd {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. +- As of v1.22 HostProcess pods can only contain HostProcess containers. This is a current limitation +of the Windows OS; non-privileged Windows containers cannot share a vNIC with the host IP namespace. +- HostProcess containers run as a process on the host and do not have any degree of +isolation other than resource constraints imposed on the HostProcess user account. Neither +filesystem or Hyper-V isolation are supported for HostProcess containers. +- Volume mounts are supported and are mounted under the container volume. +See [Volume Mounts](#volume-mounts) +- A limited set of host user accounts are available for HostProcess containers by default. +See [Choosing a User Account](#choosing-a-user-account). +- Resource limits (disk, memory, cpu count) are supported in the same fashion as processes +on the host. +- Both Named pipe mounts and Unix domain sockets are **not** currently supported and should instead +be accessed via their path on the host (e.g. \\\\.\\pipe\\\*) + +## HostProcess Pod configuration requirements + +Enabling a Windows HostProcess pod requires setting the right configurations in the pod security +configuration. Of the policies defined in the [Pod Security Standards](/docs/concepts/security/pod-security-standards) +HostProcess pods are disallowed by the baseline and restricted policies. It is therefore recommended +that HostProcess pods run in alignment with the privileged profile. + +When running under the privileged policy, here are +the configurations which need to be set to enable the creation of a HostProcess pod: + + + + + + + + + + + + + + + + + + + + + + + + + +
Privileged policy specification
ControlPolicy
Windows HostProcess +

Windows pods offer the ability to run + HostProcess containers which enables privileged access to the Windows node.

+

Allowed Values

+
    +
  • true
    • +
+
Host Networking +

Will be in host network by default initially. Support + to set network to a different compartment may be desirable in + the future.

+

Allowed Values

+
    +
  • true
    • +
+
runAsUsername +

Specification of which user the HostProcess container should run as is required for the pod spec.

+

Allowed Values

+
    +
  • NT AUTHORITY\SYSTEM
    • +
  • NT AUTHORITY\Local service
    • +
  • NT AUTHORITY\NetworkService
    • +
+
runAsNonRoot +

Because HostProcess containers have privileged access to the host, the runAsNonRoot field cannot be set to true.

+

Allowed Values

+
    +
  • Undefined/Nil
    • +
  • false
    • +
+
+ +### Example Manifest (excerpt) + +```yaml +spec: + securityContext: + windowsOptions: + hostProcess: true + runAsUserName: "NT AUTHORITY\\Local service" + hostNetwork: true + containers: + - name: test + image: image1:latest + command: + - ping + - -t + - 127.0.0.1 + nodeSelector: + "kubernetes.io/os": windows +``` + +## Volume Mounts + +HostProcess containers support the ability to mount volumes within the container volume space. +Applications running inside the container can access volume mounts directly via relative or +absolute paths. An environment variable `$CONTAINER_SANDBOX_MOUNT_POINT` is set upon container +creation and provides the absolute host path to the container volume. Relative paths are based +upon the `Pod.containers.volumeMounts.mountPath` configuration. + +### Example {#volume-mount-example} + +To access service account tokens the following path structures are supported within the container: + +`.\var\run\secrets\kubernetes.io\serviceaccount\` + +`$CONTAINER_SANDBOX_MOUNT_POINT\var\run\secrets\kubernetes.io\serviceaccount\` + +## Choosing a User Account + +HostProcess containers support the ability to run as one of three supported Windows service accounts: + +- **[LocalSystem](https://docs.microsoft.com/en-us/windows/win32/services/localsystem-account)** +- **[LocalService](https://docs.microsoft.com/en-us/windows/win32/services/localservice-account)** +- **[NetworkService](https://docs.microsoft.com/en-us/windows/win32/services/networkservice-account)** + +You should select an appropriate Windows service account for each HostProcess +container, aiming to limit the degree of privileges so as to avoid accidental (or even +malicious) damage to the host. The LocalSystem service account has the highest level +of privilege of the three and should be used only if absolutely necessary. Where possible, +use the LocalService service account as it is the least privileged of the three options. diff --git a/content/en/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md b/content/en/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md new file mode 100644 index 0000000000..ef8206b1b6 --- /dev/null +++ b/content/en/docs/tasks/configure-pod-container/enforce-standards-admission-controller.md @@ -0,0 +1,54 @@ +--- +title: Enforce Pod Security Standards by Configuring the Built-in Admission Controller +reviewers: +- tallclair +- liggitt +content_type: task +min-kubernetes-server-version: v1.22 +--- + +As of v1.22, Kubernetes provides a built-in [admission controller](/docs/reference/access-authn-authz/admission-controllers/#podsecurity) +to enforce the [Pod Security Standards](/docs/concepts/security/pod-security-standards). +You can configure this admission controller to set cluster-wide defaults and [exemptions](/docs/concepts/security/pod-security-admission/#exemptions). + +## {{% heading "prerequisites" %}} + +{{% version-check %}} + +- Enable the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features). + +## Configure the Admission Controller + +```yaml +apiVersion: apiserver.config.k8s.io/v1 +kind: AdmissionConfiguration +plugins: +- name: PodSecurity + configuration: + apiVersion: pod-security.admission.config.k8s.io/v1alpha1 + kind: PodSecurityConfiguration + # Defaults applied when a mode label is not set. + # + # Level label values must be one of: + # - "privileged" (default) + # - "baseline" + # - "restricted" + # + # Version label values must be one of: + # - "latest" (default) + # - specific version like "v{{< skew latestVersion >}}" + defaults: + enforce: "privileged" + enforce-version: "latest" + audit: "privileged" + audit-version: "latest" + warn: "privileged" + warn-version: "latest" + exemptions: + # Array of authenticated usernames to exempt. + usernames: [] + # Array of runtime class names to exempt. + runtimeClassNames: [] + # Array of namespaces to exempt. + namespaces: [] +``` \ No newline at end of file diff --git a/content/en/docs/tasks/configure-pod-container/enforce-standards-namespace-labels.md b/content/en/docs/tasks/configure-pod-container/enforce-standards-namespace-labels.md new file mode 100644 index 0000000000..9a4c3a44ed --- /dev/null +++ b/content/en/docs/tasks/configure-pod-container/enforce-standards-namespace-labels.md @@ -0,0 +1,87 @@ +--- +title: Enforce Pod Security Standards with Namespace Labels +reviewers: +- tallclair +- liggitt +content_type: task +min-kubernetes-server-version: v1.22 +--- + +Namespaces can be labeled to enforce the [Pod Security Standards](/docs/concepts/security/pod-security-standards). + +## {{% heading "prerequisites" %}} + +{{% version-check %}} + +- Enable the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features). + +## Requiring the `baseline` Pod Security Standard with namespace labels + +This manifest defines a Namespace `my-baseline-namespace` that: + +- _Blocks_ any pods that don't satisfy the `baseline` policy requirements. +- Generates a user-facing warning and adds an audit annotation to any created pod that does not + meet the `restricted` policy requirements. +- Pins the versions of the `baseline` and `restricted` policies to v{{< skew latestVersion >}}. + +```yaml +apiVersion: v1 +kind: Namespace +metadata: + name: my-baseline-namespace + labels: + pod-security.kubernetes.io/enforce: baseline + pod-security.kubernetes.io/enforce-version: v{{< skew latestVersion >}} + + # We are setting these to our _desired_ `enforce` level. + pod-security.kubernetes.io/audit: restricted + pod-security.kubernetes.io/audit-version: v{{< skew latestVersion >}} + pod-security.kubernetes.io/warn: restricted + pod-security.kubernetes.io/warn-version: v{{< skew latestVersion >}} +``` + +## Add labels to existing namespaces with `kubectl label` + +{{< note >}} +When an `enforce` policy (or version) label is added or changed, the admission plugin will test +each pod in the namespace against the new policy. Violations are returned to the user as warnings. +{{< /note >}} + +It is helpful to apply the `--dry-run` flag when initially evaluating security profile changes for +namespaces. The Pod Security Standard checks will still be run in _dry run_ mode, giving you +information about how the new policy would treat existing pods, without actually updating a policy. + +```shell +kubectl label --dry-run=server --overwrite ns --all \ + pod-security.kubernetes.io/enforce=baseline +``` + +### Applying to all namespaces + +If you're just getting started with the Pod Security Standards, a suitable first step would be to +configure all namespaces with audit annotations for a stricter level such as `baseline`: + +```shell +kubectl label --overwrite ns --all \ + pod-security.kubernetes.io/audit=baseline \ + pod-security.kubernetes.io/warn=baseline +``` + +Note that this is not setting an enforce level, so that namespaces that haven't been explicitly +evaluated can be distinguished. You can list namespaces without an explicitly set enforce level +using this command: + +```shell +kubectl get namespaces --selector='!pod-security.kubernetes.io/enforce' +``` + +### Applying to a single namespace + +You can update a specific namespace as well. This command adds the `enforce=restricted` +policy to `my-existing-namespace`, pinning the restricted policy version to v{{< skew latestVersion >}}. + +```shell +kubectl label --overwrite ns my-existing-namespace \ + pod-security.kubernetes.io/enforce=restricted \ + pod-security.kubernetes.io/enforce-version=v{{< skew latestVersion >}} +``` diff --git a/content/en/docs/tasks/configure-pod-container/migrate-from-psp.md b/content/en/docs/tasks/configure-pod-container/migrate-from-psp.md new file mode 100644 index 0000000000..f0ea2d02df --- /dev/null +++ b/content/en/docs/tasks/configure-pod-container/migrate-from-psp.md @@ -0,0 +1,48 @@ +--- +title: Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller +reviewers: +- tallclair +- liggitt +content_type: task +min-kubernetes-server-version: v1.22 +--- + + + +This page describes the process of migrating from PodSecurityPolicies to the built-in PodSecurity +admission controller. This can be done effectively using a combination of dry-run and `audit` and +`warn` modes, although this becomes harder if mutating PSPs are used. + +## {{% heading "prerequisites" %}} + +{{% version-check %}} + +- Enable the `PodSecurity` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features). + + + +## Steps + +- **Eliminate mutating PodSecurityPolicies, if your cluster has any set up.** + - Clone all mutating PSPs into a non-mutating version. + - Update all ClusterRoles authorizing use of those mutating PSPs to also authorize use of the + non-mutating variant. + - Watch for Pods using the mutating PSPs and work with code owners to migrate to valid, + non-mutating resources. + - Delete mutating PSPs. +- **Select a compatible policy level for each namespace.** Analyze existing resources in the + namespace to drive this decision. + - Review the requirements of the different [Pod Security Standards](/docs/concepts/security/pod-security-standards). + - Evaluate the difference in privileges that would come from disabling the PSP controller. + - In the event that a PodSecurityPolicy falls between two levels, consider: + - Selecting a _less_ permissive PodSecurity level prioritizes security, and may require adjusting + workloads to fit within the stricter policy. + - Selecting a _more_ permissive PodSecurity level prioritizes avoiding disrupting or + changing workloads, but may allow workload authors in the namespace greater permissions + than desired. +- **Apply the selected profiles in `warn` and `audit` mode.** This will give you an idea of how + your Pods will respond to the new policies, without breaking existing workloads. Iterate on your + [Pods' configuration](/docs/concepts/security/pod-security-admission#configuring-pods) until + they are in compliance with the selected profiles. +- Apply the profiles in `enforce` mode. +- Stop including `PodSecurityPolicy` in the `--enable-admission-plugins` flag. \ No newline at end of file diff --git a/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md index 697a4c6e0e..0886871f9c 100644 --- a/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/en/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -54,7 +54,7 @@ If you use a Docker credentials store, you won't see that `auth` entry but a `cr ## Create a Secret based on existing Docker credentials {#registry-secret-existing-credentials} -A Kubernetes cluster uses the Secret of `docker-registry` type to authenticate with +A Kubernetes cluster uses the Secret of `kubernetes.io/dockerconfigjson` type to authenticate with a container registry to pull a private image. If you already ran `docker login`, you can copy that credential into Kubernetes: @@ -102,7 +102,7 @@ kubectl create secret docker-registry regcred --docker-server=` is your Private Docker Registry FQDN. - Use `https://index.docker.io/v2/` for DockerHub. + Use `https://index.docker.io/v1/` for DockerHub. * `` is your Docker username. * `` is your Docker password. * `` is your Docker email. diff --git a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md index 0e6a02af37..abe6320563 100644 --- a/content/en/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/en/docs/tasks/configure-pod-container/quality-service-pod.md @@ -45,8 +45,12 @@ kubectl create namespace qos-example For a Pod to be given a QoS class of Guaranteed: -* Every Container, including init containers, in the Pod must have a memory limit and a memory request, and they must be the same. -* Every Container, including init containers, in the Pod must have a CPU limit and a CPU request, and they must be the same. +* Every Container in the Pod must have a memory limit and a memory request. +* For every Container in the Pod, the memory limit must equal the memory request. +* Every Container in the Pod must have a CPU limit and a CPU request. +* For every Container in the Pod, the CPU limit must equal the CPU request. + +These restrictions apply to init containers and app containers equally. Here is the configuration file for a Pod that has one Container. The Container has a memory limit and a memory request, both equal to 200 MiB. The Container has a CPU limit and a CPU request, both equal to 700 milliCPU: @@ -272,5 +276,3 @@ kubectl delete namespace qos-example - - diff --git a/content/en/docs/tasks/configure-pod-container/security-context.md b/content/en/docs/tasks/configure-pod-container/security-context.md index 104dc0003f..56bcc0f3f9 100644 --- a/content/en/docs/tasks/configure-pod-container/security-context.md +++ b/content/en/docs/tasks/configure-pod-container/security-context.md @@ -24,7 +24,7 @@ a Pod or Container. Security context settings include, but are not limited to: * [AppArmor](/docs/tutorials/clusters/apparmor/): Use program profiles to restrict the capabilities of individual programs. -* [Seccomp](https://en.wikipedia.org/wiki/Seccomp): Filter a process's system calls. +* [Seccomp](/docs/tutorials/clusters/seccomp/): Filter a process's system calls. * AllowPrivilegeEscalation: Controls whether a process can gain more privileges than its parent process. This bool directly controls whether the [`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) flag gets set on the container process. AllowPrivilegeEscalation is true always when the container is: 1) run as Privileged OR 2) has `CAP_SYS_ADMIN`. @@ -176,7 +176,6 @@ securityContext: fsGroupChangePolicy: "OnRootMismatch" ``` -This is an alpha feature. To use it, enable the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `ConfigurableFSGroupPolicy` for the kube-api-server, the kube-controller-manager, and for the kubelet. {{< note >}} This field has no effect on ephemeral volume types such as @@ -185,6 +184,25 @@ This field has no effect on ephemeral volume types such as and [`emptydir`](/docs/concepts/storage/volumes/#emptydir). {{< /note >}} +## Delegating volume permission and ownership change to CSI driver + +{{< feature-state for_k8s_version="v1.22" state="alpha" >}} + +If you deploy a [Container Storage Interface (CSI)](https://github.com/container-storage-interface/spec/blob/master/spec.md) +driver which supports the `VOLUME_MOUNT_GROUP` `NodeServiceCapability`, the +process of setting file ownership and permissions based on the +`fsGroup` specified in the `securityContext` will be performed by the CSI driver +instead of Kubernetes, provided that the `DelegateFSGroupToCSIDriver` Kubernetes +feature gate is enabled. In this case, since Kubernetes doesn't perform any +ownership and permission change, `fsGroupChangePolicy` does not take effect, and +as specified by CSI, the driver is expected to mount the volume with the +provided `fsGroup`, resulting in a volume that is readable/writable by the +`fsGroup`. + +Please refer to the [KEP](https://github.com/gnufied/enhancements/blob/master/keps/sig-storage/2317-fsgroup-on-mount/README.md) +and the description of the `VolumeCapability.MountVolume.volume_mount_group` +field in the [CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume) +for more information. ## Set the security context for a Container diff --git a/content/en/docs/tasks/configure-pod-container/static-pod.md b/content/en/docs/tasks/configure-pod-container/static-pod.md index 9126243462..c889570dc7 100644 --- a/content/en/docs/tasks/configure-pod-container/static-pod.md +++ b/content/en/docs/tasks/configure-pod-container/static-pod.md @@ -22,7 +22,7 @@ The kubelet automatically tries to create a {{< glossary_tooltip text="mirror Po on the Kubernetes API server for each static Pod. This means that the Pods running on a node are visible on the API server, but cannot be controlled from there. -The Pod names will suffixed with the node hostname with a leading hyphen +The Pod names will be suffixed with the node hostname with a leading hyphen. {{< note >}} If you are running clustered Kubernetes and are using static @@ -31,6 +31,13 @@ Pods to run a Pod on every node, you should probably be using a instead. {{< /note >}} +{{< note >}} +The `spec` of a static Pod cannot refer to other API objects +(e.g., {{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}, +{{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}, +{{< glossary_tooltip text="Secret" term_id="secret" >}}, etc). +{{< /note >}} + ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} diff --git a/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md b/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md index 384b709720..17fc9e1421 100644 --- a/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md +++ b/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md @@ -29,13 +29,13 @@ Kompose is released via GitHub on a three-week cycle, you can see all current re ```sh # Linux -curl -L https://github.com/kubernetes/kompose/releases/download/v1.22.0/kompose-linux-amd64 -o kompose +curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-linux-amd64 -o kompose # macOS -curl -L https://github.com/kubernetes/kompose/releases/download/v1.22.0/kompose-darwin-amd64 -o kompose +curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-darwin-amd64 -o kompose # Windows -curl -L https://github.com/kubernetes/kompose/releases/download/v1.22.0/kompose-windows-amd64.exe -o kompose.exe +curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-windows-amd64.exe -o kompose.exe chmod +x kompose sudo mv ./kompose /usr/local/bin/kompose diff --git a/content/en/docs/tasks/debug-application-cluster/_index.md b/content/en/docs/tasks/debug-application-cluster/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tasks/debug-application-cluster/audit.md b/content/en/docs/tasks/debug-application-cluster/audit.md index 2f8e1c9875..6c4b433ca2 100644 --- a/content/en/docs/tasks/debug-application-cluster/audit.md +++ b/content/en/docs/tasks/debug-application-cluster/audit.md @@ -94,7 +94,7 @@ rules: ``` If you're crafting your own audit profile, you can use the audit profile for Google Container-Optimized OS as a starting point. You can check the -[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh) +[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh) script, which generates an audit policy file. You can see most of the audit policy file by looking directly at the script. You can also refer to the [`Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) @@ -251,5 +251,7 @@ By default truncate is disabled in both `webhook` and `log`, a cluster administr ## {{% heading "whatsnext" %}} * Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations). -* Read the [reference for `audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/). +* Learn more about [`Event`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event) + and the [`Policy`](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy) + resource types by reading the Audit configuration reference. diff --git a/content/en/docs/tasks/debug-application-cluster/debug-application.md b/content/en/docs/tasks/debug-application-cluster/debug-application.md index f665accb18..477c9b8248 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-application.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-application.md @@ -140,24 +140,11 @@ kubectl get pods --selector=name=nginx,type=frontend ``` to list pods that match this selector. Verify that the list matches the Pods that you expect to provide your Service. - -If the list of pods matches expectations, but your endpoints are still empty, it's possible that you don't -have the right ports exposed. If your service has a `containerPort` specified, but the Pods that are -selected don't have that port listed, then they won't be added to the endpoints list. - Verify that the pod's `containerPort` matches up with the Service's `targetPort` #### Network traffic is not forwarded -If you can connect to the service, but the connection is immediately dropped, and there are endpoints -in the endpoints list, it's likely that the proxy can't contact your pods. - -There are three things to -check: - - * Are your pods working correctly? Look for restart count, and [debug pods](#debugging-pods). - * Can you connect to your pods directly? Get the IP address for the Pod, and try to connect directly to that IP. - * Is your application serving on the port that you configured? Kubernetes doesn't do port remapping, so if your application serves on 8080, the `containerPort` field needs to be 8080. +Please see [debugging service](/docs/tasks/debug-application-cluster/debug-service/) for more information. ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md index fdde133345..391efe4376 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-cluster.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-cluster.md @@ -102,7 +102,7 @@ This is an incomplete list of things that could go wrong, and how to adjust your - Action: Use IaaS providers reliable storage (e.g. GCE PD or AWS EBS volume) for VMs with apiserver+etcd - Mitigates: Apiserver backing storage lost -- Action: Use [high-availability](/docs/admin/high-availability) configuration +- Action: Use [high-availability](/docs/setup/production-environment/tools/kubeadm/high-availability/) configuration - Mitigates: Control plane node shutdown or control plane components (scheduler, API server, controller-manager) crashing - Will tolerate one or more simultaneous node or component failures - Mitigates: API server backing storage (i.e., etcd's data directory) lost diff --git a/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md index 59a83e87c7..6009a76341 100644 --- a/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md +++ b/content/en/docs/tasks/debug-application-cluster/debug-running-pod.md @@ -73,22 +73,20 @@ For more details, see [Get a Shell to a Running Container]( ## Debugging with an ephemeral debug container {#ephemeral-container} -{{< feature-state state="alpha" for_k8s_version="v1.18" >}} +{{< feature-state state="alpha" for_k8s_version="v1.22" >}} {{< glossary_tooltip text="Ephemeral containers" term_id="ephemeral-container" >}} are useful for interactive troubleshooting when `kubectl exec` is insufficient because a container has crashed or a container image doesn't include debugging utilities, such as with [distroless images]( -https://github.com/GoogleContainerTools/distroless). `kubectl` has an alpha -command that can create ephemeral containers for debugging beginning with version -`v1.18`. +https://github.com/GoogleContainerTools/distroless). ### Example debugging using ephemeral containers {#ephemeral-container-example} {{< note >}} The examples in this section require the `EphemeralContainers` [feature gate]( /docs/reference/command-line-tools-reference/feature-gates/) enabled in your -cluster and `kubectl` version v1.18 or later. +cluster and `kubectl` version v1.22 or later. {{< /note >}} You can use the `kubectl debug` command to add ephemeral containers to a @@ -137,7 +135,8 @@ creates. The `--target` parameter must be supported by the {{< glossary_tooltip text="Container Runtime" term_id="container-runtime" >}}. When not supported, the Ephemeral Container may not be started, or it may be started with an -isolated process namespace. +isolated process namespace so that `ps` does not reveal processes in other +containers. {{< /note >}} You can view the state of the newly created ephemeral container using `kubectl describe`: diff --git a/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md index 543573781b..f1ddd96389 100644 --- a/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md +++ b/content/en/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md @@ -41,7 +41,7 @@ the container starts. kubectl apply -f https://k8s.io/examples/debug/termination.yaml - In the YAML file, in the `cmd` and `args` fields, you can see that the + In the YAML file, in the `command` and `args` fields, you can see that the container sleeps for 10 seconds and then writes "Sleep expired" to the `/dev/termination-log` file. After the container writes the "Sleep expired" message, it terminates. diff --git a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md b/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md deleted file mode 100644 index 29ace662f6..0000000000 --- a/content/en/docs/tasks/debug-application-cluster/logging-stackdriver.md +++ /dev/null @@ -1,371 +0,0 @@ ---- -reviewers: -- piosz -- x13n -title: Logging Using Stackdriver -content_type: concept ---- - - - -Before reading this page, it's highly recommended to familiarize yourself -with the [overview of logging in Kubernetes](/docs/concepts/cluster-administration/logging). - -{{< note >}} -By default, Stackdriver logging collects only your container's standard output and -standard error streams. To collect any logs your application writes to a file (for example), -see the [sidecar approach](/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent) -in the Kubernetes logging overview. -{{< /note >}} - - - - - - -## Deploying - -To ingest logs, you must deploy the Stackdriver Logging agent to each node in your cluster. -The agent is a configured `fluentd` instance, where the configuration is stored in a `ConfigMap` -and the instances are managed using a Kubernetes `DaemonSet`. The actual deployment of the -`ConfigMap` and `DaemonSet` for your cluster depends on your individual cluster setup. - -### Deploying to a new cluster - -#### Google Kubernetes Engine - -Stackdriver is the default logging solution for clusters deployed on Google Kubernetes Engine. -Stackdriver Logging is deployed to a new cluster by default unless you explicitly opt-out. - -#### Other platforms - -To deploy Stackdriver Logging on a *new* cluster that you're -creating using `kube-up.sh`, do the following: - -1. Set the `KUBE_LOGGING_DESTINATION` environment variable to `gcp`. -1. **If not running on GCE**, include the `beta.kubernetes.io/fluentd-ds-ready=true` -in the `KUBE_NODE_LABELS` variable. - -Once your cluster has started, each node should be running the Stackdriver Logging agent. -The `DaemonSet` and `ConfigMap` are configured as addons. If you're not using `kube-up.sh`, -consider starting a cluster without a pre-configured logging solution and then deploying -Stackdriver Logging agents to the running cluster. - -{{< warning >}} -The Stackdriver logging daemon has known issues on platforms other -than Google Kubernetes Engine. Proceed at your own risk. -{{< /warning >}} - -### Deploying to an existing cluster - -1. Apply a label on each node, if not already present. - - The Stackdriver Logging agent deployment uses node labels to determine to which nodes - it should be allocated. These labels were introduced to distinguish nodes with the - Kubernetes version 1.6 or higher. If the cluster was created with Stackdriver Logging - configured and node has version 1.5.X or lower, it will have fluentd as static pod. Node - cannot have more than one instance of fluentd, therefore only apply labels to the nodes - that don't have fluentd pod allocated already. You can ensure that your node is labelled - properly by running `kubectl describe` as follows: - - ``` - kubectl describe node $NODE_NAME - ``` - - The output should be similar to this: - - ``` - Name: NODE_NAME - Role: - Labels: beta.kubernetes.io/fluentd-ds-ready=true - ... - ``` - - Ensure that the output contains the label `beta.kubernetes.io/fluentd-ds-ready=true`. If it - is not present, you can add it using the `kubectl label` command as follows: - - ``` - kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true - ``` - - {{< note >}} - If a node fails and has to be recreated, you must re-apply the label to - the recreated node. To make this easier, you can use Kubelet's command-line parameter - for applying node labels in your node startup script. - {{< /note >}} - -1. Deploy a `ConfigMap` with the logging agent configuration by running the following command: - - ``` - kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-configmap.yaml - ``` - - The command creates the `ConfigMap` in the `default` namespace. You can download the file - manually and change it before creating the `ConfigMap` object. - -1. Deploy the logging agent `DaemonSet` by running the following command: - - ``` - kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-ds.yaml - ``` - - You can download and edit this file before using it as well. - -## Verifying your Logging Agent Deployment - -After Stackdriver `DaemonSet` is deployed, you can discover logging agent deployment status -by running the following command: - -```shell -kubectl get ds --all-namespaces -``` - -If you have 3 nodes in the cluster, the output should looks similar to this: - -``` -NAMESPACE NAME DESIRED CURRENT READY NODE-SELECTOR AGE -... -default fluentd-gcp-v2.0 3 3 3 beta.kubernetes.io/fluentd-ds-ready=true 5m -... -``` - -To understand how logging with Stackdriver works, consider the following -synthetic log generator pod specification [counter-pod.yaml](/examples/debug/counter-pod.yaml): - -{{< codenew file="debug/counter-pod.yaml" >}} - -This pod specification has one container that runs a bash script -that writes out the value of a counter and the datetime once per -second, and runs indefinitely. Let's create this pod in the default namespace. - -```shell -kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml -``` - -You can observe the running pod: - -```shell -kubectl get pods -``` -``` -NAME READY STATUS RESTARTS AGE -counter 1/1 Running 0 5m -``` - -For a short period of time you can observe the 'Pending' pod status, because the kubelet -has to download the container image first. When the pod status changes to `Running` -you can use the `kubectl logs` command to view the output of this counter pod. - -```shell -kubectl logs counter -``` -``` -0: Mon Jan 1 00:00:00 UTC 2001 -1: Mon Jan 1 00:00:01 UTC 2001 -2: Mon Jan 1 00:00:02 UTC 2001 -... -``` - -As described in the logging overview, this command fetches log entries -from the container log file. If the container is killed and then restarted by -Kubernetes, you can still access logs from the previous container. However, -if the pod is evicted from the node, log files are lost. Let's demonstrate this -by deleting the currently running counter container: - -```shell -kubectl delete pod counter -``` -``` -pod "counter" deleted -``` - -and then recreating it: - -```shell -kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml -``` -``` -pod/counter created -``` - -After some time, you can access logs from the counter pod again: - -```shell -kubectl logs counter -``` -``` -0: Mon Jan 1 00:01:00 UTC 2001 -1: Mon Jan 1 00:01:01 UTC 2001 -2: Mon Jan 1 00:01:02 UTC 2001 -... -``` - -As expected, only recent log lines are present. However, for a real-world -application you will likely want to be able to access logs from all containers, -especially for the debug purposes. This is exactly when the previously enabled -Stackdriver Logging can help. - -## Viewing logs - -Stackdriver Logging agent attaches metadata to each log entry, for you to use later -in queries to select only the messages you're interested in: for example, -the messages from a particular pod. - -The most important pieces of metadata are the resource type and log name. -The resource type of a container log is `container`, which is named -`GKE Containers` in the UI (even if the Kubernetes cluster is not on Google Kubernetes Engine). -The log name is the name of the container, so that if you have a pod with -two containers, named `container_1` and `container_2` in the spec, their logs -will have log names `container_1` and `container_2` respectively. - -System components have resource type `compute`, which is named -`GCE VM Instance` in the interface. Log names for system components are fixed. -For a Google Kubernetes Engine node, every log entry from a system component has one of the following -log names: - -* docker -* kubelet -* kube-proxy - -You can learn more about viewing logs on [the dedicated Stackdriver page](https://cloud.google.com/logging/docs/view/logs_viewer). - -One of the possible ways to view logs is using the -[`gcloud logging`](https://cloud.google.com/logging/docs/api/gcloud-logging) -command line interface from the [Google Cloud SDK](https://cloud.google.com/sdk/). -It uses Stackdriver Logging [filtering syntax](https://cloud.google.com/logging/docs/view/advanced_filters) -to query specific logs. For example, you can run the following command: - -```none -gcloud beta logging read 'logName="projects/$YOUR_PROJECT_ID/logs/count"' --format json | jq '.[].textPayload' -``` -``` -... -"2: Mon Jan 1 00:01:02 UTC 2001\n" -"1: Mon Jan 1 00:01:01 UTC 2001\n" -"0: Mon Jan 1 00:01:00 UTC 2001\n" -... -"2: Mon Jan 1 00:00:02 UTC 2001\n" -"1: Mon Jan 1 00:00:01 UTC 2001\n" -"0: Mon Jan 1 00:00:00 UTC 2001\n" -``` - -As you can see, it outputs messages for the count container from both -the first and second runs, despite the fact that the kubelet already deleted -the logs for the first container. - -### Exporting logs - -You can export logs to [Google Cloud Storage](https://cloud.google.com/storage/) -or to [BigQuery](https://cloud.google.com/bigquery/) to run further -analysis. Stackdriver Logging offers the concept of sinks, where you can -specify the destination of log entries. More information is available on -the Stackdriver [Exporting Logs page](https://cloud.google.com/logging/docs/export/configure_export_v2). - -## Configuring Stackdriver Logging Agents - -Sometimes the default installation of Stackdriver Logging may not suit your needs, for example: - -* You may want to add more resources because default performance doesn't suit your needs. -* You may want to introduce additional parsing to extract more metadata from your log messages, -like severity or source code reference. -* You may want to send logs not only to Stackdriver or send it to Stackdriver only partially. - -In this case you need to be able to change the parameters of `DaemonSet` and `ConfigMap`. - -### Prerequisites - -If you're using GKE and Stackdriver Logging is enabled in your cluster, you -cannot change its configuration, because it's managed and supported by GKE. -However, you can disable the default integration and deploy your own. - -{{< note >}} -You will have to support and maintain a newly deployed configuration -yourself: update the image and configuration, adjust the resources and so on. -{{< /note >}} - -To disable the default logging integration, use the following command: - -``` -gcloud beta container clusters update --logging-service=none CLUSTER -``` - -You can find notes on how to then install Stackdriver Logging agents into -a running cluster in the [Deploying section](#deploying). - -### Changing `DaemonSet` parameters - -When you have the Stackdriver Logging `DaemonSet` in your cluster, you can modify the -`template` field in its spec. The DaemonSet controller manages the pods for you. -For example, assume you've installed the Stackdriver Logging as described above. Now you want to -change the memory limit to give fluentd more memory to safely process more logs. - -Get the spec of `DaemonSet` running in your cluster: - -```shell -kubectl get ds fluentd-gcp-v2.0 --namespace kube-system -o yaml > fluentd-gcp-ds.yaml -``` - -Then edit resource requirements in the spec file and update the `DaemonSet` object -in the apiserver using the following command: - -```shell -kubectl replace -f fluentd-gcp-ds.yaml -``` - -After some time, Stackdriver Logging agent pods will be restarted with the new configuration. - -### Changing fluentd parameters - -Fluentd configuration is stored in the `ConfigMap` object. It is effectively a set of configuration -files that are merged together. You can learn about fluentd configuration on the -[official site](https://docs.fluentd.org). - -Imagine you want to add a new parsing logic to the configuration, so that fluentd can understand -default Python logging format. An appropriate fluentd filter looks similar to this: - -``` - - type parser - format /^(?\w):(?\w):(?.*)/ - reserve_data true - suppress_parse_error_log true - key_name log - -``` - -Now you have to put it in the configuration and make Stackdriver Logging agents pick it up. -Get the current version of the Stackdriver Logging `ConfigMap` in your cluster -by running the following command: - -```shell -kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-configmap.yaml -``` - -Then in the value of the key `containers.input.conf` insert a new filter right after -the `source` section. - -{{< note >}} -Order is important. -{{< /note >}} - -Updating `ConfigMap` in the apiserver is more complicated than updating `DaemonSet`. It's better -to consider `ConfigMap` to be immutable. Then, in order to update the configuration, you should -create `ConfigMap` with a new name and then change `DaemonSet` to point to it -using [guide above](#changing-daemonset-parameters). - -### Adding fluentd plugins - -Fluentd is written in Ruby and allows to extend its capabilities using -[plugins](https://www.fluentd.org/plugins). If you want to use a plugin, which is not included -in the default Stackdriver Logging container image, you have to build a custom image. Imagine -you want to add Kafka sink for messages from a particular container for additional processing. -You can re-use the default [container image sources](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image) -with minor changes: - -* Change Makefile to point to your container repository, for example `PREFIX=gcr.io/`. -* Add your dependency to the Gemfile, for example `gem 'fluent-plugin-kafka'`. - -Then run `make build push` from this directory. After updating `DaemonSet` to pick up the -new image, you can use the plugin you installed in the fluentd configuration. - - diff --git a/content/en/docs/tasks/extend-kubernetes/configure-aggregation-layer.md b/content/en/docs/tasks/extend-kubernetes/configure-aggregation-layer.md index 739a69d45a..3b65d6abc6 100644 --- a/content/en/docs/tasks/extend-kubernetes/configure-aggregation-layer.md +++ b/content/en/docs/tasks/extend-kubernetes/configure-aggregation-layer.md @@ -17,7 +17,7 @@ Configuring the [aggregation layer](/docs/concepts/extend-kubernetes/api-extensi {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} {{< note >}} -There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the master CA. +There are a few setup requirements for getting the aggregation layer working in your environment to support mutual TLS auth between the proxy and extension apiservers. Kubernetes and the kube-apiserver have multiple CAs, so make sure that the proxy is signed by the aggregation layer CA and not by something else, like the Kubernetes general CA. {{< /note >}} {{< caution >}} diff --git a/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md index 7ad7072fd7..d44e6897b0 100644 --- a/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md +++ b/content/en/docs/tasks/extend-kubernetes/configure-multiple-schedulers.md @@ -18,7 +18,7 @@ learn how to run multiple schedulers in Kubernetes with an example. A detailed description of how to implement a scheduler is outside the scope of this document. Please refer to the kube-scheduler implementation in -[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/{{< param "githubbranch" >}}/pkg/scheduler) +[pkg/scheduler](https://github.com/kubernetes/kubernetes/tree/master/pkg/scheduler) in the Kubernetes source directory for a canonical example. ## {{% heading "prerequisites" %}} diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/_index.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index 671637c084..45f589e9d7 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -72,7 +72,7 @@ after upgrading the objects to a new stored version. Removing an old version: 1. Ensure all clients are fully migrated to the new version. The kube-apiserver - logs can reviewed to help identify any clients that are still accessing via + logs can be reviewed to help identify any clients that are still accessing via the old version. 1. Set `served` to `false` for the old version in the `spec.versions` list. If any clients are still unexpectedly using the old version they may begin reporting @@ -80,7 +80,7 @@ Removing an old version: If this occurs, switch back to using `served:true` on the old version, migrate the remaining clients to the new version and repeat this step. 1. Ensure the [upgrade of existing objects to the new stored version](#upgrade-existing-objects-to-a-new-stored-version) step has been completed. - 1. Verify that the `stored` is set to `true` for the new version in the `spec.versions` list in the CustomResourceDefinition. + 1. Verify that the `storage` is set to `true` for the new version in the `spec.versions` list in the CustomResourceDefinition. 1. Verify that the old version is no longer listed in the CustomResourceDefinition `status.storedVersions`. 1. Remove the old version from the CustomResourceDefinition `spec.versions` list. 1. Drop conversion support for the old version in conversion webhooks. @@ -202,7 +202,7 @@ spec: plural: crontabs # singular name to be used as an alias on the CLI and for display singular: crontab - # kind is normally the CamelCased singular type. Your resource manifests use this. + # kind is normally the PascalCased singular type. Your resource manifests use this. kind: CronTab # shortNames allow shorter string to match your resource on the CLI shortNames: diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md index 3230b7b73a..cd2d0fb103 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md @@ -154,22 +154,26 @@ from the YAML you used to create it: ```yaml apiVersion: v1 -kind: List items: - apiVersion: stable.example.com/v1 kind: CronTab metadata: - creationTimestamp: 2017-05-31T12:56:35Z + annotations: + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"stable.example.com/v1","kind":"CronTab","metadata":{"annotations":{},"name":"my-new-cron-object","namespace":"default"},"spec":{"cronSpec":"* * * * */5","image":"my-awesome-cron-image"}} + creationTimestamp: "2021-06-20T07:35:27Z" generation: 1 name: my-new-cron-object namespace: default - resourceVersion: "285" - uid: 9423255b-4600-11e7-af6a-28d2447dc82b + resourceVersion: "1326" + uid: 9aab1d66-628e-41bb-a422-57b8b3b1f5a9 spec: cronSpec: '* * * * */5' image: my-awesome-cron-image +kind: List metadata: resourceVersion: "" + selfLink: "" ``` ## Delete a CustomResourceDefinition diff --git a/content/en/docs/tasks/inject-data-application/_index.md b/content/en/docs/tasks/inject-data-application/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md index 693e730a09..e37e5b6569 100644 --- a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -1,6 +1,6 @@ --- title: Running Automated Tasks with a CronJob -min-kubernetes-server-version: v1.8 +min-kubernetes-server-version: v1.21 reviewers: - chenopis content_type: task @@ -9,6 +9,10 @@ weight: 10 +CronJobs was promoted to general availability in Kubernetes v1.21. If you are using an older version of +Kubernetes, please refer to the documentation for the version of Kubernetes that you are using, +so that you see accurate information. Older Kubernetes versions do not support the `batch/v1` CronJob API. + You can use a {{< glossary_tooltip text="CronJob" term_id="cronjob" >}} to run {{< glossary_tooltip text="Jobs" term_id="job" >}} on a time-based schedule. These automated jobs run like [Cron](https://en.wikipedia.org/wiki/Cron) tasks on a Linux or UNIX system. @@ -142,7 +146,7 @@ All modifications to a cron job, especially its `.spec`, are applied only to the The `.spec.schedule` is a required field of the `.spec`. It takes a [Cron](https://en.wikipedia.org/wiki/Cron) format string, such as `0 * * * *` or `@hourly`, as schedule time of its jobs to be created and executed. -The format also includes extended `vixie cron` step values. As explained in the +The format also includes extended "Vixie cron" step values. As explained in the [FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29): > Step values can be used in conjunction with ranges. Following a range @@ -170,13 +174,12 @@ After the deadline, the cron job does not start the job. Jobs that do not meet their deadline in this way count as failed jobs. If this field is not specified, the jobs have no deadline. -The CronJob controller counts how many missed schedules happen for a cron job. If there are more than 100 missed schedules, the cron job is no longer scheduled. When `.spec.startingDeadlineSeconds` is not set, the CronJob controller counts missed schedules from `status.lastScheduleTime` until now. +If the `.spec.startingDeadlineSeconds` field is set (not null), the CronJob +controller measures the time between when a job is expected to be created and +now. If the difference is higher than that limit, it will skip this execution. -For example, one cron job is supposed to run every minute, the `status.lastScheduleTime` of the cronjob is 5:00am, but now it's 7:00am. That means 120 schedules were missed, so the cron job is no longer scheduled. - -If the `.spec.startingDeadlineSeconds` field is set (not null), the CronJob controller counts how many missed jobs occurred from the value of `.spec.startingDeadlineSeconds` until now. - -For example, if it is set to `200`, it counts how many missed schedules occurred in the last 200 seconds. In that case, if there were more than 100 missed schedules in the last 200 seconds, the cron job is no longer scheduled. +For example, if it is set to `200`, it allows a job to be created for up to 200 +seconds after the actual schedule. ### Concurrency Policy diff --git a/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md b/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md index 62ddf56aab..2db5d3ecc3 100644 --- a/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md +++ b/content/en/docs/tasks/job/coarse-parallel-processing-work-queue.md @@ -2,7 +2,7 @@ title: Coarse Parallel Processing Using a Work Queue min-kubernetes-server-version: v1.8 content_type: task -weight: 30 +weight: 20 --- diff --git a/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md b/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md index 268eed7f9b..c5d1d0fa30 100644 --- a/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md +++ b/content/en/docs/tasks/job/fine-parallel-processing-work-queue.md @@ -2,7 +2,7 @@ title: Fine Parallel Processing Using a Work Queue content_type: task min-kubernetes-server-version: v1.8 -weight: 40 +weight: 30 --- diff --git a/content/en/docs/tasks/job/indexed-parallel-processing-static.md b/content/en/docs/tasks/job/indexed-parallel-processing-static.md new file mode 100644 index 0000000000..da5e6d4e08 --- /dev/null +++ b/content/en/docs/tasks/job/indexed-parallel-processing-static.md @@ -0,0 +1,185 @@ +--- +title: Indexed Job for Parallel Processing with Static Work Assignment +content_type: task +min-kubernetes-server-version: v1.21 +weight: 30 +--- + +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + + + + +In this example, you will run a Kubernetes Job that uses multiple parallel +worker processes. +Each worker is a different container running in its own Pod. The Pods have an +_index number_ that the control plane sets automatically, which allows each Pod +to identify which part of the overall task to work on. + +The pod index is available in the {{< glossary_tooltip text="annotation" term_id="annotation" >}} +`batch.kubernetes.io/job-completion-index` as a string representing its +decimal value. In order for the containerized task process to obtain this index, +you can publish the value of the annotation using the [downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api) +mechanism. +For convenience, the control plane automatically sets the downward API to +expose the index in the `JOB_COMPLETION_INDEX` environment variable. + +Here is an overview of the steps in this example: + +1. **Define a Job manifest using indexed completion**. + The downward API allows you to pass the pod index annotation as an + environment variable or file to the container. +2. **Start an `Indexed` Job based on that manifest**. + +## {{% heading "prerequisites" %}} + +You should already be familiar with the basic, +non-parallel, use of [Job](/docs/concepts/workloads/controllers/job/). + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +## Choose an approach + +To access the work item from the worker program, you have a few options: + +1. Read the `JOB_COMPLETION_INDEX` environment variable. The Job + {{< glossary_tooltip text="controller" term_id="controller" >}} + automatically links this variable to the annotation containing the completion + index. +1. Read a file that contains the completion index. +1. Assuming that you can't modify the program, you can wrap it with a script + that reads the index using any of the methods above and converts it into + something that the program can use as input. + +For this example, imagine that you chose option 3 and you want to run the +[rev](https://man7.org/linux/man-pages/man1/rev.1.html) utility. This +program accepts a file as an argument and prints its content reversed. + +```shell +rev data.txt +``` + +You'll use the `rev` tool from the +[`busybox`](https://hub.docker.com/_/busybox) container image. + +As this is only an example, each Pod only does a tiny piece of work (reversing a short +string). In a real workload you might, for example, create a Job that represents + the +task of producing 60 seconds of video based on scene data. +Each work item in the video rendering Job would be to render a particular +frame of that video clip. Indexed completion would mean that each Pod in +the Job knows which frame to render and publish, by counting frames from +the start of the clip. + +## Define an Indexed Job + +Here is a sample Job manifest that uses `Indexed` completion mode: + +{{< codenew language="yaml" file="application/job/indexed-job.yaml" >}} + +In the example above, you use the builtin `JOB_COMPLETION_INDEX` environment +variable set by the Job controller for all containers. An [init container](/docs/concepts/workloads/pods/init-containers/) +maps the index to a static value and writes it to a file that is shared with the +container running the worker through an [emptyDir volume](/docs/concepts/storage/volumes/#emptydir). +Optionally, you can [define your own environment variable through the downward +API](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/) +to publish the index to containers. You can also choose to load a list of values +from a [ConfigMap as an environment variable or file](/docs/tasks/configure-pod-container/configure-pod-configmap/). + +Alternatively, you can directly [use the downward API to pass the annotation +value as a volume file](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#store-pod-fields), +like shown in the following example: + +{{< codenew language="yaml" file="application/job/indexed-job-vol.yaml" >}} + +## Running the Job + +Now run the Job: + +```shell +# This uses the first approach (relying on $JOB_COMPLETION_INDEX) +kubectl apply -f https://kubernetes.io/examples/application/job/indexed-job.yaml +``` + +When you create this Job, the control plane creates a series of Pods, one for each index you specified. The value of `.spec.parallelism` determines how many can run at once whereas `.spec.completions` determines how many Pods the Job creates in total. + +Because `.spec.parallelism` is less than `.spec.completions`, the control plane waits for some of the first Pods to complete before starting more of them. + +Once you have created the Job, wait a moment then check on progress: + +```shell +kubectl describe jobs/indexed-job +``` + +The output is similar to: + +``` +Name: indexed-job +Namespace: default +Selector: controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756 +Labels: controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756 + job-name=indexed-job +Annotations: +Parallelism: 3 +Completions: 5 +Start Time: Thu, 11 Mar 2021 15:47:34 +0000 +Pods Statuses: 2 Running / 3 Succeeded / 0 Failed +Completed Indexes: 0-2 +Pod Template: + Labels: controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756 + job-name=indexed-job + Init Containers: + input: + Image: docker.io/library/bash + Port: + Host Port: + Command: + bash + -c + items=(foo bar baz qux xyz) + echo ${items[$JOB_COMPLETION_INDEX]} > /input/data.txt + + Environment: + Mounts: + /input from input (rw) + Containers: + worker: + Image: docker.io/library/busybox + Port: + Host Port: + Command: + rev + /input/data.txt + Environment: + Mounts: + /input from input (rw) + Volumes: + input: + Type: EmptyDir (a temporary directory that shares a pod's lifetime) + Medium: + SizeLimit: +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 4s job-controller Created pod: indexed-job-njkjj + Normal SuccessfulCreate 4s job-controller Created pod: indexed-job-9kd4h + Normal SuccessfulCreate 4s job-controller Created pod: indexed-job-qjwsz + Normal SuccessfulCreate 1s job-controller Created pod: indexed-job-fdhq5 + Normal SuccessfulCreate 1s job-controller Created pod: indexed-job-ncslj +``` + +In this example, you run the Job with custom values for each index. You can +inspect the output of one of the pods: + +```shell +kubectl logs indexed-job-fdhq5 # Change this to match the name of a Pod from that Job +``` + + +The output is similar to: + +``` +xuq +``` \ No newline at end of file diff --git a/content/en/docs/tasks/job/parallel-processing-expansion.md b/content/en/docs/tasks/job/parallel-processing-expansion.md index 8f5994929e..fdd309cafb 100644 --- a/content/en/docs/tasks/job/parallel-processing-expansion.md +++ b/content/en/docs/tasks/job/parallel-processing-expansion.md @@ -2,7 +2,7 @@ title: Parallel Processing using Expansions content_type: task min-kubernetes-server-version: v1.8 -weight: 20 +weight: 50 --- diff --git a/content/en/docs/tasks/manage-daemon/_index.md b/content/en/docs/tasks/manage-daemon/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tasks/manage-daemon/update-daemon-set.md b/content/en/docs/tasks/manage-daemon/update-daemon-set.md index 2f3001da0f..a74864fed5 100644 --- a/content/en/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/en/docs/tasks/manage-daemon/update-daemon-set.md @@ -7,12 +7,11 @@ weight: 10 --- - This page shows how to perform a rolling update on a DaemonSet. ## {{% heading "prerequisites" %}} -* The DaemonSet rolling update feature is only supported in Kubernetes version 1.6 or later. +{{< include "task-tutorial-prereqs.md" >}} @@ -20,22 +19,28 @@ This page shows how to perform a rolling update on a DaemonSet. DaemonSet has two update strategy types: -* OnDelete: With `OnDelete` update strategy, after you update a DaemonSet template, new +* `OnDelete`: With `OnDelete` update strategy, after you update a DaemonSet template, new DaemonSet pods will *only* be created when you manually delete old DaemonSet pods. This is the same behavior of DaemonSet in Kubernetes version 1.5 or before. -* RollingUpdate: This is the default update strategy. +* `RollingUpdate`: This is the default update strategy. With `RollingUpdate` update strategy, after you update a DaemonSet template, old DaemonSet pods will be killed, and new DaemonSet pods - will be created automatically, in a controlled fashion. At most one pod of the DaemonSet will be running on each node during the whole update process. + will be created automatically, in a controlled fashion. At most one pod of + the DaemonSet will be running on each node during the whole update process. ## Performing a Rolling Update To enable the rolling update feature of a DaemonSet, you must set its `.spec.updateStrategy.type` to `RollingUpdate`. -You may want to set [`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/concepts/workloads/controllers/deployment/#max-unavailable) (default -to 1) and [`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (default to 0) as well. +You may want to set +[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/concepts/workloads/controllers/deployment/#max-unavailable) +(default to 1), +[`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) +(default to 0) and +[`.spec.maxSurge`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#max-surge) +(a beta feature and defaults to 25%) as well. ### Creating a DaemonSet with `RollingUpdate` update strategy @@ -143,7 +148,7 @@ causes: The rollout is stuck because new DaemonSet pods can't be scheduled on at least one node. This is possible when the node is -[running out of resources](/docs/tasks/administer-cluster/out-of-resource/). +[running out of resources](/docs/concepts/scheduling-eviction/node-pressure-eviction/). When this happens, find the nodes that don't have the DaemonSet pods scheduled on by comparing the output of `kubectl get nodes` and the output of: @@ -184,14 +189,7 @@ Delete DaemonSet from a namespace : kubectl delete ds fluentd-elasticsearch -n kube-system ``` - - - ## {{% heading "whatsnext" %}} - -* See [Task: Performing a rollback on a - DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/) -* See [Concepts: Creating a DaemonSet to adopt existing DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/) - - +* See [Performing a rollback on a DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/) +* See [Creating a DaemonSet to adopt existing DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/) diff --git a/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md index 8d4cd4afe6..dd78446381 100644 --- a/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md +++ b/content/en/docs/tasks/manage-hugepages/scheduling-hugepages.md @@ -113,10 +113,4 @@ spec: - Huge page usage in a namespace is controllable via ResourceQuota similar to other compute resources like `cpu` or `memory` using the `hugepages-` token. -- Support of multiple sizes huge pages is feature gated. It can be - disabled with the `HugePageStorageMediumSize` - [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) - on the {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and - {{< glossary_tooltip text="kube-apiserver" term_id="kube-apiserver" >}} - (`--feature-gates=HugePageStorageMediumSize=false`). diff --git a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md index 3ea3c50e8d..9b16c25167 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -86,6 +86,43 @@ metadata: name: example-configmap-1-8mbdf7882g ``` +To generate a ConfigMap from an env file, add an entry to the `envs` list in `configMapGenerator`. Here is an example of generating a ConfigMap with a data item from a `.env` file: + +```shell +# Create a .env file +cat <.env +FOO=Bar +EOF + +cat <./kustomization.yaml +configMapGenerator: +- name: example-configmap-1 + envs: + - .env +EOF +``` + +The generated ConfigMap can be examined with the following command: + +```shell +kubectl kustomize ./ +``` + +The generated ConfigMap is: + +```yaml +apiVersion: v1 +data: + FOO=Bar +kind: ConfigMap +metadata: + name: example-configmap-1-8mbdf7882g +``` + +{{< note >}} +Each variable in the `.env` file becomes a separate key in the ConfigMap that you generate. This is different from the previous example which embeds a file named `.properties` (and all its entries) as the value for a single key. +{{< /note >}} + ConfigMaps can also be generated from literal key-value pairs. To generate a ConfigMap from a literal key-value pair, add an entry to the `literals` list in configMapGenerator. Here is an example of generating a ConfigMap with a data item from a key-value pair: ```shell @@ -114,6 +151,98 @@ metadata: name: example-configmap-2-g2hdhfc6tk ``` +To use a generated ConfigMap in a Deployment, reference it by the name of the configMapGenerator. Kustomize will automatically replace this name with the generated name. + +This is an example deployment that uses a generated ConfigMap: + +```yaml +# Create a application.properties file +cat <application.properties +FOO=Bar +EOF + +cat <deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-app + labels: + app: my-app +spec: + selector: + matchLabels: + app: my-app + template: + metadata: + labels: + app: my-app + spec: + containers: + - name: app + image: my-app + volumeMounts: + - name: config + mountPath: /config + volumes: + - name: config + configMap: + name: example-configmap-1 +EOF + +cat <./kustomization.yaml +resources: +- deployment.yaml +configMapGenerator: +- name: example-configmap-1 + files: + - application.properties +EOF +``` + +Generate the ConfigMap and Deployment: + +```shell +kubectl kustomize ./ +``` + +The generated Deployment will refer to the generated ConfigMap by name: + +```yaml +apiVersion: v1 +data: + application.properties: | + FOO=Bar +kind: ConfigMap +metadata: + name: example-configmap-1-g4hk9g2ff8 +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app: my-app + name: my-app +spec: + selector: + matchLabels: + app: my-app + template: + metadata: + labels: + app: my-app + spec: + containers: + - image: my-app + name: app + volumeMounts: + - mountPath: /config + name: config + volumes: + - configMap: + name: example-configmap-1-g4hk9g2ff8 + name: config +``` + #### secretGenerator You can generate Secrets from files or literal key-value pairs. To generate a Secret from a file, add an entry to the `files` list in `secretGenerator`. Here is an example of generating a Secret with a data item from a file: @@ -170,6 +299,53 @@ metadata: type: Opaque ``` +Like ConfigMaps, generated Secrets can be used in Deployments by refering to the name of the secretGenerator: + +```shell +# Create a password.txt file +cat <./password.txt +username=admin +password=secret +EOF + +cat <deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-app + labels: + app: my-app +spec: + selector: + matchLabels: + app: my-app + template: + metadata: + labels: + app: my-app + spec: + containers: + - name: app + image: my-app + volumeMounts: + - name: password + mountPath: /secrets + volumes: + - name: password + secret: + secretName: example-secret-1 +EOF + +cat <./kustomization.yaml +resources: +- deployment.yaml +secretGenerator: +- name: example-secret-1 + files: + - password.txt +EOF +``` + #### generatorOptions The generated ConfigMaps and Secrets have a content hash suffix appended. This ensures that a new ConfigMap or Secret is generated when the contents are changed. To disable the behavior of appending a suffix, one can use `generatorOptions`. Besides that, it is also possible to specify cross-cutting options for generated ConfigMaps and Secrets. @@ -815,14 +991,14 @@ deployment.apps "dev-my-nginx" deleted | commonLabels | map[string]string | labels to add to all resources and selectors | | commonAnnotations | map[string]string | annotations to add to all resources | | resources | []string | each entry in this list must resolve to an existing resource configuration file | -| configmapGenerator | [][ConfigMapArgs](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L99) | Each entry in this list generates a ConfigMap | -| secretGenerator | [][SecretArgs](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L106) | Each entry in this list generates a Secret | -| generatorOptions | [GeneratorOptions](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L109) | Modify behaviors of all ConfigMap and Secret generator | +| configMapGenerator | [][ConfigMapArgs](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/configmapargs.go#L7) | Each entry in this list generates a ConfigMap | +| secretGenerator | [][SecretArgs](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/secretargs.go#L7) | Each entry in this list generates a Secret | +| generatorOptions | [GeneratorOptions](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/generatoroptions.go#L7) | Modify behaviors of all ConfigMap and Secret generator | | bases | []string | Each entry in this list should resolve to a directory containing a kustomization.yaml file | | patchesStrategicMerge | []string | Each entry in this list should resolve a strategic merge patch of a Kubernetes object | -| patchesJson6902 | [][Json6902](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/patchjson6902.go#L8) | Each entry in this list should resolve to a Kubernetes object and a Json Patch | -| vars | [][Var](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/var.go#L31) | Each entry is to capture text from one resource's field | -| images | [][Image](https://github.com/kubernetes-sigs/kustomize/tree/master/api/types/image.go#L23) | Each entry is to modify the name, tags and/or digest for one image without creating patches | +| patchesJson6902 | [][Patch](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/patch.go#L10) | Each entry in this list should resolve to a Kubernetes object and a Json Patch | +| vars | [][Var](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/var.go#L19) | Each entry is to capture text from one resource's field | +| images | [][Image](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/image.go#L8) | Each entry is to modify the name, tags and/or digest for one image without creating patches | | configurations | []string | Each entry in this list should resolve to a file containing [Kustomize transformer configurations](https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs) | | crds | []string | Each entry in this list should resolve to an OpenAPI definition file for Kubernetes types | @@ -836,4 +1012,3 @@ deployment.apps "dev-my-nginx" deleted * [Kubectl Command Reference](/docs/reference/generated/kubectl/kubectl-commands/) * [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) - diff --git a/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md b/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md index b4d7b11a7e..759eaf76cd 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md @@ -310,10 +310,10 @@ Patch your Deployment: {{< tabs name="kubectl_retainkeys_example" >}} {{{< tab name="Bash" codelang="bash" >}} -kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-no-retainkeys.yaml)" +kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-no-retainkeys.yaml)" {{< /tab >}} {{< tab name="PowerShell" codelang="posh" >}} -kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw) +kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-no-retainkeys.yaml -Raw) {{< /tab >}}} {{< /tabs >}} @@ -341,10 +341,10 @@ Patch your Deployment again with this new patch: {{< tabs name="kubectl_retainkeys2_example" >}} {{{< tab name="Bash" codelang="bash" >}} -kubectl patch deployment retainkeys-demo --patch "$(cat patch-file-retainkeys.yaml)" +kubectl patch deployment retainkeys-demo --type merge --patch "$(cat patch-file-retainkeys.yaml)" {{< /tab >}} {{< tab name="PowerShell" codelang="posh" >}} -kubectl patch deployment retainkeys-demo --patch $(Get-Content patch-file-retainkeys.yaml -Raw) +kubectl patch deployment retainkeys-demo --type merge --patch $(Get-Content patch-file-retainkeys.yaml -Raw) {{< /tab >}}} {{< /tabs >}} diff --git a/content/en/docs/tasks/network/_index.md b/content/en/docs/tasks/network/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/en/docs/tasks/network/customize-hosts-file-for-pods.md similarity index 98% rename from content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md rename to content/en/docs/tasks/network/customize-hosts-file-for-pods.md index 8eee03bf9b..e396db5d2d 100644 --- a/content/en/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/en/docs/tasks/network/customize-hosts-file-for-pods.md @@ -3,7 +3,7 @@ reviewers: - rickypai - thockin title: Adding entries to Pod /etc/hosts with HostAliases -content_type: concept +content_type: task weight: 60 min-kubernetes-server-version: 1.7 --- @@ -16,7 +16,7 @@ Adding entries to a Pod's `/etc/hosts` file provides Pod-level override of hostn Modification not using HostAliases is not suggested because the file is managed by the kubelet and can be overwritten on during Pod creation/restart. - + ## Default hosts file content diff --git a/content/en/docs/tasks/network/validate-dual-stack.md b/content/en/docs/tasks/network/validate-dual-stack.md index 5e11cb3057..717bac27ad 100644 --- a/content/en/docs/tasks/network/validate-dual-stack.md +++ b/content/en/docs/tasks/network/validate-dual-stack.md @@ -16,7 +16,7 @@ This document shares how to validate IPv4/IPv6 dual-stack enabled Kubernetes clu * Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces) -* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Kubenet or Calico) +* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack (such as Calico, Cilium or Kubenet) * [Dual-stack enabled](/docs/concepts/services-networking/dual-stack/) cluster {{< version-check >}} @@ -40,9 +40,10 @@ a00:100::/24 ``` There should be one IPv4 block and one IPv6 block allocated. -Validate that the node has an IPv4 and IPv6 interface detected (replace node name with a valid node from the cluster. In this example the node name is k8s-linuxpool1-34450317-0): +Validate that the node has an IPv4 and IPv6 interface detected. Replace node name with a valid node from the cluster. In this example the node name is `k8s-linuxpool1-34450317-0`: + ```shell -kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .status.addresses}}{{printf "%s: %s \n" .type .address}}{{end}}' +kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .status.addresses}}{{printf "%s: %s\n" .type .address}}{{end}}' ``` ``` Hostname: k8s-linuxpool1-34450317-0 @@ -52,9 +53,10 @@ InternalIP: 2001:1234:5678:9abc::5 ### Validate Pod addressing -Validate that a Pod has an IPv4 and IPv6 address assigned. (replace the Pod name with a valid Pod in your cluster. In this example the Pod name is pod01) +Validate that a Pod has an IPv4 and IPv6 address assigned. Replace the Pod name with a valid Pod in your cluster. In this example the Pod name is `pod01`: + ```shell -kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{printf "%s \n" .ip}}{{end}}' +kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{printf "%s\n" .ip}}{{end}}' ``` ``` 10.244.1.4 @@ -72,6 +74,7 @@ You can also validate Pod IPs using the Downward API via the `status.podIPs` fie ``` The following command prints the value of the `MY_POD_IPS` environment variable from within a container. The value is a comma separated list that corresponds to the Pod's IPv4 and IPv6 addresses. + ```shell kubectl exec -it pod01 -- set | grep MY_POD_IPS ``` diff --git a/content/en/docs/tasks/run-application/_index.md b/content/en/docs/tasks/run-application/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tasks/run-application/configure-pdb.md b/content/en/docs/tasks/run-application/configure-pdb.md index 3823cac4ee..3110c2f807 100644 --- a/content/en/docs/tasks/run-application/configure-pdb.md +++ b/content/en/docs/tasks/run-application/configure-pdb.md @@ -2,11 +2,12 @@ title: Specifying a Disruption Budget for your Application content_type: task weight: 110 +min-kubernetes-server-version: v1.21 --- -{{< feature-state for_k8s_version="v1.5" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} This page shows how to limit the number of concurrent disruptions that your application experiences, allowing for higher availability @@ -17,6 +18,8 @@ nodes. ## {{% heading "prerequisites" %}} +{{< version-check >}} + * You are the owner of an application running on a Kubernetes cluster that requires high availability. * You should know how to deploy [Replicated Stateless Applications](/docs/tasks/run-application/run-stateless-application-deployment/) @@ -112,9 +115,9 @@ of the number of pods from that set that can be unavailable after the eviction. It can be either an absolute number or a percentage. {{< note >}} -For versions 1.8 and earlier: When creating a `PodDisruptionBudget` -object using the `kubectl` command line tool, the `minAvailable` field has a -default value of 1 if neither `minAvailable` nor `maxUnavailable` is specified. +The behavior for an empty selector differs between the policy/v1beta1 and policy/v1 APIs for +PodDisruptionBudgets. For policy/v1beta1 an empty selector matches zero pods, while +for policy/v1 an empty selector matches every pod in the namespace. {{< /note >}} You can specify only one of `maxUnavailable` and `minAvailable` in a single `PodDisruptionBudget`. @@ -160,7 +163,7 @@ Example PDB Using minAvailable: {{< codenew file="policy/zookeeper-pod-disruption-budget-minavailable.yaml" >}} -Example PDB Using maxUnavailable (Kubernetes 1.7 or higher): +Example PDB Using maxUnavailable: {{< codenew file="policy/zookeeper-pod-disruption-budget-maxunavailable.yaml" >}} @@ -206,7 +209,7 @@ You can get more information about the status of a PDB with this command: kubectl get poddisruptionbudgets zk-pdb -o yaml ``` ```yaml -apiVersion: policy/v1beta1 +apiVersion: policy/v1 kind: PodDisruptionBudget metadata: annotations: diff --git a/content/en/docs/tasks/run-application/delete-stateful-set.md b/content/en/docs/tasks/run-application/delete-stateful-set.md index 94b3c583eb..eff3aaee17 100644 --- a/content/en/docs/tasks/run-application/delete-stateful-set.md +++ b/content/en/docs/tasks/run-application/delete-stateful-set.md @@ -43,14 +43,14 @@ You may need to delete the associated headless service separately after the Stat kubectl delete service ``` -When deleting a StatefulSet through `kubectl`, the StatefulSet scales down to 0. All Pods that are part of this workload are also deleted. If you want to delete only the StatefulSet and not the Pods, use `--cascade=false`. +When deleting a StatefulSet through `kubectl`, the StatefulSet scales down to 0. All Pods that are part of this workload are also deleted. If you want to delete only the StatefulSet and not the Pods, use `--cascade=orphan`. For example: ```shell -kubectl delete -f --cascade=false +kubectl delete -f --cascade=orphan ``` -By passing `--cascade=false` to `kubectl delete`, the Pods managed by the StatefulSet are left behind even after the StatefulSet object itself is deleted. If the pods have a label `app=myapp`, you can then delete them as follows: +By passing `--cascade=orphan` to `kubectl delete`, the Pods managed by the StatefulSet are left behind even after the StatefulSet object itself is deleted. If the pods have a label `app=myapp`, you can then delete them as follows: ```shell kubectl delete pods -l app=myapp diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 84ae1addd2..6328d458fb 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -189,7 +189,7 @@ by making use of the `autoscaling/v2beta2` API version. First, get the YAML of your HorizontalPodAutoscaler in the `autoscaling/v2beta2` form: ```shell -kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml +kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml ``` Open the `/tmp/hpa-v2.yaml` file in an editor, and you should see YAML which looks like this: @@ -397,7 +397,9 @@ section to your HorizontalPodAutoscaler manifest to specify that you need one wo external: metric: name: queue_messages_ready - selector: "queue=worker_tasks" + selector: + matchLabels: + queue: "worker_tasks" target: type: AverageValue averageValue: 30 diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md index 5e94027423..27165d0ca7 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -68,14 +68,7 @@ or the custom metrics API (for all other metrics). The HorizontalPodAutoscaler normally fetches metrics from a series of aggregated APIs (`metrics.k8s.io`, `custom.metrics.k8s.io`, and `external.metrics.k8s.io`). The `metrics.k8s.io` API is usually provided by -metrics-server, which needs to be launched separately. See -[metrics-server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server) -for instructions. The HorizontalPodAutoscaler can also fetch metrics directly from Heapster. - -{{< note >}} -{{< feature-state state="deprecated" for_k8s_version="v1.11" >}} -Fetching metrics from Heapster is deprecated as of Kubernetes 1.11. -{{< /note >}} +metrics-server, which needs to be launched separately. For more information about resource metrics, see [Metrics Server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server). See [Support for metrics APIs](#support-for-metrics-apis) for more details. @@ -198,14 +191,17 @@ The detailed documentation of `kubectl autoscale` can be found [here](/docs/refe ## Autoscaling during rolling update -Currently in Kubernetes, it is possible to perform a rolling update by using the deployment object, which manages the underlying replica sets for you. -Horizontal Pod Autoscaler only supports the latter approach: the Horizontal Pod Autoscaler is bound to the deployment object, -it sets the size for the deployment object, and the deployment is responsible for setting sizes of underlying replica sets. +Kubernetes lets you perform a rolling update on a Deployment. In that +case, the Deployment manages the underlying ReplicaSets for you. +When you configure autoscaling for a Deployment, you bind a +HorizontalPodAutoscaler to a single Deployment. The HorizontalPodAutoscaler +manages the `replicas` field of the Deployment. The deployment controller is responsible +for setting the `replicas` of the underlying ReplicaSets so that they add up to a suitable +number during the rollout and also afterwards. -Horizontal Pod Autoscaler does not work with rolling update using direct manipulation of replication controllers, -i.e. you cannot bind a Horizontal Pod Autoscaler to a replication controller and do rolling update. -The reason this doesn't work is that when rolling update creates a new replication controller, -the Horizontal Pod Autoscaler will not be bound to the new replication controller. +If you perform a rolling update of a StatefulSet that has an autoscaled number of +replicas, the StatefulSet directly manages its set of Pods (there is no intermediate resource +similar to ReplicaSet). ## Support for cooldown/delay @@ -341,8 +337,6 @@ APIs, cluster administrators must ensure that: * For external metrics, this is the `external.metrics.k8s.io` API. It may be provided by the custom metrics adapters provided above. -* The `--horizontal-pod-autoscaler-use-rest-clients` is `true` or unset. Setting this to false switches to Heapster-based autoscaling, which is deprecated. - For more information on these different metrics paths and how they differ please see the relevant design proposals for [the HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md), [custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md) diff --git a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md index 22f929c06f..e98830b9e3 100644 --- a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md @@ -379,7 +379,7 @@ This might impact other applications on the Node, so it's best to **only do this in a test cluster**. ```shell -kubectl drain --force --delete-local-data --ignore-daemonsets +kubectl drain --force --delete-emptydir-data --ignore-daemonsets ``` Now you can watch as the Pod reschedules on a different Node: diff --git a/content/en/docs/tasks/service-catalog/_index.md b/content/en/docs/tasks/service-catalog/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tasks/tls/_index.md b/content/en/docs/tasks/tls/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tasks/tls/certificate-rotation.md b/content/en/docs/tasks/tls/certificate-rotation.md index 5dd9b85714..2db0c1255d 100644 --- a/content/en/docs/tasks/tls/certificate-rotation.md +++ b/content/en/docs/tasks/tls/certificate-rotation.md @@ -27,8 +27,8 @@ The kubelet uses certificates for authenticating to the Kubernetes API. By default, these certificates are issued with one year expiration so that they do not need to be renewed too frequently. -Kubernetes 1.8 contains [kubelet certificate -rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), a beta feature +Kubernetes contains [kubelet certificate +rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), that will automatically generate a new key and request a new certificate from the Kubernetes API as the current certificate approaches expiration. Once the new certificate is available, it will be used for authenticating connections to @@ -62,7 +62,7 @@ criteria, it will be auto approved by the controller manager, then it will have a status of `Approved`. Next, the controller manager will sign a certificate, issued for the duration specified by the `--cluster-signing-duration` parameter, and the signed certificate -will be attached to the certificate signing requests. +will be attached to the certificate signing request. The kubelet will retrieve the signed certificate from the Kubernetes API and write that to disk, in the location specified by `--cert-dir`. Then the kubelet diff --git a/content/en/docs/tasks/tools/_index.md b/content/en/docs/tasks/tools/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tasks/tools/included/install-kubectl-gcloud.md b/content/en/docs/tasks/tools/included/install-kubectl-gcloud.md deleted file mode 100644 index dcf8572618..0000000000 --- a/content/en/docs/tasks/tools/included/install-kubectl-gcloud.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "gcloud kubectl install" -description: "How to install kubectl with gcloud snippet for inclusion in each OS-specific tab." -headless: true ---- - -You can install kubectl as part of the Google Cloud SDK. - -1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/). - -1. Run the `kubectl` installation command: - - ```shell - gcloud components install kubectl - ``` - -1. Test to ensure the version you installed is up-to-date: - - ```shell - kubectl version --client - ``` \ No newline at end of file diff --git a/content/en/docs/tasks/tools/included/kubectl-convert-overview.md b/content/en/docs/tasks/tools/included/kubectl-convert-overview.md new file mode 100644 index 0000000000..b1799d52ea --- /dev/null +++ b/content/en/docs/tasks/tools/included/kubectl-convert-overview.md @@ -0,0 +1,11 @@ +--- +title: "kubectl-convert overview" +description: >- + A kubectl plugin that allows you to convert manifests from one version + of a Kubernetes API to a different version. +headless: true +--- + +A plugin for Kubernetes command-line tool `kubectl`, which allows you to convert manifests between different API +versions. This can be particularly helpful to migrate manifests to a non-deprecated api version with newer Kubernetes release. +For more info, visit [migrate to non deprecated apis](/docs/reference/using-api/deprecation-guide/#migrate-to-non-deprecated-apis) \ No newline at end of file diff --git a/content/en/docs/tasks/tools/install-kubectl-linux.md b/content/en/docs/tasks/tools/install-kubectl-linux.md index 243dbf4e0d..efb203f8b9 100644 --- a/content/en/docs/tasks/tools/install-kubectl-linux.md +++ b/content/en/docs/tasks/tools/install-kubectl-linux.md @@ -12,8 +12,7 @@ card: ## {{% heading "prerequisites" %}} -You must use a kubectl version that is within one minor version difference of your cluster. -For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. +You must use a kubectl version that is within one minor version difference of your cluster. For example, a v{{< skew latestVersion >}} client can communicate with v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, and v{{< skew nextMinorVersion >}} control planes. Using the latest version of kubectl helps avoid unforeseen issues. ## Install kubectl on Linux @@ -23,7 +22,6 @@ The following methods exist for installing kubectl on Linux: - [Install kubectl binary with curl on Linux](#install-kubectl-binary-with-curl-on-linux) - [Install using native package management](#install-using-native-package-management) - [Install using other package management](#install-using-other-package-management) -- [Install on Linux as part of the Google Cloud SDK](#install-on-linux-as-part-of-the-google-cloud-sdk) ### Install kubectl binary with curl on Linux @@ -84,6 +82,7 @@ For example, to download version {{< param "fullversion" >}} on Linux, type: If you do not have root access on the target system, you can still install kubectl to the `~/.local/bin` directory: ```bash + chmod +x kubectl mkdir -p ~/.local/bin/kubectl mv ./kubectl ~/.local/bin/kubectl # and then add ~/.local/bin/kubectl to $PATH @@ -169,15 +168,11 @@ kubectl version --client {{< /tabs >}} -### Install on Linux as part of the Google Cloud SDK - -{{< include "included/install-kubectl-gcloud.md" >}} - ## Verify kubectl configuration {{< include "included/verify-kubectl.md" >}} -## Optional kubectl configurations +## Optional kubectl configurations and plugins ### Enable shell autocompletion @@ -190,6 +185,61 @@ Below are the procedures to set up autocompletion for Bash and Zsh. {{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}} {{< /tabs >}} +### Install `kubectl convert` plugin + +{{< include "included/kubectl-convert-overview.md" >}} + +1. Download the latest release with the command: + + ```bash + curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert + ``` + +1. Validate the binary (optional) + + Download the kubectl-convert checksum file: + + ```bash + curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256" + ``` + + Validate the kubectl-convert binary against the checksum file: + + ```bash + echo "$(}} + Download the same version of the binary and checksum. + {{< /note >}} + +1. Install kubectl-convert + + ```bash + sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert + ``` + +1. Verify plugin is successfully installed + + ```shell + kubectl convert --help + ``` + + If you do not see an error, it means the plugin is successfully installed. + ## {{% heading "whatsnext" %}} {{< include "included/kubectl-whats-next.md" >}} diff --git a/content/en/docs/tasks/tools/install-kubectl-macos.md b/content/en/docs/tasks/tools/install-kubectl-macos.md index b4fa864985..b46ab03640 100644 --- a/content/en/docs/tasks/tools/install-kubectl-macos.md +++ b/content/en/docs/tasks/tools/install-kubectl-macos.md @@ -12,8 +12,7 @@ card: ## {{% heading "prerequisites" %}} -You must use a kubectl version that is within one minor version difference of your cluster. -For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. +You must use a kubectl version that is within one minor version difference of your cluster. For example, a v{{< skew latestVersion >}} client can communicate with v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, and v{{< skew nextMinorVersion >}} control planes. Using the latest version of kubectl helps avoid unforeseen issues. ## Install kubectl on macOS @@ -23,23 +22,33 @@ The following methods exist for installing kubectl on macOS: - [Install kubectl binary with curl on macOS](#install-kubectl-binary-with-curl-on-macos) - [Install with Homebrew on macOS](#install-with-homebrew-on-macos) - [Install with Macports on macOS](#install-with-macports-on-macos) -- [Install on macOS as part of the Google Cloud SDK](#install-on-macos-as-part-of-the-google-cloud-sdk) ### Install kubectl binary with curl on macOS 1. Download the latest release: - ```bash + {{< tabs name="download_binary_macos" >}} + {{< tab name="Intel" codelang="bash" >}} curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl" - ``` + {{< /tab >}} + {{< tab name="Apple Silicon" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl" + {{< /tab >}} + {{< /tabs >}} {{< note >}} To download a specific version, replace the `$(curl -L -s https://dl.k8s.io/release/stable.txt)` portion of the command with the specific version. - For example, to download version {{< param "fullversion" >}} on macOS, type: + For example, to download version {{< param "fullversion" >}} on Intel macOS, type: ```bash - curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl + curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl" + ``` + + And for macOS on Apple Silicon, type: + + ```bash + curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/arm64/kubectl" ``` {{< /note >}} @@ -48,10 +57,15 @@ The following methods exist for installing kubectl on macOS: Download the kubectl checksum file: - ```bash - curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256" - ``` - + {{< tabs name="download_checksum_macos" >}} + {{< tab name="Intel" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256" + {{< /tab >}} + {{< tab name="Apple Silicon" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl.sha256" + {{< /tab >}} + {{< /tabs >}} + Validate the kubectl binary against the checksum file: ```bash @@ -88,6 +102,10 @@ The following methods exist for installing kubectl on macOS: sudo chown root: /usr/local/bin/kubectl ``` + {{< note >}} + Make sure `/usr/local/bin` is in your PATH environment variable. + {{< /note >}} + 1. Test to ensure the version you installed is up-to-date: ```bash @@ -133,16 +151,11 @@ If you are on macOS and using [Macports](https://macports.org/) package manager, kubectl version --client ``` - -### Install on macOS as part of the Google Cloud SDK - -{{< include "included/install-kubectl-gcloud.md" >}} - ## Verify kubectl configuration {{< include "included/verify-kubectl.md" >}} -## Optional kubectl configurations +## Optional kubectl configurations and plugins ### Enable shell autocompletion @@ -155,6 +168,82 @@ Below are the procedures to set up autocompletion for Bash and Zsh. {{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}} {{< /tabs >}} +### Install `kubectl convert` plugin + +{{< include "included/kubectl-convert-overview.md" >}} + +1. Download the latest release with the command: + + {{< tabs name="download_convert_binary_macos" >}} + {{< tab name="Intel" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert" + {{< /tab >}} + {{< tab name="Apple Silicon" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert" + {{< /tab >}} + {{< /tabs >}} + +1. Validate the binary (optional) + + Download the kubectl-convert checksum file: + + {{< tabs name="download_convert_checksum_macos" >}} + {{< tab name="Intel" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert.sha256" + {{< /tab >}} + {{< tab name="Apple Silicon" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert.sha256" + {{< /tab >}} + {{< /tabs >}} + + Validate the kubectl-convert binary against the checksum file: + + ```bash + echo "$(}} + Download the same version of the binary and checksum. + {{< /note >}} + +1. Make kubectl-convert binary executable + + ```bash + chmod +x ./kubectl-convert + ``` + +1. Move the kubectl-convert binary to a file location on your system `PATH`. + + ```bash + sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert + sudo chown root: /usr/local/bin/kubectl-convert + ``` + + {{< note >}} + Make sure `/usr/local/bin` is in your PATH environment variable. + {{< /note >}} + +1. Verify plugin is successfully installed + + ```shell + kubectl convert --help + ``` + + If you do not see an error, it means the plugin is successfully installed. + ## {{% heading "whatsnext" %}} {{< include "included/kubectl-whats-next.md" >}} diff --git a/content/en/docs/tasks/tools/install-kubectl-windows.md b/content/en/docs/tasks/tools/install-kubectl-windows.md index 09e8217626..8059fa7a3a 100644 --- a/content/en/docs/tasks/tools/install-kubectl-windows.md +++ b/content/en/docs/tasks/tools/install-kubectl-windows.md @@ -12,8 +12,7 @@ card: ## {{% heading "prerequisites" %}} -You must use a kubectl version that is within one minor version difference of your cluster. -For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. +You must use a kubectl version that is within one minor version difference of your cluster. For example, a v{{< skew latestVersion >}} client can communicate with v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, and v{{< skew nextMinorVersion >}} control planes. Using the latest version of kubectl helps avoid unforeseen issues. ## Install kubectl on Windows @@ -21,9 +20,7 @@ Using the latest version of kubectl helps avoid unforeseen issues. The following methods exist for installing kubectl on Windows: - [Install kubectl binary with curl on Windows](#install-kubectl-binary-with-curl-on-windows) -- [Install with PowerShell from PSGallery](#install-with-powershell-from-psgallery) - [Install on Windows using Chocolatey or Scoop](#install-on-windows-using-chocolatey-or-scoop) -- [Install on Windows as part of the Google Cloud SDK](#install-on-windows-as-part-of-the-google-cloud-sdk) ### Install kubectl binary with curl on Windows @@ -33,7 +30,7 @@ The following methods exist for installing kubectl on Windows: Or if you have `curl` installed, use this command: ```powershell - curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe + curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe" ``` {{< note >}} @@ -45,7 +42,7 @@ The following methods exist for installing kubectl on Windows: Download the kubectl checksum file: ```powershell - curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256 + curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256" ``` Validate the kubectl binary against the checksum file: @@ -76,33 +73,6 @@ The following methods exist for installing kubectl on Windows: If you have installed Docker Desktop before, you may need to place your `PATH` entry before the one added by the Docker Desktop installer or remove the Docker Desktop's `kubectl`. {{< /note >}} -### Install with PowerShell from PSGallery - -If you are on Windows and using the [PowerShell Gallery](https://www.powershellgallery.com/) package manager, you can install and update kubectl with PowerShell. - -1. Run the installation commands (making sure to specify a `DownloadLocation`): - - ```powershell - Install-Script -Name 'install-kubectl' -Scope CurrentUser -Force - install-kubectl.ps1 [-DownloadLocation ] - ``` - - {{< note >}} - If you do not specify a `DownloadLocation`, `kubectl` will be installed in the user's `temp` Directory. - {{< /note >}} - - The installer creates `$HOME/.kube` and instructs it to create a config file. - -1. Test to ensure the version you installed is up-to-date: - - ```powershell - kubectl version --client - ``` - -{{< note >}} -Updating the installation is performed by rerunning the two commands listed in step 1. -{{< /note >}} - ### Install on Windows using Chocolatey or Scoop 1. To install kubectl on Windows you can use either [Chocolatey](https://chocolatey.org) package manager or [Scoop](https://scoop.sh) command-line installer. @@ -156,15 +126,11 @@ Updating the installation is performed by rerunning the two commands listed in s Edit the config file with a text editor of your choice, such as Notepad. {{< /note >}} -### Install on Windows as part of the Google Cloud SDK - -{{< include "included/install-kubectl-gcloud.md" >}} - ## Verify kubectl configuration {{< include "included/verify-kubectl.md" >}} -## Optional kubectl configurations +## Optional kubectl configurations and plugins ### Enable shell autocompletion @@ -174,6 +140,49 @@ Below are the procedures to set up autocompletion for Zsh, if you are running th {{< include "included/optional-kubectl-configs-zsh.md" >}} +### Install `kubectl convert` plugin + +{{< include "included/kubectl-convert-overview.md" >}} + +1. Download the latest release with the command: + + ```powershell + curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe" + ``` + +1. Validate the binary (optional) + + Download the kubectl-convert checksum file: + + ```powershell + curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe.sha256" + ``` + + Validate the kubectl-convert binary against the checksum file: + + - Using Command Prompt to manually compare `CertUtil`'s output to the checksum file downloaded: + + ```cmd + CertUtil -hashfile kubectl-convert.exe SHA256 + type kubectl-convert.exe.sha256 + ``` + + - Using PowerShell to automate the verification using the `-eq` operator to get a `True` or `False` result: + + ```powershell + $($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256) + ``` + +1. Add the binary in to your `PATH`. + +1. Verify plugin is successfully installed + + ```shell + kubectl convert --help + ``` + + If you do not see an error, it means the plugin is successfully installed. + ## {{% heading "whatsnext" %}} -{{< include "included/kubectl-whats-next.md" >}} \ No newline at end of file +{{< include "included/kubectl-whats-next.md" >}} diff --git a/content/en/docs/test.md b/content/en/docs/test.md index ae5bb447f1..b9998635e2 100644 --- a/content/en/docs/test.md +++ b/content/en/docs/test.md @@ -287,7 +287,7 @@ tables, use HTML instead. ## Visualizations with Mermaid You can use [Mermaid JS](https://mermaidjs.github.io) visualizations. -The Mermaid JS version is specified in [/layouts/partials/head.html](https://github.com/kubernetes/website/blob/master/layouts/partials/head.html) +The Mermaid JS version is specified in [/layouts/partials/head.html](https://github.com/kubernetes/website/blob/main/layouts/partials/head.html) ``` {{}} diff --git a/content/en/docs/tutorials/_index.md b/content/en/docs/tutorials/_index.md index acd2a4363f..fdc62e11fb 100644 --- a/content/en/docs/tutorials/_index.md +++ b/content/en/docs/tutorials/_index.md @@ -35,7 +35,7 @@ Before walking through each tutorial, you may want to bookmark the * [Exposing an External IP Address to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/) -* [Example: Deploying PHP Guestbook application with MongoDB](/docs/tutorials/stateless-application/guestbook/) +* [Example: Deploying PHP Guestbook application with Redis](/docs/tutorials/stateless-application/guestbook/) ## Stateful Applications @@ -51,6 +51,8 @@ Before walking through each tutorial, you may want to bookmark the * [AppArmor](/docs/tutorials/clusters/apparmor/) +* [seccomp](/docs/tutorials/clusters/seccomp/) + ## Services * [Using Source IP](/docs/tutorials/services/source-ip/) diff --git a/content/en/docs/tutorials/clusters/_index.md b/content/en/docs/tutorials/clusters/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tutorials/clusters/apparmor.md b/content/en/docs/tutorials/clusters/apparmor.md index 32f25ba483..8907768089 100644 --- a/content/en/docs/tutorials/clusters/apparmor.md +++ b/content/en/docs/tutorials/clusters/apparmor.md @@ -348,6 +348,11 @@ node with the required profile. ### Restricting profiles with the PodSecurityPolicy +{{< note >}} +PodSecurityPolicy is deprecated in Kubernetes v1.21, and will be removed in v1.25. +See [PodSecurityPolicy documentation](/docs/concepts/policy/pod-security-policy/) for more information. +{{< /note >}} + If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To enable the PodSecurityPolicy, the following flag must be set on the `apiserver`: diff --git a/content/en/docs/tutorials/clusters/seccomp.md b/content/en/docs/tutorials/clusters/seccomp.md index 971618cf55..029ea97a7d 100644 --- a/content/en/docs/tutorials/clusters/seccomp.md +++ b/content/en/docs/tutorials/clusters/seccomp.md @@ -3,9 +3,10 @@ reviewers: - hasheddan - pjbgf - saschagrunert -title: Restrict a Container's Syscalls with Seccomp +title: Restrict a Container's Syscalls with seccomp content_type: tutorial weight: 20 +min-kubernetes-server-version: v1.22 --- @@ -13,7 +14,7 @@ weight: 20 {{< feature-state for_k8s_version="v1.19" state="stable" >}} Seccomp stands for secure computing mode and has been a feature of the Linux -kernel since version 2.6.12. It can be used to sandbox the privileges of a +kernel since version 2.6.12. It can be used to sandbox the privileges of a process, restricting the calls it is able to make from userspace into the kernel. Kubernetes lets you automatically apply seccomp profiles loaded onto a Node to your Pods and containers. @@ -35,16 +36,72 @@ profiles that give only the necessary privileges to your container processes. ## {{% heading "prerequisites" %}} +{{< version-check >}} + In order to complete all steps in this tutorial, you must install [kind](https://kind.sigs.k8s.io/docs/user/quick-start/) and [kubectl](/docs/tasks/tools/). This tutorial will show examples -with both alpha (pre-v1.19) and generally available seccomp functionality, so +both alpha (new in v1.22) and generally available seccomp functionality. You should make sure that your cluster is [configured correctly](https://kind.sigs.k8s.io/docs/user/quick-start/#setting-kubernetes-version) for the version you are using. +{{< note >}} +It is not possible to apply a seccomp profile to a container running with +`privileged: true` set in the container's `securityContext`. Privileged containers always +run as `Unconfined`. +{{< /note >}} + +## Enable the use of `RuntimeDefault` as the default seccomp profile for all workloads + +{{< feature-state state="alpha" for_k8s_version="v1.22" >}} + +`SeccompDefault` is an optional kubelet +[feature gate](/docs/reference/command-line-tools-reference/feature-gates) as +well as corresponding `--seccomp-default` +[command line flag](/docs/reference/command-line-tools-reference/kubelet). +Both have to be enabled simultaneously to use the feature. + +If enabled, the kubelet will use the `RuntimeDefault` seccomp profile by default, which is +defined by the container runtime, instead of using the `Unconfined` (seccomp disabled) mode. +The default profiles aim to provide a strong set +of security defaults while preserving the functionality of the workload. It is +possible that the default profiles differ between container runtimes and their +release versions, for example when comparing those from CRI-O and containerd. + +Some workloads may require a lower amount of syscall restrictions than others. +This means that they can fail during runtime even with the `RuntimeDefault` +profile. To mitigate such a failure, you can: + +- Run the workload explicitly as `Unconfined`. +- Disable the `SeccompDefault` feature for the nodes. Also making sure that + workloads get scheduled on nodes where the feature is disabled. +- Create a custom seccomp profile for the workload. + +If you were introducing this feature into production-like cluster, the Kubernetes project +recommends that you enable this feature gate on a subset of your nodes and then +test workload execution before rolling the change out cluster-wide. + +More detailed information about a possible upgrade and downgrade strategy can be +found in the [related Kubernetes Enhancement Proposal (KEP)](https://github.com/kubernetes/enhancements/tree/a70cc18/keps/sig-node/2413-seccomp-by-default#upgrade--downgrade-strategy). + +Since the feature is in alpha state it is disabled per default. To enable it, +pass the flags `--feature-gates=SeccompDefault=true --seccomp-default` to the +`kubelet` CLI or enable it via the [kubelet configuration +file](/docs/tasks/administer-cluster/kubelet-config-file/). To enable the +feature gate in [kind](https://kind.sigs.k8s.io), ensure that `kind` provides +the minimum required Kubernetes version and enables the `SeccompDefault` feature +[in the kind configuration](https://kind.sigs.k8s.io/docs/user/quick-start/#enable-feature-gates-in-your-cluster): + +```yaml +kind: Cluster +apiVersion: kind.x-k8s.io/v1alpha4 +featureGates: + SeccompDefault: true +``` + ## Create Seccomp Profiles The contents of these profiles will be explored later on, but for now go ahead @@ -108,7 +165,7 @@ docker exec -it 6a96207fed4b ls /var/lib/kubelet/seccomp/profiles audit.json fine-grained.json violation.json ``` -## Create a Pod with a Seccomp profile for syscall auditing +## Create a Pod with a seccomp profile for syscall auditing To start off, apply the `audit.json` profile, which will log all syscalls of the process, to a new Pod. @@ -208,7 +265,7 @@ kubectl delete pod/audit-pod kubectl delete svc/audit-pod ``` -## Create Pod with Seccomp Profile that Causes Violation +## Create Pod with seccomp Profile that Causes Violation For demonstration, apply a profile to the Pod that does not allow for any syscalls. @@ -255,7 +312,7 @@ kubectl delete pod/violation-pod kubectl delete svc/violation-pod ``` -## Create Pod with Seccomp Profile that Only Allows Necessary Syscalls +## Create Pod with seccomp Profile that Only Allows Necessary Syscalls If you take a look at the `fine-pod.json`, you will notice some of the syscalls seen in the first example where the profile set `"defaultAction": @@ -339,7 +396,7 @@ kubectl delete pod/fine-pod kubectl delete svc/fine-pod ``` -## Create Pod that uses the Container Runtime Default Seccomp Profile +## Create Pod that uses the Container Runtime Default seccomp Profile Most container runtimes provide a sane set of default syscalls that are allowed or not. The defaults can easily be applied in Kubernetes by using the @@ -364,5 +421,5 @@ The default seccomp profile should provide adequate access for most workloads. Additional resources: -* [A Seccomp Overview](https://lwn.net/Articles/656307/) +* [A seccomp Overview](https://lwn.net/Articles/656307/) * [Seccomp Security Profiles for Docker](https://docs.docker.com/engine/security/seccomp/) diff --git a/content/en/docs/tutorials/configuration/_index.md b/content/en/docs/tutorials/configuration/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tutorials/configuration/configure-java-microservice/_index.md b/content/en/docs/tutorials/configuration/configure-java-microservice/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md index b29b352aca..ec6edb9cc7 100644 --- a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -55,7 +55,7 @@ Apply the ConfigMap created above, along with a Redis pod manifest: ```shell kubectl apply -f example-redis-config.yaml -kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml ``` Examine the contents of the Redis pod manifest and note the following: @@ -206,7 +206,7 @@ values from associated ConfigMaps. Let's delete and recreate the Pod: ```shell kubectl delete pod redis -kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml ``` Now re-check the configuration values one last time: diff --git a/content/en/docs/tutorials/hello-minikube.md b/content/en/docs/tutorials/hello-minikube.md index d8ad753958..e6398d7c72 100644 --- a/content/en/docs/tutorials/hello-minikube.md +++ b/content/en/docs/tutorials/hello-minikube.md @@ -60,16 +60,22 @@ If you installed minikube locally, run `minikube start`. Before you run `minikub 4. Katacoda environment only: Type `30000`, and then click **Display Port**. {{< note >}} -The `dashboard` command enables the dashboard add-on and opens the proxy in the default web browser. You can create Kubernetes resources on the dashboard such as Deployment and Service. +The `dashboard` command enables the dashboard add-on and opens the proxy in the default web browser. +You can create Kubernetes resources on the dashboard such as Deployment and Service. If you are running in an environment as root, see [Open Dashboard with URL](#open-dashboard-with-url). -To stop the proxy, run `Ctrl+C` to exit the process. The dashboard remains running. +By default, the dashboard is only accessible from within the internal Kubernetes virtual network. +The `dashboard` command creates a temporary proxy to make the dashboard accessible from outside the Kubernetes virtual network. + +To stop the proxy, run `Ctrl+C` to exit the process. +After the command exits, the dashboard remains running in the Kubernetes cluster. +You can run the `dashboard` command again to create another proxy to access the dashboard. {{< /note >}} ## Open Dashboard with URL -If you don't want to open a web browser, run the dashboard command with the url flag to emit a URL: +If you don't want to open a web browser, run the dashboard command with the `--url` flag to emit a URL: ```shell minikube dashboard --url @@ -179,7 +185,7 @@ Kubernetes [*Service*](/docs/concepts/services-networking/service/). 4. Katacoda environment only: Click the plus sign, and then click **Select port to view on Host 1**. -5. Katacoda environment only: Note the 5 digit port number displayed opposite to `8080` in services output. This port number is randomly generated and it can be different for you. Type your number in the port number text box, then click Display Port. Using the example from earlier, you would type `30369`. +5. Katacoda environment only: Note the 5-digit port number displayed opposite to `8080` in services output. This port number is randomly generated and it can be different for you. Type your number in the port number text box, then click Display Port. Using the example from earlier, you would type `30369`. This opens up a browser window that serves your app and shows the app's response. @@ -224,7 +230,7 @@ The minikube tool includes a set of built-in {{< glossary_tooltip text="addons" The output is similar to: ``` - metrics-server was successfully enabled + The 'metrics-server' addon is enabled ``` 3. View the Pod and Service you created: diff --git a/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index ad7b856223..5301c6b7a1 100644 --- a/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -25,7 +25,8 @@ weight: 20
- Continue to Module 2› + Home + Continue to Module 2 >
diff --git a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index ab008c38af..915304f912 100644 --- a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -37,7 +37,9 @@ weight: 20
- Continue to Module 3› + < Return to Module 1 + Home + Continue to Module 3 >
diff --git a/content/en/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/en/docs/tutorials/kubernetes-basics/explore/explore-interactive.html index 8c87cfab18..ad79ec5d7f 100644 --- a/content/en/docs/tutorials/kubernetes-basics/explore/explore-interactive.html +++ b/content/en/docs/tutorials/kubernetes-basics/explore/explore-interactive.html @@ -29,7 +29,9 @@ weight: 20
- Continue to Module 4› + < Return to Module 2 + Home + Continue to Module 4 >
diff --git a/content/en/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/en/docs/tutorials/kubernetes-basics/explore/explore-intro.html index 3b5a51dc40..6f8cd442b8 100644 --- a/content/en/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -74,11 +74,11 @@ weight: 10

Nodes

-

A Pod always runs on a Node. A Node is a worker machine in Kubernetes and may be either a virtual or a physical machine, depending on the cluster. Each Node is managed by the Master. A Node can have multiple pods, and the Kubernetes master automatically handles scheduling the pods across the Nodes in the cluster. The Master's automatic scheduling takes into account the available resources on each Node.

+

A Pod always runs on a Node. A Node is a worker machine in Kubernetes and may be either a virtual or a physical machine, depending on the cluster. Each Node is managed by the control plane. A Node can have multiple pods, and the Kubernetes control plane automatically handles scheduling the pods across the Nodes in the cluster. The control plane's automatic scheduling takes into account the available resources on each Node.

Every Kubernetes Node runs at least:

    -
  • Kubelet, a process responsible for communication between the Kubernetes Master and the Node; it manages the Pods and the containers running on a machine.
    • +
  • Kubelet, a process responsible for communication between the Kubernetes control plane and the Node; it manages the Pods and the containers running on a machine.
  • A container runtime (like Docker) responsible for pulling the container image from a registry, unpacking the container, and running the application.
diff --git a/content/en/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/en/docs/tutorials/kubernetes-basics/expose/expose-interactive.html index e89414b917..2b5d3aa365 100644 --- a/content/en/docs/tutorials/kubernetes-basics/expose/expose-interactive.html +++ b/content/en/docs/tutorials/kubernetes-basics/expose/expose-interactive.html @@ -26,7 +26,9 @@ weight: 20
- Continue to Module 5› + < Return to Module 3 + Home + Continue to Module 5 >
diff --git a/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html index d7687bc7b1..1996859e2e 100644 --- a/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -37,7 +37,7 @@ weight: 10
  • ClusterIP (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.
  • NodePort - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <NodeIP>:<NodePort>. Superset of ClusterIP.
  • LoadBalancer - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.
    • -
  • ExternalName - Maps the Service to the contents of the externalName field (e.g. `foo.bar.example.com`), by returning a CNAME record with its value. No proxying of any kind is set up. This type requires v1.7 or higher of kube-dns, or CoreDNS version 0.0.8 or higher.
    • +
  • ExternalName - Maps the Service to the contents of the externalName field (e.g. foo.bar.example.com), by returning a CNAME record with its value. No proxying of any kind is set up. This type requires v1.7 or higher of kube-dns, or CoreDNS version 0.0.8 or higher.

    • More information about the different types of Services can be found in the Using Source IP tutorial. Also see Connecting Applications with Services.

    Additionally, note that there are some use cases with Services that involve not defining selector in the spec. A Service created without selector will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using type: ExternalName.

    diff --git a/content/en/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/en/docs/tutorials/kubernetes-basics/scale/scale-interactive.html index 77e707c429..3fedf79782 100644 --- a/content/en/docs/tutorials/kubernetes-basics/scale/scale-interactive.html +++ b/content/en/docs/tutorials/kubernetes-basics/scale/scale-interactive.html @@ -26,7 +26,9 @@ weight: 20
    - Continue to Module 6› + < Return to Module 4 + Home + Continue to Module 6 >
    diff --git a/content/en/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/en/docs/tutorials/kubernetes-basics/update/update-interactive.html index 42663ecdaa..2e70d61d74 100644 --- a/content/en/docs/tutorials/kubernetes-basics/update/update-interactive.html +++ b/content/en/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -26,7 +26,8 @@ weight: 20
    - Back to Kubernetes Basics› + < Return to Module 5 + Return to Kubernetes Basics
    @@ -35,3 +36,7 @@ weight: 20 + + + + diff --git a/content/en/docs/tutorials/services/_index.md b/content/en/docs/tutorials/services/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tutorials/stateful-application/_index.md b/content/en/docs/tutorials/stateful-application/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tutorials/stateful-application/basic-stateful-set.md b/content/en/docs/tutorials/stateful-application/basic-stateful-set.md index a44c4392ca..760d3df013 100644 --- a/content/en/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/en/docs/tutorials/stateful-application/basic-stateful-set.md @@ -26,7 +26,7 @@ following Kubernetes concepts: * [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/) * [Headless Services](/docs/concepts/services-networking/service/#headless-services) * [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) -* [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) +* [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/) * [StatefulSets](/docs/concepts/workloads/controllers/statefulset/) * The [kubectl](/docs/reference/kubectl/kubectl/) command line tool @@ -845,12 +845,12 @@ kubectl get pods -w -l app=nginx ``` Use [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) to delete the -StatefulSet. Make sure to supply the `--cascade=false` parameter to the +StatefulSet. Make sure to supply the `--cascade=orphan` parameter to the command. This parameter tells Kubernetes to only delete the StatefulSet, and to not delete any of its Pods. ```shell -kubectl delete statefulset web --cascade=false +kubectl delete statefulset web --cascade=orphan ``` ``` statefulset.apps "web" deleted @@ -966,7 +966,7 @@ kubectl get pods -w -l app=nginx ``` In another terminal, delete the StatefulSet again. This time, omit the -`--cascade=false` parameter. +`--cascade=orphan` parameter. ```shell kubectl delete statefulset web diff --git a/content/en/docs/tutorials/stateful-application/cassandra.md b/content/en/docs/tutorials/stateful-application/cassandra.md index 5b453f6594..ffbf65286b 100644 --- a/content/en/docs/tutorials/stateful-application/cassandra.md +++ b/content/en/docs/tutorials/stateful-application/cassandra.md @@ -50,7 +50,7 @@ To complete this tutorial, you should already have a basic familiarity with ### Additional Minikube setup instructions {{< caution >}} -[Minikube](https://minikube.sigs.k8s.io/docs/) defaults to 1024MiB of memory and 1 CPU. +[Minikube](https://minikube.sigs.k8s.io/docs/) defaults to 2048MB of memory and 2 CPU. Running Minikube with the default resource configuration results in insufficient resource errors during this tutorial. To avoid these errors, start Minikube with the following settings: @@ -266,7 +266,7 @@ to also be deleted. Never assume you'll be able to access data if its volume cla The Pods in this tutorial use the [`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile) image from Google's [container registry](https://cloud.google.com/container-registry/docs/). -The Docker image above is based on [debian-base](https://github.com/kubernetes/kubernetes/tree/master/build/debian-base) +The Docker image above is based on [debian-base](https://github.com/kubernetes/release/tree/master/images/build/debian-base) and includes OpenJDK 8. This image includes a standard Cassandra installation from the Apache Debian repo. diff --git a/content/en/docs/tutorials/stateful-application/zookeeper.md b/content/en/docs/tutorials/stateful-application/zookeeper.md index 6d517ef229..3ed1cd454b 100644 --- a/content/en/docs/tutorials/stateful-application/zookeeper.md +++ b/content/en/docs/tutorials/stateful-application/zookeeper.md @@ -27,7 +27,7 @@ Kubernetes concepts: - [Cluster DNS](/docs/concepts/services-networking/dns-pod-service/) - [Headless Services](/docs/concepts/services-networking/service/#headless-services) - [PersistentVolumes](/docs/concepts/storage/volumes/) -- [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/) +- [PersistentVolume Provisioning](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/) - [StatefulSets](/docs/concepts/workloads/controllers/statefulset/) - [PodDisruptionBudgets](/docs/concepts/workloads/pods/disruptions/#pod-disruption-budget) - [PodAntiAffinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) @@ -937,7 +937,7 @@ Use [`kubectl drain`](/docs/reference/generated/kubectl/kubectl-commands/#drain) drain the node on which the `zk-0` Pod is scheduled. ```shell -kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data +kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data ``` ``` @@ -972,7 +972,7 @@ Keep watching the `StatefulSet`'s Pods in the first terminal and drain the node `zk-1` is scheduled. ```shell -kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned +kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data "kubernetes-node-ixsl" cordoned ``` ``` @@ -1015,7 +1015,7 @@ Continue to watch the Pods of the stateful set, and drain the node on which `zk-2` is scheduled. ```shell -kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data +kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data ``` ``` @@ -1101,7 +1101,7 @@ zk-1 1/1 Running 0 13m Attempt to drain the node on which `zk-2` is scheduled. ```shell -kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data +kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data ``` The output: diff --git a/content/en/docs/tutorials/stateless-application/_index.md b/content/en/docs/tutorials/stateless-application/_index.md old mode 100755 new mode 100644 diff --git a/content/en/docs/tutorials/stateless-application/guestbook.md b/content/en/docs/tutorials/stateless-application/guestbook.md index d21e60dde8..c31bcbc49e 100644 --- a/content/en/docs/tutorials/stateless-application/guestbook.md +++ b/content/en/docs/tutorials/stateless-application/guestbook.md @@ -1,121 +1,207 @@ --- -title: "Example: Deploying PHP Guestbook application with MongoDB" +title: "Example: Deploying PHP Guestbook application with Redis" reviewers: - ahmetb +- jimangel content_type: tutorial weight: 20 card: name: tutorials weight: 30 - title: "Stateless Example: PHP Guestbook with MongoDB" + title: "Stateless Example: PHP Guestbook with Redis" min-kubernetes-server-version: v1.14 +source: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook --- -This tutorial shows you how to build and deploy a simple _(not production ready)_, multi-tier web application using Kubernetes and [Docker](https://www.docker.com/). This example consists of the following components: +This tutorial shows you how to build and deploy a simple _(not production +ready)_, multi-tier web application using Kubernetes and +[Docker](https://www.docker.com/). This example consists of the following +components: -* A single-instance [MongoDB](https://www.mongodb.com/) to store guestbook entries +* A single-instance [Redis](https://www.redis.io/) to store guestbook entries * Multiple web frontend instances ## {{% heading "objectives" %}} -* Start up a Mongo database. +* Start up a Redis leader. +* Start up two Redis followers. * Start up the guestbook frontend. * Expose and view the Frontend Service. * Clean up. - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - -## Start up the Mongo Database +## Start up the Redis Database -The guestbook application uses MongoDB to store its data. +The guestbook application uses Redis to store its data. -### Creating the Mongo Deployment +### Creating the Redis Deployment -The manifest file, included below, specifies a Deployment controller that runs a single replica MongoDB Pod. +The manifest file, included below, specifies a Deployment controller that runs a single replica Redis Pod. -{{< codenew file="application/guestbook/mongo-deployment.yaml" >}} +{{< codenew file="application/guestbook/redis-leader-deployment.yaml" >}} 1. Launch a terminal window in the directory you downloaded the manifest files. -1. Apply the MongoDB Deployment from the `mongo-deployment.yaml` file: +1. Apply the Redis Deployment from the `redis-leader-deployment.yaml` file: - + - ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-leader-deployment.yaml + ``` -1. Query the list of Pods to verify that the MongoDB Pod is running: +1. Query the list of Pods to verify that the Redis Pod is running: - ```shell - kubectl get pods - ``` + ```shell + kubectl get pods + ``` - The response should be similar to this: + The response should be similar to this: - ```shell - NAME READY STATUS RESTARTS AGE - mongo-5cfd459dd4-lrcjb 1/1 Running 0 28s - ``` + ``` + NAME READY STATUS RESTARTS AGE + redis-leader-fb76b4755-xjr2n 1/1 Running 0 13s + ``` -1. Run the following command to view the logs from the MongoDB Deployment: +1. Run the following command to view the logs from the Redis leader Pod: - ```shell - kubectl logs -f deployment/mongo - ``` + ```shell + kubectl logs -f deployment/redis-leader + ``` -### Creating the MongoDB Service +### Creating the Redis leader Service -The guestbook application needs to communicate to the MongoDB to write its data. You need to apply a [Service](/docs/concepts/services-networking/service/) to proxy the traffic to the MongoDB Pod. A Service defines a policy to access the Pods. +The guestbook application needs to communicate to the Redis to write its data. +You need to apply a [Service](/docs/concepts/services-networking/service/) to +proxy the traffic to the Redis Pod. A Service defines a policy to access the +Pods. -{{< codenew file="application/guestbook/mongo-service.yaml" >}} +{{< codenew file="application/guestbook/redis-leader-service.yaml" >}} -1. Apply the MongoDB Service from the following `mongo-service.yaml` file: +1. Apply the Redis Service from the following `redis-leader-service.yaml` file: - + - ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-leader-service.yaml + ``` -1. Query the list of Services to verify that the MongoDB Service is running: +1. Query the list of Services to verify that the Redis Service is running: - ```shell - kubectl get service - ``` + ```shell + kubectl get service + ``` - The response should be similar to this: + The response should be similar to this: - ```shell - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - kubernetes ClusterIP 10.0.0.1 443/TCP 1m - mongo ClusterIP 10.0.0.151 27017/TCP 8s - ``` + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + kubernetes ClusterIP 10.0.0.1 443/TCP 1m + redis-leader ClusterIP 10.103.78.24 6379/TCP 16s + ``` {{< note >}} -This manifest file creates a Service named `mongo` with a set of labels that match the labels previously defined, so the Service routes network traffic to the MongoDB Pod. +This manifest file creates a Service named `redis-leader` with a set of labels +that match the labels previously defined, so the Service routes network +traffic to the Redis Pod. {{< /note >}} +### Set up Redis followers + +Although the Redis leader is a single Pod, you can make it highly available +and meet traffic demands by adding a few Redis followers, or replicas. + +{{< codenew file="application/guestbook/redis-follower-deployment.yaml" >}} + +1. Apply the Redis Deployment from the following `redis-follower-deployment.yaml` file: + + + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-follower-deployment.yaml + ``` + +1. Verify that the two Redis follower replicas are running by querying the list of Pods: + + ```shell + kubectl get pods + ``` + + The response should be similar to this: + + ``` + NAME READY STATUS RESTARTS AGE + redis-follower-dddfbdcc9-82sfr 1/1 Running 0 37s + redis-follower-dddfbdcc9-qrt5k 1/1 Running 0 38s + redis-leader-fb76b4755-xjr2n 1/1 Running 0 11m + ``` + +### Creating the Redis follower service + +The guestbook application needs to communicate with the Redis followers to +read data. To make the Redis followers discoverable, you must set up another +[Service](/docs/concepts/services-networking/service/). + +{{< codenew file="application/guestbook/redis-follower-service.yaml" >}} + +1. Apply the Redis Service from the following `redis-follower-service.yaml` file: + + + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-follower-service.yaml + ``` + +1. Query the list of Services to verify that the Redis Service is running: + + ```shell + kubectl get service + ``` + + The response should be similar to this: + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + kubernetes ClusterIP 10.96.0.1 443/TCP 3d19h + redis-follower ClusterIP 10.110.162.42 6379/TCP 9s + redis-leader ClusterIP 10.103.78.24 6379/TCP 6m10s + ``` + +{{< note >}} +This manifest file creates a Service named `redis-follower` with a set of +labels that match the labels previously defined, so the Service routes network +traffic to the Redis Pod. +{{< /note >}} ## Set up and Expose the Guestbook Frontend -The guestbook application has a web frontend serving the HTTP requests written in PHP. It is configured to connect to the `mongo` Service to store Guestbook entries. +Now that you have the Redis storage of your guestbook up and running, start +the guestbook web servers. Like the Redis followers, the frontend is deployed +using a Kubernetes Deployment. + +The guestbook app uses a PHP frontend. It is configured to communicate with +either the Redis follower or leader Services, depending on whether the request +is a read or a write. The frontend exposes a JSON interface, and serves a +jQuery-Ajax-based UX. ### Creating the Guestbook Frontend Deployment @@ -123,190 +209,210 @@ The guestbook application has a web frontend serving the HTTP requests written i 1. Apply the frontend Deployment from the `frontend-deployment.yaml` file: - + - ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml + ``` 1. Query the list of Pods to verify that the three frontend replicas are running: - ```shell - kubectl get pods -l app.kubernetes.io/name=guestbook -l app.kubernetes.io/component=frontend - ``` + ```shell + kubectl get pods -l app=guestbook -l tier=frontend + ``` - The response should be similar to this: + The response should be similar to this: - ``` - NAME READY STATUS RESTARTS AGE - frontend-3823415956-dsvc5 1/1 Running 0 54s - frontend-3823415956-k22zn 1/1 Running 0 54s - frontend-3823415956-w9gbt 1/1 Running 0 54s - ``` + ``` + NAME READY STATUS RESTARTS AGE + frontend-85595f5bf9-5tqhb 1/1 Running 0 47s + frontend-85595f5bf9-qbzwm 1/1 Running 0 47s + frontend-85595f5bf9-zchwc 1/1 Running 0 47s + ``` ### Creating the Frontend Service -The `mongo` Services you applied is only accessible within the Kubernetes cluster because the default type for a Service is [ClusterIP](/docs/concepts/services-networking/service/#publishing-services-service-types). `ClusterIP` provides a single IP address for the set of Pods the Service is pointing to. This IP address is accessible only within the cluster. +The `Redis` Services you applied is only accessible within the Kubernetes +cluster because the default type for a Service is +[ClusterIP](/docs/concepts/services-networking/service/#publishing-services-service-types). +`ClusterIP` provides a single IP address for the set of Pods the Service is +pointing to. This IP address is accessible only within the cluster. -If you want guests to be able to access your guestbook, you must configure the frontend Service to be externally visible, so a client can request the Service from outside the Kubernetes cluster. However a Kubernetes user you can use `kubectl port-forward` to access the service even though it uses a `ClusterIP`. +If you want guests to be able to access your guestbook, you must configure the +frontend Service to be externally visible, so a client can request the Service +from outside the Kubernetes cluster. However a Kubernetes user you can use +`kubectl port-forward` to access the service even though it uses a +`ClusterIP`. {{< note >}} -Some cloud providers, like Google Compute Engine or Google Kubernetes Engine, support external load balancers. If your cloud provider supports load balancers and you want to use it, uncomment `type: LoadBalancer`. +Some cloud providers, like Google Compute Engine or Google Kubernetes Engine, +support external load balancers. If your cloud provider supports load +balancers and you want to use it, uncomment `type: LoadBalancer`. {{< /note >}} {{< codenew file="application/guestbook/frontend-service.yaml" >}} 1. Apply the frontend Service from the `frontend-service.yaml` file: - + - ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml + ``` 1. Query the list of Services to verify that the frontend Service is running: - ```shell - kubectl get services - ``` + ```shell + kubectl get services + ``` - The response should be similar to this: + The response should be similar to this: - ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - frontend ClusterIP 10.0.0.112 80/TCP 6s - kubernetes ClusterIP 10.0.0.1 443/TCP 4m - mongo ClusterIP 10.0.0.151 6379/TCP 2m - ``` + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + frontend ClusterIP 10.97.28.230 80/TCP 19s + kubernetes ClusterIP 10.96.0.1 443/TCP 3d19h + redis-follower ClusterIP 10.110.162.42 6379/TCP 5m48s + redis-leader ClusterIP 10.103.78.24 6379/TCP 11m + ``` ### Viewing the Frontend Service via `kubectl port-forward` 1. Run the following command to forward port `8080` on your local machine to port `80` on the service. - ```shell - kubectl port-forward svc/frontend 8080:80 - ``` + ```shell + kubectl port-forward svc/frontend 8080:80 + ``` - The response should be similar to this: + The response should be similar to this: - ``` - Forwarding from 127.0.0.1:8080 -> 80 - Forwarding from [::1]:8080 -> 80 - ``` + ``` + Forwarding from 127.0.0.1:8080 -> 80 + Forwarding from [::1]:8080 -> 80 + ``` 1. load the page [http://localhost:8080](http://localhost:8080) in your browser to view your guestbook. ### Viewing the Frontend Service via `LoadBalancer` -If you deployed the `frontend-service.yaml` manifest with type: `LoadBalancer` you need to find the IP address to view your Guestbook. +If you deployed the `frontend-service.yaml` manifest with type: `LoadBalancer` +you need to find the IP address to view your Guestbook. 1. Run the following command to get the IP address for the frontend Service. - ```shell - kubectl get service frontend - ``` + ```shell + kubectl get service frontend + ``` - The response should be similar to this: + The response should be similar to this: - ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - frontend LoadBalancer 10.51.242.136 109.197.92.229 80:32372/TCP 1m - ``` + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + frontend LoadBalancer 10.51.242.136 109.197.92.229 80:32372/TCP 1m + ``` 1. Copy the external IP address, and load the page in your browser to view your guestbook. +{{< note >}} +Try adding some guestbook entries by typing in a message, and clicking Submit. +The message you typed appears in the frontend. This message indicates that +data is successfully added to Redis through the Services you created earlier. +{{< /note >}} + ## Scale the Web Frontend -You can scale up or down as needed because your servers are defined as a Service that uses a Deployment controller. +You can scale up or down as needed because your servers are defined as a +Service that uses a Deployment controller. 1. Run the following command to scale up the number of frontend Pods: - ```shell - kubectl scale deployment frontend --replicas=5 - ``` + ```shell + kubectl scale deployment frontend --replicas=5 + ``` 1. Query the list of Pods to verify the number of frontend Pods running: - ```shell - kubectl get pods - ``` + ```shell + kubectl get pods + ``` - The response should look similar to this: + The response should look similar to this: - ``` - NAME READY STATUS RESTARTS AGE - frontend-3823415956-70qj5 1/1 Running 0 5s - frontend-3823415956-dsvc5 1/1 Running 0 54m - frontend-3823415956-k22zn 1/1 Running 0 54m - frontend-3823415956-w9gbt 1/1 Running 0 54m - frontend-3823415956-x2pld 1/1 Running 0 5s - mongo-1068406935-3lswp 1/1 Running 0 56m - ``` + ``` + NAME READY STATUS RESTARTS AGE + frontend-85595f5bf9-5df5m 1/1 Running 0 83s + frontend-85595f5bf9-7zmg5 1/1 Running 0 83s + frontend-85595f5bf9-cpskg 1/1 Running 0 15m + frontend-85595f5bf9-l2l54 1/1 Running 0 14m + frontend-85595f5bf9-l9c8z 1/1 Running 0 14m + redis-follower-dddfbdcc9-82sfr 1/1 Running 0 97m + redis-follower-dddfbdcc9-qrt5k 1/1 Running 0 97m + redis-leader-fb76b4755-xjr2n 1/1 Running 0 108m + ``` 1. Run the following command to scale down the number of frontend Pods: - ```shell - kubectl scale deployment frontend --replicas=2 - ``` + ```shell + kubectl scale deployment frontend --replicas=2 + ``` 1. Query the list of Pods to verify the number of frontend Pods running: - ```shell - kubectl get pods - ``` - - The response should look similar to this: - - ``` - NAME READY STATUS RESTARTS AGE - frontend-3823415956-k22zn 1/1 Running 0 1h - frontend-3823415956-w9gbt 1/1 Running 0 1h - mongo-1068406935-3lswp 1/1 Running 0 1h - ``` + ```shell + kubectl get pods + ``` + The response should look similar to this: + ``` + NAME READY STATUS RESTARTS AGE + frontend-85595f5bf9-cpskg 1/1 Running 0 16m + frontend-85595f5bf9-l9c8z 1/1 Running 0 15m + redis-follower-dddfbdcc9-82sfr 1/1 Running 0 98m + redis-follower-dddfbdcc9-qrt5k 1/1 Running 0 98m + redis-leader-fb76b4755-xjr2n 1/1 Running 0 109m + ``` ## {{% heading "cleanup" %}} -Deleting the Deployments and Services also deletes any running Pods. Use labels to delete multiple resources with one command. +Deleting the Deployments and Services also deletes any running Pods. Use +labels to delete multiple resources with one command. 1. Run the following commands to delete all Pods, Deployments, and Services. - ```shell - kubectl delete deployment -l app.kubernetes.io/name=mongo - kubectl delete service -l app.kubernetes.io/name=mongo - kubectl delete deployment -l app.kubernetes.io/name=guestbook - kubectl delete service -l app.kubernetes.io/name=guestbook - ``` + ```shell + kubectl delete deployment -l app=redis + kubectl delete service -l app=redis + kubectl delete deployment frontend + kubectl delete service frontend + ``` - The responses should be: + The response should look similar to this: - ``` - deployment.apps "mongo" deleted - service "mongo" deleted - deployment.apps "frontend" deleted - service "frontend" deleted - ``` + ``` + deployment.apps "redis-follower" deleted + deployment.apps "redis-leader" deleted + deployment.apps "frontend" deleted + service "frontend" deleted + ``` 1. Query the list of Pods to verify that no Pods are running: - ```shell - kubectl get pods - ``` - - The response should be this: - - ``` - No resources found. - ``` + ```shell + kubectl get pods + ``` + The response should look similar to this: + ``` + No resources found in default namespace. + ``` ## {{% heading "whatsnext" %}} diff --git a/content/en/examples/access/endpoints-aggregated.yaml b/content/en/examples/access/endpoints-aggregated.yaml new file mode 100644 index 0000000000..41cd12164a --- /dev/null +++ b/content/en/examples/access/endpoints-aggregated.yaml @@ -0,0 +1,18 @@ +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + annotations: + kubernetes.io/description: |- + Add endpoints write permissions to the edit and admin roles. This was + removed by default in 1.22 because of CVE-2021-25740. See + https://issue.k8s.io/103675. This can allow writers to direct LoadBalancer + or Ingress implementations to expose backend IPs that would not otherwise + be accessible, and can circumvent network policies or security controls + intended to prevent/isolate access to those backends. + labels: + rbac.authorization.k8s.io/aggregate-to-edit: "true" + name: custom:aggregate-to-edit:endpoints # you can change this if you wish +rules: + - apiGroups: [""] + resources: ["endpoints"] + verbs: ["create", "delete", "deletecollection", "patch", "update"] diff --git a/content/en/examples/admin/cloud/ccm-example.yaml b/content/en/examples/admin/cloud/ccm-example.yaml index 20aafb31e5..3bce7b58fa 100644 --- a/content/en/examples/admin/cloud/ccm-example.yaml +++ b/content/en/examples/admin/cloud/ccm-example.yaml @@ -1,4 +1,4 @@ -# This is an example of how to setup cloud-controller-manger as a Daemonset in your cluster. +# This is an example of how to setup cloud-controller-manager as a Daemonset in your cluster. # It assumes that your masters can run pods and has the role node-role.kubernetes.io/master # Note that this Daemonset will not work straight out of the box for your cloud, this is # meant to be a guideline. diff --git a/content/en/examples/admin/dns/dns-horizontal-autoscaler.yaml b/content/en/examples/admin/dns/dns-horizontal-autoscaler.yaml index dff87cf851..b4bf65834a 100644 --- a/content/en/examples/admin/dns/dns-horizontal-autoscaler.yaml +++ b/content/en/examples/admin/dns/dns-horizontal-autoscaler.yaml @@ -1,33 +1,87 @@ +kind: ServiceAccount +apiVersion: v1 +metadata: + name: kube-dns-autoscaler + namespace: kube-system +--- +kind: ClusterRole +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: system:kube-dns-autoscaler +rules: + - apiGroups: [""] + resources: ["nodes"] + verbs: ["list", "watch"] + - apiGroups: [""] + resources: ["replicationcontrollers/scale"] + verbs: ["get", "update"] + - apiGroups: ["apps"] + resources: ["deployments/scale", "replicasets/scale"] + verbs: ["get", "update"] +# Remove the configmaps rule once below issue is fixed: +# kubernetes-incubator/cluster-proportional-autoscaler#16 + - apiGroups: [""] + resources: ["configmaps"] + verbs: ["get", "create"] +--- +kind: ClusterRoleBinding +apiVersion: rbac.authorization.k8s.io/v1 +metadata: + name: system:kube-dns-autoscaler +subjects: + - kind: ServiceAccount + name: kube-dns-autoscaler + namespace: kube-system +roleRef: + kind: ClusterRole + name: system:kube-dns-autoscaler + apiGroup: rbac.authorization.k8s.io + +--- apiVersion: apps/v1 kind: Deployment metadata: - name: dns-autoscaler + name: kube-dns-autoscaler namespace: kube-system labels: - k8s-app: dns-autoscaler + k8s-app: kube-dns-autoscaler + kubernetes.io/cluster-service: "true" spec: selector: matchLabels: - k8s-app: dns-autoscaler + k8s-app: kube-dns-autoscaler template: metadata: labels: - k8s-app: dns-autoscaler + k8s-app: kube-dns-autoscaler spec: + priorityClassName: system-cluster-critical + securityContext: + seccompProfile: + type: RuntimeDefault + supplementalGroups: [ 65534 ] + fsGroup: 65534 + nodeSelector: + kubernetes.io/os: linux containers: - name: autoscaler - image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.6.0 + image: k8s.gcr.io/cpa/cluster-proportional-autoscaler:1.8.4 resources: - requests: - cpu: 20m - memory: 10Mi + requests: + cpu: "20m" + memory: "10Mi" command: - - /cluster-proportional-autoscaler - - --namespace=kube-system - - --configmap=dns-autoscaler - - --target= - # When cluster is using large nodes(with more cores), "coresPerReplica" should dominate. - # If using small nodes, "nodesPerReplica" should dominate. - - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"min":1}} - - --logtostderr=true - - --v=2 + - /cluster-proportional-autoscaler + - --namespace=kube-system + - --configmap=kube-dns-autoscaler + # Should keep target in sync with cluster/addons/dns/kube-dns.yaml.base + - --target= + # When cluster is using large nodes(with more cores), "coresPerReplica" should dominate. + # If using small nodes, "nodesPerReplica" should dominate. + - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"preventSinglePointFailure":true,"includeUnschedulableNodes":true}} + - --logtostderr=true + - --v=2 + tolerations: + - key: "CriticalAddonsOnly" + operator: "Exists" + serviceAccountName: kube-dns-autoscaler diff --git a/content/en/examples/admin/konnectivity/konnectivity-agent.yaml b/content/en/examples/admin/konnectivity/konnectivity-agent.yaml index 3c71999427..0eb47e1c58 100644 --- a/content/en/examples/admin/konnectivity/konnectivity-agent.yaml +++ b/content/en/examples/admin/konnectivity/konnectivity-agent.yaml @@ -22,7 +22,7 @@ spec: - key: "CriticalAddonsOnly" operator: "Exists" containers: - - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.12 + - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent:v0.0.16 name: konnectivity-agent command: ["/proxy-agent"] args: [ diff --git a/content/en/examples/admin/konnectivity/konnectivity-server.yaml b/content/en/examples/admin/konnectivity/konnectivity-server.yaml index a0f45af5ff..f1f378431a 100644 --- a/content/en/examples/admin/konnectivity/konnectivity-server.yaml +++ b/content/en/examples/admin/konnectivity/konnectivity-server.yaml @@ -8,7 +8,7 @@ spec: hostNetwork: true containers: - name: konnectivity-server-container - image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.12 + image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-server:v0.0.16 command: ["/proxy-server"] args: [ "--logtostderr=true", diff --git a/content/en/examples/application/guestbook/frontend-deployment.yaml b/content/en/examples/application/guestbook/frontend-deployment.yaml index 613c654aa9..f97f20dab6 100644 --- a/content/en/examples/application/guestbook/frontend-deployment.yaml +++ b/content/en/examples/application/guestbook/frontend-deployment.yaml @@ -1,32 +1,29 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook apiVersion: apps/v1 kind: Deployment metadata: name: frontend - labels: - app.kubernetes.io/name: guestbook - app.kubernetes.io/component: frontend spec: + replicas: 3 selector: matchLabels: - app.kubernetes.io/name: guestbook - app.kubernetes.io/component: frontend - replicas: 3 + app: guestbook + tier: frontend template: metadata: labels: - app.kubernetes.io/name: guestbook - app.kubernetes.io/component: frontend + app: guestbook + tier: frontend spec: containers: - - name: guestbook - image: paulczar/gb-frontend:v5 - # image: gcr.io/google-samples/gb-frontend:v4 + - name: php-redis + image: gcr.io/google_samples/gb-frontend:v5 + env: + - name: GET_HOSTS_FROM + value: "dns" resources: requests: cpu: 100m memory: 100Mi - env: - - name: GET_HOSTS_FROM - value: dns ports: - - containerPort: 80 + - containerPort: 80 \ No newline at end of file diff --git a/content/en/examples/application/guestbook/frontend-service.yaml b/content/en/examples/application/guestbook/frontend-service.yaml index 34ad3771d7..410c6bbaf2 100644 --- a/content/en/examples/application/guestbook/frontend-service.yaml +++ b/content/en/examples/application/guestbook/frontend-service.yaml @@ -1,16 +1,19 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook apiVersion: v1 kind: Service metadata: name: frontend labels: - app.kubernetes.io/name: guestbook - app.kubernetes.io/component: frontend + app: guestbook + tier: frontend spec: # if your cluster supports it, uncomment the following to automatically create # an external load-balanced IP for the frontend service. # type: LoadBalancer + #type: LoadBalancer ports: + # the port that this service should serve on - port: 80 selector: - app.kubernetes.io/name: guestbook - app.kubernetes.io/component: frontend + app: guestbook + tier: frontend \ No newline at end of file diff --git a/content/en/examples/application/guestbook/redis-follower-deployment.yaml b/content/en/examples/application/guestbook/redis-follower-deployment.yaml new file mode 100644 index 0000000000..c418cf7364 --- /dev/null +++ b/content/en/examples/application/guestbook/redis-follower-deployment.yaml @@ -0,0 +1,30 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: apps/v1 +kind: Deployment +metadata: + name: redis-follower + labels: + app: redis + role: follower + tier: backend +spec: + replicas: 2 + selector: + matchLabels: + app: redis + template: + metadata: + labels: + app: redis + role: follower + tier: backend + spec: + containers: + - name: follower + image: gcr.io/google_samples/gb-redis-follower:v2 + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 6379 \ No newline at end of file diff --git a/content/en/examples/application/guestbook/redis-follower-service.yaml b/content/en/examples/application/guestbook/redis-follower-service.yaml new file mode 100644 index 0000000000..53283d35c4 --- /dev/null +++ b/content/en/examples/application/guestbook/redis-follower-service.yaml @@ -0,0 +1,17 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: v1 +kind: Service +metadata: + name: redis-follower + labels: + app: redis + role: follower + tier: backend +spec: + ports: + # the port that this service should serve on + - port: 6379 + selector: + app: redis + role: follower + tier: backend \ No newline at end of file diff --git a/content/en/examples/application/guestbook/redis-leader-deployment.yaml b/content/en/examples/application/guestbook/redis-leader-deployment.yaml new file mode 100644 index 0000000000..9c7547291c --- /dev/null +++ b/content/en/examples/application/guestbook/redis-leader-deployment.yaml @@ -0,0 +1,30 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: apps/v1 +kind: Deployment +metadata: + name: redis-leader + labels: + app: redis + role: leader + tier: backend +spec: + replicas: 1 + selector: + matchLabels: + app: redis + template: + metadata: + labels: + app: redis + role: leader + tier: backend + spec: + containers: + - name: leader + image: "docker.io/redis:6.0.5" + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 6379 \ No newline at end of file diff --git a/content/en/examples/application/guestbook/redis-leader-service.yaml b/content/en/examples/application/guestbook/redis-leader-service.yaml new file mode 100644 index 0000000000..e04cc183d0 --- /dev/null +++ b/content/en/examples/application/guestbook/redis-leader-service.yaml @@ -0,0 +1,17 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: v1 +kind: Service +metadata: + name: redis-leader + labels: + app: redis + role: leader + tier: backend +spec: + ports: + - port: 6379 + targetPort: 6379 + selector: + app: redis + role: leader + tier: backend \ No newline at end of file diff --git a/content/en/examples/application/job/cronjob.yaml b/content/en/examples/application/job/cronjob.yaml index 816d682f28..da905a9048 100644 --- a/content/en/examples/application/job/cronjob.yaml +++ b/content/en/examples/application/job/cronjob.yaml @@ -1,4 +1,4 @@ -apiVersion: batch/v1beta1 +apiVersion: batch/v1 kind: CronJob metadata: name: hello diff --git a/content/en/examples/application/job/indexed-job-vol.yaml b/content/en/examples/application/job/indexed-job-vol.yaml new file mode 100644 index 0000000000..ed40e1cc44 --- /dev/null +++ b/content/en/examples/application/job/indexed-job-vol.yaml @@ -0,0 +1,27 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: 'indexed-job' +spec: + completions: 5 + parallelism: 3 + completionMode: Indexed + template: + spec: + restartPolicy: Never + containers: + - name: 'worker' + image: 'docker.io/library/busybox' + command: + - "rev" + - "/input/data.txt" + volumeMounts: + - mountPath: /input + name: input + volumes: + - name: input + downwardAPI: + items: + - path: "data.txt" + fieldRef: + fieldPath: metadata.annotations['batch.kubernetes.io/job-completion-index'] \ No newline at end of file diff --git a/content/en/examples/application/job/indexed-job.yaml b/content/en/examples/application/job/indexed-job.yaml new file mode 100644 index 0000000000..5b80d35264 --- /dev/null +++ b/content/en/examples/application/job/indexed-job.yaml @@ -0,0 +1,35 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: 'indexed-job' +spec: + completions: 5 + parallelism: 3 + completionMode: Indexed + template: + spec: + restartPolicy: Never + initContainers: + - name: 'input' + image: 'docker.io/library/bash' + command: + - "bash" + - "-c" + - | + items=(foo bar baz qux xyz) + echo ${items[$JOB_COMPLETION_INDEX]} > /input/data.txt + volumeMounts: + - mountPath: /input + name: input + containers: + - name: 'worker' + image: 'docker.io/library/busybox' + command: + - "rev" + - "/input/data.txt" + volumeMounts: + - mountPath: /input + name: input + volumes: + - name: input + emptyDir: {} diff --git a/content/en/examples/application/job/redis/worker.py b/content/en/examples/application/job/redis/worker.py index b8abbee917..c3523a4e21 100644 --- a/content/en/examples/application/job/redis/worker.py +++ b/content/en/examples/application/job/redis/worker.py @@ -8,7 +8,7 @@ host="redis" # import os # host = os.getenv("REDIS_SERVICE_HOST") -q = rediswq.RedisWQ(name="job2", host="redis") +q = rediswq.RedisWQ(name="job2", host=host) print("Worker with sessionID: " + q.sessionID()) print("Initial queue state: empty=" + str(q.empty())) while not q.empty(): diff --git a/content/en/examples/application/guestbook/mongo-deployment.yaml b/content/en/examples/application/mongodb/mongo-deployment.yaml similarity index 100% rename from content/en/examples/application/guestbook/mongo-deployment.yaml rename to content/en/examples/application/mongodb/mongo-deployment.yaml diff --git a/content/en/examples/application/guestbook/mongo-service.yaml b/content/en/examples/application/mongodb/mongo-service.yaml similarity index 100% rename from content/en/examples/application/guestbook/mongo-service.yaml rename to content/en/examples/application/mongodb/mongo-service.yaml diff --git a/content/en/examples/application/zookeeper/zookeeper.yaml b/content/en/examples/application/zookeeper/zookeeper.yaml index a858a72613..4d893b369b 100644 --- a/content/en/examples/application/zookeeper/zookeeper.yaml +++ b/content/en/examples/application/zookeeper/zookeeper.yaml @@ -27,7 +27,7 @@ spec: selector: app: zk --- -apiVersion: policy/v1beta1 +apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: zk-pdb diff --git a/content/en/examples/controllers/daemonset.yaml b/content/en/examples/controllers/daemonset.yaml index f291b750c1..685a137244 100644 --- a/content/en/examples/controllers/daemonset.yaml +++ b/content/en/examples/controllers/daemonset.yaml @@ -18,6 +18,7 @@ spec: # this toleration is to have the daemonset runnable on master nodes # remove it if your masters can't run pods - key: node-role.kubernetes.io/master + operator: Exists effect: NoSchedule containers: - name: fluentd-elasticsearch diff --git a/content/en/examples/examples_test.go b/content/en/examples/examples_test.go index 982ddbd693..a31d01b130 100644 --- a/content/en/examples/examples_test.go +++ b/content/en/examples/examples_test.go @@ -149,8 +149,19 @@ func getCodecForObject(obj runtime.Object) (runtime.Codec, error) { func validateObject(obj runtime.Object) (errors field.ErrorList) { podValidationOptions := validation.PodValidationOptions{ - AllowMultipleHugePageResources: true, - AllowDownwardAPIHugePages: true, + AllowDownwardAPIHugePages: true, + AllowInvalidPodDeletionCost: false, + AllowIndivisibleHugePagesValues: true, + AllowWindowsHostProcessField: true, + AllowExpandedDNSConfig: true, + } + + quotaValidationOptions := validation.ResourceQuotaValidationOptions{ + AllowPodAffinityNamespaceSelector: true, + } + + pspValidationOptions := policy_validation.PodSecurityPolicyValidationOptions{ + AllowEphemeralVolumeType: true, } // Enable CustomPodDNS for testing @@ -174,20 +185,23 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { case *api.Namespace: errors = validation.ValidateNamespace(t) case *api.PersistentVolume: - errors = validation.ValidatePersistentVolume(t) + opts := validation.PersistentVolumeSpecValidationOptions{ + AllowReadWriteOncePod: true, + } + errors = validation.ValidatePersistentVolume(t, opts) case *api.PersistentVolumeClaim: if t.Namespace == "" { t.Namespace = api.NamespaceDefault } - errors = validation.ValidatePersistentVolumeClaim(t) + opts := validation.PersistentVolumeClaimSpecValidationOptions{ + AllowReadWriteOncePod: true, + } + errors = validation.ValidatePersistentVolumeClaim(t, opts) case *api.Pod: if t.Namespace == "" { t.Namespace = api.NamespaceDefault } - opts := validation.PodValidationOptions{ - AllowMultipleHugePageResources: true, - } - errors = validation.ValidatePodCreate(t, opts) + errors = validation.ValidatePodCreate(t, podValidationOptions) case *api.PodList: for i := range t.Items { errors = append(errors, validateObject(&t.Items[i])...) @@ -210,7 +224,7 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { if t.Namespace == "" { t.Namespace = api.NamespaceDefault } - errors = validation.ValidateResourceQuota(t) + errors = validation.ValidateResourceQuota(t, quotaValidationOptions) case *api.Secret: if t.Namespace == "" { t.Namespace = api.NamespaceDefault @@ -238,7 +252,7 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { if t.Namespace == "" { t.Namespace = api.NamespaceDefault } - errors = apps_validation.ValidateStatefulSet(t) + errors = apps_validation.ValidateStatefulSet(t, podValidationOptions) case *autoscaling.HorizontalPodAutoscaler: if t.Namespace == "" { t.Namespace = api.NamespaceDefault @@ -287,7 +301,7 @@ func validateObject(obj runtime.Object) (errors field.ErrorList) { errors = networking_validation.ValidateIngressClass(t) case *policy.PodSecurityPolicy: - errors = policy_validation.ValidatePodSecurityPolicy(t) + errors = policy_validation.ValidatePodSecurityPolicy(t, pspValidationOptions) case *apps.ReplicaSet: if t.Namespace == "" { t.Namespace = api.NamespaceDefault @@ -462,12 +476,12 @@ func TestExampleObjectSchemas(t *testing.T) { "cassandra-statefulset": {&apps.StatefulSet{}, &storage.StorageClass{}}, }, "application/guestbook": { - "frontend-deployment": {&apps.Deployment{}}, - "frontend-service": {&api.Service{}}, - "redis-master-deployment": {&apps.Deployment{}}, - "redis-master-service": {&api.Service{}}, - "redis-slave-deployment": {&apps.Deployment{}}, - "redis-slave-service": {&api.Service{}}, + "frontend-deployment": {&apps.Deployment{}}, + "frontend-service": {&api.Service{}}, + "redis-follower-deployment": {&apps.Deployment{}}, + "redis-follower-service": {&api.Service{}}, + "redis-leader-deployment": {&apps.Deployment{}}, + "redis-leader-service": {&api.Service{}}, }, "application/hpa": { "php-apache": {&autoscaling.HorizontalPodAutoscaler{}}, @@ -477,8 +491,10 @@ func TestExampleObjectSchemas(t *testing.T) { "nginx-svc": {&api.Service{}}, }, "application/job": { - "cronjob": {&batch.CronJob{}}, - "job-tmpl": {&batch.Job{}}, + "cronjob": {&batch.CronJob{}}, + "job-tmpl": {&batch.Job{}}, + "indexed-job": {&batch.Job{}}, + "indexed-job-vol": {&batch.Job{}}, }, "application/job/rabbitmq": { "job": {&batch.Job{}}, @@ -557,7 +573,8 @@ func TestExampleObjectSchemas(t *testing.T) { "two-container-pod": {&api.Pod{}}, }, "pods/config": { - "redis-pod": {&api.Pod{}}, + "redis-pod": {&api.Pod{}}, + "example-redis-config": {&api.ConfigMap{}}, }, "pods/inject": { "dapi-envars-container": {&api.Pod{}}, @@ -610,10 +627,11 @@ func TestExampleObjectSchemas(t *testing.T) { "redis": {&api.Pod{}}, }, "policy": { - "baseline-psp": {&policy.PodSecurityPolicy{}}, - "example-psp": {&policy.PodSecurityPolicy{}}, - "privileged-psp": {&policy.PodSecurityPolicy{}}, - "restricted-psp": {&policy.PodSecurityPolicy{}}, + "baseline-psp": {&policy.PodSecurityPolicy{}}, + "example-psp": {&policy.PodSecurityPolicy{}}, + "priority-class-resourcequota": {&api.ResourceQuota{}}, + "privileged-psp": {&policy.PodSecurityPolicy{}}, + "restricted-psp": {&policy.PodSecurityPolicy{}}, "zookeeper-pod-disruption-budget-maxunavailable": {&policy.PodDisruptionBudget{}}, "zookeeper-pod-disruption-budget-minavailable": {&policy.PodDisruptionBudget{}}, }, @@ -645,6 +663,7 @@ func TestExampleObjectSchemas(t *testing.T) { "minimal-ingress": {&networking.Ingress{}}, "name-virtual-host-ingress": {&networking.Ingress{}}, "name-virtual-host-ingress-no-third-host": {&networking.Ingress{}}, + "namespaced-params": {&networking.IngressClass{}}, "network-policy-allow-all-egress": {&networking.NetworkPolicy{}}, "network-policy-allow-all-ingress": {&networking.NetworkPolicy{}}, "network-policy-default-deny-egress": {&networking.NetworkPolicy{}}, diff --git a/content/en/examples/policy/baseline-psp.yaml b/content/en/examples/policy/baseline-psp.yaml index 36e440588b..57258bf313 100644 --- a/content/en/examples/policy/baseline-psp.yaml +++ b/content/en/examples/policy/baseline-psp.yaml @@ -6,20 +6,16 @@ metadata: # Optional: Allow the default AppArmor profile, requires setting the default. apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' - # Optional: Allow the default seccomp profile, requires setting the default. - seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default,unconfined' - seccomp.security.alpha.kubernetes.io/defaultProfileName: 'unconfined' + seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*' spec: privileged: false - # The moby default capability set, defined here: - # https://github.com/moby/moby/blob/0a5cec2833f82a6ad797d70acbf9cbbaf8956017/oci/caps/defaults.go#L6-L19 + # The moby default capability set, minus NET_RAW allowedCapabilities: - 'CHOWN' - 'DAC_OVERRIDE' - 'FSETID' - 'FOWNER' - 'MKNOD' - - 'NET_RAW' - 'SETGID' - 'SETUID' - 'SETFCAP' @@ -36,15 +32,16 @@ spec: - 'projected' - 'secret' - 'downwardAPI' - # Assume that persistentVolumes set up by the cluster admin are safe to use. + # Assume that ephemeral CSI drivers & persistentVolumes set up by the cluster admin are safe to use. + - 'csi' - 'persistentVolumeClaim' + - 'ephemeral' # Allow all other non-hostpath volume types. - 'awsElasticBlockStore' - 'azureDisk' - 'azureFile' - 'cephFS' - 'cinder' - - 'csi' - 'fc' - 'flexVolume' - 'flocker' @@ -67,6 +64,9 @@ spec: runAsUser: rule: 'RunAsAny' seLinux: + # This policy assumes the nodes are using AppArmor rather than SELinux. + # The PSP SELinux API cannot express the SELinux Pod Security Standards, + # so if using SELinux, you must choose a more restrictive default. rule: 'RunAsAny' supplementalGroups: rule: 'RunAsAny' diff --git a/content/en/examples/policy/restricted-psp.yaml b/content/en/examples/policy/restricted-psp.yaml index 4db57688b1..0837c5a3ce 100644 --- a/content/en/examples/policy/restricted-psp.yaml +++ b/content/en/examples/policy/restricted-psp.yaml @@ -5,14 +5,11 @@ metadata: annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default' apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' - seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default' apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' spec: privileged: false # Required to prevent escalations to root. allowPrivilegeEscalation: false - # This is redundant with non-root + disallow privilege escalation, - # but we can provide it for defense in depth. requiredDropCapabilities: - ALL # Allow core volume types. @@ -22,8 +19,10 @@ spec: - 'projected' - 'secret' - 'downwardAPI' - # Assume that persistentVolumes set up by the cluster admin are safe to use. + # Assume that ephemeral CSI drivers & persistentVolumes set up by the cluster admin are safe to use. + - 'csi' - 'persistentVolumeClaim' + - 'ephemeral' hostNetwork: false hostIPC: false hostPID: false diff --git a/content/en/examples/policy/zookeeper-pod-disruption-budget-maxunavailable.yaml b/content/en/examples/policy/zookeeper-pod-disruption-budget-maxunavailable.yaml index a62bef140f..ef0b8645ba 100644 --- a/content/en/examples/policy/zookeeper-pod-disruption-budget-maxunavailable.yaml +++ b/content/en/examples/policy/zookeeper-pod-disruption-budget-maxunavailable.yaml @@ -1,4 +1,4 @@ -apiVersion: policy/v1beta1 +apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: zk-pdb diff --git a/content/en/examples/policy/zookeeper-pod-disruption-budget-minavailable.yaml b/content/en/examples/policy/zookeeper-pod-disruption-budget-minavailable.yaml index c4776ad4c0..49a66ee669 100644 --- a/content/en/examples/policy/zookeeper-pod-disruption-budget-minavailable.yaml +++ b/content/en/examples/policy/zookeeper-pod-disruption-budget-minavailable.yaml @@ -1,4 +1,4 @@ -apiVersion: policy/v1beta1 +apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: zk-pdb diff --git a/content/en/examples/security/podsecurity-baseline.yaml b/content/en/examples/security/podsecurity-baseline.yaml new file mode 100644 index 0000000000..6251af5d2f --- /dev/null +++ b/content/en/examples/security/podsecurity-baseline.yaml @@ -0,0 +1,9 @@ +apiVersion: v1 +kind: Namespace +metadata: + name: my-baseline-namespace + labels: + pod-security.kubernetes.io/enforce: baseline + pod-security.kubernetes.io/enforce-version: latest + pod-security.kubernetes.io/warn: baseline + pod-security.kubernetes.io/warn-version: latest \ No newline at end of file diff --git a/content/en/examples/security/podsecurity-privileged.yaml b/content/en/examples/security/podsecurity-privileged.yaml new file mode 100644 index 0000000000..12471cce28 --- /dev/null +++ b/content/en/examples/security/podsecurity-privileged.yaml @@ -0,0 +1,7 @@ +apiVersion: v1 +kind: Namespace +metadata: + name: my-privileged-namespace + labels: + pod-security.kubernetes.io/enforce: privileged + pod-security.kubernetes.io/enforce-version: latest \ No newline at end of file diff --git a/content/en/examples/security/podsecurity-restricted.yaml b/content/en/examples/security/podsecurity-restricted.yaml new file mode 100644 index 0000000000..8b9c30886d --- /dev/null +++ b/content/en/examples/security/podsecurity-restricted.yaml @@ -0,0 +1,9 @@ +apiVersion: v1 +kind: Namespace +metadata: + name: my-restricted-namespace + labels: + pod-security.kubernetes.io/enforce: restricted + pod-security.kubernetes.io/enforce-version: latest + pod-security.kubernetes.io/warn: restricted + pod-security.kubernetes.io/warn-version: latest \ No newline at end of file diff --git a/content/en/examples/service/networking/namespaced-params.yaml b/content/en/examples/service/networking/namespaced-params.yaml new file mode 100644 index 0000000000..dd56724787 --- /dev/null +++ b/content/en/examples/service/networking/namespaced-params.yaml @@ -0,0 +1,12 @@ +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + name: external-lb +spec: + controller: example.com/ingress-controller + parameters: + apiGroup: k8s.example.com + kind: IngressParameters + name: external-lb + namespace: external-configuration + scope: Namespace diff --git a/content/en/includes/task-tutorial-prereqs.md b/content/en/includes/task-tutorial-prereqs.md index 93195d8b9c..b5d3c0abf3 100644 --- a/content/en/includes/task-tutorial-prereqs.md +++ b/content/en/includes/task-tutorial-prereqs.md @@ -1,7 +1,7 @@ You need to have a Kubernetes cluster, and the kubectl command-line tool must -be configured to communicate with your cluster. If you do not already have a +be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using -[minikube](/docs/tasks/tools/#minikube) +[minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/) or you can use one of these Kubernetes playgrounds: * [Katacoda](https://www.katacoda.com/courses/kubernetes/playground) diff --git a/content/en/releases/OWNERS b/content/en/releases/OWNERS new file mode 100644 index 0000000000..25d2d0a271 --- /dev/null +++ b/content/en/releases/OWNERS @@ -0,0 +1,17 @@ +# See the OWNERS docs at https://go.k8s.io/owners + +# This is the directory for English source content. +# Teams and members are visible at https://github.com/orgs/kubernetes/teams. + +reviewers: + - sig-docs-en-reviews + - release-engineering-reviewers + +approvers: + - sig-docs-en-owners + - sig-release-leads + - release-engineering-approvers + +labels: +- sig/release +- area/release-eng diff --git a/content/en/releases/_index.md b/content/en/releases/_index.md new file mode 100644 index 0000000000..af7819a0c1 --- /dev/null +++ b/content/en/releases/_index.md @@ -0,0 +1,27 @@ +--- +linktitle: Release History +title: Releases +type: docs +--- + + + + +The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support. + +Kubernetes versions are expressed as **x.y.z**, +where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology. + +More information in the [version skew policy](/releases/version-skew-policy/) document. + + + +## Release History + +{{< release-data >}} + +## Upcoming Release + +Check out the [schedule](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}}) for the upcoming **{{< skew nextMinorVersion >}}** Kubernetes release! + +## Helpful Resources \ No newline at end of file diff --git a/content/en/releases/download.md b/content/en/releases/download.md new file mode 100644 index 0000000000..aa1fca98a4 --- /dev/null +++ b/content/en/releases/download.md @@ -0,0 +1,26 @@ +--- +title: Download Kubernetes +type: docs +--- +## Core Kubernetes components + +Find links to download Kubernetes components (and their checksums) in the [CHANGELOG](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) files. + +Alternately, use [downloadkubernetes.com](https://www.downloadkubernetes.com/) to filter by version and architecture. + +## kubectl + + +The Kubernetes command-line tool, [kubectl](/docs/reference/kubectl/kubectl/), allows +you to run commands against Kubernetes clusters. + +You can use kubectl to deploy applications, inspect and manage cluster resources, +and view logs. For more information including a complete list of kubectl operations, see the +[`kubectl` reference documentation](/docs/reference/kubectl/). + +kubectl is installable on a variety of Linux platforms, macOS and Windows. +Find your preferred operating system below. + +- [Install kubectl on Linux](/docs/tasks/tools/install-kubectl-linux) +- [Install kubectl on macOS](/docs/tasks/tools/install-kubectl-macos) +- [Install kubectl on Windows](/docs/tasks/tools/install-kubectl-windows) \ No newline at end of file diff --git a/content/en/releases/notes.md b/content/en/releases/notes.md new file mode 100644 index 0000000000..3ad20944b2 --- /dev/null +++ b/content/en/releases/notes.md @@ -0,0 +1,13 @@ +--- +linktitle: Release Notes +title: Notes +type: docs +description: > + Kubernetes release notes. +sitemap: + priority: 0.5 +--- + +Release notes can be found by reading the [Changelog](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) that matches your Kubernetes version. View the changelog for {{< skew latestVersion >}} on [GitHub](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew latestVersion >}}.md). + +Alternately, release notes can be searched and filtered online at: [relnotes.k8s.io](https://relnotes.k8s.io). View filtered release notes for {{< skew latestVersion >}} on [relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew latestVersion >}}.0). diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md new file mode 100644 index 0000000000..91bd47bcd0 --- /dev/null +++ b/content/en/releases/patch-releases.md @@ -0,0 +1,188 @@ +--- +title: Patch Releases +type: docs +--- + +Schedule and team contact information for Kubernetes patch releases. + +For general information about Kubernetes release cycle, see the +[release process description]. + +## Cadence + +Our typical patch release cadence is monthly. It is +commonly a bit faster (1 to 2 weeks) for the earliest patch releases +after a 1.X minor release. Critical bug fixes may cause a more +immediate release outside of the normal cadence. We also aim to not make +releases during major holiday periods. + +## Contact + +See the [Release Managers page][release-managers] for full contact details on the Patch Release Team. + +Please give us a business day to respond - we may be in a different timezone! + +In between releases the team is looking at incoming cherry pick +requests on a weekly basis. The team will get in touch with +submitters via GitHub PR, SIG channels in Slack, and direct messages +in Slack and [email](mailto:release-managers-private@kubernetes.io) +if there are questions on the PR. + +## Cherry picks + +Please follow the [cherry pick process][cherry-picks]. + +Cherry picks must be merge-ready in GitHub with proper labels (e.g., +`approved`, `lgtm`, `release-note`) and passing CI tests ahead of the +cherry pick deadline. This is typically two days before the target +release, but may be more. Earlier PR readiness is better, as we +need time to get CI signal after merging your cherry picks ahead +of the actual release. + +Cherry pick PRs which miss merge criteria will be carried over and tracked +for the next patch release. + +## Support Period + +In accordance with the [yearly support KEP][yearly-support], the Kubernetes +Community will support active patch release series for a period of roughly +fourteen (14) months. + +The first twelve months of this timeframe will be considered the standard +period. + +Towards the end of the twelve month, the following will happen: + +- [Release Managers][release-managers] will cut a release +- The patch release series will enter maintenance mode + +During the two-month maintenance mode period, Release Managers may cut +additional maintenance releases to resolve: + +- CVEs (under the advisement of the Security Response Committee) +- dependency issues (including base image updates) +- critical core component issues + +At the end of the two-month maintenance mode period, the patch release series +will be considered EOL (end of life) and cherry picks to the associated branch +are to be closed soon afterwards. + +Note that the 28th of the month was chosen for maintenance mode and EOL target +dates for simplicity (every month has it). + +## Upcoming Monthly Releases + +Timelines may vary with the severity of bug fixes, but for easier planning we +will target the following monthly release points. Unplanned, critical +releases may also occur in between these. + +| Monthly Patch Release | Cherry Pick Deadline | Target date | +| --------------------- | -------------------- | ----------- | +| October 2021 | 2021-10-15 | 2021-10-20 | +| November 2021 | 2021-11-12 | 2021-11-17 | +| December 2021 | 2021-12-10 | 2021-12-15 | +| January 2022 | 2021-01-14 | 2021-01-19 | + +## Detailed Release History for Active Branches + +### 1.22 + +**1.22** enters maintenance mode on **2022-08-28** + +End of Life for **1.22** is **2022-10-28** + +| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE | +|---------------|----------------------|-------------|------| +| 1.22.3 | 2021-10-15 | 2021-10-20 | | +| 1.22.2 | 2021-09-10 | 2021-09-15 | | +| 1.22.1 | 2021-08-16 | 2021-08-19 | | + +### 1.21 + +**1.21** enters maintenance mode on **2022-04-28** + +End of Life for **1.21** is **2022-06-28** + +| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE | +| ------------- | -------------------- | ----------- | ---------------------------------------------------------------------- | +| 1.21.6 | 2021-10-15 | 2021-10-20 | | +| 1.21.5 | 2021-09-10 | 2021-09-15 | | +| 1.21.4 | 2021-08-07 | 2021-08-11 | | +| 1.21.3 | 2021-07-10 | 2021-07-14 | | +| 1.21.2 | 2021-06-12 | 2021-06-16 | | +| 1.21.1 | 2021-05-07 | 2021-05-12 | [Regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs) | + +### 1.20 + +**1.20** enters maintenance mode on **2021-12-28** + +End of Life for **1.20** is **2022-02-28** + +| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE | +| ------------- | -------------------- | ----------- | ----------------------------------------------------------------------------------- | +| 1.20.12 | 2021-10-15 | 2021-10-20 | | +| 1.20.11 | 2021-09-10 | 2021-09-15 | | +| 1.20.10 | 2021-08-07 | 2021-08-11 | | +| 1.20.9 | 2021-07-10 | 2021-07-14 | | +| 1.20.8 | 2021-06-12 | 2021-06-16 | | +| 1.20.7 | 2021-05-07 | 2021-05-12 | [Regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs) | +| 1.20.6 | 2021-04-09 | 2021-04-14 | | +| 1.20.5 | 2021-03-12 | 2021-03-17 | | +| 1.20.4 | 2021-02-12 | 2021-02-18 | | +| 1.20.3 | 2021-02-12 | 2021-02-17 | [Conformance Tests Issue](https://groups.google.com/g/kubernetes-dev/c/oUpY9vWgzJo) | +| 1.20.2 | 2021-01-08 | 2021-01-13 | | +| 1.20.1 | 2020-12-11 | 2020-12-18 | [Tagging Issue](https://groups.google.com/g/kubernetes-dev/c/dNH2yknlCBA) | + +### 1.19 + +**1.19** enters maintenance mode on **2021-08-28** + +End of Life for **1.19** is **2021-10-28** + +| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE | +| ------------- | -------------------- | ----------- | ------------------------------------------------------------------------- | +| 1.19.15 | 2021-09-10 | 2021-09-15 | | +| 1.19.14 | 2021-08-07 | 2021-08-11 | | +| 1.19.13 | 2021-07-10 | 2021-07-14 | | +| 1.19.12 | 2021-06-12 | 2021-06-16 | | +| 1.19.11 | 2021-05-07 | 2021-05-12 | [Regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs) | +| 1.19.10 | 2021-04-09 | 2021-04-14 | | +| 1.19.9 | 2021-03-12 | 2021-03-17 | | +| 1.19.8 | 2021-02-12 | 2021-02-17 | | +| 1.19.7 | 2021-01-08 | 2021-01-13 | | +| 1.19.6 | 2020-12-11 | 2020-12-18 | [Tagging Issue](https://groups.google.com/g/kubernetes-dev/c/dNH2yknlCBA) | +| 1.19.5 | 2020-12-04 | 2020-12-09 | | +| 1.19.4 | 2020-11-06 | 2020-11-11 | | +| 1.19.3 | 2020-10-09 | 2020-10-14 | | +| 1.19.2 | 2020-09-11 | 2020-09-16 | | +| 1.19.1 | 2020-09-04 | 2020-09-09 | | + +## Non-Active Branch History + +These releases are no longer supported. + +| MINOR VERSION | FINAL PATCH RELEASE | EOL DATE | NOTE | +| ------------- | ------------------- | ---------- | ---------------------------------------------------------------------- | +| 1.18 | 1.18.20 | 2021-06-18 | Created to resolve regression introduced in 1.18.19 | +| 1.18 | 1.18.19 | 2021-05-12 | [Regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs) | +| 1.17 | 1.17.17 | 2021-01-13 | | +| 1.16 | 1.16.15 | 2020-09-02 | | +| 1.15 | 1.15.12 | 2020-05-06 | | +| 1.14 | 1.14.10 | 2019-12-11 | | +| 1.13 | 1.13.12 | 2019-10-15 | | +| 1.12 | 1.12.10 | 2019-07-08 | | +| 1.11 | 1.11.10 | 2019-05-01 | | +| 1.10 | 1.10.13 | 2019-02-13 | | +| 1.9 | 1.9.11 | 2018-09-29 | | +| 1.8 | 1.8.15 | 2018-07-12 | | +| 1.7 | 1.7.16 | 2018-04-04 | | +| 1.6 | 1.6.13 | 2017-11-23 | | +| 1.5 | 1.5.8 | 2017-10-01 | | +| 1.4 | 1.4.12 | 2017-04-21 | | +| 1.3 | 1.3.10 | 2016-11-01 | | +| 1.2 | 1.2.7 | 2016-10-23 | | + +[cherry-picks]: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md +[release-managers]: /releases/release-managers +[release process description]: /releases/release +[yearly-support]: https://git.k8s.io/enhancements/keps/sig-release/1498-kubernetes-yearly-support-period/README.md diff --git a/content/en/releases/release-managers.md b/content/en/releases/release-managers.md new file mode 100644 index 0000000000..cf7f7b6eea --- /dev/null +++ b/content/en/releases/release-managers.md @@ -0,0 +1,218 @@ +--- +title: Release Managers +type: docs +--- + +"Release Managers" is an umbrella term that encompasses the set of Kubernetes +contributors responsible for maintaining release branches, tagging releases, +and building/packaging Kubernetes. + +The responsibilities of each role are described below. + +- [Contact](#contact) + - [Security Embargo Policy](#security-embargo-policy) +- [Handbooks](#handbooks) +- [Release Managers](#release-managers) + - [Becoming a Release Manager](#becoming-a-release-manager) +- [Release Manager Associates](#release-manager-associates) + - [Becoming a Release Manager Associate](#becoming-a-release-manager-associate) +- [Build Admins](#build-admins) +- [SIG Release Leads](#sig-release-leads) + - [Chairs](#chairs) + - [Technical Leads](#technical-leads) + +## Contact + +| Mailing List | Slack | Visibility | Usage | Membership | +| --- | --- | --- | --- | --- | +| [release-managers@kubernetes.io](mailto:release-managers@kubernetes.io) | [#release-management](https://kubernetes.slack.com/messages/CJH2GBF7Y) (channel) / @release-managers (user group) | Public | Public discussion for Release Managers | All Release Managers (including Associates, Build Admins, and SIG Chairs) | +| [release-managers-private@kubernetes.io](mailto:release-managers-private@kubernetes.io) | N/A | Private | Private discussion for privileged Release Managers | Release Managers, SIG Release leadership | +| [security-release-team@kubernetes.io](mailto:security-release-team@kubernetes.io) | [#security-release-team](https://kubernetes.slack.com/archives/G0162T1RYHG) (channel) / @security-rel-team (user group) | Private | Security release coordination with the Security Response Committee | [security-discuss-private@kubernetes.io](mailto:security-discuss-private@kubernetes.io), [release-managers-private@kubernetes.io](mailto:release-managers-private@kubernetes.io) | + +### Security Embargo Policy + +Some information about releases is subject to embargo and we have defined policy about how those embargoes are set. Please refer to the [Security Embargo Policy](https://github.com/kubernetes/committee-security-response/blob/main/private-distributors-list.md#embargo-policy) for more information. + +## Handbooks + +**NOTE: The Patch Release Team and Branch Manager handbooks will be de-duplicated at a later date.** + +- [Patch Release Team][handbook-patch-release] +- [Branch Managers][handbook-branch-mgmt] +- [Build Admins][handbook-packaging] + +## Release Managers + +**Note:** The documentation might refer to the Patch Release Team and the +Branch Management role. Those two roles were consolidated into the +Release Managers role. + +Minimum requirements for Release Managers and Release Manager Associates are: + +- Familiarity with basic Unix commands and able to debug shell scripts. +- Familiarity with branched source code workflows via `git` and associated + `git` command line invocations. +- General knowledge of Google Cloud (Cloud Build and Cloud Storage). +- Open to seeking help and communicating clearly. +- Kubernetes Community [membership][community-membership] + +Release Managers are responsible for: + +- Coordinating and cutting Kubernetes releases: + - Patch releases (`x.y.z`, where `z` > 0) + - Minor releases (`x.y.z`, where `z` = 0) + - Pre-releases (alpha, beta, and release candidates) + - Working with the [Release Team][release-team] through each + release cycle + - Setting the [schedule and cadence for patch releases][patches] +- Maintaining the release branches: + - Reviewing cherry picks + - Ensuring the release branch stays healthy and that no unintended patch + gets merged +- Mentoring the [Release Manager Associates](#associates) group +- Actively developing features and maintaining the code in k/release +- Supporting Release Manager Associates and contributors through actively + participating in the Buddy program + - Check in monthly with Associates and delegate tasks, empower them to cut + releases, and mentor + - Being available to support Associates in onboarding new contributors e.g., + answering questions and suggesting appropriate work for them to do + +This team at times works in close conjunction with the +[Security Response Committee][src] and therefore should abide by the guidelines +set forth in the [Security Release Process][security-release-process]. + +GitHub Access Controls: [@kubernetes/release-managers](https://github.com/orgs/kubernetes/teams/release-managers) + +GitHub Mentions: [@kubernetes/release-engineering](https://github.com/orgs/kubernetes/teams/release-engineering) + +- Adolfo García Veytia ([@puerco](https://github.com/puerco)) +- Carlos Panato ([@cpanato](https://github.com/cpanato)) +- Marko Mudrinić ([@xmudrii](https://github.com/xmudrii)) +- Sascha Grunert ([@saschagrunert](https://github.com/saschagrunert)) +- Stephen Augustus ([@justaugustus](https://github.com/justaugustus)) +- Verónica López ([@verolop](https://github.com/verolop)) + +### Becoming a Release Manager + +To become a Release Manager, one must first serve as a Release Manager +Associate. Associates graduate to Release Manager by actively working on +releases over several cycles and: + +- demonstrating the willingness to lead +- tag-teaming with Release Managers on patches, to eventually cut a release + independently + - because releases have a limiting function, we also consider substantial + contributions to image promotion and other core Release Engineering tasks +- questioning how Associates work, suggesting improvements, gathering feedback, + and driving change +- being reliable and responsive +- leaning into advanced work that requires Release Manager-level access and + privileges to complete + +## Release Manager Associates + +Release Manager Associates are apprentices to the Release Managers, formerly +referred to as Release Manager shadows. They are responsible for: + +- Patch release work, cherry pick review +- Contributing to k/release: updating dependencies and getting used to the + source codebase +- Contributing to the documentation: maintaining the handbooks, ensuring that + release processes are documented +- With help from a release manager: working with the Release Team during the + release cycle and cutting Kubernetes releases +- Seeking opportunities to help with prioritization and communication + - Sending out pre-announcements and updates about patch releases + - Updating the calendar, helping with the release dates and milestones from + the [release cycle timeline][k-sig-release-releases] +- Through the Buddy program, onboarding new contributors and pairing up with + them on tasks + +GitHub Mentions: @kubernetes/release-engineering + +- Arnaud Meukam ([@ameukam](https://github.com/ameukam)) +- Jim Angel ([@jimangel](https://github.com/jimangel)) +- Joyce Kung ([@thejoycekung](https://github.com/thejoycekung)) +- Max Körbächer ([@mkorbi](https://github.com/mkorbi)) +- Nabarun Pal ([@palnabarun](https://github.com/palnabarun)) +- Seth McCombs ([@sethmccombs](https://github.com/sethmccombs)) +- Taylor Dolezal ([@onlydole](https://github.com/onlydole)) +- Wilson Husin ([@wilsonehusin](https://github.com/wilsonehusin)) + +### Becoming a Release Manager Associate + +Contributors can become Associates by demonstrating the following: + +- consistent participation, including 6-12 months of active release + engineering-related work +- experience fulfilling a technical lead role on the Release Team during a + release cycle + - this experience provides a solid baseline for understanding how SIG Release + works overall—including our expectations regarding technical skills, + communications/responsiveness, and reliability +- working on k/release items that improve our interactions with Testgrid, + cleaning up libraries, etc. + - these efforts require interacting and pairing with Release Managers and + Associates + +## Build Admins + +Build Admins are (currently) Google employees with the requisite access to +Google build systems/tooling to publish deb/rpm packages on behalf of the +Kubernetes project. They are responsible for: + +- Building, signing, and publishing the deb/rpm packages +- Being the interlock with Release Managers (and Associates) on the final steps +of each minor (1.Y) and patch (1.Y.Z) release + +GitHub team: [@kubernetes/build-admins](https://github.com/orgs/kubernetes/teams/build-admins) + +- Aaron Crickenberger ([@spiffxp](https://github.com/spiffxp)) +- Amit Watve ([@amwat](https://github.com/amwat)) +- Benjamin Elder ([@BenTheElder](https://github.com/BenTheElder)) +- Grant McCloskey ([@MushuEE](https://github.com/MushuEE)) + +## SIG Release Leads + +SIG Release Chairs and Technical Leads are responsible for: + +- The governance of SIG Release +- Leading knowledge exchange sessions for Release Managers and Associates +- Coaching on leadership and prioritization + +They are mentioned explicitly here as they are owners of the various +communications channels and permissions groups (GitHub teams, GCP access) for +each role. As such, they are highly privileged community members and privy to +some private communications, which can at times relate to Kubernetes security +disclosures. + +GitHub team: [@kubernetes/sig-release-leads](https://github.com/orgs/kubernetes/teams/sig-release-leads) + +### Chairs + +- Sascha Grunert ([@saschagrunert](https://github.com/saschagrunert)) +- Stephen Augustus ([@justaugustus](https://github.com/justaugustus)) + +### Technical Leads + +- Adolfo García Veytia ([@puerco](https://github.com/puerco)) +- Carlos Panato ([@cpanato](https://github.com/cpanato)) +- Jeremy Rickard ([@jeremyrickard](https://github.com/jeremyrickard)) + +--- + +Past Branch Managers, can be found in the [releases directory][k-sig-release-releases] +of the kubernetes/sig-release repository within `release-x.y/release_team.md`. + +Example: [1.15 Release Team](https://git.k8s.io/sig-release/releases/release-1.15/release_team.md) + +[community-membership]: https://git.k8s.io/community/community-membership.md#member +[handbook-branch-mgmt]: https://git.k8s.io/sig-release/release-engineering/role-handbooks/branch-manager.md +[handbook-packaging]: https://git.k8s.io/sig-release/release-engineering/packaging.md +[handbook-patch-release]: https://git.k8s.io/sig-release/release-engineering/role-handbooks/patch-release-team.md +[k-sig-release-releases]: https://git.k8s.io/sig-release/releases +[patches]: /patch-releases.md +[src]: https://git.k8s.io/community/committee-product-security/README.md +[release-team]: https://git.k8s.io/sig-release/release-team/README.md +[security-release-process]: https://git.k8s.io/security/security-release-process.md diff --git a/content/en/releases/release.md b/content/en/releases/release.md new file mode 100644 index 0000000000..5542b41202 --- /dev/null +++ b/content/en/releases/release.md @@ -0,0 +1,365 @@ +--- +title: Kubernetes Release Cycle +type: docs +auto_generated: true +--- + + + +{{< warning >}} +This content is auto-generated and links may not function. The source of the document is located [here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md). +{{< /warning >}} + +# Targeting enhancements, Issues and PRs to Release Milestones + +This document is focused on Kubernetes developers and contributors who need to +create an enhancement, issue, or pull request which targets a specific release +milestone. + +- [TL;DR](#tldr) + - [Normal Dev (Weeks 1-8)](#normal-dev-weeks-1-8) + - [Code Freeze (Weeks 9-11)](#code-freeze-weeks-9-11) + - [Post-Release (Weeks 11+)](#post-release-weeks-11) +- [Definitions](#definitions) +- [The Release Cycle](#the-release-cycle) +- [Removal Of Items From The Milestone](#removal-of-items-from-the-milestone) +- [Adding An Item To The Milestone](#adding-an-item-to-the-milestone) + - [Milestone Maintainers](#milestone-maintainers) + - [Feature additions](#feature-additions) + - [Issue additions](#issue-additions) + - [PR Additions](#pr-additions) +- [Other Required Labels](#other-required-labels) + - [SIG Owner Label](#sig-owner-label) + - [Priority Label](#priority-label) + - [Issue/PR Kind Label](#issuepr-kind-label) + +The process for shepherding enhancements, issues, and pull requests into a +Kubernetes release spans multiple stakeholders: + +- the enhancement, issue, and pull request owner(s) +- SIG leadership +- the [Release Team][release-team] + +Information on workflows and interactions are described below. + +As the owner of an enhancement, issue, or pull request (PR), it is your +responsibility to ensure release milestone requirements are met. Automation and +the Release Team will be in contact with you if updates are required, but +inaction can result in your work being removed from the milestone. Additional +requirements exist when the target milestone is a prior release (see +[cherry pick process][cherry-picks] for more information). + +## TL;DR + +If you want your PR to get merged, it needs the following required labels and +milestones, represented here by the Prow /commands it would take to add them: + +### Normal Dev (Weeks 1-8) + +- /sig {name} +- /kind {type} +- /lgtm +- /approved + +### [Code Freeze][code-freeze] (Weeks 9-11) + +- /milestone {v1.y} +- /sig {name} +- /kind {bug, failing-test} +- /lgtm +- /approved + +### Post-Release (Weeks 11+) + +Return to 'Normal Dev' phase requirements: + +- /sig {name} +- /kind {type} +- /lgtm +- /approved + +Merges into the 1.y branch are now [via cherry picks][cherry-picks], approved +by [Release Managers][release-managers]. + +In the past, there was a requirement for a milestone-targeted pull requests to +have an associated GitHub issue opened, but this is no longer the case. +Features or enhancements are effectively GitHub issues or [KEPs][keps] which +lead to subsequent PRs. + +The general labeling process should be consistent across artifact types. + +## Definitions + +- _issue owners_: Creator, assignees, and user who moved the issue into a + release milestone + +- _Release Team_: Each Kubernetes release has a team doing project management + tasks described [here][release-team]. + + The contact info for the team associated with any given release can be found + [here](https://git.k8s.io/sig-release/releases/). + +- _Y days_: Refers to business days + +- _enhancement_: see "[Is My Thing an Enhancement?](https://git.k8s.io/enhancements/README.md#is-my-thing-an-enhancement)" + +- _[Enhancements Freeze][enhancements-freeze]_: + the deadline by which [KEPs][keps] have to be completed in order for + enhancements to be part of the current release + +- _[Exception Request][exceptions]_: + The process of requesting an extension on the deadline for a particular + Enhancement + +- _[Code Freeze][code-freeze]_: + The period of ~4 weeks before the final release date, during which only + critical bug fixes are merged into the release. + +- _[Pruning](https://git.k8s.io/sig-release/releases/release_phases.md#pruning)_: + The process of removing an Enhancement from a release milestone if it is not + fully implemented or is otherwise considered not stable. + +- _release milestone_: semantic version string or + [GitHub milestone](https://help.github.com/en/github/managing-your-work-on-github/associating-milestones-with-issues-and-pull-requests) + referring to a release MAJOR.MINOR `vX.Y` version. + + See also + [release versioning](/contributors/design-proposals/release/versioning.md). + +- _release branch_: Git branch `release-X.Y` created for the `vX.Y` milestone. + + Created at the time of the `vX.Y-rc.0` release and maintained after the + release for approximately 12 months with `vX.Y.Z` patch releases. + + Note: releases 1.19 and newer receive 1 year of patch release support, and + releases 1.18 and earlier received 9 months of patch release support. + +## The Release Cycle + +![Image of one Kubernetes release cycle](release-cycle.png) + +Kubernetes releases currently happen approximately four times per year. + +The release process can be thought of as having three main phases: + +- Enhancement Definition +- Implementation +- Stabilization + +But in reality, this is an open source and agile project, with feature planning +and implementation happening at all times. Given the project scale and globally +distributed developer base, it is critical to project velocity to not rely on a +trailing stabilization phase and rather have continuous integration testing +which ensures the project is always stable so that individual commits can be +flagged as having broken something. + +With ongoing feature definition through the year, some set of items will bubble +up as targeting a given release. **[Enhancements Freeze][enhancements-freeze]** +starts ~4 weeks into release cycle. By this point all intended feature work for +the given release has been defined in suitable planning artifacts in +conjunction with the Release Team's [Enhancements Lead](https://git.k8s.io/sig-release/release-team/role-handbooks/enhancements/README.md). + +After Enhancements Freeze, tracking milestones on PRs and issues is important. +Items within the milestone are used as a punchdown list to complete the +release. _On issues_, milestones must be applied correctly, via triage by the +SIG, so that [Release Team][release-team] can track bugs and enhancements (any +enhancement-related issue needs a milestone). + +There is some automation in place to help automatically assign milestones to +PRs. + +This automation currently applies to the following repos: + +- `kubernetes/enhancements` +- `kubernetes/kubernetes` +- `kubernetes/release` +- `kubernetes/sig-release` +- `kubernetes/test-infra` + +At creation time, PRs against the `master` branch need humans to hint at which +milestone they might want the PR to target. Once merged, PRs against the +`master` branch have milestones auto-applied so from that time onward human +management of that PR's milestone is less necessary. On PRs against release +branches, milestones are auto-applied when the PR is created so no human +management of the milestone is ever necessary. + +Any other effort that should be tracked by the Release Team that doesn't fall +under that automation umbrella should be have a milestone applied. + +Implementation and bug fixing is ongoing across the cycle, but culminates in a +code freeze period. + +**[Code Freeze][code-freeze]** starts in week ~10 and continues for ~2 weeks. +Only critical bug fixes are accepted into the release codebase during this +time. + +There are approximately two weeks following Code Freeze, and preceding release, +during which all remaining critical issues must be resolved before release. +This also gives time for documentation finalization. + +When the code base is sufficiently stable, the master branch re-opens for +general development and work begins there for the next release milestone. Any +remaining modifications for the current release are cherry picked from master +back to the release branch. The release is built from the release branch. + +Each release is part of a broader Kubernetes lifecycle: + +![Image of Kubernetes release lifecycle spanning three releases](release-lifecycle.png) + +## Removal Of Items From The Milestone + +Before getting too far into the process for adding an item to the milestone, +please note: + +Members of the [Release Team][release-team] may remove issues from the +milestone if they or the responsible SIG determine that the issue is not +actually blocking the release and is unlikely to be resolved in a timely +fashion. + +Members of the Release Team may remove PRs from the milestone for any of the +following, or similar, reasons: + +- PR is potentially de-stabilizing and is not needed to resolve a blocking + issue +- PR is a new, late feature PR and has not gone through the enhancements + process or the [exception process][exceptions] +- There is no responsible SIG willing to take ownership of the PR and resolve + any follow-up issues with it +- PR is not correctly labelled +- Work has visibly halted on the PR and delivery dates are uncertain or late + +While members of the Release Team will help with labelling and contacting +SIG(s), it is the responsibility of the submitter to categorize PRs, and to +secure support from the relevant SIG to guarantee that any breakage caused by +the PR will be rapidly resolved. + +Where additional action is required, an attempt at human to human escalation +will be made by the Release Team through the following channels: + +- Comment in GitHub mentioning the SIG team and SIG members as appropriate for + the issue type +- Emailing the SIG mailing list + - bootstrapped with group email addresses from the + [community sig list][sig-list] + - optionally also directly addressing SIG leadership or other SIG members +- Messaging the SIG's Slack channel + - bootstrapped with the slackchannel and SIG leadership from the + [community sig list][sig-list] + - optionally directly "@" mentioning SIG leadership or others by handle + +## Adding An Item To The Milestone + +### Milestone Maintainers + +The members of the [`milestone-maintainers`](https://github.com/orgs/kubernetes/teams/milestone-maintainers/members) +GitHub team are entrusted with the responsibility of specifying the release +milestone on GitHub artifacts. + +This group is [maintained](https://git.k8s.io/sig-release/release-team/README.md#milestone-maintainers) +by SIG Release and has representation from the various SIGs' leadership. + +### Feature additions + +Feature planning and definition takes many forms today, but a typical example +might be a large piece of work described in a [KEP][keps], with associated task +issues in GitHub. When the plan has reached an implementable state and work is +underway, the enhancement or parts thereof are targeted for an upcoming milestone +by creating GitHub issues and marking them with the Prow "/milestone" command. + +For the first ~4 weeks into the release cycle, the Release Team's Enhancements +Lead will interact with SIGs and feature owners via GitHub, Slack, and SIG +meetings to capture all required planning artifacts. + +If you have an enhancement to target for an upcoming release milestone, begin a +conversation with your SIG leadership and with that release's Enhancements +Lead. + +### Issue additions + +Issues are marked as targeting a milestone via the Prow "/milestone" command. + +The Release Team's [Bug Triage Lead](https://git.k8s.io/sig-release/release-team/role-handbooks/bug-triage/README.md) +and overall community watch incoming issues and triage them, as described in +the contributor guide section on +[issue triage](/contributors/guide/issue-triage.md). + +Marking issues with the milestone provides the community better visibility +regarding when an issue was observed and by when the community feels it must be +resolved. During [Code Freeze][code-freeze], a milestone must be set to merge +a PR. + +An open issue is no longer required for a PR, but open issues and associated +PRs should have synchronized labels. For example a high priority bug issue +might not have its associated PR merged if the PR is only marked as lower +priority. + +### PR Additions + +PRs are marked as targeting a milestone via the Prow "/milestone" command. + +This is a blocking requirement during Code Freeze as described above. + +## Other Required Labels + +[Here is the list of labels and their use and purpose.](https://git.k8s.io/test-infra/label_sync/labels.md#labels-that-apply-to-all-repos-for-both-issues-and-prs) + +### SIG Owner Label + +The SIG owner label defines the SIG to which we escalate if a milestone issue +is languishing or needs additional attention. If there are no updates after +escalation, the issue may be automatically removed from the milestone. + +These are added with the Prow "/sig" command. For example to add the label +indicating SIG Storage is responsible, comment with `/sig storage`. + +### Priority Label + +Priority labels are used to determine an escalation path before moving issues +out of the release milestone. They are also used to determine whether or not a +release should be blocked on the resolution of the issue. + +- `priority/critical-urgent`: Never automatically move out of a release + milestone; continually escalate to contributor and SIG through all available + channels. + - considered a release blocking issue + - requires daily updates from issue owners during [Code Freeze][code-freeze] + - would require a patch release if left undiscovered until after the minor + release +- `priority/important-soon`: Escalate to the issue owners and SIG owner; move + out of milestone after several unsuccessful escalation attempts. + - not considered a release blocking issue + - would not require a patch release + - will automatically be moved out of the release milestone at Code Freeze + after a 4 day grace period +- `priority/important-longterm`: Escalate to the issue owners; move out of the + milestone after 1 attempt. + - even less urgent / critical than `priority/important-soon` + - moved out of milestone more aggressively than `priority/important-soon` + +### Issue/PR Kind Label + +The issue kind is used to help identify the types of changes going into the +release over time. This may allow the Release Team to develop a better +understanding of what sorts of issues we would miss with a faster release +cadence. + +For release targeted issues, including pull requests, one of the following +issue kind labels must be set: + +- `kind/api-change`: Adds, removes, or changes an API +- `kind/bug`: Fixes a newly discovered bug. +- `kind/cleanup`: Adding tests, refactoring, fixing old bugs. +- `kind/design`: Related to design +- `kind/documentation`: Adds documentation +- `kind/failing-test`: CI test case is failing consistently. +- `kind/feature`: New functionality. +- `kind/flake`: CI test case is showing intermittent failures. + +[cherry-picks]: /community/blob/master/contributors/devel/sig-release/cherry-picks.md +[code-freeze]: https://git.k8s.io/sig-release/releases/release_phases.md#code-freeze +[enhancements-freeze]: https://git.k8s.io/sig-release/releases/release_phases.md#enhancements-freeze +[exceptions]: https://git.k8s.io/sig-release/releases/release_phases.md#exceptions +[keps]: https://git.k8s.io/enhancements/keps +[release-managers]: https://git.k8s.io/sig-release/release-managers.md +[release-team]: https://git.k8s.io/sig-release/release-team +[sig-list]: /sig-list.md diff --git a/content/en/docs/setup/release/version-skew-policy.md b/content/en/releases/version-skew-policy.md similarity index 96% rename from content/en/docs/setup/release/version-skew-policy.md rename to content/en/releases/version-skew-policy.md index 68ea7aef8a..56a7afda10 100644 --- a/content/en/docs/setup/release/version-skew-policy.md +++ b/content/en/releases/version-skew-policy.md @@ -6,22 +6,21 @@ reviewers: - sig-cluster-lifecycle - sig-node - sig-release -title: Kubernetes version and version skew support policy -content_type: concept -weight: 30 +title: Version Skew Policy +type: docs +description: > + The maximum version skew supported between various Kubernetes components. --- This document describes the maximum version skew supported between various Kubernetes components. Specific cluster deployment tools may place additional restrictions on version skew. - ## Supported versions -Kubernetes versions are expressed as **x.y.z**, -where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology. +Kubernetes versions are expressed as **x.y.z**, where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology. For more information, see [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning). The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support. diff --git a/content/es/docs/concepts/_index.md b/content/es/docs/concepts/_index.md index 7dd7709bae..50da027886 100644 --- a/content/es/docs/concepts/_index.md +++ b/content/es/docs/concepts/_index.md @@ -31,18 +31,18 @@ Kubernetes tiene diferentes abstracciones que representan el estado de tu sistem Los objetos básicos de Kubernetes incluyen: -* [Pod](/docs/concepts/workloads/pods/pod-overview/) +* [Pod](/es/docs/concepts/workloads/pods/pod/) * [Service](/docs/concepts/services-networking/service/) * [Volume](/docs/concepts/storage/volumes/) -* [Namespace](/docs/concepts/overview/working-with-objects/namespaces/) +* [Namespace](/es/docs/concepts/overview/working-with-objects/namespaces/) Además, Kubernetes contiene abstracciónes de nivel superior llamadas Controladores. Los Controladores se basan en los objetos básicos y proporcionan funcionalidades adicionales sobre ellos. Incluyen: -* [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) -* [Deployment](/docs/concepts/workloads/controllers/deployment/) -* [StatefulSet](/docs/concepts/workloads/controllers/statefulset/) -* [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) -* [Job](/docs/concepts/workloads/controllers/jobs-run-to-completion/) +* [ReplicaSet](/es/docs/concepts/workloads/controllers/replicaset/) +* [Deployment](/es/docs/concepts/workloads/controllers/deployment/) +* [StatefulSet](/es/docs/concepts/workloads/controllers/statefulset/) +* [DaemonSet](/es/docs/concepts/workloads/controllers/daemonset/) +* [Job](/es/docs/concepts/workloads/controllers/jobs-run-to-completion/) ## Plano de Control de Kubernetes @@ -64,15 +64,13 @@ En un clúster de Kubernetes, los nodos son las máquinas (máquinas virtuales, #### Metadatos de los Objectos -* [Annotations](/docs/concepts/overview/working-with-objects/annotations/) +* [Annotations](/es/docs/concepts/overview/working-with-objects/annotations/) ## {{% heading "whatsnext" %}} -Si estás interesado en escribir una página sobre conceptos, -revisa [Usando Templates de Páginas](/docs/home/contribute/page-templates/) -para obtener información sobre el tipo de página conceptos y la plantilla conceptos. +Si quieres empezar a contribuir a la documentación de Kubernetes accede a la página [Empieza a contribuir](/es/docs/contribute/start/). diff --git a/content/es/docs/concepts/architecture/_index.md b/content/es/docs/concepts/architecture/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/concepts/cluster-administration/_index.md b/content/es/docs/concepts/cluster-administration/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/concepts/configuration/_index.md b/content/es/docs/concepts/configuration/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/concepts/configuration/configmap.md b/content/es/docs/concepts/configuration/configmap.md index b607f0b82d..ce16f99aca 100644 --- a/content/es/docs/concepts/configuration/configmap.md +++ b/content/es/docs/concepts/configuration/configmap.md @@ -75,7 +75,7 @@ Hay cuatro maneras diferentes de usar un ConfigMap para configurar un contenedor dentro de un {{< glossary_tooltip text="Pod" term_id="pod" >}}: 1. Argumento en la linea de comandos como entrypoint de un contenedor -1. Variable de enorno de un contenedor +1. Variable de entorno de un contenedor 1. Como fichero en un volumen de solo lectura, para que lo lea la aplicación 1. Escribir el código para ejecutar dentro de un {{< glossary_tooltip text="Pod" term_id="pod" >}} que utiliza la API para leer el ConfigMap diff --git a/content/es/docs/concepts/containers/_index.md b/content/es/docs/concepts/containers/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/concepts/containers/runtime-class.md b/content/es/docs/concepts/containers/runtime-class.md index 8c53cde87d..fa27366b35 100644 --- a/content/es/docs/concepts/containers/runtime-class.md +++ b/content/es/docs/concepts/containers/runtime-class.md @@ -134,7 +134,7 @@ de containerd en `/etc/containerd/config.toml`. Los `handlers` válidos se configuran en la sección de motores de ejecución: ``` -[plugins.cri.containerd.runtimes.${HANDLER_NAME}] +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] ``` Véase la configuración de containerd para más detalles: diff --git a/content/es/docs/concepts/overview/_index.md b/content/es/docs/concepts/overview/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/concepts/overview/object-management-kubectl/_index.md b/content/es/docs/concepts/overview/object-management-kubectl/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/concepts/overview/working-with-objects/_index.md b/content/es/docs/concepts/overview/working-with-objects/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/concepts/policy/_index.md b/content/es/docs/concepts/policy/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/concepts/services-networking/_index.md b/content/es/docs/concepts/services-networking/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/concepts/storage/_index.md b/content/es/docs/concepts/storage/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/concepts/storage/volume-snapshot-classes.md b/content/es/docs/concepts/storage/volume-snapshot-classes.md new file mode 100644 index 0000000000..497b256e67 --- /dev/null +++ b/content/es/docs/concepts/storage/volume-snapshot-classes.md @@ -0,0 +1,69 @@ +--- +reviewers: +- edithturn +- raelga +title: Volume Snapshot Classes +content_type: concept +weight: 30 +--- + + + +Este documento describe el concepto de VolumeSnapshotClass en Kubernetes. Se sugiere estar familiarizado +con [Volume Snapshots](/docs/concepts/storage/volume-snapshots/) y +[Storage Classes](/docs/concepts/storage/storage-classes). + + + + +## Introducción + +Al igual que StorageClass proporciona a los administradores una forma de describir las “clases” +de almacenamiento que ofrecen al aprovisionar un volumen, VolumeSnapshotClass proporciona una +forma de describir las “clases” de almacenamiento al aprovisionar un Snapshot de volumen. + +## El Recurso VolumeSnapshotClass + +Cada VolumeSnapshotClass contiene los campos `driver`, `deletionPolicy`, y `parameters`, +que se utilizan cuando un VolumeSnapshot que pertenece a la clase, necesita aprovisionarse dinámicamente. + +El nombre de un objeto VolumeSnapshotClass es significativo y es la forma en que los usuarios pueden solicitar una clase en particular. Los administradores establecen el nombre y parámetros de una clase cuando crean por primera vez objetos VolumeSnapshotClass; una vez creados los objetos no pueden ser actualizados. + +```yaml +apiVersion: snapshot.storage.k8s.io/v1 +kind: VolumeSnapshotClass +metadata: + name: csi-hostpath-snapclass +driver: hostpath.csi.k8s.io +deletionPolicy: Delete +parameters: +``` + +Los administradores pueden especificar un VolumeSnapshotClass predeterminado para VolumeSnapshots que no solicitan ninguna clase en particular. Para definir la clase predeterminada agregue la anotación: `snapshot.storage.kubernetes.io/is-default-class: "true"`. + +```yaml +apiVersion: snapshot.storage.k8s.io/v1 +kind: VolumeSnapshotClass +metadata: + name: csi-hostpath-snapclass + annotations: + snapshot.storage.kubernetes.io/is-default-class: "true" +driver: hostpath.csi.k8s.io +deletionPolicy: Delete +parameters: +``` + +### Driver + +Las clases de Snapshot de volumen tienen un controlador que determina que complemento de volumen CSI se utiliza para aprovisionar VolumeSnapshots. Este campo debe especificarse. + +### DeletionPolicy + +Las clases de Snapshot de volumen tienen un deletionPolicy. Permite configurar lo que sucede con un VolumeSnapshotContent cuando se va a eliminar el objeto VolumeSnapshot al que está vinculado. La deletionPolicy de una clase de Snapshot de volumen puede `Retain` o `Delete`. Este campo debe ser especificado. + +Si la deletionPolicy es `Delete`, el Snapshot de almacenamiento subyacente se eliminará junto con el objeto VolumeSnapshotContent. Si deletionPolicy es `Retain`, tanto el Snapshot subyacente como VolumeSnapshotContent permanecerán. + +### Parameters + +Las clases de Snapshot de volumen tienen parámetros que describen los Snapshots de volumen que pertenecen a la clase de Snapshot de volumen. Se pueden aceptar diferentes parámetros dependiendo del `driver`. + diff --git a/content/es/docs/concepts/storage/volume-snapshots.md b/content/es/docs/concepts/storage/volume-snapshots.md new file mode 100644 index 0000000000..dcb0417a6f --- /dev/null +++ b/content/es/docs/concepts/storage/volume-snapshots.md @@ -0,0 +1,152 @@ +--- +reviewers: +- edithturn +- raelga +- electrocucaracha +title: Snapshots de Volúmenes +content_type: concept +weight: 20 +--- + + + +En Kubernetes, un _VolumeSnapshot_ representa un Snapshot de un volumen en un sistema de almacenamiento. Este documento asume que está familiarizado con [volúmenes persistentes](/docs/concepts/storage/persistent-volumes/) de Kubernetes. + + + + + + +## Introducción + +Al igual que los recursos de API `PersistentVolume` y `PersistentVolumeClaim` se utilizan para aprovisionar volúmenes para usuarios y administradores, `VolumeSnapshotContent` y `VolumeSnapshot` se proporcionan para crear Snapshots de volumen para usuarios y administradores. + +Un `VolumeSnapshotContent` es un Snapshot tomado de un volumen en el clúster que ha sido aprovisionado por un administrador. Es un recurso en el clúster al igual que un PersistentVolume es un recurso de clúster. + +Un `VolumeSnapshot` es una solicitud de Snapshot de un volumen por parte del usuario. Es similar a un PersistentVolumeClaim. + +`VolumeSnapshotClass` permite especificar diferentes atributos que pertenecen a un `VolumeSnapshot`. Estos atributos pueden diferir entre Snapshots tomados del mismo volumen en el sistema de almacenamiento y, por lo tanto, no se pueden expresar mediante el mismo `StorageClass` de un `PersistentVolumeClaim`. + +Los Snapshots de volumen brindan a los usuarios de Kubernetes una forma estandarizada de copiar el contenido de un volumen en un momento determinado, sin crear uno completamente nuevo. Esta funcionalidad permite, por ejemplo, a los administradores de bases de datos realizar copias de seguridad de las bases de datos antes de realizar una edición o eliminar modificaciones. + +Cuando utilicen esta función los usuarios deben tener en cuenta lo siguiente: + +* Los objetos de API `VolumeSnapshot`, `VolumeSnapshotContent`, y `VolumeSnapshotClass` son {{< glossary_tooltip term_id="CustomResourceDefinition" text="CRDs" >}}, y no forman parte de la API principal. +* La compatibilidad con `VolumeSnapshot` solo está disponible para controladores CSI. +* Como parte del proceso de implementación de `VolumeSnapshot`, el equipo de Kubernetes proporciona un controlador de Snapshot para implementar en el plano de control y un sidecar auxiliar llamado csi-snapshotter para implementar junto con el controlador CSI. El controlador de Snapshot observa los objetos `VolumeSnapshot` y `VolumeSnapshotContent` y es responsable de la creación y eliminación del objeto `VolumeSnapshotContent`. El sidecar csi-snapshotter observa los objetos `VolumeSnapshotContent` y activa las operaciones `CreateSnapshot` y `DeleteSnapshot` en un punto final CSI. +* También hay un servidor webhook de validación que proporciona una validación más estricta en los objetos Snapshot. Esto debe ser instalado por las distribuciones de Kubernetes junto con el controlador de Snapshots y los CRDs, no los controladores CSI. Debe instalarse en todos los clústeres de Kubernetes que tengan habilitada la función de Snapshot. +* Los controladores CSI pueden haber implementado o no la funcionalidad de Snapshot de volumen. Los controladores CSI que han proporcionado soporte para Snapshot de volumen probablemente usarán csi-snapshotter. Consulte [CSI Driver documentation](https://kubernetes-csi.github.io/docs/) para obtener más detalles. +* Los CRDs y las instalaciones del controlador de Snapshot son responsabilidad de la distribución de Kubernetes. + +## Ciclo de vida de un Snapshot de volumen y el contenido de un Snapshot de volumen. + +`VolumeSnapshotContents` son recursos en el clúster. `VolumeSnapshots` son solicitudes de esos recursos. La interacción entre `VolumeSnapshotContents` y `VolumeSnapshots` sigue este ciclo de vida: + +### Snapshot del volumen de aprovisionamiento + +Hay dos formas de aprovisionar los Snapshots: aprovisionadas previamente o aprovisionadas dinámicamente. + +#### Pre-aprovisionado {#static} +Un administrador de clúster crea una serie de `VolumeSnapshotContents`. Llevan los detalles del Snapshot del volumen real en el sistema de almacenamiento que está disponible para que lo utilicen los usuarios del clúster. Existen en la API de Kubernetes y están disponibles para su consumo. + +#### Dinámica +En lugar de utilizar un Snapshot preexistente, puede solicitar que se tome una Snapshot dinámicamente de un PersistentVolumeClaim. El [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) especifica los parámetros específicos del proveedor de almacenamiento para usar al tomar una Snapshot. + +### Vinculante + +El controlador de Snapshots maneja el enlace de un objeto `VolumeSnapshot` con un objeto `VolumeSnapshotContent` apropiado, tanto en escenarios de aprovisionamiento previo como de aprovisionamiento dinámico. El enlace es un mapeo uno a uno. + +En el caso de un enlace aprovisionado previamente, el VolumeSnapshot permanecerá sin enlazar hasta que se cree el objeto VolumeSnapshotContent solicitado. + +### Persistent Volume Claim como Snapshot Source Protection + +El propósito de esta protección es garantizar que los objetos de la API +{{< glossary_tooltip text="PersistentVolumeClaim" term_id="persistent-volume-claim" >}} +en uso, no se eliminen del sistema mientras se toma un Snapshot (ya que esto puede resultar en la pérdida de datos). + +Mientras se toma un Snapshot de un PersistentVolumeClaim, ese PersistentVolumeClaim está en uso. Si elimina un objeto de la API PersistentVolumeClaim en uso activo como fuente de Snapshot, el objeto PersistentVolumeClaim no se elimina de inmediato. En cambio, la eliminación del objeto PersistentVolumeClaim se pospone hasta que el Snapshot esté readyToUse o se cancele. + +### Borrar + +La eliminación se activa al eliminar el objeto `VolumeSnapshot`, y se seguirá la `DeletionPolicy`. Sí `DeletionPolicy` es `Delete`, entonces el Snapshot de almacenamiento subyacente se eliminará junto con el objeto `VolumeSnapshotContent`. Sí `DeletionPolicy` es `Retain`, tanto el Snapshot subyacente como el `VolumeSnapshotContent` permanecen. + +## VolumeSnapshots + +Cada VolumeSnapshot contiene una especificación y un estado. + +```yaml +apiVersion: snapshot.storage.k8s.io/v1 +kind: VolumeSnapshot +metadata: + name: new-snapshot-test +spec: + volumeSnapshotClassName: csi-hostpath-snapclass + source: + persistentVolumeClaimName: pvc-test +``` + +`persistentVolumeClaimName` es el nombre de la fuente de datos PersistentVolumeClaim para el Snapshot. Este campo es obligatorio para aprovisionar dinámicamente un Snapshot. + +Un Snapshot de volumen puede solicitar una clase particular especificando el nombre de un [VolumeSnapshotClass](/docs/concepts/storage/volume-snapshot-classes/) +utilizando el atributo `volumeSnapshotClassName`. Si no se establece nada, se usa la clase predeterminada si está disponible. + +Para los Snapshots aprovisionadas previamente, debe especificar un `volumeSnapshotContentName` como el origen del Snapshot, como se muestra en el siguiente ejemplo. El campo de origen `volumeSnapshotContentName` es obligatorio para los Snapshots aprovisionados previamente. + +```yaml +apiVersion: snapshot.storage.k8s.io/v1 +kind: VolumeSnapshot +metadata: + name: test-snapshot +spec: + source: + volumeSnapshotContentName: test-content +``` + +## Contenido del Snapshot de volumen + +Cada VolumeSnapshotContent contiene una especificación y un estado. En el aprovisionamiento dinámico, el controlador común de Snapshots crea objetos `VolumeSnapshotContent`. Aquí hay un ejemplo: + +```yaml +apiVersion: snapshot.storage.k8s.io/v1 +kind: VolumeSnapshotContent +metadata: + name: snapcontent-72d9a349-aacd-42d2-a240-d775650d2455 +spec: + deletionPolicy: Delete + driver: hostpath.csi.k8s.io + source: + volumeHandle: ee0cfb94-f8d4-11e9-b2d8-0242ac110002 + volumeSnapshotClassName: csi-hostpath-snapclass + volumeSnapshotRef: + name: new-snapshot-test + namespace: default + uid: 72d9a349-aacd-42d2-a240-d775650d2455 +``` + +`volumeHandle` es el identificador único del volumen creado en el backend de almacenamiento y devuelto por el controlador CSI durante la creación del volumen. Este campo es obligatorio para aprovisionar dinámicamente un Snapshot. Especifica el origen del volumen del Snapshot. + +Para los Snapshots aprovisionados previamente, usted (como administrador del clúster) es responsable de crear el objeto `VolumeSnapshotContent` de la siguiente manera. + +```yaml +apiVersion: snapshot.storage.k8s.io/v1 +kind: VolumeSnapshotContent +metadata: + name: new-snapshot-content-test +spec: + deletionPolicy: Delete + driver: hostpath.csi.k8s.io + source: + snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002 + volumeSnapshotRef: + name: new-snapshot-test + namespace: default +``` + +`snapshotHandle` es el identificador único del Snapshot de volumen creado en el backend de almacenamiento. Este campo es obligatorio para las Snapshots aprovisionadas previamente. Especifica el ID del Snapshot CSI en el sistema de almacenamiento que representa el `VolumeSnapshotContent`. + +## Aprovisionamiento de Volúmenes a partir de Snapshots + +Puede aprovisionar un nuevo volumen, rellenado previamente con datos de una Snapshot, mediante el campo *dataSource* en el objeto `PersistentVolumeClaim`. + +Para obtener más detalles, consulte +[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support). diff --git a/content/es/docs/concepts/storage/volumes.md b/content/es/docs/concepts/storage/volumes.md new file mode 100644 index 0000000000..fa2f781a69 --- /dev/null +++ b/content/es/docs/concepts/storage/volumes.md @@ -0,0 +1,1246 @@ +--- +title: Volumes +content_type: concept +weight: 10 +--- + + + +Los archivos localizados dentro de un contenedor son efímeros, lo cual presenta problemas +para aplicaciones no triviales cuando se ejecutan en contenedores. Un problema es la +pérdida de archivos cuando el contenedor termina. Kubelet reinicia el contenedor con un estado limpio. +Un segundo problema ocurre cuando compartimos ficheros entre contenedores corriendo juntos dentro de un `Pod`. La abstracción {{< glossary_tooltip text="volume" term_id="volume" >}} de Kubernetes resuelve ambos problemas. +Se sugiere familiaridad con [Pods](/docs/concepts/workloads/pods/) + + + +## Trasfondo + +Docker tiene el concepto de [volúmenes](https://docs.docker.com/storage/), aunque es algo más flojo y menos controlado. +Un volumen de Docker es un directorio en disco o en otro contenedor. Docker provee controladores de volúmenes, pero la funcionalidad es algo limitada. + +Kubernetes soporta muchos tipos de volúmenes. Un {{< glossary_tooltip term_id="pod" text="Pod" >}} +puede utilizar cualquier número de tipos de volúmenes simultáneamente. Los tipos de volúmenes efímeros tienen el mismo tiempo de vida que un Pod, pero los volúmenes persistentes existen más allá del tiempo de vida de un Pod. Cuando un Pod deja de existir, +Kubernetes destruye los volúmenes efímeros; sin embargo, Kubernetes no destruye los volúmenes persistentes. Para cualquier tipo de volumen en un Pod dado, los datos son preservados a lo largo de los reinicios del contenedor. + +En su núcleo, un volumen es un directorio, posiblemente con algunos datos en este, que puede ser accesible para los contenedores en un Pod. Cómo ese directorio llega a crearse, el medio que lo respalda, y el contenido de este se determinan por el tipo de volumen usado. + +Para usar un volumen, especifica los volúmenes a proveer al por en `.spec.volumes` y declara +dónde montar estos volúmenes dentro de los contenedores en `.spec.containers[*].volumeMounts`. +Un proceso en el contenedor observa una vista del sistema de archivos compuesta por la imagen Docker y volúmenes. +La [imagen Docker](https://docs.docker.com/userguide/dockerimages/) está en la raíz de la jerarquía del sistema de archivos. +Los volúmenes se montan en las rutas especificadas dentro de la imagen. Los volúmenes no se pueden montar en otros volúmenes o tener enlaces duros a otros volúmenes. Cada contenedor en la configuración del Pod debe especificar de forma independiente donde montar cada volumen. + +## Tipos de volúmenes {#volume-types} + +Kubernetes soporta varios tipos de volúmenes + +### awsElasticBlockStore {#awselasticblockstore} + +Un volumen `awsElasticBlockStore` monta un +[volumen EBS](https://aws.amazon.com/ebs/) de Amazon Web Services (AWS) en tu Pod. A diferencia de +`emptyDir`, que se borra cuando se quita un Pod, el contenido de un volumen EBS es persistido cuando se desmonta el volumen. +Esto significa que un volumen EBS puede ser pre-poblado con datos, y que los datos puedes ser compartidos entre pods. + +{{< note >}} +Debes crear un volumen EBS usando `aws ec2 create-volume` o la API de AWS antes de poder usarlo. +{{< /note >}} + +Existen algunas restricciones cuando usas un volumen `awsElasticBlockStore`: + +- Los nodos en los que corren los pods deben ser instances AWS EC2. +- Estas instancias deben estar en la misma región y zona de disponibilidad que el volumen EBS +- EBS solo soporta una única instancia EC2 montando un volumen + +#### Creando un volumen AWS EBS + +Antes poder usar un volumen EBS en un Pod, necesitas crearlo. + +```shell +aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 +``` + +Asegúrate de que la zona coincide con la zona en que has creado el clúster. Revisa que el tamaño y el tipo de +volumen EBS son compatibles para tu uso. + +#### Ejemplo de configuración AWS EBS + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-ebs +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-ebs + name: test-volume + volumes: + - name: test-volume + # Este volumen EBS debe existir anteriormente. + awsElasticBlockStore: + volumeID: "" + fsType: ext4 +``` + +Si el volumen EBS está particionado, puedes suministrar el campo opcional `partition: ""` para especificar cuál partición montar. + +#### Migración CSI AWS EBS CSI + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + +La función `CSIMigration` para `awsElasticBlockStore`, cuando se habilita, redirige todas las operaciones +de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de `ebs.csi.aws.com`. Para utilizar esta función, el [controlador AWS EBS CSI](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) debe ser instalado en el clúster y las características beta +`CSIMigration` y `CSIMigrationAWS` deben estar habilitadas. + +#### Migración CSI AWS EBS CSI completa + +{{< feature-state for_k8s_version="v1.17" state="alpha" >}} + +Para desactivar el complemento de almacenamiento `awsElasticBlockStore` de ser cargado por el administrador de controladores y el kubelet, establece el atributo `CSIMigrationAWSComplete` a `true`. Esta función requiere tener instalado el controlador de interfaz de almacenamiento del contenedor (CSI) en todos los nodos en obreros. + +### azureDisk {#azuredisk} + +El tipo de volumen `azureDisk` monta un [Data Disk](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers) de Microsoft Azure en el Pod. + +Para más detalles, mira el [`azureDisk` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md). + +#### Migración CSI azureDisk + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + +La función `CSIMigration` para `azureDisk`, cuando se habilita, redirige todas las operaciones +de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de `disk.csi.azure.com`. Para utilizar esta función, el [controlador Azure Disk CSI](https://github.com/kubernetes-sigs/azuredisk-csi-driver) debe ser instalado en el clúster y las características beta +`CSIMigration` y `CSIMigrationAzureDisk` deben estar habilitadas. + +### azureFile {#azurefile} + +El tipo de volumen `azureFile` monta un volumen de ficheros de Microsoft Azure (SMB 2.1 and 3.0) en un Pod. + +Para más detalles, mira el [`azureFile` volume plugin](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md). + +#### Migración CSI azureFile CSI + +{{< feature-state for_k8s_version="v1.21" state="beta" >}} + +La función `CSIMigration` para `azureFile`, cuando se habilita, redirige todas las operaciones +de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de `file.csi.azure.com`. Para utilizar esta función, el [controlador Azure File CSI +Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) +debe ser instalado en el clúster y las [feature gates](/docs/reference/command-line-tools-reference/feature-gates/) `CSIMigration` y `CSIMigrationAzureFile` deben estar habilitadas. + +El controlador Azure File CSI no soporta usar el mismo volumen con fsgroups diferentes, si está habilitadla migración CSI Azurefile, usar el mismo volumen con fsgorups diferentes no será compatible en absoluto. + +### cephfs + +Un volumen `cephfs` permite montar un volumen CephFS existente en tu Pod. +A diferencia de `emptydir`, que es borrado cuando se remueve el Pod, el contenido de un volumen `cephfs` es preservado y el volumen es meramente desmontado. Esto significa que un volumen `cephfs`puede ser pre-poblado por múltiples escritores simultáneamente. + +{{< note >}} +Debes tener tu propio servidor Ceph corriendo con el recurso compartido exportado antes de usarlo. +{{< /note >}} + +Mira el [CephFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/) para más detalles. + +### cinder + +{{< note >}} +Kubernetes no debe ser configurado con el proveedor cloud OpenStack. +{{< /note >}} + +El tipo de volumen `cinder` se usa para montar un volumen Cinder de OpenStack en tu Pod. + +#### Cinder volume configuration example + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-cinder +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-cinder-container + volumeMounts: + - mountPath: /test-cinder + name: test-volume + volumes: + - name: test-volume + # Este volumen de OpenStack debe existir anteriormente. + cinder: + volumeID: "" + fsType: ext4 +``` + +#### Migración CSI OpenStack + +{{< feature-state for_k8s_version="v1.21" state="beta" >}} + +La función `CSIMigration` para Cinder está habilitada por defecto en Kubernetes 1.21. +Esta redirige todas las operaciones de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de `cinder.csi.openstack.org`. +El controlador [OpenStack Cinder CSI Driver](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md) debe estar instalado en el clúster. + +Puedes deshabilitar la migración CSI para tu clúster estableciendo el [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `CSIMigrationOpenStack` a `false`. +Si deshabilitas la función `CSIMigrationOpenStack`, el complemento del volumen Cinder dentro del árbol toma la responsabilidad para todos los aspectos de la administración del almacenamiento del volumen Cinder. + +### configMap + +Un [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) +provee una manera de inyectar datos de configuración a los pods. +Los datos almacenados en un ConfigMap se pueden referenciar en un volumen de tipo `configMap` +y luego ser consumidos por aplicaciones contenerizadas corriendo en un Pod. + +Cuando haces referencia a un ConfigMap, provees el nombre del ConfigMap en el volumen. +Puedes personalizar la ruta para una entrada específica en el ConfigMap. +La siguiente configuración muestra cómo montar un ConfigMap `log-config` en un Pod llamado `configmap-pod`: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: configmap-pod +spec: + containers: + - name: test + image: busybox + volumeMounts: + - name: config-vol + mountPath: /etc/config + volumes: + - name: config-vol + configMap: + name: log-config + items: + - key: log_level + path: log_level +``` + +El ConfigMap `log-config` es montado como un volumen, y todo el contenido almacenado en su entrada `log_level` es +montado en el Pod en la ruta `/etc/config/log_level`. Ten en cuenta que esta ruta se deriva del `mountPath`del volumen y el `path` cuya clave es `log_level`. + +{{< note >}} + +- Debes crear un [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) antes de usarlo. +- Un contenedor usando un ConfigMap montado como un volumen [`subPath`](#using-subpath) no recibirá actualizaciones del ConfigMap +- Los datos de texto son expuestos como ficheros usando la codificación de caracteres UTF-8. Para otras codificaciones de caracteres, use `binaryData`. +{{< /note >}} + +### downwardAPI {#downwardapi} + +Un volumen de `downwardAPI` hace que los datos API descendentes estén disponibles para las aplicaciones. +Monta un directorio y escribe los datos solicitados en archivos de texto sin formato. + +{{< note >}} +Un contenedor usando la API descendiente montado como un volumen [`subPath`](#using-subpath) no recibirá actualizaciones API descendientes. +{{< /note >}} + +Mira el [downward API example](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) para mayores detalles. + +### emptyDir {#emptydir} + +Un volumen `emptyDir`es creado primero cuando se asigna un Pod a un nodo, y existe mientras el Pod está corriendo en el nodo. +Como su nombre lo indica un volumen `emptydir`está inicialmente vacío. Todos los contenedores en el Pod pueden leer y escribir +los archivos en el volumen `emptyDir`, aunque ese volumen se puede montar en la misma o diferente ruta en cada contenedor. Cuando un Pod es removido del nodo por alguna razón, los datos en `emptydir` se borran permanentemente. + +{{< note >}} +Un contenedor que colapsa _no_ remueve el Pod del nodo. Los datos en un volumen `emptyDir` están seguros en caso de +colapso del contenedor. +{{< /note >}} + +Algunos usos para un `emptyDir` son: + +- Espacio temporal, como para una clasificación de combinación basada en disco +- Marcar un largo cálculo para la recuperación de fallos +- Contener archivos que un contenedor de administrador de contenido recupera mientras un contenedor de servidor web + sirve los datos + +Dependiendo de tu entorno, los volúmenes `emptydir` se almacenan en cualquier medio que respalde el nodo tales como disco SSD, o almacenamiento de red. Sin embargo, si se establece el campo `emptydir.medium` a `Memory`, Kubernetes monta en su lugar un tmpfs (sistema de ficheros respaldado por la RAM). Mientras que tmpfs es muy rápido, ten en cuenta que a diferencia de los discos, tmpfs se limpia cuando el nodo reinicia y cualquier archivo que escribas cuenta con el límite de memoria del contenedor. + +{{< note >}} +Si el [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SizeMemoryBackedVolumes` está habilitado, +puedes especificar un tamaño para los volúmenes respaldados en memoria. Si no se especifica ningún tamaño, los volúmenes respaldados en memoria tienen un tamaño del 50% de la memoria en un host Linux. +{{< /note>}} + +#### Ejemplo de configuración de emptyDir + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /cache + name: cache-volume + volumes: + - name: cache-volume + emptyDir: {} +``` + +### fc (canal de fibra) {#fc} + +Un tipo de volumen `fc` permite que un volumen de almacenamiento de bloque de canal de fibra existente se monte en un Pod. +Puede especificar nombres mundiales de destino únicos o múltiples (WWN) utilizando el parámetro `targetWWNs` en su configuración de volumen. +Si se especifican varios WWN, targettWWNs esperan que esos WWN sean de conexiones de múltiples rutas. + +{{< note >}} +Debes configurar FC SAN zoning para asignar y enmascarar esos (volúmenes) LUNs para apuntar a los WWNs de destino de antemano +para que los hosts Kubernetes pueda acceder a ellos. +{{< /note >}} + +Revisa el [ejemplo de canal de fibra](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) para más detalles. + +### flocker (deprecado) {#flocker} + +[Flocker](https://github.com/ClusterHQ/flocker) es un administrador open-source de volúmenes de contenedor agrupado por clúster. +Flocker proporciona administración y orquestación de volúmenes de datos respaldados por una variedad de backends de almacenamiento. + +Un volumen `flocker` permite montar un conjunto de datos Flocker en un Pod. Si el conjunto de datos no existe en Flocker, necesita ser creado primero con el CLI de Flocker o usando la API de Flocker. Si el conjunto de datos existe será adjuntado +de nuevo por Flocker al nodo donde el Pod está programado. Esto significa que los datos pueden ser compartidos entre pods como sea necesario. + +{{< note >}} +Debes tener una instalación propia de Flocker ejecutándose antes de poder usarla. +{{< /note >}} + +Mira el [ejemplo de Flocker ](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker) para más detalles. + +### gcePersistentDisk + +Un volumen `gcePersistentDisk` monta un volumen de Google Compute Engine (GCE) +de [disco persistente](https://cloud.google.com/compute/docs/disks) (DP) en tu Pod. +A diferencia de `emptyDir`, que se borra cuando el Pod es removido, el contenido de un disco persistente es preservado +y el volumen solamente se desmonta. Esto significa que un disco persistente puede ser pre-poblado con datos, +y que esos datos se pueden compartir entre pods. + +{{< note >}} +Debes crear un disco persistente usando `gcloud`, la API de GCE o la UI antes de poder usarlo. +{{< /note >}} + +Existen algunas restricciones cuando usas `gcePersistentDisk`: + +- Los nodos en los que se ejecutan los pods deben ser máquinas virtuales GCE. +- Esas máquinas virtuales deben estar en el mismo proyecto GCE y zona que el disco persistente se encuentra. + +Una de las características del disco persistente CGE es acceso concurrente de solo lectura al disco persistente. +Un volumen `gcePersistentDisk` permite montar simultáneamente un disco de solo lectura a múltiples consumidores. +Esto significa que puedes pre-poblar un DP con tu conjunto de datos y luego servirlo en paralelo desde tantos pods como necesites. Desafortunadamente, los DPs solo se pueden montar por un único consumidor en modo lectura-escritura. +No están permitidos escritores simultáneos. + +Usar un disco persistente GCE con un Pod controlado por un ReplicaSet fallará a manos que el DP sea de solo lectura o el número de réplicas sea 0 o 1. + +#### Creando un disco persistente GCE {#gce-create-persistent-disk} + +Antes de poder usar un disco persistente GCE en un Pod, necesitas crearlo. + +```shell +gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk +``` + +#### Ejemplo de configuración de un disco persistente GCE + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-pd + name: test-volume + volumes: + - name: test-volume + # Este PD GCE debe existir con anterioridad. + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 +``` + +#### Discos regionales persistentes + +La función de [discos regionales persistentes](https://cloud.google.com/compute/docs/disks/#repds) +permite la creación de discos persistentes que están disponibles en dos zonas dentro de la misma región. +Para usar esta función, el volumen debe ser provisto como un PersistentVolumen; referenciar el volumen directamente desde un Pod no está soportado. + +#### Aprovisionamiento manual de un PD PersistentVolume Regional + +El aprovisionamiento dinámico es posible usando un [StorageClass para el DP GCE](/docs/concepts/storage/storage-classes/#gce). +Antes de crear un PersistentVolume, debes crear el disco persistente: + +```shell +gcloud compute disks create --size=500GB my-data-disk + --region us-central1 + --replica-zones us-central1-a,us-central1-b +``` + +#### Ejemplo de configuración de un disco persistente regional + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: test-volume +spec: + capacity: + storage: 400Gi + accessModes: + - ReadWriteOnce + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 + nodeAffinity: + required: + nodeSelectorTerms: + - matchExpressions: + - key: failure-domain.beta.kubernetes.io/zone + operator: In + values: + - us-central1-a + - us-central1-b +``` + +#### Migración CSI GCE + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + +La función `CSIMigration` para el DP GCE, cuando se habilita, redirige todas las operaciones +de complemento desde el complemento existente dentro del árbol existente al controlador de Interfaz de Almacenamiento del Contenedor (CSI) de `pd.csi.storage.gke.io`. Para poder usar esta función, el [controlador PD GCE](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) debe ser instalado en el clúster y habilitar las funciones beta +`CSIMigration` y `CSIMigrationGCE`. + +### gitRepo (deprecado) {#gitrepo} + +{{< warning >}} +El volumen `gitRepo` está deprecado. Para aprovisionar un contenedor con un repositorio git, monta un [EmptyDir](#emptydir) en un InitContainer que clona un repositorio usando git, luego monta el [EmptyDir](#emptydir) en el contenedor del Pod. +{{< /warning >}} + +Un volumen `gitRepo` es un ejemplo de un complemento de volumen. Este complemento monta un directorio vacío y clona un repositorio git en este directorio para que tu Pod pueda usarlo. + +Aquí un ejemplo de un volumen `gitrepo`: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: server +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /mypath + name: git-volume + volumes: + - name: git-volume + gitRepo: + repository: "git@somewhere:me/my-git-repository.git" + revision: "22f1d8406d464b0c0874075539c1f2e96c253775" +``` + +### glusterfs + +Un volumen `glusterfs` permite montar un volumen [Glusterfs](https://www.gluster.org) en tu Pod. +A diferencia de `emptyDir`, que se borra cuando se remueve un Pod, el contenido de un volumen `glusterfs` es preservado +y el volumen solamente se desmonta. Esto significa que un volumen glusterfs puede ser pre-poblado con datos, +y que los datos pueden ser compartidos entre pods. GlusterFS puede ser montado por múltiples escritores simultáneamente. + +{{< note >}} +Debes tener tu propia instalación de GlusterFS ejecutándose antes de poder usarla. +{{< /note >}} + +Mira el [ejemplo de GlusterFS](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs) para más detalles. + +### hostPath {#hostpath} + +Un volumen `hostPath` monta un archivo o un directorio del sistema de archivos del nodo host a tu Pod. +Esto no es algo de muchos Pods necesiten, pero ofrece una trampa de escape poderosa para algunas aplicaciones. + +Por ejemplo, algunos usos de un `hostPath` son: + +- ejecutar un contenedor que necesita acceso a los directorios internos de Docker, usa un `hostPath` de `/var/lib/docker` +- ejecutar un cAdvisor en un contenedor; usa un `hostPath` de `/sys` +- permitir a un Pod especificar si un `hostPath` dado debería existir ante de correr el Pod, si debe crearse, cómo debe existir + +Además de la propiedad requerida `path`, puedes especificar opcionalmente un `tipo`para un volumen `hostPath`. + +Los valores soportados para el campo `tipo` son: + +| Valor | Comportamiento | +| :------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| | Una cadena vacía (por defecto) es para compatibilidad con versiones anteriores, lo que significa que no se harán revisiones antes de montar el volumen hostPath. | +| `DirectoryOrCreate` | Si no hay nada en la ruta dada, se creará un directorio vacío como es requerido con los permisos a 0755, teniendo el mismo grupo y propiedad que el Kubelet. | +| `Directory` | Un directorio debe existir en la ruta dada | +| `FileOrCreate` | Si no hay nada en la ruta dada, se creará un archivo vacío como es requerido con los permisos a 0644, teniendo el mismo grupo y propiedad que el Kubelet. | +| `File` | Un archivo debe existir en la ruta dada | +| `Socket` | Un socket de UNIX debe existir en la ruta dada | +| `CharDevice` | Un dispositivo de caracteres debe existir en la ruta data | +| `BlockDevice` | Un dispositivo de bloques dbe existir en la ruta dada | + +Ten cuidado cuando uses este tipo de volumen, porque: + +- Los Pods con configuración idéntica (tales como los creados por un PodTemplate) pueden comportarse de forma distinta + en nodos distintos debido a diferentes ficheros en los nodos. +- Los ficheros o directorios creados en los hosts subyacentes son modificables solo por root. Debes ejecutar tu proceso como root en un [Contenedor privilegiado](/docs/tasks/configure-pod-container/security-context/) o modificar los permisos de archivo en el host para escribir a un volumen `hostPath` + +#### Ejemplo de configuración hostPath + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-pd + name: test-volume + volumes: + - name: test-volume + hostPath: + # localización del directorio en el host + path: /data + # este campo es opcional + type: Directory +``` + +{{< caution >}} +El modo `FileOrCreate` no crea el directorio padre del archivo. Si el directorio padre del archivo montado no existe, +el Pod falla en iniciar. Para asegurar que este modo funciona, puedes intentar montar directorios y ficheros de forma separada, +tal como se muestra en la [ confugiración `FileOrCreate`](#hostpath-fileorcreate-example) +{{< /caution >}} + +#### ejemplo de configuración hostPath FileOrCreate {#hostpath-fileorcreate-example} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-webserver +spec: + containers: + - name: test-webserver + image: k8s.gcr.io/test-webserver:latest + volumeMounts: + - mountPath: /var/local/aaa + name: mydir + - mountPath: /var/local/aaa/1.txt + name: myfile + volumes: + - name: mydir + hostPath: + # Asegúrate que el directorio del archivo es creado. + path: /var/local/aaa + type: DirectoryOrCreate + - name: myfile + hostPath: + path: /var/local/aaa/1.txt + type: FileOrCreate +``` + +### iscsi + +Un volumen `iscsi` permite que se monte un volumen ISCSI (SCSI sobre IP) existente +en tu Pod. A diferencia de `emptydir`, que es removido cuando se remueve un Pod, +el contenido de un volumen `iscsi` es preservado y el volumen solamente se desmonta. +Esto significa que un volumen iscsi puede ser pre-poblado con datos, y que estos datos se pueden compartir entre pods. + +{{< note >}} +Debes tener tu propio servidor ISCSI corriendo con el volumen creado antes de poder usarlo. +{{< /note >}} + +Una función de SCSI es que puede ser montado como de solo lectura por múltiples consumidores simultáneamente. +Esto significa que puedes pre-poblar un volumen con tu conjunto de datos y servirlo en paralelo para tantos Pods como necesites. +Desafortunadamente, los volúmenes ISCSI solo se pueden montar por un único consumidor en modo lectura-escritura. +Escritores simultáneos no está permitido. + +Mira el [ejemplo iSCSI](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi) para más detalles. + +### local + +Un volumen `local` representa un dispositivo de almacenamiento local como un disco, una partición o un directorio. + +Los volúmenes locales solo se pueden usar como un PersistenVolume creado estáticamente. +El aprovisionamiento dinámico no está soportado. + +Comparados con volúmenes `hostPath`, los volúmenes `local` se usan de manera duradera y portátil sin programar pods manualmente +a los nodos. El sistema está consciente de las limitaciones del nodo del volumen al mirar la afinidad del nodo en el PersistenVolumen. + +Sin embargo, los volúmenes `local`están sujetos a la disponibilidad del nodo subyacente y no son compatibles para todas las aplicaciones. + +Si un nodo deja de estar sano, entonces el volumen `local` se vuelve inaccesible al Pod. +El Pod que utiliza este volumen no se puede ejecutar. +Las aplicaciones que usan volúmenes `local` deben ser capaces de tolerar esta disponibilidad reducida, +así como la pérdida potencial de datos, dependiendo de las características de durabilidad del disco subyacente. + +El siguiente ejemplo muestra un PersistentVolume usando un volumen `local`y `nodeAffinity`: + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: example-pv +spec: + capacity: + storage: 100Gi + volumeMode: Filesystem + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Delete + storageClassName: local-storage + local: + path: /mnt/disks/ssd1 + nodeAffinity: + required: + nodeSelectorTerms: + - matchExpressions: + - key: kubernetes.io/hostname + operator: In + values: + - example-node +``` + +Debes establecer un valor de `nodeAffinity` del PersistenVolume cuando uses volúmenes `local`. +El Scheduler de Kubernetes usa `nodeaffinity` del PersistenVolume para programar estos Pods al nodo correcto. + +El `volumeMode` del PersistentVolume se puede establecer en "Block" (en lugar del valor por defecto, "Filesystem") +para exponer el volumen local como un dispositivo de bloque sin formato. + +Cuando usas volúmenes locales, se recomienda crear un StorageClass con `volumeBindingMode` en `WaitForFirstConsumer`. +Para más detalles, mira el ejemplo de [StorageClass](/docs/concepts/storage/storage-classes/#local). Retrasar el enlace con el volumen asegura que la decisión del PersistenVolumeClaim sea evaluada con otras limitaciones que el Pod pueda tener, +tales como requisitos de recursos del nodo, selectores de nodo, afinidad del Pod, y anti-afinidad del Pod. + +Se puede ejecutar un aprovisionador estático externo para un manejo mejorado del ciclo de vida del volumen local. +Ten en cuenta que este aprovisionador no soporta aprovisionamiento dinámico todavía. Para un ejemplo de un aprovisionador local externo, mira la [guía de usuario de aprovisionador de volumen local](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner) + +{{< note >}} +El PersistentVolume local requiere limpieza y borrado manual por el usuario si no se utiliza el aprovisionador estático externo para manejar el ciclo de vida del volumen. +{{< /note >}} + +### nfs + +Un volumen `nfs` permite montar un NFS (Sistema de Ficheros de Red) compartido en tu Pod. +A diferencia de `emptyDir` que se borra cuando el Pod es removido, el contenido de un volumen `nfs` solamente se desmonta. +Esto significa que un volumen NFS puede ser pre-poblado con datos, y que estos datos puedes ser compartidos entre pods. +NFS puede ser montado por múltiples escritores simultáneamente. + +{{< note >}} +Debes tener tu propio servidor NFS en ejecución con el recurso compartido exportado antes de poder usarlo. +{{< /note >}} + +Mira el [ ejemplo NFS ](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs) para más información. + +### persistentVolumeClaim {#persistentvolumeclaim} + +Un volumen `persistenceVolumeClain` se utiliza para montar un [PersistentVolume](/docs/concepts/storage/persistent-volumes/) en tu Pod. PersistentVolumeClaims son una forma en que el usuario "reclama" almacenamiento duradero (como un PersistentDisk GCE o un volumen ISCSI) sin conocer los detalles del ambiente de la nube en particular. + +Mira la información spbre [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) para más detalles. + +### portworxVolume {#portworxvolume} + +Un `portworxVolume` es un almacenamiento de bloque elástico que corre hiperconvergido con Kubernetes. +Almacenamiento de huellas de [Portworx](https://portworx.com/use-case/kubernetes-storage/) en un servidor, niveles basados en capacidades y capacidad agregada en múltiples servidores. +Portworx se ejecuta como invitado en máquinas virtuales o en nodos Linux nativos. + +Un `portworxVolume` puede ser creado dinámicamente a través de Kubernetes o puede ser pre-aprovisionado y referido dentro de un Pod. Aquí un Pod de ejemplo refiriendo a un volumen Portworx pre-aprovisionado: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-portworx-volume-pod +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /mnt + name: pxvol + volumes: + - name: pxvol + # Este volumen portworx debe sxistir con anterioridad. + portworxVolume: + volumeID: "pxvol" + fsType: "" +``` + +{{< note >}} +Asegúrate de tener un PortworxVolume con el nombre `pxvol` antes de usarlo en el Pod. +{{< /note >}} + +Para más detalles, mira los ejemplos de [volumen Portworx](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md). + +### projected + +Un volumen `projected` mapea distintas fuentes de volúmenes existentes en un mismo directorio. + +Actualmente, se pueden los siguientes tipos de volúmenes: + +- [`secret`](#secret) +- [`downwardAPI`](#downwardapi) +- [`configMap`](#configmap) +- `serviceAccountToken` + +Se requiere que todas las fuentes estén en el mismo namespace que el Pod. Para más detalles mira el [all-in-one volume design document](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md). + +#### Configuración de ejemplo con un secret, un downwardAPI, y un configMap {#example-configuration-secret-downwardapi-configmap} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: volume-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: all-in-one + mountPath: "/projected-volume" + readOnly: true + volumes: + - name: all-in-one + projected: + sources: + - secret: + name: mysecret + items: + - key: username + path: my-group/my-username + - downwardAPI: + items: + - path: "labels" + fieldRef: + fieldPath: metadata.labels + - path: "cpu_limit" + resourceFieldRef: + containerName: container-test + resource: limits.cpu + - configMap: + name: myconfigmap + items: + - key: config + path: my-group/my-config +``` + +#### Configuración de ejemplo: secrets con un modo de permisos no predeterminados {#example-configuration-secrets-nondefault-permission-mode} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: volume-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: all-in-one + mountPath: "/projected-volume" + readOnly: true + volumes: + - name: all-in-one + projected: + sources: + - secret: + name: mysecret + items: + - key: username + path: my-group/my-username + - secret: + name: mysecret2 + items: + - key: password + path: my-group/my-password + mode: 511 +``` + +Cada volumen proyectado está listado en spec bajo `sources`. Los parámetros son casi los mismos salvo dos excepciones: + +- Para los secrets, el campo `secretName` ha sido cambiado a `name` para ser consistente con el nombre del configMap. +- El `defaultMode` solo se puede especificar en el nivel proyectado y no para cada fuente de volumen. Sin, como se muestra arriba, puedes establecer explícitamente el `mode` para cada proyección individual. + +Cuando la función `TokenRequestProjection` está habilitada, puedes inyectar el token para el [service account](/docs/reference/access-authn-authz/authentication/#service-account-tokens) actual en un Pod en la ruta especificada. +Por ejemplo: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: sa-token-test +spec: + containers: + - name: container-test + image: busybox + volumeMounts: + - name: token-vol + mountPath: "/service-account" + readOnly: true + volumes: + - name: token-vol + projected: + sources: + - serviceAccountToken: + audience: api + expirationSeconds: 3600 + path: token +``` + +El Pod de ejemplo tiene un volumen proyectado que contiene el token del serviceAccount inyectado. +Este token se puede usar por el contenedor de un Pod para acceder a la API del servidor de Kubernetes. +El `audience` contiene la audiencia dirigida del token. Un recipiente del token debe identificarse a sí mismo con +un identificador especificado en la audiencia del token, de lo contrario debería rechazar el token. Este campo es opcional y por defecto tiene el valor del identificador del servidor API. + +EL campo `expirationSeconds` es la duración esperada de la validez del token del serviceAccount. +Su valor por defecto es 1 hora y debe ser al menos 10 minutos (600 segundos). Un administrador puede limitar +su valor máximo al especificar la opción `--service-account-max-token-expiration` para el servidor API. El campo `path` especifica una ruta relativa al punto de montaje del volumen proyectado. + +{{< note >}} +Un contenedor que usa una fuente de volumen proyectado como un volumen [`subPath`](#using-subpath) no recibirá actualizaciones de estas fuentes de volumen. +{{< /note >}} + +### quobyte + +Un volumen `quobyte` permite montar un volumen [Quobyte](https://www.quobyte.com) en tu Pod. + +{{< note >}} +Debes tener tu propia configuración Quobyte ejecutándose con los volúmenes creados antes de usarlo. +{{< /note >}} + +Quobyte soporta el {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}}. +CSI es el complemento recomendado para usar Quobyte dentro de Kubernetes. El proyecto Github de Quobyte tiene [instrucciones](https://github.com/quobyte/quobyte-csi#quobyte-csi) para desplegar usando CSI, junto con ejemplos. + +### rbd + +Un volumen `rbd` permite montar un volumen [Rados Block Device](https://docs.ceph.com/en/latest/rbd/) (RBD) en tu Pod. +A diferencia de `emptyDir`, que se borra cuando el Pod es removido, el contenido de un volumen `rbd` es preservado y el volumen se desmonta. Esto significa que un volumen RBD puede ser pre-poblado con datos, y que estos datos pueden ser compartidos entre pods. + +{{< note >}} +Debes tener una instalación de Ceph ejecutándose antes de usar RBD. +{{< /note >}} + +Una función de RBD es que solo se puede montar como de solo lectura por múltiples consumidores simultáneamente. +Esto significa que puedes pre-poblar un volumen con tu conjunto de datos y luego servirlo en paralelo desde tantos pods como necesites. Desafortunadamente, los volúmenes RBD solo se pueden montar por un único consumidor en modo lectura-escritura. No se permiten escritores simultáneos. + +Mira el [ejemplo RBD](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd) para más detalles. + +### scaleIO (deprecado) {#scaleio} + +ScaleIO es una plataforma de almacenamiento basada en software que usa el hardware existente para crear clústeres de almacenamiento en red de bloques compartidos escalables. El complemento de volumen `scaleIO` permite a los pods desplegados acceder a volúmenes existentes ScaleIO. Para información acerca de aprovisionamiento dinámico de nuevos persistence volumen claims, mira [ScaleIO persistent volumes](/docs/concepts/storage/persistent-volumes/#scaleio) + +{{< note >}} +Debes tener un Cluster ScaleIO ya configurado y ejecutándose con los volúmenes creados antes de poder usarlos. +{{< /note >}} + +El siguiente ejemplo es una configuración de un Pod con ScaleIO: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod-0 +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: pod-0 + volumeMounts: + - mountPath: /test-pd + name: vol-0 + volumes: + - name: vol-0 + scaleIO: + gateway: https://localhost:443/api + system: scaleio + protectionDomain: sd0 + storagePool: sp1 + volumeName: vol-0 + secretRef: + name: sio-secret + fsType: xfs +``` + +Para más detalles, mira los ejemplos de [ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio) + +### secret + +Un volumen `seret` se utiliza para pasar información sensible, como contraseñas, a los Pods. +Puedes guardar secrets en la API de Kubernetes y montarlos como ficheros para usarlos con los pods sin acoplarlos con Kubernetes directamente. Los volúmenes `secret` son respaldados por tmpfs (un sistema de ficheros respaldado por la RAM) así que nunca se escriben en un almacenamiento no volátil. + +{{< note >}} +Debes crear un secreto en la API de Kubernetes antes de poder usarlo. +{{< /note >}} + +{{< note >}} +Un contenedor que usa un Secret como un volumen [`subPath`](#using-subpath) no recibirá las actualizaciones del Secret. +{{< /note >}} + +Para más detalles, mira [Configurando Secrets](/docs/concepts/configuration/secret/). + +### storageOS {#storageos} + +Un volumen `storageos` permite montar un volumen existente [StorageOS](https://www.storageos.com) en tu Pod. + +StorageOS corre como un contenedor dentro de tu contenedor Kubernetes, haciendo accesible el almacenamiento local o adjunto desde cualquier node dentro del cluster de Kubernetes. +Los datos pueden ser replicados para protegerlos contra fallos del nodo. Este aprovisionamiento y compresión pueden mejorar el uso y reducir costes. + +El contenedor StorageOs requiere Linux de 64 bits y no tiene dependencias adicionales. +Una licencia gratuita para desarrolladores está disponible. + +{{< caution >}} +Debes correr un contenedor StorageOS en cada nodo que quiera acceder a los volúmenes StorageOS o que contribuyan a la capacidad de almacenamiento al grupo. +Para instrucciones de instalación, consulta la [documentación StorageOS](https://docs.storageos.com) +{{< /caution >}} + +El siguiente ejemplo es una configuración de un Pod con Storage OS: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + labels: + name: redis + role: master + name: test-storageos-redis +spec: + containers: + - name: master + image: kubernetes/redis:v1 + env: + - name: MASTER + value: "true" + ports: + - containerPort: 6379 + volumeMounts: + - mountPath: /redis-master-data + name: redis-data + volumes: + - name: redis-data + storageos: + # El volumen `redis-vol01` debe existir dentro de StorageOS en el namespace `default`. + volumeName: redis-vol01 + fsType: ext4 +``` + +Para más información sobre StorageOS, aprovisionamiento dinámico, y PersistentVolumeClaims, mira los +[ ejemplos de StorageOS examples](https://github.com/kubernetes/examples/blob/master/volumes/storageos). + +### vsphereVolume {#vspherevolume} + +{{< note >}} +Debes configurar el proveedor en la nube de vSphere de Kubernetes. +Para configuración de proveedores en la nube, mira la [ guía de inicio de vSphere ](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/). +{{< /note >}} + +Un volumen `vsphereVolume` se usa para montar un volumen VMDK vSphere en tu Pod. El contenido de un volumen es preservado cuando se desmonta. Tiene soporte para almacén de datos VMFS y VSAN. + +{{< note >}} +Debes crear un volumen vSphere VMDK usando uno de los siguientes métodos antes de usarlo con un Pod. +{{< /note >}} + +#### Creando un volumen VMDK {#creating-vmdk-volume} + +Elige uno de los siguientes métodos para crear un VMDK. + +{{< tabs name="tabs_volumes" >}} +{{% tab name="Create using vmkfstools" %}} +Primero entra mediante ssh en ESX, luego usa uno de los siguientes comandos para crear un VMDK: + +```shell +vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk +``` + +{{% /tab %}} +{{% tab name="Create using vmware-vdiskmanager" %}} +Usa el siguiente comando para crear un VMDK: + +```shell +vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk +``` + +{{% /tab %}} + +{{< /tabs >}} + +#### Ejemplo de configuración vSphere VMDK {#vsphere-vmdk-configuration} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-vmdk +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-vmdk + name: test-volume + volumes: + - name: test-volume + # Este volumen VMDK ya debe existir. + vsphereVolume: + volumePath: "[DatastoreName] volumes/myDisk" + fsType: ext4 +``` + +Para mayor información, mira el ejemplo de [vSphere volume](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere). + +#### Migración CSI vSphere {#vsphere-csi-migration} + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} +Cuando la función `CSIMigration` está habilitada, redirige todas las operaciones de complemento desde el complemento existente en el árbol al controlador {{< glossary_tooltip text="CSI" term_id="csi" >}} `csi.vsphere.vmware.com`. Para +usar esta función, el [controlador vSphere CSI](https://github.com/kubernetes-sigs/vsphere-csi-driver) debe estar instalado en el clúster y las [feature gates](/docs/reference/command-line-tools-reference/feature-gates/) `CSIMigration` y `CSIMigrationvSphere` deben estar habilitadas. + +Esto también requiere que la versión de vSphere vCenter/ESXi sea la 7.0u1 y la versión mínima de HW version sea VM versión 15. + +{{< note >}} +Los siguientes parámetros de Storageclass desde el complemento incorporado `vsphereVolume` no están soportados por el controlador vSphere CSI: + +- `diskformat` +- `hostfailurestotolerate` +- `forceprovisioning` +- `cachereservation` +- `diskstripes` +- `objectspacereservation` +- `iopslimit` + +Los volúmenes existentes creados usando estos parámetros serán migrados al controlador vSphere CSI, pero los volúmenes nuevos creados por el controlador vSphere CSI no respetarán estos parámetros +{{< /note >}} + +#### migración completa de vSphere CSI {#vsphere-csi-migration-complete} + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} +Para apagar el complemento `vsphereVolume` y no cargarlo por el administrador del controlador y el kubelet, necesitas establecer eta función a `true`. Debes instalar un controlador de tipo `csi.vsphere.vmware.com` en todos los nodos worker. + +## Uso de subPath {#using-subpath} + +Algunas veces es útil compartir un volumen para múltiples usos en un único Pod. +La propiedad `volumeMounts.subPath` especifica una sub-ruta dentro del volumen referenciado en lugar de su raíz. + +El siguiente ejemplo muestra cómo configurar un Pod con la pila LAMP (Linux Apache MySQL PHP) usando un único volumen compartido. Esta configuración de ejemplo usando `subPath` no se recomienda para su uso en producción. + +El código de la aplicación PHP y los recursos apuntan al directorio `html` del volumen y la base de datos MySQL se almacena en el directorio `mysql`. Por ejemplo: +The PHP application's code and assets map to the volume's `html` folder and +the MySQL database is stored in the volume's `mysql` folder. For example: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-lamp-site +spec: + containers: + - name: mysql + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "rootpasswd" + volumeMounts: + - mountPath: /var/lib/mysql + name: site-data + subPath: mysql + - name: php + image: php:7.0-apache + volumeMounts: + - mountPath: /var/www/html + name: site-data + subPath: html + volumes: + - name: site-data + persistentVolumeClaim: + claimName: my-lamp-site-data +``` + +### Uso de subPath con variables de entorno expandidas {#using-subpath-expanded-environment} + +{{< feature-state for_k8s_version="v1.17" state="stable" >}} +Usa el campo `subPathExpr` para construir un nombre de directorio `subPath` desde variables de entorno de la API. +Las propiedades `subPath` y `subPathExpr` son mutuamente exclusivas. + +En este ejemplo, un `Pod` usa `subPathExpr` para crear un directorio `pod1` dentro del volumen `hostPath` `var/logs/pods`. +El volumen `hostPath` toma el nombre del `Pod` desde la `downwardAPI`. +El directorio anfitrión `var/log/pods/pod1` se monta en `/logs` en el contenedor. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod1 +spec: + containers: + - name: container1 + env: + - name: POD_NAME + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: metadata.name + image: busybox + command: + [ + "sh", + "-c", + "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt", + ] + volumeMounts: + - name: workdir1 + mountPath: /logs + subPathExpr: $(POD_NAME) + restartPolicy: Never + volumes: + - name: workdir1 + hostPath: + path: /var/log/pods +``` + +## Recursos + +El medio de almacenamiento (como un disco o un SSD) de un volumen `emptyDir` +se determina por el medio del sistema de archivos que contiene el directorio raíz +del kubelet (típicamente `/var/lib/kubelet`). +No hay límite de cuánto espacio puede consumir un volumen `emptydir` o `hostPath`, +y no hay aislamiento entre contenedores o entre pods. + +Para aprender más sobre requerir espacio usando una espacificación de recurso, mira [cómo administrar recursos](/docs/concepts/configuration/manage-resources-containers/). + +## Complementos de volúmenes fuera del árbol + +Los complementos de volumen fuera del árbol incluyen {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI) y FlexVolume. Estos complementos permiten a los proveedores de almacenamiento crear complementos de almacenamiento personalizados sin añadir su código fuente al repositorio de Kubernetes. + +Anteriormente, todos los complementos de volumen estaban "en el árbol". Los complementos "en el árbol" se construían, enlazaban, compilaban y enviaban con los binarios del núcleo de Kubernetes. Esto significaba que agregar un nuevo sistema de almacenamiento a Kubernetes (un complemento de volumen) requería verificar el código en el repositorio de código del núcleo de Kubernetes. + +Tanto CSI como FlexVolume permiten que se desarrollen complementos de volúmenes independientemente del código base de Kubernetes, y se desplieguen (instalen) en los clústeres de Kubernetes como extensiones. + +Para los proveedores de almacenamiento que buscan crear un complemento de volumen fuera del árbol, por favor refiéranse a [Preguntas frecuentees de complementos de volumen](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). + +### csi + +La [interfaz de almacenamiento del contenedor](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI) define una interfaz estándar para sistemas de orquestación del contenedor (como Kubernetes) para exponer sistemas de almacenamiento arbitrario a sus cargas de trabajo del contenedor. + +Por favor, lee la [propuesta de diseño CSI](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) para más información. + +{{< note >}} +El soporte para las especificaciones de las versiones CSI 0.2 y 0.3 están deprecadas en Kubernetes v1.13 y serán removidos en una versión futura. +{{< /note >}} + +{{< note >}} +Los controladores CSI podrían no ser compatibles con todas las versiones de Kubernetes. +Por favor, revisa la documentación específica del controlador CSI para los pasos de despliegue soportados para cada versión de Kubernetes y una matriz de compatibilidad. +{{< /note >}} + +Una vez que se despliega un controlador de volumen CSI compatible, los usuarios pueden usar el tipo de volumen `csi` para adjuntar o montar los volúmenes expuestos por el controlador CSI. + +Un volumen `csi` puede ser usado en un Pod en tres maneras distintas: + +- a través de una referencia a [PersistentVolumeClaim](#persistentvolumeclaim) +- con un [volumen general efímero](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume) + (característica alpha) +- con un [volumen efímero CSI](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) si el controlador permite esta (característica beta) + +Los siguientes campos están disponibles para que los administradores de almacenamiento configuren el volumen persistente CSI + +- `driver`: Un valor de cadena de caracteres que especifica el nombre del controlador de volumen a usar. Este valor debe corresponder al valor de respuesta en el `GetPluginInfoResponse` por el controlador CSI tal como se define en la [especificación CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo). Es usado por Kubernetes para identificar cuál controlador llamar, y por los componentes del controlador CSI para identificar cuáles objetos PV pertenecen al controlador CSI. +- `volumenHandle`: Un valor de cadena de caracteres que identifica el volumen unívocamente. Este valor debe corresponder al valor en el campo `volumen.id` del `CreateVolumeResponse` por el controlador CSI como se define en la [especificación CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). El valor es pasado como `volume.id` en todas las llamadas al controlador de volumen CSI cuando referencias el volumen. +- `readOnly`: Un valor booleano opcional que indica si el volumen es para ser "ControllerPublished" (adjuntado) como solo lectura. Por defecto es falso. Este valor es pasado el controlador CSI en el campo `readOnly` en el `ControllerPublishVolumeRequest`. +- `fsType`: Si el `VolumeMode`del PV es `Filesystem` entonces este campo se puede usar para especificar el sistema de archivos que debería usarse para montar el volumen. Si el volumen no ha sido formateado y soportado, este valor se utilizará para formatear el volumen. Este valor se para al controlador CSI con el campo `VolumeCapability` de `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, y `NodePublishVolumeRequest`. +- `volumeAttributes`: Un mapa de cadena de caracteres que especifica las propiedades estáticas de un volumen. Este mapa debe corresponder al map devuelto por el campo `volume.attributes` del `CreateVolumeResponse` por el controlador CSI tal como se define en la [especificación CSI spec](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). El mapa es pasado al controlador CSI con el campo `volume.context` en el `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, y `NodePublishVolumeRequest`. +- `controllerPublishSecretRef`: Una referencia al objeto secret que contiene información sensible para pasar al controlador CSI para completar las llamadas CSI `ControllerPublishVolume` y `ControllerUnpublishVolume`. Este campo es opcional, y puede estar vacío si no se requiere un secret. Si el Secret contiene más de un secret, se pasan todos los secrets. +- `nodeStageSecretRef`: Una referencia al objeto secret que contiene información sensible a pasar al controlador CSI para completar la llamada CSI `NodeStageVolume`. Este ampo es opcional, y puede estar vacío si no se requiere un secret. Si el Secret contiene más de un secret, todos los secrets son pasados. +- `nodePublishSecretRef`: Una referencia al objeto que contiene información sensible a pasar al controlador CSI para completar la llamada CSI `NodePublishVolume`. Este ampo es opcional, y puede estar vacío si no se requiere un secret. Si el Secret contiene más de un secret, todos los secrets son pasados. + +#### Soporte de volumen CSI de fila de bloques + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +Los proveedores con controladores CSI externos pueden implementar soporte de volumen de bloques sin procesar en cargas de trabajo de Kubernetes. + +Puedes configurar tu +You can set up your [PersistentVolume/PersistentVolumeClaim with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support) como de costumbre, sin ningún cambio específico CSI. + +#### Volúmenes efímeros CSI + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +Puedes configurar directamente volúmenes CSI dentro de la especificación del Pod. +Los volúmenes especificados de esta manera son efímeros y no se persisten entre reinicios del Pod. Mira [Volúmenes efímeros](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) para más información. + +Para más información de cómo desarrollador un controlador CSI, mira la [documentación kubernetes-csi](https://kubernetes-csi.github.io/docs/) + +#### Migrando a controladores CSI desde complementos en el árbol. + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} +La función `CSIMigration`, cuando está habilitada, dirige todas las operaciones hacia complementos existentes en el árbol a complementos CSI correspondientes (que se espera que estén instalados y configurados). Como resultado, los operadores no tienen que hacer ningún cambio de configuración a las clases de almacenamiento, PersistentVolumes o PersistentVolumeClaims (refiriéndose a complementos en el árbol) cuando haces la transición a un controlador CSI que un reemplaza complemento en el árbol. + +Las operaciones y funciones que están soportadas incluye: +aprovisionamiento/borrado, adjuntar/separar, montar/desmontar y redimensionar volúmenes. + +In-tree plugins that support `CSIMigration` and have a corresponding CSI driver implemented +are listed in [Types of Volumes](#volume-types). + +### flexVolume + +FlexVolume is an out-of-tree plugin interface that has existed in Kubernetes +since version 1.2 (before CSI). It uses an exec-based model to interface with +drivers. The FlexVolume driver binaries must be installed in a pre-defined volume +plugin path on each node and in some cases the control plane nodes as well. + +Pods interact with FlexVolume drivers through the `flexvolume` in-tree volume plugin. +For more details, see the [FlexVolume](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) examples. + +## Propagación del montaje + +La propagación del montaje permite compartir volúmenes montados por un contenedor para otros contenedores en el mismo Pod, o aun para otros pods en el mismo nodo. + +La propagación del montaje de un volumen es controlada por el campo `mountPropagation` en `Container.volumeMounts`. Sus valores son: + +- `None` - Este montaje de volumen no recibirá ningún montaje posterior que el host haya montado en este volumen o en cualquiera de sus subdirectorios. De manera similar, los montajes creados por el contenedor no serán visibles en el host. Este es el modo por defecto. + + Este modo es igual la propagación del montaje `private` tal como se describe en la [ documentación Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + +- `HostToContainer` - Este montaje de volumen recibirá todos los montajes subsecuentes que son montados a este volumen o cualquiera de sus subdirectorios. + + En otras palabras, si el host monta algo dentro del montaje del volumen, el contenedor lo verá montado allí. + + De manera similar, si cualquier Pod con propagación de montaje `Bidirectional` al mismo volumen monta algo allí, el contenedor con propagación de montaje` HostToContainer` lo verá. + + Este modo es igual a la propagación de montaje `rslave` tal como se describe en la [documentación del kernel de Linux](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + +- `Bidirectional`- Este montaje de volumen se comporta de la misma manera de el montaje`HostToContainer`. Adicionalmente, todos los montajes de volúmenes creados por el contenedor serán propagados de vuelta al host y a todos los contenedores de todos los pods que usan el mismo volumen. + + Un uso típico para este modo es un Pod con un FlexVolumen o un controlador CSI o un Pod que necesita montar al en el host usando un volumen `hostPath`. + + Este modo es igual a la propagación de montaje `rshared` tal como se describe en la [documentación del kernel de Linux documentación](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + + {{< warning >}} + La propagación por montaje `Bidirectional` puede ser peligrosa. Puede dañar el sistema operativo host y, por lo tanto, solo se permite en contenedores privilegiados. Se recomienda encarecidamente estar familiarizado con el comportamiento del kernel de Linux. + Además, cualquier montaje de volumen creado por contenedores en pods debe destruirse (desmontado) por los contenedores en el momento de la terminación. + {{< /warning >}} + +### Configuration + +Before mount propagation can work properly on some deployments (CoreOS, +RedHat/Centos, Ubuntu) mount share must be configured correctly in +Docker as shown below. + +Edit your Docker's `systemd` service file. Set `MountFlags` as follows: + +```shell +MountFlags=shared +``` + +Or, remove `MountFlags=slave` if present. Then restart the Docker daemon: + +```shell +sudo systemctl daemon-reload +sudo systemctl restart docker +``` + +## {{% heading "whatsnext" %}} + +Sigue un ejemplo de [desplegar WordPrss y MySQL con volúmenes persistentes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/). diff --git a/content/es/docs/concepts/workloads/controllers/_index.md b/content/es/docs/concepts/workloads/controllers/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/concepts/workloads/controllers/daemonset.md b/content/es/docs/concepts/workloads/controllers/daemonset.md index d52a5d7010..686cf2f21f 100644 --- a/content/es/docs/concepts/workloads/controllers/daemonset.md +++ b/content/es/docs/concepts/workloads/controllers/daemonset.md @@ -12,23 +12,14 @@ Al eliminar un DaemonSet se limpian todos los Pods que han sido creados. Algunos casos de uso típicos de un DaemonSet son: -- ejecutar un proceso de almacenamiento en el clúster, como `glusterd`, `ceph`, en cada nodo. -- ejecutar un proceso de recolección de logs en cada nodo, como `fluentd` o `logstash`. -- ejecutar un proceso de monitorización de nodos en cada nodo, como [Prometheus Node Exporter]( - https://github.com/prometheus/node_exporter), [Sysdig Agent] (https://sysdigdocs.atlassian.net/wiki/spaces/Platform), `collectd`, - [Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/), - [AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes), - [Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/), - [New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration), - Ganglia `gmond` o un agente de Instana. +- Ejecutar un proceso de almacenamiento en el clúster. +- Ejecutar un proceso de recolección de logs en cada nodo. +- Ejecutar un proceso de monitorización de nodos en cada nodo. De forma básica, se debería usar un DaemonSet, cubriendo todos los nodos, por cada tipo de proceso. -En configuraciones más complejas se podría usar múltiples DaemonSets para un único tipo de proceso, +En configuraciones más complejas se podría usar múltiples DaemonSets para un único tipo de proceso, pero con diferentes parámetros y/o diferentes peticiones de CPU y memoria según el tipo de hardware. - - - ## Escribir una especificación de DaemonSet @@ -46,7 +37,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml ### Campos requeridos -Como con cualquier otra configuración de Kubernetes, un DaemonSet requiere los campos `apiVersion`, `kind`, y `metadata`. +Como con cualquier otra configuración de Kubernetes, un DaemonSet requiere los campos `apiVersion`, `kind`, y `metadata`. Para información general acerca de cómo trabajar con ficheros de configuración, ver los documentos [desplegar aplicaciones](/docs/user-guide/deploying-applications/), [configurar contenedores](/docs/tasks/), y [gestión de objetos usando kubectl](/docs/concepts/overview/object-management-kubectl/overview/). @@ -56,10 +47,10 @@ Un DaemonSet también necesita un sección [`.spec`](https://git.k8s.io/communit El campo `.spec.template` es uno de los campos obligatorios de la sección `.spec`. -El campo `.spec.template` es una [plantilla Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Tiene exactamente el mismo esquema que un [Pod](/docs/concepts/workloads/pods/pod/), +El campo `.spec.template` es una [plantilla Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Tiene exactamente el mismo esquema que un [Pod](/docs/concepts/workloads/pods/pod/), excepto por el hecho de que está anidado y no tiene los campos `apiVersion` o `kind`. -Además de los campos obligatorios de un Pod, la plantilla Pod para un DaemonSet debe especificar +Además de los campos obligatorios de un Pod, la plantilla Pod para un DaemonSet debe especificar las etiquetas apropiadas (ver [selector de pod](#pod-selector)). Una plantilla Pod para un DaemonSet debe tener una [`RestartPolicy`](/docs/user-guide/pod-states) @@ -67,7 +58,7 @@ Una plantilla Pod para un DaemonSet debe tener una [`RestartPolicy`](/docs/user- ### Selector de Pod -El campo `.spec.selector` es un selector de pod. Funciona igual que el campo `.spec.selector` +El campo `.spec.selector` es un selector de pod. Funciona igual que el campo `.spec.selector` de un [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/). A partir de Kubernetes 1.8, se debe configurar un selector de pod que coincida con las @@ -86,15 +77,15 @@ Cuando se configura ambos campos, el resultado es conjuntivo (AND). Si se especifica el campo `.spec.selector`, entonces debe coincidir con el campo `.spec.template.metadata.labels`. Aquellas configuraciones que no coinciden, son rechazadas por la API. -Además, normalmente no se debería crear ningún Pod con etiquetas que coincidan con el selector, bien sea de forma directa, via otro +Además, normalmente no se debería crear ningún Pod con etiquetas que coincidan con el selector, bien sea de forma directa, via otro DaemonSet, o via otro controlador como un ReplicaSet. De ser así, el controlador del DaemonSet -pensará que dichos Pods fueron en realidad creados por él mismo. Kubernetes, en cualquier caso, no te impide realizar esta +pensará que dichos Pods fueron en realidad creados por él mismo. Kubernetes, en cualquier caso, no te impide realizar esta operación. Un caso donde puede que necesites hacer esto es cuando quieres crear manualmente un Pod con un valor diferente en un nodo para pruebas. -### Ejecutar Pods sólo en algunos Nodos +### Ejecutar Pods sólo en Nodos seleccionados Si se configura un `.spec.template.spec.nodeSelector`, entonces el controlador del DaemonSet - creará los Pods en aquellos nodos que coincidan con el [selector de nodo](/docs/concepts/configuration/assign-pod-node/) indicado. + creará los Pods en aquellos nodos que coincidan con el [selector de nodo](/docs/concepts/configuration/assign-pod-node/) indicado. De forma similar, si se configura una `.spec.template.spec.affinity`, entonces el controlador del DaemonSet creará los Pods en aquellos nodos que coincidan con la [afinidad de nodo](/docs/concepts/configuration/assign-pod-node/) indicada. Si no se configura ninguno de los dos, entonces el controlador del DaemonSet creará los Pods en todos los nodos. @@ -115,13 +106,13 @@ se indica el campo `.spec.nodeName`, y por ello el planificador los ignora). Por {{< feature-state state="beta" for-kubernetes-version="1.12" >}} -Un DaemonSet garantiza que todos los nodos elegibles ejecuten una copia de un Pod. +Un DaemonSet garantiza que todos los nodos elegibles ejecuten una copia de un Pod. Normalmente, es el planificador de Kubernetes quien determina el nodo donde se ejecuta un Pod. Sin embargo, los pods del DaemonSet son creados y planificados por el mismo controlador del DaemonSet. Esto introduce los siguientes inconvenientes: * Comportamiento inconsistente de los Pods: Los Pods normales que están esperando - a ser creados, se encuentran en estado `Pending`, pero los pods del DaemonSet no pasan por el estado `Pending`. + a ser creados, se encuentran en estado `Pending`, pero los pods del DaemonSet no pasan por el estado `Pending`. Esto confunde a los usuarios. * La [prioridad y el comportamiento de apropiación de Pods](/docs/concepts/configuration/pod-priority-preemption/) se maneja por el planificador por defecto. Cuando se habilita la contaminación, el controlador del DaemonSet @@ -130,7 +121,7 @@ Esto introduce los siguientes inconvenientes: `ScheduleDaemonSetPods` permite planificar DaemonSets usando el planificador por defecto en vez del controlador del DaemonSet, añadiendo la condición `NodeAffinity` a los pods del DaemonSet, en vez de la condición `.spec.nodeName`. El planificador por defecto -se usa entonces para asociar el pod a su servidor destino. Si la afinidad de nodo del +se usa entonces para asociar el pod a su servidor destino. Si la afinidad de nodo del pod del DaemonSet ya existe, se sustituye. El controlador del DaemonSet sólo realiza estas operaciones cuando crea o modifica los pods del DaemonSet, y no se realizan cambios al `spec.template` del DaemonSet. @@ -146,7 +137,7 @@ nodeAffinity: - target-host-name ``` -Adicionalmente, se añade de forma automática la tolerancia `node.kubernetes.io/unschedulable:NoSchedule` +Adicionalmente, se añade de forma automática la tolerancia `node.kubernetes.io/unschedulable:NoSchedule` a los Pods del DaemonSet. Así, el planificador por defecto ignora los nodos `unschedulable` cuando planifica los Pods del DaemonSet. @@ -158,23 +149,23 @@ A pesar de que los Pods de proceso respetan las la siguientes tolerancias son añadidas a los Pods del DaemonSet de forma automática según las siguientes características: -| Clave de tolerancia | Efecto | Versión | Descripción | -| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ | -| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red. | -| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red. | -| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de espacio en disco. | -| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de memoria. | -| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | Los pods del DaemonSet toleran los atributos unschedulable del planificador por defecto. | -| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | Los pods del DaemonSet, que usan la red del servidor anfitrión, toleran los atributos network-unavailable del planificador por defecto. | +| Clave de tolerancia | Efecto | Versión | Descripción | +| ---------------------------------------- | ---------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------- | +| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red. | +| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red. | +| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de espacio en disco. | +| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de memoria. | +| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | Los pods del DaemonSet toleran los atributos unschedulable del planificador por defecto. | +| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | Los pods del DaemonSet, que usan la red del servidor anfitrión, toleran los atributos network-unavailable del planificador por defecto. | ## Comunicarse con los Pods de los DaemonSets Algunos patrones posibles para la comunicación con los Pods de un DaemonSet son: -- **Push**: Los Pods del DaemonSet se configuran para enviar actualizaciones a otro servicio, +- **Push**: Los Pods del DaemonSet se configuran para enviar actualizaciones a otro servicio, como una base de datos de estadísticas. No tienen clientes. -- **NodeIP y Known Port**: Los Pods del DaemonSet pueden usar un `hostPort`, de forma que se les puede alcanzar via las IPs del nodo. Los clientes conocen la lista de IPs del nodo de algún modo, +- **NodeIP y Known Port**: Los Pods del DaemonSet pueden usar un `hostPort`, de forma que se les puede alcanzar via las IPs del nodo. Los clientes conocen la lista de IPs del nodo de algún modo, y conocen el puerto acordado. - **DNS**: Se crea un [servicio headless](/docs/concepts/services-networking/service/#headless-services) con el mismo selector de pod, y entonces se descubre a los DaemonSets usando los recursos `endpoints` o mediante múltiples registros de tipo A en el DNS. @@ -185,10 +176,10 @@ y conocen el puerto acordado. Si se cambian las etiquetas de nodo, el DaemonSet comenzará de forma inmediata a añadir Pods a los nuevos nodos que coincidan y a eliminar los Pods de aquellos nuevos nodos donde no coincidan. -Puedes modificar los Pods que crea un DaemonSet. Sin embargo, no se permite actualizar todos los campos de los Pods. +Puedes modificar los Pods que crea un DaemonSet. Sin embargo, no se permite actualizar todos los campos de los Pods. Además, el controlador del DaemonSet utilizará la plantilla original la próxima vez que se cree un nodo (incluso con el mismo nombre). -Puedes eliminar un DaemonSet. Si indicas el parámetro `--cascade=false` al usar `kubectl`, +Puedes eliminar un DaemonSet. Si indicas el parámetro `--cascade=false` al usar `kubectl`, entonces los Pods continuarán ejecutándose en los nodos. Así, puedes crear entonces un nuevo DaemonSet con una plantilla diferente. El nuevo DaemonSet con la plantilla diferente reconocerá a todos los Pods existentes que tengan etiquetas coincidentes y no modificará o eliminará ningún Pod aunque la plantilla no coincida con los Pods desplegados. @@ -198,14 +189,14 @@ A partir de las versión 1.6 de Kubernetes, puedes [llevar a cabo una actualizac ## Alternativas al DaemonSet -### Secuencias de comandos de inicialización +### Secuencias de comandos de inicialización Aunque es perfectamente posible ejecutar procesos arrancándolos directamente en un nodo (ej. usando `init`, `upstartd`, o `systemd`), existen numerosas ventajas si se realiza via un DaemonSet: - Capacidad de monitorizar y gestionar los logs de los procesos del mismo modo que para las aplicaciones. - Mismo lenguaje y herramientas de configuración (ej. plantillas de Pod, `kubectl`) tanto para los procesos como para las aplicaciones. -- Los procesos que se ejecutan en contenedores con límitaciones de recursos aumentan el aislamiento entre dichos procesos y el resto de contenedores de aplicaciones. +- Los procesos que se ejecutan en contenedores con límitaciones de recursos aumentan el aislamiento entre dichos procesos y el resto de contenedores de aplicaciones. Sin embargo, esto también se podría conseguir ejecutando los procesos en un contenedor en vez de un Pod (ej. arrancarlos directamente via Docker). @@ -231,8 +222,6 @@ ambos crean Pods, y que dichos Pods tienen procesos que no se espera que termine servidores de almacenamiento). Utiliza un Deployment para definir servicios sin estado, como las interfaces de usuario, donde el escalado vertical y horizontal -del número de réplicas y las actualizaciones continuas son mucho más importantes que el control exacto del servidor donde se ejecuta el Pod. -Utiliza un DaemonSet cuando es importante que una copia de un Pod siempre se ejecute en cada uno de los nodos, -y cuando se necesite que arranque antes que el resto de Pods. - - +del número de réplicas y las actualizaciones continuas son mucho más importantes que el control exacto del servidor donde se ejecuta el Pod. +Utiliza un DaemonSet cuando es importante que una copia de un Pod siempre se ejecute en cada uno de los nodos, +y cuando se necesite que arranque antes que el resto de Pods. \ No newline at end of file diff --git a/content/es/docs/concepts/workloads/controllers/deployment.md b/content/es/docs/concepts/workloads/controllers/deployment.md index 17a42882a0..9fc506ae01 100644 --- a/content/es/docs/concepts/workloads/controllers/deployment.md +++ b/content/es/docs/concepts/workloads/controllers/deployment.md @@ -84,16 +84,14 @@ Esto es útil para futuras introspecciones, por ejemplo para comprobar qué coma A continuación, ejecuta el comando `kubectl get deployments`. La salida debe ser parecida a la siguiente: ```shell -NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE -nginx-deployment 3 0 0 0 1s +NAME READY UP-TO-DATE AVAILABLE AGE +nginx-deployment 3/3 3 3 1s ``` Cuando inspeccionas los Deployments de tu clúster, se muestran los siguientes campos: * `NAME` enumera los nombre de los Deployments del clúster. -* `DESIRED` muestra el número deseado de _réplicas_ de la aplicación, que se define - cuando se crea el Deployment. Esto se conoce como el _estado deseado_. -* `CURRENT` muestra cuántas réplicas se están ejecutando actualment. +* `READY` muestra cuántas réplicas de la aplicación están disponibles para sus usuarios. Sigue el patrón número de réplicas `listas/deseadas`. * `UP-TO-DATE` muestra el número de réplicas que se ha actualizado para alcanzar el estado deseado. * `AVAILABLE` muestra cuántas réplicas de la aplicación están disponibles para los usuarios. * `AGE` muestra la cantidad de tiempo que la aplicación lleva ejecutándose. @@ -105,6 +103,20 @@ Nótese cómo los valores de cada campo corresponden a los valores de la especif * El número de réplicas actualizadas es 0 de acuerdo con el campo `.status.updatedReplicas`. * El número de réplicas disponibles es 0 de acuerdo con el campo `.status.availableReplicas`. +Si deseamos obtener más información del Deployment utilice el parámetro '-o wide', ejecutando el comando 'kubectl get deployments -o wide'. La salida será parecida a la siguiente: + +```shell +NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR +nginx-deployment 3/3 3 3 10s nginx nginx:1.7.9 app=nginx +``` + +Ejecutando el comando anterior se muestran los siguientes campos adicionales: + +* `CONTAINERS` muestra los nombres de los contenedores declarados en `.spec.template.spec.containers.[name]`. +* `IMAGES` muestra los nombres de las imágenes declaradas en `.spec.template.spec.containers.[image]`. +* 'SELECTOR' muestra el Label selector que se declaró en matchLabels o matchExpressions. + + Para ver el estado del Deployment, ejecuta el comando `kubectl rollout status deployment.v1.apps/nginx-deployment`. Este comando devuelve el siguiente resultado: ```shell @@ -115,8 +127,8 @@ deployment "nginx-deployment" successfully rolled out Ejecuta de nuevo el comando `kubectl get deployments` unos segundos más tarde: ```shell -NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE -nginx-deployment 3 3 3 3 18s +NAME READY UP-TO-DATE AVAILABLE AGE +nginx-deployment 3/3 3 3 18s ``` Fíjate que el Deployment ha creado todas las tres réplicas, y que todas las réplicas están actualizadas (contienen @@ -204,8 +216,8 @@ Cuando el despliegue funciona, puede que quieras `obtener` el Deployment: kubectl get deployments ``` ``` -NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE -nginx-deployment 3 3 3 3 36s +NAME READY UP-TO-DATE AVAILABLE AGE +nginx-deployment 3/3 3 3 36s ``` El número de réplicas actualizadas indica que el Deployment ha actualizado las réplicas según la última configuración. @@ -241,7 +253,7 @@ La próxima vez que quieras actualizar estos Pods, sólo necesitas actualizar la El Deployment permite garantizar que sólo un número determinado de Pods puede eliminarse mientras se están actualizando. Por defecto, garantiza que al menos el 25% menos del número deseado de Pods se está ejecutando (máx. 25% no disponible). -El Deployment tmabién permite garantizar que sólo un número determinado de Pods puede crearse por encima del número deseado de +El Deployment también permite garantizar que sólo un número determinado de Pods puede crearse por encima del número deseado de Pods. Por defecto, garantiza que al menos el 25% más del número deseado de Pods se está ejecutando (máx. 25% de aumento). Por ejemplo, si miras detenidamente el Deployment de arriba, verás que primero creó un Pod, @@ -515,8 +527,8 @@ al retroceder a la revisión 2. kubectl get deployment nginx-deployment ``` ``` -NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE -nginx-deployment 3 3 3 3 30m +NAME READY UP-TO-DATE AVAILABLE AGE +nginx-deployment 3/3 3 3 30m ``` ```shell @@ -601,8 +613,8 @@ Por ejemplo, imagina que estás ejecutando un Deployment con 10 réplicas, donde kubectl get deploy ``` ``` -NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE -nginx-deployment 10 10 10 10 50s +NAME READY UP-TO-DATE AVAILABLE AGE +nginx-deployment 10/10 10 10 50s ``` Si actualizas a una nueva imagen que no puede descargarse desde el clúster: @@ -641,8 +653,8 @@ réplicas arranquen positivamente. kubectl get deploy ``` ``` -NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE -nginx-deployment 15 18 7 8 7m +NAME READY UP-TO-DATE AVAILABLE AGE +nginx-deployment 18/15 7 8 7m ``` ```shell @@ -665,8 +677,8 @@ Por ejemplo, con un Deployment que acaba de crearse: kubectl get deploy ``` ``` -NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE -nginx 3 3 3 3 1m +NAME READY UP-TO-DATE AVAILABLE AGE +nginx-deployment 3/3 3 3 1m ``` ```shell kubectl get rs @@ -1106,5 +1118,3 @@ no generará nuevos despliegues mientras esté pausado. Un Deployment se pausa d [`kubectl rolling update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) actualiza los Pods y los ReplicationControllers de forma similar. Pero se recomienda el uso de Deployments porque se declaran del lado del servidor, y proporcionan características adicionales como la posibilidad de retroceder a revisiones anteriores incluso después de haber terminado una actualización continua. - - diff --git a/content/es/docs/concepts/workloads/pods/_index.md b/content/es/docs/concepts/workloads/pods/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/getting-started-guides/_index.md b/content/es/docs/getting-started-guides/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/getting-started-guides/fedora/_index.md b/content/es/docs/getting-started-guides/fedora/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/application-architect.md b/content/es/docs/reference/glossary/application-architect.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/application-developer.md b/content/es/docs/reference/glossary/application-developer.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/certificate.md b/content/es/docs/reference/glossary/certificate.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/cluster.md b/content/es/docs/reference/glossary/cluster.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/container-runtime.md b/content/es/docs/reference/glossary/container-runtime.md index 597ceaf25c..fd3328e799 100644 --- a/content/es/docs/reference/glossary/container-runtime.md +++ b/content/es/docs/reference/glossary/container-runtime.md @@ -2,7 +2,7 @@ title: Container Runtime id: container-runtime date: 2019-06-05 -full_link: /es/docs/reference/generated/container-runtime +full_link: /docs/setup/production-environment/container-runtimes short_description: > El _Container Runtime_, entorno de ejecución de un contenedor, es el software responsable de ejecutar contenedores. diff --git a/content/es/docs/reference/glossary/controller.md b/content/es/docs/reference/glossary/controller.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/docker.md b/content/es/docs/reference/glossary/docker.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/etcd.md b/content/es/docs/reference/glossary/etcd.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/image.md b/content/es/docs/reference/glossary/image.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/index.md b/content/es/docs/reference/glossary/index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/job.md b/content/es/docs/reference/glossary/job.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/kops.md b/content/es/docs/reference/glossary/kops.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/kube-apiserver.md b/content/es/docs/reference/glossary/kube-apiserver.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/kube-controller-manager.md b/content/es/docs/reference/glossary/kube-controller-manager.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/kube-proxy.md b/content/es/docs/reference/glossary/kube-proxy.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/kube-scheduler.md b/content/es/docs/reference/glossary/kube-scheduler.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/kubeadm.md b/content/es/docs/reference/glossary/kubeadm.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/kubectl.md b/content/es/docs/reference/glossary/kubectl.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/kubelet.md b/content/es/docs/reference/glossary/kubelet.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/label.md b/content/es/docs/reference/glossary/label.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/limitrange.md b/content/es/docs/reference/glossary/limitrange.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/minikube.md b/content/es/docs/reference/glossary/minikube.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/namespace.md b/content/es/docs/reference/glossary/namespace.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/node.md b/content/es/docs/reference/glossary/node.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/persistent-volume-claim.md b/content/es/docs/reference/glossary/persistent-volume-claim.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/pod.md b/content/es/docs/reference/glossary/pod.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/replica-set.md b/content/es/docs/reference/glossary/replica-set.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/secret.md b/content/es/docs/reference/glossary/secret.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/selector.md b/content/es/docs/reference/glossary/selector.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/sysctl.md b/content/es/docs/reference/glossary/sysctl.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/glossary/volume.md b/content/es/docs/reference/glossary/volume.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/kubectl/_index.md b/content/es/docs/reference/kubectl/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/reference/setup-tools/kubeadm/_index.md b/content/es/docs/reference/setup-tools/kubeadm/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/setup/independent/_index.md b/content/es/docs/setup/independent/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/setup/release/_index.md b/content/es/docs/setup/release/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tasks/access-application-cluster/_index.md b/content/es/docs/tasks/access-application-cluster/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tasks/access-kubernetes-api/_index.md b/content/es/docs/tasks/access-kubernetes-api/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tasks/access-kubernetes-api/custom-resources/_index.md b/content/es/docs/tasks/access-kubernetes-api/custom-resources/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tasks/administer-cluster/_index.md b/content/es/docs/tasks/administer-cluster/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tasks/administer-cluster/kubeadm/_index.md b/content/es/docs/tasks/administer-cluster/kubeadm/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tasks/configure-pod-container/_index.md b/content/es/docs/tasks/configure-pod-container/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tasks/debug-application-cluster/logging-stackdriver.md b/content/es/docs/tasks/debug-application-cluster/logging-stackdriver.md deleted file mode 100644 index 3a247b5e88..0000000000 --- a/content/es/docs/tasks/debug-application-cluster/logging-stackdriver.md +++ /dev/null @@ -1,366 +0,0 @@ ---- -title: Escribiendo Logs con Stackdriver -content_type: concept ---- - - - -Antes de seguir leyendo esta página, deberías familiarizarte con el -[resumen de escritura de logs en Kubernetes](/docs/concepts/cluster-administration/logging). - -{{< note >}} -Por defecto, Stackdriver recolecta toda la salida estándar de tus contenedores, así -como el flujo de la salida de error. Para recolectar cualquier log tu aplicación escribe en un archivo (por ejemplo), -ver la [estrategia de sidecar](/docs/concepts/cluster-administration/logging#sidecar-container-with-a-logging-agent) -en el resumen de escritura de logs en Kubernetes. -{{< /note >}} - - - - - - -## Despliegue - -Para ingerir logs, debes desplegar el agente de Stackdriver Logging en cada uno de los nodos de tu clúster. -Dicho agente configura una instancia de `fluentd`, donde la configuración se guarda en un `ConfigMap` -y las instancias se gestionan a través de un `DaemonSet` de Kubernetes. El despliegue actual del -`ConfigMap` y el `DaemonSet` dentro de tu clúster depende de tu configuración individual del clúster. - -### Desplegar en un nuevo clúster - -#### Google Kubernetes Engine - -Stackdriver es la solución por defecto de escritura de logs para aquellos clústeres desplegados en Google Kubernetes Engine. -Stackdriver Logging se despliega por defecto en cada clúster a no ser que se le indique de forma explícita no hacerlo. - -#### Otras plataformas - -Para desplegar Stackdriver Logging en un *nuevo* clúster que estés creando con -`kube-up.sh`, haz lo siguiente: - -1. Configura la variable de entorno `KUBE_LOGGING_DESTINATION` con el valor `gcp`. -1. **Si no estás trabajando en GCE**, incluye `beta.kubernetes.io/fluentd-ds-ready=true` -en la variable `KUBE_NODE_LABELS`. - -Una vez que tu clúster ha arrancado, cada nodo debería ejecutar un agente de Stackdriver Logging. -Los `DaemonSet` y `ConfigMap` se configuran como extras. Si no estás usando `kube-up.sh`, -considera la posibilidad de arrancar un clúster sin una solución pre-determinada de escritura de logs -y entonces desplegar los agentes de Stackdriver Logging una vez el clúster esté ejecutándose. - -{{< warning >}} -El proceso de Stackdriver Logging reporta problemas conocidos en plataformas distintas -a Google Kubernetes Engine. Úsalo bajo tu propio riesgo. -{{< /warning >}} - -### Desplegar a un clúster existente - -1. Aplica una etiqueta en cada nodo, si no estaba presente ya. - - El despliegue del agente de Stackdriver Logging utiliza etiquetas de nodo para - determinar en qué nodos debería desplegarse. Estas etiquetas fueron introducidas - para distinguir entre nodos de Kubernetes de la versión 1.6 o superior. - Si el clúster se creó con Stackdriver Logging configurado y el nodo tiene la - versión 1.5.X o inferior, ejecutará fluentd como un pod estático. Puesto que un nodo - no puede tener más de una instancia de fluentd, aplica únicamente las etiquetas - a los nodos que no tienen un pod de fluentd ya desplegado. Puedes confirmar si tu nodo - ha sido etiquetado correctamente ejecutando `kubectl describe` de la siguiente manera: - - ``` - kubectl describe node $NODE_NAME - ``` - - La salida debería ser similar a la siguiente: - - ``` - Name: NODE_NAME - Role: - Labels: beta.kubernetes.io/fluentd-ds-ready=true - ... - ``` - - Asegúrate que la salida contiene la etiqueta `beta.kubernetes.io/fluentd-ds-ready=true`. - Si no está presente, puedes añadirla usando el comando `kubectl label` como se indica: - - ``` - kubectl label node $NODE_NAME beta.kubernetes.io/fluentd-ds-ready=true - ``` - - {{< note >}} - Si un nodo falla y tiene que volver a crearse, deberás volver a definir - la etiqueta al nuevo nodo. Para facilitar esta tarea, puedes utilizar el - parámetro de línea de comandos del Kubelet para aplicar dichas etiquetas - cada vez que se arranque un nodo. - {{< /note >}} - -1. Despliega un `ConfigMap` con la configuración del agente de escritura de logs ejecutando el siguiente comando: - - ``` - kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-configmap.yaml - ``` - - Este comando crea el `ConfigMap` en el espacio de nombres `default`. Puedes descargar el archivo - manualmente y cambiarlo antes de crear el objeto `ConfigMap`. - -1. Despliega el agente `DaemonSet` de escritura de logs ejecutando el siguiente comando: - - ``` - kubectl apply -f https://k8s.io/examples/debug/fluentd-gcp-ds.yaml - ``` - - Puedes descargar y editar este archivo antes de usarlo igualmente. - -## Verificar el despliegue de tu agente de escritura de logs - -Tras el despliegue del `DaemonSet` de StackDriver, puedes comprobar el estado de -cada uno de los despliegues de los agentes ejecutando el siguiente comando: - -```shell -kubectl get ds --all-namespaces -``` - -Si tienes 3 nodos en el clúster, la salida debería ser similar a esta: - -``` -NAMESPACE NAME DESIRED CURRENT READY NODE-SELECTOR AGE -... -default fluentd-gcp-v2.0 3 3 3 beta.kubernetes.io/fluentd-ds-ready=true 5m -... -``` -Para comprender cómo funciona Stackdriver, considera la siguiente especificación -de un generador de logs sintéticos [counter-pod.yaml](/examples/debug/counter-pod.yaml): - -{{< codenew file="debug/counter-pod.yaml" >}} - -Esta especificación de pod tiene un contenedor que ejecuta una secuencia de comandos bash -que escribe el valor de un contador y la fecha y hora cada segundo, de forma indefinida. -Vamos a crear este pod en el espacio de nombres por defecto. - -```shell -kubectl apply -f https://k8s.io/examples/debug/counter-pod.yaml -``` - -Puedes observar el pod corriendo: - -```shell -kubectl get pods -``` -``` -NAME READY STATUS RESTARTS AGE -counter 1/1 Running 0 5m -``` - -Durante un período de tiempo corto puedes observar que el estado del pod es 'Pending', debido a que el kubelet -tiene primero que descargar la imagen del contenedor. Cuando el estado del pod cambia a `Running` -puedes usar el comando `kubectl logs` para ver la salida de este pod contador. - -```shell -kubectl logs counter -``` -``` -0: Mon Jan 1 00:00:00 UTC 2001 -1: Mon Jan 1 00:00:01 UTC 2001 -2: Mon Jan 1 00:00:02 UTC 2001 -... -``` - -Como se describe en el resumen de escritura de logs, este comando visualiza las entradas de logs -del archivo de logs del contenedor. Si se termina el contenedor y Kubernetes lo reinicia, -todavía puedes acceder a los logs de la ejecución previa del contenedor. Sin embargo, -si el pod se desaloja del nodo, los archivos de log se pierden. Vamos a demostrar este -comportamiento mediante el borrado del contenedor que ejecuta nuestro contador: - -```shell -kubectl delete pod counter -``` -``` -pod "counter" deleted -``` - -y su posterior re-creación: - -```shell -kubectl create -f https://k8s.io/examples/debug/counter-pod.yaml -``` -``` -pod/counter created -``` - -Tras un tiempo, puedes acceder a los logs del pod contador otra vez: - -```shell -kubectl logs counter -``` -``` -0: Mon Jan 1 00:01:00 UTC 2001 -1: Mon Jan 1 00:01:01 UTC 2001 -2: Mon Jan 1 00:01:02 UTC 2001 -... -``` - -Como era de esperar, únicamente se visualizan las líneas de log recientes. Sin embargo, -para una aplicación real seguramente prefieras acceder a los logs de todos los contenedores, -especialmente cuando te haga falta depurar problemas. Aquí es donde haber habilitado -Stackdriver Logging puede ayudarte. - -## Ver logs - -El agente de Stackdriver Logging asocia metadatos a cada entrada de log, para que puedas usarlos posteriormente -en consultas para seleccionar sólo los mensajes que te interesan: por ejemplo, -los mensajes de un pod en particular. - -Los metadatos más importantes son el tipo de recurso y el nombre del log. -El tipo de recurso de un log de contenedor tiene el valor `container`, que se muestra como -`GKE Containers` en la UI (incluso si el clúster de Kubernetes no está en Google Kubernetes Engine). -El nombre de log es el nombre del contenedor, de forma que si tienes un pod con -dos contenedores, denominados `container_1` y `container_2` en la especificación, sus logs -tendrán los nombres `container_1` y `container_2` respectivamente. - -Los componentes del sistema tienen el valor `compute` como tipo de recursos, que se muestra como -`GCE VM Instance` en la UI. Los nombres de log para los componentes del sistema son fijos. -Para un nodo de Google Kubernetes Engine, cada entrada de log de cada componente de sistema tiene uno de los siguientes nombres: - -* docker -* kubelet -* kube-proxy - -Puedes aprender más acerca de cómo visualizar los logs en la [página dedicada a Stackdriver](https://cloud.google.com/logging/docs/view/logs_viewer). - -Uno de los posibles modos de ver los logs es usando el comando de línea de interfaz -[`gcloud logging`](https://cloud.google.com/logging/docs/api/gcloud-logging) -del [SDK de Google Cloud](https://cloud.google.com/sdk/). -Este comando usa la [sintaxis de filtrado](https://cloud.google.com/logging/docs/view/advanced_filters) de StackDriver Logging -para consultar logs específicos. Por ejemplo, puedes ejecutar el siguiente comando: - -```none -gcloud beta logging read 'logName="projects/$YOUR_PROJECT_ID/logs/count"' --format json | jq '.[].textPayload' -``` -``` -... -"2: Mon Jan 1 00:01:02 UTC 2001\n" -"1: Mon Jan 1 00:01:01 UTC 2001\n" -"0: Mon Jan 1 00:01:00 UTC 2001\n" -... -"2: Mon Jan 1 00:00:02 UTC 2001\n" -"1: Mon Jan 1 00:00:01 UTC 2001\n" -"0: Mon Jan 1 00:00:00 UTC 2001\n" -``` - -Como puedes observar, muestra los mensajes del contenedor contador tanto de la -primera como de la segunda ejecución, a pesar de que el kubelet ya había eliminado los logs del primer contenedor. - -### Exportar logs - -Puedes exportar los logs al [Google Cloud Storage](https://cloud.google.com/storage/) -o a [BigQuery](https://cloud.google.com/bigquery/) para llevar a cabo un análisis más profundo. -Stackdriver Logging ofrece el concepto de destinos, donde puedes especificar el destino de -las entradas de logs. Más información disponible en la [página de exportación de logs](https://cloud.google.com/logging/docs/export/configure_export_v2) de StackDriver. - -## Configurar los agentes de Stackdriver Logging - -En ocasiones la instalación por defecto de Stackdriver Logging puede que no se ajuste a tus necesidades, por ejemplo: - -* Puede que quieras añadir más recursos porque el rendimiento por defecto no encaja con tus necesidades. -* Puede que quieras añadir un parseo adicional para extraer más metadatos de tus mensajes de log, -como la severidad o referencias al código fuente. -* Puede que quieras enviar los logs no sólo a Stackdriver o sólo enviarlos a Stackdriver parcialmente. - -En cualquiera de estos casos, necesitas poder cambiar los parámetros del `DaemonSet` y el `ConfigMap`. - -### Prerequisitos - -Si estás usando GKE y Stackdriver Logging está habilitado en tu clúster, no puedes -cambiar su configuración, porque ya está gestionada por GKE. -Sin embargo, puedes deshabilitar la integración por defecto y desplegar la tuya propia. - -{{< note >}} -Tendrás que mantener y dar soporte tú mismo a la nueva configuración desplegada: -actualizar la imagen y la configuración, ajustar los recuros y todo eso. -{{< /note >}} - -Para deshabilitar la integración por defecto, usa el siguiente comando: - -``` -gcloud beta container clusters update --logging-service=none CLUSTER -``` - -Puedes encontrar notas acerca de cómo instalar los agentes de Stackdriver Logging - en un clúster ya ejecutándose en la [sección de despliegue](#deploying). - -### Cambiar los parámetros del `DaemonSet` - -Cuando tienes un `DaemonSet` de Stackdriver Logging en tu clúster, puedes simplemente -modificar el campo `template` en su especificación, y el controlador del daemonset actualizará los pods por ti. Por ejemplo, -asumamos que acabas de instalar el Stackdriver Logging como se describe arriba. Ahora quieres cambiar -el límite de memoria que se le asigna a fluentd para poder procesar más logs de forma segura. - -Obtén la especificación del `DaemonSet` que corre en tu clúster: - -```shell -kubectl get ds fluentd-gcp-v2.0 --namespace kube-system -o yaml > fluentd-gcp-ds.yaml -``` - -A continuación, edita los requisitos del recurso en el `spec` y actualiza el objeto `DaemonSet` -en el apiserver usando el siguiente comando: - -```shell -kubectl replace -f fluentd-gcp-ds.yaml -``` - -Tras un tiempo, los pods de agente de Stackdriver Logging se reiniciarán con la nueva configuración. - -### Cambiar los parámetros de fluentd - -La configuración de Fluentd se almacena en un objeto `ConfigMap`. Realmente se trata de un conjunto -de archivos de configuración que se combinan conjuntamente. Puedes aprender acerca de -la configuración de fluentd en el [sitio oficial](http://docs.fluentd.org). - -Imagina que quieres añadir una nueva lógica de parseo a la configuración actual, de forma que fluentd pueda entender -el formato de logs por defecto de Python. Un filtro apropiado de fluentd para conseguirlo sería: - -``` - - type parser - format /^(?\w):(?\w):(?.*)/ - reserve_data true - suppress_parse_error_log true - key_name log - -``` - -Ahora tienes que añadirlo a la configuración actual y que los agentes de Stackdriver Logging la usen. -Para ello, obtén la versión actual del `ConfigMap` de Stackdriver Logging de tu clúster -ejecutando el siguiente comando: - -```shell -kubectl get cm fluentd-gcp-config --namespace kube-system -o yaml > fluentd-gcp-configmap.yaml -``` - -Luego, como valor de la clave `containers.input.conf`, inserta un nuevo filtro justo después -de la sección `source`. - -{{< note >}} -El orden es importante. -{{< /note >}} - -Actualizar el `ConfigMap` en el apiserver es más complicado que actualizar el `DaemonSet`. -Es mejor considerar que un `ConfigMap` es inmutable. Así, para poder actualizar la configuración, deberías -crear un nuevo `ConfigMap` con otro nombre y cambiar el `DaemonSet` para que apunte al nuevo -siguiendo la [guía de arriba](#changing-daemonset-parameters). - -### Añadir plugins de fluentd - -Fluentd está desarrollado en Ruby y permite extender sus capacidades mediante el uso de -[plugins](http://www.fluentd.org/plugins). Si quieres usar un plugin que no está incluido en -la imagen por defecto del contenedor de Stackdriver Logging, debes construir tu propia imagen. -Imagina que quieres añadir un destino Kafka para aquellos mensajes de un contenedor en particular -para poder procesarlos posteriormente. Puedes reusar los [fuentes de imagen de contenedor](https://git.k8s.io/contrib/fluentd/fluentd-gcp-image) -con algunos pequeños cambios: - -* Cambia el archivo Makefile para que apunte a tu repositorio de contenedores, ej. `PREFIX=gcr.io/`. -* Añade tu dependencia al archivo Gemfile, por ejemplo `gem 'fluent-plugin-kafka'`. - -Luego, ejecuta `make build push` desde ese directorio. Cuando el `DaemonSet` haya tomado los cambios de la nueva imagen, -podrás usar el plugin que has indicado en la configuración de fluentd. - - diff --git a/content/es/docs/tasks/federation/_index.md b/content/es/docs/tasks/federation/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tasks/federation/administer-federation/_index.md b/content/es/docs/tasks/federation/administer-federation/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tasks/inject-data-application/_index.md b/content/es/docs/tasks/inject-data-application/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tasks/manage-daemon/_index.md b/content/es/docs/tasks/manage-daemon/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tasks/run-application/_index.md b/content/es/docs/tasks/run-application/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tasks/service-catalog/_index.md b/content/es/docs/tasks/service-catalog/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tasks/tls/_index.md b/content/es/docs/tasks/tls/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tasks/tools/install-kubectl.md b/content/es/docs/tasks/tools/install-kubectl.md index af1abeb63d..fdca3db92c 100644 --- a/content/es/docs/tasks/tools/install-kubectl.md +++ b/content/es/docs/tasks/tools/install-kubectl.md @@ -188,7 +188,7 @@ Si estás en macOS y utilizas el gestor de paquetes [Macports](https://macports. ### Instalar el binario de kubectl con curl en Windows -1. Descargar la última entrega {{< param "fullversion" >}} de [este link]((https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe). +1. Descargar la última entrega {{< param "fullversion" >}} de [este link](https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe). o si tiene `curl` instalada, utiliza este comando: diff --git a/content/es/docs/tutorials/_index.md b/content/es/docs/tutorials/_index.md index 47db2da8b9..27c804973a 100644 --- a/content/es/docs/tutorials/_index.md +++ b/content/es/docs/tutorials/_index.md @@ -31,6 +31,8 @@ Antes de recorrer cada tutorial, recomendamos añadir un marcador a ## Configuración +* [Ejemplo: Configurando un Microservicio en Java](/docs/tutorials/configuration/configure-java-microservice/) + * [Configuring Redis Using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/) ## Aplicaciones Stateless @@ -53,6 +55,8 @@ Antes de recorrer cada tutorial, recomendamos añadir un marcador a * [AppArmor](/docs/tutorials/clusters/apparmor/) +* [seccomp](/docs/tutorials/clusters/seccomp/) + ## Servicios * [Using Source IP](/docs/tutorials/services/source-ip/) diff --git a/content/es/docs/tutorials/clusters/_index.md b/content/es/docs/tutorials/clusters/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tutorials/configuration/_index.md b/content/es/docs/tutorials/configuration/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tutorials/kubernetes-basics/_index.md b/content/es/docs/tutorials/kubernetes-basics/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/es/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index a91e00f679..6743729d49 100644 --- a/content/es/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/es/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/es/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/es/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 28a2f35a0e..2ec6de59e9 100644 --- a/content/es/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/es/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/es/docs/tutorials/online-training/_index.md b/content/es/docs/tutorials/online-training/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tutorials/services/_index.md b/content/es/docs/tutorials/services/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tutorials/stateful-application/_index.md b/content/es/docs/tutorials/stateful-application/_index.md old mode 100755 new mode 100644 diff --git a/content/es/docs/tutorials/stateless-application/_index.md b/content/es/docs/tutorials/stateless-application/_index.md old mode 100755 new mode 100644 diff --git a/content/es/examples/controllers/daemonset.yaml b/content/es/examples/controllers/daemonset.yaml index f6c598c9bf..e41e0a6b6f 100644 --- a/content/es/examples/controllers/daemonset.yaml +++ b/content/es/examples/controllers/daemonset.yaml @@ -16,6 +16,7 @@ spec: spec: tolerations: - key: node-role.kubernetes.io/master + operator: Exists effect: NoSchedule containers: - name: fluentd-elasticsearch diff --git a/content/fr/_index.html b/content/fr/_index.html index 53c11593db..836e5b7504 100644 --- a/content/fr/_index.html +++ b/content/fr/_index.html @@ -43,12 +43,12 @@ Kubernetes est une solution open-source qui vous permet de tirer parti de vos in

    - Venez au KubeCon NA Virtuel du 17 au 20 Novembre 2020 + Venez au KubeCon NA Los Angeles, USA du 11 au 15 Octobre 2021



    - Venez au KubeCon EU Virtuel du 4 au 7 Mai 2021 + Venez au KubeCon EU Valence, Espagne du 15 au 20 Mai 2022
    diff --git a/content/fr/docs/concepts/architecture/_index.md b/content/fr/docs/concepts/architecture/_index.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/concepts/architecture/nodes.md b/content/fr/docs/concepts/architecture/nodes.md index fd211a1a35..f493fe5b17 100644 --- a/content/fr/docs/concepts/architecture/nodes.md +++ b/content/fr/docs/concepts/architecture/nodes.md @@ -12,7 +12,7 @@ weight: 10 Un nœud est une machine de travail dans Kubernetes, connue auparavant sous le nom de `minion`. Un nœud peut être une machine virtuelle ou une machine physique, selon le cluster. Chaque nœud contient les services nécessaires à l'exécution de [pods](/docs/concepts/workloads/pods/pod/) et est géré par les composants du master. -Les services sur un nœud incluent le [container runtime](/docs/concepts/overview/components/#node-components), kubelet and kube-proxy. +Les services sur un nœud incluent le [container runtime](/docs/concepts/overview/components/#node-components), kubelet et kube-proxy. Consultez la section [Le Nœud Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) dans le document de conception de l'architecture pour plus de détails. @@ -141,6 +141,7 @@ Sinon, le contrôleur de nœud supprime le nœud de sa liste de nœuds. La troisième est la surveillance de la santé des nœuds. Le contrôleur de noeud est responsable de la mise à jour de la condition NodeReady de NodeStatus vers ConditionUnknown lorsqu'un noeud devient inaccessible (le contrôleur de noeud cesse de recevoir des heartbeats pour une raison quelconque, par exemple en raison d'une panne du noeud), puis de l'éviction ultérieure de tous les pods du noeud. (en utilisant une terminaison propre) si le nœud continue d’être inaccessible. (Les délais d'attente par défaut sont de 40 secondes pour commencer à signaler ConditionUnknown et de 5 minutes après cela pour commencer à expulser les pods.) + Le contrôleur de nœud vérifie l'état de chaque nœud toutes les `--node-monitor-period` secondes. Dans les versions de Kubernetes antérieures à 1.13, NodeStatus correspond au heartbeat du nœud. @@ -157,6 +158,7 @@ Dans la plupart des cas, le contrôleur de noeud limite le taux d’expulsion à Le comportement d'éviction de noeud change lorsqu'un noeud d'une zone de disponibilité donnée devient défaillant. Le contrôleur de nœud vérifie quel pourcentage de nœuds de la zone est défaillant (la condition NodeReady est ConditionUnknown ou ConditionFalse) en même temps. Si la fraction de nœuds défaillant est au moins `--unhealthy-zone-threshold` (valeur par défaut de 0,55), le taux d'expulsion est réduit: si le cluster est petit (c'est-à-dire inférieur ou égal à ` --large-cluster-size-threshold` noeuds - valeur par défaut 50) puis les expulsions sont arrêtées, sinon le taux d'expulsion est réduit à `--secondary-node-eviction-rate` (valeur par défaut de 0,01) par seconde. + Ces stratégies sont implémentées par zone de disponibilité car une zone de disponibilité peut être partitionnée à partir du master, tandis que les autres restent connectées. Si votre cluster ne s'étend pas sur plusieurs zones de disponibilité de fournisseur de cloud, il n'existe qu'une seule zone de disponibilité (la totalité du cluster). diff --git a/content/fr/docs/concepts/cluster-administration/_index.md b/content/fr/docs/concepts/cluster-administration/_index.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/concepts/cluster-administration/logging.md b/content/fr/docs/concepts/cluster-administration/logging.md index 465ec742b1..0932de7406 100644 --- a/content/fr/docs/concepts/cluster-administration/logging.md +++ b/content/fr/docs/concepts/cluster-administration/logging.md @@ -82,7 +82,7 @@ conteneur a crashé. Si le Pod a plusieurs conteneurs, il faut spécifier le nom du conteneur dont on veut récupérer le journal d'évènement. Dans notre exemple le conteneur s'appelle -`count` donc vous pouvez utiliser `kubectl logs counter count`. Plus de détails +`count` donc vous pouvez utiliser `kubectl logs counter count`. Plus de détails dans la [documentation de `kubectl logs`] (/docs/reference/generated/kubectl/kubectl-commands#logs) diff --git a/content/fr/docs/concepts/services-networking/_index.md b/content/fr/docs/concepts/services-networking/_index.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/concepts/workloads/_index.md b/content/fr/docs/concepts/workloads/_index.md index 1d81794f7b..4561edb155 100644 --- a/content/fr/docs/concepts/workloads/_index.md +++ b/content/fr/docs/concepts/workloads/_index.md @@ -1,4 +1,51 @@ --- title: Workloads weight: 50 +description: > + Comprendre les Pods, le plus petit objet déployable sur Kubernetes, et les abstractions de haut niveaux vous permettant de les lancer. +no_list: true --- + + + + +Un workload (charge de travail) est une application fonctionnant sur Kubernetes. Que votre workload soit un composant unique ou un agrégat de composants, sur Kubernetes celui-ci fonctionnera dans une série de pods. Dans Kubernetes, un Pod represente un ensemble de conteneur (containers) en fonctionnement sur votre cluster. + +Les pods Kubernetes ont un cycle de vie définit (defined lifecycle). Par exemple, quand un pod est en fonction sur votre cluster et qu’une panne critique survient sur le noeud (node) où se situe ce pod, tous les pods du noeud seront en échec. Kubernetes traite ce niveau d’échec comme un état final : +Vous devez créer un nouveau Pod pour retrouver l’état initial même si le noeud redevient sain. + +Cependant, pour vous simplifier la vie, vous n’avez pas a gérer chaque Pod directement. Vous pouvez utiliser une ressource workload qui gère votre groupe de pods à votre place. Ces ressources configurent des controleurs (controllers) qui s’assurent que le bon nombre et le bon type de pod soit en fonction pour égaler l’état que vous avez spécifié. + +Kubernetes fournit plusieurs ressources workload pré-faites : + +* [`Deployment`](/docs/concepts/workloads/controllers/deployment/) et [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) +(qui remplacent l’ancienne ressource {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}})). +Le `Deployment` (déploiement) est une bonne approche pour manager une application stateless sur votre cluster, tous les `Pods` d’un `Deployment` sont interchangeables et peuvent être remplacés si besoin. +* Le [`StatefulSet`](/docs/concepts/workloads/controllers/statefulset/) vous permet de lancer un ou plusieurs Pods en relation qui garde plus ou moins la trace de leurs état. +Par exemple si votre workload enregistre des données de façon persistente, vous pouvez lancer un `StatefulSet` qui fera le lien entre les `Pods` et un volume persistent ([`PersistentVolume`](/docs/concepts/storage/persistent-volumes/)). +Votre code, présent dans les `Pods` du `StatefulSet`, peut répliquer des données dans les autres `Pods` qui sont dans le même `StatefulSet`, +pour améliorer la résilience global. +* Le [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) permet de définir les `Pods` qui effectuent des actions sur le noeud local. +Ceux-ci peuvent être fondamental aux opérations de votre cluster, comme un outil d’aide réseau, ou peuvent faire part d’un module complémentaire (add-on). +Pour chaque nouveau noeud ajouté au cluster, le controle plane organise l'ajout d'un `Pod` pour ce `DaemonSet` sur le nouveau noeud. +* Les [`Job`](/docs/concepts/workloads/controllers/job/) et [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) sont des taches lancées jusqu’à accomplissement puis s’arrêtent. Les `Jobs` réprésentent une tâche ponctuelle, les `CronJob` sont des tâches récurrentes planifiés. + +Dans l’écosystème étendu de Kubernetes, vous pouvez trouver des ressources workload de fournisseurs tiers qui offrent des fonctionnalités supplémentaires. +L’utilisation d’un [`CustomResourceDefinition`](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) permet d’ajouter une ressource workload d’un fournisseur tiers si vous souhaitez rajouter une fonctionnalité ou un comportement spécifique qui ne fait pas partie du noyau de Kubernetes. +Par exemple, si vous voulez lancer un groupe de `Pods` pour votre application mais que vous devez arrêter leurs fonctionnement tant qu’ils ne sont pas tous disponibles, alors vous pouvez implémenter ou installer une extension qui permet cette fonctionnalité. + +## {{% heading "whatsnext" %}} +Vous pouvez continuer la lecture des ressources, vous pouvez aussi apprendre à connaitre les taches qui leurs sont liées : +* Lancer une [application stateless en utilisant un `Deployment`](/docs/tasks/run-application/run-stateless-application-deployment/). +* Lancer une application statefull, soit comme [instance unique](/docs/tasks/run-application/run-single-instance-stateful-application/) + ou alors comme un [ensemble répliqué](/docs/tasks/run-application/run-replicated-stateful-application/). +* Lancer une [tâche automatisée avec un `CronJob`](/docs/tasks/job/automated-tasks-with-cron-jobs/). + +Pour en apprendre plus sur les méchanismes de Kubernetes, de séparation du code et de la configuration, +allez voir [Configuration](/docs/concepts/configuration/). + +Il y a deux concepts supportés qui fournissent un contexte sur le sujet : comment Kubernetes gère les pods pour les applications : +* Le [ramasse-miettes](/docs/concepts/workloads/controllers/garbage-collection/), fait le ménage dans votre cluster après qu’une de _vos ressource_ soit supprimé. +* Le [temps de vie d’un controlleur éteint](/docs/concepts/workloads/controllers/ttlafterfinished/) supprime les Jobs une fois qu’un temps définit soit passé après son accomplissement. + +Une fois que votre application est lancée, vous souhaitez peut etre la rendre disponible sur internet comme un [Service](/docs/concepts/services-networking/service/) ou comme une application web uniquement en utilsant un [Ingress](/docs/concepts/services-networking/ingress). diff --git a/content/fr/docs/concepts/workloads/controllers/replicaset.md b/content/fr/docs/concepts/workloads/controllers/replicaset.md index 81ccb6e7b3..820c8bb42d 100644 --- a/content/fr/docs/concepts/workloads/controllers/replicaset.md +++ b/content/fr/docs/concepts/workloads/controllers/replicaset.md @@ -214,7 +214,7 @@ Un ReplicaSet a également besoin de [`.spec` section](https://git.k8s.io/commun L'attribut `.spec.template` est un [modèle de pod](/docs/concepts/workloads/Pods/pod-overview/#pod-templates) qui requiert d'avoir des labels. Dans notre exemple `frontend.yaml`, nous avons un label : `tier: frontend`. Il faut faire attention à ne pas avoir des selecteurs que d'autres controllers utilisent, afin d'éviter que le ReplicaSet n'adopte ce pod. -Pour le champ [restart policy](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy), +Pour le champ [restart policy](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy), `.spec.template.spec.restartPolicy`, la seule valeur autorisée est `Always`, qui est la valeur par défaut. ### Sélecteur de Pod diff --git a/content/fr/docs/concepts/workloads/controllers/statefulset.md b/content/fr/docs/concepts/workloads/controllers/statefulset.md new file mode 100644 index 0000000000..f223a8432f --- /dev/null +++ b/content/fr/docs/concepts/workloads/controllers/statefulset.md @@ -0,0 +1,278 @@ +--- +title: StatefulSets +content_type: concept +weight: 30 +--- + + + +StatefulSet est l'objet de l'API de charge de travail utilisé pour gérer des applications avec état (*stateful*). + +{{< glossary_definition term_id="statefulset" length="all" >}} + + + + +## Utiliser des StatefulSets + +Les StatefulSets sont utiles pour des applications qui nécessitent une ou plusieurs des choses suivantes : + +* Des identifiants réseau stables et uniques. +* Un stockage persistant stable. +* Un déploiement et une mise à l'échelle ordonnés et contrôlés. +* Des mises à jour continues (*rolling update*) ordonnées et automatisées. + +Ci-dessus, stable est synonyme de persistance suite au (re)scheduling de Pods. +Si une application ne nécessite aucun identifiant stable ou de déploiement, suppression ou +mise à l'échelle stables, vous devriez déployer votre application en utilisant un objet de charge de travail +fournissant un ensemble de réplicas sans état (*stateless*). + +Un [Deployment](/fr/docs/concepts/workloads/controllers/deployment/) ou +[ReplicaSet](/fr/docs/concepts/workloads/controllers/replicaset/) peut être mieux adapté pour vos applications sans état. + +## Limitations + +* Le stockage pour un Pod donné doit être provisionné soit par un [approvisionneur de PersistentVolume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) basé sur un `storage class` donné, soit pré-provisionné par un admin. +* Supprimer et/ou réduire l'échelle d'un StatefulSet à zéro ne supprimera *pas* les volumes associés avec le StatefulSet. Ceci est fait pour garantir la sécurité des données, ce qui a généralement plus de valeur qu'une purge automatique de toutes les ressources relatives à un StatefulSet. +* Les StatefulSets nécessitent actuellement un [Service Headless](/fr/docs/concepts/services-networking/service/#headless-services) qui est responsable de l'identité réseau des Pods. Vous êtes responsable de la création de ce Service. +* Les StatefulSets ne fournissent aucune garantie de la terminaison des pods lorsqu'un StatefulSet est supprimé. Pour avoir une terminaison ordonnée et maîtrisée des pods du StatefulSet, il est possible de réduire l'échelle du StatefulSet à 0 avant de le supprimer. +* Lors de l'utilisation de [Rolling Updates](#rolling-updates) avec la + [Politique de gestion des Pods](#politiques-de-gestion-dun-pod) par défaut (`OrderedReady`), + il est possible de tomber dans un état indéfini nécessitant une + [intervention manuelle pour réparer](#rollback-forcé). + +## Composants + +L'exemple ci-dessous décrit les composants d'un StatefulSet. + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: nginx + labels: + app: nginx +spec: + ports: + - port: 80 + name: web + clusterIP: None + selector: + app: nginx +--- +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: web +spec: + selector: + matchLabels: + app: nginx # doit correspondre à .spec.template.metadata.labels + serviceName: "nginx" + replicas: 3 # est 1 par défaut + template: + metadata: + labels: + app: nginx # doit correspondre à .spec.selector.matchLabels + spec: + terminationGracePeriodSeconds: 10 + containers: + - name: nginx + image: k8s.gcr.io/nginx-slim:0.8 + ports: + - containerPort: 80 + name: web + volumeMounts: + - name: www + mountPath: /usr/share/nginx/html + volumeClaimTemplates: + - metadata: + name: www + spec: + accessModes: [ "ReadWriteOnce" ] + storageClassName: "my-storage-class" + resources: + requests: + storage: 1Gi +``` + +Dans l'exemple ci-dessus : + +* Un Service Headless, appelé `nginx`, est utilisé pour contrôler le domaine réseau. +* Le StatefulSet, appelé `web`, a une Spec indiquant que 3 réplicas du container nginx seront démarrés dans des Pods. +* Le `volumeClaimTemplates` fournira un stockage stable utilisant des [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisionnés par un approvisionneur de PersistentVolume. + +Le nom d'un objet StatefulSet doit être un +[nom de sous-domaine DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) valide. + +## Sélecteur de Pod + +Vous devez renseigner le champ `.spec.selector` d'un StatefulSet pour qu'il corresponde aux labels de son `.spec.template.metadata.labels`. Avant Kubernetes 1.8, le champ `.spec.selector` était mis par défaut s'il était omis. Pour les versions 1.8 et ultérieures, ne pas spécifier de sélecteur de Pod résulte en une erreur de validation lors de la création du StatefulSet. + +## Identité du Pod + +Les Pods d'un StatefulSet ont une identité unique comprenant un ordinal, une identité réseau stable et un stockage stable. +L'identité est accrochée au Pod, indépendamment du noeud sur lequel il est (re)programmé. + +### Index Ordinal + +Pour un StatefulSet avec N réplicas, chaque Pod du StatefulSet se verra assigné un ordinal entier, de 0 à N-1, +unique sur l'ensemble des pods. + +### ID réseau stable + +Chaque Pod dans un StatefulSet dérive son nom d'hôte du nom du StatefulSet +et de l'ordinal du Pod. Le modèle pour le nom d'hôte généré est +`$(nom statefulset)-$(ordinal)`. L'exemple ci-dessus créera trois Pods +nommés `web-0,web-1,web-2`. +Un StatefulSet peut utiliser un [Service Headless](/docs/concepts/services-networking/service/#headless-services) +pour contrôler le domaine de ses Pods. Le domaine pris en charge par ce Service prend la forme : +`$(nom service).$(namespace).svc.cluster.local`, où "cluster.local" est le domaine du cluster. +Chaque fois qu'un Pod est créé, il obtient un sous-domaine DNS correspondant, prenant la forme : +`$(nom pod).$(domaine du service gouvernant)`, où le service gouvernant est défini par le +champ `serviceName` du StatefulSet. + +En fonction de la façon dont est configuré le DNS dans votre cluster, vous ne pourrez peut-être pas rechercher immédiatement +le nom DNS d'un pod nouvellement exécuté. Ce problème peut se produire lorsque d'autres clients dans le +cluster ont déjà envoyé des requêtes pour le nom d'hôte du Pod avant sa création. +La mise en cache négative (normale pour le DNS) signifie que les résultats des recherches précédentes ayant échoué sont +mémorisés et réutilisés, même après que le Pod ait démarré, pendant au moins quelques secondes. + +Si vous avez besoin de découvrir les Pods rapidement après leur création, vous avez plusieurs options : + +- Interrogez directement l'API Kubernetes (par exemple, à l'aide d'un watch) plutôt que de vous fier aux recherches DNS. +- Réduisez le temps de mise en cache dans votre fournisseur de DNS Kubernetes (cela signifie généralement modifier le ConfigMap de CoreDNS, qui met actuellement en cache pendant 30 secondes). + +Comme mentionné dans la section [limitations](#limitations), vous êtes responsable de +créer le [Service Headless](/docs/concepts/services-networking/service/#headless-services) +responsable de l'identité réseau des Pods. + +Voici quelques exemples de choix pour le domaine du cluster, le nom du service, +le nom du StatefulSet et comment cela affecte les noms DNS des pods du StatefulSet. + +Domaine Cluster | Service (ns/nom) | StatefulSet (ns/nom) | Domaine StatefulSet | DNS Pod | Nom d'hôte | +--------------- | ----------------- | -------------------- | ------------------------------- | -------------------------------------------- | ------------ | + cluster.local | default/nginx | default/web | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} | + cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} | + kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} | + +{{< note >}} +Le domaine cluster sera `cluster.local` à moins qu'il soit +[configuré autrement](/docs/concepts/services-networking/dns-pod-service/). +{{< /note >}} + +### Stockage stable + +Kubernetes crée un [PersistentVolume](/docs/concepts/storage/persistent-volumes/) pour chaque +VolumeClaimTemplate. Dans l'exemple nginx ci-dessus, chaque Pod se verra affecter un unique PersistentVolume +avec un StorageClass de `my-storage-class` et 1 Gib de stockage provisionné. Si aucun StorageClass +n'est spécifié, alors le StorageClass par défaut sera utilisé. Lorsqu'un Pod est (re)schedulé +sur un noeud, ses `volumeMounts` montent les PersistentVolumes associés aux +PersistentVolumeClaims. Notez que les PersistentVolumes associés avec les PersistentVolumeClaims des Pods +ne sont pas supprimés lorsque les Pods, ou le StatefulSet, sont supprimés. +Ceci doit être fait manuellement. + +### Étiquette du nom de Pod + +Lorsque le StatefulSet {{< glossary_tooltip term_id="controller" >}} crée un Pod, +il ajoute une étiquette, `statefulset.kubernetes.io/pod-name`, renseignée avec le nom du Pod. +Cette étiquette vous permet d'attacher un Service à un Pod spécifique du StatefulSet. + +## Garanties de déploiement et de mise à l'échelle + +* Pour un StatefulSet avec N réplicas, lorsque les Pods sont déployés, ils sont créés de manière séquentielle, dans l'ordre {0..N-1}. +* Lorsque les Pods sont supprimés, ils sont terminés dans l'ordre inverse, {N-1..0}. +* Avant qu'une opération de mise à l'échelle soit appliquée à un Pod, tous ses prédécesseurs doivent être Running et Ready. +* Avant qu'un Pod soit terminé, tous ses successeurs doivent être complètement arrêtés. + +Le StatefulSet ne devrait pas spécifier un `pod.Spec.TerminationGracePeriodSeconds` à 0. Cette pratique +est dangereuse et fortement déconseillée. Pour plus d'explications, veuillez vous référer à [forcer la suppression de Pods de StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/). + +Lorsque l'exemple nginx ci-dessus est créé, trois Pods seront déployés dans l'ordre +web-0, web-1, web-2. web-1 ne sera pas déployé avant que web-0 soit +[Running et Ready](/fr/docs/concepts/workloads/pods/pod-lifecycle/), et web-2 ne sera pas déployé avant que +web-1 soit Running et Ready. Si web-0 venait à échouer, après que web-1 soit Running et Ready, mais avant que +web-2 soit lancé, web-2 ne serait pas lancé avant que web-0 soit correctement relancé et redevienne Running et Ready. + +Si un utilisateur venait à mettre à l'échelle l'exemple déployé en patchant le StatefulSet pour que +`replicas=1`, web-2 serait terminé en premier. web-1 ne serait pas terminé avant que web-2 +ne soit complètement arrêté et supprimé. Si web-0 venait à échouer après que web-2 soit terminé et complètement arrêté, +mais avant que web-1 soit terminé, web-1 ne serait pas terminé avant que web-0 soit Running et Ready. + +### Politiques de gestion d'un Pod + +Dans Kubernetes 1.7 et ultérieurs, le StatefulSet vous permet d'assouplir ses garanties d'ordre, +tout en préservant ses garanties d'unicité et d'identité via son champ `.spec.podManagementPolicy`. + +#### Gestion de Pod OrderedReady + +La gestion de Pod `OrderedReady` est la valeur par défaut pour les StatefulSets. Il implémente le comportement décrit [ci-dessus](#garanties-de-déploiment-et-de-mise-à-l-échelle). + +#### Gestion de Pod Parallel + +La gestion de Pod `Parallel` indique au contrôleur de StatefulSet de lancer ou +terminer tous les Pods en parallèle, et de ne pas attendre que les Pods deviennent Running +et Ready ou complètement terminés avant de lancer ou terminer un autre +Pod. Cette option affecte seulement le comportement pour les opérations de mise à l'échelle. +Les mises à jour ne sont pas affectées. + +## Stratégies de mise à jour + +Dans Kubernetes 1.7 et ultérieurs, le champ `.spec.updateStrategy` d'un StatefulSet vous permet +de configurer et désactiver les rolling updates automatisés pour les conteneurs, étiquettes, +requête/limites de ressources, et annotations pour les Pods d'un StatefulSet. + +### On Delete + +La stratégie de mise à jour `OnDelete` implémente l'ancien comportement (1.6 et précédents). Lorsque +`.spec.updateStrategy.type` d'un StatefulSet est mis à `OnDelete`, le contrôleur de StatefulSet +ne mettra pas à jour automatiquement les Pods dans un StatefulSet. +Les utilisateurs doivent supprimer manuellement les Pods pour forcer le contrôleur à créer de nouveaux +Pods qui réflètent les modifications faites à un `.spec.template` d'un StatefulSet. + +### Rolling Updates + +La stratégie de mise à jour `RollingUpdate` implémente le rolling update automatisé pour les Pods d'un +StatefulSet. C'est la stratégie par défaut lorsque `.spec.updateStrategy` n'est pas spécifié. +Lorsqu'un `.spec.updateStrategy.type` d'un StatefulSet est mis à `RollingUpdate`, le contrôleur de +StatefulSet va supprimer et recréer chaque Pod d'un StatefulSet. Il va procéder dans le même ordre +que pour la terminaison d'un Pod (de l'ordinal le plus grand au plus petit), mettant à jour chaque Pod, +un seul à la fois. Il va attendre qu'un Pod mis à jour soit Running et Ready avant de mettre à jour +son prédécesseur. + +#### Partitions + +La stratégie de mise à jour `RollingUpdate` peut être partitionnée, en spécifiant une +`.spec.updateStrategy.rollingUpdate.partition`. Si une partition est spécifiée, tous les Pods ayant un +ordinal plus grand ou égal à la partition seront mis à jour lorsque le +`.spec.template` du StatefulSet sera mis à jour. Tous les Pods ayant un ordinal inférieur à la partition +ne sera pas mis à jour, et, même s'ils sont supprimés, ils seront recréés avec l'ancienne version. Si une +`.spec.updateStrategy.rollingUpdate.partition` d'un StatefulSet est plus grand que son `.spec.replicas`, +les mises à jour de son `.spec.template` ne seront pas propagés à ses Pods. +Dans la plupart des cas vous n'aurez pas à utiliser de partition, mais elles sont utiles si vous désirez +organiser une mise à jour, déployer une version canari, ou effectuer un déploiement par étapes. + +#### Rollback forcé + +En utilisant des [Rolling Updates](#rolling-updates) avec la +[politique de gestion d'un Pod](#politiques-de-gestion-dun-pod) par défaut (`OrderedReady`), +il est possible de se retrouver dans un état inconsistant nécessitant une intervention manuelle pour réparation. + +Si vous mettez à jour le template de Pod dans une configuration qui ne devient jamais Running et +Ready (par exemple, du fait d'un mauvais binaire ou d'une erreur de configuration au niveau de l'application), +le StatefulSet va arrêter le rollout et attendre. + +Dans cet état, il n'est pas suffisant de revenir à une bonne configuration du template de Pod. +En raison d'une [erreur connue](https://github.com/kubernetes/kubernetes/issues/67250), +le StatefulSet va continuer à attendre que le Pod en échec Pod devienne Ready +(ce qui n'arrive jamais) avant qu'il tente de revenir à la bonne configuration. + +Après être revenu au bon template, vous devez aussi supprimer tous les Pods que le StatefulSet +avait déjà essayé de démarrer avec la mauvaise configuration. +Le StatefulSet va alors commencer à recréer les Pods en utilisant le bon template. + +## {{% heading "whatsnext" %}} + +* Suivre un exemple de [déploiement d'une application stateful](/docs/tutorials/stateful-application/basic-stateful-set/). +* Suivre un exemple de [déploiement de Cassandra avec des Stateful Sets](/docs/tutorials/stateful-application/cassandra/). +* Suivre un exemple d'[exécution d'une application stateful redondante](/docs/tasks/run-application/run-replicated-stateful-application/). diff --git a/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md index 9e00fb57b0..cdb91bb27a 100644 --- a/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md +++ b/content/fr/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -135,7 +135,6 @@ hack/update-generated-swagger-docs.sh hack/update-swagger-spec.sh hack/update-openapi-spec.sh hack/update-generated-protobuf.sh -hack/update-api-reference-docs.sh ``` Exécutez `git status` pour voir ce qui a été généré. @@ -144,8 +143,6 @@ Exécutez `git status` pour voir ce qui a été généré. On branch master ... modified: api/openapi-spec/swagger.json - modified: api/swagger-spec/apps_v1.json - modified: docs/api-reference/apps/v1/definitions.html modified: staging/src/k8s.io/api/apps/v1/generated.proto modified: staging/src/k8s.io/api/apps/v1/types.go modified: staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go diff --git a/content/fr/docs/reference/glossary/annotation.md b/content/fr/docs/reference/glossary/annotation.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/approver.md b/content/fr/docs/reference/glossary/approver.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/certificate.md b/content/fr/docs/reference/glossary/certificate.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/cla.md b/content/fr/docs/reference/glossary/cla.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/cloud-controller-manager.md b/content/fr/docs/reference/glossary/cloud-controller-manager.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/cloud-provider.md b/content/fr/docs/reference/glossary/cloud-provider.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/cluster-architect.md b/content/fr/docs/reference/glossary/cluster-architect.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/cluster-operator.md b/content/fr/docs/reference/glossary/cluster-operator.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/code-contributor.md b/content/fr/docs/reference/glossary/code-contributor.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/configmap.md b/content/fr/docs/reference/glossary/configmap.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/container-env-variables.md b/content/fr/docs/reference/glossary/container-env-variables.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/container-runtime.md b/content/fr/docs/reference/glossary/container-runtime.md index ccd95157b9..1d2c8b105f 100644 --- a/content/fr/docs/reference/glossary/container-runtime.md +++ b/content/fr/docs/reference/glossary/container-runtime.md @@ -2,7 +2,7 @@ title: Container Runtime id: container-runtime date: 2019-06-05 -full_link: /docs/reference/generated/container-runtime +full_link: /docs/setup/production-environment/container-runtimes short_description: > L'environnement d'exécution de conteneurs est le logiciel responsable de l'exécution des conteneurs. diff --git a/content/fr/docs/reference/glossary/contributor.md b/content/fr/docs/reference/glossary/contributor.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/controller.md b/content/fr/docs/reference/glossary/controller.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/cronjob.md b/content/fr/docs/reference/glossary/cronjob.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/customresourcedefinition.md b/content/fr/docs/reference/glossary/customresourcedefinition.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/daemonset.md b/content/fr/docs/reference/glossary/daemonset.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/deployment.md b/content/fr/docs/reference/glossary/deployment.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/developer.md b/content/fr/docs/reference/glossary/developer.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/downstream.md b/content/fr/docs/reference/glossary/downstream.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/dynamic-volume-provisioning.md b/content/fr/docs/reference/glossary/dynamic-volume-provisioning.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/etcd.md b/content/fr/docs/reference/glossary/etcd.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/helm-chart.md b/content/fr/docs/reference/glossary/helm-chart.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/ingress.md b/content/fr/docs/reference/glossary/ingress.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/init-container.md b/content/fr/docs/reference/glossary/init-container.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/istio.md b/content/fr/docs/reference/glossary/istio.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/kube-apiserver.md b/content/fr/docs/reference/glossary/kube-apiserver.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/kube-controller-manager.md b/content/fr/docs/reference/glossary/kube-controller-manager.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/kube-proxy.md b/content/fr/docs/reference/glossary/kube-proxy.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/kube-scheduler.md b/content/fr/docs/reference/glossary/kube-scheduler.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/service.md b/content/fr/docs/reference/glossary/service.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/glossary/statefulset.md b/content/fr/docs/reference/glossary/statefulset.md new file mode 100644 index 0000000000..2acf3370a1 --- /dev/null +++ b/content/fr/docs/reference/glossary/statefulset.md @@ -0,0 +1,22 @@ +--- +title: StatefulSet +id: statefulset +date: 2018-04-12 +full_link: /fr/docs/concepts/workloads/controllers/statefulset/ +short_description: > + Gère le déploiement et la mise à l'échelle d'un ensemble de Pods, avec un stockage durable et des identifiants persistants pour chaque Pod. + +aka: +tags: +- fundamental +- core-object +- workload +- storage +--- + Gère le déploiement et la mise à l'échelle d'un ensemble de {{< glossary_tooltip text="Pods" term_id="pod" >}}, *et fournit des garanties sur l'ordre et l'unicité* de ces Pods. + + + +Comme un {{< glossary_tooltip term_id="deployment" >}}, un StatefulSet gère des Pods qui sont basés sur une même spécification de conteneur. Contrairement à un Deployment, un StatefulSet maintient une identité pour chacun de ces Pods. Ces Pods sont créés à partir de la même spec, mais ne sont pas interchangeables : chacun a un identifiant persistant qu'il garde à travers tous ses re-scheduling. + +Si vous voulez utiliser des volumes de stockage pour fournir de la persistance à votre charge de travail, vous pouvez utiliser un StatefulSet comme partie de la solution. Même si des Pods individuels d'un StatefulSet sont susceptibles d'échouer, les identifiants persistants des Pods rendent plus facile de faire correspondre les volumes existants aux nouveaux Pods remplaçant ceux ayant échoué. diff --git a/content/fr/docs/reference/kubectl/_index.md b/content/fr/docs/reference/kubectl/_index.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/kubectl/kubectl.md b/content/fr/docs/reference/kubectl/kubectl.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md index edf5c7e4c9..0df7c1a65b 100644 --- a/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md +++ b/content/fr/docs/reference/setup-tools/kubeadm/kubeadm-init.md @@ -131,7 +131,7 @@ Pour de l'information sur comment passer des options aux composants du control p ### Utiliser des images personnalisées {#custom-images} -Par défaut, kubeadm télécharge les images depuis `k8s.gcr.io`, à moins que la version demandée de Kubernetes soit une version Intégration Continue (CI). Dans ce cas, `gcr.io/kubernetes-ci-images` est utilisé. +Par défaut, kubeadm télécharge les images depuis `k8s.gcr.io`, à moins que la version demandée de Kubernetes soit une version Intégration Continue (CI). Dans ce cas, `gcr.io/k8s-staging-ci-images` est utilisé. Vous pouvez outrepasser ce comportement en utilisant [kubeadm avec un fichier de configuration](#config-file). Les personnalisations permises sont : diff --git a/content/fr/docs/setup/custom-cloud/kubespray.md b/content/fr/docs/setup/custom-cloud/kubespray.md index 2e10c21f46..cde3cbb3f9 100644 --- a/content/fr/docs/setup/custom-cloud/kubespray.md +++ b/content/fr/docs/setup/custom-cloud/kubespray.md @@ -8,7 +8,7 @@ content_type: concept Cette documentation permet d'installer rapidement un cluster Kubernetes hébergé sur GCE, Azure, Openstack, AWS, vSphere, Oracle Cloud Infrastructure (expérimental) ou sur des serveurs physiques (bare metal) grâce à [Kubespray](https://github.com/kubernetes-incubator/kubespray). -Kubespray se base sur des outils de provisioning, des [paramètres](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md) et playbooks [Ansible](http://docs.ansible.com/) ainsi que sur des connaissances spécifiques à Kubernetes et l'installation de systèmes d'exploitation afin de fournir: +Kubespray se base sur des outils de provisioning, des [paramètres](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/ansible.md) et playbooks [Ansible](https://docs.ansible.com/) ainsi que sur des connaissances spécifiques à Kubernetes et l'installation de systèmes d'exploitation afin de fournir: * Un cluster en haute disponibilité * des composants modulables @@ -49,7 +49,7 @@ Afin de vous aider à préparer votre de votre environnement, Kubespray fournit ### (2/5) Construire un fichier d'inventaire Ansible -Lorsque vos serveurs sont disponibles, créez un fichier d'inventaire Ansible ([inventory](http://docs.ansible.com/ansible/intro_inventory.html)). +Lorsque vos serveurs sont disponibles, créez un fichier d'inventaire Ansible ([inventory](https://docs.ansible.com/ansible/latest/network/getting_started/first_inventory.html)). Vous pouvez le créer manuellement ou en utilisant un script d'inventaire dynamique. Pour plus d'informations se référer à [Building your own inventory](https://github.com/kubernetes-incubator/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory). ### (3/5) Préparation au déploiement de votre cluster diff --git a/content/fr/docs/setup/pick-right-solution.md b/content/fr/docs/setup/pick-right-solution.md deleted file mode 100644 index a730ce8eb1..0000000000 --- a/content/fr/docs/setup/pick-right-solution.md +++ /dev/null @@ -1,303 +0,0 @@ ---- -reviewers: -- yastij -title: Choisir la bonne solution -description: Panorama de solutions Kubernetes -weight: 10 -content_type: concept ---- - - - -Kubernetes peut fonctionner sur des plateformes variées: sur votre PC portable, sur des VMs d'un fournisseur de cloud, ou un rack -de serveurs bare-metal. L'effort demandé pour configurer un cluster varie de l'éxécution d'une simple commande à la création -de votre propre cluster personnalisé. Utilisez ce guide pour choisir la solution qui correspond le mieux à vos besoins. - -Si vous voulez simplement jeter un coup d'oeil rapide, utilisez alors de préférence les [solutions locales basées sur Docker](#solutions-locales). - -Lorsque vous êtes prêts à augmenter le nombre de machines et souhaitez bénéficier de la haute disponibilité, une -[solution hébergée](#solutions-hebergées) est la plus simple à déployer et à maintenir. - -[Les solutions cloud clés en main](#solutions-clés-en-main) ne demandent que peu de commande pour déployer et couvrent un large panel de - fournisseurs de cloud. [Les solutions clés en main pour cloud privé](#solutions-on-premises-clés-en-main) possèdent la simplicité des solutions cloud clés en main combinées avec la sécurité de votre propre réseau privé. - -Si vous avez déjà un moyen de configurer vos resources, utilisez [kubeadm](/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) pour facilement -déployer un cluster grâce à une seule ligne de commande par machine. - -[Les solutions personnalisées](#solutions-personnalisées) varient d'instructions pas à pas, à des conseils relativement généraux pour déployer un - -cluster Kubernetes en partant du début. - - - - - -## Solutions locales - -* [Minikube](/fr/docs/setup/learning-environment/minikube/) est une méthode pour créer un cluster Kubernetes local à noeud unique pour le développement et le test. L'installation est entièrement automatisée et ne nécessite pas de compte de fournisseur de cloud. - -* [Docker Desktop](https://www.docker.com/products/docker-desktop) est une -application facile à installer pour votre environnement Mac ou Windows qui vous permet de -commencer à coder et déployer votre code dans des conteneurs en quelques minutes sur un nœud unique Kubernetes. - -* [Minishift](https://docs.okd.io/latest/minishift/) installe la version communautaire de la plate-forme d'entreprise OpenShift -de Kubernetes pour le développement local et les tests. Il offre une VM tout-en-un (`minishift start`) pour Windows, macOS et Linux, - le `oc cluster up` containerisé (Linux uniquement) et [est livré avec quelques Add Ons faciles à installer](https://github.com/minishift/minishift-addons/tree/master/add-ons). - -* [MicroK8s](https://microk8s.io/) fournit une commande unique d'installation de la dernière version de Kubernetes sur une machine locale -pour le développement et les tests. L'installation est rapide (~30 sec) et supporte de nombreux plugins dont Istio avec une seule commande. - -* [IBM Cloud Private-CE (Community Edition)](https://github.com/IBM/deploy-ibm-cloud-private) peut utiliser VirtualBox sur votre machine -pour déployer Kubernetes sur une ou plusieurs machines virtuelles afin de développer et réaliser des scénarios de test. Cette solution -peut créer un cluster multi-nœuds complet. - -* [IBM Cloud Private-CE (Community Edition) sur Linux Containers](https://github.com/HSBawa/icp-ce-on-linux-containers) est un script IaC (Infrastructure as Code) basé sur Terraform/Packer/BASH pour créer un cluster LXD à sept nœuds (1 Boot, 1 Master, 1 Management, 1 Proxy et 3 Workers) sur une machine Linux. - -* [Kubeadm-dind](https://github.com/kubernetes-sigs/kubeadm-dind-cluster) est un cluster Kubernetes multi-nœuds (tandis que minikube est -un nœud unique) qui ne nécessite qu'un docker-engine. Il utilise la technique du docker-in-docker pour déployer le cluster Kubernetes. - -* [Ubuntu sur LXD](/docs/getting-start-guides/ubuntu/local/) supporte un déploiement de 9 instances sur votre machine locale. - -## Solutions hebergées - -* [AppsCode.com](https://appscode.com/products/cloud-deployment/) fournit des clusters Kubernetes managés pour divers clouds publics, dont AWS et Google Cloud Platform. - -* [APPUiO](https://appuio.ch) propose une plate-forme de cloud public OpenShift, supportant n'importe quel workload Kubernetes. De plus, APPUiO propose des Clusters OpenShift privés et managés, fonctionnant sur n'importe quel cloud public ou privé. - -* [Amazon Elastic Container Service for Kubernetes](https://aws.amazon.com/eks/) offre un service managé de Kubernetes. - -* [Azure Kubernetes Service](https://azure.microsoft.com/services/container-service/) offre des clusters Kubernetes managés. - -* [Containership Kubernetes Engine (CKE)](https://containership.io/containership-platform) Approvisionnement et gestion intuitive de clusters - Kubernetes sur GCP, Azure, AWS, Packet, et DigitalOcean. Mises à niveau transparentes, auto-scaling, métriques, création de -workloads, et plus encore. - -* [DigitalOcean Kubernetes](https://www.digitalocean.com/products/kubernetes/) offre un service managé de Kubernetes. - -* [Giant Swarm](https://giantswarm.io/product/) offre des clusters Kubernetes managés dans leur propre centre de données, on-premises ou sur des clouds public. - -* [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) offre des clusters Kubernetes managés. - -* [IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-getting-started) offre des clusters Kubernetes managés avec choix d'isolation, des outils opérationnels, une vision intégrée de la sécurité des images et des conteneurs et une intégration avec Watson, IoT et les données. - -* [Kubermatic](https://www.loodse.com) fournit des clusters Kubernetes managés pour divers clouds publics, y compris AWS et Digital Ocean, ainsi que sur site avec intégration OpenStack. - -* [Kublr](https://kublr.com) offre des clusters Kubernetes sécurisés, évolutifs et hautement fiables sur AWS, Azure, GCP et on-premises, - de qualité professionnelle. Il inclut la sauvegarde et la reprise après sinistre prêtes à l'emploi, la journalisation et la surveillance centralisées multi-clusters, ainsi qu'une fonction d'alerte intégrée. - -* [Madcore.Ai](https://madcore.ai) est un outil CLI orienté développement pour déployer l'infrastructure Kubernetes dans AWS. Les masters, un groupe d'autoscaling pour les workers sur des spot instances, les ingress-ssl-lego, Heapster, et Grafana. - -* [Nutanix Karbon](https://www.nutanix.com/products/karbon/) est une plateforme de gestion et d'exploitation Kubernetes multi-clusters hautement disponibles qui simplifie l'approvisionnement, les opérations et la gestion du cycle de vie de Kubernetes. - -* [OpenShift Dedicated](https://www.openshift.com/dedicated/) offre des clusters Kubernetes gérés et optimisés par OpenShift. - -* [OpenShift Online](https://www.openshift.com/features/) fournit un accès hébergé gratuit aux applications Kubernetes. - -* [Oracle Container Engine for Kubernetes](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengoverview.htm) est un service entièrement géré, évolutif et hautement disponible que vous pouvez utiliser pour déployer vos applications conteneurisées dans le cloud. - -* [Platform9](https://platform9.com/products/kubernetes/) offre des Kubernetes gérés on-premises ou sur n'importe quel cloud public, et fournit une surveillance et des alertes de santé 24h/24 et 7j/7. (Kube2go, une plate-forme de service de déploiement de cluster Kubernetes pour le déploiement de l'interface utilisateur Web9, a été intégrée à Platform9 Sandbox.) - -* [Stackpoint.io](https://stackpoint.io) fournit l'automatisation et la gestion de l'infrastructure Kubernetes pour plusieurs clouds publics. - -* [SysEleven MetaKube](https://www.syseleven.io/products-services/managed-kubernetes/) offre un Kubernetes-as-a-Service sur un cloud public OpenStack. Il inclut la gestion du cycle de vie, les tableaux de bord d'administration, la surveillance, la mise à l'échelle automatique et bien plus encore. - -* [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) est une offre d'entreprise Kubernetes-as-a-Service faisant partie du catalogue de services Cloud VMware qui fournit des clusters Kubernetes faciles à utiliser, sécurisés par défaut, rentables et basés sur du SaaS. - -## Solutions clés en main - -Ces solutions vous permettent de créer des clusters Kubernetes sur une gamme de fournisseurs de Cloud IaaaS avec seulement -quelques commandes. Ces solutions sont activement développées et bénéficient du soutien actif de la communauté. - -* [Agile Stacks](https://www.agilestacks.com/products/kubernetes) -* [Alibaba Cloud](/docs/setup/turnkey/alibaba-cloud/) -* [APPUiO](https://appuio.ch) -* [AWS](/docs/setup/turnkey/aws/) -* [Azure](/docs/setup/turnkey/azure/) -* [CenturyLink Cloud](/docs/setup/turnkey/clc/) -* [Conjure-up Kubernetes with Ubuntu on AWS, Azure, Google Cloud, Oracle Cloud](/docs/getting-started-guides/ubuntu/) -* [Containership](https://containership.io/containership-platform) -* [Docker Enterprise](https://www.docker.com/products/docker-enterprise) -* [Gardener](https://gardener.cloud/) -* [Giant Swarm](https://giantswarm.io) -* [Google Compute Engine (GCE)](/docs/setup/turnkey/gce/) -* [IBM Cloud](https://github.com/patrocinio/kubernetes-softlayer) -* [Kontena Pharos](https://kontena.io/pharos/) -* [Kubermatic](https://cloud.kubermatic.io) -* [Kublr](https://kublr.com/) -* [Madcore.Ai](https://madcore.ai/) -* [Nirmata](https://nirmata.com/) -* [Nutanix Karbon](https://www.nutanix.com/products/karbon/) -* [Oracle Container Engine for K8s](https://docs.us-phoenix-1.oraclecloud.com/Content/ContEng/Concepts/contengprerequisites.htm) -* [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service) -* [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/) -* [Stackpoint.io](/docs/setup/turnkey/stackpoint/) -* [Tectonic by CoreOS](https://coreos.com/tectonic) -* [VMware Cloud PKS](https://cloud.vmware.com/vmware-cloud-pks) - -## Solutions On-Premises clés en main - -Ces solutions vous permettent de créer des clusters Kubernetes sur votre cloud privé sécurisé avec seulement quelques commandes. - -* [Agile Stacks](https://www.agilestacks.com/products/kubernetes) -* [APPUiO](https://appuio.ch) -* [Docker Enterprise](https://www.docker.com/products/docker-enterprise) -* [Giant Swarm](https://giantswarm.io) -* [GKE On-Prem | Google Cloud](https://cloud.google.com/gke-on-prem/) -* [IBM Cloud Private](https://www.ibm.com/cloud-computing/products/ibm-cloud-private/) -* [Kontena Pharos](https://kontena.io/pharos/) -* [Kubermatic](https://www.loodse.com) -* [Kublr](https://kublr.com/) -* [Mirantis Cloud Platform](https://www.mirantis.com/software/kubernetes/) -* [Nirmata](https://nirmata.com/) -* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) by [Red Hat](https://www.redhat.com) -* [Pivotal Container Service](https://pivotal.io/platform/pivotal-container-service) -* [Rancher 2.0](https://rancher.com/docs/rancher/v2.x/en/) -* [SUSE CaaS Platform](https://www.suse.com/products/caas-platform) -* [SUSE Cloud Application Platform](https://www.suse.com/products/cloud-application-platform/) - -## Solutions personnalisées - -Kubernetes peut fonctionner sur une large gamme de fournisseurs de Cloud et d'environnements bare-metal, ainsi qu'avec de nombreux -systèmes d'exploitation. - -Si vous pouvez trouver un guide ci-dessous qui correspond à vos besoins, utilisez-le. C'est peut-être un peu dépassé, mais... -ce sera plus facile que de partir de zéro. Si vous voulez repartir de zéro, soit parce que vous avez des exigences particulières, -ou simplement parce que vous voulez comprendre ce qu'il y a à l'interieur de Kubernetes -essayez le guide [Getting Started from Scratch](/docs/setup/release/building-from-source/). - -### Universel - -Si vous avez déjà un moyen de configurer les ressources d'hébergement, utilisez -[kubeadm](/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) pour déployer facilement un cluster -avec une seule commande par machine. - -### Cloud - -Ces solutions sont des combinaisons de fournisseurs de cloud computing et de systèmes d'exploitation qui ne sont pas couverts par les solutions ci-dessus. - -* [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) -* [CoreOS on AWS or GCE](/docs/setup/custom-cloud/coreos/) -* [Gardener](https://gardener.cloud/) -* [Kublr](https://kublr.com/) -* [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/) -* [Kubespray](/docs/setup/custom-cloud/kubespray/) -* [Rancher Kubernetes Engine (RKE)](https://github.com/rancher/rke) - -### VMs On-Premises - -* [Cloud Foundry Container Runtime (CFCR)](https://docs-cfcr.cfapps.io/) -* [CloudStack](/docs/setup/on-premises-vm/cloudstack/) (uses Ansible, CoreOS and flannel) -* [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) (uses Fedora and flannel) -* [Nutanix AHV](https://www.nutanix.com/products/acropolis/virtualization/) -* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com) -* [oVirt](/docs/setup/on-premises-vm/ovirt/) -* [Vagrant](/docs/setup/custom-cloud/coreos/) (uses CoreOS and flannel) -* [VMware](/docs/setup/custom-cloud/coreos/) (uses CoreOS and flannel) -* [VMware vSphere](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/) -* [VMware vSphere, OpenStack, or Bare Metal](/docs/getting-started-guides/ubuntu/) (uses Juju, Ubuntu and flannel) - -### Bare Metal - -* [CoreOS](/docs/setup/custom-cloud/coreos/) -* [Digital Rebar](/docs/setup/on-premises-metal/krib/) -* [Docker Enterprise](https://www.docker.com/products/docker-enterprise) -* [Fedora (Single Node)](/docs/getting-started-guides/fedora/fedora_manual_config/) -* [Fedora (Multi Node)](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) -* [Kubernetes on Ubuntu](/docs/getting-started-guides/ubuntu/) -* [OpenShift Container Platform](https://www.openshift.com/products/container-platform/) (OCP) Kubernetes platform by [Red Hat](https://www.redhat.com) - -### Integrations - -Ces solutions fournissent une intégration avec des orchestrateurs, des resources managers ou des plateformes tierces. - -* [DCOS](/docs/setup/on-premises-vm/dcos/) - * Community Edition DCOS utilise AWS - * Enterprise Edition DCOS supporte l'hébergement cloud, les VMs on-premises, et le bare-metal - -## Tableau des Solutions - -Ci-dessous vous trouverez un tableau récapitulatif de toutes les solutions listées précédemment. - -| Fournisseur de IaaS | Config. Mgmt. | OS | Réseau | Docs | Niveau de support | -|------------------------------------------------|------------------------------------------------------------------------------|--------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| tous | tous | multi-support | tout les CNI | [docs](/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) | Project ([SIG-cluster-lifecycle](https://git.k8s.io/community/sig-cluster-lifecycle)) | -| Google Kubernetes Engine | | | GCE | [docs](https://cloud.google.com/kubernetes-engine/docs/) | Commercial | -| Docker Enterprise | personnalisé | [multi-support](https://success.docker.com/article/compatibility-matrix) | [multi-support](https://docs.docker.com/ee/ucp/kubernetes/install-cni-plugin/) | [docs](https://docs.docker.com/ee/) | Commercial | -| IBM Cloud Private | Ansible | multi-support | multi-support | [docs](https://www.ibm.com/support/knowledgecenter/SSBS6K/product_welcome_cloud_private.html) | [Commercial](https://www.ibm.com/mysupport/s/topic/0TO500000001o0fGAA/ibm-cloud-private?language=en_US&productId=01t50000004X1PWAA0) and [Community](https://www.ibm.com/support/knowledgecenter/SSBS6K_3.1.2/troubleshoot/support_types.html) | -| Red Hat OpenShift | Ansible & CoreOS | RHEL & CoreOS | [multi-support](https://docs.openshift.com/container-platform/3.11/architecture/networking/network_plugins.html) | [docs](https://docs.openshift.com/container-platform/3.11/welcome/index.html) | Commercial | -| Stackpoint.io | | multi-support | multi-support | [docs](https://stackpoint.io/) | Commercial | -| AppsCode.com | Saltstack | Debian | multi-support | [docs](https://appscode.com/products/cloud-deployment/) | Commercial | -| Madcore.Ai | Jenkins DSL | Ubuntu | flannel | [docs](https://madcore.ai) | Community ([@madcore-ai](https://github.com/madcore-ai)) | -| Platform9 | | multi-support | multi-support | [docs](https://platform9.com/managed-kubernetes/) | Commercial | -| Kublr | personnalisé | multi-support | multi-support | [docs](http://docs.kublr.com/) | Commercial | -| Kubermatic | | multi-support | multi-support | [docs](http://docs.kubermatic.io/) | Commercial | -| IBM Cloud Kubernetes Service | | Ubuntu | IBM Cloud Networking + Calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-getting-started) | Commercial | -| Giant Swarm | | CoreOS | flannel and/or Calico | [docs](https://docs.giantswarm.io/) | Commercial | -| GCE | Saltstack | Debian | GCE | [docs](/docs/setup/turnkey/gce/) | Project | -| Azure Kubernetes Service | | Ubuntu | Azure | [docs](https://docs.microsoft.com/en-us/azure/aks/) | Commercial | -| Azure (IaaS) | | Ubuntu | Azure | [docs](/docs/setup/turnkey/azure/) | [Community (Microsoft)](https://github.com/Azure/acs-engine) | -| Bare-metal | personnalisé | Fedora | _none_ | [docs](/docs/getting-started-guides/fedora/fedora_manual_config/) | Project | -| Bare-metal | personnalisé | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal)) | -| libvirt | personnalisé | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal)) | -| KVM | personnalisé | Fedora | flannel | [docs](/docs/getting-started-guides/fedora/flannel_multi_node_cluster/) | Community ([@aveshagarwal](https://github.com/aveshagarwal)) | -| DCOS | Marathon | CoreOS/Alpine | personnalisé | [docs](/docs/getting-started-guides/dcos/) | Community ([Kubernetes-Mesos Authors](https://github.com/mesosphere/kubernetes-mesos/blob/master/AUTHORS.md)) | -| AWS | CoreOS | CoreOS | flannel | [docs](/docs/setup/turnkey/aws/) | Community | -| GCE | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires)) | -| Vagrant | CoreOS | CoreOS | flannel | [docs](/docs/getting-started-guides/coreos/) | Community ([@pires](https://github.com/pires), [@AntonioMeireles](https://github.com/AntonioMeireles)) | -| CloudStack | Ansible | CoreOS | flannel | [docs](/docs/getting-started-guides/cloudstack/) | Community ([@sebgoa](https://github.com/sebgoa)) | -| VMware vSphere | tous | multi-support | multi-support | [docs](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/) | [Community](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/contactus.html) | -| Bare-metal | personnalisé | CentOS | flannel | [docs](/docs/getting-started-guides/centos/centos_manual_config/) | Community ([@coolsvap](https://github.com/coolsvap)) | -| lxd | Juju | Ubuntu | flannel/canal | [docs](/docs/getting-started-guides/ubuntu/local/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) | -| AWS | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) | -| Azure | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) | -| GCE | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) | -| Oracle Cloud | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) | -| Rackspace | personnalisé | CoreOS | flannel/calico/canal | [docs](https://developer.rackspace.com/docs/rkaas/latest/) | [Commercial](https://www.rackspace.com/managed-kubernetes) | -| VMware vSphere | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) | -| Bare Metal | Juju | Ubuntu | flannel/calico/canal | [docs](/docs/getting-started-guides/ubuntu/) | [Commercial](https://www.ubuntu.com/kubernetes) and [Community](https://jujucharms.com/kubernetes) | -| AWS | Saltstack | Debian | AWS | [docs](/docs/setup/turnkey/aws/) | Community ([@justinsb](https://github.com/justinsb)) | -| AWS | kops | Debian | AWS | [docs](https://github.com/kubernetes/kops/) | Community ([@justinsb](https://github.com/justinsb)) | -| Bare-metal | personnalisé | Ubuntu | flannel | [docs](/docs/getting-started-guides/ubuntu/) | Community ([@resouer](https://github.com/resouer), [@WIZARD-CXY](https://github.com/WIZARD-CXY)) | -| oVirt | | | | [docs](/docs/setup/on-premises-vm/ovirt/) | Community ([@simon3z](https://github.com/simon3z)) | -| tous | tous | tous | tous | [docs](/docs/setup/release/building-from-source/) | Community ([@erictune](https://github.com/erictune)) | -| tous | tous | tous | tous | [docs](http://docs.projectcalico.org/v2.2/getting-started/kubernetes/installation/) | Commercial and Community | -| tous | RKE | multi-support | flannel or canal | [docs](https://rancher.com/docs/rancher/v2.x/en/quick-start-guide/) | [Commercial](https://rancher.com/what-is-rancher/overview/) and [Community](https://github.com/rancher/rancher) | -| tous | [Gardener Cluster-Operator](https://kubernetes.io/blog/2018/05/17/gardener/) | multi-support | multi-support | [docs](https://gardener.cloud) | [Project/Community](https://github.com/gardener) and [Commercial]( https://cloudplatform.sap.com/) | -| Alibaba Cloud Container Service For Kubernetes | ROS | CentOS | flannel/Terway | [docs](https://www.aliyun.com/product/containerservice) | Commercial | -| Agile Stacks | Terraform | CoreOS | multi-support | [docs](https://www.agilestacks.com/products/kubernetes) | Commercial | -| IBM Cloud Kubernetes Service | | Ubuntu | calico | [docs](https://cloud.ibm.com/docs/containers?topic=containers-container_index#container_index) | Commercial | -| Digital Rebar | kubeadm | tous | metal | [docs](/docs/setup/on-premises-metal/krib/) | Community ([@digitalrebar](https://github.com/digitalrebar)) | -| VMware Cloud PKS | | Photon OS | Canal | [docs](https://docs.vmware.com/en/VMware-Kubernetes-Engine/index.html) | Commercial | -| Mirantis Cloud Platform | Salt | Ubuntu | multi-support | [docs](https://docs.mirantis.com/mcp/) | Commercial | - -{{< note >}} -Le tableau ci-dessus est ordonné par versions testées et utilisées dans les noeuds, suivis par leur niveau de support. -{{< /note >}} - -### Définition des colonnes - -* **IaaS Provider** est le produit ou l'organisation qui fournit les machines virtuelles ou physiques (nœuds) sur lesquelles Kubernetes fonctionne. -* **OS** est le système d'exploitation de base des nœuds. -* **Config. Mgmt.** est le système de gestion de configuration qui permet d'installer et de maintenir Kubernetes sur les - nœuds. -* **Le réseau** est ce qui implémente le [modèle de réseau](/docs/concepts/cluster-administration/networking/). Ceux qui ont le type de réseautage - Aucun_ ne peut pas prendre en charge plus d'un nœud unique, ou peut prendre en charge plusieurs nœuds VM dans un nœud physique unique. -* **Conformité** indique si un cluster créé avec cette configuration a passé la conformité du projet. - pour le support de l'API et des fonctionnalités de base de Kubernetes v1.0.0. -* **Niveaux de soutien** - * **Projet** : Les contributeurs de Kubernetes utilisent régulièrement cette configuration, donc elle fonctionne généralement avec la dernière version. - de Kubernetes. - * **Commercial** : Une offre commerciale avec son propre dispositif d'accompagnement. - * **Communauté** : Soutenu activement par les contributions de la communauté. Peut ne pas fonctionner avec les versions récentes de Kubernetes. - * **Inactif** : Pas de maintenance active. Déconseillé aux nouveaux utilisateurs de Kubernetes et peut être retiré. -* **Note** contient d'autres informations pertinentes, telles que la version de Kubernetes utilisée. - - - -[1]: https://gist.github.com/erictune/4cabc010906afbcc5061 - -[2]: https://gist.github.com/derekwaynecarr/505e56036cdf010bf6b6 - -[3]: https://gist.github.com/erictune/2f39b22f72565365e59b - - diff --git a/content/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 06c6d2f53c..06d5e5f286 100644 --- a/content/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/fr/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -10,7 +10,7 @@ card: -Cette page vous apprend comment installer la boîte à outils `kubeadm`. +Cette page vous apprend comment installer la boîte à outils `kubeadm`. Pour plus d'informations sur la création d'un cluster avec kubeadm, une fois que vous avez effectué ce processus d'installation, voir la page: [Utiliser kubeadm pour créer un cluster](/fr/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/). @@ -225,8 +225,9 @@ Installez les plugins CNI (requis pour la plupart des réseaux de pods) : ```bash CNI_VERSION="v0.8.2" +ARCH="amd64" sudo mkdir -p /opt/cni/bin -curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz +curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz ``` Définissez le répertoire pour télécharger les fichiers de commande @@ -245,7 +246,8 @@ Installez crictl (requis pour Kubeadm / Kubelet Container Runtime Interface (CRI ```bash CRICTL_VERSION="v1.17.0" -curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz +ARCH="amd64" +curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz ``` Installez `kubeadm`,` kubelet`, `kubectl` et ajoutez un service systemd` kubelet`: @@ -254,8 +256,9 @@ RELEASE_VERSION="v0.6.0" ```bash RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)" +ARCH="amd64" cd $DOWNLOAD_DIR -sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl} +sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl} sudo chmod +x {kubeadm,kubelet,kubectl} curl -sSL "https://raw.githubusercontent.com/kubernetes/release/${RELEASE_VERSION}/cmd/kubepkg/templates/latest/deb/kubelet/lib/systemd/system/kubelet.service" | sed "s:/usr/bin:${DOWNLOAD_DIR}:g" | sudo tee /etc/systemd/system/kubelet.service diff --git a/content/fr/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/fr/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md index c8966b56fa..b13b6ff7d9 100644 --- a/content/fr/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md +++ b/content/fr/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md @@ -230,8 +230,8 @@ kubeadm contient tout ce qui est nécessaire pour générer les certificats déc ```sh root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml - root@HOST1 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml - root@HOST2 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml + root@HOST1 $ kubeadm init phase etcd local --config=/tmp/${HOST1}/kubeadmcfg.yaml + root@HOST2 $ kubeadm init phase etcd local --config=/tmp/${HOST2}/kubeadmcfg.yaml ``` 1. Facultatif: Vérifiez la santé du cluster diff --git a/content/fr/docs/setup/release/_index.md b/content/fr/docs/setup/release/_index.md old mode 100755 new mode 100644 diff --git a/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md index eea6e5cd3d..114bcc784b 100644 --- a/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/fr/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -19,7 +19,7 @@ Dans cet exercice, vous allez utiliser kubectl pour récupérer tous les pods ex ## Répertorier toutes les images de conteneurs dans tous les namespaces - Récupérez tous les pods dans tous les namespace à l'aide de `kubectl get pods --all-namespaces` -- Formatez la sortie pour inclure uniquement la liste des noms d'image de conteneur à l'aide de `-o jsonpath={..image}`. +- Formatez la sortie pour inclure uniquement la liste des noms d'image de conteneur à l'aide de `-o jsonpath={.items[*].spec.containers[*].image}`. Cela analysera récursivement le champ `image` du json retourné. - Voir la [reference jsonpath](/docs/reference/kubectl/jsonpath/) pour plus d'informations sur l'utilisation de jsonpath. - Formatez la sortie à l'aide des outils standard: `tr`, `sort`, `uniq` @@ -28,7 +28,7 @@ Dans cet exercice, vous allez utiliser kubectl pour récupérer tous les pods ex - Utilisez `uniq` pour agréger le nombre d'images ```shell -kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\ tr -s '[[:space:]]' '\n' |\ sort |\ uniq -c @@ -69,7 +69,7 @@ Pour cibler uniquement les pods correspondant à un label spécifique, utilisez Les éléments suivants correspondent uniquement aux pods avec les labels `app=nginx`. ```shell -kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx +kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx ``` ## Filtrage des images de conteneur de liste par namespace de pod @@ -78,7 +78,7 @@ Pour cibler uniquement les pods dans un namespace spécifique, utilisez l'indica Ce qui suit correspond uniquement aux pods du namespace `kube-system`. ```shell -kubectl get pods --namespace kube-system -o jsonpath="{..image}" +kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}" ``` ## Répertorier les images de conteneurs en utilisant un go-template au lieu de jsonpath diff --git a/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 4b8b736336..5902ca926d 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -225,7 +225,7 @@ Si la startup probe ne réussit jamais, le conteneur est tué après 300s puis s Parfois, les applications sont temporairement incapables de servir le trafic. Par exemple, une application peut avoir besoin de charger des larges données ou des fichiers de configuration pendant le démarrage, ou elle peut dépendre de services externes après le démarrage. -Dans ces cas, vous ne voulez pas tuer l'application, mais tu ne veux pas non plus lui envoyer de requêtes. Kubernetes fournit des readiness probes pour détecter et atténuer ces situations. Un pod avec des conteneurs qui signale qu'elle n'est pas prête ne reçoit pas de trafic par les services de Kubernetes. +Dans ces cas, vous ne voulez pas tuer l'application, mais vous ne voulez pas non plus lui envoyer de requêtes. Kubernetes fournit des readiness probes pour détecter et atténuer ces situations. Un pod avec des conteneurs qui signale qu'elle n'est pas prête ne reçoit pas de trafic par les services de Kubernetes. {{< note >}} Readiness probes fonctionnent sur le conteneur pendant tout son cycle de vie. diff --git a/content/fr/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/fr/docs/tasks/configure-pod-container/configure-pod-configmap.md new file mode 100644 index 0000000000..6e9c4c5ba6 --- /dev/null +++ b/content/fr/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -0,0 +1,684 @@ +--- +title: Configurer un pod pour utiliser une ConfigMap +content_template: templates/task +weight: 150 +card: + name: tasks + weight: 50 +--- + + + +Les ConfigMaps vous permettent de découpler les artefacts de configuration du contenu de l'image pour garder les applications conteneurisées portables. +Cette page fournit une série d'exemples d'utilisation montrant comment créer des ConfigMaps et configurer des pods à l'aide des données stockées dans des ConfigMaps. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +## Créer un ConfigMap + +Vous pouvez utiliser soit `kubectl create configmap` ou un générateur ConfigMap dans `kustomization.yaml` pour créer un ConfigMap. +Notez que `kubectl` prends en charge `kustomization.yaml` à partir de la version 1.14. + +### Créer un ConfigMap à l'aide de kubectl create configmap + +Utilisez la commande `kubectl create configmap` pour créer des Configmaps depuis des [dossiers](#create-configmaps-from-directories), [fichiers](#create-configmaps-from-files), ou des [valeurs littérales](#create-configmaps-from-literal-values): + +```shell +kubectl create configmap +``` + +où \ est le nom que vous souhaitez attribuer à ConfigMap et \ est le répertoire, le fichier ou la valeur littérale à partir de laquelle récupérer les données. + +La source de données correspond à une paire clé-valeur dans ConfigMap, où + +* clé = le nom du fichier ou la clé que vous avez fournie sur la ligne de commande, et +* valeur = le contenu du fichier ou la valeur littérale que vous avez fournie sur la ligne de commande. + +Vous pouvez utiliser [`kubectl describe`](/docs/reference/generated/kubectl/kubectl-commands/#describe) ou [`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get) pour récupérer des informations sur un ConfigMap. + +#### Créer des ConfigMaps à partir de répertoires + +Vous pouvez utiliser `kubectl create configmap` pour créer un ConfigMap à partir de plusieurs fichiers dans le même répertoire. + +Par exemple: + +```shell +# Créez le répertoire local +mkdir -p configure-pod-container/configmap/ + +# Téléchargez les exemples de fichiers dans le répertoire `configure-pod-container/configmap/` +wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties +wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties + +# Créer la configmap +kubectl create configmap game-config --from-file=configure-pod-container/configmap/ +``` + +combine le contenu du répertoire `configure-pod-container/configmap/` + +```shell +game.properties +ui.properties +``` + +dans le ConfigMap suivant: + +```shell +kubectl describe configmaps game-config +``` + +où la sortie est similaire à ceci: + +```text +Name: game-config +Namespace: default +Labels: +Annotations: + +Data +==== +game.properties: 158 bytes +ui.properties: 83 bytes +``` + +Les fichiers `game.properties` et `ui.properties` dans le répertoire `configure-pod-container/configmap/` sont représentés dans la section `data` de la ConfigMap. + +```shell +kubectl get configmaps game-config -o yaml +``` + +La sortie est similaire à ceci: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2016-02-18T18:52:05Z + name: game-config + namespace: default + resourceVersion: "516" + uid: b4952dc3-d670-11e5-8cd0-68f728db1985 +data: + game.properties: | + enemies=aliens + lives=3 + enemies.cheat=true + enemies.cheat.level=noGoodRotten + secret.code.passphrase=UUDDLRLRBABAS + secret.code.allowed=true + secret.code.lives=30 + ui.properties: | + color.good=purple + color.bad=yellow + allow.textmode=true + how.nice.to.look=fairlyNice +``` + +#### Créer des ConfigMaps à partir de fichiers + +Vous pouvez utiliser `kubectl create configmap` pour créer un ConfigMap à partir d'un fichier individuel ou de plusieurs fichiers. + +Par exemple, + +```shell +kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties +``` + +produirait le ConfigMap suivant: + +```shell +kubectl describe configmaps game-config-2 +``` + +où la sortie est similaire à ceci: + +```text +Name: game-config-2 +Namespace: default +Labels: +Annotations: + +Data +==== +game.properties: 158 bytes +``` + +Vous pouvez passer l'argument `--from-file` plusieurs fois pour créer un ConfigMap à partir de plusieurs sources de données. + +```shell +kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties +``` + +Décrivez la ConfigMap crée `game-config-2`: + +```shell +kubectl describe configmaps game-config-2 +``` + +La sortie est similaire à ceci: + +```text +Name: game-config-2 +Namespace: default +Labels: +Annotations: + +Data +==== +game.properties: 158 bytes +ui.properties: 83 bytes +``` + +Utilisez l'option `--from-env-file` pour créer un ConfigMap à partir d'un fichier env, par exemple: + +```shell +# Les fichiers env contiennent une liste de variables d'environnement. +# Ces règles de syntaxe s'appliquent: +# Chaque ligne d'un fichier env doit être au format VAR=VAL. +# Les lignes commençant par # (c'est-à-dire les commentaires) sont ignorées. +# Les lignes vides sont ignorées. +# Il n'y a pas de traitement spécial des guillemets (c'est-à-dire qu'ils feront partie de la valeur ConfigMap)). + +# Téléchargez les exemples de fichiers dans le dossier `configure-pod-container/configmap/` +wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties + +# Le fichier env `game-env-file.properties` ressemble à ceci +cat configure-pod-container/configmap/game-env-file.properties +enemies=aliens +lives=3 +allowed="true" + +# Ce commentaire et la ligne vide au-dessus sont ignorés +``` + +```shell +kubectl create configmap game-config-env-file \ + --from-env-file=configure-pod-container/configmap/game-env-file.properties +``` + +produirait le ConfigMap suivant: + +```shell +kubectl get configmap game-config-env-file -o yaml +``` + +où la sortie est similaire à ceci: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2017-12-27T18:36:28Z + name: game-config-env-file + namespace: default + resourceVersion: "809965" + uid: d9d1ca5b-eb34-11e7-887b-42010a8002b8 +data: + allowed: '"true"' + enemies: aliens + lives: "3" +``` + +{{< caution >}} +Lorsque vous passez plusieurs fois `--from-env-file` pour créer un ConfigMap à partir de plusieurs sources de données, seul le dernier fichier env est utilisé. +{{< /caution >}} + +Le comportement consistant à passer plusieurs fois `--from-env-file` est démontré par: + +```shell +# Téléchargez les exemples de fichiers dans le répertoire `configure-pod-container/configmap/` +wget https://k8s.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties + +# Créez le configmap +kubectl create configmap config-multi-env-files \ + --from-env-file=configure-pod-container/configmap/game-env-file.properties \ + --from-env-file=configure-pod-container/configmap/ui-env-file.properties +``` + +produirait le ConfigMap suivant: + +```shell +kubectl get configmap config-multi-env-files -o yaml +``` + +où la sortie est similaire à ceci: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2017-12-27T18:38:34Z + name: config-multi-env-files + namespace: default + resourceVersion: "810136" + uid: 252c4572-eb35-11e7-887b-42010a8002b8 +data: + color: purple + how: fairlyNice + textmode: "true" +``` + +#### Définissez la clé à utiliser lors de la création d'un ConfigMap à partir d'un fichier + +Vous pouvez définir une clé autre que le nom de fichier à utiliser dans la section `data` de votre ConfigMap lorsque vous utilisez l'argument `--from-file`: + +```shell +kubectl create configmap game-config-3 --from-file== +``` + +où `` est la clé que vous souhaitez utiliser dans la ConfigMap et `` est l'emplacement du fichier de source de données que vous souhaitez que la clé représente. + +Par exemple: + +```shell +kubectl create configmap game-config-3 --from-file=game-special-key=configure-pod-container/configmap/game.properties +``` + +produirait la ConfigMap suivante: + +```shell +kubectl get configmaps game-config-3 -o yaml +``` + +où la sortie est similaire à ceci: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2016-02-18T18:54:22Z + name: game-config-3 + namespace: default + resourceVersion: "530" + uid: 05f8da22-d671-11e5-8cd0-68f728db1985 +data: + game-special-key: | + enemies=aliens + lives=3 + enemies.cheat=true + enemies.cheat.level=noGoodRotten + secret.code.passphrase=UUDDLRLRBABAS + secret.code.allowed=true + secret.code.lives=30 +``` + +#### Créer des ConfigMaps à partir de valeurs littérales + +Vous pouvez utiliser `kubectl create configmap` avec l'argument `--from-literal` définir une valeur littérale à partir de la ligne de commande: + +```shell +kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm +``` + +Vous pouvez transmettre plusieurs paires clé-valeur. +Chaque paire fournie sur la ligne de commande est représentée comme une entrée distincte dans la section `data` de la ConfigMap. + +```shell +kubectl get configmaps special-config -o yaml +``` + +La sortie est similaire à ceci: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2016-02-18T19:14:38Z + name: special-config + namespace: default + resourceVersion: "651" + uid: dadce046-d673-11e5-8cd0-68f728db1985 +data: + special.how: very + special.type: charm +``` + +### Créer un ConfigMap à partir du générateur + +`kubectl` supporte `kustomization.yaml` depuis 1.14. +Vous pouvez également créer un ConfigMap à partir de générateurs, puis l'appliquer pour créer l'objet sur l'Apiserver. +Les générateurs doivent être spécifiés dans un `kustomization.yaml` à l'intérieur d'un répertoire. + +#### Générer des ConfigMaps à partir de fichiers + +Par exemple, pour générer un ConfigMap à partir de fichiers `configure-pod-container/configmap/game.properties` + +```shell +# Create a kustomization.yaml file with ConfigMapGenerator +cat <./kustomization.yaml +configMapGenerator: +- name: game-config-4 + files: + - configure-pod-container/configmap/game.properties +EOF +``` + +Appliquer le dossier kustomization pour créer l'objet ConfigMap. + +```shell +kubectl apply -k . +configmap/game-config-4-m9dm2f92bt created +``` + +Vous pouvez vérifier que le ConfigMap a été créé comme ceci: + +```text +kubectl get configmap +NAME DATA AGE +game-config-4-m9dm2f92bt 1 37s + + +kubectl describe configmaps/game-config-4-m9dm2f92bt +Name: game-config-4-m9dm2f92bt +Namespace: default +Labels: +Annotations: kubectl.kubernetes.io/last-applied-configuration: + {"apiVersion":"v1","data":{"game.properties":"enemies=aliens\nlives=3\nenemies.cheat=true\nenemies.cheat.level=noGoodRotten\nsecret.code.p... + +Data +==== +game.properties: +---- +enemies=aliens +lives=3 +enemies.cheat=true +enemies.cheat.level=noGoodRotten +secret.code.passphrase=UUDDLRLRBABAS +secret.code.allowed=true +secret.code.lives=30 +Events: +``` + +Notez que le nom ConfigMap généré a un suffixe obtenu par hachage de son contenu. +Cela garantit qu'un nouveau ConfigMap est généré chaque fois que le contenu est modifié. + +#### Définissez la clé à utiliser lors de la génération d'un ConfigMap à partir d'un fichier + +Vous pouvez définir une clé autre que le nom de fichier à utiliser dans le générateur ConfigMap. +Par exemple, pour générer un ConfigMap à partir du fichier `configure-pod-container/configmap/game.properties` +avec la clé `game-special-key` + +```shell +# Créer un fichier kustomization.yaml avec ConfigMapGenerator +cat <./kustomization.yaml +configMapGenerator: +- name: game-config-5 + files: + - game-special-key=configure-pod-container/configmap/game.properties +EOF +``` + +Appliquer le dossier kustomization pour créer l'objet ConfigMap. + +```text +kubectl apply -k . +configmap/game-config-5-m67dt67794 created +``` + +#### Générer des ConfigMaps à partir de littéraux + +Pour générer un ConfigMap à partir de littéraux `special.type=charm` et `special.how=very`, vous pouvez spécifier le générateur ConfigMap dans `kustomization.yaml` comme + +```shell +# Create a kustomization.yaml file with ConfigMapGenerator +cat <./kustomization.yaml +configMapGenerator: +- name: special-config-2 + literals: + - special.how=very + - special.type=charm +EOF +``` + +Appliquez le dossier kustomization pour créer l'objet ConfigMap. + +```text +kubectl apply -k . +configmap/special-config-2-c92b5mmcf2 created +``` + +## Définir des variables d'environnement de conteneur à l'aide des données ConfigMap + +### Définissez une variable d'environnement de conteneur avec les données d'une seule ConfigMap + +1. Définissez une variable d'environnement comme paire clé-valeur dans un ConfigMap: + + ```shell + kubectl create configmap special-config --from-literal=special.how=very + ``` + +1. Attribuez la valeur `special.how` défini dans ConfigMap à la variable d'environnement `SPECIAL_LEVEL_KEY` dans la spécification du Pod. + + {{< codenew file="pods/pod-single-configmap-env-variable.yaml" >}} + + Créez le pod: + + ```shell + kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml + ``` + + Maintenant, la sortie du Pod comprend une variable d'environnement `SPECIAL_LEVEL_KEY=very`. + +### Définir des variables d'environnement de conteneur avec des données de plusieurs ConfigMaps + +* Comme avec l'exemple précédent, créez d'abord les ConfigMaps. + + {{< codenew file="configmap/configmaps.yaml" >}} + + Créez le ConfigMap: + + ```shell + kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml + ``` + +* Définissez les variables d'environnement dans la spécification Pod. + + {{< codenew file="pods/pod-multiple-configmap-env-variable.yaml" >}} + + Créez le pod: + + ```shell + kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml + ``` + + Maintenant, la sortie du Pod comprend des variables d'environnement `SPECIAL_LEVEL_KEY=very` et `LOG_LEVEL=INFO`. + +## Configurer toutes les paires clé-valeur dans un ConfigMap en tant que variables d'environnement de conteneur + +{{< note >}} +Cette fonctionnalité est disponible dans Kubernetes v1.6 et versions ultérieures. +{{< /note >}} + +* Créez un ConfigMap contenant plusieurs paires clé-valeur. + + {{< codenew file="configmap/configmap-multikeys.yaml" >}} + + Créez le ConfigMap: + + ```shell + kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml + ``` + +* Utilisez `envFrom` pour définir toutes les données du ConfigMap en tant que variables d'environnement du conteneur. + La clé de ConfigMap devient le nom de la variable d'environnement dans le pod. + + {{< codenew file="pods/pod-configmap-envFrom.yaml" >}} + + Créez le pod: + + ```shell + kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml + ``` + + Maintenant, la sortie du Pod comprend les variables d'environnement `SPECIAL_LEVEL=very` et `SPECIAL_TYPE=charm`. + +## Utiliser des variables d'environnement définies par ConfigMap dans les commandes du Pod + +Vous pouvez utiliser des variables d'environnement définies par ConfigMap dans la section `command` de la spécification du Pod en utilisant la syntaxe de substitution Kubernetes `$(VAR_NAME)`. + +Par exemple, la spécification de pod suivante + +{{< codenew file="pods/pod-configmap-env-var-valueFrom.yaml" >}} + +créé en exécutant + +```shell +kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-env-var-valueFrom.yaml +``` + +produit la sortie suivante dans le conteneur `test-container`: + +```shell +very charm +``` + +## Ajouter des données ConfigMap à un volume + +Comme expliqué dans [Créer des ConfigMaps à partir de fichiers](#create-configmaps-from-files), lorsque vous créez un ConfigMap à l'aide `--from-file`, le nom de fichier devient une clé stockée dans la section `data` du ConfigMap. +Le contenu du fichier devient la valeur de la clé. + +Les exemples de cette section se réfèrent à un ConfigMap nommé special-config, illustré ci-dessous. + +{{< codenew file="configmap/configmap-multikeys.yaml" >}} + +Créez le ConfigMap: + +```shell +kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml +``` + +### Remplissez un volume avec des données stockées dans un ConfigMap + +Ajoutez le nom ConfigMap sous la section `volumes` de la spécification Pod. +Ceci ajoute les données ConfigMap au répertoire spécifié comme `volumeMounts.mountPath` (dans ce cas, `/etc/config`). +La section `command` répertorie les fichiers de répertoire dont les noms correspondent aux clés de ConfigMap. + +{{< codenew file="pods/pod-configmap-volume.yaml" >}} + +Créez le pod: + +```shell +kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml +``` + +Lorsque le pod s'exécute, la commande `ls /etc/config/` produit la sortie ci-dessous: + +```shell +SPECIAL_LEVEL +SPECIAL_TYPE +``` + +{{< caution >}} +S'il y a des fichiers dans le dossier `/etc/config/`, ils seront supprimés. +{{< /caution >}} + +### Ajouter un configmap à un chemin spécifique dans un volume + +Utilisez le champ `path` pour spécifier le chemin de fichier souhaité pour les éléments de configmap spécifiques. +Dans ce cas, le `SPECIAL_LEVEL` sera monté dans le volume `config-volume` au chemin `/etc/config/keys`. + +{{< codenew file="pods/pod-configmap-volume-specific-key.yaml" >}} + +Créez le Pod : + +```shell +kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume-specific-key.yaml +``` + +Lorsque le pod fonctionne, la commande `cat /etc/config/keys` produit la sortie ci-dessous : + +```shell +very +``` + +{{< caution >}} +Comme avant, tous les fichiers précédents dans le répertoire `/etc/config/` seront supprimés. +{{< /caution >}} + +### Projections de clés pour des chemins et des autorisations de fichiers spécifiques + +Vous pouvez projeter des clés vers des chemins spécifiques avec des autorisations spécifiques fichiers par fichiers. +Le guide de l'utilisateur [Secrets](/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod) explique la syntaxe. + +### Les ConfigMaps montées sont mises à jour automatiquement + +Lorsqu'une ConfigMap déjà consommée dans un volume est mise à jour, les clés projetées sont éventuellement mises à jour elles aussi. +Kubelet vérifie si la ConfigMap montée est fraîche à chaque synchronisation périodique. +Cependant, il utilise son cache local basé sur le ttl pour obtenir la valeur actuelle de la ConfigMap. +Par conséquent, le délai total entre le moment où la ConfigMap est mise à jour et le moment où les nouvelles clés sont projetées vers le pod peut être aussi long que la période de synchronisation de kubelet (1 minute par défaut) + le ttl du cache ConfigMaps (1 minute par défaut) dans kubelet. +Vous pouvez déclencher un rafraîchissement immédiat en mettant à jour l'une des annotations du pod. + +{{< note >}} +Un conteneur utilisant un ConfigMap comme volume [subPath](/docs/concepts/storage/volumes/#using-subpath) ne recevra pas les mises à jour de ConfigMap. +{{< /note >}} + + + +## Comprendre le lien entre les ConfigMaps et les Pods + +La ressource API ConfigMap stocke les données de configuration sous forme de paires clé-valeur. +Les données peuvent être consommées dans des pods ou fournir les configurations des composants du système tels que les contrôleurs. +ConfigMap est similaire à [Secrets](/docs/concepts/configuration/secret/), mais fournit un moyen de travailler avec des chaînes de caractères qui ne contiennent pas d'informations sensibles. +Les utilisateurs comme les composants du système peuvent stocker des données de configuration dans un ConfigMap. + +{{< note >}} +Les ConfigMaps doivent faire référence aux fichiers de propriétés, et non les remplacer. +Pensez à la ConfigMap comme représentant quelque chose de similaire au répertoire `/etc` de Linux et à son contenu. +Par exemple, si vous créez un [volume Kubernetes](/docs/concepts/storage/volumes/) à partir d'une ConfigMap, chaque élément de données de la ConfigMap est représenté par un fichier individuel dans le volume. +{{< /note >}} + +Le champ `data` de la ConfigMap contient les données de configuration. +Comme le montre l'exemple ci-dessous, cela peut être simple -- comme des propriétés individuelles définies à l'aide de `--from-literal` -- ou complexe -- comme des fichiers de configuration ou des blobs JSON définis à l'aide de `--from-file`. + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + creationTimestamp: 2016-02-18T19:14:38Z + name: example-config + namespace: default +data: + # example of a simple property defined using --from-literal + example.property.1: hello + example.property.2: world + # example of a complex property defined using --from-file + example.property.file: |- + property.1=value-1 + property.2=value-2 + property.3=value-3 +``` + +### Restrictions + +* Vous devez créer un ConfigMap avant de le référencer dans une spécification de Pod (sauf si vous marquez le ConfigMap comme "facultatif"). + Si vous faites référence à un ConfigMap qui n'existe pas, le Pod ne démarrera pas. + De même, les références à des clés qui n'existent pas dans la ConfigMap empêcheront le pod de démarrer. + +* Si vous utilisez `envFrom` pour définir des variables d'environnement à partir de ConfigMaps, les clés considérées comme invalides seront ignorées. + Le pod sera autorisé à démarrer, mais les noms invalides seront enregistrés dans le journal des événements (`InvalidVariableNames`). + Le message du journal énumère chaque clé sautée. + Par exemple : + + ```shell + kubectl get events + ``` + + Le résultat est similaire à celui-ci : + + ```text + LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE + 0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names. + ``` + +* Les ConfigMaps résident dans un {{< glossary_tooltip term_id="namespace" >}}. + Un ConfigMap ne peut être référencé que par des pods résidant dans le même namespace. + +* Vous ne pouvez pas utiliser des ConfigMaps pour {{< glossary_tooltip text="static pods" term_id="static-pod" >}}, car le Kubelet ne le supporte pas. + +{{% heading "whatsnext" %}} + +* Suivez un exemple concret de [Configurer Redis en utilisant un ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/). diff --git a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md index 1147f2234e..4f38f3a397 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-service-account.md @@ -155,8 +155,8 @@ La sortie est comme la suivante : Name: build-robot-secret Namespace: default Labels: -Annotations: kubernetes.io/service-account.name=build-robot - kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da +Annotations: kubernetes.io/service-account: name=build-robot + kubernetes.io/service-account: uid=da68f9c6-9d26-11e7-b84e-002dc52800da Type: kubernetes.io/service-account-token diff --git a/content/fr/examples/configmap/configmap-multikeys.yaml b/content/fr/examples/configmap/configmap-multikeys.yaml new file mode 100644 index 0000000000..289702d123 --- /dev/null +++ b/content/fr/examples/configmap/configmap-multikeys.yaml @@ -0,0 +1,8 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: special-config + namespace: default +data: + SPECIAL_LEVEL: very + SPECIAL_TYPE: charm diff --git a/content/fr/examples/configmap/configmaps.yaml b/content/fr/examples/configmap/configmaps.yaml new file mode 100644 index 0000000000..91b9f29755 --- /dev/null +++ b/content/fr/examples/configmap/configmaps.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: ConfigMap +metadata: + name: special-config + namespace: default +data: + special.how: very +--- +apiVersion: v1 +kind: ConfigMap +metadata: + name: env-config + namespace: default +data: + log_level: INFO diff --git a/content/fr/examples/pods/pod-configmap-env-var-valueFrom.yaml b/content/fr/examples/pods/pod-configmap-env-var-valueFrom.yaml new file mode 100644 index 0000000000..00827ec98a --- /dev/null +++ b/content/fr/examples/pods/pod-configmap-env-var-valueFrom.yaml @@ -0,0 +1,21 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/echo", "$(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ] + env: + - name: SPECIAL_LEVEL_KEY + valueFrom: + configMapKeyRef: + name: special-config + key: SPECIAL_LEVEL + - name: SPECIAL_TYPE_KEY + valueFrom: + configMapKeyRef: + name: special-config + key: SPECIAL_TYPE + restartPolicy: Never diff --git a/content/fr/examples/pods/pod-configmap-envFrom.yaml b/content/fr/examples/pods/pod-configmap-envFrom.yaml new file mode 100644 index 0000000000..70ae7e5bcf --- /dev/null +++ b/content/fr/examples/pods/pod-configmap-envFrom.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + envFrom: + - configMapRef: + name: special-config + restartPolicy: Never diff --git a/content/fr/examples/pods/pod-configmap-volume-specific-key.yaml b/content/fr/examples/pods/pod-configmap-volume-specific-key.yaml new file mode 100644 index 0000000000..72e38fd836 --- /dev/null +++ b/content/fr/examples/pods/pod-configmap-volume-specific-key.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh","-c","cat /etc/config/keys" ] + volumeMounts: + - name: config-volume + mountPath: /etc/config + volumes: + - name: config-volume + configMap: + name: special-config + items: + - key: SPECIAL_LEVEL + path: keys + restartPolicy: Never diff --git a/content/fr/examples/pods/pod-configmap-volume.yaml b/content/fr/examples/pods/pod-configmap-volume.yaml new file mode 100644 index 0000000000..478c2e8d2b --- /dev/null +++ b/content/fr/examples/pods/pod-configmap-volume.yaml @@ -0,0 +1,18 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "ls /etc/config/" ] + volumeMounts: + - name: config-volume + mountPath: /etc/config + volumes: + - name: config-volume + configMap: + # Indiquez le nom de la ConfigMap contenant les fichiers que vous souhaitez ajouter au conteneur + name: special-config + restartPolicy: Never diff --git a/content/fr/examples/pods/pod-multiple-configmap-env-variable.yaml b/content/fr/examples/pods/pod-multiple-configmap-env-variable.yaml new file mode 100644 index 0000000000..4790a9c661 --- /dev/null +++ b/content/fr/examples/pods/pod-multiple-configmap-env-variable.yaml @@ -0,0 +1,21 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + env: + - name: SPECIAL_LEVEL_KEY + valueFrom: + configMapKeyRef: + name: special-config + key: special.how + - name: LOG_LEVEL + valueFrom: + configMapKeyRef: + name: env-config + key: log_level + restartPolicy: Never diff --git a/content/fr/examples/pods/pod-single-configmap-env-variable.yaml b/content/fr/examples/pods/pod-single-configmap-env-variable.yaml new file mode 100644 index 0000000000..09d6f4a696 --- /dev/null +++ b/content/fr/examples/pods/pod-single-configmap-env-variable.yaml @@ -0,0 +1,19 @@ +apiVersion: v1 +kind: Pod +metadata: + name: dapi-test-pod +spec: + containers: + - name: test-container + image: k8s.gcr.io/busybox + command: [ "/bin/sh", "-c", "env" ] + env: + # Définie la variable d'environnement + - name: SPECIAL_LEVEL_KEY + valueFrom: + configMapKeyRef: + # La ConfigMap contenant la valeur que vous voulez attribuer à SPECIAL_LEVEL_KEY + name: special-config + # Spécifier la clé associée à la valeur + key: special.how + restartPolicy: Never diff --git a/content/hi/docs/_index.md b/content/hi/docs/_index.md new file mode 100644 index 0000000000..2244c2f26b --- /dev/null +++ b/content/hi/docs/_index.md @@ -0,0 +1,6 @@ +--- +linktitle: कुबेरनेट्स प्रलेखन +title: प्रलेखन +sitemap: + priority: 1.0 +--- diff --git a/content/id/community/static/cncf-code-of-conduct.md b/content/id/community/static/cncf-code-of-conduct.md index 7ee127a6b3..9ec35edc3d 100644 --- a/content/id/community/static/cncf-code-of-conduct.md +++ b/content/id/community/static/cncf-code-of-conduct.md @@ -24,7 +24,7 @@ Contoh perilaku kasar, melecehkan, atau tidak dapat diterima di Kubernetes dapat Kode Etik ini diadaptasi dari Covenant Contributor , versi 1.2.0, tersedia di - + ### Pedoman Perilaku Acara CNCF diff --git a/content/id/docs/concepts/_index.md b/content/id/docs/concepts/_index.md index 33f4ada445..623b3fac3a 100644 --- a/content/id/docs/concepts/_index.md +++ b/content/id/docs/concepts/_index.md @@ -61,7 +61,7 @@ Kontroler merupakan objek mendasar dengan fungsi tambahan, contoh dari kontroler * [Deployment](/id/docs/concepts/workloads/controllers/deployment/) * [StatefulSet](/id/docs/concepts/workloads/controllers/statefulset/) * [DaemonSet](/id/docs/concepts/workloads/controllers/daemonset/) -* [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) +* [Job](/id/docs/concepts/workloads/controllers/job/) ## *Control Plane* Kubernetes diff --git a/content/id/docs/concepts/architecture/controller.md b/content/id/docs/concepts/architecture/controller.md index bff7130eb7..096dd75085 100644 --- a/content/id/docs/concepts/architecture/controller.md +++ b/content/id/docs/concepts/architecture/controller.md @@ -60,7 +60,7 @@ Job adalah sumber daya dalam Kubernetes yang menjalankan a {{< glossary_tooltip term_id="pod" >}}, atau mungkin beberapa Pod sekaligus, untuk melakukan sebuah pekerjaan dan kemudian berhenti. -(Setelah [dijadwalkan](../../../../en/docs/concepts/scheduling/), objek Pod +(Setelah [dijadwalkan](../../../../en/docs/concepts/scheduling-eviction/), objek Pod akan menjadi bagian dari keadaan yang diinginkan oleh kubelet). Ketika _controller job_ melihat tugas baru, maka _controller_ itu memastikan bahwa, diff --git a/content/id/docs/concepts/architecture/nodes.md b/content/id/docs/concepts/architecture/nodes.md index a4cae113e6..685d54dddd 100644 --- a/content/id/docs/concepts/architecture/nodes.md +++ b/content/id/docs/concepts/architecture/nodes.md @@ -166,7 +166,7 @@ Pada kasus ini, kontroler node berasumsi ada masalah pada jaringan master, dan m Mulai dari Kubernetes 1.6, kontroler node juga bertanggung jawab untuk melakukan eviction pada pod-pod yang berjalan di atas node dengan taints `NoExecute`, ketika pod-pod tersebut sudah tidak lagi tolerate terhadap taints. Sebagai tambahan, hal ini di-nonaktifkan secara default pada fitur alpha, kontroler node bertanggung jawab untuk menambahkan taints yang berhubungan dengan masalah pada node, seperti terputus atau `NotReady`. -Lihat [dokumentasi ini](/id/docs/concepts/configuration/taint-and-toleration/) untuk bahasan detail tentang taints `NoExecute` dan fitur alpha. +Lihat [dokumentasi ini](/id/docs/concepts/scheduling-eviction/taint-and-toleration/) untuk bahasan detail tentang taints `NoExecute` dan fitur alpha. Mulai dari versi 1.8, kontroler node bisa diatur untuk bertanggung jawab pada pembuatan taints yang merepresentasikan node condition. Ini merupakan fitur alpha untuk versi 1.8. diff --git a/content/id/docs/concepts/cluster-administration/addons.md b/content/id/docs/concepts/cluster-administration/addons.md index ca50347492..e8a52a4910 100644 --- a/content/id/docs/concepts/cluster-administration/addons.md +++ b/content/id/docs/concepts/cluster-administration/addons.md @@ -27,7 +27,7 @@ Laman ini akan menjabarkan beberapa *add-ons* yang tersedia serta tautan instruk * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) memungkinkan Kubernetes agar dapat terkoneksi dengan beragam *plugin* CNI, seperti Calico, Canal, Flannel, Romana, atau Weave dengan mulus. * [Contiv](http://contiv.github.io) menyediakan jaringan yang dapat dikonfigurasi (*native* L3 menggunakan BGP, *overlay* menggunakan vxlan, klasik L2, dan Cisco-SDN/ACI) untuk berbagai penggunaan serta *policy framework* yang kaya dan beragam. Proyek Contiv merupakan proyek [open source](http://github.com/contiv). Laman [instalasi](http://github.com/contiv/install) ini akan menjabarkan cara instalasi, baik untuk klaster dengan kubeadm maupun non-kubeadm. * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), yang berbasis dari [Tungsten Fabric](https://tungsten.io), merupakan sebuah proyek *open source* yang menyediakan virtualisasi jaringan *multi-cloud* serta platform manajemen *policy*. Contrail dan Tungsten Fabric terintegrasi dengan sistem orkestrasi lainnya seperti Kubernetes, OpenShift, OpenStack dan Mesos, serta menyediakan mode isolasi untuk mesin virtual (VM), kontainer/pod dan *bare metal*. -* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) merupakan penyedia jaringan *overlay* yang dapat digunakan pada Kubernetes. +* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) merupakan penyedia jaringan *overlay* yang dapat digunakan pada Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) merupakan solusi jaringan yang mendukung multipel jaringan pada Kubernetes. * [Multus](https://github.com/Intel-Corp/multus-cni) merupakan sebuah multi *plugin* agar Kubernetes mendukung multipel jaringan secara bersamaan sehingga dapat menggunakan semua *plugin* CNI (contoh: Calico, Cilium, Contiv, Flannel), ditambah pula dengan SRIOV, DPDK, OVS-DPDK dan VPP pada *workload* Kubernetes. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) menyediakan integrasi antara VMware NSX-T dan orkestrator kontainer seperti Kubernetes, termasuk juga integrasi antara NSX-T dan platform CaaS/PaaS berbasis kontainer seperti *Pivotal Container Service* (PKS) dan OpenShift. diff --git a/content/id/docs/concepts/cluster-administration/flow-control.md b/content/id/docs/concepts/cluster-administration/flow-control.md index b8d8f9acf7..4f6036c0ca 100644 --- a/content/id/docs/concepts/cluster-administration/flow-control.md +++ b/content/id/docs/concepts/cluster-administration/flow-control.md @@ -368,7 +368,7 @@ beban kerja yang berperilaku buruk yang dapat membahayakan kesehatan dari sistem Untuk latar belakang informasi mengenai detail desain dari prioritas dan kesetaraan API, silahkan lihat -[proposal pembaharuan](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md). +[proposal pembaharuan](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1040-priority-and-fairness). Kamu juga dapat membuat saran dan permintaan akan fitur melalui [SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery). diff --git a/content/id/docs/concepts/configuration/overview.md b/content/id/docs/concepts/configuration/overview.md index 67fb2061fe..51fb10f5ef 100644 --- a/content/id/docs/concepts/configuration/overview.md +++ b/content/id/docs/concepts/configuration/overview.md @@ -34,7 +34,7 @@ Dokumentasi ini terbuka. Jika Anda menemukan sesuatu yang tidak ada dalam daftar - Jangan gunakan Pods naked (artinya, Pods tidak terikat dengan a [ReplicaSet](/id/docs/concepts/workloads/controllers/replicaset/) a [Deployment](/id/docs/concepts/workloads/controllers/deployment/)) jika kamu bisa menghindarinya. Pod naked tidak akan dijadwal ulang jika terjadi kegagalan pada node. - Deployment, yang keduanya menciptakan ReplicaSet untuk memastikan bahwa jumlah Pod yang diinginkan selalu tersedia, dan menentukan strategi untuk mengganti Pods (seperti [RollingUpdate](/id/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), hampir selalu lebih disukai daripada membuat Pods secara langsung, kecuali untuk beberapa yang eksplisit [`restartPolicy: Never`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) banyak skenario . A [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/) mungkin juga sesuai. + Deployment, yang keduanya menciptakan ReplicaSet untuk memastikan bahwa jumlah Pod yang diinginkan selalu tersedia, dan menentukan strategi untuk mengganti Pods (seperti [RollingUpdate](/id/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), hampir selalu lebih disukai daripada membuat Pods secara langsung, kecuali untuk beberapa yang eksplisit [`restartPolicy: Never`](/id/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) banyak skenario . A [Job](/id/docs/concepts/workloads/controllers/job/) mungkin juga sesuai. ## Services diff --git a/content/id/docs/concepts/containers/runtime-class.md b/content/id/docs/concepts/containers/runtime-class.md index 73252a03e4..49b1c6f1fa 100644 --- a/content/id/docs/concepts/containers/runtime-class.md +++ b/content/id/docs/concepts/containers/runtime-class.md @@ -45,7 +45,7 @@ soal bagaimana melakukan konfigurasi untuk implementasi CRI yang kamu miliki. Untuk saat ini, RuntimeClass berasumsi bahwa semua _node_ di dalam klaster punya konfigurasi yang sama (homogen). Jika ada _node_ yang punya konfigurasi berbeda dari yang lain (heterogen), maka perbedaan ini harus diatur secara independen di luar RuntimeClass -melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](/id/docs/concepts/configuration/assign-pod-node/)). +melalui fitur _scheduling_ (lihat [Menempatkan Pod pada Node](/id/docs/concepts/scheduling-eviction/assign-pod-node/)). {{< /note >}} Seluruh konfigurasi memiliki nama `handler` yang terkait, dijadikan referensi oleh RuntimeClass. @@ -111,7 +111,7 @@ _Handler runtime_ diatur melalui konfigurasi containerd pada `/etc/containerd/co _Handler_ yang valid dapat dikonfigurasi pada bagian _runtime_: ``` -[plugins.cri.containerd.runtimes.${HANDLER_NAME}] +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] ``` Lihat dokumentasi konfigurasi containerd untuk lebih detail: diff --git a/content/id/docs/concepts/extend-kubernetes/operator.md b/content/id/docs/concepts/extend-kubernetes/operator.md index 315ae35e3d..b9a8bf5a06 100644 --- a/content/id/docs/concepts/extend-kubernetes/operator.md +++ b/content/id/docs/concepts/extend-kubernetes/operator.md @@ -132,7 +132,7 @@ menggunakan bahasa / _runtime_ yang dapat bertindak sebagai * Menggunakan perangkat yang ada untuk menulis Operator kamu sendiri, misalnya: * menggunakan [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) * menggunakan [kubebuilder](https://book.kubebuilder.io/) - * menggunakan [Metacontroller](https://metacontroller.app/) bersama dengan + * menggunakan [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html) bersama dengan `WebHooks` yang kamu implementasikan sendiri * menggunakan the [Operator _Framework_](https://github.com/operator-framework/getting-started) * [Terbitkan](https://operatorhub.io/) Operator kamu agar dapat digunakan oleh diff --git a/content/id/docs/concepts/overview/working-with-objects/labels.md b/content/id/docs/concepts/overview/working-with-objects/labels.md index 306edc0bfb..7b4b125062 100644 --- a/content/id/docs/concepts/overview/working-with-objects/labels.md +++ b/content/id/docs/concepts/overview/working-with-objects/labels.md @@ -220,6 +220,6 @@ selector: #### Memilih kumpulan Node Salah satu contoh penggunaan pemilihan dengan menggunakan label yaitu untuk membatasi suatu kumpulan Node tertentu yang dapat digunakan oleh Pod. -Lihat dokumentasi pada [pemilihan Node](/id/docs/concepts/configuration/assign-pod-node/) untuk informasi lebih lanjut. +Lihat dokumentasi pada [pemilihan Node](/id/docs/concepts/scheduling-eviction/assign-pod-node/) untuk informasi lebih lanjut. diff --git a/content/id/docs/concepts/policy/_index.md b/content/id/docs/concepts/policy/_index.md old mode 100755 new mode 100644 diff --git a/content/id/docs/concepts/scheduling-eviction/_index.md b/content/id/docs/concepts/scheduling-eviction/_index.md new file mode 100644 index 0000000000..0d080ed79d --- /dev/null +++ b/content/id/docs/concepts/scheduling-eviction/_index.md @@ -0,0 +1,5 @@ +--- +title: "Penjadwalan dan Pengusiran" +weight: 90 +--- + diff --git a/content/id/docs/concepts/configuration/assign-pod-node.md b/content/id/docs/concepts/scheduling-eviction/assign-pod-node.md similarity index 98% rename from content/id/docs/concepts/configuration/assign-pod-node.md rename to content/id/docs/concepts/scheduling-eviction/assign-pod-node.md index ee9e8bf2f4..f8654f4276 100644 --- a/content/id/docs/concepts/configuration/assign-pod-node.md +++ b/content/id/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -114,7 +114,7 @@ Berikut ini contoh dari pod yang menggunakan afinitas node: Aturan afinitas node tersebut menyatakan pod hanya bisa ditugaskan pada node dengan label yang memiliki kunci `kubernetes.io/e2e-az-name` dan bernilai `e2e-az1` atau `e2e-az2`. Selain itu, dari semua node yang memenuhi kriteria tersebut, mode dengan label dengan kunci `another-node-label-key` and bernilai `another-node-label-value` harus lebih diutamakan. -Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/id/docs/concepts/configuration/taint-and-toleration/) untuk menolak pod dari node tertentu. +Kamu dapat meilhat operator `In` digunakan dalam contoh berikut. Sitaksis afinitas node yang baru mendukung operator-operator berikut: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. Kamu dapat menggunakan `NotIn` dan `DoesNotExist` untuk mewujudkan perilaku node anti-afinitas, atau menggunakan [node taints](/id/docs/concepts/scheduling-eviction/taint-and-toleration/) untuk menolak pod dari node tertentu. Jika kamu menyatakan `nodeSelector` dan `nodeAffinity`. *keduanya* harus dipenuhi agar pod dapat dijadwalkan pada node kandidat. @@ -284,7 +284,7 @@ Lihat [tutorial ZooKeeper](/docs/tutorials/stateful-application/zookeeper/#toler Untuk informasi lebih lanjut tentang afinitas/anti-afinitas antar pod, lihat [design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md). -Kamu juga dapat mengecek [Taints](/id/docs/concepts/configuration/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod. +Kamu juga dapat mengecek [Taints](/id/docs/concepts/scheduling-eviction/taint-and-toleration/), yang memungkinkan sebuah *node* untuk *menolak* sekumpulan pod. ## nodeName diff --git a/content/id/docs/concepts/scheduling/kube-scheduler.md b/content/id/docs/concepts/scheduling-eviction/kube-scheduler.md similarity index 99% rename from content/id/docs/concepts/scheduling/kube-scheduler.md rename to content/id/docs/concepts/scheduling-eviction/kube-scheduler.md index 6f7efab3d9..f55b1d942d 100644 --- a/content/id/docs/concepts/scheduling/kube-scheduler.md +++ b/content/id/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -94,7 +94,7 @@ penilaian oleh penjadwal: ## {{% heading "whatsnext" %}} -* Baca tentang [penyetelan performa penjadwal](/id/docs/concepts/scheduling/scheduler-perf-tuning/) +* Baca tentang [penyetelan performa penjadwal](/id/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) * Baca tentang [pertimbangan penyebarang topologi pod](/id/docs/concepts/workloads/pods/pod-topology-spread-constraints/) * Baca [referensi dokumentasi](/docs/reference/command-line-tools-reference/kube-scheduler/) untuk _kube-scheduler_ * Pelajari tentang [mengkonfigurasi beberapa penjadwal](/docs/tasks/administer-cluster/configure-multiple-schedulers/) diff --git a/content/id/docs/concepts/configuration/resource-bin-packing.md b/content/id/docs/concepts/scheduling-eviction/resource-bin-packing.md similarity index 100% rename from content/id/docs/concepts/configuration/resource-bin-packing.md rename to content/id/docs/concepts/scheduling-eviction/resource-bin-packing.md diff --git a/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md b/content/id/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md similarity index 97% rename from content/id/docs/concepts/scheduling/scheduler-perf-tuning.md rename to content/id/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 3689ecf7cb..3e94be5432 100644 --- a/content/id/docs/concepts/scheduling/scheduler-perf-tuning.md +++ b/content/id/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -8,7 +8,7 @@ weight: 70 {{< feature-state for_k8s_version="v1.14" state="beta" >}} -[kube-scheduler](/id/docs/concepts/scheduling/kube-scheduler/#kube-scheduler) +[kube-scheduler](/id/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler) merupakan penjadwal (_scheduler_) Kubernetes bawaan yang bertanggung jawab terhadap penempatan Pod-Pod pada seluruh Node di dalam sebuah klaster. @@ -66,7 +66,7 @@ Kamu bisa mengatur ambang batas untuk menentukan berapa banyak jumlah Node minim persentase bagian dari seluruh Node di dalam klaster kamu. kube-scheduler akan mengubahnya menjadi bilangan bulat berisi jumlah Node. Saat penjadwalan, jika kube-scheduler mengidentifikasi cukup banyak Node-Node layak untuk melewati jumlah persentase yang diatur, maka kube-scheduler -akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/id/docs/concepts/scheduling/kube-scheduler/#kube-scheduler-implementation). +akan berhenti mencari Node-Node layak dan lanjut ke [fase penskoran] (/id/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation). [Bagaimana penjadwal mengecek Node](#bagaimana-penjadwal-mengecek-node) menjelaskan proses ini secara detail. diff --git a/content/id/docs/concepts/scheduling/scheduling-framework.md b/content/id/docs/concepts/scheduling-eviction/scheduling-framework.md similarity index 100% rename from content/id/docs/concepts/scheduling/scheduling-framework.md rename to content/id/docs/concepts/scheduling-eviction/scheduling-framework.md diff --git a/content/id/docs/concepts/configuration/taint-and-toleration.md b/content/id/docs/concepts/scheduling-eviction/taint-and-toleration.md similarity index 100% rename from content/id/docs/concepts/configuration/taint-and-toleration.md rename to content/id/docs/concepts/scheduling-eviction/taint-and-toleration.md diff --git a/content/id/docs/concepts/scheduling/_index.md b/content/id/docs/concepts/scheduling/_index.md deleted file mode 100644 index 8903577124..0000000000 --- a/content/id/docs/concepts/scheduling/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "Penjadwalan" -weight: 90 ---- - diff --git a/content/id/docs/concepts/services-networking/service.md b/content/id/docs/concepts/services-networking/service.md index 5136a00415..3c85c5abbf 100644 --- a/content/id/docs/concepts/services-networking/service.md +++ b/content/id/docs/concepts/services-networking/service.md @@ -745,7 +745,7 @@ dan tidak akan menerima trafik apa pun. Untuk menghasilkan distribusi trafik yang merata, kamu dapat menggunakan _DaemonSet_ atau melakukan spesifikasi -[pod anti-affinity](/id/docs/concepts/configuration/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) +[pod anti-affinity](/id/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity-beta-feature) agar `Pod` tidak di-_assign_ ke _node_ yang sama. NLB juga dapat digunakan dengan anotasi [internal load balancer](/id/docs/concepts/services-networking/service/#internal-load-balancer). diff --git a/content/id/docs/concepts/storage/_index.md b/content/id/docs/concepts/storage/_index.md old mode 100755 new mode 100644 diff --git a/content/id/docs/concepts/storage/storage-classes.md b/content/id/docs/concepts/storage/storage-classes.md index 2897399e80..083620d937 100644 --- a/content/id/docs/concepts/storage/storage-classes.md +++ b/content/id/docs/concepts/storage/storage-classes.md @@ -149,10 +149,10 @@ PersistentVolumeClaim dibuat. PersistentVolume akan dipilih atau di-_provisionin sesuai dengan topologi yang dispesifikasikan oleh limitasi yang diberikan oleh mekanisme _scheduling_ Pod. Hal ini termasuk, tetapi tidak hanya terbatas pada, [persyaratan sumber daya](/id/docs/concepts/configuration/manage-compute-resources-container), -[_node selector_](/id/docs/concepts/configuration/assign-pod-node/#nodeselector), +[_node selector_](/id/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector), [afinitas dan -anti-afinitas Pod](/id/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity), -serta [_taint_ dan _toleration_](/id/docs/concepts/configuration/taint-and-toleration). +anti-afinitas Pod](/id/docs/concepts/scheduling-evictionassign-pod-node/#affinity-and-anti-affinity), +serta [_taint_ dan _toleration_](/id/docs/concepts/scheduling-eviction/taint-and-toleration). Beberapa _plugin_ di bawah ini mendukung `WaitForFirstConsumer` dengan _provisioning_ dinamis: @@ -595,11 +595,11 @@ metadata: provisioner: kubernetes.io/azure-disk parameters: storageaccounttype: Standard_LRS - kind: Shared + kind: managed ``` * `storageaccounttype`: Akun penyimpanan Azure yang ada pada tingkatan Sku. Nilai _default_-nya adalah kosong. -* `kind`: Nilai yang mungkin adalah `shared` (default), `dedicated`, dan `managed`. +* `kind`: Nilai yang mungkin adalah `shared`, `dedicated`, dan `managed` (default). Ketika `kind` yang digunakan adalah `shared`, semua disk yang tidak di-_manage_ akan dibuat pada beberapa akun penyimpanan yang ada pada grup sumber daya yang sama dengan klaster. Ketika `kind` yang digunakan adalah `dedicated`, sebuah akun penyimpanan diff --git a/content/id/docs/concepts/workloads/controllers/daemonset.md b/content/id/docs/concepts/workloads/controllers/daemonset.md index 0b1c0e71e9..905a0a193a 100644 --- a/content/id/docs/concepts/workloads/controllers/daemonset.md +++ b/content/id/docs/concepts/workloads/controllers/daemonset.md @@ -97,8 +97,8 @@ membuat Pod dengan nilai yang berbeda di sebuah Node untuk _testing_. Jika kamu menspesifikasikan `.spec.template.spec.nodeSelector`, maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [selektor -Node](/id/docs/concepts/configuration/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`, -maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/id/docs/concepts/configuration/assign-pod-node/). +Node](/id/docs/concepts/scheduling-eviction/assign-pod-node/). Demikian juga, jika kamu menspesifikasikan `.spec.template.spec.affinity`, +maka _controller_ DaemonSet akan membuat Pod pada Node yang cocok dengan [Node affinity](/id/docs/concepts/scheduling-eviction/assign-pod-node/). Jika kamu tidak menspesifikasikan sama sekali, maka _controller_ DaemonSet akan membuat Pod pada semua Node. diff --git a/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md b/content/id/docs/concepts/workloads/controllers/job.md similarity index 99% rename from content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md rename to content/id/docs/concepts/workloads/controllers/job.md index 5f4720646b..4a7cce3f2a 100644 --- a/content/id/docs/concepts/workloads/controllers/jobs-run-to-completion.md +++ b/content/id/docs/concepts/workloads/controllers/job.md @@ -1,5 +1,5 @@ --- -title: Job - Dijalankan Hingga Selesai +title: Jobs content_type: concept feature: title: Eksekusi batch diff --git a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md index 97aa5a47f3..0f462008ee 100644 --- a/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/id/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -10,7 +10,7 @@ weight: 65 Pengendali TTL menyediakan mekanisme TTL yang membatasi umur dari suatu objek sumber daya yang telah selesai digunakan. Pengendali TTL untuk saat ini hanya menangani -[Jobs](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/), +{{< glossary_tooltip text="Jobs" term_id="job" >}}, dan nantinya bisa saja digunakan untuk sumber daya lain yang telah selesai digunakan misalnya saja Pod atau sumber daya khusus (_custom resource_) lainnya. @@ -32,7 +32,7 @@ Pengendali TTL untuk saat ini hanya mendukung Job. Sebuah operator klaster dapat menggunakan fitur ini untuk membersihkan Job yang telah dieksekusi (baik `Complete` atau `Failed`) secara otomatis dengan menentukan _field_ `.spec.ttlSecondsAfterFinished` pada Job, seperti yang tertera di -[contoh](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically). +[contoh](/id/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically). Pengendali TTL akan berasumsi bahwa sebuah sumber daya dapat dihapus apabila TTL dari sumber daya tersebut telah habis. Proses dihapusnya sumber daya ini dilakukan secara berantai, dimana sumber daya lain yang diff --git a/content/id/docs/contribute/localization_id.md b/content/id/docs/contribute/localization_id.md index 5a9c491297..beffa5be6c 100644 --- a/content/id/docs/contribute/localization_id.md +++ b/content/id/docs/contribute/localization_id.md @@ -107,7 +107,7 @@ dapat menemukan kata-kata tersebut dalam bahasa Indonesia. ### Panduan untuk kata-kata API Objek Kubernetes Gunakan gaya "CamelCase" untuk menulis objek API Kubernetes, lihat daftar -lengkapnya [di sini](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/). +lengkapnya [di sini](/docs/reference/kubernetes-api/). Sebagai contoh: * *Benar*: PersistentVolume. *Salah*: volume persisten, `PersistentVolume`, @@ -130,7 +130,7 @@ ditulis dalam huruf kapital pada halaman asli bahasa Inggris. ### Panduan untuk "Feature Gate" Kubernetes -Istilah [_functional gate_](https://kubernetes.io/ko/docs/reference/command-line-tools-reference/feature-gates/) +Istilah [_feature gate_](/docs/reference/command-line-tools-reference/feature-gates/) Kubernetes tidak perlu diterjemahkan ke dalam bahasa Indonesia dan tetap dipertahankan dalam bentuk aslinya. @@ -175,4 +175,4 @@ scale | | skala | | process | kata kerja | memproses | https://kbbi.web.id/proses | replica | kata benda | replika | https://kbbi.web.id/replika | flag | | tanda, parameter, argumen | | -event | | _event_ | | \ No newline at end of file +event | | _event_ | | diff --git a/content/id/docs/reference/glossary/controller.md b/content/id/docs/reference/glossary/controller.md old mode 100755 new mode 100644 diff --git a/content/id/docs/reference/glossary/managed-service.md b/content/id/docs/reference/glossary/managed-service.md old mode 100755 new mode 100644 diff --git a/content/id/docs/reference/glossary/name.md b/content/id/docs/reference/glossary/name.md old mode 100755 new mode 100644 diff --git a/content/id/docs/reference/glossary/service-broker.md b/content/id/docs/reference/glossary/service-broker.md old mode 100755 new mode 100644 diff --git a/content/id/docs/reference/glossary/service-catalog.md b/content/id/docs/reference/glossary/service-catalog.md old mode 100755 new mode 100644 diff --git a/content/id/docs/reference/glossary/service.md b/content/id/docs/reference/glossary/service.md old mode 100755 new mode 100644 diff --git a/content/id/docs/reference/glossary/taint.md b/content/id/docs/reference/glossary/taint.md new file mode 100644 index 0000000000..1545a025fd --- /dev/null +++ b/content/id/docs/reference/glossary/taint.md @@ -0,0 +1,18 @@ +--- +title: Taint +id: taint +date: 2019-01-11 +full_link: /id/docs/concepts/scheduling-eviction/taint-and-toleration/ +short_description: > + Objek inti yang terdiri dari tiga properti yang diperlukan: _key_(kunci), _value_(nilai), dan _effect_(efek). Taint mencegah penjadwalan Pod pada Node atau grup Node. + +aka: +tags: +- core-object +- fundamental +--- + Objek inti yang terdiri dari tiga properti yang diperlukan: _key_(kunci), _value_(nilai), dan _effect_(efek). Taint mencegah penjadwalan {{< glossary_tooltip text="Pod" term_id="pod" >}} pada {{< glossary_tooltip text="Node" term_id="node" >}} atau grup dari Node. + + + +Taint dan {{< glossary_tooltip text="toleransi" term_id="toleration" >}} bekerja sama untuk memastikan bahwa Pod tidak dijadwalkan ke Node yang tidak sesuai. Satu atau lebih taint dapat diterapkan pada Node. Sebuah Node seharusnya hanya menjadwalkan Pod dengan toleransi yang cocok untuk taint yang dikonfigurasi. diff --git a/content/id/docs/reference/glossary/toleration.md b/content/id/docs/reference/glossary/toleration.md new file mode 100644 index 0000000000..45a2ac7f7c --- /dev/null +++ b/content/id/docs/reference/glossary/toleration.md @@ -0,0 +1,17 @@ +--- +title: Toleransi (Toleration) +id: toleration +date: 2019-01-11 +full_link: /docs/concepts/scheduling-eviction/taint-and-toleration/ +short_description: > + Objek inti yang terdiri dari tiga properti yang diperlukan: _key_(kunci), _value_(nilai), dan _effect_(efek). Toleransi memungkinkan penjadwalan Pod pada Node atau grup dari Node yang memiliki taint yang cocok. +aka: +tags: +- core-object +- fundamental +--- + Objek inti yang terdiri dari tiga properti yang diperlukan: _key_(kunci), _value_(nilai), dan _effect_(efek). Toleransi memungkinkan penjadwalan Pod pada Node atau grup dari Node yang memiliki {{< glossary_tooltip text="taints" term_id="taint" >}} yang cocok. + + + +Toleransi dan {{< glossary_tooltip text="taints" term_id="taint" >}} bekerja sama untuk memastikan bahwa Pod tidak dijadwalkan ke Node yang tidak sesuai. Satu atau lebih taint dapat diterapkan pada Node. Sebuah Node seharusnya hanya menjadwalkan Pod dengan toleransi yang cocok untuk taint yang dikonfigurasi. diff --git a/content/id/docs/reference/glossary/uid.md b/content/id/docs/reference/glossary/uid.md old mode 100755 new mode 100644 diff --git a/content/id/docs/reference/setup-tools/kubeadm/_index.md b/content/id/docs/reference/setup-tools/kubeadm/_index.md index 6e858c541a..25fbca1cca 100644 --- a/content/id/docs/reference/setup-tools/kubeadm/_index.md +++ b/content/id/docs/reference/setup-tools/kubeadm/_index.md @@ -8,7 +8,7 @@ card: weight: 40 --- -Kubeadm adalah fitur yang dibuat untuk menyediakan `kubeadm init` dan` kubeadm join` sebagai praktik terbaik dengan "jalur cepat" untuk membuat klaster Kubernetes. +Kubeadm adalah fitur yang dibuat untuk menyediakan `kubeadm init` dan` kubeadm join` sebagai praktik terbaik dengan "jalur cepat" untuk membuat klaster Kubernetes. kubeadm melakukan tindakan yang diperlukan untuk membuat klaster minimum yang layak untuk aktif dan berjalan. Secara desain, ini hanya memperdulikan tentang *bootstrap*, bukan tentang mesin *provisioning*. Demikian pula, dengan instalasi berbagai *addon* atau tambahan yang bagus untuk dimiliki, seperti Dasbor Kubernetes, solusi pemantauan, dan tambahan khusus cloud, tidak termasuk dalam cakupan. diff --git a/content/id/docs/setup/best-practices/_index.md b/content/id/docs/setup/best-practices/_index.md old mode 100755 new mode 100644 diff --git a/content/id/docs/setup/learning-environment/_index.md b/content/id/docs/setup/learning-environment/_index.md index 4c116a9bc0..cdfe637e64 100644 --- a/content/id/docs/setup/learning-environment/_index.md +++ b/content/id/docs/setup/learning-environment/_index.md @@ -2,3 +2,34 @@ title: Lingkungan Pembelajaran weight: 20 --- + +## kind + +[`kind`](https://kind.sigs.k8s.io/docs/) memberikan kamu kemampuan untuk +menjalankan Kubernetes pada komputer lokal kamu. Perangkat ini membutuhkan +[Docker](https://docs.docker.com/get-docker/) yang sudah diinstal dan +terkonfigurasi. + +Halaman [Memulai Cepat](https://kind.sigs.k8s.io/docs/user/quick-start/) `kind` +memperlihatkan kepada kamu tentang apa yang perlu kamu lakukan agar `kind` dapat +berjalan dan bekerja. + +Melihat Memulai Cepat Kind + +## minikube + +Seperti halnya dengan `kind`, [`minikube`](https://minikube.sigs.k8s.io/) +merupakan perangkat yang memungkinkan kamu untuk menjalankan Kubernetes +secara lokal. `minikube` menjalankan sebuah klaster Kubernetes dengan +satu node saja dalam komputer pribadi (termasuk Windows, macOS dan Linux) +sehingga kamu dapat mencoba Kubernetes atau untuk pekerjaan pengembangan +sehari-hari. + +Kamu bisa mengikuti petunjuk resmi +[Memulai!](https://minikube.sigs.k8s.io/docs/start/) +`minikube` jika kamu ingin fokus agar perangkat ini terinstal. + +Lihat Panduan Memulai! Minikube + +Setelah kamu memiliki `minikube` yang bekerja, kamu bisa menggunakannya +untuk [menjalankan aplikasi contoh](/id/docs/tutorials/hello-minikube/). diff --git a/content/id/docs/setup/learning-environment/minikube.md b/content/id/docs/setup/learning-environment/minikube.md deleted file mode 100644 index 8729968738..0000000000 --- a/content/id/docs/setup/learning-environment/minikube.md +++ /dev/null @@ -1,514 +0,0 @@ ---- -title: Instalasi Kubernetes dengan Minikube -weight: 30 -content_type: concept ---- - - - -Minikube adalah alat yang memudahkan untuk menjalankan Kubernetes pada komputer lokal. Minikube menjalankan satu Node klaster Kubernetes di dalam _Virtual Machine_ (VM) pada laptop kamu untuk pengguna yang ingin mencoba Kubernetes atau mengembangkannya. - - - - -## Fitur Minikube - -Minikube mendukung fitur Kubernetes berikut: - -* DNS -* NodePort -* {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}} dan {< glossary_tooltip text="Secret" term_id="secret" >}} -* _Dashboard_ -* _Container runtime_: [Docker](https://www.docker.com/), [CRI-O](https://cri-o.io/), dan [containerd](https://github.com/containerd/containerd) -* {{< glossary_tooltip text="CNI" term_id="cni" >}} -* Ingress - -## Instalasi - -Lihat [Instalasi Minikube](/id/docs/tasks/tools/install-minikube/). - -## Memulai Cepat - -Demonstrasi singkat ini memandu kamu tentang bagaimana memulai, menggunakan dan menghapus Minikube secara lokal. Ikuti langkah berikut untuk memulai dan menjelajahi Minikube. - -1. Mulailah Minikube dan buatlah sebuah klaster: - - ```shell - minikube start - ``` - - Keluaran menyerupai: - - ``` - Starting local Kubernetes cluster... - Running pre-create checks... - Creating machine... - Starting local Kubernetes cluster... - ``` - Untuk informasi lebih lanjut mengenai bagaimana memulai klaster pada versi Kubernetes tertentu, VM atau Container _runtime_, lihatlah [Memulai klaster](#memulai-klaster). - -2. Kini kamu bisa berinteraksi dengan klaster kamu dengan kubectl. Untuk informasi lebih lanjut, lihatlah [Interaksi dengan klaster kamu](#interaksi-dengan-klaster-kamu). - - Mari kita buat Kubernetes Deployment menggunakan _image_ bernama `echoserver`, yaitu sebuah server HTTP sederhana dan buka layanan pada porta 8080 dengan menggunakan opsi `--port`. - - ```shell - kubectl create deployment hello-minikube --image=k8s.gcr.io/echoserver:1.10 - ``` - - Keluaran menyerupai: - - ``` - deployment.apps/hello-minikube created - ``` -3. Untuk mengakses Deployment `hello-minikube`, bukalah dia sebagai sebuah Service: - - ```shell - kubectl expose deployment hello-minikube --type=NodePort --port=8080 - ``` - - Opsi `--type=NodePort` menentukan tipe Service. - - Keluarannya menyerupai: - - ``` - service/hello-minikube exposed - ``` - -4. Pod `hello-minikube` saat ini telah dibuat namun kamu harus menunggu hingga Pod selesai dijalankan sebelum dapat mengaksesnya melalui Service yang telah dibuka. - - Cek apakah Pod sudah berjalan dan beroperasi: - - ```shell - kubectl get pod - ``` - - Jika keluaran menampilkan `STATUS` sebagai `ContainerCreating`, maka Pod sedang dalam proses pembuatan: - - ``` - NAME READY STATUS RESTARTS AGE - hello-minikube-3383150820-vctvh 0/1 ContainerCreating 0 3s - ``` - - Jika keluaran menampilkan `STATUS` sebagai `Running`, maka Pod sudah berjalan dan beroperasi: - - ``` - NAME READY STATUS RESTARTS AGE - hello-minikube-3383150820-vctvh 1/1 Running 0 13s - ``` - -5. Ambil URL Service yang telah dibuka untuk melihat Service secara detail: - - ```shell - minikube service hello-minikube --url - ``` - -6. Untuk melihat detail dari klaster lokal kamu, salin dan tempel URL yang kamu dapatkan dari keluaran pada peramban kamu. - - Keluarannya menyerupai: - - ``` - Hostname: hello-minikube-7c77b68cff-8wdzq - - Pod Information: - -no pod information available- - - Server values: - server_version=nginx: 1.13.3 - lua: 10008 - - Request Information: - client_address=172.17.0.1 - method=GET - real path=/ - query= - request_version=1.1 - request_scheme=http - request_uri=http://192.168.99.100:8080/ - - Request Headers: - accept=*/* - host=192.168.99.100:30674 - user-agent=curl/7.47.0 - - Request Body: - -no body in request- - ``` - - Jika kamu tidak lagi membutuhkan Service dan klaster, maka kamu bisa menghapusnya. - -7. Hapuslah Service `hello-minikube`: - - ```shell - kubectl delete services hello-minikube - ``` - - Keluarannya menyerupai: - - ``` - service "hello-minikube" deleted - ``` - -8. Hapuslah Deployment `hello-minikube`: - - ```shell - kubectl delete deployment hello-minikube - ``` - - Keluarannya menyerupai: - - ``` - deployment.extensions "hello-minikube" deleted - ``` - -9. Hentikanlah klaster Minikube lokal: - - ```shell - minikube stop - ``` - - Keluarannya menyerupai: - - ``` - Stopping "minikube"... - "minikube" stopped. - ``` - - Untuk informasi lebih lanjut, lihatlah [Menghentikan Klaster](#menghentikan-klaster). - -10. Hapuslah klaster Minikube lokal - - ```shell - minikube delete - ``` - Keluarannya menyerupai: - ``` - Deleting "minikube" ... - The "minikube" cluster has been deleted. - ``` - Untuk informasi lebih lanjut, lihat [Menghapus Klaster](#menghapus-klaster). - -## Mengelola Klaster - -### Memulai Klaster - -Perintah `minikube start` bisa digunakan untuk memulai klaster kamu. -Perintah ini membuat dan mengonfigurasi sebuah mesin virtual yang menjalankan klaster Kubernetes dengan satu Node. -Perintah ini juga mengonfigurasi instalasi [kubectl](/id/docs/user-guide/kubectl-overview/) untuk berkomunikasi dengan klaster ini. - -{{< note >}} -Jika kamu menggunakan proksi web, maka kamu harus meneruskan informasi berikut ini ke perintah `minikube start`: - -```shell -https_proxy= minikube start --docker-env http_proxy= --docker-env https_proxy= --docker-env no_proxy=192.168.99.0/24 -``` -Sayangnya, pengaturan dengan _environment variable_ saja tidak berguna. - -Minikube juga membuat konteks "minikube", dan menetapkannya sebagai bawaan di kubectl. -Untuk kembali menggunakan konteks ini, jalankan perintah: `kubectl config use-context minikube`. -{{< /note >}} - -#### Menentukan Versi Kubernetes - -Kamu bisa menentukan versi Kubernetes yang digunakan oleh Minikube dengan -menambahkan `--kubernetes-version` ke perintah `minikube start`. Sebagai -contoh, untuk menjalankan versi {{}}, kamu akan menjalankan perintah berikut: - -``` -minikube start --kubernetes-version {{< param "fullversion" >}} -``` -#### Menentukan _driver_ VM - -Kamu bisa mengubah _driver_ VM dengan menambahkan tanda `--driver=` pada `minikube start`. -Sebagai contoh: -```shell -minikube start --driver= -``` - -Minikube mendukung _driver_ berikut ini: -{{< note >}} -Lihat [_DRIVER_](https://minikube.sigs.k8s.io/docs/reference/drivers/) untuk detail tentang _driver_ yang didukung dan proses instalasi _plugin_. -{{< /note >}} - -* ([instalasi driver](https://minikube.sigs.k8s.io/docs/drivers/docker/)) docker -* ([instalasi driver](https://minikube.sigs.k8s.io/docs/drivers/virtualbox/)) virtualbox -* ([instalasi driver](https://minikube.sigs.k8s.io/docs/drivers/podman/)) podman (TAHAP EXPERIMEN) -* vmwarefusion -* ([instalasi driver](https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/)) kvm2 -* ([instalasi driver](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/)) hyperkit -* ([instalasi driver](https://minikube.sigs.k8s.io/docs/reference/drivers/hyperv/)) hyperv -Perlu diingat bahwa IP dibawah adalah dinamik dan bisa berubah. IP ini bisa diambil dengan `minikube ip`. -* ([instalasi driver](https://minikube.sigs.k8s.io/docs/reference/drivers/vmware/)) vmware (_driver_ VMware terpadu) -* ([instalasi driver](https://minikube.sigs.k8s.io/docs/reference/drivers/parallels/)) parallels -* none (menjalankan komponen Kubernetes pada hos dan bukan pada mesin virtual. Kamu harus menjalankan Linux dan harus menginstal {{}}.) - -{{< caution >}} -Jika kamu menggunakan _driver_ `none`, beberapa komponen Kubernetes dijalankan sebagai Container istimewa yang memiliki efek samping di luar lingkungan Minikube. Efek samping tersebut berarti bahwa _driver_ `none` tidak direkomendasikan untuk komputer pribadi. -{{< /caution >}} - -#### Memulai klaster pada _runtime_ kontainer alternatif -Kamu bisa memulai Minikube pada _runtime_ kontainer berikut. -{{< tabs name="container_runtimes" >}} -{{% tab name="containerd" %}} -Untuk menggunakan [containerd](https://github.com/containerd/containerd) sebagai _runtime_ kontainer, jalankan: -```bash -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --container-runtime=containerd \ - --bootstrapper=kubeadm -``` - -Atau kamu bisa menggunakan versi yang diperpanjang: - -```bash -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --extra-config=kubelet.container-runtime=remote \ - --extra-config=kubelet.container-runtime-endpoint=unix:///run/containerd/containerd.sock \ - --extra-config=kubelet.image-service-endpoint=unix:///run/containerd/containerd.sock \ - --bootstrapper=kubeadm -``` -{{% /tab %}} -{{% tab name="CRI-O" %}} -Untuk menggunakan [CRI-O](https://cri-o.io/) sebagain _runtime_ kontainer, jalankan: -```bash -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --container-runtime=cri-o \ - --bootstrapper=kubeadm -``` -Atau kamu bisa menggunakan versi yang diperpanjang: - -```bash -minikube start \ - --network-plugin=cni \ - --enable-default-cni \ - --extra-config=kubelet.container-runtime=remote \ - --extra-config=kubelet.container-runtime-endpoint=/var/run/crio.sock \ - --extra-config=kubelet.image-service-endpoint=/var/run/crio.sock \ - --bootstrapper=kubeadm -``` -{{% /tab %}} -{{< /tabs >}} - -#### Menggunakan _image_ lokal degan menggunakan kembali _daemon_ Docker - -Saat menggunakan sebuah VM untuk Kubernetes, akan lebih baik jika _daemon_ Docker bawaan Minikube digunakan kembali. Menggunakan kembali _daemon_ bawaan membuat kamu tidak perlu membangun registri Docker pada mesin hos kamu dan mengunggah _image_ ke dalamnya. Namun, kamu dapat membangun di dalam _daemon_ Docker yang sama dengan Minikube, yang tentunya dapat mempercepat percobaan lokal. - -{{< note >}} -Pastikan untuk memberi _tag_ pada Docker _image_ kamu dengan sesuatu selain `latest` dan gunakan _tag_ tersebut untuk menarik _image_. Karena `:latest` adalah bawaan, dengan kebijakan penarikan _image_ bawaan, yaitu `Always`, kesalahan penarikan _image_ (`ErrImagePull`) akhirnya dapat terjadi jika kamu tidak memiliki _image_ Docker di register Docker bawaan (biasanya DockerHub). -{{< /note >}} - -Untuk bekerja dengan _daemon_ Docker pada mesin Mac/Linux, jalankan baris terakhir dari `minikube docker-env`. - -Kamu sekarang dapat menggunakan Docker di terminal mesin Mac/Linux kamu untuk berkomunikasi dengan _daemon_ Docker di dalam VM Minikube: - -```shell -docker ps -``` - -{{< note >}} -Pada Centos 7, Docker bisa memberikan kesalahan berikut: - -``` -Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no such file or directory -``` - -Kamu bisa memperbaikinya dengan memperbaharui /etc/sysconfig/docker untuk memastikan bahwa lingkungan Minikube dikenali: - -```shell -< DOCKER_CERT_PATH=/etc/docker ---- -> if [ -z "${DOCKER_CERT_PATH}" ]; then -> DOCKER_CERT_PATH=/etc/docker -> fi -``` -{{< /note >}} - -### Mengonfigurasi Kubernetes - -Minikube memiliki sebuah fitur "pengonfigurasi" yang memperbolehkan pengguna untuk mengkonfigurasi komponen Kubernetes dengan sembarang nilai. -Untuk menggunakan fitur ini, kamu bisa menggunakan _flag_ `--extra-config` pada perintah `minikube start`. - -_Flag_ ini berulang, jadi kamu bisa menggunakannya beberapa kali dengan beberapa nilai yang berbeda untuk mengatur beberapa opsi. - -_Flag_ ini menerima sebuah _string_ dalam format `component.key=value`, di mana `component` adalah salah satu _string_ dari list di bawah, `key` adalah nilai dari _struct_ configurasi dan `value` adalah nilai yang digunakan. - -Kunci yang valid bisa ditemukan dengan memeriksa dokumentasi `componentconfigs` Kubernetes untuk setiap komponen. -Berikut adalah dokumentasi untuk setiap konfigurasi yang didukung: - -* [kubelet](https://godoc.org/k8s.io/kubernetes/pkg/kubelet/apis/config#KubeletConfiguration) -* [apiserver](https://godoc.org/k8s.io/kubernetes/cmd/kube-apiserver/app/options#ServerRunOptions) -* [proxy](https://godoc.org/k8s.io/kubernetes/pkg/proxy/apis/config#KubeProxyConfiguration) -* [controller-manager](https://godoc.org/k8s.io/kubernetes/pkg/controller/apis/config#KubeControllerManagerConfiguration) -* [etcd](https://godoc.org/github.com/coreos/etcd/etcdserver#ServerConfig) -* [scheduler](https://godoc.org/k8s.io/kubernetes/pkg/scheduler/apis/config#KubeSchedulerConfiguration) - -#### Contoh - -Untuk mengubah pengaturan `MaxPods` menjadi 5 pada Kubelet, gunakan _flag_ ini: `--extra-config=kubelet.MaxPods=5`. - -Fitur ini juga mendukung _struct_ yang berulang. Untuk mengubah pengaturan `LeaderElection.LeaderElect` menjadi `true` pada penjadwal, gunakan _flag_: `--extra-config=scheduler.LeaderElection.LeaderElect=true`. - -Untuk mengatur `AuthorizationMode` pada `apiserver` menjadi `RBAC`, kamu bisa menggunakan: `--extra-config=apiserver.authorization-mode=RBAC`. - -### Menghentikan klaster -Perintah `minikube stop` bisa digunakan untuk menghentikan klaster kamu. -Perintah ini menghentikan mesin virtual Minikube, tapi mempertahankan semua status dan data klaster. -Memulai klaster lagi akan mengembalikannya ke keadaan sebelumnya. - -### Menghapus klaster -Perintah `minikube delete` bisa digunakan untuk menghapus klaster kamu. -Perintah ini menghentikan dan menghapus mesin virtual Minikube. Tidak ada data atau _state_ yang dipertahankan. - -### Memperbaharui Minikube -Jika kamu menggunakan MacOS dan [Brew Package Manager](https://brew.sh/) sudah terpasang, jalankan: - -```shell -brew update -brew upgrade minikube -``` - -## Interaksi dengan Klaster Kamu - -### Kubectl - -Perintah `minikube start` membuat sebuah [konteks kubectl](/id/docs/reference/generated/kubectl/kubectl-commands#-em-set-context-em-) yang disebut "minikube". -Konteks ini menyimpan pengaturan untuk berkomunikasi dengan klaster Minikube kamu. - -Minikube menetapkan konteks ini sebagai bawaan secara otomatis, tetapi jika kamu ingin mengubah kembali ke konteks tersebut di kemudian hari, gunakan: - -`kubectl config use-context minikube` - -Atau berikan konteks untuk setiap perintah seperti ini: - -`kubectl get pods --context=minikube` - -### Dashboard - -Untuk mengakses [Kubernetes Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/), gunakan perintah ini pada terminal setelah memulai Minikube untuk mendapatkan alamatnya: - -```shell -minikube dashboard -``` - -### Service - -Untuk mengakses Service yang dibuka via NodePort, jalankan perintah ini pada terminal setelah memulai Minikube untuk mendapatkan alamat: - -```shell -minikube service [-n NAMESPACE] [--url] NAME -``` - -## Jaringan - -Mesin virtual Minikube dibuka ke sistem hos melalui alamat IP _host-only_ , yang bisa didapatkan dengan perintah `minikube ip`. -Seluruh Service dengan jenis `NodePort` bisa diakses melalui alamat IP pada NodePort. - -Untuk mementukan NodePort pada Service kamu, kamu bisa menggunakan perintah `kubectl` sebagai berikut: - -`kubectl get service $SERVICE --output='jsonpath="{.spec.ports[0].nodePort}"'` - -## PersistentVolume - -Minikube mendukung [PersistentVolume](/id/docs/concepts/storage/persistent-volumes/) dengan jenis `hostPath`. -PersistenVolume ini dipetakan ke direktori di dalam mesin virtual Minikube. - -Mesin virtual Minikube melakukan _booting_ ke tmpfs, sehingga sebagian besar direktori tidak akan bertahan setelah di _reboot_ (`minikube stop`). - -Namun, Minikube diatur untuk mempertahankan berkas yang tersimpan didalam direktori hos berikut: - -* `/data` -* `/var/lib/minikube` -* `/var/lib/docker` - -Ini adalah contoh pengaturan PersistentVolume untuk mempertahankan data di dalam direktori `/data`: - -```yaml -apiVersion: v1 -kind: PersistentVolume -metadata: - name: pv0001 -spec: - accessModes: - - ReadWriteOnce - capacity: - storage: 5Gi - hostPath: - path: /data/pv0001/ -``` - -## Folder hos yang di _mount_ -Beberapa _driver_ akan memasang folder _hos_ dalam VM sehingga kamu dapat dengan mudah berbagi berkas antara VM dan hos. Saat ini, hal tersebut tidak dapat dikonfigurasi dan berbeda untuk setiap _driver_ dan sistem operasi yang kamu gunakan. - -{{< note >}} -Berbagi folder hos belum diimplementasikan pada _driver_ KVM. -{{< /note >}} - -| Driver | OS | HostFolder | VM | -| --- | --- | --- | --- | -| VirtualBox | Linux | /home | /hosthome | -| VirtualBox | macOS | /Users | /Users | -| VirtualBox | Windows | C://Users | /c/Users | -| VMware Fusion | macOS | /Users | /mnt/hgfs/Users | -| Xhyve | macOS | /Users | /Users | - -## Registri Container Pribadi - -Untuk mengakses registri Container pribadi, ikuti langkah berikut pada [halaman ini](/id/docs/concepts/containers/images/). - -Kami merekomendasi penggunaan `ImagePullSecrets`, tetapi jika kamu ingin mengonfigurasi akses pada virtual mesin Minikube, kamu bisa menempatkan `.dockercfg` pada direktori `/home/docker` atau `config.json` dalam direktori `/home/docker/.docker`. - -## Tambahan (_Add-on_) - -Supaya Minikube memulai atau memulai kembali kustom tambahan dengan benar, -tempatkan tambahan yang ingin kamu jalankan di dalam direktori `~/.minikube/addons`. -Tambahan dalam folder akan dipindahkan ke virtual mesin Minikube dan dijalankan setiap kali Minikube -dimulai atau dimulai ulang. - -## Menggunakan Minikube dengan Proksi HTTP - -Minikube membuat sebuah mesin virtual yang memasukkan Kubernetes dan _daemon_ Docker. -Ketika Kubernetes berusaha untuk menjadwalkan Container dengan Docker, _daemon_ Docker mungkin membutuhkan -akses jaringan eksternal untuk menarik Container. - -Jika kamu berada di belakang _proxy_ HTTP, kamu mungkin perlu menyediakan Docker dengan pengaturan proksi. -Untuk melakukan ini, berikan _environment variable_ yang dibutuhkan sebagai _flag_ pada saat `minikube start`. - -Contoh: - -```shell -minikube start --docker-env http_proxy=http://$YOURPROXY:PORT \ - --docker-env https_proxy=https://$YOURPROXY:PORT -``` - -Jika alamat mesin virtual kamu adalah 192.168.99.100, maka ada kemungkinan pengaturan proksi kamu akan mencegah `kubectl` untuk mencapainya. -Untuk melewatkan konfigurasi _proxy_ untuk alamat IP ini, kamu harus memodifikasi pengaturan _no_proxy` kamu. Kamu bisa melakukannya dengan: - -```shell -export no_proxy=$no_proxy,$(minikube ip) -``` - -## Masalah yang Diketahui - -Fitur yang memerlukan banyak Node tidak akan berfungsi dalam Minikube. - -## Desain - -Minikube menggunakan [libmachine](https://github.com/docker/machine/tree/master/libmachine) untuk menyediakan mesin virtual, dan [kubeadm](https://github.com/kubernetes/kubeadm) untuk menyediakan klaster Kubernetes. - -Untuk info lebih lanjut tentang Minikube, lihat [proposal](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/local-cluster-ux.md). - -## Tautan Tambahan - -* **Tujuan and Non-Tujuan**: Untuk tujuan dan non-tujuan dari projek Minikube, lihat [roadmap](https://minikube.sigs.k8s.io/docs/contrib/roadmap/). -* **Petunjuk Pengembangan**: Lihat [Berkontribusi](https://minikube.sigs.k8s.io/docs/contrib/) untuk ikhtisar bagaimana cara mengirimkan _pull request_. -* **Membangun Minikube**: Untuk instruksi bagaimana membangun atau mengetes Minikube dari sumber kode, lihat [petunjuk membangun](https://minikube.sigs.k8s.io/docs/contrib/building/). -* **Menambahkan Dependensi Baru**: Untuk instruksi bagaimana menambahkan dependensi baru ke Minikube, lihat [petunjuk penambahan dependensi](https://minikube.sigs.k8s.io/docs/contrib/drivers/). -* **Menambahkan Addon Baru**: Untuk instruksi bagaimana menambahkan tambahan baru untuk Minikube, lihat [petunjuk menambahkan addon baru](https://minikube.sigs.k8s.io/docs/contrib/addons/). -* **MicroK8s**: Pengguna Linux yang ingin menghindari penggunaan mesin virtual, bisa mempertimbangkan [MicroK8s](https://microk8s.io/) sebagai alternatif. - -## Komunitas - -Kontribusi, pertanyaan, dan komentar sangat diharapkan! Pengembang Minikube berkumpul dalam [Slack](https://kubernetes.slack.com) di _channel_ #minikube (dapatkan undangan [di sini](http://slack.kubernetes.io/)). Kami juga memiliki [milis kubernetes-dev Google Groups](https://groups.google.com/forum/#!forum/kubernetes-dev). Jika kamu memposting sesuatu, awali subjek kamu dengan "minikube: ". diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index 6bbf23b53e..c4f68432ab 100644 --- a/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -6,7 +6,7 @@ weight: 30 -Perkakas `kubeadm` membantu kamu membuat sebuah klaster Kubernetes minimum yang layak dan sesuai dengan _best practice_. Bahkan, kamu dapat menggunakan `kubeadm` untuk membuat sebuah klaster yang lolos [uji Kubernetes Conformance](https://kubernetes.io/blog/2017/10/software-conformance-certification). +Perkakas `kubeadm` membantu kamu membuat sebuah klaster Kubernetes minimum yang layak dan sesuai dengan _best practice_. Bahkan, kamu dapat menggunakan `kubeadm` untuk membuat sebuah klaster yang lolos [uji Kubernetes Conformance](https://kubernetes.io/blog/2017/10/software-conformance-certification). `kubeadm` juga mendukung fungsi siklus hidup (_lifecycle_) klaster lainnya, seperti [_bootstrap token_](/docs/reference/access-authn-authz/bootstrap-tokens/) dan pembaruan klaster (_cluster upgrade_). @@ -635,5 +635,3 @@ mendukung platform pilihanmu. ## Penyelesaian masalah Jika kamu menemui kesulitan dengan kubeadm, silakan merujuk pada [dokumen penyelesaian masalah](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/). - - diff --git a/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index fa0b0ce7f0..fa474e82f9 100644 --- a/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/id/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -10,7 +10,7 @@ card: -Laman ini menunjukkan cara untuk menginstal `kubeadm`. +Laman ini menunjukkan cara untuk menginstal `kubeadm`. Untuk informasi mengenai cara membuat sebuah klaster dengan kubeadm setelah kamu melakukan proses instalasi ini, lihat laman [Menggunakan kubeadm untuk Membuat Sebuah Klaster](/id/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/). @@ -225,16 +225,18 @@ Menginstal _plugin_ CNI (dibutuhkan untuk kebanyakan jaringan Pod): ```bash CNI_VERSION="v0.8.2" +ARCH="amd64" mkdir -p /opt/cni/bin -curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz +curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz ``` Menginstal crictl (dibutuhkan untuk kubeadm / Kubelet Container Runtime Interface (CRI)) ```bash CRICTL_VERSION="v1.17.0" +ARCH="amd64" mkdir -p /opt/bin -curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz +curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz ``` Menginstal `kubeadm`, `kubelet`, `kubectl` dan menambahkan _systemd service_ `kubelet`: @@ -243,8 +245,9 @@ Menginstal `kubeadm`, `kubelet`, `kubectl` dan menambahkan _systemd service_ `ku RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)" mkdir -p /opt/bin +ARCH="amd64" cd /opt/bin -curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl} +curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl} chmod +x {kubeadm,kubelet,kubectl} RELEASE_VERSION="v0.2.7" diff --git a/content/id/docs/tasks/access-application-cluster/_index.md b/content/id/docs/tasks/access-application-cluster/_index.md old mode 100755 new mode 100644 diff --git a/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md index f2140e5276..86a6b267e2 100644 --- a/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md +++ b/content/id/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -28,7 +28,7 @@ Container untuk masing-masing Pod. - Silakan ambil semua Pod dalam Namespace dengan menggunakan perintah `kubectl get pods --all-namespaces` - Silakan format keluarannya agar hanya menyertakan daftar nama _image_ dari Container - dengan menggunakan perintah `-o jsonpath={..image}`. Perintah ini akan mem-_parsing field_ + dengan menggunakan perintah `-o jsonpath={.items[*].spec.containers[*].image}`. Perintah ini akan mem-_parsing field_ `image` dari keluaran json yang dihasilkan. - Silakan lihat [referensi jsonpath](/docs/user-guide/jsonpath/) untuk informasi lebih lanjut tentang cara menggunakan `jsonpath`. @@ -38,7 +38,7 @@ Container untuk masing-masing Pod. - Gunakan `uniq` untuk mengumpulkan jumlah _image_ ```sh -kubectl get pods --all-namespaces -o jsonpath="{..image}" |\ +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\ tr -s '[[:space:]]' '\n' |\ sort |\ uniq -c @@ -86,7 +86,7 @@ Untuk menargetkan hanya Pod yang cocok dengan label tertentu saja, gunakan tanda dibawah ini akan menghasilkan Pod dengan label yang cocok dengan `app=nginx`. ```sh -kubectl get pods --all-namespaces -o=jsonpath="{..image}" -l app=nginx +kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx ``` ## Membuat daftar _image_ Container yang difilter berdasarkan Namespace Pod @@ -95,7 +95,7 @@ Untuk hanya menargetkan Pod pada Namespace tertentu, gunakankan tanda Namespace. dibawah ini hanya menyaring Pod pada Namespace `kube-system`. ```sh -kubectl get pods --namespace kube-system -o jsonpath="{..image}" +kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}" ``` ## Membuat daftar _image_ Container dengan menggunakan go-template sebagai alternatif dari jsonpath diff --git a/content/id/docs/tasks/administer-cluster/_index.md b/content/id/docs/tasks/administer-cluster/_index.md old mode 100755 new mode 100644 diff --git a/content/id/docs/tasks/administer-cluster/sysctl-cluster.md b/content/id/docs/tasks/administer-cluster/sysctl-cluster.md index 9adbb50a9f..7120f087fa 100644 --- a/content/id/docs/tasks/administer-cluster/sysctl-cluster.md +++ b/content/id/docs/tasks/administer-cluster/sysctl-cluster.md @@ -156,7 +156,7 @@ Sangat disarankan untuk menggunakan Kubernetes [fitur _taints and toleration_](/ Pod dengan sysctl _unsafe_ akan gagal diluncurkan pada sembarang Node yang belum mengaktifkan kedua sysctl _unsafe_ secara eksplisit. Seperti halnya sysctl _node-level_ sangat disarankan untuk menggunakan [fitur _taints and toleration_](/docs/reference/generated/kubectl/kubectl-commands/#taint) atau -[pencemaran dalam Node](/docs/concepts/scheduling-eviction/taint-and-toleration/) +[pencemaran dalam Node](/id/docs/concepts/scheduling-eviction/taint-and-toleration/) untuk Pod dalam Node yang tepat. ## PodSecurityPolicy diff --git a/content/id/docs/tasks/configure-pod-container/_index.md b/content/id/docs/tasks/configure-pod-container/_index.md old mode 100755 new mode 100644 diff --git a/content/id/docs/tasks/configure-pod-container/configure-service-account.md b/content/id/docs/tasks/configure-pod-container/configure-service-account.md index 4a4d5999db..e53812d65a 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/id/docs/tasks/configure-pod-container/configure-service-account.md @@ -151,8 +151,8 @@ Keluarannya akan serupa dengan: Name: build-robot-secret Namespace: default Labels: -Annotations: kubernetes.io/service-account.name=build-robot - kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da +Annotations: kubernetes.io/service-account.name: build-robot + kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da Type: kubernetes.io/service-account-token diff --git a/content/id/docs/tasks/debug-application-cluster/_index.md b/content/id/docs/tasks/debug-application-cluster/_index.md old mode 100755 new mode 100644 diff --git a/content/id/docs/tasks/inject-data-application/_index.md b/content/id/docs/tasks/inject-data-application/_index.md old mode 100755 new mode 100644 diff --git a/content/id/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/id/docs/tasks/job/automated-tasks-with-cron-jobs.md index c2c4b9399f..5a850cb739 100644 --- a/content/id/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/id/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -146,7 +146,7 @@ Semua modifikasi pada sebuah CronJob, terutama `.spec`, akan diterapkan pada pro `.spec.schedule` adalah _field_ yang wajib diisi dari sebuah `.spec` Dibutuhkan sebuah format string [Cron](https://en.wikipedia.org/wiki/Cron), misalnya `0 * * * *` atau `@hourly`, sebagai jadwal Job untuk dibuat dan dieksekusi. -Format ini juga mencakup nilai langkah `Vixie cron`. Seperti penjelasan di [FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29): +Format ini juga mencakup nilai langkah "Vixie cron". Seperti penjelasan di [FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29): > Nilai langkah dapat digunakan bersama dengan rentang. Sebuah rentang diikuti dengan > `/` menentukan lompatan angka melalui rentang. @@ -162,8 +162,8 @@ Sebuah tanda tanya (`?`) dalam penjadwalan memiliki makna yang sama dengan tanda ### Templat Job `.spec.JobTemplate` adalah templat untuk sebuah Job, dan itu wajib. -Templat Job memiliki skema yang sama dengan [Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/), kecuali jika bersarang dan tidak memiliki sebuah `apiVersion` atau `kind`. -Untuk informasi lebih lanjut tentang menulis sebuah Job `.spec` lihat [Menulis spesifikasi Job](/id/docs/concepts/workloads/controllers/jobs-run-to-completion/#writing-a-job-spec). +Templat Job memiliki skema yang sama dengan [Job](/id/docs/concepts/workloads/controllers/job/), kecuali jika bersarang dan tidak memiliki sebuah `apiVersion` atau `kind`. +Untuk informasi lebih lanjut tentang menulis sebuah Job `.spec` lihat [Menulis spesifikasi Job](/id/docs/concepts/workloads/controllers/job/#writing-a-job-spec). ### _Starting Deadline_ diff --git a/content/id/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/id/docs/tasks/run-application/horizontal-pod-autoscale.md index 1ae40d2090..cd82ded0b1 100644 --- a/content/id/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/id/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -290,7 +290,7 @@ dan [panduan penggunaan metrik eksternal](/docs/tasks/run-application/horizontal ## Dukungan untuk Perilaku *Scaling* yang dapat Dikonfigurasi -Mulai dari versi [v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md), API `v2beta2` mengizinkan perilaku *scaling* dapat +Mulai dari versi [v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md), API `v2beta2` mengizinkan perilaku *scaling* dapat dikonfigurasi melalui *field* `behavior` pada HorizontalPodAutoscaler. Perilaku *scaling up* dan *scaling down* ditentukan terpisah pada *field* `slaceUp` dan *field* `scaleDown`, dibawah dari *field* `behavior`. Sebuah stabilisator dapat ditentukan untuk kedua arah *scale* untuk mencegah perubahan replika yang terlalu diff --git a/content/id/docs/tasks/tls/_index.md b/content/id/docs/tasks/tls/_index.md old mode 100755 new mode 100644 diff --git a/content/id/docs/tasks/tools/_index.md b/content/id/docs/tasks/tools/_index.md old mode 100755 new mode 100644 diff --git a/content/id/docs/tutorials/_index.md b/content/id/docs/tutorials/_index.md index 9f3ec5afb3..041b7b62d2 100644 --- a/content/id/docs/tutorials/_index.md +++ b/content/id/docs/tutorials/_index.md @@ -50,6 +50,8 @@ Sebelum melangkah lebih lanjut ke tutorial, sebaiknya tandai dulu halaman [Kamus * [AppArmor](/docs/tutorials/clusters/apparmor/) +* [seccomp](/docs/tutorials/clusters/seccomp/) + ## Servis * [Menggunakan Source IP](/docs/tutorials/services/source-ip/) diff --git a/content/id/docs/tutorials/hello-minikube.md b/content/id/docs/tutorials/hello-minikube.md index faba283d89..398c5a3a3f 100644 --- a/content/id/docs/tutorials/hello-minikube.md +++ b/content/id/docs/tutorials/hello-minikube.md @@ -15,11 +15,11 @@ card: -Tutorial ini menunjukkan bagaimana caranya menjalankan aplikasi sederhana Node.js Halo Dunia di Kubernetes, dengan [Minikube](/docs/getting-started-guides/minikube) dan Katacoda. +Tutorial ini menunjukkan bagaimana caranya menjalankan aplikasi sederhana Node.js Halo Dunia di Kubernetes, dengan [`minikube`](/docs/getting-started-guides/minikube) dan Katacoda. Katacoda menyediakan environment Kubernetes secara gratis di dalam browser. {{< note >}} -Kamupun bisa mengikuti tutorial ini kalau sudah instalasi [Minikube di lokal](/id/docs/tasks/tools/install-minikube/) kamu. +Kamupun bisa mengikuti tutorial ini kalau sudah instalasi minikube di lokal. Silakan lihat [memulai `minikube`](https://minikube.sigs.k8s.io/docs/start/) untuk instruksi instalasi. {{< /note >}} @@ -27,7 +27,7 @@ Kamupun bisa mengikuti tutorial ini kalau sudah instalasi [Minikube di lokal](/i ## {{% heading "objectives" %}} -* Deploy aplikasi halo dunia pada Minikube. +* Deploy aplikasi halo dunia pada minikube. * Jalankan aplikasinya. * Melihat log aplikasi. @@ -54,7 +54,7 @@ Untuk info lebih lanjut tentang perintah `docker build`, baca [dokumentasi Docke {{< kat-button >}} - {{< note >}}Kalau kamu memilih instalasi Minikube secara lokal, jalankan `minikube start`.{{< /note >}} + {{< note >}}Kalau kamu memilih instalasi minikube secara lokal, jalankan `minikube start`.{{< /note >}} 2. Buka dasbor Kubernetes di dalam browser: @@ -147,7 +147,7 @@ Supaya Kontainer `hello-node` bisa diakses dari luar jaringan virtual Kubernetes ``` Untuk penyedia cloud yang memiliki load balancer, sebuah alamat IP eksternal akan disediakan untuk mengakses Servis tersebut. - Pada Minikube, tipe `LoadBalancer` membuat Servis tersebut dapat diakses melalui perintah `minikube service`. + Pada minikube, tipe `LoadBalancer` membuat Servis tersebut dapat diakses melalui perintah `minikube service`. 3. Jalankan perintah berikut: @@ -163,7 +163,7 @@ Supaya Kontainer `hello-node` bisa diakses dari luar jaringan virtual Kubernetes ## Aktifkan addons -Minikube punya beberapa addons yang bisa diaktifkan, dinon-aktifkan, maupun dibuka di dalam environment Kubernetes lokal. +Perangkat minikube meliputi sekumpulan {{< glossary_tooltip text="addons" term_id="addons" >}} bawaan yang bisa diaktifkan, dinonaktifkan, maupun dibuka di dalam environment Kubernetes lokal. 1. Daftar addons yang ada saat ini: @@ -249,13 +249,13 @@ kubectl delete service hello-node kubectl delete deployment hello-node ``` -Kamu juga boleh mematikan mesin virtual (VM) untuk Minikube: +Kamu juga boleh mematikan mesin virtual atau _virtual machine_ (VM) untuk minikube: ```shell minikube stop ``` -Kamu juga boleh menghapus Minikube VM: +Kamu juga boleh menghapus minikube VM: ```shell minikube delete diff --git a/content/id/docs/tutorials/stateful-application/_index.md b/content/id/docs/tutorials/stateful-application/_index.md old mode 100755 new mode 100644 diff --git a/content/id/docs/tutorials/stateful-application/basic-stateful-set.md b/content/id/docs/tutorials/stateful-application/basic-stateful-set.md index 35c27666b4..0e15eceddb 100644 --- a/content/id/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/id/docs/tutorials/stateful-application/basic-stateful-set.md @@ -845,12 +845,12 @@ kubectl get pods -w -l app=nginx ``` Gunakan perintah [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) -untuk menghapus StatefulSet. Pastikan kamu menambahkan parameter `--cascade=false` ke +untuk menghapus StatefulSet. Pastikan kamu menambahkan parameter `--cascade=orphan` ke perintah tersebut. Parameter ini memberitahukan Kubernetes untuk hanya menghapus StatefulSet dan agar tidak menghapus Pod yang ada padanya. ```shell -kubectl delete statefulset web --cascade=false +kubectl delete statefulset web --cascade=orphan ``` ``` statefulset.apps "web" deleted @@ -965,7 +965,7 @@ kubectl get pods -w -l app=nginx ``` Pada terminal yang lain, hapus StatefulSet lagi. Kali ini, hilangkan parameter -`--cascade=false`. +`--cascade=orphan`. ```shell kubectl delete statefulset web diff --git a/content/id/examples/application/job/cronjob.yaml b/content/id/examples/application/job/cronjob.yaml index 2ce31233c3..34ab2a3f06 100644 --- a/content/id/examples/application/job/cronjob.yaml +++ b/content/id/examples/application/job/cronjob.yaml @@ -1,4 +1,4 @@ -apiVersion: batch/v1beta1 +apiVersion: batch/v1 kind: CronJob metadata: name: hello diff --git a/content/id/examples/controllers/daemonset.yaml b/content/id/examples/controllers/daemonset.yaml index 1bfa082833..375391826d 100644 --- a/content/id/examples/controllers/daemonset.yaml +++ b/content/id/examples/controllers/daemonset.yaml @@ -16,6 +16,7 @@ spec: spec: tolerations: - key: node-role.kubernetes.io/master + operator: Exists effect: NoSchedule containers: - name: fluentd-elasticsearch diff --git a/content/it/docs/concepts/architecture/_index.md b/content/it/docs/concepts/architecture/_index.md old mode 100755 new mode 100644 diff --git a/content/it/docs/concepts/architecture/nodes.md b/content/it/docs/concepts/architecture/nodes.md index 0494050420..c3c58be9d4 100644 --- a/content/it/docs/concepts/architecture/nodes.md +++ b/content/it/docs/concepts/architecture/nodes.md @@ -156,8 +156,9 @@ Condizione Notata quando un nodo diventa irraggiungibile (ad esempio, il control ricevere heartbeat per qualche motivo, ad es. a causa del fatto che il nodo si trova in basso), e poi in seguito sfratto tutti i pod dal nodo (usando una terminazione elegante) se il nodo continua essere irraggiungibile. (I timeout predefiniti sono 40 secondi per iniziare la segnalazione -ConditionUnknown e 5m dopo di ciò per iniziare a sfrattare i pod.) Il controller del nodo -controlla lo stato di ogni nodo ogni `--node-monitor-period` secondi. +ConditionUnknown e 5m dopo di ciò per iniziare a sfrattare i pod.) + +Il controller del nodo controlla lo stato di ogni nodo ogni `--node-monitor-period` secondi. Nelle versioni di Kubernetes precedenti alla 1.13, NodeStatus è l'heartbeat di nodo. A partire da Kubernetes 1.13, la funzionalità di lease del nodo viene introdotta come un @@ -191,8 +192,9 @@ lo stesso tempo. Se la frazione di nodi malsani è almeno se il cluster è piccolo (cioè ha meno o uguale a `--large-cluster-size-threshold` nodes - default 50) quindi gli sfratti sono fermato, altrimenti il ​​tasso di sfratto è ridotto a -`--secondary-node-eviction-rate` (default 0.01) al secondo. La ragione per cui -le politiche sono implementate per zona di disponibilità è perché una zona di disponibilità +`--secondary-node-eviction-rate` (default 0.01) al secondo. + +La ragione per cui le politiche sono implementate per zona di disponibilità è perché una zona di disponibilità potrebbe divenire partizionato dal master mentre gli altri rimangono connessi. Se il tuo cluster non si estende su più zone di disponibilità del provider cloud, quindi c'è solo una zona di disponibilità (l'intero cluster). diff --git a/content/it/docs/concepts/cluster-administration/_index.md b/content/it/docs/concepts/cluster-administration/_index.md old mode 100755 new mode 100644 diff --git a/content/it/docs/concepts/cluster-administration/addons.md b/content/it/docs/concepts/cluster-administration/addons.md index 3a91ff7b93..8bd3c154af 100644 --- a/content/it/docs/concepts/cluster-administration/addons.md +++ b/content/it/docs/concepts/cluster-administration/addons.md @@ -26,7 +26,7 @@ I componenti aggiuntivi in ogni sezione sono ordinati alfabeticamente - l'ordine * [Cilium](https://github.com/cilium/cilium) è un plug-in di criteri di rete e di rete L3 in grado di applicare in modo trasparente le politiche HTTP / API / L7. Sono supportate entrambe le modalità di routing e overlay / incapsulamento. * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) consente a Kubernetes di connettersi senza problemi a una scelta di plugin CNI, come Calico, Canal, Flannel, Romana o Weave. * [Contiv](http://contiv.github.io) offre networking configurabile (L3 nativo con BGP, overlay con vxlan, L2 classico e Cisco-SDN / ACI) per vari casi d'uso e un ricco framework di policy. Il progetto Contiv è completamente [open source](http://github.com/contiv). Il [programma di installazione](http://github.com/contiv/install) fornisce sia opzioni di installazione basate su kubeadm che non su Kubeadm. -* [Flanella](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) è un provider di reti sovrapposte che può essere utilizzato con Kubernetes. +* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) è un provider di reti sovrapposte che può essere utilizzato con Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) è una soluzione di rete che supporta più reti in Kubernetes. * [Multus](https://github.com/Intel-Corp/multus-cni) è un multi-plugin per il supporto di più reti in Kubernetes per supportare tutti i plugin CNI (es. Calico, Cilium, Contiv, Flannel), oltre a SRIOV, DPDK, OVS-DPDK e carichi di lavoro basati su VPP in Kubernetes. * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) fornisce l'integrazione tra VMware NSX-T e orchestratori di contenitori come Kubernetes, oltre all'integrazione tra NSX-T e piattaforme CaaS / PaaS basate su container come Pivotal Container Service (PKS) e OpenShift. diff --git a/content/it/docs/concepts/containers/_index.md b/content/it/docs/concepts/containers/_index.md old mode 100755 new mode 100644 diff --git a/content/it/docs/concepts/containers/images.md b/content/it/docs/concepts/containers/images.md new file mode 100644 index 0000000000..43fe439ee0 --- /dev/null +++ b/content/it/docs/concepts/containers/images.md @@ -0,0 +1,316 @@ +--- +title: Immagini +content_type: concept +weight: 10 +--- + + + +L'immagine di un container rappresenta dati binari che incapsulano un'applicazione e +tutte le sue dipendenze software. Le immagini sono costituite da pacchetti software +eseguibili che possono essere avviati in modalità standalone e su cui si possono fare +ipotesi ben precise circa l'ambiente in cui vengono eseguiti. + +Tipicamente viene creata un'immagine di un'applicazione ed effettuato il _push_ +su un registry (un repository pubblico di immagini) prima di poterne fare riferimento esplicito in un +{{< glossary_tooltip text="Pod" term_id="pod" >}} + +Questa pagina va a delineare nello specifico il concetto di immagine di un container. + + + +## I nomi delle immagini + +Alle immagini dei container vengono normalmente attribuiti nomi come `pause`, `example/mycontainer`, o `kube-apiserver`. +Le immagini possono anche contenere l'hostname del registry in cui le immagini sono pubblicate; +ad esempio: `registro.fittizio.esempio/nomeimmagine`, +ed è possibile che sia incluso nel nome anche il numero della porta; ad esempio: `registro.fittizio.esempio:10443/nomeimmagine`. + +Se non si specifica l'hostname di un registry, Kubernetes assume che ci si riferisca al registry pubblico di Docker. + +Dopo la parte relativa al nome dell'immagine si può aggiungere un _tag_ (come comunemente avviene per comandi come `docker` e `podman`). +I tag permettono l'identificazione di differenti versioni della stessa serie di immagini. + +I tag delle immagini sono composti da lettere minuscole e maiuscole, numeri, underscore (`_`), +punti (`.`), e trattini (`-`). +Esistono regole aggiuntive relative a dove i caratteri separatori (`_`, `-`, and `.`) +possano essere inseriti nel tag di un'immagine. +Se non si specifica un tag, Kubernetes assume il tag `latest` che va a definire l'immagine disponibile più recente. + +{{< caution >}} +Evitate di utilizzare il tag `latest` quando si rilasciano dei container in produzione, +in quanto risulta difficile tracciare quale versione dell'immagine sia stata avviata e persino più difficile +effettuare un rollback ad una versione precente. + +Invece, meglio specificare un tag specifico come ad esempio `v1.42.0`. +{{< /caution >}} + +## Aggiornamento delle immagini + +Quando un {{< glossary_tooltip text="Deployment" term_id="deployment" >}}, +{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}, Pod, o qualsiasi altro +oggetto che includa un Pod template viene creato per la prima volta, la policy di default per il pull di tutti i container nel Pod +è impostata su `IfNotPresent` (se non presente) se non specificato diversamente. +Questa policy permette al +{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} di evitare di fare il pull +di un'immagine se questa è già presente. + +Se necessario, si può forzare il pull in ogni occasione in uno dei seguenti modi: + +- impostando `imagePullPolicy` (specifica per il pull delle immagini) del container su `Always` (sempre). +- omettendo `imagePullPolicy` ed usando il tag `:latest` (più recente) per l'immagine da utilizzare; + Kubernetes imposterà la policy su `Always` (sempre). +- omettendo `imagePullPolicy` ed il tag per l'immagine da utilizzare. +- abilitando l'admission controller [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages). + +{{< note >}} +Il valore dell'impostazione `imagePullPolicy` del container è sempre presente quando l'oggetto viene creato per la prima volta +e non viene aggiornato se il tag dell'immagine dovesse cambiare successivamente. + +Ad esempio, creando un Deployment con un'immagine il cui tag _non_ è +`:latest`, e successivamente aggiornando il tag di quell'immagine a `:latest`, il campo + `imagePullPolicy` _non_ cambierà su `Always`. +È necessario modificare manualmente la policy di pull di ogni oggetto dopo la sua creazione. +{{< /note >}} + +Quando `imagePullPolicy` è definito senza un valore specifico, esso è impostato su `Always`. + +## Multi-architecture support nelle immagini + +Oltre a fornire immagini binarie, un _container registry_ può fornire un [indice delle immagini disponibili per un container](https://github.com/opencontainers/image-spec/blob/master/image-index.md). +L'indice di un'immagine può puntare a più [file manifest](https://github.com/opencontainers/image-spec/blob/master/manifest.md) ciascuno per una versione specifica dell'architettura di un container. +L'idea è che si può avere un unico nome per una stessa immagine (ad esempio: `pause`, `example/mycontainer`, `kube-apiserver`) e permettere a diversi sistemi di recuperare l'immagine binaria corretta a seconda dell'architettura della macchina che la sta utilizzando. + + +Kubernetes stesso tipicamente nomina le immagini dei container tramite il suffisso `-$(ARCH)`. +Per la garantire la retrocompatibilità è meglio generare le vecchie immagini con dei suffissi. +L'idea è quella di generare, ad esempio, l'immagine `pause` con un manifest che include tutte le architetture supportate, +affiancata, ad esempio, da `pause-amd64` che è retrocompatibile per le vecchie configurazioni o per quei file YAML +in cui sono specificate le immagini con i suffissi. + +## Utilizzare un private registry + +I private registry possono richiedere l'utilizzo di chiavi per accedere alle immagini in essi contenute. +Le credenziali possono essere fornite in molti modi: + - configurando i nodi in modo tale da autenticarsi al private registry + - tutti i pod possono acquisire informazioni da qualsiasi private registry configurato + - è necessario che l'amministratore del cluster configuri i nodi in tal senso + - tramite pre-pulled images (immagini pre-caricate sui nodi) + - tutti i pod possono accedere alle immagini salvate sulla cache del nodo a cui si riferiscono + - è necessario effettuare l'accesso come root di sistema su ogni nodo per inserire questa impostazione + - specificando _ImagePullSecrets_ su un determinato pod + - solo i pod che forniscono le proprie chiavi hanno la possibilità di accedere al private registry + - tramite estensioni locali o specifiche di un _Vendor_ + - se si sta utilizzando una configurazione personalizzata del nodo oppure se manualmente, o tramite il _cloud provider_, + si implementa un meccanismo di autenticazione del nodo presso il _container registry_. + +Di seguito la spiegazione dettagliata di queste opzioni. + +### Configurazione dei nodi per l'autenticazione ad un private registry + +Se si sta utilizzando Docker sui nodi, si può configurare il _Docker container runtime_ +per autenticare il nodo presso un private container registry. + +Questo è un approccio possibile se si ha il controllo sulle configurazioni del nodo. + +{{< note >}} +Kubernetes di default supporta solo le sezioni `auths` e `HttpHeaders` nelle configurazioni relative a Docker. +Eventuali _helper_ per le credenziali di Docker (`credHelpers` o `credsStore`) non sono supportati. +{{< /note >}} + + +Docker salva le chiavi per i registri privati in `$HOME/.dockercfg` oppure nel file `$HOME/.docker/config.json`. +Inserendo lo stesso file nella lista seguente, kubelet lo utilizzerà per recuperare le credenziali quando deve fare il _pull_ delle immagini. + +* `{--root-dir:-/var/lib/kubelet}/config.json` +* `{cwd of kubelet}/config.json` +* `${HOME}/.docker/config.json` +* `/.docker/config.json` +* `{--root-dir:-/var/lib/kubelet}/.dockercfg` +* `{cwd of kubelet}/.dockercfg` +* `${HOME}/.dockercfg` +* `/.dockercfg` + +{{< note >}} +Potrebbe essere necessario impostare `HOME=/root` esplicitamente come variabile d'ambiente del processo _kubelet_. +{{< /note >}} + +Di seguito i passi consigliati per configurare l'utilizzo di un private registry da parte dei nodi del _cluster_. +In questo esempio, eseguire i seguenti comandi sul proprio desktop/laptop: + + 1. Esegui `docker login [server]` per ogni _set_ di credenziali che vuoi utilizzare. Questo comando aggiornerà `$HOME/.docker/config.json` sul tuo PC. + 1. Controlla il file `$HOME/.docker/config.json` in un editor di testo per assicurarti che contenga le credenziali che tu voglia utilizzare. + 1. Recupera la lista dei tuoi nodi; ad esempio: + - se vuoi utilizzare i nomi: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )` + - se vuoi recuperare gli indirizzi IP: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )` + 1. Copia il tuo file locale `.docker/config.json` in uno dei path sopra riportati nella lista di ricerca. + - ad esempio, per testare il tutto: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done` + +{{< note >}} +Per i cluster di produzione, utilizza un configuration management tool per poter applicare le impostazioni su tutti i nodi laddove necessario. +{{< /note >}} + +Puoi fare una verifica creando un Pod che faccia uso di un'immagine privata; ad esempio: + +```shell +kubectl apply -f - <}} +Questo approccio è possibile se si ha il controllo sulla configurazione del nodo. +Non funzionerà qualora il cloud provider gestisca i nodi e li sostituisca automaticamente. +{{< /note >}} + +Kubelet di default prova a fare il pull di ogni immagine dal registry specificato. +Tuttavia, qualora la proprietà `imagePullPolicy` (specifica di pull dell'immagine) del container sia impostata su `IfNotPresent` (vale a dire, se non è già presente) oppure su `Never` (mai), +allora l'immagine locale è utilizzata (in via preferenziale o esclusiva, rispettivamente). + +Se si vuole fare affidamento a immagini pre-scaricate per non dover incorrere in una fase di autenticazione presso il registry, +bisogna assicurarsi che tutti i nodi nel cluster abbiano scaricato le stesse versioni delle immagini. + +Questa procedura può essere utilizzata per accelerare il processo di creazione delle istanze o come alternativa all'autenticazione presso un private registry. + +Tutti i pod avranno accesso in lettura a qualsiasi immagine pre-scaricata. + +### Specificare la proprietà imagePullSecrets su un Pod + +{{< note >}} +Questo approccio è quello consigliato per l'avvio di container a partire da immagini presenti in registri privati. +{{< /note >}} + +Kubernetes da la possibilità di specificare le chiavi del _container registry_ su un Pod. + +#### Creare un Secret tramite Docker config + +Esegui il comando seguente, sostituendo i valori riportati in maiuscolo con quelli corretti: + +```shell +kubectl create secret docker-registry --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL +``` + +Se possiedi il file delle credenziali per Docker, anziché utilizzare il comando quì sopra +puoi importare il file di credenziali come un Kubernetes +{{< glossary_tooltip text="Secrets" term_id="secret" >}}. +[Creare un Secret a partire da credenziali Docker](/docs/tasks/configure-pod-container/pull-image-private-registry/#registry-secret-existing-credentials) fornisce la spiegazione dettagliata su come fare. + +Ciò è particolarmente utile se si utilizzano più _container registry_ privati, +in quanto il comando `kubectl create secret docker-registry` genera un Secret che +funziona con un solo private registry. + +{{< note >}} +I Pod possono fare riferimento ai Secret per il pull delle immagini soltanto nel proprio _namespace_, +quindi questo procedimento deve essere svolto per ogni _namespace_. +{{< /note >}} + +#### Fare riferimento ad imagePullSecrets in un Pod + +È possibile creare pod che referenzino quel Secret aggiungendo la sezione `imagePullSecrets` alla definizione del Pod. + +Ad esempio: + +```shell +cat < pod.yaml +apiVersion: v1 +kind: Pod +metadata: + name: foo + namespace: awesomeapps +spec: + containers: + - name: foo + image: janedoe/awesomeapp:v1 + imagePullSecrets: + - name: myregistrykey +EOF + +cat <> ./kustomization.yaml +resources: +- pod.yaml +EOF +``` + +Questo deve esser fatto per ogni Pod che utilizzi un private registry. + +Comunque, le impostazioni relative a questo campo possono essere automatizzate inserendo la sezione _imagePullSecrets_ +nella definizione della risorsa [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/). + +Visitare la pagina [Aggiungere ImagePullSecrets ad un Service Account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) per istruzioni più dettagliate. + +Puoi utilizzarlo in congiunzione al file `.docker/config.json` configurato per ogni nodo. In questo caso, si applicherà un _merge_ delle credenziali. + +## Casi d'uso + +Ci sono varie soluzioni per configurare i private registry. Di seguito, alcuni casi d'uso comuni e le soluzioni suggerite. + +1. Cluster in cui sono utilizzate soltanto immagini non proprietarie (ovvero _open-source_). In questo caso non sussiste il bisogno di nascondere le immagini. + - Utilizza immagini pubbliche da Docker hub. + - Nessuna configurazione richiesta. + - Alcuni _cloud provider_ mettono in _cache_ o effettuano il _mirror_ di immagini pubbliche, il che migliora la disponibilità delle immagini e ne riduce il tempo di _pull_. +1. Cluster con container avviati a partire da immagini proprietarie che dovrebbero essere nascoste a chi è esterno all'organizzazione, ma + visibili a tutti gli utenti abilitati nel cluster. + - Utilizza un private [Docker registry](https://docs.docker.com/registry/). + - Esso può essere ospitato da [Docker Hub](https://hub.docker.com/signup), o da qualche altra piattaforma. + - Configura manualmente il file .docker/config.json su ogni nodo come descritto sopra. + - Oppure, avvia un private registry dietro il tuo firewall con accesso in lettura libero. + - Non è necessaria alcuna configurazione di Kubernetes. + - Utilizza un servizio di _container registry_ che controlli l'accesso alle immagini + - Esso funzionerà meglio con una configurazione del cluster basata su _autoscaling_ che con una configurazione manuale del nodo. + - Oppure, su un cluster dove la modifica delle configurazioni del nodo non è conveniente, utilizza `imagePullSecrets`. +1. Cluster con immagini proprietarie, alcune delle quali richiedono un controllo sugli accessi. + - Assicurati che l'_admission controller_ [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) sia attivo. Altrimenti, tutti i Pod potenzialmente possono avere accesso a tutte le immagini. + - Sposta i dati sensibili un un _Secret_, invece di inserirli in un'immagine. +1. Un cluster multi-tenant dove ogni tenant necessiti di un private registry. + - Assicurati che l'_admission controller_ [AlwaysPullImages](/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages) sia attivo. Altrimenti, tutti i Pod di tutti i tenant potrebbero potenzialmente avere accesso a tutte le immagini. + - Avvia un private registry che richieda un'autorizzazione all'accesso. + - Genera delle credenziali di registry per ogni tenant, inseriscile in dei _Secret_, e popola i _Secret_ per ogni _namespace_ relativo ad ognuno dei tenant. + - Il singolo tenant aggiunge così quel _Secret_ all'impostazione _imagePullSecrets_ di ogni _namespace_. + + +Se si ha la necessità di accedere a più registri, si può generare un _Secret_ per ognuno di essi. +Kubelet farà il _merge_ di ogni `imagePullSecrets` in un singolo file virtuale `.docker/config.json`. + +## {{% heading "whatsnext" %}} + +* Leggi [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md) \ No newline at end of file diff --git a/content/it/docs/concepts/overview/_index.md b/content/it/docs/concepts/overview/_index.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/cloud-controller-manager.md b/content/it/docs/reference/glossary/cloud-controller-manager.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/cluster.md b/content/it/docs/reference/glossary/cluster.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/container-runtime.md b/content/it/docs/reference/glossary/container-runtime.md index 640b3eaa17..4b6b5d1e53 100644 --- a/content/it/docs/reference/glossary/container-runtime.md +++ b/content/it/docs/reference/glossary/container-runtime.md @@ -2,7 +2,7 @@ title: Container Runtime id: container-runtime date: 2019-06-05 -full_link: /docs/reference/generated/container-runtime +full_link: /docs/setup/production-environment/container-runtimes short_description: > Il container runtime è il software che è responsabile per l'esecuzione dei container. diff --git a/content/it/docs/reference/glossary/container.md b/content/it/docs/reference/glossary/container.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/controller.md b/content/it/docs/reference/glossary/controller.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/daemonset.md b/content/it/docs/reference/glossary/daemonset.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/deployment.md b/content/it/docs/reference/glossary/deployment.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/docker.md b/content/it/docs/reference/glossary/docker.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/etcd.md b/content/it/docs/reference/glossary/etcd.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/job.md b/content/it/docs/reference/glossary/job.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/kube-apiserver.md b/content/it/docs/reference/glossary/kube-apiserver.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/kube-controller-manager.md b/content/it/docs/reference/glossary/kube-controller-manager.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/kube-proxy.md b/content/it/docs/reference/glossary/kube-proxy.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/kube-scheduler.md b/content/it/docs/reference/glossary/kube-scheduler.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/kubeadm.md b/content/it/docs/reference/glossary/kubeadm.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/kubelet.md b/content/it/docs/reference/glossary/kubelet.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/label.md b/content/it/docs/reference/glossary/label.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/node.md b/content/it/docs/reference/glossary/node.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/pod.md b/content/it/docs/reference/glossary/pod.md old mode 100755 new mode 100644 diff --git a/content/it/docs/reference/glossary/statefulset.md b/content/it/docs/reference/glossary/statefulset.md old mode 100755 new mode 100644 diff --git a/content/it/docs/tutorials/_index.md b/content/it/docs/tutorials/_index.md index 04069ff5eb..240fce078c 100644 --- a/content/it/docs/tutorials/_index.md +++ b/content/it/docs/tutorials/_index.md @@ -50,6 +50,8 @@ Prima di procedere con vari tutorial, raccomandiamo di aggiungere il * [AppArmor](/docs/tutorials/clusters/apparmor/) +* [seccomp](/docs/tutorials/clusters/seccomp/) + ## Servizi * [Utilizzare Source IP](/docs/tutorials/services/source-ip/) diff --git a/content/ja/docs/concepts/architecture/cloud-controller.md b/content/ja/docs/concepts/architecture/cloud-controller.md index cf86ec011b..a315616af3 100644 --- a/content/ja/docs/concepts/architecture/cloud-controller.md +++ b/content/ja/docs/concepts/architecture/cloud-controller.md @@ -20,7 +20,7 @@ cloud-controller-managerは、プラグイン機構を用い、異なるクラ ## 設計 -![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png) +![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.svg) クラウドコントローラーマネージャーは、複製されたプロセスの集合としてコントロールプレーンで実行されます。（通常、Pod内のコンテナとなります）各cloud-controller-managerは、シングルプロセスで複数の{{< glossary_tooltip text="controllers" term_id="controller" >}}を実装します。 @@ -182,7 +182,7 @@ rules: どのようにあなた自身のクラウドコントローラーマネージャーが実装されるのか、もしくは既存プロジェクトの拡張について知りたいですか？ -クラウドコントローラーマネージャーは、いかなるクラウドからもプラグインとしての実装を許可するためにGoインターフェースを使います。具体的には、[kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)の [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)で定義されている`CloudProvider`を使います。 +クラウドコントローラーマネージャーは、いかなるクラウドからもプラグインとしての実装を許可するためにGoインターフェースを使います。具体的には、[kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)の [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69)で定義されている`CloudProvider`を使います。 本ドキュメントでハイライトした共有コントローラー（Node、Route、Service）の実装と共有クラウドプロバイダーインターフェースに沿ったいくつかの足場は、Kubernetesコアの一部です。クラウドプロバイダに特化した実装は、Kubernetesのコアの外部として、また`CloudProvider`インターフェースを実装します。 diff --git a/content/ja/docs/concepts/architecture/controller.md b/content/ja/docs/concepts/architecture/controller.md index c2f71c9029..eaa0f4eb49 100644 --- a/content/ja/docs/concepts/architecture/controller.md +++ b/content/ja/docs/concepts/architecture/controller.md @@ -50,7 +50,11 @@ Jobとは対照的に、クラスターの外部に変更を加える必要が 外部の状態とやりとりをするコントローラーは、目的の状態をAPIサーバーから取得した後、外部のシステムと直接通信し、現在の状態を目的の状態に近づけます。 -(クラスター内のノードを水平にスケールさせるコントローラーが実際に存在します。詳しくは、[クラスターのオートスケーリング](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)を読んでください。) +(クラスター内のノードを水平にスケールさせる[コントローラー](https://github.com/kubernetes/autoscaler/)が実際に存在します。) + +ここで重要な点は、コントローラーが目的の状態を実現するために変更を加えてから、現在の状態をクラスターのAPIサーバーに報告することです。他の制御ループは、その報告されたデータを監視し、独自のアクションを実行できます。 + +サーモスタットの例では、部屋が非常に寒い場合、別のコントローラーが霜防止ヒーターをオンにすることもあります。Kubernetesクラスターを使用すると、コントロールプレーンは、[Kubernetesを拡張して](/ja/docs/concepts/extend-kubernetes/)実装することにより、IPアドレス管理ツールやストレージサービス、クラウドプロバイダーAPI、およびその他のサービスと間接的に連携します。 ## 目的の状態 vs 現在の状態 {#desired-vs-current} @@ -86,4 +90,3 @@ Kubernetesを拡張するためにコントロールプレーンの外で動作 * 基本的な[Kubernetesオブジェクト](/ja/docs/concepts/#kubernetes-objects)について学ぶ * [Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)について学ぶ * 自分でコントローラーを書きたい場合は、「Kubernetesを拡張する」の[エクステンションパターン](/ja/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)を読んでください。 - diff --git a/content/ja/docs/concepts/architecture/nodes.md b/content/ja/docs/concepts/architecture/nodes.md index 9c47531a37..bf5fa1acb9 100644 --- a/content/ja/docs/concepts/architecture/nodes.md +++ b/content/ja/docs/concepts/architecture/nodes.md @@ -275,4 +275,3 @@ kubeletはリソースの割当を決定する際にトポロジーのヒント * [Node APIオブジェクト](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)について読む。 * アーキテクチャ設計文書の[Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)という章を読む。 * [TaintとToleration](/ja/docs/concepts/scheduling-eviction/taint-and-toleration/)について読む。 -* [クラスターのオートスケール](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)について読む。 diff --git a/content/ja/docs/concepts/cluster-administration/_index.md b/content/ja/docs/concepts/cluster-administration/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/concepts/cluster-administration/addons.md b/content/ja/docs/concepts/cluster-administration/addons.md new file mode 100644 index 0000000000..c07cfce07c --- /dev/null +++ b/content/ja/docs/concepts/cluster-administration/addons.md @@ -0,0 +1,53 @@ +--- +title: アドオンのインストール +content_type: concept +--- + + + +{{% thirdparty-content %}} + +アドオンはKubernetesの機能を拡張するものです。 + +このページでは、利用可能なアドオンの一部の一覧と、それぞれのアドオンのインストール方法へのリンクを提供します。 + + + +## ネットワークとネットワークポリシー + +* [ACI](https://www.github.com/noironetworks/aci-containers)は、統合されたコンテナネットワークとネットワークセキュリティをCisco ACIを使用して提供します。 +* [Antrea](https://antrea.io/)は、L3またはL4で動作して、Open vSwitchをネットワークデータプレーンとして活用する、Kubernetes向けのネットワークとセキュリティサービスを提供します。 +* [Calico](https://docs.projectcalico.org/latest/introduction/)はネットワークとネットワークプリシーのプロバイダーです。Calicoは、BGPを使用または未使用の非オーバーレイおよびオーバーレイネットワークを含む、フレキシブルなさまざまなネットワークオプションをサポートします。Calicoはホスト、Pod、そして(IstioとEnvoyを使用している場合には)サービスメッシュ上のアプリケーションに対してネットワークポリシーを強制するために、同一のエンジンを使用します。 +* [Canal](https://github.com/tigera/canal/tree/master/k8s-install)はFlannelとCalicoをあわせたもので、ネットワークとネットワークポリシーを提供します。 +* [Cilium](https://github.com/cilium/cilium)は、L3のネットワークとネットワークポリシーのプラグインで、HTTP/API/L7のポリシーを透過的に強制できます。ルーティングとoverlay/encapsulationモードの両方をサポートしており、他のCNIプラグイン上で機能できます。 +* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)は、KubernetesをCalico、Canal、Flannel、Romana、Weaveなど選択したCNIプラグインをシームレスに接続できるようにするプラグインです。 +* [Contiv](https://contiv.github.io)は、さまざまなユースケースと豊富なポリシーフレームワーク向けに設定可能なネットワーク(BGPを使用したネイティブのL3、vxlanを使用したオーバーレイ、古典的なL2、Cisco-SDN/ACI)を提供します。Contivプロジェクトは完全に[オープンソース](https://github.com/contiv)です。[インストーラ](https://github.com/contiv/install)はkubeadmとkubeadm以外の両方をベースとしたインストールオプションがあります。 +* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)は、[Tungsten Fabric](https://tungsten.io)をベースにしている、オープンソースでマルチクラウドに対応したネットワーク仮想化およびポリシー管理プラットフォームです。ContrailおよびTungsten Fabricは、Kubernetes、OpenShift、OpenStack、Mesosなどのオーケストレーションシステムと統合されており、仮想マシン、コンテナ/Pod、ベアメタルのワークロードに隔離モードを提供します。 +* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)は、Kubernetesで使用できるオーバーレイネットワークプロバイダーです。 +* [Knitter](https://github.com/ZTE/Knitter/)は、1つのKubernetes Podで複数のネットワークインターフェイスをサポートするためのプラグインです。 +* [Multus](https://github.com/Intel-Corp/multus-cni)は、すべてのCNIプラグイン(たとえば、Calico、Cilium、Contiv、Flannel)に加えて、SRIOV、DPDK、OVS-DPDK、VPPをベースとするKubernetes上のワークロードをサポートする、複数のネットワークサポートのためのマルチプラグインです。 +* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)は、Open vSwitch(OVS)プロジェクトから生まれた仮想ネットワーク実装である[OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)をベースとする、Kubernetesのためのネットワークプロバイダです。OVN-Kubernetesは、OVSベースのロードバランサーおよびネットワークポリシーの実装を含む、Kubernetes向けのオーバーレイベースのネットワーク実装を提供します。 +* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin)は、クラウドネイティブベースのService function chaining(SFC)、Multiple OVNオーバーレイネットワーク、動的なサブネットの作成、動的な仮想ネットワークの作成、VLANプロバイダーネットワーク、Directプロバイダーネットワークを提供し、他のMulti-networkプラグインと付け替え可能なOVNベースのCNIコントローラープラグインです。 +* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in(NCP)は、VMware NSX-TとKubernetesなどのコンテナオーケストレーター間のインテグレーションを提供します。また、NSX-Tと、Pivotal Container Service(PKS)とOpenShiftなどのコンテナベースのCaaS/PaaSプラットフォームとのインテグレーションも提供します。 +* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst)は、Kubernetes Podと非Kubernetes環境間で可視化とセキュリティモニタリングを使用してポリシーベースのネットワークを提供するSDNプラットフォームです。 +* [Romana](https://romana.io)は、[NetworkPolicy API](/docs/concepts/services-networking/network-policies/)もサポートするPodネットワーク向けのL3のネットワークソリューションです。Kubeadmアドオンのインストールの詳細は[こちら](https://github.com/romana/romana/tree/master/containerize)で確認できます。 +* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/)は、ネットワークパーティションの両面で機能し、外部データベースを必要とせずに、ネットワークとネットワークポリシーを提供します。 + +## サービスディスカバリ + +* [CoreDNS](https://coredns.io)は、フレキシブルで拡張可能なDNSサーバーです。Pod向けのクラスター内DNSとして[インストール](https://github.com/coredns/deployment/tree/master/kubernetes)できます。 + +## 可視化と制御 + +* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard)はKubernetes向けのダッシュボードを提供するウェブインターフェイスです。 +* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s)は、コンテナ、Pod、Serviceなどをグラフィカルに可視化するツールです。[Weave Cloud account](https://cloud.weave.works/)と組み合わせて使うか、UIを自分でホストして使います。 + +## インフラストラクチャ + +* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation)は仮想マシンをKubernetes上で実行するためのアドオンです。通常、ベアメタルのクラスタで実行します。 + +## レガシーなアドオン + +いくつかのアドオンは、廃止された[cluster/addons](https://git.k8s.io/kubernetes/cluster/addons)ディレクトリに掲載されています。 + +よくメンテナンスされたアドオンはここにリンクしてください。PRを歓迎しています。 diff --git a/content/ja/docs/concepts/cluster-administration/cloud-providers.md b/content/ja/docs/concepts/cluster-administration/cloud-providers.md deleted file mode 100644 index f5fc0fe845..0000000000 --- a/content/ja/docs/concepts/cluster-administration/cloud-providers.md +++ /dev/null @@ -1,327 +0,0 @@ ---- -title: クラウドプロバイダー -content_type: concept -weight: 30 ---- - - -このページでは、特定のクラウドプロバイダーで実行されているKubernetesを管理する方法について説明します。 - - -### kubeadm -[kubeadm](/ja/docs/reference/setup-tools/kubeadm/kubeadm/)は、Kubernetesクラスターを作成する選択肢として人気があります。 -kubeadmには、クラウドプロバイダーの設定情報を指定する設定オプションがあります。 -例えば、典型的なインツリークラウドプロバイダーは、以下のようにkubeadmを使用して設定することができます。 - -```yaml -apiVersion: kubeadm.k8s.io/v1beta2 -kind: InitConfiguration -nodeRegistration: - kubeletExtraArgs: - cloud-provider: "openstack" - cloud-config: "/etc/kubernetes/cloud.conf" ---- -apiVersion: kubeadm.k8s.io/v1beta2 -kind: ClusterConfiguration -kubernetesVersion: v1.13.0 -apiServer: - extraArgs: - cloud-provider: "openstack" - cloud-config: "/etc/kubernetes/cloud.conf" - extraVolumes: - - name: cloud - hostPath: "/etc/kubernetes/cloud.conf" - mountPath: "/etc/kubernetes/cloud.conf" -controllerManager: - extraArgs: - cloud-provider: "openstack" - cloud-config: "/etc/kubernetes/cloud.conf" - extraVolumes: - - name: cloud - hostPath: "/etc/kubernetes/cloud.conf" - mountPath: "/etc/kubernetes/cloud.conf" -``` - -典型的なインツリークラウドプロバイダーは、通常、[kube-apiserver](/ja/docs/reference/command-line-tools-reference/kube-apiserver/)および[kube-controller-manager](ja//docs/reference/command-line-tools-reference/kube-controller-manager/)、[kubelet](/ja/docs/reference/command-line-tools-reference/kubelet/)のコマンドラインで指定される`--cloud-provider`と`--cloud-config`の両方が必要です。 -プロバイダーごとに`--cloud-config`で指定されるファイルの内容についても、以下に記載します。 - -すべての外部クラウドプロバイダーについては、以下の見出しに列挙されている個々のリポジトリーの案内に従ってください。または[すべてのリポジトリーのリスト](https://github.com/kubernetes?q=cloud-provider-&type=&language=)もご覧ください。 - -## AWS -ここでは、Amazon Web ServicesでKubernetesを実行する際に使用できるすべての設定について説明します。 - -この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-aws](https://github.com/kubernetes/cloud-provider-aws#readme)リポジトリーを参照してください。 - -### ノード名 - -AWSクラウドプロバイダーは、AWSインスタンスのプライベートDNS名をKubernetesのNodeオブジェクトの名前として使用します。 - -### ロードバランサー -以下のようにアノテーションを設定することで、[外部ロードバランサー](/ja/docs/tasks/access-application-cluster/create-external-load-balancer/)をAWS上で特定の機能を利用するように構成できます。 - -```yaml -apiVersion: v1 -kind: Service -metadata: - name: example - namespace: kube-system - labels: - run: example - annotations: - service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #replace this value - service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http -spec: - type: LoadBalancer - ports: - - port: 443 - targetPort: 5556 - protocol: TCP - selector: - app: example -``` -AWSのロードバランサーサービスには、_アノテーション_ を使ってさまざまな設定を適用することができます。以下では、AWS ELBでサポートされているアノテーションについて説明します。 - -* `service.beta.kubernetes.io/aws-load-balancer-access-log-emit-interval`: アクセスログの送信間隔を指定するために使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled`: アクセスログを有効または無効にするためにサービスで使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name`: アクセスログ用のs3バケット名を指定するために使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix`: アクセスログ用のs3バケットのプレフィックスを指定するために使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags`: ELBに追加タグとして記録されるキーとバリューのペアのコンマ区切りリストとして指定するためにサービスで使用します。例えば、`"Key1=Val1,Key2=Val2,KeyNoVal1=,KeyNoVal2"`のように指定できます。 -* `service.beta.kubernetes.io/aws-load-balancer-backend-protocol`: リスナーの背後にあるバックエンド(Pod)が使用するプロトコルを指定するためにサービスで使用します。`http`(デフォルト)または`https`を指定すると、接続を終端してヘッダーを解析するHTTPSリスナーが生成されます。`ssl`または`tcp`を指定すると、「生の」SSLリスナーが使われます。`http`を指定して`aws-load-balancer-ssl-cert`を使わない場合は、HTTPリスナーが使われます。 -* `service.beta.kubernetes.io/aws-load-balancer-ssl-cert`: セキュアなリスナーを要求するためにサービスで使用します。値は有効な証明書のARNです。詳細は、[ELBリスナーの設定](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html)を参照してください。CertARNは、IAMまたはCM証明書のARNで、例えば`arn:aws:acm:us-east-1:123456789012:certificate/12345678-1234-1234-1234-123456789012`のようになります。 -* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-enabled`: 接続ドレインを有効または無効にするためにサービスで使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-connection-draining-timeout`: 接続ドレインのタイムアウトを指定するためにサービスで使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout`: アイドル接続タイムアウトを指定するためにサービスで使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled`: クロスゾーン負荷分散を有効または無効にするためにサービスで使用されます。 -* `service.beta.kubernetes.io/aws-load-balancer-security-groups`: 作成されたELBに追加するセキュリティーグループを指定するために使用します。これは、以前にELBに割り当てられた他のすべてのセキュリティーグループを置き換えます。ここで定義されたセキュリティーグループは、サービス間で共有してはいけません。 -* `service.beta.kubernetes.io/aws-load-balancer-extra-security-groups`: 作成されたELBに加える追加のセキュリティーグループを指定するためにサービスで使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-internal`: 内部ELBが必要であることを示すためにサービスで使用します。 -* `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol`: ELB上でプロキシープロトコルを有効にするためにサービスで使用します。現在は、すべてのELBバックエンドでプロキシープロトコルを有効にすることを意味する`*`という値しか受け付けません。将来的には、特定のバックエンドでのみプロキシープロトコルを設定できるように調整できます。 -* `service.beta.kubernetes.io/aws-load-balancer-ssl-ports`: SSL/HTTPSリスナーを使用するポートのコンマ区切りリストを指定するためにサービスで使用します。デフォルトは`*`(すべて)です。 - -AWSのアノテーションの情報は、[aws.go](https://github.com/kubernetes/legacy-cloud-providers/blob/master/aws/aws.go)のコメントから引用しています。 - -## Azure - -この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-azure](https://github.com/kubernetes/cloud-provider-azure#readme)リポジトリーを参照してください。 - -### ノード名 - -Azureクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -Kubernetesノード名は、Azure VM名と一致しなければならないことに注意してください。 - -## CloudStack - -この外部クラウドプロバイダーを利用したい場合、[apache/cloudstack-kubernetes-provider](https://github.com/apache/cloudstack-kubernetes-provider)リポジトリーを参照してください。 - -### ノード名 - -CloudStackクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -Kubernetesノード名は、CloudStack VM名と一致しなければならないことに注意してください。 - -## GCE - -この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-gcp](https://github.com/kubernetes/cloud-provider-gcp#readme)リポジトリーを参照してください。 - -### ノード名 - -GCEクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -Kubernetesノード名の最初のセグメントは、GCEインスタンス名と一致しなければならないことに注意してください。例えば、`kubernetes-node-2.c.my-proj.internal`という名前のノードは、`kubernetes-node-2`という名前のインスタンスに対応していなければなりません。 - -## HUAWEI CLOUD - -この外部クラウドプロバイダーを利用したい場合、[kubernetes-sigs/cloud-provider-huaweicloud](https://github.com/kubernetes-sigs/cloud-provider-huaweicloud)リポジトリーを参照してください。 - -### ノード名 - -HUAWEI CLOUDプロバイダーは、ノードのプライベートIPアドレスをKubernetesノード名として使用します。 -ノードでkubeletを開始するときは、必ず`--hostname-override=`を指定してください。 - -## OpenStack -ここでは、OpenStackでKubernetesを実行する際に使用できるすべての設定について説明します。 - -この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-openstack](https://github.com/kubernetes/cloud-provider-openstack#readme)リポジトリーを参照してください。 - -### ノード名 - -OpenStackクラウドプロバイダーは、インスタンス名(OpenStackのメタデータで決定されたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -インスタンス名は必ず、Kubernetesノード名は、CloudStack VM名と一致しなければならないことに注意してください。 -kubeletがNodeオブジェクトを正常に登録できるように、インスタンス名は有効なKubernetesノード名である必要があります。 - -### サービス - -KubernetesのOpenStackクラウドプロバイダーの実装では、利用可能な場合、基盤となるクラウドからこれらのOpenStackのサービスの使用をサポートします。 - -| サービス名 | APIバージョン | 必須か | -|--------------------------|----------------|----------| -| Block Storage (Cinder) | V1†, V2, V3 | No | -| Compute (Nova) | V2 | No | -| Identity (Keystone) | V2‡, V3 | Yes | -| Load Balancing (Neutron) | V1§, V2 | No | -| Load Balancing (Octavia) | V2 | No | - -† Block Storage V1 APIのサポートは非推奨ですが、Kubernetes 1.9ではBlock Storage V3 APIのサポートが追加されました。 - -‡ Identity V2 APIのサポートは非推奨となり、将来のリリースでプロバイダーから削除される予定です。「Queens」のリリース時点で、OpenStackはIdentity V2 APIを公開しません。 - -§ Load Balancing V1 APIのサポートは、Kubernetes 1.9で削除されました。 - -サービスディスカバリーは、プロバイダー設定で提供される`auth-url`を使用して、OpenStack Identity(Keystone)が管理するサービスカタログを一覧表示することで実現されます。 -プロバイダーは、Keystone以外のOpenStackサービスが利用できなくなった場合には、機能を緩やかに低下させ、影響を受ける機能のサポートを放棄します。 -特定の機能は、基盤となるクラウドでNeutronが公開している拡張機能のリストに基づいて有効または無効にされます。 - -### cloud.conf -Kubernetesはcloud.confというファイルを介して、OpenStackとのやりとり方法を知っています。 -これは、KubernetesにOpenStack認証エンドポイントの認証情報と場所を提供するファイルです。 -ファイル内に以下の詳細を指定することで、cloud.confファイルを作成できます。 - -#### 典型的な設定 -以下の設定例は、最も頻繁に設定が必要な値に関するものです。 -プロバイダーをOpenStackクラウドのKeystoneエンドポイントに指定し、そのエンドポイントでの認証方法の詳細を提供し、さらにロードバランサーを設定します。 - -```yaml -[Global] -username=user -password=pass -auth-url=https:///identity/v3 -tenant-id=c869168a828847f39f7f06edd7305637 -domain-id=2a73b8f597c04551a0fdc8e95544be8a - -[LoadBalancer] -subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a -``` - -##### グローバル -これらのOpenStackプロバイダーの設定オプションは、グローバル設定に関連しており、`cloud.conf`ファイルの`[Global]`セクションに記述する必要があります。 - -* `auth-url`(必死): 認証に使用するKeystone APIのURLです。OpenStackのコントロールパネルでは、Access and Security > API Access > Credentialsで確認できます。 -* `username`(必須): Keystoneに設定されている有効なユーザーのユーザー名を参照します。 -* `password`(必須): Keystoneで設定された有効なユーザーのパスワードを参照します。 -* `tenant-id`(必須): リソースを作成するプロジェクトのIDを指定するために使用します。 -* `tenant-name`(任意): リソースを作成するプロジェクトの名前を指定します。 -* `trust-id`(任意): 認証に使用するtrustの識別子を指定するために使用します。trustは、ユーザー(委託者)が他のユーザー(受託者)に役割を委譲したり、受託者が委託者になりすますことを許可したりする権限を表します。利用可能なtrustは、Keystone APIの`/v3/OS-TRUST/trusts`エンドポイントの下にあります。 -* `domain-id`(任意): ユーザーが所属するドメインのIDを指定するために使用します。 -* `domain-name`(任意): ユーザーが所属するドメイン名を指定するために使用します。 -* `region`(任意): マルチリージョンのOpenStackクラウド上で実行する際に使うリージョンの識別子を指定するために使用します。リージョンはOpenStackデプロイメントの一般的な区分です。リージョンには厳密な地理的な意味合いはありませんが、デプロイメントでは`us-east`のような地理的な名前をリージョンの識別子に使うことができます。利用可能なリージョンはKeystone APIの`/v3/regions`エンドポイントの下にあります。 -* `ca-file`(任意): カスタムCAファイルのパスを指定するために使用します。 - - -テナントをプロジェクトに変更するKeystone V3を使用している場合、`tenant-id`の値は自動的にAPIのプロジェクト構造体にマッピングされます。 - -##### ロードバランサー -これらのOpenStackプロバイダーの設定オプションは、ロードバランサー設定に関連しており、`cloud.conf`ファイルの`[LoadBalancer]`セクションに記述する必要があります。 - -* `lb-version`(任意): 自動バージョン検出を上書きするために使用します。有効な値は`v1`または`v2`です。値が指定されていない場合、自動検出は基盤となるOpenStackクラウドが公開するサポートバージョンのうち、最も高いものを選択します。 -* `use-octavia`(任意): Octavia LBaaS V2サービスカタログエンドポイントを探して、利用するかどうかを決定するために使用します。有効な値は`true`または`false`です。`true`が指定され、Octaiva LBaaS V2エントリーが見つからなかった場合、プロバイダーはフォールバックして代わりにNeutron LBaaS V2エンドポイントを見つけようとします。デフォルト値は`false` です。 -* `subnet-id`(任意): ロードバランサーを作成したいサブネットのIDを指定します。Network > Networksにあります。サブネットを取得するには、それぞれのネットワークをクリックします。 -* `floating-network-id`(任意): 指定した場合、ロードバランサーのフローティングIPを作成します。 -* `lb-method`(任意): ロードバランサープールのメンバー間で負荷分散させるアルゴリズムを指定するために使用します。値には`ROUND_ROBIN`、`LEAST_CONNECTIONS`、`SOURCE_IP`を指定できます。何も指定しない場合のデフォルトの動作は`ROUND_ROBIN` です。 -* `lb-provider`(任意): ロードバランサーのプロバイダーを指定するために使用します。指定しない場合は、Neutronで設定されたデフォルトのプロバイダサービスが使用されます。 -* `create-monitor`(任意): Neutronロードバランサーのヘルスモニターを作成するかどうかを表します。有効な値は`true`と`false`で、デフォルト値は`false`です。`true`を指定した場合は、`monitor-delay`、`monitor-timeout`、`monitor-max-retries`も設定しなければなりません。 -* `monitor-delay`(任意): ロードバランサーのメンバーにプローブを送信するまでの時間です。有効な時間単位を指定してください。有効な時間単位は"ns"、"us"(または"μs")、"ms"、"s"、"m"、"h"です。 -* `monitor-timeout`(任意): モニタリングがタイムアウトする前にpingの応答を待つための最大の時間です。この値はdelay値よりも小さくする必要があります。有効な時間単位を指定してください。有効な時間単位は"ns"、"us"(または"μs")、"ms"、"s"、"m"、"h"です。 -* `monitor-max-retries`(任意): ロードバランサーメンバーのステータスをINACTIVEに変更する前に許容されるpingの失敗の数です。1から10の間の数値でなければなりません。 -* `manage-security-groups`(任意): ロードバランサーがセキュリティーグループのルールを自動的に管理するかどうかを決定します。有効な値は`true`と`false`で、デフォルト値は`false`です。`true`を指定した場合は、`node-security-group`も指定しなければなりません。 -* `node-security-group`(任意): 管理するセキュリティーグループのIDです。 - -##### ブロックストレージ -これらのOpenStackプロバイダーの設定オプションは、ブロックストレージ設定に関連しており、`cloud.conf`ファイルの`[BlockStorage]`セクションに記述する必要があります。 - -* `bs-version`(任意): 自動バージョン検出を上書きするために使用します。有効な値は`v1`、`v2`、`v3`、`auto`です。`auto`が指定された場合、自動検出は基盤となるOpenStackクラウドが公開するサポートバージョンのうち、最も高いものを選択します。何も指定しない場合のデフォルト値は`auto`です。 -* `trust-device-path`(任意): ほとんどのシナリオでは、Cinderが提供するブロックデバイス名(例: `/dev/vda`)は信頼できません。このブール値はこの動作をトグルします。`true`に設定すると、Cinderが提供するブロックデバイス名を信頼することになります。デフォルト値の`false`は、シリアル番号と`/dev/disk/by-id`のマッピングに基づいてデバイスのパスを検出します。 -* `ignore-volume-az`(任意): Cinderボリュームをアタッチする際のアベイラビリティーゾーンの使用に影響を与えます。NovaとCinderのアベイラビリティーゾーンが異なる場合は、`true`に設定する必要があります。これは、Novaのアベイラビリティーゾーンが多くあるにも関わらず、Cinderのアベイラビリティーゾーンが1つしかない場合によく見られます。デフォルト値は以前のリリースで使用されていた動作を維持するために`false`になっていますが、将来的には変更される可能性があります。 -* `node-volume-attach-limit`(任意): ノードにアタッチできるボリュームの最大数で、デフォルトはCinderの256です。 - -エンドポイントを区別するためにポートではなくパスを使用しているOpenStackデプロイメントにおいて、Kubernetesのバージョン1.8以下をデプロイする際、明示的に`bs-version`パラメーターの設定が必要な場合があります。パスベースのエンドポイントは`http://foo.bar/volume`の形式であり、ポートベースのエンドポイントは`http://foo.bar:xxx`の形式です。 - -パスベースのエンドポイントを使う環境で、Kubernetesが古い自動検出ロジックを使用している場合、ボリュームの切り離しを試みると`BS API version autodetection failed.`というエラーが返されます。この問題を回避するには、クラウドプロバイダー設定に以下のように追記することで、Cinder APIバージョン2を強制的に使用することができます。 - -```yaml -[BlockStorage] -bs-version=v2 -``` - -##### メタデータ -これらのOpenStackプロバイダーの設定オプションは、メタデータ設定に関連しており、`cloud.conf`ファイルの`[Metadata]`セクションに記述する必要があります。 - -* `search-order`(任意): この設定のキーは、プロバイダーが実行するインスタンスに関連するメタデータの取得方法に影響します。デフォルト値の`configDrive,metadataService`について、プロバイダーは、コンフィグドライブが利用可能な場合は最初にインスタンスに関連するメタデータをそこから取得し、次にメタデータサービスから取得します。代替値は以下の通りです。 - * `configDrive` - コンフィグドライブからのみ、インスタンスのメタデータを取得します。 - * `metadataService` - メタデータサービスからのみ、インスタンスのメタデータを取得します。 - * `metadataService,configDrive` - 最初にメタデータサービスからインスタンスのメタデータを取得し、次にコンフィグドライブから取得します。 - - コンフィグドライブ上のメタデータは時間の経過とともに陳腐化する可能性がありますが、メタデータサービスは常に最新の情報を提供するため、この動作を調整するのが望ましいです。しかし、すべてのOpenStackクラウドがコンフィグドライブとメタデータサービスの両方を提供しているわけではなく、どちらか一方しか利用できない場合もあるため、デフォルトでは両方をチェックするようになっています。 - -##### ルート -これらのOpenStackプロバイダーの設定オプションは、[kubenet](/ja/docs/concepts/cluster-administration/network-plugins/#kubenet)のKubernetesネットワークプラグインに関連しており、`cloud.conf`ファイルの`[Route]`セクションに記述する必要があります。 - - -* `router-id`(任意): 基盤となるクラウドのNeutronデプロイメントが`extraroutes`拡張機能をサポートしている場合は、`router-id`を使用してルートを追加するルーターを指定します。選択したルーターは、クラスターノードを含むプライベートネットワークにまたがっていなければなりません(通常、ノードネットワークは1つしかないので、この値はノードネットワークのデフォルトルーターになります)。この値は、OpenStackで[kubenet](/docs/concepts/cluster-administration/network-plugins/#kubenet)を使用するために必要です。 - -## OVirt - -### ノード名 - -OVirtクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -Kubernetesノード名は、VMのFQDN(`...`の下でOVirtによって報告されたもの)と一致しなければならないことに注意してください。 - -## Photon - -### ノード名 - -Photonクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -Kubernetesノード名はPhoton VM名と一致しなければならないことに注意してください(もしくは、`--cloud-config`で`overrideIP`がtrueに設定されている場合は、Kubernetesノード名はPhoton VMのIPアドレスと一致しなければなりません)。 - -## vSphere - -{{< tabs name="vSphere cloud provider" >}} -{{% tab name="vSphere 6.7U3以上" %}} -vSphere 6.7U3以上のすべてのvSphereデプロイメントでは、[external vSphere cloud provider](https://github.com/kubernetes/cloud-provider-vsphere)と[vSphere CSI driver](https://github.com/kubernetes-sigs/vsphere-csi-driver)の使用を推奨します。クイックスタートガイドについては、[Deploying a Kubernetes Cluster on vSphere with CSI and CPI](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/kubernetes-on-vsphere-with-kubeadm.html)を参照してください。 -{{% /tab %}} -{{% tab name="vSphere 6.7U3未満" %}} -vSphere 6.7U3未満を実行している場合は、インツリーのvSphereクラウドプロバイダーを推奨します。クイックスタートガイドについては、[Running a Kubernetes Cluster on vSphere with kubeadm](https://cloud-provider-vsphere.sigs.k8s.io/tutorials/k8s-vcp-on-vsphere-with-kubeadm.html)を参照してください。 -{{% /tab %}} -{{< /tabs >}} - -vSphereクラウドプロバイダーの詳細なドキュメントについては、[vSphereクラウドプロバイダーのドキュメントサイト](https://cloud-provider-vsphere.sigs.k8s.io)を参照してください。 - -## IBM Cloud Kubernetes Service - -### コンピュートノード -IBM Cloud Kubernetes Serviceプロバイダーを使用することで、仮想ノードと物理ノード(ベアメタル)を混在させたクラスターを単一のゾーン、またはリージョン内の複数のゾーンにまたがって作成することができます。詳細については、[Planning your cluster and worker node setup](https://cloud.ibm.com/docs/containers?topic=containers-planning_worker_nodes)を参照してください。 - -Kubernetes Nodeオブジェクトの名前は、IBM Cloud Kubernetes ServiceワーカーノードインスタンスのプライベートIPアドレスです。 - -### ネットワーク -IBM Cloud Kubernetes Serviceプロバイダーは、高品質なネットワークパフォーマンスとノードのネットワーク分離のためにVLANを提供します。カスタムファイアウォールやCalicoネットワークポリシーを設定して、クラスターにセキュリティーの追加レイヤーを加えたり、VPNを使用してクラスターをオンプレミスデータセンターに接続したりすることができます。詳細については、[Planning your cluster network setup](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters)を参照してください。 - -アプリケーションをパブリックまたはクラスター内で公開するには、NodePort、LoadBalancer、Ingressサービスを利用できます。また、Ingressアプリケーションのロードバランサーをアノテーションでカスタマイズすることもできます。詳細については、[Choosing an app exposure service](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning)を参照してください。 - -### ストレージ -IBM Cloud Kubernetes Serviceプロバイダーは、Kubernetesネイティブの永続ボリュームを活用して、ユーザーがファイル、ブロック、およびクラウドオブジェクトストレージをアプリケーションにマウントできるようにします。また、データの永続ストレージにDatabase as a Serviceやサードパーティーのアドオンを使用することもできます。詳しくは、[Planning highly available persistent storage](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning)を参照してください。 - -## Baidu Cloud Container Engine - -### ノード名 - -Baiduクラウドプロバイダーは、ノードのプライベートIPアドレス(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -Kubernetesノード名はBaidu VMのプライベートIPと一致しなければならないことに注意してください。 - -## Tencent Kubernetes Engine - -この外部クラウドプロバイダーを利用したい場合、[TencentCloud/tencentcloud-cloud-controller-manager](https://github.com/TencentCloud/tencentcloud-cloud-controller-manager)リポジトリーを参照してください。 - -### ノード名 - -Baiduクラウドプロバイダーは、ノードのホスト名(kubeletで決定されたもの、または`--hostname-override`で上書きされたもの)を、Kubernetes Nodeオブジェクトの名前として使用します。 -Kubernetesノード名はTencent VMのプライベートIPと一致しなければならないことに注意してください。 - -## Alibaba Cloud Kubernetes - -この外部クラウドプロバイダーを利用したい場合、[kubernetes/cloud-provider-alibaba-cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)リポジトリーを参照してください。 - -### ノード名 - -Alibaba Cloudではノード名の書式は必要ありませんが、kubeletでは`--provider-id=${REGION_ID}.${INSTANCE_ID}`を追加する必要があります。パラメーター`${REGION_ID}`はKubernetesのリージョンのIDを、`${INSTANCE_ID}`はAlibaba ECS(Elastic Compute Service)のIDを表します。 - -### ロードバランサー - -[アノテーション](https://www.alibabacloud.com/help/en/doc-detail/86531.htm)を設定することで、Alibaba Cloudの特定の機能を使用するように外部のロードバランサーを設定できます。 diff --git a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md index 5d85797649..89b3b28919 100644 --- a/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md +++ b/content/ja/docs/concepts/cluster-administration/cluster-administration-overview.md @@ -29,8 +29,6 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る ## クラスターの管理 -* [クラスターの管理](/docs/tasks/administer-cluster/cluster-management/)では、クラスターのライフサイクルに関するいくつかのトピックを紹介しています。例えば、新規クラスターの作成、クラスターのマスターやワーカーノードのアップグレード、ノードのメンテナンスの実施(例: カーネルのアップグレード)、稼働中のクラスターのKubernetes APIバージョンのアップグレードについてです。 - * [ノードの管理](/ja/docs/concepts/architecture/nodes/)方法について学んでください。 * 共有クラスターにおける[リソースクォータ](/docs/concepts/policy/resource-quotas/)のセットアップと管理方法について学んでください。 @@ -41,7 +39,7 @@ Kubernetesクラスターの計画、セットアップ、設定の例を知る * [Kubernetes コンテナの環境](/ja/docs/concepts/containers/container-environment/)では、Kubernetesノード上でのKubeletが管理するコンテナの環境について説明します。 -* [Kubernetes APIへのアクセス制御](/docs/reference/access-authn-authz/controlling-access/)では、ユーザーとサービスアカウントの権限の設定方法について説明します。 +* [Kubernetes APIへのアクセス制御](/docs/concepts/security/controlling-access)では、Kubernetesで自身のAPIに対するアクセスコントロールがどのように実装されているかを説明します。 * [認証](/docs/reference/access-authn-authz/authentication/)では、様々な認証オプションを含むKubernetesでの認証について説明します。 diff --git a/content/ja/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/ja/docs/concepts/cluster-administration/kubelet-garbage-collection.md new file mode 100644 index 0000000000..ffa08d63bd --- /dev/null +++ b/content/ja/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -0,0 +1,67 @@ +--- +title: コンテナイメージのガベージコレクション +content_type: concept +weight: 70 +--- + + + +ガベージコレクションは、未使用の[イメージ](/ja/docs/concepts/containers/#container-images)と未使用の[コンテナ](/ja/docs/concepts/containers/)をクリーンアップするkubeletの便利な機能です。kubeletコンテナのガベージコレクションを1分ごとに行い、イメージのガベージコレクションは5分ごとに行います。 + +存在することが期待されているコンテナを削除してkubeletの動作を壊す可能性があるため、外部のガベージコレクションのツールは推奨されません。 + + + +## イメージのガベージコレクション + +Kubernetesでは、すべてのイメージのライフサイクルの管理はcadvisorと協調してimageManager経由で行います。 + +イメージのガベージコレクションのポリシーについて考えるときは、`HighThresholdPercent`および`LowThresholdPercent`という2つの要因について考慮する必要があります。ディスク使用量がhigh thresholdを超えると、ガベージコレクションがトリガされます。ガベージコレクションは、low +thresholdが満たされるまで、最後に使われてから最も時間が経った(least recently used)イメージを削除します。 + +## コンテナのガベージコレクション + +コンテナのガベージコレクションのポリシーは、3つのユーザー定義の変数を考慮に入れます。`MinAge`は、ガベージコレクションできるコンテナの最小の年齢です。`MaxPerPodContainer`は、すべての単一のPod(UID、コンテナ名)が保持することを許されているdead状態のコンテナの最大値です。`MaxContainers`はdead状態のコンテナの合計の最大値です。これらの変数は、`MinAge`は0に、`MaxPerPodContainer`と`MaxContainers`は0未満にそれぞれ設定することで個別に無効にできます。 + +kubeletは、未指定のコンテナ、削除されたコンテナ、前述のフラグにより設定された境界の外にあるコンテナに対して動作します。一般に、最も古いコンテナが最初に削除されます。`MaxPerPodContainer`と`MaxContainer`は、Podごとの保持するコンテナの最大値(`MaxPerPodContainer`)がグローバルのdead状態のコンテナの許容範囲(`MaxContainers`)外である場合には、互いに競合する可能性があります。このような状況では、`MaxPerPodContainer`が調整されます。最悪のケースのシナリオでは、`MaxPerPodContainer`が1にダウングレードされ、最も古いコンテナが強制退去されます。さらに、`MinAge`より古くなると、削除済みのPodが所有するコンテナが削除されます。 + +kubeletによって管理されないコンテナは、コンテナのガベージコレクションの対象にはなりません。 + +## ユーザー設定 + +イメージのガベージコレクションを調整するために、以下のkubeletのフラグを使用して次のようなしきい値を調整できます。 + +1. `image-gc-high-threshold`: イメージのガベージコレクションをトリガするディスク使用量の割合(%)。デフォルトは85%。 +2. `image-gc-low-threshold`: イメージのガベージコレクションが解放を試みるディスク使用量の割合(%)。デフォルトは80%。 + +ガベージコレクションのポリシーは、以下のkubeletのフラグを使用してカスタマイズできます。 + +1. `minimum-container-ttl-duration`: 完了したコンテナがガベージコレクションされる前に経過するべき最小期間。デフォルトは0分です。つまり、すべての完了したコンテナはガベージコレクションされます。 +2. `maximum-dead-containers-per-container`: コンテナごとに保持される古いインスタンスの最大値です。デフォルトは1です。 +3. `maximum-dead-containers`: グローバルに保持するべき古いコンテナのインスタンスの最大値です。デフォルトは-1です。つまり、グローバルなリミットは存在しません。 + +コンテナは役に立たなくなる前にガベージコレクションされる可能性があります。こうしたコンテナには、トラブルシューティングに役立つログや他のデータが含まれるかもしれません。そのため、期待されるコンテナごとに最低でも1つのdead状態のコンテナが許容されるようにするために、`maximum-dead-containers-per-container`には十分大きな値を設定することが強く推奨されます。同様の理由で、`maximum-dead-containers`にも、より大きな値を設定することが推奨されます。詳しくは、[こちらのissue](https://github.com/kubernetes/kubernetes/issues/13287)を読んでください。 + +## 廃止 + +このドキュメントにあるkubeletの一部のガベージコレクションの機能は、将来kubelet evictionで置換される予定です。 + +これには以下のものが含まれます。 + +| 既存のフラグ | 新しいフラグ | 理由 | +| ------------- | -------- | --------- | +| `--image-gc-high-threshold` | `--eviction-hard`または`--eviction-soft` | 既存のevictionのシグナルがイメージのガベージコレクションをトリガする可能性がある | +| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaimが同等の動作を実現する | +| `--maximum-dead-containers` | | 古いログがコンテナのコンテキストの外部に保存されるようになったら廃止 | +| `--maximum-dead-containers-per-container` | | 古いログがコンテナのコンテキストの外部に保存されるようになったら廃止 | +| `--minimum-container-ttl-duration` | | 古いログがコンテナのコンテキストの外部に保存されるようになったら廃止 | +| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | evictionはディスクのしきい値を他のリソースに一般化している | +| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | evictionはディスクのpressure transitionを他のリソースに一般化している | + + + +## {{% heading "whatsnext" %}} + + +詳細については、[リソース不足のハンドリング方法を設定する](/docs/tasks/administer-cluster/out-of-resource/)を参照してください。 + diff --git a/content/ja/docs/concepts/cluster-administration/networking.md b/content/ja/docs/concepts/cluster-administration/networking.md index b81c51f437..b94c9f6d15 100644 --- a/content/ja/docs/concepts/cluster-administration/networking.md +++ b/content/ja/docs/concepts/cluster-administration/networking.md @@ -39,7 +39,7 @@ Kubernetesは、ネットワークの実装に次の基本的な要件を課し このモデルは全体としてそれほど複雑ではないことに加え、KubernetesがVMからコンテナへのアプリへの移植を簡単にするという要望と基本的に互換性があります。ジョブがVMで実行されていた頃も、VMにはIPがあってプロジェクト内の他のVMと通信できました。これは同じ基本モデルです。 -KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内のコンテナは、IPアドレスを含むネットワーク名前空間を共有します。これは、`Pod`内のコンテナがすべて`localhost`上の互いのポートに到達できることを意味します。また、`Pod`内のコンテナがポートの使用を調整する必要があることも意味しますが、これもVM内のプロセスと同じです。これのことを「IP-per-pod(Pod毎のIP)」モデルと呼びます。 +KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内のコンテナは、IPアドレスとMACアドレスを含むネットワーク名前空間を共有します。これは、`Pod`内のコンテナがすべて`localhost`上の互いのポートに到達できることを意味します。また、`Pod`内のコンテナがポートの使用を調整する必要があることも意味しますが、これもVM内のプロセスと同じです。これのことを「IP-per-pod(Pod毎のIP)」モデルと呼びます。 この実装方法は実際に使われているコンテナランタイムの詳細部分です。 @@ -51,6 +51,8 @@ KubernetesのIPアドレスは`Pod`スコープに存在します。`Pod`内の この一覧はアルファベット順にソートされており、順序は優先ステータスを意味するものではありません。 +{{% thirdparty-content %}} + ### ACI [Cisco Application Centric Infrastructure](https://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html) offers an integrated overlay and underlay SDN solution that supports containers, virtual machines, and bare metal servers. @@ -99,6 +101,10 @@ With the help of the Big Cloud Fabric's virtual pod multi-tenant architecture, c BCF was recognized by Gartner as a visionary in the latest [Magic Quadrant](https://go.bigswitch.com/17GatedDocuments-MagicQuadrantforDataCenterNetworking_Reg.html). One of the BCF Kubernetes on-premises deployments (which includes Kubernetes, DC/OS & VMware running on multiple DCs across different geographic regions) is also referenced [here](https://portworx.com/architects-corner-kubernetes-satya-komala-nio/). +### Calico + +[Calico](https://docs.projectcalico.org/)は、コンテナ、仮想マシン、ホストベースのワークロードのためのオープンソースのネットワーク及びネットワークセキュリティのソリューションです。Calicoは、純粋なLinuxのeBPFデータプレーンや、Linuxの標準的なネットワークデータプレーン、WindowsのHNSデータプレーンを含む、複数のデータプレーンをサポートしています。Calicoは完全なネットワークスタックを提供していますが、[クラウドプロバイダーのCNI](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations)と組み合わせてネットワークポリシーを提供することもできます。 + ### Cilium [Cilium](https://github.com/cilium/cilium) is open source software for @@ -129,6 +135,11 @@ tables to provide per-instance subnets to each host (which is limited to 50-100 entries per VPC). In short, cni-ipvlan-vpc-k8s significantly reduces the network complexity required to deploy Kubernetes at scale within AWS. +### Coil + +[Coil](https://github.com/cybozu-go/coil)は、容易に連携できるよう設計されていて、フレキシブルなEgressネットワークを提供することができるCNIプラグインです。 +Coilはベアメタルと比較して低いオーバーヘッドで操作することができ、また外部のネットワークへの任意のEgress NATゲートウェイを定義することができます。 + ### Contiv [Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](https://contiv.io) is all open sourced. @@ -266,14 +277,6 @@ stateful ACLs, load-balancers etc to build different virtual networking topologies. The project has a specific Kubernetes plugin and documentation at [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes). -### Project Calico - -[Project Calico](https://docs.projectcalico.org/) is an open source container networking provider and network policy engine. - -Calico provides a highly scalable networking and network policy solution for connecting Kubernetes pods based on the same IP networking principles as the internet, for both Linux (open source) and Windows (proprietary - available from [Tigera](https://www.tigera.io/essentials/)). Calico can be deployed without encapsulation or overlays to provide high-performance, high-scale data center networking. Calico also provides fine-grained, intent based network security policy for Kubernetes pods via its distributed firewall. - -Calico can also be run in policy enforcement mode in conjunction with other networking solutions such as Flannel, aka [canal](https://github.com/tigera/canal), or native GCE, AWS or Azure networking. - ### Romana [Romana](https://romana.io) is an open source network and security automation solution that lets you deploy Kubernetes without an overlay network. Romana supports Kubernetes [Network Policy](/docs/concepts/services-networking/network-policies/) to provide isolation across network namespaces. @@ -287,9 +290,7 @@ or stand-alone. In either version, it doesn't require any configuration or extr to run, and in both cases, the network provides one IP address per pod - as is standard for Kubernetes. - ## {{% heading "whatsnext" %}} ネットワークモデルの初期設計とその根拠、および将来の計画については、[ネットワーク設計ドキュメント](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)で詳細に説明されています。 - diff --git a/content/ja/docs/concepts/cluster-administration/system-logs.md b/content/ja/docs/concepts/cluster-administration/system-logs.md new file mode 100644 index 0000000000..cae76d7e34 --- /dev/null +++ b/content/ja/docs/concepts/cluster-administration/system-logs.md @@ -0,0 +1,126 @@ +--- +title: システムログ +content_type: concept +weight: 60 +--- + + + +システムコンポーネントのログは、クラスター内で起こったイベントを記録します。このログはデバッグのために非常に役立ちます。ログのverbosityを設定すると、ログをどの程度詳細に見るのかを変更できます。ログはコンポーネント内のエラーを表示する程度の荒い粒度にすることも、イベントのステップバイステップのトレース(HTTPのアクセスログ、Podの状態の変更、コントローラーの動作、スケジューラーの決定など)を表示するような細かい粒度に設定することもできます。 + + + +## klog + +klogは、Kubernetesのログライブラリです。[klog](https://github.com/kubernetes/klog)は、Kubernetesのシステムコンポーネント向けのログメッセージを生成します。 + +klogの設定に関する詳しい情報については、[コマンドラインツールのリファレンス](/docs/reference/command-line-tools-reference/)を参照してください。 + +klogネイティブ形式の例: + +``` +I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756] +``` + +### 構造化ログ + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +{{< warning >}} +構造化ログへのマイグレーションは現在進行中の作業です。このバージョンでは、すべてのログメッセージが構造化されているわけではありません。ログファイルをパースする場合、JSONではないログの行にも対処しなければなりません。 + +ログの形式と値のシリアライズは変更される可能性があります。 +{{< /warning>}} + +構造化ログは、ログメッセージに単一の構造を導入し、プログラムで情報の抽出ができるようにするものです。構造化ログは、僅かな労力とコストで保存・処理できます。新しいメッセージ形式は後方互換性があり、デフォルトで有効化されます。 + +構造化ログの形式: + +```ini + "" ="" ="" ... +``` + +例: + +```ini +I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready" +``` + + +### JSONログ形式 + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +{{}} +JSONの出力は多数の標準のklogフラグをサポートしていません。非対応のklogフラグの一覧については、[コマンドラインツールリファレンス](/docs/reference/command-line-tools-reference/)を参照してください。 + +すべてのログがJSON形式で書き込むことに対応しているわけではありません(たとえば、プロセスの開始時など)。ログのパースを行おうとしている場合、JSONではないログの行に対処できるようにしてください。 + +フィールド名とJSONのシリアライズは変更される可能性があります。 +{{< /warning >}} + +`--logging-format=json`フラグは、ログの形式をネイティブ形式klogからJSON形式に変更します。以下は、JSONログ形式の例(pretty printしたもの)です。 + +```json +{ + "ts": 1580306777.04728, + "v": 4, + "msg": "Pod status updated", + "pod":{ + "name": "nginx-1", + "namespace": "default" + }, + "status": "ready" +} +``` + +特別な意味を持つキー: +* `ts` - Unix時間のタイムスタンプ(必須、float) +* `v` - verbosity (必須、int、デフォルトは0) +* `err` - エラー文字列 (オプション、string) +* `msg` - メッセージ (必須、string) + +現在サポートされているJSONフォーマットの一覧: +* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} +* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} +* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} + +### ログのサニタイズ + +{{< feature-state for_k8s_version="v1.20" state="alpha" >}} + +{{}} +ログのサニタイズ大きな計算のオーバーヘッドを引き起こす可能性があるため、本番環境では有効にするべきではありません。 +{{< /warning >}} + +`--experimental-logging-sanitization`フラグはklogのサニタイズフィルタを有効にします。有効にすると、すべてのログの引数が機密データ(パスワード、キー、トークンなど)としてタグ付けされたフィールドについて検査され、これらのフィールドのログの記録は防止されます。 + +現在ログのサニタイズをサポートしているコンポーネント一覧: +* kube-controller-manager +* kube-apiserver +* kube-scheduler +* kubelet + +{{< note >}} +ログのサニタイズフィルターは、ユーザーのワークロードのログが機密データを漏洩するのを防げるわけではありません。 +{{< /note >}} + +### ログのverbosityレベル + +`-v`フラグはログのverbosityを制御します。値を増やすとログに記録されるイベントの数が増えます。値を減らすとログに記録されるイベントの数が減ります。verbosityの設定を増やすと、ますます多くの深刻度の低いイベントをログに記録するようになります。verbosityの設定を0にすると、クリティカルなイベントだけをログに記録します。 + +### ログの場所 + +システムコンポーネントには2種類あります。コンテナ内で実行されるコンポーネントと、コンテナ内で実行されないコンポーネントです。たとえば、次のようなコンポーネントがあります。 + +* Kubernetesのスケジューラーやkube-proxyはコンテナ内で実行されます。 +* kubeletやDockerのようなコンテナランタイムはコンテナ内で実行されません。 + +systemdを使用しているマシンでは、kubeletとコンテナランタイムはjournaldに書き込みを行います。それ以外のマシンでは、`/var/log`ディレクトリ内の`.log`ファイルに書き込みます。コンテナ内部のシステムコンポーネントは、デフォルトのログ機構をバイパスするため、常に`/var/log`ディレクトリ内の`.log`ファイルに書き込みます。コンテナのログと同様に、`/var/log`ディレクトリ内のシステムコンポーネントのログはローテートする必要があります。`kube-up.sh`スクリプトによって作成されたKubernetesクラスターでは、ログローテーションは`logrotate`ツールで設定されます。`logrotate`ツールはログを1日ごとまたはログのサイズが100MBを超えたときにローテートします。 + +## {{% heading "whatsnext" %}} + +* [Kubernetesのログのアーキテクチャ](/docs/concepts/cluster-administration/logging/)について読む。 +* [構造化ログ](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging)について読む。 +* [ログの深刻度の慣習](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md)について読む。 diff --git a/content/ja/docs/concepts/configuration/_index.md b/content/ja/docs/concepts/configuration/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/concepts/configuration/configmap.md b/content/ja/docs/concepts/configuration/configmap.md index 54147a7a90..32799c9e9d 100644 --- a/content/ja/docs/concepts/configuration/configmap.md +++ b/content/ja/docs/concepts/configuration/configmap.md @@ -22,12 +22,18 @@ ConfigMapは機密性や暗号化を提供しません。保存したいデー こうすることで、必要であればクラウド上で実行しているコンテナイメージを取得することで、ローカルでも完全に同じコードを使ってデバッグができるようになります。 +ConfigMapは、大量のデータを保持するようには設計されていません。ConfigMapに保存されるデータは1MiBを超えることはできません。この制限を超える設定を保存する必要がある場合は、ボリュームのマウントを検討するか、別のデータベースまたはファイルサービスを使用することを検討してください。 + ## ConfigMapオブジェクト -ConfigMapは、他のオブジェクトが使うための設定を保存できるAPI[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)です。ほとんどのKubernetesオブジェクトに`spec`セクションがあるのとは違い、ConfigMapにはアイテム(キー)と値を保存するための`data`セクションがあります。 +ConfigMapは、他のオブジェクトが使うための設定を保存できるAPI[オブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)です。ほとんどのKubernetesオブジェクトに`spec`セクションがあるのとは違い、ConfigMapには`data`および`binaryData`フィールドがあります。これらのフィールドは、キーとバリューのペアを値として受け入れます。`data`フィールドと`binaryData`フィールドはどちらもオプションです。`data`フィールドはUTF-8バイトシーケンスを含むように設計されていますが、`binaryData`フィールドはバイナリデータを含むように設計されています。 ConfigMapの名前は、有効な[DNSのサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)でなければなりません。 +`data`または`binaryData`フィールドの各キーは、英数字、`-`、`_`、または`.`で構成されている必要があります。`data`に格納されているキーは、`binaryData`フィールドのキーと重複することはできません。 + +v1.19以降、ConfigMapの定義に`immutable`フィールドを追加して、[イミュータブルなConfigMap](#configmap-immutable)を作成できます。 + ## ConfigMapとPod ConfigMapを参照して、ConfigMap内のデータを元にしてPod内のコンテナの設定をするPodの`spec`を書くことができます。このとき、PodとConfigMapは同じ{{< glossary_tooltip text="名前空間" term_id="namespace" >}}内に存在する必要があります。 @@ -43,7 +49,7 @@ data: # プロパティーに似たキー。各キーは単純な値にマッピングされている player_initial_lives: "3" ui_properties_file_name: "user-interface.properties" - # + # ファイルに似たキー game.properties: | enemy.types=aliens,monsters @@ -56,7 +62,7 @@ data: ConfigMapを利用してPod内のコンテナを設定する方法には、次の4種類があります。 -1. コマンドライン引数をコンテナのエントリーポイントに渡す +1. コンテナ内のコマンドと引数 1. 環境変数をコンテナに渡す 1. 読み取り専用のボリューム内にファイルを追加し、アプリケーションがそのファイルを読み取る 1. Kubernetes APIを使用してConfigMapを読み込むコードを書き、そのコードをPod内で実行する @@ -75,7 +81,8 @@ metadata: spec: containers: - name: demo - image: game.example/demo-game + image: alpine + command: ["sleep", "3600"] env: # 環境変数を定義します。 - name: PLAYER_INITIAL_LIVES # ここではConfigMap内のキーの名前とは違い @@ -117,11 +124,9 @@ ConfigMapは1行のプロパティの値と複数行のファイルに似た形 ConfigMapは、データボリュームとしてマウントできます。ConfigMapは、Podへ直接公開せずにシステムの他の部品として使うこともできます。たとえば、ConfigMapには、システムの他の一部が設定のために使用するデータを保存できます。 -{{< note >}} ConfigMapの最も一般的な使い方では、同じ名前空間にあるPod内で実行されているコンテナに設定を構成します。ConfigMapを独立して使用することもできます。 たとえば、ConfigMapに基づいて動作を調整する{{< glossary_tooltip text="アドオン" term_id="addons" >}}や{{< glossary_tooltip text="オペレーター" term_id="operator-pattern" >}}を見かけることがあるかもしれません。 -{{< /note >}} ### ConfigMapをPodからファイルとして使う @@ -161,14 +166,17 @@ Pod内に複数のコンテナが存在する場合、各コンテナにそれ ボリューム内で現在使用中のConfigMapが更新されると、射影されたキーも最終的に(eventually)更新されます。kubeletは定期的な同期のたびにマウントされたConfigMapが新しいかどうか確認します。しかし、kubeletが現在のConfigMapの値を取得するときにはローカルキャッシュを使用します。キャッシュの種類は、[KubeletConfiguration構造体](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)の中の`ConfigMapAndSecretChangeDetectionStrategy`フィールドで設定可能です。ConfigMapは、監視(デフォルト)、ttlベース、またはすべてのリクエストを直接APIサーバーへ単純にリダイレクトする方法のいずれかによって伝搬されます。その結果、ConfigMapが更新された瞬間から、新しいキーがPodに射影されるまでの遅延の合計は、最長でkubeletの同期期間+キャッシュの伝搬遅延になります。ここで、キャッシュの伝搬遅延は選択したキャッシュの種類に依存します(監視の伝搬遅延、キャッシュのttl、または0に等しくなります)。 -{{< feature-state for_k8s_version="v1.18" state="alpha" >}} +環境変数として使用されるConfigMapは自動的に更新されないため、ポッドを再起動する必要があります。 +## イミュータブルなConfigMap {#configmap-immutable} -Kubernetesのアルファ版の機能である _イミュータブルなSecretおよびConfigMap_ は、個別のSecretやConfigMapをイミュータブルに設定するオプションを提供します。ConfigMapを広範に使用している(少なくとも数万のConfigMapがPodにマウントされている)クラスターでは、データの変更を防ぐことにより、以下のような利点が得られます。 +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + +Kubernetesのベータ版の機能である _イミュータブルなSecretおよびConfigMap_ は、個別のSecretやConfigMapをイミュータブルに設定するオプションを提供します。ConfigMapを広範に使用している(少なくとも数万のConfigMapがPodにマウントされている)クラスターでは、データの変更を防ぐことにより、以下のような利点が得られます。 - アプリケーションの停止を引き起こす可能性のある予想外の(または望まない)変更を防ぐことができる - ConfigMapをイミュータブルにマークして監視を停止することにより、kube-apiserverへの負荷を大幅に削減し、クラスターの性能が向上する -この機能を使用するには、`ImmutableEmphemeralVolumes`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、SecretやConfigMapの`immutable`フィールドを`true`に設定してください。次に例を示します。 +この機能は、`ImmutableEmphemeralVolumes`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)によって管理されます。`immutable`フィールドを`true`に設定することで、イミュータブルなConfigMapを作成できます。次に例を示します。 ```yaml apiVersion: v1 @@ -180,9 +188,7 @@ data: immutable: true ``` -{{< note >}} -一度ConfigMapやSecretがイミュータブルに設定すると、この変更を元に戻したり、`data`フィールドのコンテンツを変更することは*できません*。既存のPodは削除されたConfigMapのマウントポイントを保持するため、こうしたPodは再作成することをおすすめします。 -{{< /note >}} +一度ConfigMapがイミュータブルに設定されると、この変更を元に戻したり、`data`または`binaryData`フィールドのコンテンツを変更することは*できません*。ConfigMapの削除と再作成のみ可能です。既存のPodは削除されたConfigMapのマウントポイントを保持するため、こうしたPodは再作成することをおすすめします。 ## {{% heading "whatsnext" %}} diff --git a/content/ja/docs/concepts/configuration/manage-resources-containers.md b/content/ja/docs/concepts/configuration/manage-resources-containers.md index 761999d937..0d59ecd319 100644 --- a/content/ja/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ja/docs/concepts/configuration/manage-resources-containers.md @@ -29,6 +29,10 @@ Podが動作しているNodeに利用可能なリソースが十分にある場 制限は、違反が検出されるとシステムが介入するように事後的に、またはコンテナーが制限を超えないようにシステムが防ぐように強制的に、実装できます。 異なるランタイムは、同じ制限を実装するために異なる方法をとることができます。 +{{< note >}} +コンテナが自身のメモリー制限を指定しているが、メモリー要求を指定していない場合、Kubernetesは制限に一致するメモリー要求を自動的に割り当てます。同様に、コンテナが自身のCPU制限を指定しているが、CPU要求を指定していない場合、Kubernetesは制限に一致するCPU要求を自動的に割り当てます。 +{{< /note >}} + ## リソースタイプ *CPU*と*メモリー*はいずれも*リソースタイプ*です。リソースタイプには基本単位があります。 @@ -106,7 +110,6 @@ spec: containers: - name: app image: images.my-company.example/app:v4 - env: resources: requests: memory: "64Mi" @@ -234,7 +237,7 @@ kubeletは、`tmpfs`のemptyDirボリュームをローカルのエフェメラ ### ローカルのエフェメラルストレージの要求と制限設定 -ローカルのエフェメラルストレージを管理するためには_ephemeral-storage_パラメーターを利用することができます。 +ローカルのエフェメラルストレージを管理するためには _ephemeral-storage_ パラメーターを利用することができます。 Podの各コンテナは、次の1つ以上を指定できます。 * `spec.containers[].resources.limits.ephemeral-storage` * `spec.containers[].resources.requests.ephemeral-storage` diff --git a/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md new file mode 100644 index 0000000000..b3ed117931 --- /dev/null +++ b/content/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -0,0 +1,114 @@ +--- +title: kubeconfigファイルを使用してクラスターアクセスを組織する +content_type: concept +weight: 60 +--- + + + +kubeconfigを使用すると、クラスターに、ユーザー、名前空間、認証の仕組みに関する情報を組織できます。`kubectl`コマンドラインツールはkubeconfigファイルを使用してクラスターを選択するために必要な情報を見つけ、クラスターのAPIサーバーと通信します。 + +{{< note >}} +クラスターへのアクセスを設定するために使われるファイルは*kubeconfigファイル*と呼ばれます。これは設定ファイルを指すために使われる一般的な方法です。`kubeconfig`という名前を持つファイルが存在するという意味ではありません。 +{{< /note >}} + +デフォルトでは、`kubectl`は`$HOME/.kube`ディレクトリ内にある`config`という名前のファイルを探します。`KUBECONFIG`環境変数を設定するか、[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/)フラグで指定することで、別のkubeconfigファイルを指定することもできます。 + +kubeconfigファイルの作成と指定に関するステップバイステップの手順を知りたいときは、[複数のクラスターへのアクセスを設定する](/docs/tasks/access-application-cluster/configure-access-multiple-clusters)を参照してください。 + + + +## 複数のクラスター、ユーザ、認証の仕組みのサポート + +複数のクラスターを持っていて、ユーザーやコンポーネントがさまざまな方法で認証を行う次のような状況を考えてみます。 + +- 実行中のkubeletが証明書を使用して認証を行う可能性がある。 +- ユーザーがトークンを使用して認証を行う可能性がある。 +- 管理者が個別のユーザに提供する複数の証明書を持っている可能性がある。 + +kubeconfigファイルを使用すると、クラスター、ユーザー、名前空間を組織化することができます。また、contextを定義することで、複数のクラスターや名前空間を素早く簡単に切り替えられます。 + +## Context + +kubeconfigファイルの*context*要素は、アクセスパラメーターを使いやすい名前でグループ化するために使われます。各contextは3つのパラメータ、cluster、namespace、userを持ちます。デフォルトでは、`kubectl`コマンドラインツールはクラスターとの通信に*current context*のパラメーターを使用します。 + +current contextを選択するには、以下のコマンドを使用します。 + +``` +kubectl config use-context +``` + +## KUBECONFIG環境変数 + +`KUBECONFIG`環境変数には、kubeconfigファイルのリストを指定できます。LinuxとMacでは、リストはコロン区切りです。Windowsでは、セミコロン区切りです。`KUBECONFIG`環境変数は必須ではありません。`KUBECONFIG`環境変数が存在しない場合は、`kubectl`はデフォルトのkubeconfigファイルである`$HOME/.kube/config`を使用します。 + +`KUBECONFIG`環境変数が存在する場合は、`kubectl`は`KUBECONFIG`環境変数にリストされているファイルをマージした結果を有効な設定として使用します。 + +## kubeconfigファイルのマージ + +設定ファイルを確認するには、以下のコマンドを実行します。 + +```shell +kubectl config view +``` + +上で説明したように、出力は1つのkubeconfigファイルから作られる場合も、複数のkubeconfigファイルをマージした結果となる場合もあります。 + +`kubectl`がkubeconfigファイルをマージするときに使用するルールを以下に示します。 + +1. もし`--kubeconfig`フラグが設定されていた場合、指定したファイルだけが使用されます。マージは行いません。このフラグに指定できるのは1つのファイルだけです。 + + そうでない場合、`KUBECONFIG`環境変数が設定されていた場合には、それをマージするべきファイルのリストとして使用します。`KUBECONFIG`環境変数にリストされたファイルのマージは、次のようなルールに従って行われます。 + + * 空のファイルを無視する。 + * デシリアライズできない内容のファイルに対してエラーを出す。 + * 特定の値やmapのキーを設定する最初のファイルが勝つ。 + * 値やmapのキーは決して変更しない。 + 例: 最初のファイルが指定した`current-context`を保持する。 + 例: 2つのファイルが`red-user`を指定した場合、1つ目のファイルの`red-user`だけを使用する。もし2つ目のファイルの`red-user`以下に競合しないエントリーがあったとしても、それらは破棄する。 + + `KUBECONFIG`環境変数を設定する例については、[KUBECONFIG環境変数を設定する](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)を参照してください。 + + それ以外の場合は、デフォルトのkubeconfigファイル`$HOME/.kube/config`をマージせずに使用します。 + +1. 以下のチェーンで最初に見つかったものをもとにして、使用するcontextを決定する。 + + 1. `--context`コマンドラインフラグが存在すれば、それを使用する。 + 1. マージしたkubeconrfigファイルから`current-context`を使用する。 + + この時点では、空のcontextも許容されます。 + +1. クラスターとユーザーを決定する。この時点では、contextである場合もそうでない場合もあります。以下のチェーンで最初に見つかったものをもとにして、クラスターとユーザーを決定します。この手順はユーザーとクラスターについてそれぞれ1回ずつ、合わせて2回実行されます。 + + 1. もし存在すれば、コマンドラインフラグ`--user`または`--cluster`を使用する。 + 1. もしcontextが空でなければ、contextからユーザーまたはクラスターを取得する。 + + この時点では、ユーザーとクラスターは空である可能性があります。 + +1. 使用する実際のクラスター情報を決定する。この時点では、クラスター情報は存在しない可能性があります。以下のチェーンで最初に見つかったものをもとにして、クラスター情報の各パーツをそれぞれを構築します。 + + 1. もし存在すれば、`--server`、`--certificate-authority`、`--insecure-skip-tls-verify`コマンドラインフラグを使用する。 + 1. もしマージしたkubeconfigファイルにクラスター情報の属性が存在すれば、それを使用する。 + 1. もしサーバーの場所が存在しなければ、マージは失敗する。 + +1. 使用する実際のユーザー情報を決定する。クラスター情報の場合と同じルールを使用して、ユーザー情報を構築します。ただし、ユーザーごとに許可される認証方法は1つだけです。 + + 1. もし存在すれば、`--client-certificate`、`--client-key`、`--username`、`--password`、`--token`コマンドラインフラグを使用する。 + 1. マージしたkubeconfigファイルの`user`フィールドを使用する。 + 1. もし2つの競合する方法が存在する場合、マージは失敗する。 + +1. もし何らかの情報がまだ不足していれば、デフォルトの値を使用し、認証情報については場合によってはプロンプトを表示する。 + +## ファイルリファレンス + +kubeconfigファイル内のファイルとパスのリファレンスは、kubeconfigファイルの位置からの相対パスで指定します。コマンドライン上のファイルのリファレンスは、現在のワーキングディレクトリからの相対パスです。`$HOME/.kube/config`内では、相対パスは相対のまま、絶対パスは絶対のまま保存されます。 + +## {{% heading "whatsnext" %}} + + +* [複数のクラスターへのアクセスを設定する](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) + + + + diff --git a/content/ja/docs/concepts/configuration/overview.md b/content/ja/docs/concepts/configuration/overview.md index 5f2fd15120..ee63e066d8 100644 --- a/content/ja/docs/concepts/configuration/overview.md +++ b/content/ja/docs/concepts/configuration/overview.md @@ -58,11 +58,11 @@ weight: 10 ## ラベルの使用 -- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの__セマンティック属性__を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。 +- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`のように、アプリケーションまたはデプロイメントの __セマンティック属性__ を識別する[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を定義して使いましょう。これらのラベルを使用して、他のリソースに適切なポッドを選択できます。例えば、すべての`tier：frontend`を持つPodを選択するServiceや、`app：myapp`に属するすべての`phase：test`コンポーネント、などです。このアプローチの例を知るには、[ゲストブック](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)アプリも合わせてご覧ください。 セレクターからリリース固有のラベルを省略することで、Serviceを複数のDeploymentにまたがるように作成できます。 [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)により、ダウンタイムなしで実行中のサービスを簡単に更新できます。 -オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が_適用_されると、Deploymentコントローラは制御された速度で実際の状態を望ましい状態に変更します。 +オブジェクトの望ましい状態はDeploymentによって記述され、その仕様への変更が _適用_ されると、Deploymentコントローラは制御された速度で実際の状態を望ましい状態に変更します。 - デバッグ用にラベルを操作できます。Kubernetesコントローラー（ReplicaSetなど）とServiceはセレクターラベルを使用してPodとマッチするため、Podから関連ラベルを削除すると、コントローラーによって考慮されたり、Serviceによってトラフィックを処理されたりすることがなくなります。既存のPodのラベルを削除すると、そのコントローラーはその代わりに新しいPodを作成します。これは、「隔離」環境で以前の「ライブ」Podをデバッグするのに便利な方法です。対話的にラベルを削除または追加するには、[`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label)を使います。 diff --git a/content/ja/docs/concepts/configuration/pod-priority-preemption.md b/content/ja/docs/concepts/configuration/pod-priority-preemption.md new file mode 100644 index 0000000000..c06b3b41b0 --- /dev/null +++ b/content/ja/docs/concepts/configuration/pod-priority-preemption.md @@ -0,0 +1,240 @@ +--- +title: Podの優先度とプリエンプション +content_type: concept +weight: 70 +--- + + + +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + +[Pod](/ja/docs/concepts/workloads/pods/)は _priority_（優先度）を持つことができます。 +優先度は他のPodに対する相対的なPodの重要度を示します。 +もしPodをスケジューリングできないときには、スケジューラーはそのPodをスケジューリングできるようにするため、優先度の低いPodをプリエンプトする（追い出す）ことを試みます。 + + + + + + +{{< warning >}} +クラスターの全てのユーザーが信用されていない場合、悪意のあるユーザーが可能な範囲で最も高い優先度のPodを作成することが可能です。これは他のPodが追い出されたりスケジューリングできない状態を招きます。 +管理者はResourceQuotaを使用して、ユーザーがPodを高い優先度で作成することを防ぐことができます。 + +詳細は[デフォルトで優先度クラスの消費を制限する](/ja/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) +を参照してください。 +{{< /warning >}} + +## 優先度とプリエンプションを使う方法 + +優先度とプリエンプションを使うには、 + +1. 1つまたは複数の[PriorityClass](#priorityclass)を追加します + +1. 追加したPriorityClassを[`priorityClassName`](#pod-priority)に設定したPodを作成します。 + もちろんPodを直接作る必要はありません。 + 一般的には`priorityClassName`をDeploymentのようなコレクションオブジェクトのPodテンプレートに追加します。 + +これらの手順のより詳しい情報については、この先を読み進めてください。 + +{{< note >}} +Kubernetesには最初から既に2つのPriorityClassが設定された状態になっています。 +`system-cluster-critical`と`system-node-critical`です。 +これらは汎用のクラスであり、[重要なコンポーネントが常に最初にスケジュールされることを保証する](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)ために使われます。 +{{< /note >}} + +## PriorityClass + +PriorityClassはnamespaceによらないオブジェクトで、優先度クラスの名称から優先度を表す整数値への対応を定義します。 +PriorityClassオブジェクトのメタデータの`name`フィールドにて名称を指定します。 +値は`value`フィールドで指定し、必須です。 +値が大きいほど、高い優先度を示します。 +PriorityClassオブジェクトの名称は[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)として適切であり、かつ`system-`から始まってはいけません。 + +PriorityClassオブジェクトは10億以下の任意の32ビットの整数値を持つことができます。 +それよりも大きな値は通常はプリエンプトや追い出すべきではない重要なシステム用のPodのために予約されています。 +クラスターの管理者は割り当てたい優先度に対して、PriorityClassオブジェクトを1つずつ作成すべきです。 + +PriorityClassは任意でフィールド`globalDefault`と`description`を設定可能です。 +`globalDefault`フィールドは`priorityClassName`が指定されないPodはこのPriorityClassを使うべきであることを示します。`globalDefault`がtrueに設定されたPriorityClassはシステムで一つのみ存在可能です。`globalDefault`が設定されたPriorityClassが存在しない場合は、`priorityClassName`が設定されていないPodの優先度は0に設定されます。 + +`description`フィールドは任意の文字列です。クラスターの利用者に対して、PriorityClassをどのような時に使うべきか示すことを意図しています。 + +### PodPriorityと既存のクラスターに関する注意 + +- もし既存のクラスターをこの機能がない状態でアップグレードすると、既存のPodの優先度は実質的に0になります。 + +- `globalDefault`が`true`に設定されたPriorityClassを追加しても、既存のPodの優先度は変わりません。PriorityClassのそのような値は、PriorityClassが追加された以後に作成されたPodのみに適用されます。 + +- PriorityClassを削除した場合、削除されたPriorityClassの名前を使用する既存のPodは変更されませんが、削除されたPriorityClassの名前を使うPodをそれ以上作成することはできなくなります。 + +### PriorityClassの例 + +```yaml +apiVersion: scheduling.k8s.io/v1 +kind: PriorityClass +metadata: + name: high-priority +value: 1000000 +globalDefault: false +description: "この優先度クラスはXYZサービスのPodに対してのみ使用すべきです。" +``` + +## 非プリエンプトのPriorityClass {#non-preempting-priority-class} + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + +`PreemptionPolicy: Never`と設定されたPodは、スケジューリングのキューにおいて他の優先度の低いPodよりも優先されますが、他のPodをプリエンプトすることはありません。 +スケジューリングされるのを待つ非プリエンプトのPodは、リソースが十分に利用可能になるまでスケジューリングキューに残ります。 +非プリエンプトのPodは、他のPodと同様に、スケジューラーのバックオフの対象になります。これは、スケジューラーがPodをスケジューリングしようと試みたものの失敗した場合、低い頻度で再試行するようにして、より優先度の低いPodが先にスケジューリングされることを許します。 + +非プリエンプトのPodは、他の優先度の高いPodにプリエンプトされる可能性はあります。 + +`PreemptionPolicy`はデフォルトでは`PreemptLowerPriority`に設定されており、これが設定されているPodは優先度の低いPodをプリエンプトすることを許容します。これは既存のデフォルトの挙動です。 +`PreemptionPolicy`を`Never`に設定すると、これが設定されたPodはプリエンプトを行わないようになります。 + +ユースケースの例として、データサイエンスの処理を挙げます。 +ユーザーは他の処理よりも優先度を高くしたいジョブを追加できますが、そのとき既存の実行中のPodの処理結果をプリエンプトによって破棄させたくはありません。 +`PreemptionPolicy: Never`が設定された優先度の高いジョブは、他の既にキューイングされたPodよりも先に、クラスターのリソースが「自然に」開放されたときにスケジューリングされます。 + +### 非プリエンプトのPriorityClassの例 + +```yaml +apiVersion: scheduling.k8s.io/v1 +kind: PriorityClass +metadata: + name: high-priority-nonpreempting +value: 1000000 +preemptionPolicy: Never +globalDefault: false +description: "この優先度クラスは他のPodをプリエンプトさせません。" +``` + +## Podの優先度 {#pod-priority} + +一つ以上のPriorityClassがあれば、仕様にPriorityClassを指定したPodを作成することができるようになります。優先度のアドミッションコントローラーは`priorityClassName`フィールドを使用し、優先度の整数値を設定します。PriorityClassが見つからない場合、そのPodの作成は拒否されます。 + +下記のYAMLは上記の例で作成したPriorityClassを使用するPodの設定の例を示します。優先度のアドミッションコントローラーは仕様を確認し、このPodの優先度は1000000であると設定します。 + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + env: test +spec: + containers: + - name: nginx + image: nginx + imagePullPolicy: IfNotPresent + priorityClassName: high-priority +``` + +### スケジューリング順序におけるPodの優先度の効果 + +Podの優先度が有効な場合、スケジューラーは待機状態のPodをそれらの優先度順に並べ、スケジューリングキューにおいてより優先度の低いPodよりも前に来るようにします。その結果、その条件を満たしたときには優先度の高いPodは優先度の低いPodより早くスケジューリングされます。優先度の高いPodがスケジューリングできない場合は、スケジューラーは他の優先度の低いPodのスケジューリングも試みます。 + +## プリエンプション + +Podが作成されると、スケジューリング待ちのキューに入り待機状態になります。スケジューラーはキューからPodを取り出し、ノードへのスケジューリングを試みます。Podに指定された条件を全て満たすノードが見つからない場合は、待機状態のPodのためにプリエンプションロジックが発動します。待機状態のPodをPと呼ぶことにしましょう。プリエンプションロジックはPよりも優先度の低いPodを一つ以上追い出せばPをスケジューリングできるようになるノードを探します。そのようなノードがあれば、優先度の低いPodはノードから追い出されます。Podが追い出された後に、Pはノードへスケジューリング可能になります。 + +### ユーザーへ開示される情報 + +Pod PがノードNのPodをプリエンプトした場合、ノードNの名称がPのステータスの`nominatedNodeName`フィールドに設定されます。このフィールドはスケジューラーがPod Pのために予約しているリソースの追跡を助け、ユーザーにクラスターにおけるプリエンプトに関する情報を与えます。 + +Pod Pは必ずしも「指名したノード」へスケジューリングされないことに注意してください。Podがプリエンプトされると、そのPodは終了までの猶予期間を得ます。スケジューラーがPodの終了を待つ間に他のノードが利用可能になると、スケジューラーは他のノードをPod Pのスケジューリング先にします。この結果、Podの`nominatedNodeName`と`nodeName`は必ずしも一致しません。また、スケジューラーがノードNのPodをプリエンプトさせた後に、Pod Pよりも優先度の高いPodが来た場合、スケジューラーはノードNをその新しい優先度の高いPodへ与えます。このような場合は、スケジューラーはPod Pの`nominatedNodeName`を消去します。これによって、スケジューラーはPod Pが他のノードのPodをプリエンプトさせられるようにします。 + +### プリエンプトの制限 + +#### プリエンプトされるPodの正常終了 + +Podがプリエンプトされると、[猶予期間](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)が与えられます。 + +Podは作業を完了し、終了するために十分な時間が与えられます。仮にそうでない場合、強制終了されます。この猶予期間によって、スケジューラーがPodをプリエンプトした時刻と、待機状態のPod Pがノード Nにスケジュール可能になるまでの時刻の間に間が開きます。この間、スケジューラーは他の待機状態のPodをスケジュールしようと試みます。プリエンプトされたPodが終了したら、スケジューラーは待ち行列にあるPodをスケジューリングしようと試みます。そのため、Podがプリエンプトされる時刻と、Pがスケジュールされた時刻には間が開くことが一般的です。この間を最小にするには、優先度の低いPodの猶予期間を0または小さい値にする方法があります。 + +#### PodDisruptionBudgetは対応するが、保証されない + +[PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) (PDB)は、アプリケーションのオーナーが冗長化されたアプリケーションのPodが意図的に中断される数の上限を設定できるようにするものです。KubernetesはPodをプリエンプトする際にPDBに対応しますが、PDBはベストエフォートで考慮します。スケジューラーはプリエンプトさせたとしてもPDBに違反しないPodを探します。そのようなPodが見つからない場合でもプリエンプションは実行され、PDBに反しますが優先度の低いPodが追い出されます。 + +#### 優先度の低いPodにおけるPod間のアフィニティ + +次の条件が真の場合のみ、ノードはプリエンプションの候補に入ります。 +「待機状態のPodよりも優先度の低いPodをノードから全て追い出したら、待機状態のPodをノードへスケジュールできるか」 + +{{< note >}} +プリエンプションは必ずしも優先度の低いPodを全て追い出しません。 +優先度の低いPodを全て追い出さなくても待機状態のPodがスケジューリングできる場合、一部のPodのみ追い出されます。 +このような場合であったとしても、上記の条件は真である必要があります。偽であれば、そのノードはプリエンプションの対象とはされません。 +{{< /note >}} + +待機状態のPodが、優先度の低いPodとの間でPod間のアフィニティを持つ場合、Pod間のアフィニティはそれらの優先度の低いPodがなければ満たされません。この場合、スケジューラーはノードのどのPodもプリエンプトしようとはせず、代わりに他のノードを探します。スケジューラーは適切なノードを探せる場合と探せない場合があります。この場合、待機状態のPodがスケジューリングされる保証はありません。 + +この問題に対して推奨される解決策は、優先度が同一または高いPodに対してのみPod間のアフィニティを作成することです。 + +#### 複数ノードに対するプリエンプション + +Pod PがノードNにスケジューリングできるよう、ノードNがプリエンプションの対象となったとします。 +他のノードのPodがプリエンプトされた場合のみPが実行可能になることもあります。下記に例を示します。 + +* Pod PをノードNに配置することを検討します。 +* Pod QはノードNと同じゾーンにある別のノードで実行中です。 +* Pod Pはゾーンに対するQへのアンチアフィニティを持ちます (`topologyKey: topology.kubernetes.io/zone`)。 +* Pod Pと、ゾーン内の他のPodに対しては他のアンチアフィニティはない状態です。 +* Pod PをノードNへスケジューリングするには、Pod Qをプリエンプトすることが考えられますが、スケジューラーは複数ノードにわたるプリエンプションは行いません。そのため、Pod PはノードNへはスケジューリングできないとみなされます。 + +Pod Qがそのノードから追い出されると、Podアンチアフィニティに違反しなくなるので、Pod PはノードNへスケジューリング可能になります。 + +複数ノードに対するプリエンプションに関しては、十分な需要があり、合理的な性能を持つアルゴリズムを見つけられた場合に、追加することを検討する可能性があります。 + +## トラブルシューティング + +Podの優先度とプリエンプションは望まない副作用をもたらす可能性があります。 +いくつかの起こりうる問題と、その対策について示します。 + +### Podが不必要にプリエンプトされる + +プリエンプションは、リソースが不足している場合に優先度の高い待機状態のPodのためにクラスターの既存のPodを追い出します。 +誤って高い優先度をPodに割り当てると、意図しない高い優先度のPodはクラスター内でプリエンプションを引き起こす可能性があります。Podの優先度はPodの仕様の`priorityClassName`フィールドにて指定されます。優先度を示す整数値へと変換された後、`podSpec`の`priority`へ設定されます。 + +この問題に対処するには、Podの`priorityClassName`をより低い優先度に変更するか、このフィールドを未設定にすることができます。`priorityClassName`が未設定の場合、デフォルトでは優先度は0とされます。 + +Podがプリエンプトされたとき、プリエンプトされたPodのイベントが記録されます。 +プリエンプションはPodに必要なリソースがクラスターにない場合のみ起こるべきです。 +このような場合、プリエンプションはプリエンプトされるPodよりも待機状態のPodの優先度が高い場合のみ発生します。 +プリエンプションは待機状態のPodがない場合や待機状態のPodがプリエンプト対象のPod以下の優先度を持つ場合には決して発生しません。そのような状況でプリエンプションが発生した場合、問題を報告してください。 + +### Podはプリエンプトされたが、プリエンプトさせたPodがスケジューリングされない + +Podがプリエンプトされると、それらのPodが要求した猶予期間が与えられます。そのデフォルトは30秒です。 +Podがその期間内に終了しない場合、強制終了されます。プリエンプトされたPodがなくなれば、プリエンプトさせたPodはスケジューリング可能です。 + +プリエンプトさせたPodがプリエンプトされたPodの終了を待っている間に、より優先度の高いPodが同じノードに対して作成されることもあります。この場合、スケジューラーはプリエンプトさせたPodの代わりに優先度の高いPodをスケジューリングします。 + +これは予期された挙動です。優先度の高いPodは優先度の低いPodに取って代わります。 + +### 優先度の高いPodが優先度の低いPodより先にプリエンプトされる + +スケジューラーは待機状態のPodが実行可能なノードを探します。ノードが見つからない場合、スケジューラーは任意のノードから優先度の低いPodを追い出し、待機状態のPodのためのリソースを確保しようとします。 +仮に優先度の低いPodが動いているノードが待機状態のPodを動かすために適切ではない場合、スケジューラーは他のノードで動いているPodと比べると、優先度の高いPodが動いているノードをプリエンプションの対象に選ぶことがあります。この場合もプリエンプトされるPodはプリエンプトを起こしたPodよりも優先度が低い必要があります。 + +複数のノードがプリエンプションの対象にできる場合、スケジューラーは優先度が最も低いPodのあるノードを選ぼうとします。しかし、そのようなPodがPodDisruptionBudgetを持っており、プリエンプトするとPDBに反する場合はスケジューラーは優先度の高いPodのあるノードを選ぶこともあります。 + +複数のノードがプリエンプションの対象として利用可能で、上記の状況に当てはまらない場合、スケジューラーは優先度の最も低いノードを選択します。 + +## Podの優先度とQoSの相互作用 {#interactions-of-pod-priority-and-qos} + +Podの優先度と{{< glossary_tooltip text="QoSクラス" term_id="qos-class" >}}は直交する機能で、わずかに相互作用がありますが、デフォルトではQoSクラスによる優先度の設定の制約はありません。スケジューラーのプリエンプションのロジックはプリエンプションの対象を決めるときにQoSクラスは考慮しません。 +プリエンプションはPodの優先度を考慮し、優先度が最も低いものを候補とします。より優先度の高いPodは優先度の低いPodを追い出すだけではプリエンプトを起こしたPodのスケジューリングに不十分な場合と、`PodDisruptionBudget`により優先度の低いPodが保護されている場合のみ対象になります。 + +QoSとPodの優先度の両方を考慮するコンポーネントは[リソース不足によりkubeletがPodを追い出す](/docs/tasks/administer-cluster/out-of-resource/)のみです。 +kubeletは追い出すPodの順位付けを次の順で行います。枯渇したリソースを要求以上に使用しているか、優先度、枯渇したリソースの消費量の複数のPodの要求に対する相対値。 +詳細は[エンドユーザーのPodの追い出し](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)を参照してください。 + + +kubeletによるリソース不足時のPodの追い出しでは、リソースの消費が要求を超えないPodは追い出されません。優先度の低いPodのリソースの利用量がその要求を超えていなければ、追い出されることはありません。より優先度が高く、要求を超えてリソースを使用しているPodが追い出されます。 + + +## {{% heading "whatsnext" %}} + +* PriorityClassと関連付けてResourceQuotaを使用することに関して [デフォルトで優先度クラスの消費を制限する](/ja/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) diff --git a/content/ja/docs/concepts/configuration/secret.md b/content/ja/docs/concepts/configuration/secret.md index 9ae7c55067..f2a71e1860 100644 --- a/content/ja/docs/concepts/configuration/secret.md +++ b/content/ja/docs/concepts/configuration/secret.md @@ -1,5 +1,5 @@ --- -title: Secrets +title: Secret content_type: concept feature: title: Secretと構成管理 @@ -11,18 +11,18 @@ weight: 30 KubernetesのSecretはパスワード、OAuthトークン、SSHキーのような機密情報を保存し、管理できるようにします。 -Secretに機密情報を保存することは、それらを{{< glossary_tooltip text="Pod" term_id="pod" >}}の定義や{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載するより、安全で柔軟です。詳しくは[Secretの設計文書](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)を参照してください。 +Secretに機密情報を保存することは、それらを{{< glossary_tooltip text="Pod" term_id="pod" >}}の定義や{{< glossary_tooltip text="コンテナイメージ" term_id="image" >}}に直接記載するより、安全で柔軟です。 +詳しくは[Secretの設計文書](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)を参照してください。 +Secretはパスワード、トークン、キーのような小容量の機密データを含むオブジェクトです。 +他の方法としては、そのような情報はPodの定義やイメージに含めることができます。 +ユーザーはSecretを作ることができ、またシステムが作るSecretもあります。 ## Secretの概要 -Secretはパスワード、トークン、キーのような小容量の機密データを含むオブジェクトです。 -他の方法としては、そのような情報はPodの定義やイメージに含めることができます。 -ユーザーはSecretを作ることができ、またシステムが作るSecretもあります。 - Secretを使うには、PodはSecretを参照することが必要です。 PodがSecretを使う方法は3種類あります。 @@ -30,392 +30,292 @@ PodがSecretを使う方法は3種類あります。 - [コンテナの環境変数](#using-secrets-as-environment-variables)として利用する - Podを生成するために[kubeletがイメージをpullする](#using-imagepullsecrets)ときに使用する -### 内蔵のSecret -#### 自動的にサービスアカウントがAPIの認証情報のSecretを生成し、アタッチする - -KubernetesはAPIにアクセスするための認証情報を含むSecretを自動的に生成し、この種のSecretを使うように自動的にPodを改変します。 - -必要であれば、APIの認証情報が自動生成され利用される機能は無効化したり、上書きしたりすることができます。しかし、安全にAPIサーバーでアクセスすることのみが必要なのであれば、これは推奨されるワークフローです。 - -サービスアカウントがどのように機能するのかについては、[サービスアカウント](/docs/tasks/configure-pod-container/configure-service-account/) -のドキュメントを参照してください。 - -### Secretを作成する - -#### `kubectl`を利用してSecretを作成する - -SecretにはPodがデータベースにアクセスするために必要な認証情報を含むことができます。 -例えば、ユーザー名とパスワードからなる接続文字列です。 -ローカルマシンのファイル`./username.txt`にユーザー名を、ファイル`./password.txt`にパスワードを保存することができます。 - -```shell -# この後の例で使用するファイルを作成します -echo -n 'admin' > ./username.txt -echo -n '1f2d1e2e67df' > ./password.txt -``` - -`kubectl create secret`コマンドはそれらのファイルをSecretに格納して、APIサーバー上でオブジェクトを作成します。 Secretオブジェクトの名称は正当な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。 +シークレットの構成ファイルを作成するときに、`data`および/または`stringData`フィールドを指定できます。`data`フィールドと`stringData`フィールドはオプションです。 +`data`フィールドのすべてのキーの値は、base64でエンコードされた文字列である必要があります。 +base64文字列への変換が望ましくない場合は、代わりに`stringData`フィールドを指定することを選択できます。これは任意の文字列を値として受け入れます。 + + +`data`と`stringData`のキーは、英数字、`-`、`_`、または`.`で構成されている必要があります。 +`stringData`フィールドのすべてのキーと値のペアは、内部で`data`フィールドにマージされます。 +キーが`data`フィールドと`stringData`フィールドの両方に表示される場合、`stringData`フィールドで指定された値が優先されます。 + +## Secretの種類 {#secret-types} + +Secretを作成するときは、[`Secret`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)の`type`フィールド、または特定の同等の`kubectl`コマンドラインフラグ（使用可能な場合）を使用して、その型を指定できます。 +Secret型は、Secret dataのプログラムによる処理を容易にするために使用されます。 + +Kubernetesは、いくつかの一般的な使用シナリオに対応するいくつかの組み込み型を提供します。 +これらの型は、実行される検証とKubernetesが課す制約の点で異なります。 + +| Builtin Type | Usage | +|--------------|-------| +| `Opaque` | arbitrary user-defined data | +| `kubernetes.io/service-account-token` | service account token | +| `kubernetes.io/dockercfg` | serialized `~/.dockercfg` file | +| `kubernetes.io/dockerconfigjson` | serialized `~/.docker/config.json` file | +| `kubernetes.io/basic-auth` | credentials for basic authentication | +| `kubernetes.io/ssh-auth` | credentials for SSH authentication | +| `kubernetes.io/tls` | data for a TLS client or server | +| `bootstrap.kubernetes.io/token` | bootstrap token data | + +Secretオブジェクトの`type`値として空でない文字列を割り当てることにより、独自のSecret型を定義して使用できます。空の文字列は`Opaque`型として扱われます。Kubernetesは型名に制約を課しません。ただし、組み込み型の1つを使用している場合は、その型に定義されているすべての要件を満たす必要があります。 + +### Opaque secrets + +`Opaque`は、Secret構成ファイルから省略された場合のデフォルトのSecret型です。 +`kubectl`を使用してSecretを作成する場合、`generic`サブコマンドを使用して`Opaque`Secret型を示します。 たとえば、次のコマンドは、`Opaque`型の空のSecretを作成します。 ```shell -kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt -``` - -次のように出力されます: - -``` -secret "db-user-pass" created -``` - -デフォルトのキー名はファイル名です。`[--from-file=[key=]source]`を使って任意でキーを指定することができます。 - -```shell -kubectl create secret generic db-user-pass --from-file=username=./username.txt --from-file=password=./password.txt -``` - -{{< note >}} -`$`、`\`、`*`、`=`、`!`のような特殊文字は[シェル](https://ja.wikipedia.org/wiki/%E3%82%B7%E3%82%A7%E3%83%AB)に解釈されるので、エスケープする必要があります。 -ほとんどのシェルではパスワードをエスケープする最も簡単な方法はシングルクォート(`'`)で囲むことです。 -例えば、実際のパスワードが`S!B\*d$zDsb=`だとすると、実行すべきコマンドは下記のようになります。 - -```shell -kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password='S!B\*d$zDsb=' -``` - -`--from-file`を使ってファイルからパスワードを読み込む場合、ファイルに含まれるパスワードの特殊文字をエスケープする必要はありません。 -{{< /note >}} - -Secretが作成されたことを確認できます。 - -```shell -kubectl get secrets +kubectl create secret generic empty-secret +kubectl get secret empty-secret ``` 出力は次のようになります。 ``` -NAME TYPE DATA AGE -db-user-pass Opaque 2 51s +NAME TYPE DATA AGE +empty-secret Opaque 0 2m6s ``` -Secretの説明を参照することができます。 +`DATA`列には、Secretに保存されているデータ項目の数が表示されます。 +この場合、`0`は空のSecretを作成したことを意味します。 -```shell -kubectl describe secrets/db-user-pass -``` +### Service account token Secrets -出力は次のようになります。 - -``` -Name: db-user-pass -Namespace: default -Labels: -Annotations: - -Type: Opaque - -Data -==== -password.txt: 12 bytes -username.txt: 5 bytes -``` - -{{< note >}} -`kubectl get`や`kubectl describe`コマンドはデフォルトではSecretの内容の表示を避けます。 -これはSecretを誤って盗み見られたり、ターミナルのログへ記録されてしまったりすることがないよう保護するためです。 -{{< /note >}} - -Secretの内容を参照する方法は[Secretのデコード](#decoding-a-secret)を参照してください。 - -#### 手動でSecretを作成する - -SecretをJSONまたはYAMLフォーマットのファイルで作成し、その後オブジェクトを作成することができます。 -Secretオブジェクトの名称は正当な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names)である必要があります。 -[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)は、`data`と`stringData`の2つの連想配列を持ちます。 -`data`フィールドは任意のデータの保存に使われ、Base64でエンコードされています。 -`stringData`は利便性のために存在するもので、機密データをエンコードされない文字列で扱えます。 - -例えば、`data`フィールドを使って1つのSecretに2つの文字列を保存するには、次のように文字列をBase64エンコードします。 - -```shell -echo -n 'admin' | base64 -``` - -出力は次のようになります。 - -``` -YWRtaW4= -``` - -```shell -echo -n '1f2d1e2e67df' | base64 -``` - -出力は次のようになります。 - -``` -MWYyZDFlMmU2N2Rm -``` - -このようなSecretを書きます。 +`kubernetes.io/service-account-token`型のSecretは、サービスアカウントを識別するトークンを格納するために使用されます。 このSecret型を使用する場合は、`kubernetes.io/service-account.name`アノテーションが既存のサービスアカウント名に設定されていることを確認する必要があります。Kubernetesコントローラーは、`kubernetes.io/service-account.uid`アノテーションや実際のトークンコンテンツに設定された`data`フィールドの`token`キーなど、他のいくつかのフィールドに入力します。 ```yaml apiVersion: v1 kind: Secret metadata: - name: mysecret -type: Opaque + name: secret-sa-sample + annotations: + kubernetes.io/service-account.name: "sa-name" +type: kubernetes.io/service-account-token data: - username: YWRtaW4= - password: MWYyZDFlMmU2N2Rm + # You can include additional key value pairs as you do with Opaque Secrets + extra: YmFyCg== ``` -これでSecretを[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)コマンドで作成できるようになりました。 +`Pod`を作成すると、Kubernetesはservice account Secretを自動的に作成し、このSecretを使用するようにPodを自動的に変更します。service account token Secretには、APIにアクセスするための資格情報が含まれています。 -```shell -kubectl apply -f ./secret.yaml -``` +API証明の自動作成と使用は、必要に応じて無効にするか、上書きすることができます。 ただし、API Serverに安全にアクセスするだけの場合は、これが推奨されるワークフローです。 -出力は次のようになります。 +ServiceAccountの動作の詳細については、[ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/)のドキュメントを参照してください。 +PodからServiceAccountを参照する方法については、[`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)の`automountServiceAccountToken`フィールドと`serviceAccountName`フィールドを確認することもできます。 -``` -secret "mysecret" created -``` +### Docker config Secrets -状況によっては、代わりに`stringData`フィールドを使いたいときもあるでしょう。 -このフィールドを使えばBase64でエンコードされていない文字列を直接Secretに書くことができて、その文字列はSecretが作られたり更新されたりするときにエンコードされます。 +次の`type`値のいずれかを使用して、イメージのDockerレジストリにアクセスするための資格情報を格納するSecretを作成できます。 -実用的な例として、設定ファイルの格納にSecretを使うアプリケーションをデプロイすることを考えます。 -デプロイプロセスの途中で、この設定ファイルの一部のデータを投入したいとしましょう。 +- `kubernetes.io/dockercfg` +- `kubernetes.io/dockerconfigjson` -例えば、アプリケーションは次のような設定ファイルを使用するとします。 + +`kubernetes.io/dockercfg`型は、Dockerコマンドラインを構成するためのレガシー形式であるシリアル化された`~/.dockercfg`を保存するために予約されています。 +このSecret型を使用する場合は、Secretの`data`フィールドに`.dockercfg`キーが含まれていることを確認する必要があります。このキーの値は、base64形式でエンコードされた`~/.dockercfg`ファイルの内容です。 + +`kubernetes.io/dockerconfigjson`型は、`~/.dockercfg`の新しいフォーマットである`~/.docker/config.json`ファイルと同じフォーマットルールに従うシリアル化されたJSONを保存するために設計されています。 +このSecret型を使用する場合、Secretオブジェクトの`data`フィールドには`.dockerconfigjson`キーが含まれている必要があります。このキーでは、`~/.docker/config.json`ファイルのコンテンツがbase64でエンコードされた文字列として提供されます。 + +以下は、`kubernetes.io/dockercfg`型のSecretの例です。 ```yaml -apiUrl: "https://my.api.com/api/v1" -username: "user" -password: "password" +apiVersion: v1 +kind: Secret + name: secret-dockercfg +type: kubernetes.io/dockercfg + data: + .dockercfg: | + "" ``` -次のような定義を使用して、この設定ファイルをSecretに保存することができます。 +{{< note >}} +base64エンコーディングを実行したくない場合は、代わりに`stringData`フィールドを使用することを選択できます。 +{{< /note >}} + +マニフェストを使用してこれらの型のSecretを作成すると、APIserverは期待されるキーが`data`フィールドに存在するかどうかを確認し、提供された値を有効なJSONとして解析できるかどうかを確認します。APIサーバーは、JSONが実際にDocker configファイルであるかどうかを検証しません。 + + +Docker configファイルがない場合、または`kubectl`を使用してDockerレジストリSecretを作成する場合は、次の操作を実行できます。 + +```shell +kubectl create secret docker-registry secret-tiger-docker \ + --docker-username=tiger \ + --docker-password=pass113 \ + --docker-email=tiger@acme.com +``` + +このコマンドは、`kubernetes.io/dockerconfigjson`型のSecretを作成します。 +`data`フィールドから`.dockerconfigjson`コンテンツをダンプすると、その場で作成された有効なDocker configである次のJSONコンテンツを取得します。 + +```json +{ + "auths": { + "https://index.docker.io/v1/": { + "username": "tiger", + "password": "pass113", + "email": "tiger@acme.com", + "auth": "dGlnZXI6cGFzczExMw==" + } + } +} +``` + +### Basic authentication Secret + +`kubernetes.io/basic-auth`型は、Basic認証に必要な認証を保存するために提供されています。このSecret型を使用する場合、Secretの`data`フィールドには次の2つのキーが含まれている必要があります。 + +- `username`: 認証のためのユーザー名 +- `password`: 認証のためのパスワードかトークン + +上記の2つのキーの両方の値は、base64でエンコードされた文字列です。もちろん、Secretの作成に`stringData`を使用してクリアテキストコンテンツを提供することもできます。 + +次のYAMLは、Basic authentication Secretの設定例です。 + ```yaml apiVersion: v1 kind: Secret metadata: - name: mysecret -type: Opaque + name: secret-basic-auth +type: kubernetes.io/basic-auth stringData: - config.yaml: |- - apiUrl: "https://my.api.com/api/v1" - username: {{username}} - password: {{password}} + username: admin + password: t0p-Secret ``` -デプロイツールは`kubectl apply`を実行する前に`{{username}}`と`{{password}}`のテンプレート変数を置換することができます。 -`stringData`フィールドは利便性のための書き込み専用フィールドです。 -Secretを取得するときに出力されることは決してありません。 -例えば、次のコマンドを実行すると、 +Basic認証Secret型は、ユーザーの便宜のためにのみ提供されています。Basic認証に使用される資格情報の`Opaque`を作成できます。 +ただし、組み込みのSecret型を使用すると、認証の形式を統一するのに役立ち、APIserverは必要なキーがSecret configurationで提供されているかどうかを確認します。 + + +### SSH authentication secrets + +組み込みのタイプ`kubernetes.io/ssh-auth`は、SSH認証で使用されるデータを保存するために提供されています。このSecret型を使用する場合、使用するSSH認証として`data`（または`stringData`）フィールドに`ssh-privatekey`キーと値のペアを指定する必要があります。 + +次のYAMLはSSH authentication Secretの設定例です： + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-ssh-auth +type: kubernetes.io/ssh-auth +data: + # the data is abbreviated in this example + ssh-privatekey: | + MIIEpQIBAAKCAQEAulqb/Y ... +``` + +SSH authentication Secret型は、ユーザーの便宜のためにのみ提供されています。 +SSH認証に使用される資格情報の`Opaque`を作成できます。 +ただし、組み込みのSecret型を使用すると、認証の形式を統一するのに役立ち、APIserverは必要なキーがSecret configurationで提供されているかどうかを確認します。 + +### TLS secrets + +Kubernetesは、TLSに通常使用される証明書とそれに関連付けられたキーを保存するための組み込みのSecret型`kubernetes.io/tls`を提供します。このデータは、主にIngressリソースのTLS terminationで使用されますが、他のリソースで使用されることも、ワークロードによって直接使用されることもあります。 +このSecret型を使用する場合、APIサーバーは各キーの値を実際には検証しませんが、`tls.key`および`tls.crt`キーをSecret configurationの`data`（または`stringData`）フィールドに指定する必要があります。 + + +次のYAMLはTLS Secretの設定例です： + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-tls +type: kubernetes.io/tls +data: + # the data is abbreviated in this example + tls.crt: | + MIIC2DCCAcCgAwIBAgIBATANBgkqh ... + tls.key: | + MIIEpgIBAAKCAQEA7yn3bRHQ5FHMQ ... +``` + +TLS Secret型は、ユーザーの便宜のために提供されています。 TLSサーバーやクライアントに使用される資格情報の`Opaque`を作成できます。ただし、組み込みのSecret型を使用すると、プロジェクトでSecret形式の一貫性を確保できます。APIserverは、必要なキーがSecret configurationで提供されているかどうかを確認します。 + +`kubectl`を使用してTLS Secretを作成する場合、次の例に示すように`tls`サブコマンドを使用できます。 ```shell -kubectl get secret mysecret -o yaml +kubectl create secret tls my-tls-secret \ + --cert=path/to/cert/file \ + --key=path/to/key/file ``` -出力は次のようになります。 + +公開鍵と秘密鍵のペアは、事前に存在している必要があります。`--cert`の公開鍵証明書は.PEMエンコード（Base64エンコードDER形式）であり、`--key`の指定された秘密鍵と一致する必要があります。 +秘密鍵は、一般にPEM秘密鍵形式と呼ばれる暗号化されていない形式である必要があります。どちらの場合も、PEMの最初と最後の行（たとえば、`-------- BEGIN CERTIFICATE -----`と`------- END CERTIFICATE ----`）は含まれて*いません*。 + +### Bootstrap token Secrets + +Bootstrap token Secretは、Secretの`type`を`bootstrap.kubernetes.io/token`に明示的に指定することで作成できます。このタイプのSecretは、ノードのブートストラッププロセス中に使用されるトークン用に設計されています。よく知られているConfigMapに署名するために使用されるトークンを格納します。 + +Bootstrap toke Secretは通常、`kube-system`namespaceで作成され`bootstrap-token-`の形式で名前が付けられます。ここで``はトークンIDの6文字の文字列です。 + +Kubernetesマニフェストとして、Bootstrap token Secretは次のようになります。 ```yaml apiVersion: v1 kind: Secret metadata: - creationTimestamp: 2018-11-15T20:40:59Z - name: mysecret - namespace: default - resourceVersion: "7225" - uid: c280ad2e-e916-11e8-98f2-025000000001 -type: Opaque + name: bootstrap-token-5emitj + namespace: kube-system +type: bootstrap.kubernetes.io/token data: - config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19 + auth-extra-groups: c3lzdGVtOmJvb3RzdHJhcHBlcnM6a3ViZWFkbTpkZWZhdWx0LW5vZGUtdG9rZW4= + expiration: MjAyMC0wOS0xM1QwNDozOToxMFo= + token-id: NWVtaXRq + token-secret: a3E0Z2lodnN6emduMXAwcg== + usage-bootstrap-authentication: dHJ1ZQ== + usage-bootstrap-signing: dHJ1ZQ== ``` -`username`のようなフィールドを`data`と`stringData`の両方で指定すると、`stringData`の値が使用されます。 -例えば、次のSecret定義からは + +Bootstrap type Secretには、`data`で指定された次のキーがあります。 + +- `token_id`：トークン識別子としてのランダムな6文字の文字列。必須。 +- `token-secret`：実際のtoken secretとしてのランダムな16文字の文字列。必須。 +- `description`：トークンの使用目的を説明する人間が読める文字列。オプション。 +- `expiration`：トークンの有効期限を指定するRFC3339を使用した絶対UTC時間。オプション。 +- `usage-bootstrap-`：Bootstrap tokenの追加の使用法を示すブールフラグ。 +- `auth-extra-groups`：`system：bootstrappers`グループに加えて認証されるグループ名のコンマ区切りのリスト。 + +上記のYAMLは、値がすべてbase64でエンコードされた文字列であるため、分かりづらく見えるかもしれません。実際には、次のYAMLを使用して同一のSecretを作成できます。 ```yaml apiVersion: v1 kind: Secret metadata: - name: mysecret -type: Opaque -data: - username: YWRtaW4= + # Note how the Secret is named + name: bootstrap-token-5emitj + # A bootstrap token Secret usually resides in the kube-system namespace + namespace: kube-system +type: bootstrap.kubernetes.io/token stringData: - username: administrator + auth-extra-groups: "system:bootstrappers:kubeadm:default-node-token" + expiration: "2020-09-13T04:39:10Z" + # This token ID is used in the name + token-id: "5emitj" + token-secret: "kq4gihvszzgn1p0r" + # This token can be used for authentication + usage-bootstrap-authentication: "true" + # and it can be used for signing + usage-bootstrap-signing: "true" ``` -次のようなSecretが生成されます。 +## Secretの作成 -```yaml -apiVersion: v1 -kind: Secret -metadata: - creationTimestamp: 2018-11-15T20:46:46Z - name: mysecret - namespace: default - resourceVersion: "7579" - uid: 91460ecb-e917-11e8-98f2-025000000001 -type: Opaque -data: - username: YWRtaW5pc3RyYXRvcg== -``` +Secretを作成するには、いくつかのオプションがあります。 -`YWRtaW5pc3RyYXRvcg==`をデコードすると`administrator`になります。 +- [create Secret using `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- [create Secret from config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- [create Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) -`data`や`stringData`のキーは英数字または'-'、'_'、'.'からなる必要があります。 - -{{< note >}} -シリアライズされたJSONやYAMLの機密データはBase64エンコードされています。 -文字列の中の改行は不正で、含まれていてはなりません。 -Darwin/macOSの`base64`ユーティリティーを使うときは、長い行を分割する`-b`オプションを指定するのは避けるべきです。 -反対に、Linuxユーザーは`base64`コマンドに`-w 0`オプションを指定するか、`-w`オプションが使えない場合は`base64 | tr -d '\n'`のようにパイプ*すべき*です。 -{{< /note >}} - -#### ジェネレーターからSecretを作成する - -Kubernetes v1.14から、`kubectl`は[Kustomizeを使ったオブジェクトの管理](/docs/tasks/manage-kubernetes-objects/kustomization/)に対応しています。 -KustomizeはSecretやConfigMapを生成するリソースジェネレーターを提供します。 -Kustomizeのジェネレーターはディレクトリの中の`kustomization.yaml`ファイルにて指定されるべきです。 -Secretが生成された後には、`kubectl apply`コマンドを使用してAPIサーバー上にSecretを作成することができます。 - -#### ファイルからのSecretの生成 - -./username.txtと./password.txtのファイルから生成するように`secretGenerator`を定義することで、Secretを生成することができます。 - -```shell -cat <./kustomization.yaml -secretGenerator: -- name: db-user-pass - files: - - username.txt - - password.txt -EOF -``` - -Secretを生成するには、`kustomization.yaml`を含むディレクトリをapplyします。 - -```shell -kubectl apply -k . -``` - -出力は次のようになります。 - -``` -secret/db-user-pass-96mffmfh4k created -``` - -Secretが生成されたことを確認できます。 - -```shell -kubectl get secrets -``` - -出力は次のようになります。 - -``` -NAME TYPE DATA AGE -db-user-pass-96mffmfh4k Opaque 2 51s -``` - -```shell -kubectl describe secrets/db-user-pass-96mffmfh4k -``` - -出力は次のようになります。 - -``` -Name: db-user-pass -Namespace: default -Labels: -Annotations: - -Type: Opaque - -Data -==== -password.txt: 12 bytes -username.txt: 5 bytes -``` - -#### 文字列リテラルからのSecretの生成 - -リテラル`username=admin`と`password=secret`から生成するように`secretGenerator`を定義して、Secretを生成することができます。 - -```shell -cat <./kustomization.yaml -secretGenerator: -- name: db-user-pass - literals: - - username=admin - - password=secret -EOF -``` - -Secretを生成するには、`kustomization.yaml`を含むディレクトリをapplyします。 - -```shell -kubectl apply -k . -``` - -出力は次のようになります。 - -``` -secret/db-user-pass-dddghtt9b5 created -``` - -{{< note >}} -Secretが生成されるとき、Secretのデータからハッシュ値が算出され、Secretの名称にハッシュ値が加えられます。 -これはデータが更新されたときに毎回新しいSecretが生成されることを保証します。 -{{< /note >}} - -#### Secretのデコード - -Secretは`kubectl get secret`を実行することで取得可能です。 -例えば、前のセクションで作成したSecretは次のコマンドを実行することで参照できます。 - -```shell -kubectl get secret mysecret -o yaml -``` - -出力は次のようになります。 - -```yaml -apiVersion: v1 -kind: Secret -metadata: - creationTimestamp: 2016-01-22T18:41:56Z - name: mysecret - namespace: default - resourceVersion: "164619" - uid: cfee02d6-c137-11e5-8d73-42010af00002 -type: Opaque -data: - username: YWRtaW4= - password: MWYyZDFlMmU2N2Rm -``` - -`password`フィールドをデコードします。 - -```shell -echo 'MWYyZDFlMmU2N2Rm' | base64 --decode -``` - -出力は次のようになります。 - -``` -1f2d1e2e67df -``` - -#### Secretの編集 +## Secretの編集 既存のSecretは次のコマンドで編集することができます。 @@ -491,7 +391,7 @@ Podに複数のコンテナがある場合、それぞれのコンテナが`volu #### Secretのキーの特定のパスへの割り当て Secretのキーが割り当てられるパスを制御することができます。 -それぞれのキーがターゲットとするパスは`.spec.volumes[].secret.items`フィールドによって指定てきます。 +それぞれのキーがターゲットとするパスは`.spec.volumes[].secret.items`フィールドによって指定できます。 ```yaml apiVersion: v1 @@ -668,32 +568,6 @@ Secretはwatch（デフォルト）、TTLベース、単に全てのリクエス Secretを[subPath](/docs/concepts/storage/volumes#using-subpath)を指定してボリュームにマウントしているコンテナには、Secretの更新が反映されません。 {{< /note >}} -{{< feature-state for_k8s_version="v1.18" state="alpha" >}} - -Kubernetesのアルファ機能である _Immutable Secrets and ConfigMaps_ は各SecretやConfigMapが不変であると設定できるようにします。 -Secretを広範に利用しているクラスター（PodにマウントされているSecretが1万以上）においては、データが変更されないようにすることで次のような利点が得られます。 - -- 意図しない（または望まない）変更によってアプリケーションの停止を引き起こすことを防ぎます -- 不変であると設定されたSecretの監視を停止することにより、kube-apiserverの負荷が著しく軽減され、クラスターのパフォーマンスが改善されます - -この機能を利用するには、`ImmutableEphemeralVolumes`[feature gate](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にして、SecretまたはConfigMapの`immutable`フィールドに`true`を指定します。例えば、次のようにします。 - -```yaml -apiVersion: v1 -kind: Secret -metadata: - ... -data: - ... -immutable: true -``` - -{{< note >}} -一度SecretやConfigMapを不変であると設定すると、この変更を戻すことや`data`フィールドの内容を書き換えることは _できません_ 。 -Secretを削除して、再生成することだけができます。 -既存のPodは削除されたSecretへのマウントポイントを持ち続けるため、Podを再生成することが推奨されます。 -{{< /note >}} - ### Secretを環境変数として使用する {#using-secrets-as-environment-variables} SecretをPodの{{< glossary_tooltip text="環境変数" term_id="container-env-variables" >}}として使用するには、 @@ -753,6 +627,32 @@ echo $SECRET_PASSWORD 1f2d1e2e67df ``` +## Immutable Secrets {#secret-immutable} + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + +Kubernetesベータ機能*ImmutableSecrets and ConfigMaps*は、個々のSecretsとConfigMapsをimutableとして設定するオプションを提供します。Secret（少なくとも数万の、SecretからPodへの一意のマウント）を広範囲に使用するクラスターの場合、データの変更を防ぐことには次の利点があります。 + +- アプリケーションの停止を引き起こす可能性のある偶発的な（または不要な）更新からユーザーを保護します +- imutableとしてマークされたSecretのウォッチを閉じることで、kube-apiserverの負荷を大幅に削減することができ、クラスターのパフォーマンスを向上させます。 + +この機能は、`ImmutableEphemeralVolumes`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)によって制御されます。これは、v1.19以降デフォルトで有効になっています。`immutable`フィールドを`true`に設定することで、imutableのSecretを作成できます。例えば、 +```yaml +apiVersion: v1 +kind: Secret +metadata: + ... +data: + ... +immutable: true +``` +{{< note >}} +SecretまたはConfigMapがimutableとしてマークされると、この変更を元に戻したり、`data`フィールドの内容を変更したりすることは*できません*。Secretを削除して再作成することしかできません。 +既存のPodは、削除されたSecretへのマウントポイントを維持します。これらのPodを再作成することをお勧めします。 +{{< /note >}} + + + ### imagePullSecretsを使用する {#using-imagepullsecrets} `imagePullSecrets`フィールドは同一のネームスペース内のSecretの参照のリストです。 @@ -1028,8 +928,8 @@ kubectl apply -k . 2つのサービスアカウントを使用すると、ベースのPod仕様をさらに単純にすることができます。 -1. `prod-user` と `prod-db-secret` -1. `test-user` と `test-db-secret` +1. `prod-user`と`prod-db-secret` +1. `test-user`と`test-db-secret` 簡略化されたPod仕様は次のようになります。 @@ -1155,3 +1055,10 @@ Podに複数のコンテナが含まれることもあります。しかし、Po - Secretを利用するPodを作成できるユーザーはSecretの値を見ることができます。たとえAPIサーバーのポリシーがユーザーにSecretの読み取りを許可していなくても、ユーザーはSecretを晒すPodを実行することができます。 - 現在、任意のノードでルート権限を持つ人は誰でも、kubeletに偽装することで _任意の_ SecretをAPIサーバーから読み取ることができます。 単一のノードのルート権限を不正に取得された場合の影響を抑えるため、実際に必要としているノードに対してのみSecretを送る機能が計画されています。 + + +## {{% heading "whatsnext" %}} + +- [`kubectl`を使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)方法を学ぶ +- [config fileを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-config-file/)方法を学ぶ +- [kustomizeを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を学ぶ diff --git a/content/ja/docs/concepts/containers/_index.md b/content/ja/docs/concepts/containers/_index.md old mode 100755 new mode 100644 index 5b10416c0f..cb2b457e57 --- a/content/ja/docs/concepts/containers/_index.md +++ b/content/ja/docs/concepts/containers/_index.md @@ -18,10 +18,10 @@ no_list: true -## コンテナイメージ +## コンテナイメージ {#container-images} [コンテナイメージ](/docs/concepts/containers/images/)はすぐに実行可能なソフトウェアパッケージで、アプリケーションの実行に必要なものをすべて含んています。コードと必要なランタイム、アプリケーションとシステムのライブラリ、そして必須な設定項目のデフォルト値を含みます。 -設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいコンテナをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。 +設計上、コンテナは不変で、既に実行中のコンテナのコードを変更することはできません。コンテナ化されたアプリケーションがあり変更したい場合は、変更を含んだ新しいイメージをビルドし、コンテナを再作成して、更新されたイメージから起動する必要があります。 ## コンテナランタイム diff --git a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md index ba94bd6fab..7804a0c212 100644 --- a/content/ja/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/ja/docs/concepts/containers/container-lifecycle-hooks.md @@ -30,11 +30,11 @@ Angularなどのコンポーネントライフサイクルフックを持つ多 `PreStop` -このフックは、liveness probeの失敗、プリエンプション、リソース競合などのAPI要求または管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナがすでに終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。 -これはブロッキング、つまり同期的であるため、コンテナを削除するための呼び出しを送信する前に完了する必要があります。 +このフックは、APIからの要求、またはliveness probeの失敗、プリエンプション、リソース競合などの管理イベントが原因でコンテナが終了する直前に呼び出されます。コンテナがすでに終了状態または完了状態にある場合、preStopフックの呼び出しは失敗します。 +これはブロッキング、つまり同期的であるため、コンテナを停止する信号が送信される前に完了する必要があります。 ハンドラーにパラメーターは渡されません。 -終了動作の詳細な説明は、[Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。 +終了動作の詳細な説明は、[Termination of Pods](/ja/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)にあります。 ### フックハンドラーの実装 @@ -47,27 +47,32 @@ Angularなどのコンポーネントライフサイクルフックを持つ多 ### フックハンドラーの実行 -コンテナライフサイクル管理フックが呼び出されると、Kubernetes管理システムはそのフック用に登録されたコンテナ内のハンドラーを実行します。 +コンテナライフサイクル管理フックが呼び出されると、Kubernetes管理システムはフックアクションにしたがってハンドラーを実行します。 +`exec`と`tcpSocket`はコンテナの中で実行され、`httpGet`はkubeletプロセスによって実行されます。 フックハンドラーの呼び出しは、コンテナを含むPodのコンテキスト内で同期しています。 これは、`PostStart`フックの場合、コンテナのENTRYPOINTとフックは非同期に起動することを意味します。 しかし、フックの実行に時間がかかりすぎたりハングしたりすると、コンテナは`running`状態になることができません。 -その振る舞いは `PreStop`フックに似ています。 -実行中にフックがハングした場合、Podフェーズは`Terminating`状態に留まり、Podの`terminationGracePeriodSeconds`が終了した後に終了します。 -`PostStart`または`PreStop`フックが失敗した場合、コンテナを強制終了します。 +`PreStop`フックはコンテナを停止する信号から非同期で実行されるのではなく、信号が送られる前に実行を完了する必要があります。 +もし`PreStop`フックが実行中にハングした場合、Podは`Terminating`状態になり、 +`terminationGracePeriodSeconds`の時間切れで強制終了されるまで続きます。 +この猶予時間は、`PreStop`フックが実行され正常にコンテナを停止できるまでの合計時間に適用されます。 +例えば`terminationGracePeriodSeconds`が60で、フックの終了に55秒かかり、シグナルを受信した後にコンテナを正常に停止させるのに10秒かかる場合、コンテナは正常に停止する前に終了されてしまいます。`terminationGracePeriodSeconds`が、これら２つの実行にかかる合計時間(55+10)よりも短いからです。 + +`PostStart`または`PreStop`フックが失敗した場合、コンテナは強制終了します。 ユーザーはフックハンドラーをできるだけ軽量にするべきです。 -ただし、コンテナを停止する前に状態を保存する場合など、長時間実行されるコマンドが意味をなす場合があります。 +ただし、コンテナを停止する前に状態を保存するなどの場合は、長時間のコマンド実行が必要なケースもあります。 -### フック配送保証 +### フック配信保証 -フックの配送は *少なくとも1回* を意図しています。これはフックが`PostStart`や`PreStop`のような任意のイベントに対して複数回呼ばれることがあることを意味します。 +フックの配信は *少なくとも1回* を意図しています。これはフックが`PostStart`や`PreStop`のような任意のイベントに対して複数回呼ばれることがあることを意味します。 これを正しく処理するのはフックの実装次第です。 -通常、単一の配送のみが行われます。 +通常、1回の配信のみが行われます。 たとえば、HTTPフックレシーバーがダウンしていてトラフィックを受け取れない場合、再送信は試みられません。 -ただし、まれに二重配送が発生することがあります。 +ただし、まれに二重配信が発生することがあります。 たとえば、フックの送信中にkubeletが再起動した場合、kubeletが起動した後にフックが再送信される可能性があります。 ### フックハンドラーのデバッグ @@ -101,4 +106,3 @@ Events: * [コンテナ環境](/ja/docs/concepts/containers/container-environment/)の詳細 * [コンテナライフサイクルイベントへのハンドラー紐付け](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)のハンズオン - diff --git a/content/ja/docs/concepts/containers/images.md b/content/ja/docs/concepts/containers/images.md index 0ad4459d79..ab1bdda921 100644 --- a/content/ja/docs/concepts/containers/images.md +++ b/content/ja/docs/concepts/containers/images.md @@ -48,10 +48,9 @@ weight: 10 `imagePullPolicy`が値なしで定義された場合、この場合も`Always`が設定されます。 -## マニフェストを使ったマルチアーキテクチャイメージ +## イメージインデックスを使ったマルチアーキテクチャイメージ -コンテナレジストリはバイナリイメージの提供だけでなく、[コンテナイメージマニフェスト](https://github.com/opencontainers/image-spec/blob/master/manifest.md)も提供する事ができます。 -マニフェストはコンテナのアーキテクチャ固有バージョンに関するイメージマニフェストを参照できます。マニフェストの目的はイメージの名前(例:`pause`、`example/mycontainer`、`kube-apiserver`)をもたせ、様々なシステムが使用しているマシンアーキテクチャにあう適切なバイナリイメージを取得できることです。 +コンテナレジストリはバイナリイメージの提供だけでなく、[コンテナイメージインデックス](https://github.com/opencontainers/image-spec/blob/master/image-index.md)も提供する事ができます。イメージインデックスはコンテナのアーキテクチャ固有バージョンに関する複数の[イメージマニフェスト](https://github.com/opencontainers/image-spec/blob/master/manifest.md)を指すことができます。イメージインデックスの目的はイメージの名前(例:`pause`、`example/mycontainer`、`kube-apiserver`)をもたせ、様々なシステムが使用しているマシンアーキテクチャにあう適切なバイナリイメージを取得できることです。 Kubernetes自身は、通常コンテナイメージに`-$(ARCH)`のサフィックスを持つ名前をつけます。下位互換の為にサフィックス付きの古い仕様のイメージを生成してください。その目的は、`pause`のようなすべてのアーキテクチャのマニフェストを持つイメージと、サフィックスのあるイメージをハードコードしていた可能性のある古い仕様の設定やYAMLファイルと下位互換がある`pause-amd64`のようなイメージを生成することです。 @@ -179,7 +178,7 @@ Node構成を制御できる場合、この方法が適しています。 すべてのPodは事前にPullしたイメージへの読み取りアクセス権をもちます。 -### PodでImagePullSecretsを指定する +### PodでimagePullSecretsを指定する {{< note >}} この方法がプライベートレジストリのイメージに基づいてコンテナを実行するための推奨の方法です。 @@ -187,7 +186,7 @@ Node構成を制御できる場合、この方法が適しています。 KubernetesはPodでのコンテナイメージレジストリキーの指定をサポートしています。 -#### Docker Configを利用してSecretを作成する。 +#### Dockerの設定を利用してSecretを作成する。 適切な大文字の値を置き換えて、次のコマンドを実行します。 diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md index 8d89f7ff37..bc4e285c66 100644 --- a/content/ja/docs/concepts/containers/runtime-class.md +++ b/content/ja/docs/concepts/containers/runtime-class.md @@ -140,7 +140,7 @@ RuntimeClassのnodeSelectorはアドミッション機能によりPodのnodeSele {{< feature-state for_k8s_version="v1.18" state="beta" >}} -Podが稼働する時に関連する_オーバーヘッド_リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。 +Podが稼働する時に関連する _オーバーヘッド_ リソースを指定できます。オーバーヘッドを宣言すると、クラスター(スケジューラーを含む)がPodとリソースに関する決定を行うときにオーバーヘッドを考慮することができます。 Podオーバーヘッドを使うためには、PodOverhead[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしなければなりません。(デフォルトではonです) PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによって定義されます。 @@ -149,7 +149,7 @@ PodのオーバーヘッドはRuntimeClass内の`overhead`フィールドによ ## {{% heading "whatsnext" %}} -- [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) -- [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md) -- [Podオーバーヘッド](/docs/concepts/configuration/pod-overhead/)のコンセプトを読む +- [RuntimeClassデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md) +- [RuntimeClassスケジューリングデザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling) +- [Podオーバーヘッド](/docs/concepts/scheduling-eviction/pod-overhead/)のコンセプトを読む - [PodOverhead機能デザイン](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) diff --git a/content/ja/docs/concepts/extend-kubernetes/_index.md b/content/ja/docs/concepts/extend-kubernetes/_index.md index e1b30a8ae8..07cf8b2af2 100644 --- a/content/ja/docs/concepts/extend-kubernetes/_index.md +++ b/content/ja/docs/concepts/extend-kubernetes/_index.md @@ -105,7 +105,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま ### APIアクセス拡張 {#api-access-extensions} -リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/reference/access-authn-authz/controlling-access/)を参照して下さい。 +リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/concepts/security/controlling-access/)を参照して下さい。 これらの各ステップごとに拡張ポイントが用意されています。 diff --git a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index 3616f568c1..85c1c4a77f 100644 --- a/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -14,7 +14,7 @@ weight: 10 ## カスタムリソース -*リソース* は、[Kubernetes API](/docs/reference/using-api/api-overview/)のエンドポイントで、特定の[APIオブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)のコレクションを保持します。例えば、ビルトインの *Pods* リソースは、Podオブジェクトのコレクションを包含しています。 +*リソース* は、[Kubernetes API](/ja/docs/concepts/overview/kubernetes-api/)のエンドポイントで、特定の[APIオブジェクト](/ja/docs/concepts/overview/working-with-objects/kubernetes-objects/)のコレクションを保持します。例えば、ビルトインの *Pods* リソースは、Podオブジェクトのコレクションを包含しています。 *カスタムリソース* は、Kubernetes APIの拡張で、デフォルトのKubernetesインストールでは、必ずしも利用できるとは限りません。つまりそれは、特定のKubernetesインストールのカスタマイズを表します。しかし、今現在、多数のKubernetesのコア機能は、カスタムリソースを用いて作られており、Kubernetesをモジュール化しています。 diff --git a/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md index feffdf058b..fd889ecfa2 100644 --- a/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/ja/docs/concepts/extend-kubernetes/extend-cluster.md @@ -107,7 +107,7 @@ Webhookのモデルでは、Kubernetesは外部のサービスを呼び出しま ### APIアクセスエクステンション -リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/reference/access-authn-authz/controlling-access/)を参照して下さい。 +リクエストがKubernetes APIサーバーに到達すると、まず最初に認証が行われ、次に認可、その後、様々なAdmission Controlの対象になります。このフローの詳細は[Kubernetes APIへのアクセスをコントロールする](/docs/concepts/security/controlling-access/)を参照して下さい。 これらの各ステップごとに拡張ポイントが用意されています。 diff --git a/content/ja/docs/concepts/extend-kubernetes/operator.md b/content/ja/docs/concepts/extend-kubernetes/operator.md index e9ac2054e8..116ebbb434 100644 --- a/content/ja/docs/concepts/extend-kubernetes/operator.md +++ b/content/ja/docs/concepts/extend-kubernetes/operator.md @@ -27,7 +27,7 @@ Kubernetesは自動化のために設計されています。追加の作業、 ワークロードのデプロイおよび稼働を自動化するためにKubernetesを使うことができます。 *さらに* Kubernetesがそれをどのように行うかの自動化も可能です。 Kubernetesの{{< glossary_tooltip text="コントローラー" term_id="controller" >}}コンセプトは、Kubernetesのソースコードを修正すること無く、クラスターの振る舞いを拡張することを可能にします。 -オペレーターはKubernetes APIのクライアントで、[Custom Resource](/docs/concepts/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。 +オペレーターはKubernetes APIのクライアントで、[Custom Resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)にとっての、コントローラーのように振る舞います。 ## オペレーターの例 {#example} @@ -87,10 +87,12 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更 * [Custom Resources](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)をより深く学びます * ユースケースに合わせた、既製のオペレーターを[OperatorHub.io](https://operatorhub.io/)から見つけます * 自前のオペレーターを書くために既存のツールを使います、例: + * [Charmed Operator Framework](https://juju.is/) * [KUDO](https://kudo.dev/)（Kubernetes Universal Declarative Operator）を使います * [kubebuilder](https://book.kubebuilder.io/)を使います - * [Metacontroller](https://metacontroller.app/)を自分で実装したWebHooksと一緒に使います - * [Operator Framework](https://github.com/operator-framework/getting-started)を使います + * [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html)を自分で実装したWebHooksと一緒に使います + * [Operator Framework](https://operatorframework.io)を使います + * [shell-operator](https://github.com/flant/shell-operator) * 自前のオペレーターを他のユーザーのために[公開](https://operatorhub.io/)します * オペレーターパターンを紹介している[CoreOSオリジナル記事](https://coreos.com/blog/introducing-operators.html)を読みます * Google Cloudが出したオペレーター作成のベストプラクティス[記事](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)を読みます diff --git a/content/ja/docs/concepts/overview/_index.md b/content/ja/docs/concepts/overview/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/concepts/overview/components.md b/content/ja/docs/concepts/overview/components.md index dbea76db1d..3dafc54e57 100644 --- a/content/ja/docs/concepts/overview/components.md +++ b/content/ja/docs/concepts/overview/components.md @@ -17,7 +17,7 @@ Kubernetesをデプロイすると、クラスターが展開されます。 すべてのコンポーネントが結び付けられたKubernetesクラスターの図を次に示します。 -![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.png) +![Kubernetesのコンポーネント](/images/docs/components-of-kubernetes.svg) diff --git a/content/ja/docs/concepts/overview/kubernetes-api.md b/content/ja/docs/concepts/overview/kubernetes-api.md index 251f671b6d..876cdac7fa 100644 --- a/content/ja/docs/concepts/overview/kubernetes-api.md +++ b/content/ja/docs/concepts/overview/kubernetes-api.md @@ -18,22 +18,13 @@ APIサーバーは、エンドユーザー、クラスターのさまざまな Kubernetes APIを使用すると、Kubernetes API内のオブジェクトの状態をクエリで操作できます（例：Pod、Namespace、ConfigMap、Events）。 -APIエンドポイント、リソースタイプ、サンプルについては[APIリファレンス](/docs/reference/kubernetes-api/)で説明しています。 +ほとんどの操作は、APIを使用している[kubectl](/docs/reference/kubectl/overview/)コマンドラインインターフェースもしくは[kubeadm](/docs/reference/setup-tools/kubeadm/)のような別のコマンドラインツールを通して実行できます。 +RESTコールを利用して直接APIにアクセスすることも可能です。 + +Kubernetes APIを利用してアプリケーションを書いているのであれば、[client libraries](/docs/reference/using-api/client-libraries/)の利用を考えてみてください。 -## APIの変更 - -成功を収めているシステムはすべて、新しいユースケースの出現や既存の変化に応じて成長し、変化する必要があります。 -したがって、Kubernetesには、Kubernetes APIを継続的に変更および拡張できる設計機能があります。 -Kubernetesプロジェクトは、既存のクライアントとの互換性を破壊しないこと、およびその互換性を一定期間維持して、他のプロジェクトが適応する機会を提供することを目的としています。 - -基本的に、新しいAPIリソースと新しいリソースフィールドは追加することができます。 -リソースまたはフィールドを削除するには、[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従ってください。 - -互換性のある変更の構成要素とAPIの変更方法については、[APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)で詳しく説明しています。 - - ## OpenAPI 仕様 {#api-specification} 完全なAPIの詳細は、[OpenAPI](https://www.openapis.org/)を使用して文書化されています。 @@ -43,6 +34,7 @@ Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOp + @@ -70,74 +62,55 @@ Kubernetes APIサーバーは、`/openapi/v2`エンドポイントを介してOp -
    OpenAPI v2クエリの有効なリクエストヘッダー値
    Headerapplication/jsonを提供
    OpenAPI v2クエリの有効なリクエストヘッダー値
    -Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しており、そのフォーマットの概要は[デザイン提案](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md)に記載されています。また各スキーマのIDFファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。 - -## APIバージョニング - -フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/rbac.authorization.k8s.io/v1alpha1`のように、それぞれ異なるAPIのパスが割り当てられています。 - -APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンが行われます。 - -JSONとProtocol Buffersのシリアライズスキーマも、スキーマ変更に関して同じガイドラインに従います。ここから以下の説明は、双方のフォーマットをカバーしています。 - -APIとソフトウエアのバージョニングは、間接的にしか関連していないことに注意してください。[APIとリリースバージョニング提案](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md)で、APIとソフトウェアのバージョニングの関連について記載しています。 - -異なるバージョンのAPIでは、安定性やサポートのレベルも変わります。各レベルの詳細な条件は、[APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions)に記載されています。下記に簡潔にまとめます: - -- アルファレベル(版): - - バージョン名に`alpha`を含みます(例、`v1alpha1`)。 - - バグが多いかもしれません。アルファ機能の有効化がバグを顕在化させるかもしれません。デフォルトでは無効となっています。 - - アルファ機能のサポートは、いつでも通知無しに取りやめられる可能性があります。 - - ソフトウェアリリース後、APIが通知無しに互換性が無い形で変更される可能性があります。 - - バグが増えるリスク、また長期サポートが無いことから、短期間のテスト用クラスターでの利用を推奨します。 -- ベータレベル(版): - - バージョン名に`beta`を含みます(例、`v2beta3`)。 - - コードは十分にテストされています。ベータ機能の有効化は安全だと考えられます。デフォルトで有効化されています。 - - 全体的な機能のサポートは取りやめられませんが、詳細は変更される可能性があります。 - - オブジェクトのスキーマ、意味はその後のベータ、安定版リリースで互換性が無い形で変更される可能性があります。その場合、次のバージョンへアップデートするための手順を提供します。その手順ではAPIオブジェクトの削除、修正、再作成が必要になるかもしれません。修正のプロセスは多少の検討が必要になるかもしれません。これは、この機能を利用しているアプリケーションでダウンタイムが必要になる可能性があるためです。 - - 今後のリリースで、互換性の無い変更が行われる可能性があるため、ビジネスクリティカルな場面以外での利用を推奨します。もし複数のクラスターを持っており、それぞれ個別にアップグレードが可能な場合、この制限の影響を緩和できるかもしれません。 - - **是非ベータ機能を試して、フィードバックをください！ベータから安定版になってしまうと、より多くの変更を加えることが難しくなってしまいます。** -- 安定版: - - バージョン名は`vX`のようになっており、`X`は整数です。 - - 安定版の機能は、今後のリリースバージョンにも適用されます。 - -## APIグループ {#api-groups} - -APIの拡張を簡易に行えるようにするため、Kubernetesは[*APIグループ*](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md)を実装しました。 -APIグループは、RESTのパスとシリアライズされたオブジェクトの`apiVersion`フィールドで指定されます。 - -クラスターにはいくつかのAPIグループがあります: - -1. *core* グループ(*legacy group* とも呼ばれます)は、`/api/v1`というRESTのパスで、`apiVersion: v1`を使います。 - -1. 名前付きのグループは、`/apis/$GROUP_NAME/$VERSION`というRESTのパスで、`apiVersion: $GROUP_NAME/$VERSION`(例、`apiVersion: batch/v1`)を使います。Kubernetesの[APIリファレンス](/docs/reference/kubernetes-api/)にすべての使用可能なAPIグループのリストがあります。 - -[カスタムリソース](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)でAPIを拡張するために、2つの方法があります: - -1. [カスタムリソース定義](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)は、APIサーバーが選択したリソースAPIを提供する方法を宣言的に定義できます。 -1. [独自の拡張APIサーバーを実装](/docs/tasks/extend-kubernetes/setup-extension-api-server/)し、[アグリゲーター](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)を使用してクライアントに対してシームレスにすることもできます。 - -## APIグループの有効化、無効化 - -いくつかのリソースとAPIグループはデフォルトで有効になっています。それらは、kube-apiserverのコマンドラインオプションとしてAPIサーバーの`--runtime-config`設定で、有効化、無効化できます。 - -`--runtime-config`は、カンマ区切りの複数の値を設定可能です。例えば、batch/v1を無効化する場合、`--runtime-config=batch/v1=false`をセットし、batch/v2alpha1を有効化する場合、`--runtime-config=batch/v2alpha1`をセットします。このフラグは、APIサーバーのランタイム設定を表すkey=valueのペアを、カンマ区切りで指定したセットを指定可能です。 - -{{< note >}}APIグループ、リソースの有効化、無効化は、`--runtime-config`の変更を反映するため、kube-apiserverとkube-controller-managerの再起動が必要です。{{< /note >}} +Kubernetesは、他の手段として主にクラスター間の連携用途向けのAPIに、Protocol buffersをベースにしたシリアライズフォーマットを実装しています。このフォーマットに関しては、[Kubernetes Protobuf serialization](https://github.com/kubernetes/community/blob/master/contributors/des ign-proposals/api-machinery/protobuf.md)デザイン提案を参照してください。また、各スキーマのInterface Definition Language（IDL）ファイルは、APIオブジェクトを定義しているGoパッケージ内に配置されています。 ## 永続性 KubernetesはAPIリソースの観点からシリアル化された状態を{{< glossary_tooltip term_id="etcd" >}}に書き込むことで保存します。 +## APIグループとバージョニング + +フィールドの削除やリソース表現の再構成を簡単に行えるようにするため、Kubernetesは複数のAPIバージョンをサポートしており、`/api/v1`や`/apis/rbac.authorization.k8s.io/v1alpha1`のように、それぞれ異なるAPIのパスが割り当てられています。 + +APIが、システムリソースと動作について明確かつ一貫したビューを提供し、サポート終了、実験的なAPIへのアクセス制御を有効にするために、リソースまたはフィールドレベルではなく、APIレベルでバージョンが行われます。 + +APIの発展や拡張を簡易に行えるようにするため、Kubernetesは[有効もしくは無効](/docs/reference/using-api/#enabling-or-disabling)を行える[APIグループ](/docs/reference/using-api/#api-groups)を実装しました。 + +APIリソースは、APIグループ、リソースタイプ、ネームスペース（namespacedリソースのための）、名前によって区別されます。APIサーバーは、APIバージョン間の変換を透過的に処理します。すべてのバージョンの違いは、実際のところ同じ永続データとして表現されます。APIサーバーは、同じ基本的なデータを複数のAPIバージョンで提供することができます。 + +例えば、同じリソースで`v1`と`v1beta1`の2つのバージョンが有ることを考えてみます。`v1beta1`バージョンのAPIを利用しオブジェクトを最初に作成したとして、`v1beta1`もしくは`v1`どちらのAPIバージョンを利用してもオブジェクトのread、update、deleteができます。 + +## APIの変更 + +成功を収めているシステムはすべて、新しいユースケースの出現や既存の変化に応じて成長し、変化する必要があります。 +したがって、Kubernetesには、Kubernetes APIを継続的に変更および拡張できる設計機能があります。 +Kubernetesプロジェクトは、既存のクライアントとの互換性を破壊 _しないこと_ 、およびその互換性を一定期間維持して、他のプロジェクトが適応する機会を提供することを目的としています。 + +基本的に、新しいAPIリソースと新しいリソースフィールドは追加することができます。 +リソースまたはフィールドを削除するには、[API非推奨ポリシー](/docs/reference/using-api/deprecation-policy/)に従ってください。 + +Kubernetesは、公式のKubernetes APIが一度一般提供（GA）に達した場合、通常は`v1`APIバージョンです、互換性を維持することを強い責任があります。さらに、Kubernetesは _beta_ についても可能な限り互換性を維持し続けます。ベータAPIを採用した場合、その機能が安定版になったあとでも、APIを利用してクラスタを操作し続けることができます。 + +{{< note >}} +Kubernetesは、 _alpha_ APIバージョンについても互換性の維持に注力しますが、いくつかの事情により不可である場合もあります。アルファAPIバージョンを使っている場合、クラスタのアップグレードやAPIが変更された場合に備えて、Kubernetesのリリースノートを確認してください。 +{{< /note >}} + +APIバージョンレベルの定義に関する詳細は[APIバージョンのリファレンス](/docs/reference/using-api/#api-versioning)を参照してください。 + +## APIの拡張 + +Kubernetes APIは2つの方法で拡張できます。 + +1. [カスタムリソース](/ja/docs/concepts/extend-kubernetes/api-extension/custom-resources/)は、APIサーバーが選択したリソースAPIをどのように提供するかを宣言的に定義します。 +1. [アグリゲーションレイヤー](/ja/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)を実装することでKubernetes APIを拡張することもできます。 + ## {{% heading "whatsnext" %}} -[APIアクセスの制御](/docs/reference/access-authn-authz/controlling-access/)は、クラスターがAPIアクセスの認証と承認を管理する方法を説明しています。 - -全体的なAPI規則は、[API規則](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions)の資料で説明されています。 - -APIエンドポイント、リソースタイプ、サンプルについては、[APIリファレンス](/docs/reference/kubernetes-api/)をご覧ください。 +- 自分自身で[カスタムリソース定義](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)を追加してKubernetes APIを拡張する方法について学んでください。 +- [Kubernetes APIのアクセス制御](/docs/concepts/security/controlling-access/)では、クラスターがAPIアクセスの認証と承認を管理する方法を説明しています。 +- [APIリファレンス](/ja/docs/reference/kubernetes-api/)を読んで、APIエンドポイント、リソースタイプやサンプルについて学んでください。 +- [APIの変更](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme)から、互換性のある変更とは何か, どのようにAPIを変更するかについて学んでください。 diff --git a/content/ja/docs/concepts/overview/what-is-kubernetes.md b/content/ja/docs/concepts/overview/what-is-kubernetes.md index dab17c9b1b..d8025aa1df 100644 --- a/content/ja/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ja/docs/concepts/overview/what-is-kubernetes.md @@ -8,6 +8,8 @@ weight: 10 card: name: concepts weight: 10 +sitemap: + priority: 0.9 --- @@ -33,7 +35,7 @@ Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロッ 各VMは、仮想ハードウェア上で各自のOSを含んだ全コンポーネントを実行する完全なマシンです。 -**コンテナを使ったデプロイ (Container deployment):** コンテナはVMと似ていますが、アプリケーション間でオペレーティング・システム(OS)を共有できる緩和された分離特性を持っています。そのため、コンテナは軽量だといわれます。VMと同じように、コンテナは各自のファイルシステム、CPU、メモリー、プロセス空間等を持っています。基盤のインフラストラクチャから分離されているため、クラウドやOSディストリビューションを越えて移動することが可能です。 +**コンテナを使ったデプロイ (Container deployment):** コンテナはVMと似ていますが、アプリケーション間でオペレーティング・システム(OS)を共有できる緩和された分離特性を持っています。そのため、コンテナは軽量だといわれます。VMと同じように、コンテナは各自のファイルシステム、CPUの共有、メモリー、プロセス空間等を持っています。基盤のインフラストラクチャから分離されているため、クラウドやOSディストリビューションを越えて移動することが可能です。 コンテナは、その他にも次のようなメリットを提供するため、人気が高まっています。 @@ -56,17 +58,17 @@ Kubernetesの名称は、ギリシャ語に由来し、操舵手やパイロッ Kubernetesは以下を提供します。 -* **サービスディスカバリーと負荷分散** +* **サービスディスカバリーと負荷分散** Kubernetesは、DNS名または独自のIPアドレスを使ってコンテナを公開することができます。コンテナへのトラフィックが多い場合は、Kubernetesは負荷分散し、ネットワークトラフィックを振り分けることができるため、デプロイが安定します。 -* **ストレージ オーケストレーション** +* **ストレージ オーケストレーション** Kubernetesは、ローカルストレージやパブリッククラウドプロバイダーなど、選択したストレージシステムを自動でマウントすることができます。 -* **自動化されたロールアウトとロールバック** +* **自動化されたロールアウトとロールバック** Kubernetesを使うとデプロイしたコンテナのあるべき状態を記述することができ、制御されたスピードで実際の状態をあるべき状態に変更することができます。例えば、アプリケーションのデプロイのために、新しいコンテナの作成や既存コンテナの削除、新しいコンテナにあらゆるリソースを適用する作業を、Kubernetesで自動化できます。 -* **自動ビンパッキング** +* **自動ビンパッキング** コンテナ化されたタスクを実行するノードのクラスターをKubernetesへ提供します。各コンテナがどれくらいCPUやメモリー(RAM)を必要とするのかをKubernetesに宣言することができます。Kubernetesはコンテナをノードにあわせて調整することができ、リソースを最大限に活用してくれます。 -* **自己修復** +* **自己修復** Kubernetesは、処理が失敗したコンテナを再起動し、コンテナを入れ替え、定義したヘルスチェックに応答しないコンテナを強制終了します。処理の準備ができるまでは、クライアントに通知しません。 -* **機密情報と構成管理** +* **機密情報と構成管理** Kubernetesは、パスワードやOAuthトークン、SSHキーのよう機密の情報を保持し、管理することができます。機密情報をデプロイし、コンテナイメージを再作成することなくアプリケーションの構成情報を更新することができます。スタック構成の中で機密情報を晒してしまうこともありません。 ## Kubernetesにないもの diff --git a/content/ja/docs/concepts/overview/working-with-objects/_index.md b/content/ja/docs/concepts/overview/working-with-objects/_index.md old mode 100755 new mode 100644 index d4a9f2e6b6..10da27655c --- a/content/ja/docs/concepts/overview/working-with-objects/_index.md +++ b/content/ja/docs/concepts/overview/working-with-objects/_index.md @@ -1,5 +1,8 @@ --- -title: "Kubernetesのオブジェクトについて" +title: "Kubernetesオブジェクトを利用する" weight: 40 +description: > + Kubernetesオブジェクトは、Kubernetes上で永続的なエンティティです。Kubernetesはこれらのエンティティを使い、クラスターの状態を表現します。 + Kubernetesオブジェクトモデルと、これらのオブジェクトの利用方法について学びます。 --- diff --git a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 9b3eeb7332..345cceacf5 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/ja/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -72,8 +72,7 @@ Kubernetesオブジェクトを`.yaml`ファイルに記載して作成する場 -* [Kubernetes API overview](/docs/reference/using-api/api-overview/)はこのページでは取り上げていない他のAPIについて説明します。 * 最も重要、かつ基本的なKubernetesオブジェクト群を学びましょう、例えば、[Pod](/ja/docs/concepts/workloads/pods/)です。 -* Kubernetesの[コントローラー](/docs/concepts/architecture/controller/)を学びましょう。 - +* Kubernetesの[コントローラー](/ja/docs/concepts/architecture/controller/)を学びましょう。 +* [Using the Kubernetes API](/docs/reference/using-api/)はこのページでは取り上げていない他のAPIについて説明します。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/labels.md b/content/ja/docs/concepts/overview/working-with-objects/labels.md index b6abcb974d..95d6dfc09f 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ja/docs/concepts/overview/working-with-objects/labels.md @@ -151,10 +151,11 @@ partition !partition ``` -最初の例では、キーが`environment`で、値が`production`か`qa`に等しいリソースを全て選択します。 -第2の例では、キーが`tier`で、値が`frontend`と`backend`以外のもの、そして`tier`キーを持たないリソースを全て選択します。 -第3の例では、`partition`というキーをもつラベルを全て選択し、値はチェックしません。 -第4の例では、`partition`というキーを持たないラベルを全て選択し、値はチェックしません。 +* 最初の例では、キーが`environment`で、値が`production`か`qa`に等しいリソースを全て選択します。 +* 第2の例では、キーが`tier`で、値が`frontend`と`backend`以外のもの、そして`tier`キーを持たないリソースを全て選択します。 +* 第3の例では、`partition`というキーをもつラベルを全て選択し、値はチェックしません。 +* 第4の例では、`partition`というキーを持たないラベルを全て選択し、値はチェックしません。 + 同様に、コンマセパレーターは、_AND_ オペレーターと同様にふるまいます。そのため、`partition`と`environment`キーの値がともに`qa`でないラベルを選択するには、`partition,environment notin (qa)`と記述することで可能です。 *集合ベース* のラベルセレクターは、`environment=production`という記述が`environment in (production)`と等しいため、一般的な等価形式となります。 `!=`と`notin`も同様に等価となります。 @@ -198,7 +199,7 @@ kubectl get pods -l 'environment,environment notin (frontend)' ``` ### APIオブジェクトに参照を設定する -[`Service`](/ja/docs/concepts/services-networking/service/) と [`ReplicationController`](/docs/concepts/workloads/controllers/replicationcontroller/)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクターを[Pod](/ja/docs/concepts/workloads/pods/pod/)のような他のリソースのセットを指定するのにも使われます。 +[`Service`](/ja/docs/concepts/services-networking/service/) と [`ReplicationController`](/docs/concepts/workloads/controllers/replicationcontroller/)のような、いくつかのKubernetesオブジェクトでは、ラベルセレクターを[Pod](/ja/docs/concepts/workloads/pods/)のような他のリソースのセットを指定するのにも使われます。 #### ServiceとReplicationController `Service`が対象とするPodの集合は、ラベルセレクターによって定義されます。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md index f9ebbabffd..dcf56c7959 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ja/docs/concepts/overview/working-with-objects/namespaces.md @@ -24,8 +24,6 @@ Namespaceは名前空間のスコープを提供します。リソース名は Namespaceは、複数のユーザーの間でクラスターリソースを分割する方法です。(これは[リソースクォータ](/docs/concepts/policy/resource-quotas/)を介して分割します。) -Kubernetesの将来的なバージョンにおいて、同一のNamespace内のオブジェクトは、デフォルトで同一のアクセスコントロールポリシーが適用されます。 - 同じアプリケーションの異なるバージョンなど、少し違うリソースをただ分割するだけに、複数のNamespaceを使う必要はありません。 同一のNamespace内でリソースを区別するためには[ラベル](/ja/docs/concepts/overview/working-with-objects/labels/)を使用してください。 diff --git a/content/ja/docs/concepts/overview/working-with-objects/object-management.md b/content/ja/docs/concepts/overview/working-with-objects/object-management.md index 49092c6dea..591a978360 100644 --- a/content/ja/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/ja/docs/concepts/overview/working-with-objects/object-management.md @@ -120,7 +120,7 @@ kubectl replace -f nginx.yaml ## 宣言型オブジェクト設定 宣言型オブジェクト設定を利用する場合、ユーザーはローカルに置かれている設定ファイルを操作します。 -しかし、ユーザーは操作内容をファイルに記載しません。作成、更新、そして削除といった操作はオブジェクトごとに`kubectl`が検出します。 +しかし、ユーザーはファイルに対する操作内容を指定しません。作成、更新、そして削除といった操作はオブジェクトごとに`kubectl`が検出します。 この仕組みが、異なるオブジェクトごとに異なる操作をディレクトリに対して行うことを可能にしています。 {{< note >}} diff --git a/content/ja/docs/concepts/policy/_index.md b/content/ja/docs/concepts/policy/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/concepts/policy/resource-quotas.md b/content/ja/docs/concepts/policy/resource-quotas.md index 7b00056fcf..cadcadf0ef 100644 --- a/content/ja/docs/concepts/policy/resource-quotas.md +++ b/content/ja/docs/concepts/policy/resource-quotas.md @@ -15,7 +15,7 @@ weight: 10 -`ResourceQuota`オブジェクトによって定義されるリソースクォータは、名前空間ごとの総リソース消費を制限するための制約を提供します。リソースクォータは同じ名前空間のクラスター内でタイプごとに作成できるオブジェクト数や、プロジェクト内のリソースによって消費されるコンピュートリソースの総量を制限できます。 +`ResourceQuota`オブジェクトによって定義されるリソースクォータは、名前空間ごとの総リソース消費を制限するための制約を提供します。リソースクォータは同じ名前空間のクラスター内でタイプごとに作成できるオブジェクト数や、名前空間内のリソースによって消費されるコンピュートリソースの総量を制限できます。 リソースクォータは下記のように働きます。 @@ -25,7 +25,7 @@ weight: 10 - リソースの作成や更新がクォータの制約に違反しているとき、そのリクエストはHTTPステータスコード`403 FORBIDDEN`で失敗し、違反した制約を説明するメッセージが表示されます。 - `cpu`や`memory`といったコンピューターリソースに対するクォータが名前空間内で有効になっているとき、ユーザーはそれらの値に対する`requests`や`limits`を設定する必要があります。設定しないとクォータシステムがPodの作成を拒否します。 ヒント: コンピュートリソースの要求を設定しないPodに対してデフォルト値を強制するために、`LimitRanger`アドミッションコントローラーを使用してください。この問題を解決する例は[walkthrough](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)で参照できます。 -`ResourceQuota`のオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります. +ResourceQuotaのオブジェクト名は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります. 名前空間とクォータを使用して作成できるポリシーの例は以下の通りです。 @@ -40,7 +40,7 @@ weight: 10 多くのKubernetesディストリビューションにおいてリソースクォータはデフォルトで有効になっています。APIサーバーで`--enable-admission-plugins=`の値に`ResourceQuota`が含まれるときに有効になります。 -特定の名前空間に`ResourceQuota`があるとき、そのリソースクォータはその名前空間に適用されます。 +特定の名前空間にResourceQuotaがあるとき、そのリソースクォータはその名前空間に適用されます。 ## リソースクォータの計算 @@ -55,6 +55,9 @@ weight: 10 | `limits.memory` | 停止していない状態の全てのPodで、メモリーの合計がこの値を超えることができません。 | | `requests.cpu` | 停止していない状態の全てのPodで、CPUリクエストの合計がこの値を超えることができません。 | | `requests.memory` | 停止していない状態の全てのPodで、メモリーリクエストの合計がこの値を超えることができません。 | +| `hugepages-` | 停止していない状態の全てのPodで, 指定されたサイズのHuge Pageリクエスト数がこの値を超えることができません。 | +| `cpu` | `requests.cpu`と同じ。 | +| `memory` | `requests.memory`と同じ。 | ### 拡張リソースのためのリソースクォータ @@ -79,8 +82,8 @@ GPUリソースを例にすると、もしリソース名が`nvidia.com/gpu`で | --------------------- | ----------------------------------------------------------- | | `requests.storage` | 全てのPersistentVolumeClaimにおいて、ストレージのリクエストの合計がこの値を超えないようにします。 | | `persistentvolumeclaims` | 特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 | -| `.storageclass.storage.k8s.io/requests.storage` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、ストレージリクエストの合計がこの値を超えないようにします。 | -| `.storageclass.storage.k8s.io/persistentvolumeclaims` | ストレージクラス名に関連する全てのPersistentVolumeClaimにおいて、特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 | +| `.storageclass.storage.k8s.io/requests.storage` | ストレージクラス名``に関連する全てのPersistentVolumeClaimにおいて、ストレージリクエストの合計がこの値を超えないようにします。 | +| `.storageclass.storage.k8s.io/persistentvolumeclaims` | ストレージクラス名``に関連する全てのPersistentVolumeClaimにおいて、特定の名前空間内で作成可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 | 例えば、もし管理者が`gold`ストレージクラスを`bronze`ストレージクラスと分けてリソースクォータを設定するとき、管理者はリソースクォータを下記のように指定できます。 @@ -93,12 +96,14 @@ Kubernetes v1.8において、ローカルのエフェメラルストレージ | ------------------------------- |----------------------------------------------------------- | | `requests.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリクエストの合計がこの値を超えないようにします。 | | `limits.ephemeral-storage` | 名前空間内の全てのPodで、ローカルのエフェメラルストレージのリミットの合計がこの値を超えないようにします。 | +| `ephemeral-storage` | `requests.ephemeral-storage`と同じ。 | ## オブジェクト数に対するクォータ -Kubernetes v1.9では下記のシンタックスを使用して、名前空間に紐づいた全ての標準リソースタイプに対するリソースクォータのサポートが追加されました。 +下記のシンタックスを使用して、名前空間に紐づいた全ての標準であるリソースタイプの中の特定のリソースの総数に対するリソースクォータを設定できます。 -* `count/.` +* `count/.` コアでないグループのリソース用 +* `count/` コアグループのリソース用 オブジェクト数に対するクォータでユーザーが設定するリソースの例は下記の通りです。 @@ -112,13 +117,12 @@ Kubernetes v1.9では下記のシンタックスを使用して、名前空間 * `count/statefulsets.apps` * `count/jobs.batch` * `count/cronjobs.batch` -* `count/deployments.extensions` -Kubernetes v1.15において、同一のシンタックスを使用して、カスタムリソースに対するサポートが追加されました。例えば、`example.com`というAPIグループ内の`widgets`というカスタムリソースのリソースクォータを設定するには`count/widgets.example.com`と記述します。 +カスタムリソースに対して同じシンタックスを使用できます。例えば、`example.com`というAPIグループ内の`widgets`というカスタムリソースのリソースクォータを設定するには`count/widgets.example.com`と記述します。 -`count/*`リソースクォータの使用において、オブジェクトがサーバーストレージに存在するときオブジェクトはクォータの計算対象となります。このようなタイプのリソースクォータはストレージリソース浪費の防止に有効です。例えば、もしSecretが大量に存在するとき、そのSecretリソースの総数に対してリソースクォータの制限をかけたい場合です。クラスター内でSecretが大量にあると、サーバーとコントローラーの起動を妨げることになります！また、適切に設定されていないCronJobが名前空間内で大量のJobを作成し、サービスが利用不可能になることを防ぐためにリソースクォータを設定できます。 +`count/*`リソースクォータの使用において、オブジェクトがサーバーストレージに存在するときオブジェクトはクォータの計算対象となります。このようなタイプのリソースクォータはストレージリソース浪費の防止に有効です。例えば、もしSecretが大量に存在するとき、そのSecretリソースの総数に対してリソースクォータの制限をかけたい場合です。クラスター内でSecretが大量にあると、サーバーとコントローラーの起動を妨げることになります。適切に設定されていないCronJobから保護するためにジョブのクォータを設定できます。名前空間内で大量のJobを作成するCronJobは、サービスを利用不可能にする可能性があります。 -Kubernetes v1.9より前のバージョンでは、限定されたリソースのセットにおいて汎用オブジェクトカウントのリソースクォータを実行可能でした。さらに、特定のリソースに対するリソースクォータを種類ごとに制限することができます。 +また、限定されたリソースのセットにおいて汎用オブジェクトカウントのリソースクォータを実行可能です。 下記のタイプのリソースがサポートされています。 @@ -128,7 +132,7 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース | `persistentvolumeclaims` | 名前空間内で存在可能な[PersistentVolumeClaim](/ja/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)の総数。 | | `pods` | 名前空間内で存在可能な停止していないPodの総数。`.status.phase in (Failed, Succeeded)`がtrueのとき、Podは停止状態にあります。 | | `replicationcontrollers` | 名前空間内で存在可能なReplicationControlerの総数。 | -| `resourcequotas` | 名前空間内で存在可能な[リソースクォータ](/docs/reference/access-authn-authz/admission-controllers/#resourcequota)の総数。 | +| `resourcequotas` | 名前空間内で存在可能なResourceQuotaの総数。 | | `services` | 名前空間内で存在可能なServiceの総数。 | | `services.loadbalancers` | 名前空間内で存在可能なtype:LoadBalancerであるServiceの総数。 | | `services.nodeports` | 名前空間内で存在可能なtype:NodePortであるServiceの総数。 | @@ -138,7 +142,7 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース ## クォータのスコープについて -各リソースクォータには関連するスコープのセットを関連づけることができます。クォータは、列挙されたスコープの共通部分と一致する場合にのみリソースの使用量を計測します。 +各リソースクォータには関連する`scope`のセットを関連づけることができます。クォータは、列挙されたscopeの共通部分と一致する場合にのみリソースの使用量を計測します。 スコープがクォータに追加されると、サポートするリソースの数がスコープに関連するリソースに制限されます。許可されたセット以外のクォータ上でリソースを指定するとバリデーションエラーになります。 @@ -148,27 +152,72 @@ Kubernetes v1.9より前のバージョンでは、限定されたリソース | `NotTerminating` | `.spec.activeDeadlineSecondsがnil`であるPodに一致します。 | | `BestEffort` | ベストエフォート型のサービス品質のPodに一致します。 | | `NotBestEffort` | ベストエフォート型のサービス品質でないPodに一致します。 | +| `PriorityClass` | 指定された[優先度クラス](/docs/concepts/configuration/pod-priority-preemption)と関連付いているPodに一致します。 | -`BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します: `pods` +`BestEffort`スコープはリソースクォータを次のリソースに対するトラッキングのみに制限します: -`Terminating`、`NotTerminating`、`NotBestEffort`スコープは、リソースクォータを次のリソースに対するトラッキングのみに制限します: - -* `cpu` -* `limits.cpu` -* `limits.memory` -* `memory` * `pods` + +`Terminating`、`NotTerminating`、`NotBestEffort`、`PriorityClass`スコープは、リソースクォータを次のリソースに対するトラッキングのみに制限します: + +* `pods` +* `cpu` +* `memory` * `requests.cpu` * `requests.memory` +* `limits.cpu` +* `limits.memory` + +同じクォータで`Terminating`と`NotTerminating`の両方のスコープを指定することはできず、また同じクォータで`BestEffort`と`NotBestEffort`の両方のスコープを指定することもできないことに注意してください。 + +`scopeSelector`は`operator` フィールドにおいて下記の値をサポートしています。: + +* `In` +* `NotIn` +* `Exists` +* `DoesNotExist` + +`scopeSelector`の定義において`scopeName`に下記のいずれかの値を使用する場合、`operator`に`Exists`を指定してください。 + +* `Terminating` +* `NotTerminating` +* `BestEffort` +* `NotBestEffort` + +`operator`が`In`または`NotIn`の場合、`values`フィールドには少なくとも1つの値が必要です。例えば以下のように記述します： + +```yaml + scopeSelector: + matchExpressions: + - scopeName: PriorityClass + operator: In + values: + - middle +``` + +`operator`が`Exists`または`DoesNotExist`の場合、`values`フィールドは指定*しないでください*。 ### PriorityClass毎のリソースクォータ -{{< feature-state for_k8s_version="v1.12" state="beta" >}} +{{< feature-state for_k8s_version="v1.17" state="stable" >}} Podは特定の[優先度](/docs/concepts/configuration/pod-priority-preemption/#pod-priority)で作成されます。リソースクォータのSpec内にある`scopeSelector`フィールドを使用して、Podの優先度に基づいてPodのシステムリソースの消費をコントロールできます。 リソースクォータのSpec内の`scopeSelector`によってPodが選択されたときのみ、そのリソースクォータが一致し、消費されます。 +リソースクォータが`scopeSelector`フィールドを使用して優先度クラスに対してスコープされる場合、リソースクォータのオプジェクトは、次のリソースのみトラッキングするように制限されます: + +* `pods` +* `cpu` +* `memory` +* `ephemeral-storage` +* `limits.cpu` +* `limits.memory` +* `limits.ephemeral-storage` +* `requests.cpu` +* `requests.memory` +* `requests.ephemeral-storage` + この例ではリソースクォータのオブジェクトを作成し、特定の優先度を持つPodに一致させます。この例は下記のように動作します。 - クラスター内のPodは"low"、"medium"、"high"の3つの優先度クラスのうち1つをもちます。 @@ -230,7 +279,7 @@ items: kubectl create -f ./quota.yml ``` -```shell +``` resourcequota/pods-high created resourcequota/pods-medium created resourcequota/pods-low created @@ -242,7 +291,7 @@ resourcequota/pods-low created kubectl describe quota ``` -```shell +``` Name: pods-high Namespace: default Resource Used Hard @@ -305,7 +354,7 @@ kubectl create -f ./high-priority-pod.yml kubectl describe quota ``` -```shell +``` Name: pods-high Namespace: default Resource Used Hard @@ -333,13 +382,6 @@ memory 0 20Gi pods 0 10 ``` -`scopeSelector`は`operator`フィールドにおいて下記の値をサポートしています。 - -* `In` -* `NotIn` -* `Exist` -* `DoesNotExist` - ## リクエスト vs リミット コンピュートリソースを分配する際に、各コンテナはCPUとメモリーそれぞれのリクエストとリミット値を指定します。クォータはそれぞれの値を設定できます。 @@ -400,7 +442,7 @@ kubectl create -f ./object-counts.yaml --namespace=myspace kubectl get quota --namespace=myspace ``` -```shell +``` NAME AGE compute-resources 30s object-counts 32s @@ -410,7 +452,7 @@ object-counts 32s kubectl describe quota compute-resources --namespace=myspace ``` -```shell +``` Name: compute-resources Namespace: myspace Resource Used Hard @@ -426,7 +468,7 @@ requests.nvidia.com/gpu 0 4 kubectl describe quota object-counts --namespace=myspace ``` -```shell +``` Name: object-counts Namespace: myspace Resource Used Hard @@ -447,53 +489,50 @@ kubectl create namespace myspace ``` ```shell -kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace +kubectl create quota test --hard=count/deployments.apps=2,count/replicasets.apps=4,count/pods=3,count/secrets=4 --namespace=myspace ``` ```shell -kubectl create deployment nginx --image=nginx --namespace=myspace -kubectl scale deployment nginx --replicas=2 --namespace=myspace +kubectl create deployment nginx --image=nginx --namespace=myspace --replicas=2 ``` ```shell kubectl describe quota --namespace=myspace ``` -```shell +``` Name: test Namespace: myspace Resource Used Hard -------- ---- ---- -count/deployments.extensions 1 2 +count/deployments.apps 1 2 count/pods 2 3 -count/replicasets.extensions 1 4 +count/replicasets.apps 1 4 count/secrets 1 4 ``` ## クォータとクラスター容量 -`ResourceQuotas`はクラスター容量に依存しません。またユニット数の絶対値で表されます。そのためクラスターにノードを追加したことにより、各名前空間が自動的により多くのリソースを消費するような機能が提供されるわけでは*ありません*。 +ResourceQuotaはクラスター容量に依存しません。またユニット数の絶対値で表されます。そのためクラスターにノードを追加したことにより、各名前空間が自動的により多くのリソースを消費するような機能が提供されるわけでは*ありません*。 下記のようなより複雑なポリシーが必要な状況があります。 - - 複数チーム間でクラスターリソースの総量を分けあう。 - - 各テナントが必要な時にリソース使用量を増やせるようにするが、偶発的なリソースの枯渇を防ぐために上限を設定する。 - - 1つの名前空間に対してリソース消費の需要を検出し、ノードを追加し、クォータを増加させる。 +- 複数チーム間でクラスターリソースの総量を分けあう。 +- 各テナントが必要な時にリソース使用量を増やせるようにするが、偶発的なリソースの枯渇を防ぐために上限を設定する。 +- 1つの名前空間に対してリソース消費の需要を検出し、ノードを追加し、クォータを増加させる。 -このようなポリシーは、クォータの使用量の監視と、他のシグナルにしたがってクォータのハードの制限を調整する"コントローラー"を記述することにより、`ResourceQuotas`をビルディングブロックのように使用して実装できます。 +このようなポリシーは、クォータの使用量の監視と、他のシグナルにしたがってクォータのハードの制限を調整する"コントローラー"を記述することにより、ResourceQuotaをビルディングブロックのように使用して実装できます。 リソースクォータは集約されたクラスターリソースを分割しますが、ノードに対しては何の制限も行わないことに注意して下さい。例: 複数の名前空間のPodは同一のノード上で稼働する可能性があります。 -## デフォルトで優先度クラスの消費を制限する +## デフォルトで優先度クラスの消費を制限する {#limit-priority-class-consumption-by-default} 例えば"cluster-services"のように、条件に一致するクォータオブジェクトが存在する場合に限り、特定の優先度のPodを名前空間で許可することが望ましい場合があります。 このメカニズムにより、オペレーターは特定の高優先度クラスの使用を限られた数の名前空間に制限することができ、全ての名前空間でこれらの優先度クラスをデフォルトで使用することはできなくなります。 -これを実施するには、kube-apiserverの`--admission-control-config-file`というフラグを使い、下記の設定ファイルに対してパスを渡す必要がります。 +これを実施するには、`kube-apiserver`の`--admission-control-config-file`というフラグを使い、下記の設定ファイルに対してパスを渡す必要がります。 -{{< tabs name="example1" >}} -{{% tab name="apiserver.config.k8s.io/v1" %}} ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration @@ -509,27 +548,6 @@ plugins: operator: In values: ["cluster-services"] ``` -{{% /tab %}} -{{% tab name="apiserver.k8s.io/v1alpha1" %}} -```yaml -# v1.17では非推奨になり、apiserver.config.k8s.io/v1の使用を推奨します。 -apiVersion: apiserver.k8s.io/v1alpha1 -kind: AdmissionConfiguration -plugins: -- name: "ResourceQuota" - configuration: - # v1.17では非推奨になり、apiserver.config.k8s.io/v1、ResourceQuotaConfigurationの使用を推奨します。 - apiVersion: resourcequota.admission.k8s.io/v1beta1 - kind: Configuration - limitedResources: - - resource: pods - matchScopes: - - scopeName: PriorityClass - operator: In - values: ["cluster-services"] -``` -{{% /tab %}} -{{< /tabs >}} なお、"cluster-services"Podは、条件に一致する`scopeSelector`を持つクォータオブジェクトが存在する名前空間でのみ許可されます。 @@ -541,14 +559,9 @@ plugins: values: ["cluster-services"] ``` -さらなる情報は、[LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)と[優先度クラスに対するクォータサポートの design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)を参照してください。 - -## 例 - -[リソースクォータの使用方法の例](/docs/tasks/administer-cluster/quota-api-object/)を参照してください。 - - ## {{% heading "whatsnext" %}} - さらなる情報は[クォータの design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md)を参照してください。 - +- [リソースクォータの使用方法の例](/docs/tasks/administer-cluster/quota-api-object/)を参照してください。 +- [優先度クラスに対するクォータサポートの design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)を参照してください。 +- [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765)を参照してください。 diff --git a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md index 18b767cbb4..6bc7af0dab 100644 --- a/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ja/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -66,17 +66,7 @@ nodeSelectorを以下のように追加します: ## 補足: ビルトインNodeラベル {#built-in-node-labels} 明示的に[付与](#step-one-attach-label-to-the-node)するラベルの他に、事前にNodeへ付与されているものもあります。 -以下のようなラベルが該当します。 - -* [`kubernetes.io/hostname`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-hostname) -* [`failure-domain.beta.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesiozone) -* [`failure-domain.beta.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#failure-domainbetakubernetesioregion) -* [`topology.kubernetes.io/zone`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) -* [`topology.kubernetes.io/region`](/docs/reference/kubernetes-api/labels-annotations-taints/#topologykubernetesiozone) -* [`beta.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#beta-kubernetes-io-instance-type) -* [`node.kubernetes.io/instance-type`](/docs/reference/kubernetes-api/labels-annotations-taints/#nodekubernetesioinstance-type) -* [`kubernetes.io/os`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-os) -* [`kubernetes.io/arch`](/docs/reference/kubernetes-api/labels-annotations-taints/#kubernetes-io-arch) +これらのラベルのリストは、[Well-Known Labels, Annotations and Taints](/docs/reference/kubernetes-api/labels-annotations-taints/)を参照してください。 {{< note >}} これらのラベルは、クラウドプロバイダー固有であり、確実なものではありません。 @@ -93,7 +83,7 @@ Nodeにラベルを付与することで、Podは特定のNodeやNodeグルー `NodeRestriction`プラグインは、kubeletが`node-restriction.kubernetes.io/`プレフィックスを有するラベルの設定や上書きを防ぎます。 Nodeの隔離にラベルのプレフィックスを使用するためには、以下のようにします。 -1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が_有効_になっていること。 +1. [Node authorizer](/docs/reference/access-authn-authz/node/)を使用していることと、[NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)が _有効_ になっていること。 2. Nodeに`node-restriction.kubernetes.io/` プレフィックスのラベルを付与し、そのラベルがnode selectorに指定されていること。 例えば、`example.com.node-restriction.kubernetes.io/fips=true` または `example.com.node-restriction.kubernetes.io/pci-dss=true`のようなラベルです。 diff --git a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md index 861e528cd9..cbd833ba3d 100644 --- a/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ja/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -26,11 +26,11 @@ kube-schedulerは、もし希望するのであれば自分自身でスケジュ kube-schedulerは、新規に作成された各Podや他のスケジューリングされていないPodを稼働させるために最適なNodeを選択します。 しかし、Pod内の各コンテナにはそれぞれ異なるリソースの要件があり、各Pod自体にもそれぞれ異なる要件があります。そのため、既存のNodeは特定のスケジューリング要求によってフィルターされる必要があります。 -クラスター内でPodに対する割り当て要求を満たしたNodeは_割り当て可能_ なNodeと呼ばれます。 +クラスター内でPodに対する割り当て要求を満たしたNodeは _割り当て可能_ なNodeと呼ばれます。 もし適切なNodeが一つもない場合、スケジューラーがNodeを割り当てることができるまで、そのPodはスケジュールされずに残ります。 スケジューラーはPodに対する割り当て可能なNodeをみつけ、それらの割り当て可能なNodeにスコアをつけます。その中から最も高いスコアのNodeを選択し、Podに割り当てるためのいくつかの関数を実行します。 -スケジューラーは_binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったNodeの情報を通知します。 +スケジューラーは _binding_ と呼ばれる処理中において、APIサーバーに対して割り当てが決まったNodeの情報を通知します。 スケジューリングを決定する上で考慮が必要な要素としては、個別または複数のリソース要求や、ハードウェア/ソフトウェアのポリシー制約、affinityやanti-affinityの設定、データの局所性や、ワークロード間での干渉などが挙げられます。 @@ -50,65 +50,10 @@ _スコアリング_ ステップでは、Podを割り当てるのに最も適 最後に、kube-schedulerは最も高いランクのNodeに対してPodを割り当てます。もし同一のスコアのNodeが複数ある場合は、kube-schedulerがランダムに1つ選択します。 -### デフォルトのポリシーについて +スケジューラーのフィルタリングとスコアリングの動作に関する設定には2つのサポートされた手法があります。 -kube-schedulerは、デフォルトで用意されているスケジューリングポリシーのセットを持っています。 - -### フィルタリング - -- `PodFitsHostPorts`: Nodeに、Podが要求するポートが利用可能かどうかをチェックします。 - -- `PodFitsHost`: Podがそのホスト名において特定のNodeを指定しているかをチェックします。 - -- `PodFitsResources`: Nodeに、Podが要求するリソース(例: CPUとメモリー)が利用可能かどうかをチェックします。 - -- `PodMatchNodeSelector`: PodのNodeSelectorが、Nodeのラベルにマッチするかどうかをチェックします。 - -- `NoVolumeZoneConflict`: Podが要求するVolumeがNode上で利用可能かを、障害が発生しているゾーンを考慮して評価します。 - -- `NoDiskConflict`: NodeのVolumeがPodの要求を満たし、すでにマウントされているかどうかを評価します。 - -- `MaxCSIVolumeCount`: CSI Volumeをいくつ割り当てるべきか決定し、それが設定された上限を超えるかどうかを評価します。 - -- `CheckNodeMemoryPressure`: もしNodeがメモリーの容量が逼迫している場合、また設定された例外がない場合はそのPodはそのNodeにスケジュールされません。 - -- `CheckNodePIDPressure`: もしNodeのプロセスIDが枯渇しそうになっていた場合や、設定された例外がない場合はそのPodはそのNodeにスケジュールされません。 - -- `CheckNodeDiskPressure`: もしNodeのストレージが逼迫している場合(ファイルシステムの残り容量がほぼない場合)や、設定された例外がない場合はそのPodはそのNodeにスケジュールされません。 - -- `CheckNodeCondition`: Nodeは、ファイルシステムの空き容量が完全になくなった場合、ネットワークが利用不可な場合、kubeletがPodを稼働させる準備をできていない場合などに、その状況を通知できます。Nodeがこの状況下かつ設定された例外がない場合、Podは該当のNodeにスケジュールされません。 - -- `PodToleratesNodeTaints`: PodのTolerationがNodeのTaintを許容できるかチェックします。 - -- `CheckVolumeBinding`: Podが要求するVolumeの要求を満たすか評価します。これはPersistentVolumeClaimがバインドされているかに関わらず適用されます。 - -### スコアリング - -- `SelectorSpreadPriority`:　同一のService、StatefulSetや、ReplicaSetに属するPodを複数のホストをまたいで稼働させます。 - -- `InterPodAffinityPriority`: weightedPodAffinityTermの要素をイテレートして合計を計算したり、もし一致するPodAffinityTermがNodeに適合している場合は、"重み"を合計値に足したりします。:最も高い合計値を持つNode(複数もあり)が候補となります。 - -- `LeastRequestedPriority`: 要求されたリソースがより低いNodeを優先するものです。言い換えると、Nodeに多くのPodが稼働しているほど、Podが使用するリソースが多くなり、その要求量が低いNodeが選択されます。 - -- `MostRequestedPriority`: 要求されたリソースがより多いNodeを優先するものです。このポリシーは、ワークロードの全体セットを実行するために必要な最小数のNodeに対して、スケジュールされたPodを適合させます。　 - -- `RequestedToCapacityRatioPriority`: デフォルトのリソーススコアリング関数を使用して、requestedToCapacityベースのResourceAllocationPriorityを作成します。 - -- `BalancedResourceAllocation`: バランスのとれたリソース使用量になるようにNodeを選択します。 - -- `NodePreferAvoidPodsPriority`: Nodeの`scheduler.alpha.kubernetes.io/preferAvoidPods`というアノテーションに基づいてNodeの優先順位づけをします。この設定により、2つの異なるPodが同じNode上で実行しないことを示唆できます。 - -- `NodeAffinityPriority`: "PreferredDuringSchedulingIgnoredDuringExecution"の値によって示されたNode Affinityのスケジューリング性向に基づいてNodeの優先順位づけを行います。詳細は[NodeへのPodの割り当て](https://kubernetes.io/ja/docs/concepts/scheduling-eviction/assign-pod-node/)にて確認できます。 - -- `TaintTolerationPriority`: Node上における許容できないTaintsの数に基づいて、全てのNodeの優先順位リストを準備します。このポリシーでは優先順位リストを考慮してNodeのランクを調整します。 - -- `ImageLocalityPriority`: すでにPodに対するコンテナイメージをローカルにキャッシュしているNodeを優先します。 - -- `ServiceSpreadingPriority`: このポリシーの目的は、特定のServiceに対するバックエンドのPodが、それぞれ異なるNodeで実行されるようにすることです。このポリシーではServiceのバックエンドのPodがすでに実行されていないNode上にスケジュールするように優先します。これによる結果として、Serviceは単体のNode障害に対してより耐障害性が高まります。 - -- `CalculateAntiAffinityPriorityMap`: このポリシーは[PodのAnti-Affinity](/ja/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)の実装に役立ちます。 - -- `EqualPriorityMap`: 全てのNodeに対して等しい重みを与えます。 +1. [スケジューリングポリシー](/docs/reference/scheduling/policies) は、フィルタリングのための _Predicates_ とスコアリングのための _Priorities_ の設定することができます。 +1. [スケジューリングプロファイル](/docs/reference/scheduling/config/#profiles)は、`QueueSort`、 `Filter`、 `Score`、 `Bind`、 `Reserve`、 `Permit`やその他を含む異なるスケジューリングの段階を実装するプラグインを設定することができます。kube-schedulerを異なるプロファイルを実行するように設定することもできます。 ## {{% heading "whatsnext" %}} @@ -118,4 +63,8 @@ kube-schedulerは、デフォルトで用意されているスケジューリン * kube-schedulerの[リファレンスドキュメント](/docs/reference/command-line-tools-reference/kube-scheduler/)を参照してください。 * [複数のスケジューラーの設定](/docs/tasks/administer-cluster/configure-multiple-schedulers/)について学んでください。 * [トポロジーの管理ポリシー](/docs/tasks/administer-cluster/topology-manager/)について学んでください。 -* [Podのオーバーヘッド](/docs/concepts/configuration/pod-overhead/)について学んでください。 +* [Podのオーバーヘッド](/docs/concepts/scheduling-eviction/pod-overhead/)について学んでください。 +* ボリュームを使用するPodのスケジューリングについて以下で学んでください。 + * [Volume Topology Support](/docs/concepts/storage/storage-classes/#volume-binding-mode) + * [ストレージ容量の追跡](/ja//docs/concepts/storage/storage-capacity/) + * [Node-specific Volume Limits](/docs/concepts/storage/storage-limits/) diff --git a/content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 7adfe28827..3457132bd1 100644 --- a/content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/ja/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -1,7 +1,7 @@ --- title: スケジューラーのパフォーマンスチューニング content_type: concept -weight: 70 +weight: 80 --- @@ -15,12 +15,44 @@ weight: 70 このページでは、大規模のKubernetesクラスターにおけるパフォーマンス最適化のためのチューニングについて説明します。 - -## スコア付けするノードの割合 +大規模クラスターでは、レイテンシー(新規Podをすばやく配置)と精度(スケジューラーが不適切な配置を行うことはめったにありません)の間でスケジューリング結果を調整するスケジューラーの動作をチューニングできます。 -Kubernetes 1.12以前では、Kube-schedulerがクラスター内の全てのノードに対して割り当て可能かをチェックし、実際に割り当て可能なノードのスコア付けをしていました。Kubernetes 1.12では新機能を追加し、ある数の割り当て可能なノードが見つかった時点で、割り当て可能なノードの探索を止めれるようになりました。これにより大規模なクラスターにおけるスケジューラーのパフォーマンスが向上しました。その数はクラスターのサイズの割合(%)として指定されます。この割合は`percentageOfNodesToScore`というオプションの設定項目によって指定可能です。この値の範囲は1から100までです。100より大きい値は100%として扱われます。0を指定したときは、この設定オプションを指定しないものとして扱われます。Kubernetes 1.14では、この値が指定されていないときは、スコア付けするノードの割合をクラスターのサイズに基づいて決定するためのメカニズムがあります。このメカニズムでは100ノードのクラスターに対しては50%の割合とするような線形な式を使用します。5000ノードのクラスターに対しては10%となります。自動で算出される割合の最低値は5%となります。言い換えると、クラスターの規模がどれだけ大きくても、ユーザーがこの値を5未満に設定しない限りスケジューラーは少なくても5%のクラスター内のノードをスコア付けすることになります。 +このチューニング設定は、kube-scheduler設定の`percentageOfNodesToScore`で設定できます。KubeSchedulerConfiguration設定は、クラスター内のノードにスケジュールするための閾値を決定します。 + +### 閾値の設定 + +`percentageOfNodesToScore`オプションは、0から100までの数値を受け入れます。0は、kube-schedulerがコンパイル済みのデフォルトを使用することを示す特別な値です。 +`percentageOfNodesToScore`に100より大きな値を設定した場合、kube-schedulerの挙動は100を設定した場合と同様となります。 + +この値を変更するためには、kube-schedulerの設定ファイル(これは`/etc/kubernetes/config/kube-scheduler.yaml`の可能性が高い)を編集し、スケジューラーを再起動します。 + +この変更をした後、 + +```bash +kubectl get pods -n kube-system | grep kube-scheduler +``` + +を実行して、kube-schedulerコンポーネントが正常であることを確認できます。 + +## ノードへのスコア付けの閾値 {#percentage-of-nodes-to-score} + +スケジューリング性能を改善するため、kube-schedulerは割り当て可能なノードが十分に見つかるとノードの検索を停止できます。大規模クラスターでは、すべてのノードを考慮する単純なアプローチと比較して時間を節約できます。 + +クラスター内のすべてのノードに対する十分なノード数を整数パーセンテージで指定します。kube-schedulerは、これをノード数に変換します。スケジューリング中に、kube-schedulerが設定されたパーセンテージを超える十分な割り当て可能なノードを見つけた場合、kube-schedulerはこれ以上割り当て可能なノードを探すのを止め、[スコアリングフェーズ](/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)に進みます。 + +[スケジューラーはどのようにノードを探索するか](#how-the-scheduler-iterates-over-nodes)で処理を詳しく説明しています。 + +### デフォルトの閾値 + +閾値を指定しない場合、Kubernetesは100ノードのクラスタでは50%、5000ノードのクラスタでは10%になる線形方程式を使用して数値を計算します。自動計算の下限は5%です。 + +つまり、明示的に`percentageOfNodesToScore`を5未満の値を設定しない限り、クラスターの規模に関係なく、kube-schedulerは常に少なくともクラスターの5%のノードに対してスコア付けをします。 + +スケジューラーにクラスター内のすべてのノードに対してスコア付けをさせる場合は、`percentageOfNodesToScore`の値に100を設定します。 + +## 例 `percentageOfNodesToScore`の値を50%に設定する例は下記のとおりです。 @@ -35,22 +67,23 @@ algorithmSource: percentageOfNodesToScore: 50 ``` +## percentageOfNodesToScoreのチューニング + +`percentageOfNodesToScore`は1から100の間の範囲である必要があり、デフォルト値はクラスターのサイズに基づいて計算されます。また、クラスターのサイズの最小値は50ノードとハードコードされています。 + {{< note >}} -割り当て可能なノードが50未満のクラスターにおいては、割り当て可能なノードの探索を止めるほどノードが多くないため、スケジューラーは全てのノードをチェックします。 +割り当て可能なノードが50以下のクラスタでは、スケジューラの検索を早期に停止するのに十分な割り当て可能なノードがないため、スケジューラはすべてのノードをチェックします。 + +小規模クラスタでは、`percentageOfNodesToScore`に低い値を設定したとしても、同様の理由で変更による影響は全くないか、ほとんどありません。 + +クラスターのノード数が数百以下の場合は、この設定オプションをデフォルト値のままにします。変更してもスケジューラの性能を大幅に改善する可能性はほとんどありません。 {{< /note >}} -**この機能を無効にするためには**、`percentageOfNodesToScore`を100に設定してください。 +この値を設定する際に考慮するべき重要な注意事項として、割り当て可能ノードのチェック対象のノードが少ないと、一部のノードはPodの割り当てのためにスコアリングされなくなります。結果として、高いスコアをつけられる可能性のあるノードがスコアリングフェーズに渡されることがありません。これにより、Podの配置が理想的なものでなくなります。 +kube-schedulerが頻繁に不適切なPodの配置を行わないよう、`percentageOfNodesToScore`をかなり低い値を設定することは避けるべきです。スケジューラのスループットがアプリケーションにとって致命的で、ノードのスコアリングが重要でない場合を除いて、10%未満に設定することは避けてください。言いかえると、割り当て可能な限り、Podは任意のノード上で稼働させるのが好ましいです。 -### percentageOfNodesToScoreのチューニング - -`percentageOfNodesToScore`は1から100の間の範囲である必要があり、デフォルト値はクラスターのサイズに基づいて計算されます。また、クラスターのサイズの最小値は50ノードとハードコードされています。これは数百のノードを持つようなクラスターにおいてこの値を50より低い値に変更しても、スケジューラーが検出する割り当て可能なノードの数に大きな影響を与えないことを意味します。このオプションは意図的なものです。その理由としては、小規模のクラスターにおいてパフォーマンスを著しく改善する可能性が低いためです。1000ノードを超える大規模なクラスターでこの値を低く設定すると、パフォーマンスが著しく改善される可能性があります。 - -この値を設定する際に考慮するべき重要な注意事項として、割り当て可能ノードのチェック対象のノードが少ないと、一部のノードはPodの割り当てのためにスコアリングされなくなります。結果として、高いスコアをつけられる可能性のあるノードがスコアリングフェーズに渡されることがありません。これにより、Podの配置が理想的なものでなくなります。したがって、この値をかなり低い割合に設定すべきではありません。一般的な経験則として、この値を10未満に設定しないことです。スケジューラーのスループットがアプリケーションにとって致命的で、ノードのスコアリングが重要でないときのみ、この値を低く設定するべきです。言いかえると、割り当て可能な限り、Podは任意のノード上で稼働させるのが好ましいです。 - -クラスターが数百のノードを持つ場合やそれに満たない場合でも、この設定オプションのデフォルト値を低くするのを推奨しません。デフォルト値を低くしてもスケジューラーのパフォーマンスを大幅に改善することはありません。 - -### スケジューラーはどのようにノードを探索するか +## スケジューラーはどのようにノードを探索するか {#how-the-scheduler-iterates-over-nodes} このセクションでは、この機能の内部の詳細を理解したい人向けになります。 diff --git a/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md index ba9d37d2ea..e24b960924 100644 --- a/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ja/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -22,30 +22,30 @@ Nodeにtaintを付与するには[kubectl taint](/docs/reference/generated/kubec 例えば、次のコマンドは ```shell -kubectl taint nodes node1 key=value:NoSchedule +kubectl taint nodes node1 key1=value1:NoSchedule ``` -`node1`にtaintを設定します。このtaintのキーは`key`、値は`value`、taintの効果は`NoSchedule`です。 +`node1`にtaintを設定します。このtaintのキーは`key1`、値は`value1`、taintの効果は`NoSchedule`です。 これは`node1`にはPodに合致するtolerationがなければスケジューリングされないことを意味します。 上記のコマンドで付与したtaintを外すには、下記のコマンドを使います。 ```shell -kubectl taint nodes node1 key:NoSchedule- +kubectl taint nodes node1 key1=value1:NoSchedule- ``` PodのtolerationはPodSpecの中に指定します。下記のtolerationはどちらも、上記の`kubectl taint`コマンドで追加したtaintと合致するため、どちらのtolerationが設定されたPodも`node1`へスケジューリングされることができます。 ```yaml tolerations: -- key: "key" +- key: "key1" operator: "Equal" - value: "value" + value: "value1" effect: "NoSchedule" ``` ```yaml tolerations: -- key: "key" +- key: "key1" operator: "Exists" effect: "NoSchedule" ``` @@ -67,7 +67,7 @@ tolerationがtaintと合致するのは、`key`と`effect`が同一であり、 空の`key`と演算子`Exists`は全ての`key`、`value`、`effect`と一致するため、すべてのtaintと合致します。 -空の`effect`は`key`が一致する全てのeffectと合致します。 +空の`effect`は`key1`が一致する全てのeffectと合致します。 {{< /note >}} diff --git a/content/ja/docs/concepts/security/overview.md b/content/ja/docs/concepts/security/overview.md index 0157b28f78..ca9505a6dd 100644 --- a/content/ja/docs/concepts/security/overview.md +++ b/content/ja/docs/concepts/security/overview.md @@ -82,12 +82,12 @@ Kubernetesを保護する為には２つの懸念事項があります。 ワークロードセキュリティに関する懸念事項 | 推奨事項 | ------------------------------ | --------------------- | -RBAC認可(Kubernetes APIへのアクセス) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/ -認証 | https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/ | +RBAC認可(Kubernetes APIへのアクセス) | https://kubernetes.io/ja/docs/reference/access-authn-authz/rbac/ +認証 | https://kubernetes.io/docs/concepts/security/controlling-access/ | アプリケーションのSecret管理(およびetcdへの保存時に暗号化) | https://kubernetes.io/ja/docs/concepts/configuration/secret/
    https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ | PodSecurityPolicy | https://kubernetes.io/docs/concepts/policy/pod-security-policy/ | Quality of Service (およびクラスターリソース管理) | https://kubernetes.io/ja/docs/tasks/configure-pod-container/quality-service-pod/ | -NetworkPolicy | https://kubernetes.io/docs/concepts/services-networking/network-policies/ | +NetworkPolicy | https://kubernetes.io/ja/docs/concepts/services-networking/network-policies/ | Kubernetes IngressのTLS | https://kubernetes.io/ja/docs/concepts/services-networking/ingress/#tls | @@ -123,10 +123,10 @@ TLS経由のアクセスのみ | コードがTCP通信を必要とする場合 関連するKubernetesセキュリティについて学びます。 -* [Podのセキュリティ基準](/docs/concepts/security/pod-security-standards/) -* [PodのNetworkPolicy](/docs/concepts/services-networking/network-policies/) +* [Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards/) +* [Podのネットワークポリシー]](/ja/docs/concepts/services-networking/network-policies/) +* [Kubernetes APIへのアクセスを制御する](/docs/concepts/security/controlling-access) * [クラスターの保護](/docs/tasks/administer-cluster/securing-a-cluster/) -* [APIアクセスコントロール](/docs/reference/access-authn-authz/controlling-access/) * コントロールプレーンとの[通信時のデータ暗号化](/docs/tasks/tls/managing-tls-in-a-cluster/) * [保存時のデータ暗号化](/docs/tasks/administer-cluster/encrypt-data/) * [Kubernetes Secret](/ja/docs/concepts/configuration/secret/) diff --git a/content/ja/docs/concepts/services-networking/_index.md b/content/ja/docs/concepts/services-networking/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/concepts/services-networking/dns-pod-service.md b/content/ja/docs/concepts/services-networking/dns-pod-service.md index 4375928a45..bd679a7039 100644 --- a/content/ja/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ja/docs/concepts/services-networking/dns-pod-service.md @@ -122,6 +122,29 @@ spec: A(AAAA)レコードはPodの名前に対して作成されないため、`hostname`はPodのA(AAAA)レコードが作成されるために必須となります。`hostname`を持たないが`subdomain`を持つようなPodは、そのPodのIPアドレスを指し示すHeadless Service(`default-subdomain.my-namespace.svc.cluster.local`)に対するA(AAAA)レコードのみ作成します。 {{< /note >}} +### PodのsetHostnameAsFQDNフィールド + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +**前提条件**: {{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}に対して`SetHostnameAsFQDN`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。 + +Podが完全修飾ドメイン名(FQDN)を持つように構成されている場合、そのホスト名は短いホスト名です。 +例えば、FQDNが`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`のPodがある場合、 +デフォルトではそのPod内の`hostname`コマンドは`busybox-1`を返し、`hostname --fqdn`コマンドはFQDNを返します。 + +Podのspecで`setHostnameAsFQDN: true`を設定した場合、そのPodの名前空間に対してkubeletはPodのFQDNをホスト名に書き込みます。 +この場合、`hostname`と`hostname --fqdn`の両方がPodのFQDNを返します。 + +{{< note >}} +Linuxでは、カーネルのホスト名のフィールド(`struct utsname`の`nodename`フィールド)は64文字に制限されています。 + +Podがこの機能を有効にしていて、そのFQDNが64文字より長い場合、Podは起動に失敗します。 +Podは`Pending`ステータス(`kubectl`でみられる`ContainerCreating`)のままになり、「Podのホスト名とクラスタードメインからFQDNを作成できなかった」や、「FQDN`long-FQDN`が長すぎる(64文字が最大, 70文字が要求された)」などのエラーイベントが生成されます。 + +このシナリオのユーザー体験を向上させる1つの方法は、[admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)を作成して、ユーザーがDeploymentなどのトップレベルのオブジェクトを作成するときにFQDNのサイズを制御することです。 +{{< /note >}} + + ### PodのDNSポリシー DNSポリシーはPod毎に設定できます。現在のKubernetesでは次のようなPod固有のDNSポリシーをサポートしています。これらのポリシーはPod Specの`dnsPolicy`フィールドで指定されます。 diff --git a/content/ja/docs/concepts/services-networking/dual-stack.md b/content/ja/docs/concepts/services-networking/dual-stack.md index 4dd77cf2bb..3bad029501 100644 --- a/content/ja/docs/concepts/services-networking/dual-stack.md +++ b/content/ja/docs/concepts/services-networking/dual-stack.md @@ -40,6 +40,7 @@ IPv4/IPv6デュアルスタックを有効にするには、クラスターの * kube-apiserver: * `--feature-gates="IPv6DualStack=true"` + * `--service-cluster-ip-range=,` * kube-controller-manager: * `--feature-gates="IPv6DualStack=true"` * `--cluster-cidr=,` @@ -89,7 +90,7 @@ IPv6が有効になった外部ロードバランサーをサポートしてい ## 外向きのトラフィック {#egress-traffic} -パブリックおよび非パブリックでのルーティングが可能なIPv6アドレスのブロックを利用するためには、クラスターがベースにしている{{< glossary_tooltip text="CNI" term_id="cni" >}}プロバイダーがIPv6の転送を実装している必要があります。もし非パブリックでのルーティングが可能なIPv6アドレスを使用するPodがあり、そのPodをクラスター外の送信先(例:パブリックインターネット)に到達させたい場合、外向きのトラフィックと応答の受信のためにIPマスカレードを設定する必要があります。[ip-masq-agent](https://github.com/kubernetes-incubator/ip-masq-agent)はデュアルスタックに対応しているため、デュアルスタックのクラスター上でのIPマスカレードにはip-masq-agentが利用できます。 +パブリックおよび非パブリックでのルーティングが可能なIPv6アドレスのブロックを利用するためには、クラスターがベースにしている{{< glossary_tooltip text="CNI" term_id="cni" >}}プロバイダーがIPv6の転送を実装している必要があります。もし非パブリックでのルーティングが可能なIPv6アドレスを使用するPodがあり、そのPodをクラスター外の送信先(例:パブリックインターネット)に到達させたい場合、外向きのトラフィックと応答の受信のためにIPマスカレードを設定する必要があります。[ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent)はデュアルスタックに対応しているため、デュアルスタックのクラスター上でのIPマスカレードにはip-masq-agentが利用できます。 ## 既知の問題 diff --git a/content/ja/docs/concepts/services-networking/endpoint-slices.md b/content/ja/docs/concepts/services-networking/endpoint-slices.md index 24a588c29e..b9d60eb6b3 100644 --- a/content/ja/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ja/docs/concepts/services-networking/endpoint-slices.md @@ -1,7 +1,7 @@ --- title: EndpointSlice content_type: concept -weight: 15 +weight: 35 --- @@ -14,13 +14,19 @@ weight: 15 ## 動機 -Endpoints APIはKubernetes内のネットワークエンドポイントを追跡する単純で直観的な手段を提供してきました。残念ながら、KubernetesクラスターやServiceが大規模になるにつれて、Endpoints APIの限界が明らかになってきました。最も顕著な問題の1つに、ネットワークエンドポイントの数が大きくなったときのスケーリングの問題があります。 +Endpoint APIはKubernetes内のネットワークエンドポイントを追跡する単純で直観的な手段を提供してきました。 +残念ながら、Kubernetesクラスターや{{< glossary_tooltip text="Service" term_id="service" >}}が大規模になり、より多くのトラフィックを処理し、より多くのバックエンドPodに送信するようになるにしたがって、Endpoint APIの限界が明らかになってきました。 +最も顕著な問題の1つに、ネットワークエンドポイントの数が大きくなったときのスケーリングの問題があります。 -Serviceのすべてのネットワークエンドポイントが単一のEndpointsリソースに格納されていたため、リソースのサイズが非常に大きくなる場合がありました。これがKubernetesのコンポーネント(特に、マスターコントロールプレーン)の性能に悪影響を与え、結果として、Endpointsに変更があるたびに、大量のネットワークトラフィックと処理が発生するようになってしまいました。EndpointSliceは、この問題を緩和するとともに、トポロジカルルーティングなどの追加機能のための拡張可能なプラットフォームを提供します。 +Serviceのすべてのネットワークエンドポイントが単一のEndpointリソースに格納されていたため、リソースのサイズが非常に大きくなる場合がありました。これがKubernetesのコンポーネント(特に、マスターコントロールプレーン)の性能に悪影響を与え、結果として、Endpointに変更があるたびに、大量のネットワークトラフィックと処理が発生するようになってしまいました。EndpointSliceは、この問題を緩和するとともに、トポロジカルルーティングなどの追加機能のための拡張可能なプラットフォームを提供します。 ## EndpointSliceリソース {#endpointslice-resource} -Kubernetes内ではEndpointSliceにはネットワークエンドポイントの集合へのリファレンスが含まれます。EndpointSliceコントローラーは、{{< glossary_tooltip text="セレクター" term_id="selector" >}}が指定されると、Kubernetes Serviceに対するEndpointSliceを自動的に作成します。これらのEndpointSliceにはServiceセレクターに一致する任意のPodへのリファレンスが含まれます。EndpointSliceはネットワークエンドポイントをユニークなServiceとPortの組み合わせでグループ化します。EndpointSliceオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 +Kubernetes内ではEndpointSliceにはネットワークエンドポイントの集合へのリファレンスが含まれます。 +コントロールプレーンは、{{< glossary_tooltip text = "セレクター" term_id = "selector" >}}が指定されているKubernetes ServiceのEndpointSliceを自動的に作成します。 +これらのEndpointSliceには、Serviceセレクターに一致するすべてのPodへのリファレンスが含まれています。 +EndpointSliceは、プロトコル、ポート番号、およびサービス名の一意の組み合わせによってネットワークエンドポイントをグループ化します。 +EndpointSliceオブジェクトの名前は有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 一例として、以下に`example`というKubernetes Serviceに対するサンプルのEndpointSliceリソースを示します。 @@ -47,9 +53,9 @@ endpoints: topology.kubernetes.io/zone: us-west2-a ``` -デフォルトではEndpointSliceコントローラーが管理するEndpointSliceには、1つにつき最大で100個のエンドポイントしか所属しません。この規模以下であれば、EndpointSliceはEndpointとServiceが1対1対応になり、性能は変わらないはずです。 +デフォルトでは、コントロールプレーンはEndpointSliceを作成・管理し、それぞれのエンドポイント数が100以下になるようにします。`--max-endpoints-per-slice`{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}フラグを設定することで、最大1000個まで設定可能です。 -EndpointSliceは内部トラフィックのルーティング方法に関して、kube-proxyに対する唯一のソース(source of truth)として振る舞うことができます。EndpointSliceを有効にすれば、非常に多数のエンドポイントを持つServiceに対して性能向上が得られるはずです。 +EndpointSliceは内部トラフィックのルーティング方法に関して、{{< glossary_tooltip term_id="kube-proxy" text="kube-proxy" >}}に対する唯一のソース(source of truth)として振る舞うことができます。EndpointSliceを有効にすれば、非常に多数のエンドポイントを持つServiceに対して性能向上が得られるはずです。 ### アドレスの種類 @@ -59,9 +65,10 @@ EndpointSliceは次の3種類のアドレスをサポートします。 * IPv6 * FQDN (Fully Qualified Domain Name、完全修飾ドメイン名) -### トポロジー +### トポロジー {#topology} -EndpointSliceに属する各エンドポイントは、関連するトポロジーの情報を持つことができます。この情報は、エンドポイントの場所を示すために使われ、対応するNode、ゾーン、リージョンに関する情報が含まれます。値が利用できる場合にはEndpointSliceコントローラーによって次のようなTopologyラベルが設定されます。 +EndpointSliceに属する各エンドポイントは、関連するトポロジーの情報を持つことができます。この情報は、エンドポイントの場所を示すために使われ、対応するNode、ゾーン、リージョンに関する情報が含まれます。 +値が利用できる場合には、コントロールプレーンはEndpointSliceコントローラーに次のようなTopologyラベルを設定します。 * `kubernetes.io/hostname` - このエンドポイントが存在するNodeの名前。 * `topology.kubernetes.io/zone` - このエンドポイントが存在するゾーン。 @@ -71,25 +78,34 @@ EndpointSliceに属する各エンドポイントは、関連するトポロジ ### 管理 -EndpointSliceはデフォルトではEndpointSliceコントローラーによって作成・管理されます。EndpointSliceには他にもサービスメッシュの実装などのさまざまなユースケースがあるため、他のエンティティやコントローラーがEndpointSliceの追加の集合を管理する場合もあります。複数のエンティティが互いに干渉せずにEndpointSliceを管理できるようにするために、EndpointSliceを管理しているエンティティを表す`endpointslice.kubernetes.io/managed-by`ラベルが使用されます。EndpointSliceコントローラーの場合、管理対象のすべてのEndpointSliceに対して、このラベルの値として`endpointslice-controller.k8s.io`を設定します。EndpointSliceを管理するその他のエンティティも同様に、このラベルにユニークな値を設定する必要があります。 +ほとんどの場合、コントロールプレーン（具体的には、EndpointSlice {{< glossary_tooltip text = "コントローラー" term_id = "controller" >}}）は、EndpointSliceオブジェクトを作成および管理します。EndpointSliceには、サービスメッシュの実装など、他のさまざまなユースケースがあり、他のエンティティまたはコントローラーがEndpointSliceの追加セットを管理する可能性があります。 + +複数のエンティティが互いに干渉することなくEndpointSliceを管理できるようにするために、KubernetesはEndpointSliceを管理するエンティティを示す`endpointslice.kubernetes.io/managed-by`という{{< glossary_tooltip term_id="label" text="ラベル" >}}を定義します。 +EndpointSliceを管理するその他のエンティティも同様に、このラベルにユニークな値を設定する必要があります。 ### 所有権 -ほとんどのユースケースでは、EndpointSliceは対象のエンドポイントが追跡しているServiceによって所有されます。これは、各EndpointSlice上のownerリファレンスと`kubernetes.io/service-name`ラベルによって示されます。これにより、Serviceに属するすべてのEndpointSliceを簡単に検索できるようになっています。 +ほとんどのユースケースでは、EndpointSliceはエンドポイントスライスオブジェクトがエンドポイントを追跡するServiceによって所有されます。 +これは、各EndpointSlice上のownerリファレンスと`kubernetes.io/service-name`ラベルによって示されます。これにより、Serviceに属するすべてのEndpointSliceを簡単に検索できるようになっています。 -## EndpointSliceコントローラー +### EndpointSliceのミラーリング -EndpointSliceコントローラーは対応するEndpointSliceが最新の状態であることを保証するために、ServiceとPodを監視します。このコントローラーはセレクターが指定した各Serviceに対応するEndpointSliceを管理します。EndpointSliceはServiceセレクターに一致するPodのIPを表します。 +場合によっては、アプリケーションはカスタムEndpointリソースを作成します。これらのアプリケーションがEndpointリソースとEndpointSliceリソースの両方に同時に書き込む必要がないようにするために、クラスターのコントロールプレーンは、ほとんどのEndpointリソースを対応するEndpointSliceにミラーリングします。 -### EndpointSliceのサイズ +コントロールプレーンは、次の場合を除いて、Endpointリソースをミラーリングします。 -デフォルトでは、それぞれのEndpointSliceのサイズの上限は100個のEndpointsに制限されています。この制限は{{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}に`--max-endpoints-per-slice`フラグを使用することで、最大で1000まで設定できます。 +* Endpointリソースの`endpointslice.kubernetes.io/skip-mirror`ラベルが`true`に設定されています。 +* Endpointリソースが`control-plane.alpha.kubernetes.io/leader`アノテーションを持っています。 +* 対応するServiceリソースが存在しません。 +* 対応するServiceリソースには、nil以外のセレクターがあります。 + +個々のEndpointリソースは、複数のEndpointSliceに変換される場合があります。これは、Endpointリソースに複数のサブセットがある場合、または複数のIPファミリ（IPv4およびIPv6）を持つエンドポイントが含まれている場合に発生します。サブセットごとに最大1000個のアドレスがEndpointSliceにミラーリングされます。 ### EndpointSliceの分散 -それぞれのEndpointSliceにはポートの集合があり、リソース内のすべてのエンドポイントに適用されます。サービスが名前付きポートを使用した場合、Podが同じ名前のポートに対して、結果的に異なるターゲットポート番号が使用されて、異なるEndpointSliceが必要になる場合があります。これはサービスの部分集合がEndpointsにグループ化される場合と同様です。 +それぞれのEndpointSliceにはポートの集合があり、リソース内のすべてのエンドポイントに適用されます。サービスが名前付きポートを使用した場合、Podが同じ名前のポートに対して、結果的に異なるターゲットポート番号が使用されて、異なるEndpointSliceが必要になる場合があります。これはサービスの部分集合がEndpointにグループ化される場合と同様です。 -コントローラーはEndpointSliceをできる限り充填しようとしますが、積極的にリバランスを行うことはありません。コントローラーのロジックは極めて単純で、以下のようになっています。 +コントロールプレーンはEndpointSliceをできる限り充填しようとしますが、積極的にリバランスを行うことはありません。コントローラーのロジックは極めて単純で、以下のようになっています。 1. 既存のEndpointSliceをイテレートし、もう必要のないエンドポイントを削除し、変更があったエンドポイントを更新する。 2. 前のステップで変更されたEndpointSliceをイテレートし、追加する必要がある新しいエンドポイントで充填する。 @@ -101,8 +117,16 @@ EndpointSliceコントローラーは対応するEndpointSliceが最新の状態 現実的には、こうしたあまり理想的ではない分散が発生することは稀です。EndpointSliceコントローラーによって処理されるほとんどの変更は、既存のEndpointSliceに収まるほど十分小さくなるためです。そうでなかったとしても、すぐに新しいEndpointSliceが必要になる可能性が高いです。また、Deploymentのローリングアップデートが行われれば、自然な再充填が行われます。Podとそれに対応するエンドポイントがすべて置換されるためです。 +### エンドポイントの重複 + +EndpointSliceの変更の性質上、エンドポイントは同時に複数のEndpointSliceで表される場合があります。 +これは、さまざまなEndpointSliceオブジェクトへの変更が、さまざまな時間にKubernetesクライアントのウォッチ/キャッシュに到達する可能性があるために自然に発生します。 +EndpointSliceを使用する実装では、エンドポイントを複数のスライスに表示できる必要があります。 +エンドポイント重複排除を実行する方法のリファレンス実装は、`kube-proxy`の`EndpointSliceCache`実装にあります。 + + ## {{% heading "whatsnext" %}} -* [EndpointSliceを有効にする](/docs/tasks/administer-cluster/enabling-endpointslices) +* [EndpointSliceの有効化](/docs/tasks/administer-cluster/enabling-endpointslices)について学ぶ * [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)を読む diff --git a/content/ja/docs/concepts/services-networking/ingress-controllers.md b/content/ja/docs/concepts/services-networking/ingress-controllers.md index cbd652d17e..75dfb1d11b 100644 --- a/content/ja/docs/concepts/services-networking/ingress-controllers.md +++ b/content/ja/docs/concepts/services-networking/ingress-controllers.md @@ -11,47 +11,42 @@ Ingressリソースが動作するためには、クラスターでIngressコン `kube-controller-manager`バイナリの一部として実行される他のタイプのコントローラーとは異なり、Ingressコントローラーはクラスターで自動的に起動されません。このページを使用して、クラスターに最適なIngressコントローラーの実装を選択してください。 -プロジェクトとしてのKubernetesは現在、[GCE](https://git.k8s.io/ingress-gce/README.md)と[nginx](https://git.k8s.io/ingress-nginx/README.md)のコントローラーをサポートし、保守しています。 - - +プロジェクトとしてのKubernetesは現在、[AWS](https://github.com/kubernetes-sigs/aws-load-balancer-controller#readme)、[GCE](https://git.k8s.io/ingress-gce/README.md#readme)、および[nginx](https://git.k8s.io/ingress-nginx/README.md#readme)のIngressコントローラーをサポート・保守しています。 ## 追加のコントローラー {#additional-controllers} -* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress)は[Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview)を利用して[AKSクラスター](https://docs.microsoft.com/azure/aks/kubernetes-walkthrough-portal)でIngressを実行可能にするIngressコントローラーです。 -* [Ambassador](https://www.getambassador.io/) API Gatewayは[Envoy](https://www.envoyproxy.io)ベースのIngressコントローラーで、[Datawire](https://www.datawire.io/)による[コミュニティ版](https://www.getambassador.io/docs)または[商用版](https://www.getambassador.io/pro/)のサポートがあります。 -* [AppsCode Inc.](https://appscode.com)では、最も広く使用されている[HAProxy](https://www.haproxy.org/)ベースのIngressコントローラーである[Voyager](https://appscode.com/products/voyager)のサポートと保守を提供しています。 -* [AWS ALB Ingress Controller](https://github.com/kubernetes-sigs/aws-alb-ingress-controller)は[AWS Application Load Balancer](https://aws.amazon.com/elasticloadbalancing/)を使用したIngressを有効にします。 -* [Contour](https://projectcontour.io/)は、VMwareが提供し、サポートしている[Envoy](https://www.envoyproxy.io/)ベースのIngressコントローラーです。 -* Citrixは、[ベアメタル](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment/baremetal)と[クラウド](https://github.com/citrix/citrix-k8s-ingress-controller/tree/master/deployment)のデプロイ用に、ハードウェア(MPX）、仮想化(VPX)、[フリーコンテナ化(CPX) ADC](https://www.citrix.com/products/citrix-adc/cpx-express.html)用の[Ingressコントローラー](https://github.com/citrix/citrix-k8s-ingress-controller)を提供しています。 -* F5 Networksは[F5 BIG-IP Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)の[サポートと保守](https://support.f5.com/csp/article/K86859508)を提供しています。 -* [Gloo](https://gloo.solo.io)は[Envoy](https://www.envoyproxy.io)をベースにしたオープンソースのIngressコントローラーで、[solo.io](https://www.solo.io)からのエンタープライズサポートでAPI Gateway機能を提供しています。 -* [HAProxy Ingress](https://haproxy-ingress.github.io)は、HAProxy用の高度にカスタマイズ可能なコミュニティ主導のIngressコントローラーです。 -* [HAProxy Technologies](https://www.haproxy.com/)は[HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress)のサポートと保守を提供しています。[公式ドキュメント](https://www.haproxy.com/documentation/hapee/1-9r1/traffic-management/kubernetes-ingress-controller/)を参照してください。 -* [Istio](https://istio.io/)ベースのIngressコントローラー[Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/)。 -* [Kong](https://konghq.com/)は、[Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller)の[コミュニティ版](https://discuss.konghq.com/c/kubernetes)と[商用版]](https://konghq.com/kong-enterprise/)のサポートと保守を提供しています。 -* [NGINX, Inc.](https://www.nginx.com/)は[NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)のサポートと保守を提供しています。 +{{% thirdparty-content %}} + +* [AKS Application Gateway Ingress Controller](https://github.com/Azure/application-gateway-kubernetes-ingress)は、[Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview)を設定するIngressコントローラーです。 +* [Ambassador](https://www.getambassador.io/) API Gatewayは[Envoy](https://www.envoyproxy.io)ベースのIngressコントローラーです。 +* [Citrix ingress controller](https://github.com/citrix/citrix-k8s-ingress-controller#readme)は、Citrix Application Delivery Controllerで動作します。 +* [Contour](https://projectcontour.io/)は、[Envoy](https://www.envoyproxy.io/)ベースのIngressコントローラーです。 +* F5 BIG-IPの[Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)はF5 BIG-IPの仮想サーバー上でIngressの設定を可能にします。 +* [Gloo](https://gloo.solo.io)は[Envoy](https://www.envoyproxy.io)をベースにしたオープンソースのIngressコントローラーで、API Gateway機能を提供しています。 +* [HAProxy Ingress](https://haproxy-ingress.github.io)は、[HAProxy](http://www.haproxy.org/#desc)用のIngressコントローラーです。 +* [HAProxy Ingress Controller for Kubernetes](https://github.com/haproxytech/kubernetes-ingress)も、[HAProxy](http://www.haproxy.org/#desc)用のIngressコントローラーです。 +* [Istio Ingress](https://istio.io/latest/docs/tasks/traffic-management/ingress/kubernetes-ingress/)は、[Istio](https://istio.io/)ベースのIngressコントローラーです。 +* [Kong Ingress Controller for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller#readme)は、[Kong Gateway](https://konghq.com/kong/)向けのIngressコントローラーです。 +* [NGINX Ingress Controller for Kubernetes](https://www.nginx.com/products/nginx/kubernetes-ingress-controller)は、[NGINX](https://www.nginx.com/resources/glossary/nginx/)ウェブサーバーで(プロキシとして)動作します。 * [Skipper](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/)は、カスタムプロキシーを構築するためのライブラリーとして設計された、Kubernetes Ingressなどのユースケースを含む、サービス構成用のHTTPルーターとリバースプロキシーです。 -* [Traefik](https://github.com/containous/traefik)はフル機能([Let's Encrypt](https://letsencrypt.org), secrets, http2, websocket)のIngressコントローラーで、[Containous](https://containo.us/services)による商用サポートもあります。 +* [Traefik Kubernetes Ingress provider](https://doc.traefik.io/traefik/providers/kubernetes-ingress/)は、[Traefik](https://github.com/containous/traefik) proxy向けのIngressコントローラーです。 +* [Voyager](https://appscode.com/products/voyager)は、[HAProxy](http://www.haproxy.org/#desc)向けのIngressコントローラーです。 ## 複数のIngressコントローラーの使用 {#using-multiple-ingress-controllers} -[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定します。 +[Ingressコントローラーは、好きな数だけ](https://git.k8s.io/ingress-nginx/docs/user-guide/multiple-ingress.md#multiple-ingress-controllers)クラスターにデプロイすることができます。Ingressを作成する際には、クラスター内に複数のIngressコントローラーが存在する場合にどのIngressコントローラーを使用するかを示すために適切な[`ingress.class`](https://git.k8s.io/ingress-gce/docs/faq/README.md#how-do-i-run-multiple-ingress-controllers-in-the-same-cluster)のアノテーションを指定する必要があります。 クラスを定義しない場合、クラウドプロバイダーはデフォルトのIngressコントローラーを使用する場合があります。 理想的には、すべてのIngressコントローラーはこの仕様を満たすべきですが、いくつかのIngressコントローラーはわずかに異なる動作をします。 - {{< note >}} Ingressコントローラーのドキュメントを確認して、選択する際の注意点を理解してください。 {{< /note >}} - - ## {{% heading "whatsnext" %}} - -* [Ingress](/ja/docs/concepts/services-networking/ingress/)の詳細 -* [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube) +* [Ingress](/ja/docs/concepts/services-networking/ingress/)についてさらに学ぶ。 +* [Minikube上でNGINX Ingressコントローラーを使用してIngressをセットアップする](/ja/docs/tasks/access-application-cluster/ingress-minikube)。 diff --git a/content/ja/docs/concepts/services-networking/ingress.md b/content/ja/docs/concepts/services-networking/ingress.md index 76bb234f7e..97d18640b8 100644 --- a/content/ja/docs/concepts/services-networking/ingress.md +++ b/content/ja/docs/concepts/services-networking/ingress.md @@ -5,7 +5,7 @@ weight: 40 --- -{{< feature-state for_k8s_version="v1.1" state="beta" >}} +{{< feature-state for_k8s_version="v1.19" state="stable" >}} {{< glossary_definition term_id="ingress" length="all" >}} @@ -23,17 +23,28 @@ weight: 40 ## Ingressとは何か -[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)はクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。 +[Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1-networking-k8s-io)はクラスター外からクラスター内{{< link text="Service" url="/ja/docs/concepts/services-networking/service/" >}}へのHTTPとHTTPSのルートを公開します。トラフィックのルーティングはIngressリソース上で定義されるルールによって制御されます。 -```none - internet - | - [ Ingress ] - --|-----|-- - [ Services ] -``` +全てのトラフィックを単一のServiceに送る単純なIngressの例を示します。 -IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。 +{{< mermaid >}} +graph LR; + client([クライアント])-. Ingress管理下の
    ロードバランサー .->ingress[Ingress]; + ingress-->|ルーティングルール|service[Service]; + subgraph cluster[クラスター] + ingress; + service-->pod1[Pod]; + service-->pod2[Pod]; + end + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; + class ingress,service,pod1,pod2 k8s; + class client plain; + class cluster cluster; +{{}} + +IngressはServiceに対して、外部疎通できるURL、負荷分散トラフィック、SSL/TLS終端の機能や、名前ベースの仮想ホスティングを提供するように設定できます。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)は通常はロードバランサーを使用してIngressの機能を実現しますが、エッジルーターや、追加のフロントエンドを構成してトラフィックの処理を支援することもできます。 Ingressは任意のポートやプロトコルを公開しません。HTTPやHTTPS以外のServiceをインターネットに公開する場合、[Service.Type=NodePort](/ja/docs/concepts/services-networking/service/#nodeport)や[Service.Type=LoadBalancer](/ja/docs/concepts/services-networking/service/#loadbalancer)のServiceタイプを一般的には使用します。 @@ -53,23 +64,7 @@ Ingressコントローラーのドキュメントを確認して、選択する Ingressリソースの最小構成の例は以下のとおりです。 -```yaml -apiVersion: networking.k8s.io/v1beta1 -kind: Ingress -metadata: - name: test-ingress - annotations: - nginx.ingress.kubernetes.io/rewrite-target: / -spec: - rules: - - http: - paths: - - path: /testpath - pathType: Prefix - backend: - serviceName: test - servicePort: 80 -``` +{{< codenew file="service/networking/minimal-ingress.yaml" >}} 他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。 @@ -80,52 +75,106 @@ Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/ 各HTTPルールは以下の情報を含みます。 * オプションで設定可能なホスト名。上記のリソースの例では、ホスト名が指定されていないと、そのルールは指定されたIPアドレスを経由する全てのインバウンドHTTPトラフィックに適用されます。ホスト名が指定されていると(例: foo.bar.com)、そのルールはホストに対して適用されます。 -* パスのリスト(例: `/testpath`)。各パスには`serviceName`と`servicePort`で定義されるバックエンドが関連づけられます。ロードバランサーがトラフィックを関連づけられたServiceに転送するために、外部からくるリクエストのホスト名とパスが条件と一致させる必要があります。 -* [Serviceドキュメント](/ja/docs/concepts/services-networking/service/)に書かれているように、バックエンドはServiceとポート名の組み合わせとなります。Ingressで設定されたホスト名とパスのルールに一致するHTTP(とHTTPS)のリクエストは、リスト内のバックエンドに対して送信されます。 +* パスのリスト(例: `/testpath`)。各パスには`service.name`と`service.port.name`または`service.port.number`で定義されるバックエンドが関連づけられます。ロードバランサーがトラフィックを関連づけられたServiceに転送するために、外部からくるリクエストのホスト名とパスが条件と一致させる必要があります。 +* バックエンドは[Serviceドキュメント](/ja/docs/concepts/services-networking/service/)に書かれているようなService名とポート名の組み合わせ、または{{< glossary_tooltip term_id="CustomResourceDefinition" text="CRD" >}}による[カスタムリソースバックエンド](#resource-backend)です。Ingressで設定されたホスト名とパスのルールに一致するHTTP(とHTTPS)のリクエストは、リスト内のバックエンドに対して送信されます。 -Ingressコントローラーでは、デフォルトのバックエンドが設定されていることがあります。これはSpec内で指定されているパスに一致しないようなリクエストのためのバックエンドです。 +Ingressコントローラーでは、`defaultBackend`が設定されていることがあります。これはSpec内で指定されているパスに一致しないようなリクエストのためのバックエンドです。 -### デフォルトのバックエンド +### デフォルトのバックエンド {#default-backend} -ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。このデフォルトのバックエンドは、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。 +ルールが設定されていないIngressは、全てのトラフィックをデフォルトのバックエンドに転送します。`defaultBackend`は、[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のオプション設定であり、Ingressリソースでは指定されていません。 -IngressオブジェクトでHTTPリクエストが1つもホスト名とパスの条件に一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。 +HTTPリクエストがIngressオブジェクトのホスト名とパスの条件に1つも一致しない時、そのトラフィックはデフォルトのバックエンドに転送されます。 + +### リソースバックエンド {#resource-backend} + +`Resource`バックエンドはIngressオブジェクトと同じnamespaceにある他のKubernetesリソースを指すObjectRefです。 +`Resource`はServiceの設定とは排他であるため、両方を指定するとバリデーションに失敗します。 +`Resource`バックエンドのよくある用途は、静的なアセットが入ったオブジェクトストレージを設定することです。 + +{{< codenew file="service/networking/ingress-resource-backend.yaml" >}} + +上記のIngressを作成した後に、次のコマンドで参照することができます。 + +```bash +kubectl describe ingress ingress-resource-backend +``` + +``` +Name: ingress-resource-backend +Namespace: default +Address: +Default backend: APIGroup: k8s.example.com, Kind: StorageBucket, Name: static-assets +Rules: + Host Path Backends + ---- ---- -------- + * + /icons APIGroup: k8s.example.com, Kind: StorageBucket, Name: icon-assets +Annotations: +Events: +``` ### パスのタイプ -Ingressのそれぞれのパスは対応するパスのタイプを持ちます。サポートされているパスのタイプは3種類あります。 +Ingressのそれぞれのパスは対応するパスのタイプを持ちます。`pathType`が明示的に指定されていないパスはバリデーションに通らないでしょう。サポートされているパスのタイプは3種類あります。 -* _`ImplementationSpecific`_ (デフォルト): このパスタイプでは、パスとの一致はIngressClassに依存します。Ingressの実装はこれを独立した`pathType`と扱うことも、`Prefix`や`Exact`と同一のパスタイプと扱うこともできます。 +* `ImplementationSpecific`（実装に特有）: このパスタイプでは、パスとの一致はIngressClassに依存します。Ingressの実装はこれを独立した`pathType`と扱うことも、`Prefix`や`Exact`と同一のパスタイプと扱うこともできます。 -* _`Exact`_: 大文字小文字を区別して完全に一致するURLパスと一致します。 +* `Exact`: 大文字小文字を区別して完全に一致するURLパスと一致します。 -* _`Prefix`_: `/`で分割されたURLと前方一致で一致します。大文字小文字は区別され、パスの要素対要素で比較されます。パス要素は`/`で分割されたパスの中のラベルのリストを参照します。リクエストがパス _p_ に一致するのは、Ingressのパス _p_ がリクエストパス _p_ と要素単位で前方一致する場合です。 +* `Prefix`: `/`で分割されたURLと前方一致で一致します。大文字小文字は区別され、パスの要素対要素で比較されます。パス要素は`/`で分割されたパスの中のラベルのリストを参照します。リクエストがパス _p_ に一致するのは、Ingressのパス _p_ がリクエストパス _p_ と要素単位で前方一致する場合です。 {{< note >}} パスの最後の要素がリクエストパスの最後の要素の部分文字列である場合、これは一致しません（例えば、`/foo/bar`は`/foo/bar/baz`と一致しますが、`/foo/barbaz`とは一致しません）。 {{< /note >}} +### 例 + +| タイプ | パス | リクエストパス | 一致するか | +|--------|---------------------------------|-------------------------------|--------------------------------------| +| Prefix | `/` | （全てのパス） | はい | +| Exact | `/foo` | `/foo` | はい | +| Exact | `/foo` | `/bar` | いいえ | +| Exact | `/foo` | `/foo/` | いいえ | +| Exact | `/foo/` | `/foo` | いいえ | +| Prefix | `/foo` | `/foo`, `/foo/` | はい | +| Prefix | `/foo/` | `/foo`, `/foo/` | はい | +| Prefix | `/aaa/bb` | `/aaa/bbb` | いいえ | +| Prefix | `/aaa/bbb` | `/aaa/bbb` | はい | +| Prefix | `/aaa/bbb/` | `/aaa/bbb` | はい、末尾のスラッシュは無視 | +| Prefix | `/aaa/bbb` | `/aaa/bbb/` | はい、末尾のスラッシュと一致 | +| Prefix | `/aaa/bbb` | `/aaa/bbb/ccc` | はい、パスの一部と一致 | +| Prefix | `/aaa/bbb` | `/aaa/bbbxyz` | いいえ、接頭辞と一致しない | +| Prefix | `/`, `/aaa` | `/aaa/ccc` | はい、接頭辞`/aaa`と一致 | +| Prefix | `/`, `/aaa`, `/aaa/bbb` | `/aaa/bbb` | はい、接頭辞`/aaa/bbb`と一致 | +| Prefix | `/`, `/aaa`, `/aaa/bbb` | `/ccc` | はい、接頭辞`/`と一致 | +| Prefix | `/aaa` | `/ccc` | いいえ、デフォルトバックエンドを使用 | +| Mixed | `/foo` (Prefix), `/foo` (Exact) | `/foo` | はい、Exactが優先 | + #### 複数のパスとの一致 リクエストがIngressの複数のパスと一致することがあります。そのような場合は、最も長くパスが一致したものが優先されます。2つのパスが同等に一致した場合は、完全一致が前方一致よりも優先されます。 +## ホスト名のワイルドカード + +ホストは正確に一致する（例えば`foo.bar.com`）かワイルドカード（例えば`*.foo.com`）とすることができます。 +正確な一致ではHTTPヘッダーの`host`が`host`フィールドと一致することが必要です。 +ワイルドカードによる一致では、HTTPヘッダーの`host`がワイルドカードルールに沿って後方一致することが必要です。 + +| Host | Hostヘッダー | 一致するか | +| ----------- |-------------------| ------------------------------------------------------------| +| `*.foo.com` | `bar.foo.com` | 共通の接尾辞により一致 | +| `*.foo.com` | `baz.bar.foo.com` | 一致しない。ワイルドカードは単一のDNSラベルのみを対象とする | +| `*.foo.com` | `foo.com` | 一致しない。ワイルドカードは単一のDNSラベルのみを対象とする | + +{{< codenew file="service/networking/ingress-wildcard-host.yaml" >}} + ## Ingress Class Ingressは異なったコントローラーで実装されうるため、しばしば異なった設定を必要とします。 IngressClassリソースは、この種別のIngressを実装すべきコントローラーの名称を含む追加の設定情報を含みます。各IngressはIngressClassリソースへの参照によって種別を指定すべきです。 -```yaml -apiVersion: networking.k8s.io/v1beta1 -kind: IngressClass -metadata: - name: external-lb -spec: - controller: example.com/ingress-controller - parameters: - apiGroup: k8s.example.com/v1alpha - kind: IngressParameters - name: external-lb -``` +{{< codenew file="service/networking/external-lb.yaml" >}} IngressClassリソースは任意のパラメータフィールドを含むことができます。これは追加の設定情報を参照するために利用することができます。 @@ -137,7 +186,7 @@ Kubernetes 1.18でIngressClassリソースと`ingressClassName`フィールド Ingressの新しい`ingressClassName`フィールドはこのアノテーションを置き換えるものですが、完全に等価ではありません。 アノテーションは一般にIngressを実装すべきIngressのコントローラーの名称を示していましたが、フィールドはIngressClassリソースを示しており、これはIngressのコントローラーの名称を含む追加のIngressの設定情報を持ちます。 -### デフォルトのIngress Class +### デフォルトのIngressClass {#default-ingress-class} 特定のIngressClassをクラスターでのデフォルトとすることができます。 IngressClassリソースの`ingressclass.kubernetes.io/is-default-class`アノテーションを`true`に設定すると、`ingressClassName`フィールドが指定されないIngressにはこのデフォルトIngressClassが割り当てられるようになります。 @@ -148,20 +197,21 @@ IngressClassリソースの`ingressclass.kubernetes.io/is-default-class`アノ ## Ingressのタイプ -### 単一ServiceのIngress +### 単一ServiceのIngress {#single-service-ingress} + Kubernetesには、単一のServiceを公開できるようにする既存の概念があります（[Ingressの代替案](#alternatives)を参照してください）。ルールなしで*デフォルトのバックエンド* を指定することにより、Ingressでこれを実現することもできます。 -{{< codenew file="service/networking/ingress.yaml" >}} +{{< codenew file="service/networking/test-ingress.yaml" >}} `kubectl apply -f`を実行してIngressを作成すると、その作成したIngressの状態を確認することができます。 -```shell +```bash kubectl get ingress test-ingress ``` ``` -NAME HOSTS ADDRESS PORTS AGE -test-ingress * 203.0.113.123 80 59s +NAME CLASS HOSTS ADDRESS PORTS AGE +test-ingress external-lb * 203.0.113.123 80 59s ``` `203.0.113.123`はIngressコントローラーによって割り当てられたIPで、作成したIngressを利用するためのものです。 @@ -174,34 +224,29 @@ IngressコントローラーとロードバランサーがIPアドレス割り ファンアウト設定では単一のIPアドレスのトラフィックを、リクエストされたHTTP URIに基づいて1つ以上のServiceに転送します。Ingressによってロードバランサーの数を少なくすることができます。例えば、以下のように設定します。 -```none -foo.bar.com -> 178.91.123.132 -> / foo service1:4200 - / bar service2:8080 -``` +{{< mermaid >}} +graph LR; + client([クライアント])-. Ingress管理下の
    ロードバランサー .->ingress[Ingress, 178.91.123.132]; + ingress-->|/foo|service1[Service service1:4200]; + ingress-->|/bar|service2[Service service2:8080]; + subgraph cluster[クラスター] + ingress; + service1-->pod1[Pod]; + service1-->pod2[Pod]; + service2-->pod3[Pod]; + service2-->pod4[Pod]; + end + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; + class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s; + class client plain; + class cluster cluster; +{{}} Ingressを以下のように設定します。 -```yaml -apiVersion: networking.k8s.io/v1beta1 -kind: Ingress -metadata: - name: simple-fanout-example - annotations: - nginx.ingress.kubernetes.io/rewrite-target: / -spec: - rules: - - host: foo.bar.com - http: - paths: - - path: /foo - backend: - serviceName: service1 - servicePort: 4200 - - path: /bar - backend: - serviceName: service2 - servicePort: 8080 -``` +{{< codenew file="service/networking/simple-fanout-example.yaml" >}} Ingressを`kubectl apply -f`によって作成したとき: @@ -220,8 +265,6 @@ Rules: foo.bar.com /foo service1:4200 (10.8.0.90:4200) /bar service2:8080 (10.8.0.91:8080) -Annotations: - nginx.ingress.kubernetes.io/rewrite-target: / Events: Type Reason Age From Message ---- ------ ---- ---- ------- @@ -232,75 +275,46 @@ IngressコントローラーはService(`service1`、`service2`)が存在する 構築が完了すると、ADDRESSフィールドでロードバランサーのアドレスを確認できます。 {{< note >}} -使用する[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)に依存しますが、default-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。 +使用する[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)に依存しますが、default-http-backend[Service](/ja/docs/concepts/services-networking/service/)の作成が必要な場合があります。 {{< /note >}} ### 名前ベースのバーチャルホスティング 名前ベースのバーチャルホストは、HTTPトラフィックを同一のIPアドレスの複数のホスト名に転送することをサポートしています。 -```none -foo.bar.com --| |-> foo.bar.com service1:80 - | 178.91.123.132 | -bar.foo.com --| |-> bar.foo.com service2:80 -``` +{{< mermaid >}} +graph LR; + client([クライアント])-. Ingress管理下の
    ロードバランサー .->ingress[Ingress, 178.91.123.132]; + ingress-->|Host: foo.bar.com|service1[Service service1:80]; + ingress-->|Host: bar.foo.com|service2[Service service2:80]; + subgraph cluster[クラスター] + ingress; + service1-->pod1[Pod]; + service1-->pod2[Pod]; + service2-->pod3[Pod]; + service2-->pod4[Pod]; + end + classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; + classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; + classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; + class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s; + class client plain; + class cluster cluster; +{{}} 以下のIngress設定は、ロードバランサーに対して、[Hostヘッダー](https://tools.ietf.org/html/rfc7230#section-5.4)に基づいてリクエストを転送するように指示するものです。 -```yaml -apiVersion: networking.k8s.io/v1beta1 -kind: Ingress -metadata: - name: name-virtual-host-ingress -spec: - rules: - - host: foo.bar.com - http: - paths: - - backend: - serviceName: service1 - servicePort: 80 - - host: bar.foo.com - http: - paths: - - backend: - serviceName: service2 - servicePort: 80 -``` +{{< codenew file="service/networking/name-virtual-host-ingress.yaml" >}} rules項目でのホストの設定がないIngressを作成すると、IngressコントローラーのIPアドレスに対するwebトラフィックは、要求されている名前ベースのバーチャルホストなしにマッチさせることができます。 -例えば、以下のIngressリソースは`first.bar.com`に対するトラフィックを`service1`へ、`second.foo.com`に対するトラフィックを`service2`へ、リクエストにおいてホスト名が指定されていない(リクエストヘッダーがないことを意味します)トラフィックは`service3`へ転送します。 +例えば、以下のIngressは`first.bar.com`に対するトラフィックを`service1`へ、`second.foo.com`に対するトラフィックを`service2`へ、リクエストにおいてホスト名が指定されていない(リクエストヘッダーがないことを意味します)トラフィックは`service3`へ転送します。 -```yaml -apiVersion: networking.k8s.io/v1beta1 -kind: Ingress -metadata: - name: name-virtual-host-ingress -spec: - rules: - - host: first.bar.com - http: - paths: - - backend: - serviceName: service1 - servicePort: 80 - - host: second.foo.com - http: - paths: - - backend: - serviceName: service2 - servicePort: 80 - - http: - paths: - - backend: - serviceName: service3 - servicePort: 80 -``` +{{< codenew file="service/networking/name-virtual-host-ingress-no-third-host.yaml" >}} ### TLS -TLSの秘密鍵と証明書を含んだ{{< glossary_tooltip term_id="secret" >}}を指定することにより、Ingressをセキュアにできます。現在Ingressは単一のTLSポートである443番ポートのみサポートし、TLS終端を行うことを想定しています。IngressのTLS設定のセクションで異なるホストを指定すると、それらのホストはSNI TLSエクステンション(IngressコントローラーがSNIをサポートしている場合)を介して指定されたホスト名に対し、同じポート上で多重化されます。TLSのSecretは`tls.crt`と`tls.key`というキーを含む必要があり、TLSを使用するための証明書と秘密鍵を含む値となります。以下がその例です。 +TLSの秘密鍵と証明書を含んだ{{< glossary_tooltip term_id="secret" >}}を指定することにより、Ingressをセキュアにできます。Ingressは単一のTLSポートである443番ポートのみサポートし、IngressでTLS終端を行うことを想定しています。IngressからServiceやPodへのトラフィックは平文です。IngressのTLS設定のセクションで異なるホストを指定すると、それらのホストはSNI TLSエクステンション(IngressコントローラーがSNIをサポートしている場合)を介して指定されたホスト名に対し、同じポート上で多重化されます。TLSのSecretは`tls.crt`と`tls.key`というキーを含む必要があり、TLSを使用するための証明書と秘密鍵を含む値となります。以下がその例です。 ```yaml apiVersion: v1 @@ -314,37 +328,25 @@ data: type: kubernetes.io/tls ``` -IngressでこのSecretを参照すると、クライアントとロードバランサー間の通信にTLSを使用するようIngressコントローラーに指示することになります。作成したTLS Secretは、`sslexample.foo.com`の完全修飾ドメイン名(FQDN)とも呼ばれる共通名(CN)を含む証明書から作成したものであることを確認する必要があります。 +IngressでこのSecretを参照すると、クライアントとロードバランサー間の通信にTLSを使用するようIngressコントローラーに指示することになります。作成したTLS Secretは、`https-example.foo.com`の完全修飾ドメイン名(FQDN)とも呼ばれる共通名(CN)を含む証明書から作成したものであることを確認する必要があります。 -```yaml -apiVersion: networking.k8s.io/v1beta1 -kind: Ingress -metadata: - name: tls-example-ingress -spec: - tls: - - hosts: - - sslexample.foo.com - secretName: testsecret-tls - rules: - - host: sslexample.foo.com - http: - paths: - - path: / - backend: - serviceName: service1 - servicePort: 80 -``` +{{< note >}} +デフォルトルールではTLSが機能しない可能性があることに注意してください。 +これは取り得る全てのサブドメインに対する証明書を発行する必要があるからです。 +そのため、`tls`セクションの`hosts`は`rules`セクションの`host`と明示的に一致する必要があります。 +{{< /note >}} + +{{< codenew file="service/networking/tls-example-ingress.yaml" >}} {{< note >}} サポートされるTLSの機能はIngressコントローラーによって違いがあります。利用する環境でTLSがどのように動作するかを理解するためには、[nginx](https://kubernetes.github.io/ingress-nginx/user-guide/tls/)や、[GCE](https://git.k8s.io/ingress-gce/README.md#frontend-https)、他のプラットフォーム固有のIngressコントローラーのドキュメントを確認してください。 {{< /note >}} -### 負荷分散 +### 負荷分散 {#load-balancing} Ingressコントローラーは、負荷分散アルゴリズムやバックエンドの重みスキームなど、すべてのIngressに適用されるいくつかの負荷分散ポリシーの設定とともにブートストラップされます。発展した負荷分散のコンセプト(例: セッションの永続化、動的重み付けなど)はIngressによってサポートされていません。代わりに、それらの機能はService用のロードバランサーを介して利用できます。 -Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください([nginx](https://git.k8s.io/ingress-nginx/README.md)、[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。 +Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください(例えば[nginx](https://git.k8s.io/ingress-nginx/README.md)、または[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。 ## Ingressの更新 @@ -385,16 +387,22 @@ spec: http: paths: - backend: - serviceName: service1 - servicePort: 80 + service: + name: service1 + port: + number: 80 path: /foo + pathType: Prefix - host: bar.baz.com http: paths: - backend: - serviceName: service2 - servicePort: 80 + service: + name: service2 + port: + number: 80 path: /foo + pathType: Prefix .. ``` @@ -430,11 +438,7 @@ Events: ## アベイラビリティーゾーンをまたいだ障害について -障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。複数のクラスターにおいてIngressをデプロイする方法の詳細に関しては[Kubernetes Cluster Federationのドキュメント](https://github.com/kubernetes-sigs/federation-v2)を参照してください。 - -## 将来追加予定の内容 - -Ingressと関連するリソースの今後の開発については[SIG Network](https://github.com/kubernetes/community/tree/master/sig-network)で行われている議論を確認してください。様々なIngressコントローラーの開発については[Ingress リポジトリー](https://github.com/kubernetes/ingress/tree/master)を確認してください。 +障害のあるドメインをまたいでトラフィックを分散する手法は、クラウドプロバイダーによって異なります。詳細に関して、[Ingress コントローラー](/ja/docs/concepts/services-networking/ingress-controllers)のドキュメントを参照してください。 ## Ingressの代替案 {#alternatives} @@ -447,4 +451,4 @@ Ingressリソースを直接含まない複数の方法でサービスを公開 ## {{% heading "whatsnext" %}} * [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)について学ぶ * [Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)について学ぶ -* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube) +* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube/) diff --git a/content/ja/docs/concepts/services-networking/network-policies.md b/content/ja/docs/concepts/services-networking/network-policies.md index 61a798b947..441063aeae 100644 --- a/content/ja/docs/concepts/services-networking/network-policies.md +++ b/content/ja/docs/concepts/services-networking/network-policies.md @@ -6,9 +6,17 @@ weight: 50 -ネットワークポリシーは、{{< glossary_tooltip text="Pod" term_id="pod">}}のグループが、Pod相互や他のネットワークエンドポイントと通信する場合に許可を与える方法を指定するための仕様です。 +IPアドレスまたはポートのレベル(OSI参照モデルのレイヤ3または4)でトラフィックフローを制御したい場合、クラスター内の特定のアプリケーションにKubernetesのネットワークポリシーを使用することを検討してください。ネットワークポリシーはアプリケーション中心の構造であり、{{}}がネットワークを介して多様な「エンティティ」(「Endpoint」や「Service」のようなKubernetesに含まれる特定の意味を持つ共通の用語との重複を避けるため、ここではエンティティという単語を使用します。)と通信する方法を指定できます。 -NetworkPolicyリソースは、{{< glossary_tooltip text="ラベル" term_id="label">}}を使用してPodを選択し、選択したPodに対してどんなトラフィックを許可するかを指定するルールを定義します。 +Podが通信できるエンティティは以下の3つの識別子の組み合わせによって識別されます。 + +1. 許可されている他のPod(例外: Podはそれ自体へのアクセスをブロックできません) +2. 許可されている名前空間 +3. IPブロック(例外: PodまたはノードのIPアドレスに関係なく、Podが実行されているノードとの間のトラフィックは常に許可されます。) + +Podベースもしくは名前空間ベースのネットワークポリシーを定義する場合、{{}}を使用してセレクターに一致するPodとの間で許可されるトラフィックを指定します。 + +一方でIPベースのネットワークポリシーが作成されると、IPブロック(CIDRの範囲)に基づいてポリシーが定義されます。 ## 前提条件 @@ -186,14 +194,33 @@ __ipBlock__: 特定のIPのCIDRの範囲を選択して、ingressの送信元ま ## SCTPのサポート -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} -この機能を利用するには、クラスター管理者がAPIサーバーで`--feature-gates=SCTPSupport=true,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。フィーチャーゲートが有効になれば、NetworkPolicyの`protocol`フィールドに`SCTP`が指定できるようになります。 +ベータ版の機能として、これはデフォルトで有効化されます。 +クラスターレベルでSCTPを無効化するために、クラスター管理者はAPIサーバーで`--feature-gates=SCTPSupport=false,…`と指定して、`SCTPSupport`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を無効にする必要があります。 {{< note >}} SCTPプロトコルのネットワークポリシーをサポートする{{< glossary_tooltip text="CNI" term_id="cni" >}}プラグインを使用している必要があります。 {{< /note >}} +## ネットワークポリシーでできないこと(少なくともまだ) + +Kubernetes1.20現在、ネットワークポリシーAPIに以下の機能は存在しません。 +しかし、オペレーティングシステムのコンポーネント(SELinux、OpenVSwitch、IPTablesなど)、レイヤ7の技術(Ingressコントローラー、サービスメッシュ実装)、もしくはアドミッションコントローラーを使用して回避策を実装できる場合があります。 +Kubernetesのネットワークセキュリティを初めて使用する場合は、ネットワークポリシーAPIを使用して以下のユーザーストーリーを(まだ)実装できないことに注意してください。これらのユーザーストーリーの一部(全てではありません)は、ネットワークポリシーAPIの将来のリリースで活発に議論されています。 + +- クラスター内トラフィックを強制的に共通ゲートウェイを通過させる(これは、サービスメッシュもしくは他のプロキシで提供するのが最適な場合があります)。 +- TLS関連のもの(これにはサービスメッシュまたはIngressコントローラを使用します)。 +- ノードの固有のポリシー(これらにはCIDR表記を使用できますが、Kubernetesのアイデンティティでノードを指定することはできません)。 +- 名前空間またはサービスを名前で指定する(ただし、Podまたは名前空間を{{< glossary_tooltip text="ラベル" term_id="label" >}}で指定することができます。これは多くの場合で実行可能な回避策です)。 +- サードパーティによって実行される「ポリシー要求」の作成または管理 +- 全ての名前空間もしくはPodに適用されるデフォルトのポリシー(これを実現できるサードパーティのKubernetesディストリビューションとプロジェクトがいくつか存在します)。 +- 高度なポリシークエリと到達可能性ツール +- 単一のポリシー宣言でポートの範囲を指定する機能 +- ネットワークセキュリティイベント(例えばブロックされた接続や受け入れられた接続)をログに記録する機能 +- ポリシーを明示的に拒否する機能(現在、ネットワークポリシーのモデルはデフォルトで拒否されており、許可ルールを追加する機能のみが存在します)。 +- ループバックまたは内向きのホストトラフィックを拒否する機能(Podは現在localhostのアクセスやそれらが配置されているノードからのアクセスをブロックすることはできません)。 + ## {{% heading "whatsnext" %}} - [ネットワークポリシーを宣言する](/ja/docs/tasks/administer-cluster/declare-network-policy/)で追加の例の説明を読む。 diff --git a/content/ja/docs/concepts/services-networking/service.md b/content/ja/docs/concepts/services-networking/service.md index d6894e959e..f7273d45f1 100644 --- a/content/ja/docs/concepts/services-networking/service.md +++ b/content/ja/docs/concepts/services-networking/service.md @@ -23,7 +23,7 @@ KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセッ ## Serviceを利用する動機 -{{< glossary_tooltip term_id="pod" text="Pod" >}}は停止が想定して設計されています。 Podが作成され、もしそれらが停止する時、Podは再作成されません。 +Kubernetes {{< glossary_tooltip term_id="pod" text="Pod" >}}はクラスターの状態に合わせて作成され削除されます。Podは揮発的なリソースです。 {{< glossary_tooltip term_id="deployment" >}}をアプリケーションを稼働させるために使用すると、Podを動的に作成・削除してくれます。 各Podはそれ自身のIPアドレスを持ちます。しかしDeploymentでは、ある時点において同時に稼働しているPodのセットは、その後のある時点において稼働しているPodのセットとは異なる場合があります。 @@ -35,7 +35,8 @@ KubernetesはPodにそれぞれのIPアドレス割り振りや、Podのセッ ## Serviceリソース {#service-resource} Kubernetesにおいて、ServiceはPodの論理的なセットや、そのPodのセットにアクセスするためのポリシーを定義します(このパターンはよくマイクロサービスと呼ばることがあります)。 -ServiceによってターゲットとされたPodのセットは、たいてい {{< glossary_tooltip text="セレクター" term_id="selector" >}} (セレクターなしのServiceを利用したい場合は[下記](#services-without-selectors)を参照してください)によって定義されます。 +ServiceによってターゲットとされたPodのセットは、たいてい {{< glossary_tooltip text="セレクター" term_id="selector" >}}によって定義されます。 +その他の方法について知りたい場合は[セレクターなしのService](#services-without-selectors)を参照してください。 例えば、3つのレプリカが稼働しているステートレスな画像処理用のバックエンドを考えます。これらのレプリカは代替可能です。— フロントエンドはバックエンドが何であろうと気にしません。バックエンドのセットを構成する実際のPodのセットが変更された際、フロントエンドクライアントはその変更を気にしたり、バックエンドのPodのセットの情報を記録しておく必要はありません。 @@ -90,11 +91,11 @@ ServiceのデフォルトプロトコルはTCPです。また、他の[サポー Serviceは多くの場合、KubernetesのPodに対するアクセスを抽象化しますが、他の種類のバックエンドも抽象化できます。 例えば: - * プロダクション環境で外部のデータベースクラスターを利用したいが、テスト環境では、自身のクラスターが持つデータベースを利用したい場合 - * Serviceを、異なるNamespace内のServiceや他のクラスターのServiceに向ける場合 - * ワークロードをKubernetesに移行するとき、アプリケーションに対する処理をしながら、バックエンドの一部をKubernetesで実行する場合 +* プロダクション環境で外部のデータベースクラスターを利用したいが、テスト環境では、自身のクラスターが持つデータベースを利用したい場合 +* Serviceを、異なる{{< glossary_tooltip term_id="namespace" >}}のServiceや他のクラスターのServiceに向ける場合 +* ワークロードをKubernetesに移行するとき、アプリケーションに対する処理をしながら、バックエンドの一部をKubernetesで実行する場合 -このような場合において、ユーザーはPodセレクター_なしで_ Serviceを定義できます。 +このような場合において、ユーザーはPodセレクター*なしで*Serviceを定義できます。 ```yaml apiVersion: v1 @@ -137,20 +138,19 @@ link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6)に設 ExternalName Serviceはセレクターの代わりにDNS名を使用する特殊なケースのServiceです。さらなる情報は、このドキュメントの後で紹介する[ExternalName](#externalname)を参照ください。 ### エンドポイントスライス + {{< feature-state for_k8s_version="v1.17" state="beta" >}} エンドポイントスライスは、Endpointsに対してよりスケーラブルな代替手段を提供できるAPIリソースです。概念的にはEndpointsに非常に似ていますが、エンドポイントスライスを使用すると、ネットワークエンドポイントを複数のリソースに分割できます。デフォルトでは、エンドポイントスライスは、100個のエンドポイントに到達すると「いっぱいである」と見なされ、その時点で追加のエンドポイントスライスが作成され、追加のエンドポイントが保存されます。 -エンドポイントスライスは、[エンドポイントスライスのドキュメント](/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。 +エンドポイントスライスは、[エンドポイントスライスのドキュメント](/ja/docs/concepts/services-networking/endpoint-slices/)にて詳しく説明されている追加の属性と機能を提供します。 ### アプリケーションプロトコル -{{< feature-state for_k8s_version="v1.18" state="alpha" >}} - -AppProtocolフィールドは、各Serviceのポートで使用されるアプリケーションプロトコルを指定する方法を提供します。 - -アルファ機能のため、このフィールドはデフォルトで有効化されていません。このフィールドを使用するには、 `ServiceAppProtocol` という[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効化してください。 +{{< feature-state for_k8s_version="v1.19" state="beta" >}} +`AppProtocol`フィールドによってServiceの各ポートに対して特定のアプリケーションプロトコルを指定することができます。 +この値は、対応するEndpointsオブジェクトとEndpointSliceオブジェクトに反映されます。 ## 仮想IPとサービスプロキシー {#virtual-ips-and-service-proxies} Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。`kube-proxy`は[`ExternalName`](#externalname)タイプ以外の`Service`用に仮想IPを実装する責務があります。 @@ -162,9 +162,9 @@ Kubernetesクラスターの各Nodeは`kube-proxy`を稼働させています。 Serviceにおいてプロキシーを使う理由はいくつかあります。 - * DNSの実装がレコードのTTLをうまく扱わず、期限が切れた後も名前解決の結果をキャッシュするという長い歴史がある。 - * いくつかのアプリケーションではDNSルックアップを1度だけ行い、その結果を無期限にキャッシュする。 - * アプリケーションとライブラリーが適切なDNS名の再解決を行ったとしても、DNSレコード上の0もしくは低い値のTTLがDNSに負荷をかけることがあり、管理が難しい。 +* DNSの実装がレコードのTTLをうまく扱わず、期限が切れた後も名前解決の結果をキャッシュするという長い歴史がある。 +* いくつかのアプリケーションではDNSルックアップを1度だけ行い、その結果を無期限にキャッシュする。 +* アプリケーションとライブラリーが適切なDNS名の再解決を行ったとしても、DNSレコード上の0もしくは低い値のTTLがDNSに負荷をかけることがあり、管理が難しい。 ### user-spaceプロキシーモード {#proxy-mode-userspace} @@ -211,12 +211,12 @@ IPVSプロキシーモードはiptablesモードと同様に、netfilterのフ IPVSはバックエンドPodに対するトラフィックのバランシングのために多くのオプションを下記のとおりに提供します。 -- `rr`: ラウンドロビン -- `lc`: 最低コネクション数(オープンされているコネクション数がもっとも小さいもの) -- `dh`: 送信先IPによって割り当てられたハッシュ値をもとに割り当てる(Destination Hashing) -- `sh`: 送信元IPによって割り当てられたハッシュ値をもとに割り当てる(Source Hashing) -- `sed`: 見込み遅延が最小なもの -- `nq`: キューなしスケジューリング +* `rr`: ラウンドロビン +* `lc`: 最低コネクション数(オープンされているコネクション数がもっとも小さいもの) +* `dh`: 送信先IPによって割り当てられたハッシュ値をもとに割り当てる(Destination Hashing) +* `sh`: 送信元IPによって割り当てられたハッシュ値をもとに割り当てる(Source Hashing) +* `sed`: 見込み遅延が最小なもの +* `nq`: キューなしスケジューリング {{< note >}} IPVSモードでkube-proxyを稼働させるためには、kube-proxyを稼働させる前にNode上でIPVSを有効にしなければなりません。 @@ -282,7 +282,7 @@ PodがNode上で稼働するとき、kubeletはアクティブな各Serviceに これは[Docker links互換性](https://docs.docker.com/userguide/dockerlinks/)のある変数( [makeLinkVariables関数](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L72)を確認してください)や、より簡単な`{SVCNAME}_SERVICE_HOST`や、`{SVCNAME}_SERVICE_PORT`変数をサポートします。この変数名で使われるService名は大文字に変換され、`-`は`_`に変換されます。 -例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`"redis-master"`というServiceは、下記のような環境変数を生成します。 +例えば、TCPポート6379番を公開していて、さらにclusterIPが10.0.0.11に割り当てられている`redis-master`というServiceは、下記のような環境変数を生成します。 ```shell REDIS_MASTER_SERVICE_HOST=10.0.0.11 @@ -308,12 +308,12 @@ ServiceのclusterIPを発見するためにDNSのみを使う場合、このよ CoreDNSなどのクラスター対応のDNSサーバーは新しいServiceや、各Service用のDNSレコードのセットのためにKubernetes APIを常に監視します。 もしクラスターを通してDNSが有効になっている場合、全てのPodはDNS名によって自動的にServiceに対する名前解決をするようにできるはずです。 -例えば、Kubernetesの`"my-ns"`というNamespace内で`"my-service"`というServiceがある場合、KubernetesコントロールプレーンとDNS Serviceが協調して動作し、`"my-service.my-ns"`というDNSレコードを作成します。 -`"my-ns"`というNamespace内のPodは`my-service`という名前で簡単に名前解決できるはずです(`"my-service.my-ns"`でも動作します)。 +例えば、Kubernetesの`my-ns`というNamespace内で`my-service`というServiceがある場合、KubernetesコントロールプレーンとDNS Serviceが協調して動作し、`my-service.my-ns`というDNSレコードを作成します。 +`my-ns`というNamespace内のPodは`my-service`という名前で簡単に名前解決できるはずです(`my-service.my-ns`でも動作します)。 他のNamespace内でのPodは`my-service.my-ns`といった形で指定しなくてはなりません。これらのDNS名は、そのServiceのclusterIPに名前解決されます。 -Kubernetesは名前付きのポートに対するDNS SRV(Service)レコードもサポートしています。もし`"my-service.my-ns"`というServiceが`"http"`という名前のTCPポートを持っていた場合、IPアドレスと同様に、`"http"`のポート番号を探すために`_http._tcp.my-service.my-ns`というDNS SRVクエリを実行できます。 +Kubernetesは名前付きのポートに対するDNS SRV(Service)レコードもサポートしています。もし`my-service.my-ns`というServiceが`http`という名前のTCPポートを持っていた場合、IPアドレスと同様に、`http`のポート番号を探すために`_http._tcp.my-service.my-ns`というDNS SRVクエリを実行できます。 KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一の方法です。 [DNS Pods と Service](/ja/docs/concepts/services-networking/dns-pod-service/)にて`ExternalName`による名前解決に関するさらなる情報を確認できます。 @@ -337,8 +337,8 @@ KubernetesのDNSサーバーは`ExternalName` Serviceにアクセスする唯一 ラベルセレクターを定義しないHeadless Serviceにおいては、Endpointsコントローラーは`Endpoints`レコードを作成しません。 しかしDNSのシステムは下記の2つ両方を探索し、設定します。 - * [`ExternalName`](#externalname)タイプのServiceに対するCNAMEレコード - * 他の全てのServiceタイプを含む、Service名を共有している全ての`Endpoints`レコード +* [`ExternalName`](#externalname)タイプのServiceに対するCNAMEレコード +* 他の全てのServiceタイプを含む、Service名を共有している全ての`Endpoints`レコード ## Serviceの公開 (Serviceのタイプ) {#publishing-services-service-types} @@ -349,16 +349,15 @@ Kubernetesの`ServiceTypes`によって、ユーザーがどのような種類 `Type`項目の値と、そのふるまいは以下のようになります。 - * `ClusterIP`: クラスター内部のIPでServiceを公開する。このタイプではServiceはクラスター内部からのみ疎通性があります。このタイプはデフォルトの`ServiceType`です。 - * [`NodePort`](#nodeport): 各NodeのIPにて、静的なポート(`NodePort`)上でServiceを公開します。その`NodePort` のServiceが転送する先の`ClusterIP` Serviceが自動的に作成されます。`:`にアクセスすることによって`NodePort` Serviceにアクセスできるようになります。 - * [`LoadBalancer`](#loadbalancer): クラウドプロバイダーのロードバランサーを使用して、Serviceを外部に公開します。クラスター外部にあるロードバランサーが転送する先の`NodePort`と`ClusterIP` Serviceは自動的に作成されます。 - * [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。 +* `ClusterIP`: クラスター内部のIPでServiceを公開する。このタイプではServiceはクラスター内部からのみ疎通性があります。このタイプはデフォルトの`ServiceType`です。 +* [`NodePort`](#nodeport): 各NodeのIPにて、静的なポート(`NodePort`)上でServiceを公開します。その`NodePort` のServiceが転送する先の`ClusterIP` Serviceが自動的に作成されます。`:`にアクセスすることによって`NodePort` Serviceにアクセスできるようになります。 +* [`LoadBalancer`](#loadbalancer): クラウドプロバイダーのロードバランサーを使用して、Serviceを外部に公開します。クラスター外部にあるロードバランサーが転送する先の`NodePort`と`ClusterIP` Serviceは自動的に作成されます。 +* [`ExternalName`](#externalname): `CNAME`レコードを返すことにより、`externalName`フィールドに指定したコンテンツ(例: `foo.bar.example.com`)とServiceを紐づけます。しかし、いかなる種類のプロキシーも設定されません。 + {{< note >}} + `ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.0.8以上が必要となります。 + {{< /note >}} - {{< note >}} - `ExternalName`タイプのServiceを利用するためには、kube-dnsのバージョン1.7かCoreDNSのバージョン0.0.8以上が必要となります。 - {{< /note >}} - -また、Serviceを公開するために[Ingress](/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。 +また、Serviceを公開するために[Ingress](/ja/docs/concepts/services-networking/ingress/)も利用可能です。IngressはServiceのタイプではありませんが、クラスターに対するエントリーポイントとして動作します。 Ingressは同一のIPアドレスにおいて、複数のServiceを公開するように、ユーザーの設定した転送ルールを1つのリソースにまとめることができます。 ### NodePort タイプ {#nodeport} @@ -461,6 +460,7 @@ Split-HorizonなDNS環境において、ユーザーは2つのServiceを外部 タブを選択してください。 {{% /tab %}} {{% tab name="GCP" %}} + ```yaml [...] metadata: @@ -469,8 +469,10 @@ metadata: cloud.google.com/load-balancer-type: "Internal" [...] ``` + {{% /tab %}} {{% tab name="AWS" %}} + ```yaml [...] metadata: @@ -479,8 +481,10 @@ metadata: service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0 [...] ``` + {{% /tab %}} {{% tab name="Azure" %}} + ```yaml [...] metadata: @@ -489,8 +493,10 @@ metadata: service.beta.kubernetes.io/azure-load-balancer-internal: "true" [...] ``` + {{% /tab %}} {{% tab name="IBM Cloud" %}} + ```yaml [...] metadata: @@ -502,6 +508,7 @@ metadata: {{% /tab %}} {{% tab name="OpenStack" %}} + ```yaml [...] metadata: @@ -510,8 +517,10 @@ metadata: service.beta.kubernetes.io/openstack-internal-load-balancer: "true" [...] ``` + {{% /tab %}} {{% tab name="Baidu Cloud" %}} + ```yaml [...] metadata: @@ -520,8 +529,10 @@ metadata: service.beta.kubernetes.io/cce-load-balancer-internal-vpc: "true" [...] ``` + {{% /tab %}} {{% tab name="Tencent Cloud" %}} + ```yaml [...] metadata: @@ -529,6 +540,7 @@ metadata: service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxx [...] ``` + {{% /tab %}} {{< /tabs >}} @@ -675,8 +687,16 @@ AWS上でのELB Service用のアクセスログを管理するためにはいく # この値はservice.beta.kubernetes.io/aws-load-balancer-healthcheck-intervalの値以下である必要があります。 # デフォルトでは5 この値は2から60の間で設定可能 + service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f" + # ELBが作成される際に追加されるセキュリティグループのリスト + # service.beta.kubernetes.io/aws-load-balancer-extra-security-groupsアノテーションと異なり + # 元々ELBに付与されていたセキュリティグループを置き換えることになります。 + service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e" # ELBに追加される予定のセキュリティーグループのリスト + + service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api" + # ロードバランサーがターゲットノードを指定する際に利用するキーバリューのペアのコンマ区切りリストです。 ``` #### AWSでのNetwork Load Balancerのサポート {#aws-nlb-support} @@ -738,8 +758,9 @@ spec: annotations: # 指定したノードでロードバランサーをバインドします service.kubernetes.io/qcloud-loadbalancer-backends-label: key in (value1, value2) + # 既存のロードバランサーのID - service.kubernetes.io/tke-existed-lbid:lb-6swtxxxx + service.kubernetes.io/tke-existed-lbid: lb-6swtxxxx # ロードバランサー(LB)のカスタムパラメーターは、LBタイプの変更をまだサポートしていません service.kubernetes.io/service.extensiveParameters: "" @@ -750,11 +771,14 @@ spec: # ロードバランサーのタイプを指定します # 有効な値: classic(Classic Cloud Load Balancer)またはapplication(Application Cloud Load Balancer) service.kubernetes.io/loadbalance-type: xxxxx + # パブリックネットワーク帯域幅の課金方法を指定します # 有効な値: TRAFFIC_POSTPAID_BY_HOUR(bill-by-traffic)およびBANDWIDTH_POSTPAID_BY_HOUR(bill-by-bandwidth) service.kubernetes.io/qcloud-loadbalancer-internet-charge-type: xxxxxx + # 帯域幅の値を指定します(値の範囲:[1-2000] Mbps)。 service.kubernetes.io/qcloud-loadbalancer-internet-max-bandwidth-out: "10" + # この注釈が設定されている場合、ロードバランサーはポッドが実行されているノードのみを登録します # そうでない場合、すべてのノードが登録されます service.kubernetes.io/local-svc-only-bind-node-with-pod: true @@ -777,6 +801,7 @@ spec: type: ExternalName externalName: my.database.example.com ``` + {{< note >}} ExternalNameはIpv4のアドレスの文字列のみ受け付けますが、IPアドレスではなく、数字で構成されるDNS名として受け入れます。 IPv4アドレスに似ているExternalNamesはCoreDNSもしくはIngress-Nginxによって名前解決されず、これはExternalNameは正規のDNS名を指定することを目的としているためです。 @@ -857,7 +882,7 @@ Kubernetesは各Serviceに、それ自身のIPアドレスを割り当てるこ ### ServiceのIPアドレス {#ips-and-vips} 実際に固定された向き先であるPodのIPアドレスとは異なり、ServiceのIPは実際には単一のホストによって応答されません。 -その代わり、kube-proxyは必要な時に透過的にリダイレクトされる_仮想_ IPアドレスを定義するため、iptables(Linuxのパケット処理ロジック)を使用します。 +その代わり、kube-proxyは必要な時に透過的にリダイレクトされる*仮想*IPアドレスを定義するため、iptables(Linuxのパケット処理ロジック)を使用します。 クライアントがVIPに接続する時、そのトラフィックは自動的に適切なEndpointsに転送されます。 Service用の環境変数とDNSは、Serviceの仮想IPアドレス(とポート)の面において、自動的に生成されます。 @@ -914,12 +939,12 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで もしクラウドプロバイダーがサポートしている場合、ServiceのEndpointsに転送される外部のHTTP/HTTPSでのリバースプロキシーをセットアップするために、LoadBalancerモードでServiceを作成可能です。 {{< note >}} -ユーザーはまた、HTTP / HTTPS Serviceを公開するために、Serviceの代わりに{{< glossary_tooltip term_id="ingress" >}}を利用することもできます。 +ユーザーはまた、HTTP/HTTPS Serviceを公開するために、Serviceの代わりに{{< glossary_tooltip term_id="ingress" >}}を利用することもできます。 {{< /note >}} ### PROXY プロトコル -もしクラウドプロバイダーがサポートしている場合(例: [AWS](/docs/concepts/cluster-administration/cloud-providers/#aws))、Kubernetesクラスターの外部のロードバランサーを設定するためにLoadBalancerモードでServiceを利用できます。これは[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)がついた接続を転送します。 +もしクラウドプロバイダーがサポートしている場合、Kubernetesクラスターの外部のロードバランサーを設定するためにLoadBalancerモードでServiceを利用できます。これは[PROXY protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)がついた接続を転送します。 ロードバランサーは、最初の一連のオクテットを送信します。 下記のような例となります。 @@ -927,15 +952,16 @@ ServiceはKubernetesのREST APIにおいてトップレベルのリソースで ``` PROXY TCP4 192.0.2.202 10.0.42.7 12345 7\r\n ``` + クライアントからのデータのあとに追加されます。 ### SCTP -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} +{{< feature-state for_k8s_version="v1.19" state="beta" >}} -KubernetesはService、Endpoints、NetworkPolicyとPodの定義においてα版の機能として`protocol`フィールドの値でSCTPをサポートしています。この機能を有効にするために、クラスター管理者はAPI Serverにおいて`SCTPSupport`というフィーチャーゲートを有効にする必要があります。例えば、`--feature-gates=SCTPSupport=true,…`といったように設定します。 +KubernetesはService、Endpoints、EndpointSlice、NetworkPolicyとPodの定義において`protocol`フィールドの値でSCTPをサポートしています。ベータ版の機能のため、この機能はデフォルトで有効になっています。SCTPをクラスターレベルで無効にするには、クラスター管理者はAPI Serverにおいて`SCTPSupport` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を`--feature-gates=SCTPSupport=false,…`と設定して無効にする必要があります。 -そのフィーチャーゲートが有効になった時、ユーザーはService、Endpoints、NetworkPolicyの`protocol`フィールドと、Podの`SCTP`フィールドを設定できます。 +そのフィーチャーゲートが有効になった時、ユーザーはService、Endpoints、EndpointSlice、NetworkPolicy、またはPodの`protocol`フィールドに`SCTP`を設定できます。 Kubernetesは、TCP接続と同様に、SCTPアソシエーションに応じてネットワークをセットアップします。 #### 警告 {#caveat-sctp-overview} @@ -967,11 +993,8 @@ SCTPはWindowsベースのNodeではサポートされていません。 kube-proxyはuserspaceモードにおいてSCTPアソシエーションの管理をサポートしません。 {{< /warning >}} - - ## {{% heading "whatsnext" %}} - -* [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/)を参照してください。 -* [Ingress](/docs/concepts/services-networking/ingress/)を参照してください。 -* [EndpointSlices](/docs/concepts/services-networking/endpoint-slices/)を参照してください。 +* [Connecting Applications with Services](/ja/docs/concepts/services-networking/connect-applications-service/)を参照してください。 +* [Ingress](/ja/docs/concepts/services-networking/ingress/)を参照してください。 +* [EndpointSlices](/ja/docs/concepts/services-networking/endpoint-slices/)を参照してください。 diff --git a/content/ja/docs/concepts/storage/_index.md b/content/ja/docs/concepts/storage/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/concepts/storage/dynamic-provisioning.md b/content/ja/docs/concepts/storage/dynamic-provisioning.md index 4fb1908a6c..4cb9855a63 100644 --- a/content/ja/docs/concepts/storage/dynamic-provisioning.md +++ b/content/ja/docs/concepts/storage/dynamic-provisioning.md @@ -54,7 +54,7 @@ parameters: ユーザーは`PersistentVolumeClaim`リソース内でStorageClassを含むことで、動的にプロビジョンされたStorageをリクエストできます。Kubernetes v1.6以前では、この機能は`volume.beta.kubernetes.io/storage-class`アノテーションを介して使うことができました。しかしこのアノテーションではv1.6から廃止になりました。その代わりユーザーは現在では`PersistentVolumeClaim`オブジェクトの`storageClassName`を使う必要があります。このフィールドの値は、管理者によって設定された`StorageClass`の名前と一致しなければなりません([下記](#enabling-dynamic-provisioning)のセクションも参照ください)。 -"fast"というStorageClassを選択するために、例としてユーザーは下記の`PersistentVolumeClaim`を作成します。 +"fast"というStorageClassを選択するために、例としてユーザーは下記のPersistentVolumeClaimを作成します。 ```yaml apiVersion: v1 diff --git a/content/ja/docs/concepts/storage/persistent-volumes.md b/content/ja/docs/concepts/storage/persistent-volumes.md index 24bcea4ee5..b22ed7d8eb 100644 --- a/content/ja/docs/concepts/storage/persistent-volumes.md +++ b/content/ja/docs/concepts/storage/persistent-volumes.md @@ -162,6 +162,49 @@ spec: ``` ただし、カスタムリサイクラーPodテンプレートの`volumes`パート内で指定された特定のパスは、リサイクルされるボリュームの特定のパスに置き換えられます。 +### 永続ボリュームの予約 + +コントロールプレーンは、永続ボリュームクレームをクラスター内の一致する永続ボリュームに[バインド](#バインディング)できます。 +ただし、永続ボリュームクレームを特定の永続ボリュームにバインドする場合、それらを事前にバインドする必要があります。 + +永続ボリュームクレームで永続ボリュームを指定することにより、その特定の永続ボリュームと永続ボリュームクレームの間のバインディングを宣言します。 +永続ボリュームが存在し、その`claimRef`フィールドで永続ボリュームクレームを予約していない場合に永続ボリュームと永続ボリュームクレームがバインドされます。 + +バインディングは、ノードアフィニティを含むいくつかのボリュームの一致基準に関係なく発生します。 +コントロールプレーンは、依然として[ストレージクラス](/docs/concepts/storage/storage-classes/)、アクセスモード、および要求されたストレージサイズが有効であることをチェックします。 + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: foo-pvc + namespace: foo +spec: + storageClassName: "" # 空の文字列を明示的に指定する必要があります。そうしないとデフォルトのストレージクラスが設定されてしまいます。 + volumeName: foo-pv + ... +``` + +この方法は、永続ボリュームへのバインド特権を保証するものではありません。 +他の永続ボリュームクレームが指定した永続ボリュームを使用できる場合、最初にそのストレージボリュームを予約する必要があります。 +永続ボリュームの`claimRef`フィールドに関連する永続ボリュームクレームを指定して、他の永続ボリュームクレームがその永続ボリュームにバインドできないようにしてください。 + + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: foo-pv +spec: + storageClassName: "" + claimRef: + name: foo-pvc + namespace: foo + ... +``` + +これは、既存の永続ボリュームを再利用する場合など、`claimPolicy`が`Retain`に設定されている永続ボリュームを使用する場合に役立ちます。 + ### 永続ボリュームクレームの拡大 {{< feature-state for_k8s_version="v1.11" state="beta" >}} @@ -247,26 +290,32 @@ EBSの拡張は時間がかかる操作です。また変更は、ボリュー PersistentVolumeの種類はプラグインとして実装されます。Kubernetesは現在次のプラグインに対応しています。 -* GCEPersistentDisk -* AWSElasticBlockStore -* AzureFile -* AzureDisk -* CSI -* FC (Fibre Channel) -* FlexVolume -* Flocker -* NFS -* iSCSI -* RBD (Ceph Block Device) -* CephFS -* Cinder (OpenStack block storage) -* Glusterfs -* VsphereVolume -* Quobyte Volumes -* HostPath (テスト用の単一ノードのみ。ローカルストレージはどのような方法でもサポートされておらず、またマルチノードクラスターでは動作しません) -* Portworx Volumes -* ScaleIO Volumes -* StorageOS +* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS) +* [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk) - Azure Disk +* [`azureFile`](/docs/concepts/storage/volumes/#azurefile) - Azure File +* [`cephfs`](/docs/concepts/storage/volumes/#cephfs) - CephFS volume +* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage) + (**非推奨**) +* [`csi`](/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI) +* [`fc`](/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage +* [`flexVolume`](/docs/concepts/storage/volumes/#flexVolume) - FlexVolume +* [`flocker`](/docs/concepts/storage/volumes/#flocker) - Flocker storage +* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk +* [`glusterfs`](/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume +* [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume + (テスト用の単一ノードのみ。マルチノードクラスターでは動作しません。代わりに`local`ボリュームを利用することを検討してください。) +* [`iscsi`](/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage +* [`local`](/docs/concepts/storage/volumes/#local) - ノードにマウントされたローカルストレージデバイス +* [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage +* `photonPersistentDisk` - Photon controller persistent disk + (対応するクラウドプロバイダーが削除されたため、このボリュームタイプは機能しなくなりました。) +* [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Portworx volume +* [`quobyte`](/docs/concepts/storage/volumes/#quobyte) - Quobyte volume +* [`rbd`](/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) volume +* [`scaleIO`](/docs/concepts/storage/volumes/#scaleio) - ScaleIO volume + (**非推奨**) +* [`storageos`](/docs/concepts/storage/volumes/#storageos) - StorageOS volume +* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK volume ## 永続ボリューム @@ -382,7 +431,7 @@ PVはクラスを持つことができます。これは`storageClassName`属性 ### マウントオプション -Kubernets管理者は永続ボリュームがNodeにマウントされるときの追加マウントオプションを指定できます。 +Kubernetes管理者は永続ボリュームがNodeにマウントされるときの追加マウントオプションを指定できます。 {{< note >}} すべての永続ボリュームタイプがすべてのマウントオプションをサポートするわけではありません。 diff --git a/content/ja/docs/concepts/workloads/_index.md b/content/ja/docs/concepts/workloads/_index.md index 41bb9d33d2..ca846cd0e7 100644 --- a/content/ja/docs/concepts/workloads/_index.md +++ b/content/ja/docs/concepts/workloads/_index.md @@ -1,5 +1,37 @@ --- title: "ワークロード" weight: 50 +description: > + Kubernetesにおけるデプロイ可能な最小のオブジェクトであるPodと、高レベルな抽象化がPodの実行を助けることを理解します。 +no_list: true --- +{{< glossary_definition term_id="workload" length="short" >}} +ワークロードが1つのコンポーネントからなる場合でも、複数のコンポーネントが協調して動作する場合でも、Kubernetesではそれらは[Pod](/ja/docs/concepts/workloads/pods)の集合として実行されます。Kubernetesでは、Podはクラスター上で実行中の{{< glossary_tooltip text="コンテナ" term_id="container" >}}の集合として表されます。 + +Podには定義されたライフサイクルがあります。たとえば、一度Podがクラスター上で実行中になると、そのPodが実行中の{{< glossary_tooltip text="ノード" term_id="node" >}}上で深刻な障害が起こったとき、そのノード上のすべてのPodは停止してしまうことになります。Kubernetesではそのようなレベルの障害を最終的なものとして扱うため、たとえノードが後で復元したとしても、ユーザーは新しいPodを作成し直す必要があります。 + +しかし、生活をかなり楽にするためには、それぞれのPodを直接管理する必要はありません。_ワークロードリソース_ を利用すれば、あなたの代わりにPodの集合の管理を行ってもらえます。これらのリソースはあなたが指定した状態に一致するように{{< glossary_tooltip term_id="controller" text="コントローラー" >}}を設定し、正しい種類のPodが正しい数だけ実行中になることを保証してくれます。 + +ワークロードリソースには、次のような種類があります。 + +* [Deployment](/ja/docs/concepts/workloads/controllers/deployment/)と[ReplicaSet](/ja/docs/concepts/workloads/controllers/replicaset/)(レガシーなリソース{{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}を置き換えるものです) +* [StatefulSet](/ja/docs/concepts/workloads/controllers/statefulset/) +* [DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)(ストレージドライバやネットワークプラグインなど、ノードローカルな機能を提供するためのPodを実行するために使われます) +* [Job](/docs/concepts/workloads/controllers/job/)と[CronJob](/ja/docs/concepts/workloads/controllers/cron-jobs/)(実行後に完了するようなタスクのために使われます) + +多少関連のある2種類の補助的な概念もあります。 +* [ガベージコレクション](/ja/docs/concepts/workloads/controllers/garbage-collection/)は、オブジェクトが _所有するリソース_ が削除された後に、そのオブジェクトをクラスターからクリーンアップします。 +* [終了したリソースのためのTTLコントローラー](/ja/docs/concepts/workloads/controllers/ttlafterfinished/)は、Jobの完了後、定義した時間が経過した後にJobを削除します。 + +## {{% heading "whatsnext" %}} + +各リソースについて読む以外にも、以下のページでそれぞれのワークロードに関連する特定のタスクについて学ぶことができます。 + +* [Deploymentを使用してステートレスアプリケーションを実行する](/ja/docs/tasks/run-application/run-stateless-application-deployment/) +* [単一レプリカ](/ja/docs/tasks/run-application/run-single-instance-stateful-application/)または[レプリカセット](/ja/docs/tasks/run-application/run-replicated-stateful-application/)のいずれかとしてステートフルなアプリケーションを実行する +* [CronJobを使用して自動タスクを実行する](/ja/docs/tasks/job/automated-tasks-with-cron-jobs/) + +アプリケーションが実行できるようになったら、インターネット上で公開したくなるかもしれません。その場合には、[Service](/ja/docs/concepts/services-networking/service/)として公開したり、ウェブアプリケーションだけの場合、[Ingress](/ja/docs/concepts/services-networking/ingress)を使用することができます。 + +コードを設定から分離するKubernetesのしくみについて学ぶには、[設定](/ja/docs/concepts/configuration/)を読んでください。 diff --git a/content/ja/docs/concepts/workloads/controllers/_index.md b/content/ja/docs/concepts/workloads/controllers/_index.md index 65c91d6280..86a36414a2 100644 --- a/content/ja/docs/concepts/workloads/controllers/_index.md +++ b/content/ja/docs/concepts/workloads/controllers/_index.md @@ -1,4 +1,4 @@ --- -title: "コントローラー" +title: "ワークロードリソース" weight: 20 --- diff --git a/content/ja/docs/concepts/workloads/controllers/daemonset.md b/content/ja/docs/concepts/workloads/controllers/daemonset.md index 363a549997..7d2d55febb 100644 --- a/content/ja/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ja/docs/concepts/workloads/controllers/daemonset.md @@ -70,8 +70,6 @@ Kubernetes1.8のように、ユーザーは`.spec.template`のラベルにマッ もし`spec.selector`が指定されたとき、`.spec.template.metadata.labels`とマッチしなければなりません。この2つの値がマッチしない設定をした場合、APIによってリジェクトされます。 -また、ユーザーは通常、別のDaemonSetやReplicaSetなどの別のワークロードリソースを使用する場合であっても直接であっても、このセレクターマッチするラベルを持つPodを作成すべきではありません。さもないと、DaemonSet {{}}は、それらのPodが作成されたものとみなすためです。Kubernetesはこれを行うことを止めません。ユーザーがこれを行いたい1つのケースとしては、テスト用にノード上に異なる値を持つPodを手動で作成するような場合があります。 - ### 選択したNode上でPodを稼働させる もしユーザーが`.spec.template.spec.nodeSelector`を指定したとき、DaemonSetコントローラーは、その[node diff --git a/content/ja/docs/concepts/workloads/controllers/deployment.md b/content/ja/docs/concepts/workloads/controllers/deployment.md index e2d720323d..de2388ebee 100644 --- a/content/ja/docs/concepts/workloads/controllers/deployment.md +++ b/content/ja/docs/concepts/workloads/controllers/deployment.md @@ -95,7 +95,7 @@ Deploymentによって作成されたReplicaSetを管理しないでください コマンドの実行結果は以下のとおりです。 ```shell Waiting for rollout to finish: 2 out of 3 new replicas have been updated... - deployment.apps/nginx-deployment successfully rolled out + deployment "nginx-deployment" successfully rolled out ``` 4. 数秒後、再度`kubectl get deployments`を実行してください。 @@ -194,7 +194,7 @@ Deploymentを更新するには以下のステップに従ってください。 ``` もしくは ``` - deployment.apps/nginx-deployment successfully rolled out + deployment "nginx-deployment" successfully rolled out ``` 更新されたDeploymentのさらなる情報を取得するには、以下を確認してください。 @@ -788,7 +788,7 @@ kubectl rollout status deployment.v1.apps/nginx-deployment 実行結果は以下のとおりです。 ``` Waiting for rollout to finish: 2 of 3 updated replicas are available... -deployment.apps/nginx-deployment successfully rolled out +deployment "nginx-deployment" successfully rolled out ``` そして`kubectl rollout`の終了ステータスが0となります（成功です）: ```shell diff --git a/content/ja/docs/concepts/workloads/controllers/garbage-collection.md b/content/ja/docs/concepts/workloads/controllers/garbage-collection.md index 3a1e630d20..cd7f4bf25e 100644 --- a/content/ja/docs/concepts/workloads/controllers/garbage-collection.md +++ b/content/ja/docs/concepts/workloads/controllers/garbage-collection.md @@ -124,7 +124,7 @@ kubectl delete replicaset my-repset --cascade=false ### Deploymentsに関する追記事項 -Kubernetes1.7以前では、Deploymentに対するカスケード削除において、作成されたReplicaSetだけでなく、それらのPodも削除するためには、ユーザーは`propagationPolicy: Foreground`と指定*しなくてはなりません* 。もしこのタイプの_propagationPolicy_ が使われなかった場合、そのReplicaSetは削除されますが、そのPodは削除されずみなしご状態になります。 +Kubernetes1.7以前では、Deploymentに対するカスケード削除において、作成されたReplicaSetだけでなく、それらのPodも削除するためには、ユーザーは`propagationPolicy: Foreground`と指定*しなくてはなりません* 。もしこのタイプの*propagationPolicy*が使われなかった場合、そのReplicaSetは削除されますが、そのPodは削除されずみなしご状態になります。 さらなる詳細に関しては[kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613)を参照してください。 ## 既知の問題について diff --git a/content/ja/docs/concepts/workloads/controllers/replicaset.md b/content/ja/docs/concepts/workloads/controllers/replicaset.md index 9f8ccfc377..f2317706cf 100644 --- a/content/ja/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ja/docs/concepts/workloads/controllers/replicaset.md @@ -197,7 +197,7 @@ ReplicaSetオブジェクトの名前は、有効な ### Pod テンプレート -`.spec.template`はラベルを持つことが必要な[Pod テンプレート](/ja/docs/concepts/workloads/pods/pod-overview/#podテンプレート) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。 +`.spec.template`はラベルを持つことが必要な[Pod テンプレート](/ja/docs/concepts/workloads/pods/#podテンプレート) です。先ほど作成した`frontend.yaml`の例では、`tier: frontend`というラベルを1つ持っています。 他のコントローラーがこのPodを所有しようとしないためにも、他のコントローラーのセレクターでラベルを上書きしないように注意してください。 テンプレートの[再起動ポリシー](/docs/concepts/workloads/Pods/pod-lifecycle/#restart-policy)のためのフィールドである`.spec.template.spec.restartPolicy`は`Always`のみ許可されていて、そしてそれがデフォルト値です。 @@ -300,7 +300,7 @@ ReplicaSetは、Node上のいくつかのエージェント(例えば、Kubelet ### Job -PodをPodそれ自身で停止させたいような場合(例えば、バッチ用のジョブなど)は、ReplicaSetの代わりに[`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/)を使用してください。 +PodをPodそれ自身で停止させたいような場合(例えば、バッチ用のジョブなど)は、ReplicaSetの代わりに[`Job`](/docs/concepts/workloads/controllers/job/)を使用してください。 ### DaemonSet diff --git a/content/ja/docs/concepts/workloads/pods/_index.md b/content/ja/docs/concepts/workloads/pods/_index.md old mode 100755 new mode 100644 index 7f62f167e8..de7ba27148 --- a/content/ja/docs/concepts/workloads/pods/_index.md +++ b/content/ja/docs/concepts/workloads/pods/_index.md @@ -1,4 +1,160 @@ --- title: "Pod" +content_type: concept weight: 10 +no_list: true +card: + name: concepts + weight: 60 --- + +*Pod*は、Kubernetes内で作成・管理できるコンピューティングの最小のデプロイ可能なユニットです(Podという名前は、たとえばクジラの群れ(pod of whales)やえんどう豆のさや(pea pod)などの表現と同じような意味です)。 + +*Pod*は、1つまたは複数の{{< glossary_tooltip text="コンテナ" term_id="container" >}}のグループであり、ストレージやネットワークの共有リソースを持ち、コンテナの実行方法に関する仕様を持っています。同じPodに含まれるリソースは、常に同じ場所で同時にスケジューリングされ、共有されたコンテキストの中で実行されます。Podはアプリケーションに特化した「論理的なホスト」をモデル化します。つまり、1つのPod内には、1つまたは複数の比較的密に結合されたアプリケーションコンテナが含まれます。クラウド外の文脈で説明すると、アプリケーションが同じ物理ホストや同じバーチャルマシンで実行されることが、クラウドアプリケーションの場合には同じ論理ホスト上で実行されることに相当します。 + +アプリケーションコンテナと同様に、Podでも、Podのスタートアップ時に実行される[initコンテナ](/ja/docs/concepts/workloads/pods/init-containers/)を含めることができます。また、クラスターで利用できる場合には、[エフェメラルコンテナ](/ja/docs/concepts/workloads/pods/ephemeral-containers/)を注入してデバッグすることもできます。 + + + +## Podとは何か？ + +{{< note >}} +KubernetesはDockerだけでなく複数の{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}をサポートしていますが、[Docker](https://www.docker.com/)が最も一般的に知られたランタイムであるため、Docker由来の用語を使ってPodを説明するのが理解の助けとなります。 +{{< /note >}} + +Podの共有コンテキストは、Dockerコンテナを隔離するのに使われているのと同じ、Linuxのnamespaces、cgroups、場合によっては他の隔離技術の集合を用いて作られます。Podのコンテキスト内では、各アプリケーションが追加の準隔離技術を適用することもあります。 + +Dockerの概念を使って説明すると、Podは共有の名前空間と共有ファイルシステムのボリュームを持つDockerコンテナのグループに似ています。 + +## Podを使用する + +通常、たとえ単一のコンテナしか持たないシングルトンのPodだとしても、自分でPodを直接作成する必要はありません。その代わりに、{{< glossary_tooltip text="Deployment" +term_id="deployment" >}}や{{< glossary_tooltip text="Job" term_id="job" >}}などのワークロードリソースを使用してPodを作成します。もしPodが状態を保持する必要がある場合は、{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}リソースを使用することを検討してください。 + +Kubernetesクラスター内のPodは、主に次の2種類の方法で使われます。 + +* **単一のコンテナを稼働させるPod**。「1Pod1コンテナ」構成のモデルは、Kubernetesでは最も一般的なユースケースです。このケースでは、ユーザーはPodを単一のコンテナのラッパーとして考えることができます。Kubernetesはコンテナを直接管理するのではなく、Podを管理します。 +* **協調して稼働させる必要がある複数のコンテナを稼働させるPod**。単一のPodは、密に結合してリソースを共有する必要があるような、同じ場所で稼働する複数のコンテナからなるアプリケーションをカプセル化することもできます。これらの同じ場所で稼働するコンテナ群は、単一のまとまりのあるサービスのユニットを構成します。たとえば、1つのコンテナが共有ボリュームからファイルをパブリックに配信し、別の*サイドカー*コンテナがそれらのファイルを更新するという構成が考えられます。Podはこれらの複数のコンテナ、ストレージリソース、一時的なネットワークIDなどを、単一のユニットとしてまとめます。 + + {{< note >}} + 複数のコンテナを同じ場所で同時に管理するように単一のPod内にグループ化するのは、比較的高度なユースケースです。このパターンを使用するのは、コンテナが密に結合しているような特定のインスタンス内でのみにするべきです。 + {{< /note >}} + +各Podは、与えられたアプリケーションの単一のインスタンスを稼働するためのものです。もしユーザーのアプリケーションを水平にスケールさせたい場合(例: 複数インスタンスを稼働させる)、複数のPodを使うべきです。1つのPodは各インスタンスに対応しています。Kubernetesでは、これは一般的に*レプリケーション*と呼ばれます。レプリケーションされたPodは、通常ワークロードリソースと、それに対応する{{< glossary_tooltip text="コントローラー" term_id="controller" >}}によって、作成・管理されます。 + +Kubernetesがワークロードリソースとそのコントローラーを活用して、スケーラブルで自動回復するアプリケーションを実装する方法については、詳しくは[Podとコントローラー](#pods-and-controllers)を参照してください。 + +### Podが複数のコンテナを管理する方法 + +Podは、まとまりの強いサービスのユニットを構成する、複数の協調する(コンテナとして実行される)プロセスをサポートするために設計されました。単一のPod内の複数のコンテナは、クラスター内の同じ物理または仮想マシン上で、自動的に同じ場所に配置・スケジューリングされます。コンテナ間では、リソースや依存関係を共有したり、お互いに通信したり、停止するときにはタイミングや方法を協調して実行できます。 + +たとえば、あるコンテナが共有ボリューム内のファイルを配信するウェブサーバーとして動作し、別の「サイドカー」コンテナがリモートのリソースからファイルをアップデートするような構成が考えられます。この構成を以下のダイアグラムに示します。 + +{{< figure src="/images/docs/pod.svg" alt="Podのダイアグラムの例" width="50%" >}} + +Podによっては、{{< glossary_tooltip text="appコンテナ" term_id="app-container" >}}に加えて{{< glossary_tooltip text="initコンテナ" term_id="init-container" >}}を持っている場合があります。initコンテナはappコンテナが起動する前に実行・完了するコンテナです。 + +Podは、Podを構成する複数のコンテナに対して、[ネットワーク](#pod-networking)と[ストレージ](#pod-storage)の2種類の共有リソースを提供します。 + +## Podを利用する + +通常Kubernetesでは、たとえ単一のコンテナしか持たないシングルトンのPodだとしても、個別のPodを直接作成することはめったにありません。その理由は、Podがある程度一時的で使い捨てできる存在として設計されているためです。Podが作成されると(あなたが直接作成した場合でも、{{< glossary_tooltip text="コントローラー" term_id="controller" >}}が間接的に作成した場合でも)、新しいPodはクラスター内の{{< glossary_tooltip term_id="node" >}}上で実行されるようにスケジューリングされます。Podは、実行が完了するか、Podオブジェクトが削除されるか、リソース不足によって*強制退去*されるか、ノードが停止するまで、そのノード上にとどまります。 + +{{< note >}} +Pod内のコンテナの再起動とPodの再起動を混同しないでください。Podはプロセスではなく、コンテナが実行するための環境です。Podは削除されるまでは残り続けます。 +{{< /note >}} + +Podオブジェクトのためのマニフェストを作成したときは、指定したPodの名前が有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)であることを確認してください。 + +### Podとコンテナコントローラー {#pods-and-controllers} + +ワークロードリソースは、複数のPodを作成・管理するために利用できます。リソースに対応するコントローラーが、複製やロールアウトを扱い、Podの障害時には自動回復を行います。たとえば、あるノードに障害が発生した場合、コントローラーはそのノードの動作が停止したことを検知し、代わりのPodを作成します。そして、スケジューラーが代わりのPodを健全なノード上に配置します。 + +以下に、1つ以上のPodを管理するワークロードリソースの一例をあげます。 + +* {{< glossary_tooltip text="Deployment" term_id="deployment" >}} +* {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} +* {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}} + +### Podテンプレート + +{{< glossary_tooltip text="workload" term_id="workload" >}}リソース向けのコントローラーは、Podを*Podテンプレート*を元に作成し、あなたの代わりにPodを管理してくれます。 + +PodTemplateはPodを作成するための仕様で、[Deployment](/ja/docs/concepts/workloads/controllers/deployment/)、[Job](/ja/docs/concepts/workloads/controllers/job/)、[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)などのワークロードリソースの中に含まれています。 + +ワークロードリソースに対応する各コントローラーは、ワークロードオブジェクト内にある`PodTemplate`を使用して実際のPodを作成します。`PodTemplate`は、アプリを実行するために使われるワークロードリソースがどんな種類のものであれ、その目的の状態の一部を構成するものです。 + +以下は、単純なJobのマニフェストの一例で、1つのコンテナを実行する`template`があります。Pod内のコンテナはメッセージを出力した後、一時停止します。 + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: hello +spec: + template: + # これがPodテンプレートです + spec: + containers: + - name: hello + image: busybox + command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600'] + restartPolicy: OnFailure + # Podテンプレートはここまでです +``` + +Podテンプレートを修正するか新しいPodに切り替えたとしても、すでに存在するPodには直接の影響はありません。ワークロードリソース内のPodテンプレートを変更すると、そのリソースは更新されたテンプレートを使用して代わりとなるPodを作成する必要があります。 + +たとえば、StatefulSetコントローラーは、各StatefulSetごとに、実行中のPodが現在のPodテンプレートに一致することを保証します。Podテンプレートを変更するためにStatefulSetを編集すると、StatefulSetは更新されたテンプレートを元にした新しいPodを作成するようになります。最終的に、すべての古いPodが新しいPodで置き換えられ、更新は完了します。 + +各ワークロードリソースは、Podテンプレートへの変更を処理するための独自のルールを実装しています。特にStatefulSetについて更に詳しく知りたい場合は、StatefulSetの基本チュートリアル内の[アップデート戦略](/ja/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets)を読んでください。 + +ノード上では、{{< glossary_tooltip term_id="kubelet" text="kubelet" >}}はPodテンプレートに関する詳細について監視や管理を直接行うわけではありません。こうした詳細は抽象化されています。こうした抽象化や関心の分離のおかげでシステムのセマンティクスが単純化され、既存のコードを変更せずにクラスターの動作を容易に拡張できるようになっているのです。 + +## リソースの共有と通信 + +Podは、データの共有と構成するコンテナ間での通信を可能にします。 + +### Pod内のストレージ {#pod-storage} + +Podでは、共有ストレージである{{< glossary_tooltip text="ボリューム" term_id="volume" >}}の集合を指定できます。Pod内のすべてのコンテナは共有ボリュームにアクセスできるため、それら複数のコンテナでデータを共有できるようになります。また、ボリュームを利用すれば、Pod内のコンテナの1つに再起動が必要になった場合にも、Pod内の永続化データを保持し続けられるようにできます。Kubernetesの共有ストレージの実装方法とPodで利用できるようにする方法に関するさらに詳しい情報は、[ストレージ](/ja/docs/concepts/storage/)を読んでください。 + +### Podネットワーク + +各Podには、各アドレスファミリーごとにユニークなIPアドレスが割り当てられます。Pod内のすべてのコンテナは、IPアドレスとネットワークポートを含むネットワーク名前空間を共有します。Podの中では(かつその場合に**のみ**)、そのPod内のコンテナは`localhost`を使用して他のコンテナと通信できます。Podの内部にあるコンテナが*Podの外部にある*エンティティと通信する場合、(ポートなどの)共有ネットワークリソースの使い方をコンテナ間で調整しなければなりません。Pod内では、コンテナはIPアドレスとポートの空間を共有するため、`localhost`で他のコンテナにアクセスできます。また、Pod内のコンテナは、SystemVのセマフォやPOSIXの共有メモリなど、標準のプロセス間通信を使って他のコンテナと通信することもできます。異なるPod内のコンテナは異なるIPアドレスを持つため、[特別な設定](/docs/concepts/policy/pod-security-policy/)をしない限りIPCで通信することはできません。異なるPod上で実行中のコンテナ間でやり取りをしたい場合は、IPネットワークを使用して通信できます。 + +Pod内のコンテナは、システムのhostnameがPodに設定した`name`と同一であると考えます。ネットワークについての詳しい情報は、[ネットワーク](/ja/docs/concepts/cluster-administration/networking/)で説明しています。 + +## コンテナの特権モード + +Pod内のどんなコンテナも、`privileged`フラグをコンテナのspecの[security context](/docs/tasks/configure-pod-container/security-context/)に設定することで、特権モード(privileged mode)を有効にできます。これは、ネットワークスタックの操作やハードウェアデバイスへのアクセスなど、オペレーティングシステムの管理者の権限が必要なコンテナの場合に役に立ちます。特権コンテナ内のプロセスはコンテナ外のプロセスが利用できるのとほぼ同等の権限を取得します。 + +{{< note >}} +この設定を有効にするには、{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}が特権コンテナの概念をサポートしていなければなりません。 +{{< /note >}} + +## static Pod + +*static Pod*は、{{< glossary_tooltip text="APIサーバー" term_id="kube-apiserver" >}}には管理されない、特定のノード上でkubeletデーモンによって直接管理されるPodのことです。大部分のPodはコントロープレーン(たとえば{{< glossary_tooltip text="Deployment" term_id="deployment" >}})によって管理されますが、static Podの場合はkubeletが各static Podを直接管理します(障害時には再起動します)。 + +static Podは常に特定のノード上の1つの{{< glossary_tooltip term_id="kubelet" >}}に紐付けられます。static Podの主な用途は、セルフホストのコントロールプレーンを実行すること、言い換えると、kubeletを使用して個別の[コントロールプレーンコンポーネント](/ja/docs/concepts/overview/components/#control-plane-components)を管理することです。 + +kubeletは自動的にKubernetes APIサーバー上に各static Podに対応する{{< glossary_tooltip text="ミラーPod" term_id="mirror-pod" >}}の作成を試みます。つまり、ノード上で実行中のPodはAPIサーバー上でも見えるようになるけれども、APIサーバー上から制御はできないということです。 + +## {{% heading "whatsnext" %}} + +* [Podのライフサイクル](/ja/docs/concepts/workloads/pods/pod-lifecycle/)について学ぶ。 +* [PodPreset](/ja/docs/concepts/workloads/pods/podpreset/)について学ぶ。 +* [RuntimeClass](/ja/docs/concepts/containers/runtime-class/)と、それを用いてPodごとに異なるコンテナランタイム設定する方法について学ぶ。 +* [Podトポロジー分布制約](/docs/concepts/workloads/pods/pod-topology-spread-constraints/)について読む。 +* [PodDisruptionBudget](/ja/docs/concepts/workloads/pods/disruptions/)と、それを使用してクラスターの停止(disruption)中にアプリケーションの可用性を管理する方法について読む。 +* PodはKubernetes REST API内のトップレベルのリソースです。[Pod](/ja/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)オブジェクトの定義では、オブジェクトの詳細について記述されています。 +* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns)では、2つ以上のコンテナを利用する場合の一般的なレイアウトについて説明しています。 + +Kubernetesが共通のPod APIを他のリソース内(たとえば{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}や{{< glossary_tooltip text="Deployment" term_id="deployment" >}}など)にラッピングしている理由の文脈を理解するためには、Kubernetes以前から存在する以下のような既存技術について読むのが助けになります。 + + * [Aurora](https://aurora.apache.org/documentation/latest/reference/configuration/#job-schema) + * [Borg](https://research.google.com/pubs/pub43438.html) + * [Marathon](https://mesosphere.github.io/marathon/docs/rest-api.html) + * [Omega](https://research.google/pubs/pub41684/) + * [Tupperware](https://engineering.fb.com/data-center-engineering/tupperware/) diff --git a/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md index db69d83fcd..beb92b3b88 100644 --- a/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md @@ -59,7 +59,7 @@ weight: 80 "apiVersion": "v1", "kind": "EphemeralContainers", "metadata": { - "name": "example-pod" + "name": "example-pod" }, "ephemeralContainers": [{ "command": [ diff --git a/content/ja/docs/concepts/workloads/pods/init-containers.md b/content/ja/docs/concepts/workloads/pods/init-containers.md index 5e7baf0665..4cf7d75fae 100644 --- a/content/ja/docs/concepts/workloads/pods/init-containers.md +++ b/content/ja/docs/concepts/workloads/pods/init-containers.md @@ -20,7 +20,7 @@ Initコンテナは下記の項目をのぞいて、通常のコンテナと全 * Initコンテナは常に完了するまで稼働します。 * 各Initコンテナは、次のInitコンテナが稼働する前に正常に完了しなくてはなりません。 -もしあるPodの単一のInitコンテナが失敗した場合、KubernetesはInitコンテナが成功するまで何度もそのPodを再起動します。しかし、もしそのPodの`restartPolicy`がNeverの場合、再起動されません。 +もしあるPodの単一のInitコンテナが失敗した場合、Kubeletは成功するまで何度もそのInitコンテナを再起動します。しかし、もしそのPodの`restartPolicy`がNeverで、そのPodの起動時にInitコンテナが失敗した場合、KubernetesはそのPod全体を失敗として扱います。 PodにInitコンテナを指定するためには、Podの仕様にそのアプリケーションの`containers`配列と並べて、`initContainers`フィールドを[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)型のオブジェクトの配列として指定してください。 Initコンテナのステータスは、`.status.initContainerStatuses`フィールドにコンテナのステータスの配列として返されます(`.status.containerStatuses`と同様)。 diff --git a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md index 8afc01295d..012c042c81 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ja/docs/concepts/workloads/pods/pod-lifecycle.md @@ -8,7 +8,7 @@ weight: 30 このページではPodのライフサイクルについて説明します。Podは定義されたライフサイクルに従い `Pending`[フェーズ](#pod-phase)から始まり、少なくとも1つのプライマリーコンテナが正常に開始した場合は`Running`を経由し、次に失敗により終了したコンテナの有無に応じて、`Succeeded`または`Failed`フェーズを経由します。 -Podの実行中、kubeletはコンテナを再起動して、ある種の障害を処理できます。Pod内で、Kubernetesはさまざまなコンテナの[ステータス](#container-states)を追跡して、対処します。 +Podの実行中、kubeletはコンテナを再起動して、ある種の障害を処理できます。Pod内で、Kubernetesはさまざまなコンテナの[ステータス](#container-states)を追跡して、回復させるためのアクションを決定します。 Kubernetes APIでは、Podには仕様と実際のステータスの両方があります。Podオブジェクトのステータスは、[PodのCondition](#pod-conditions)のセットで構成されます。[カスタムのReadiness情報](#pod-readiness-gate)をPodのConditionデータに挿入することもできます。 @@ -43,13 +43,13 @@ Podの各フェーズの値と意味は厳重に守られています。ここ これらが`phase`の取りうる値です。 -値 | 概要 -:-----|:----------- -`Pending` | PodがKubernetesクラスターによって承認されましたが、1つ以上のコンテナがセットアップされて稼働する準備ができていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。 -`Running` | PodがNodeにバインドされ、すべてのコンテナが作成されました。少なくとも1つのコンテナがまだ実行されているか、開始または再起動中です。 -`Succeeded` |Pod内のすべてのコンテナが正常に終了し、再起動されません。 -`Failed` | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。 -`Unknown` | 何らかの理由によりPodの状態を取得できませんでした。このフェーズは通常はPodのホストとの通信エラーにより発生します。 +値 | 概要 +:-----------|:----------- +`Pending` | PodがKubernetesクラスターによって承認されましたが、1つ以上のコンテナがセットアップされて稼働する準備ができていません。これには、スケジュールされるまでの時間と、ネットワーク経由でイメージをダウンロードするための時間などが含まれます。 +`Running` | PodがNodeにバインドされ、すべてのコンテナが作成されました。少なくとも1つのコンテナがまだ実行されているか、開始または再起動中です。 +`Succeeded` | Pod内のすべてのコンテナが正常に終了し、再起動されません。 +`Failed` | Pod内のすべてのコンテナが終了し、少なくとも1つのコンテナが異常終了しました。つまり、コンテナはゼロ以外のステータスで終了したか、システムによって終了されました。 +`Unknown` | 何らかの理由によりPodの状態を取得できませんでした。このフェーズは通常はPodのホストとの通信エラーにより発生します。 Nodeが停止するか、クラスタの残りの部分から切断された場合、Kubernetesは失われたNode上のすべてのPodの`Phase`をFailedに設定するためのポリシーを適用します。 @@ -69,7 +69,7 @@ Podのコンテナの状態を確認するには`kubectl describe pod [POD_NAME] ### `Running` {#container-state-running} -`Running`状態はコンテナが問題なく実行されていることを示します。コンテナがRunning状態に入る前に`postStart`フック（もしあれば）が実行されます。`Running`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Running`状態になった時刻が表示されます。 +`Running`状態はコンテナが問題なく実行されていることを示します。`postStart`フックが構成されていた場合、それはすでに実行が完了しています。`Running`状態のコンテナを持つPodに対して`kubectl`コマンドを使用すると、そのコンテナが`Running`状態になった時刻が表示されます。 ### `Terminated` {#container-state-terminated} @@ -81,7 +81,7 @@ Podのコンテナの状態を確認するには`kubectl describe pod [POD_NAME] Podの`spec`には、Always、OnFailure、またはNeverのいずれかの値を持つ`restartPolicy`フィールドがあります。デフォルト値はAlwaysです。 -`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間問題なく実行されると、kubeletはコンテナの再起動バックオフタイマーをリセットします。 +`restartPolicy`は、Pod内のすべてのコンテナに適用されます。`restartPolicy`は、同じNode上のkubeletによるコンテナの再起動のみを参照します。Pod内のコンテナが終了した後、kubeletは5分を上限とする指数バックオフ遅延（10秒、20秒、40秒...）でコンテナを再起動します。コンテナが10分間実行されると、kubeletはコンテナの再起動バックオフタイマーをリセットします。 ## PodのCondition {#pod-conditions} @@ -148,7 +148,7 @@ Podのコンテナは準備完了ですが、少なくとも1つのカスタム ## コンテナのProbe {#container-probes} -[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/admin/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります: +[Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) は [kubelet](/docs/reference/command-line-tools-reference/kubelet/) により定期的に実行されるコンテナの診断です。診断を行うために、kubeletはコンテナに実装された [Handler](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#handler-v1-core)を呼びます。Handlerには次の3つの種類があります: * [ExecAction](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#execaction-v1-core): コンテナ内で特定のコマンドを実行します。コマンドがステータス0で終了した場合に診断を成功と見まします。 @@ -209,7 +209,7 @@ Podが削除されたときにリクエストを来ないようにするため ### startupProbeをいつ使うべきか? {#when-should-you-use-a-startup-probe} -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} +{{< feature-state for_k8s_version="v1.18" state="beta" >}} startupProbeは、サービスの開始に時間がかかるコンテナを持つポッドに役立ちます。livenessProbeの間隔を長く設定するのではなく、コンテナの起動時に別のProbeを構成して、livenessProbeの間隔よりも長い時間を許可できます。 コンテナの起動時間が、`initialDelaySeconds + failureThreshold x periodSeconds`よりも長い場合は、livenessProbeと同じエンドポイントをチェックするためにstartupProbeを指定します。`periodSeconds`のデフォルトは30秒です。次に、`failureThreshold`をlivenessProbeのデフォルト値を変更せずにコンテナが起動できるように、十分に高い値を設定します。これによりデッドロックを防ぐことができます。 @@ -220,7 +220,7 @@ Podは、クラスター内のNodeで実行中のプロセスを表すため、 ユーザーは削除を要求可能であるべきで、プロセスがいつ終了するかを知ることができなければなりませんが、削除が最終的に完了することも保証できるべきです。ユーザーがPodの削除を要求すると、システムはPodが強制終了される前に意図された猶予期間を記録および追跡します。強制削除までの猶予期間がある場合、{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}正常な終了を試みます。 -通常、コンテナランタイムは各コンテナのメインプロセスにTERMシグナルを送信します。猶予期間が終了すると、プロセスにKILLシグナルが送信され、Podは{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}から削除されます。プロセスの終了を待っている間にkubeletかコンテナランタイムの管理サービスが再起動されると、クラスターは元の猶予期間を含めて、最初からリトライされます。 +通常、コンテナランタイムは各コンテナのメインプロセスにTERMシグナルを送信します。多くのコンテナランタイムは、コンテナイメージで定義されたSTOPSIGNAL値を尊重し、TERMの代わりにこれを送信します。猶予期間が終了すると、プロセスにKILLシグナルが送信され、Podは{{< glossary_tooltip text="API Server" term_id="kube-apiserver" >}}から削除されます。プロセスの終了を待っている間にkubeletかコンテナランタイムの管理サービスが再起動されると、クラスターは元の猶予期間を含めて、最初からリトライされます。 フローの例は下のようになります。 diff --git a/content/ja/docs/concepts/workloads/pods/pod-overview.md b/content/ja/docs/concepts/workloads/pods/pod-overview.md index 4d286fdbcf..6e053f9ab1 100644 --- a/content/ja/docs/concepts/workloads/pods/pod-overview.md +++ b/content/ja/docs/concepts/workloads/pods/pod-overview.md @@ -61,7 +61,7 @@ Podは、Podによって構成されたコンテナ群のために2種類の共 ## Podを利用する -ユーザーはまれに、Kubenetes内で独立したPodを直接作成する場合があります(シングルトンPodなど)。 +ユーザーはまれに、Kubernetes内で独立したPodを直接作成する場合があります(シングルトンPodなど)。 これはPodが比較的、一時的な使い捨てエンティティとしてデザインされているためです。Podが作成された時(ユーザーによって直接的、またはコントローラーによって間接的に作成された場合)、ユーザーのクラスター内の単一の{{< glossary_tooltip term_id="node" >}}上で稼働するようにスケジューリングされます。そのPodはプロセスが停止されたり、Podオブジェクトが削除されたり、Podがリソースの欠如のために*追い出され* たり、ノードが故障するまでノード上に残り続けます。 {{< note >}} diff --git a/content/ja/docs/contribute/_index.md b/content/ja/docs/contribute/_index.md index 008b575e1a..4bc7489b5e 100644 --- a/content/ja/docs/contribute/_index.md +++ b/content/ja/docs/contribute/_index.md @@ -1,55 +1,76 @@ --- content_type: concept -title: Kubernetesのドキュメントに貢献する +title: K8sのドキュメントに貢献する linktitle: 貢献 main_menu: true +no_list: true weight: 80 +card: + name: 貢献 + weight: 10 + title: K8sへの貢献を始める --- -ドキュメントやウェブサイトに貢献したい方、ご協力お待ちしています。 -はじめての方、久しぶりの方、開発者でもエンドユーザでも、はたまたタイポを見逃せない方でもどなたでも貢献可能です。 +*Kubernetesは初心者でも経験者でも、全てのコントリビューターからの改善を歓迎しています！* +{{< note >}} +Kubernetesへの貢献について総合的に知りたい場合は、[contributor documentation](https://www.kubernetes.dev/docs/)を参照してください。 +{{< /note >}} + +このウェブサイトは[Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs)が管理しています。 + +Kubernetesドキュメントコントリビューターは + +- 既存のコンテンツを改善します +- 新しいコンテンツを作成します +- ドキュメントを翻訳します +- Kubernetesリリースサイクルの一部としてドキュメントを管理・公開します ## はじめに -どなたでも、問題を説明するissueや、ドキュメントの改善を求めるissueを作成し、プルリクエスト(PR)を用いて変更に貢献することができます。 -一部のタスクでは、Kubernetes organizationで、より多くの信頼とアクセス権限が必要です。 -役割と権限についての詳細は、[SIG Docsへの参加](/docs/contribute/participating/)を参照してください。 - -Kubernetesのドキュメントは、GitHubのリポジトリーにあります。 -どなたからの貢献も歓迎しますが、Kubernetesコミュニティの効果的な運用のためには、gitとGitHubを基本的に使いこなせる必要があります。 +どなたでも、問題を説明するissueや、ドキュメントの改善を求めるissueを作成し、[`kubernetes/website` GitHub リポジトリ](https://github.com/kubernetes/website)に対するプルリクエスト(PR)を用いて変更に貢献することができます。 +Kubernetesコミュニティで効果的に働くためには、[git](https://git-scm.com/)と[GitHub](https://lab.github.com/)を基本的に使いこなせる必要があります。 ドキュメンテーションに関わるには: 1. CNCFの[Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)にサインしてください。 2. [ドキュメンテーションのリポジトリー](https://github.com/kubernetes/website)と、ウェブサイトの[静的サイトジェネレーター](https://gohugo.io)に慣れ親しんでください。 -3. [コンテンツの改善](https://kubernetes.io/docs/contribute/start/#improve-existing-content)と[変更レビュー](https://kubernetes.io/docs/contribute/start/#review-docs-pull-requests)の基本的なプロセスを理解していることを確認してください。 +3. [プルリクエストのオープン](/docs/contribute/new-content/open-a-pr/)と[変更レビュー](/docs/contribute/review/reviewing-prs/)の基本的なプロセスを理解していることを確認してください。 -## 貢献するためのベストプラクティス +一部のタスクでは、Kubernetes organizationで、より多くの信頼とアクセス権限が必要です。 +役割と権限についての詳細は、[SIG Docsへの参加](/docs/contribute/participating/)を参照してください。 -- 明快で意味のあるGitコミットメッセージを書いてください。 -- PRがマージされたときにissueを参照し、自動的にissueをクローズする _Github Special Keywords_ を必ず含めるようにしてください。 -- タイプミスの修正や、スタイルの変更、文法の変更などのような小さな変更をPRに加える場合は、比較的小さな変更のためにコミットの数が増えすぎないように、コミットはまとめてください。 -- あなたがコードを変更をした理由を示し、レビュアーがあなたのPRを理解するのに十分な情報を確保した適切なPR説明を、必ず含めるようにしてください。 -- 追加文献 : - - [chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/) - - [github.com/blog/1506-closing-issues-via-pull-requests ](https://github.com/blog/1506-closing-issues-via-pull-requests ) - - [davidwalsh.name/squash-commits-git ](https://davidwalsh.name/squash-commits-git ) +## はじめての貢献 +- 貢献のための複数の方法について学ぶために[貢献の概要](/docs/contribute/new-content/overview/)を読んでください。 +- 良い開始地点を探すために[`kubernetes/website` issueリスト](https://github.com/kubernetes/website/issues/)を確認してください。 +- 既存のドキュメントに対して[GitHubを使ってプルリクエストをオープン](/docs/contribute/new-content/open-a-pr/#changes-using-github)し、GitHubへのissueの登録について学んでください。 +- 正確さと言語の校正のため、他のKubernetesコミュニティメンバーから[プルリクエストのレビュー](/docs/contribute/review/reviewing-prs/)を受けてください。 +- 見識のあるコメントを残せるようにするため、Kubernetesの[コンテンツ](/docs/contribute/style/content-guide/)と[スタイルガイド](/docs/contribute/style/style-guide/)を読んでください。 +- [ページコンテンツの種類](/docs/contribute/style/page-content-types/)と[Hugoショートコード](/docs/contribute/style/hugo-shortcodes/)について勉強してください。 + +## 次のステップ + +- リポジトリの[ローカルクローンでの作業](/docs/contribute/new-content/open-a-pr/#fork-the-repo)について学んでください。 +- [リリース機能](/docs/contribute/new-content/new-features/)について記載してください。 +- [SIG Docs](/docs/contribute/participate/)に参加し、[memberやreviewer](/docs/contribute/participate/roles-and-responsibilities/)になってください。 +- [国際化](/docs/contribute/localization/)を始めたり、支援したりしてください。 + +## SIG Docsに参加する + +[SIG Docs](/docs/contribute/participate/)はKubernetesのドキュメントとウェブサイトを公開・管理するコントリビューターのグループです。SIG Docsに参加することはKubernetesコントリビューター（機能開発でもそれ以外でも）にとってKubernetesプロジェクトに大きな影響を与える素晴らしい方法の一つです。 + +SIG Docsは複数の方法でコミュニケーションをとっています。 + +- [Kubernetes Slackインスタンスの`#sig-docs`に参加してください](https://slack.k8s.io/)。自己紹介を忘れずに！ +- [`kubernetes-sig-docs`メーリングリストに参加してください](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)。ここでは幅広い議論が起こり、公式な決定が記録されます。 +- [毎週のSIG Docsビデオミーティング](https://github.com/kubernetes/community/tree/master/sig-docs)に参加してください。ミーティングは `#sig-docs`でアナウンスされ、[Kubernetesコミュニティミーティングカレンダー](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles)に追加されます。[Zoomクライアント](https://zoom.us/download)をダウンロードするか、電話を使って通話する必要があります。 ## その他の貢献方法 -- TwitterやStack Overflowといったオンラインフォーラムを通してKubernetesコミュニティに貢献したい方、または各地のミートアップやイベントについて知りたい方は[Kubernetes community site](/community/)へ。 -- 機能開発に貢献したい方は、まずはじめに[Kubernetesコントリビューターチートシート](https://github.com/kubernetes/community/blob/master/contributors/guide/contributor-cheatsheet/README-ja.md)を読んでください。 - - -## {{% heading "whatsnext" %}} - -- ドキュメントへの貢献の基本について、さらに知りたい場合は、[貢献の開始](/docs/contribute/start/)を参照してください。 -- 変更を提案をする際は、[Kubernetesドキュメンテーションスタイルガイド](/docs/contribute/style/style-guide/)に従ってください。 -- SIG Docsについて、さらに知りたい場合は、[SIG Docsへの参加](/docs/contribute/participating/)を参照してください。 -- Kubernetesドキュメントのローカライズについて、さらに知りたい場合は、[Kubernetesドキュメントのローカライズ](/docs/contribute/localization/)を参照してください。 - +- [Kubernetesコミュニティサイト](/community/)を訪問してください。TwitterやStack Overflowに参加したり、Kubernetesの集会やイベントについて学んだりしてください。 +- 機能開発に貢献したい方は、まずはじめに[Kubernetesコントリビューターチートシート](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)を読んでください。 +- [ブログ記事やケーススタディ](/docs/contribute/new-content/blogs-case-studies/)を投稿してください。 diff --git a/content/ja/docs/contribute/new-content/_index.md b/content/ja/docs/contribute/new-content/_index.md new file mode 100644 index 0000000000..f9cb2e1301 --- /dev/null +++ b/content/ja/docs/contribute/new-content/_index.md @@ -0,0 +1,4 @@ +--- +title: 新しいコンテンツの貢献 +weight: 20 +--- diff --git a/content/ja/docs/contribute/new-content/overview.md b/content/ja/docs/contribute/new-content/overview.md new file mode 100644 index 0000000000..e3db3744e9 --- /dev/null +++ b/content/ja/docs/contribute/new-content/overview.md @@ -0,0 +1,54 @@ +--- +title: 新しいコンテンツの貢献の概要 +linktitle: 概要 +content_type: concept +main_menu: true +weight: 5 +--- + + + +このセクションでは、新しいコンテンツの貢献を行う前に知っておくべき情報を説明します。 + + + +## 貢献の基本 + +- KubernetesのドキュメントはMarkdownで書き、Kubernetesのウェブサイトは[Hugo](https://gohugo.io/)を使ってビルドします。 +- ソースは[GitHub](https://github.com/kubernetes/website)にあります。Kubernetesのドキュメントは`/content/en/docs/`にあります。リファレンスドキュメントの一部は、`update-imported-docs/`ディレクトリ内のスクリプトから自動的に生成されます。 +- [Page content types](/docs/contribute/style/page-content-types/)にHugoによるドキュメントのコンテンツの見え方を記述しています。 +- 標準のHugoのshortcodeに加えて、多数の[カスタムのHugo shortcode](/docs/contribute/style/hugo-shortcodes/)を使用してコンテンツの見え方をコントロールしています。 +- ドキュメントのソースは`/content/`内にある複数の言語で利用できます。各言語はそれぞれ[ISO 639-1標準](https://www.loc.gov/standards/iso639-2/php/code_list.php)で定義された2文字のコードの名前のフォルダを持ちます。たとえば、英語のドキュメントのソースは`/content/en/docs/`内に置かれています。 +- 複数言語でのドキュメントへの貢献や新しい翻訳の開始に関する情報については、[Kubernetesのドキュメントを翻訳する](/docs/contribute/localization)を参照してください。 + +## 始める前に {#before-you-begin} + +### CNCF CLAに署名する {#sign-the-cla} + +すべてのKubernetesのコントリビューターは、[コントリビューターガイド](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)を読み、[Contributor License Agreement(コントリビューターライセンス契約、CLA)への署名](https://github.com/kubernetes/community/blob/master/CLA.md)を**必ず行わなければなりません**。 + +CLAへの署名が完了していないコントリビューターからのpull requestは、自動化されたテストで失敗します。名前とメールアドレスは`git config`コマンドで表示されるものに一致し、gitの名前とメールアドレスはCNCF CLAで使われたものに一致しなければなりません。 + +### どのGitブランチを使用するかを選ぶ + +pull requestをオープンするときは、どのブランチをベースにして作業するかをあらかじめ知っておく必要があります。 + +シナリオ | ブランチ +:---------|:------------ +現在のリリースに対する既存または新しい英語のコンテンツ | `master` +機能変更のリリースに対するコンテンツ | 機能変更が含まれるメジャーおよびマイナーバージョンに対応する、`dev-`というパターンのブランチを使います。たとえば、機能変更が`v{{< skew nextMinorVersion >}}`に含まれる場合、ドキュメントの変更は``dev-{{< skew nextMinorVersion >}}``ブランチに追加します。 +他の言語内のコンテンツ(翻訳) | 各翻訳対象の言語のルールに従います。詳しい情報は、[翻訳のブランチ戦略](/docs/contribute/localization/#branching-strategy)を読んでください。 + +それでも選ぶべきブランチがわからないときは、Slack上の`#sig-docs`チャンネルで質問してください。 + +{{< note >}} +すでにpull requestを作成していて、ベースブランチが間違っていたことに気づいた場合は、作成者であるあなただけがベースブランチを変更できます。 +{{< /note >}} + +### 言語ごとのPR + +pull requestはPRごとに1つの言語に限定してください。複数の言語に同一の変更を行う必要がある場合は、言語ごとに別々のPRを作成してください。 + +## コントリビューターのためのツール + +`kubernetes/website`リポジトリ内の[doc contributors tools](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools)ディレクトリには、コントリビューターとしての旅を楽にしてくれるツールがあります。 diff --git a/content/ja/docs/contribute/participate/_index.md b/content/ja/docs/contribute/participate/_index.md new file mode 100644 index 0000000000..bf21148c40 --- /dev/null +++ b/content/ja/docs/contribute/participate/_index.md @@ -0,0 +1,102 @@ +--- +title: SIG Docsへの参加 +content_type: concept +weight: 60 +card: + name: contribute + weight: 60 +--- + + + +SIG Docsは、Kubernetesプロジェクト内の +[special interest groups](https://github.com/kubernetes/community/blob/master/sig-list.md)の1つであり、 +Kubernetes全体のドキュメントの作成、更新、および保守に重点を置いています。 +SIGの詳細については、[SIG DocsのGithubリポジトリ](https://github.com/kubernetes/community/blob/master/sig-list.md)を参照してください。 + +SIG Docsは、すべての寄稿者からのコンテンツとレビューを歓迎します。 +誰でもPull Request(PR)を開くことができ、コンテンツに関するissueを提出したり、進行中のPull Requestにコメントしたりできます。 + +あなたは、[member](/docs/contribute/participate/roles-and-responsibilities/#members)や、 +[reviewer](/docs/contribute/participate/roles-and-responsibilities/#reviewers)、 +[approver](/docs/contribute/participate/roles-and-responsibilities/#approvers)になることもできます。 +これらの役割にはより多くのアクセスが必要であり、変更を承認およびコミットするための特定の責任が伴います。 +Kubernetesコミュニティ内でメンバーシップがどのように機能するかについての詳細は、 +[community-membership](https://github.com/kubernetes/community/blob/master/community-membership.md) +をご覧ください。 + +このドキュメントの残りの部分では、kubernetesの中で最も広く公開されている +Kubernetesのウェブサイトとドキュメントの管理を担当しているSIG Docsの中で、これらの役割がどのように機能するのかを概説します。 + + + + +## SIG Docs chairperson + +SIG Docsを含む各SIGは、議長として機能する1人以上のSIGメンバーを選択します。 +これらは、SIGDocsとKubernetes organizationの他の部分との連絡先です。 +それらには、Kubernetesプロジェクト全体の構造と、SIG Docsがその中でどのように機能するかについての広範な知識が必要です。 +現在のchairpersonのリストについては、 +[Leadership](https://github.com/kubernetes/community/tree/master/sig-docs#leadership) +を参照してください。 + +## SIG Docs teamsと自動化 + +SIG Docsの自動化は、GitHub teamsとOWNERSファイルの2つの異なるメカニズムに依存しています。 + +### GitHub teams + +GitHubには、二つのSIG Docs +[teams](https://github.com/orgs/kubernetes/teams?query=sig-docs) +カテゴリがあります: + +- `@sig-docs-{language}-owners`は承認者かつリードです。 +- `@sig-docs-{language}-reviewers` はレビュアーです。 + +それぞれをGitHubコメントの`@name`で参照して、そのグループの全員とコミュニケーションできます。 + +ProwチームとGitHub teamsが完全に一致せずに重複する場合があります。 +問題の割り当て、Pull Request、およびPR承認のサポートのために、自動化ではOWNERSファイルからの情報を使用します。 + +### OWNERSファイルとfront-matter + +Kubernetesプロジェクトは、GitHubのissueとPull Requestに関連する自動化のためにprowと呼ばれる自動化ツールを使用します。 +[Kubernetes Webサイトリポジトリ](https://github.com/kubernetes/website) +は、2つの[prowプラグイン](https://github.com/kubernetes/test-infra/tree/master/prow/plugins)を使用します： + +- blunderbuss +- approve + +これらの2つのプラグインは`kubernetes.website`のGithubリポジトリのトップレベルにある +[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)ファイルと、 +[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES)ファイルを使用して、 +リポジトリ内でのprowの動作を制御します。 + +OWNERSファイルには、SIG Docsのレビュー担当者および承認者であるユーザーのリストが含まれています。 +OWNERSファイルはサブディレクトリに存在することもでき、そのサブディレクトリとその子孫のファイルのレビュー担当者または承認者として機能できるユーザーを上書きできます。 +一般的なOWNERSファイルの詳細については、 +[OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md)を参照してください。 + +さらに、個々のMarkdownファイルは、個々のGitHubユーザー名またはGitHubグループを一覧表示することにより、そのfront-matterでレビュー担当者と承認者を一覧表示できます。 + +OWNERSファイルとMarkdownファイルのfront-matterの組み合わせにより、PRの技術的および編集上のレビューを誰に依頼するかについてPRの所有者が自動化システムから得るアドバイスが決まります。 + +## マージの仕組み + +Pull Requestがコンテンツの公開に使用されるブランチにマージされると、そのコンテンツは http://kubernetes.io に公開されます。 +公開されたコンテンツの品質を高くするために、Pull RequestのマージはSIG Docsの承認者に限定しています。仕組みは次のとおりです。 + +- Pull Requestに`lgtm`ラベルと`approve`ラベルの両方があり、`hold`ラベルがなく、すべてのテストに合格すると、Pull Requestは自動的にマージされます。 +- Kubernetes organizationのメンバーとSIG Docsの承認者はコメントを追加して、特定のPull Requestが自動的にマージされないようにすることができます(`/hold`コメントを追加するか、`/lgtm`コメントを保留します)。 +- Kubernetesメンバーは誰でも、`/lgtm`コメントを追加することで`lgtm`ラベルを追加できます。 +- `/approve`コメントを追加してPull Requestをマージできるのは、SIG Docsの承認者だけです。一部の承認者は、[PR Wrangler](/docs/contribute/participate/pr-wranglers/)や[SIG Docsのchairperson](#sig-docs-chairperson)など、追加の特定の役割も実行します。 + + + +## {{% heading "whatsnext" %}} + +Kubernetesドキュメントへの貢献の詳細については、以下を参照してください： + +- [Contributing new content](/docs/contribute/new-content/overview/) +- [Reviewing content](/docs/contribute/review/reviewing-prs) +- [ドキュメントスタイルの概要](/ja/docs/contribute/style/) diff --git a/content/ja/docs/contribute/review/for-approvers.md b/content/ja/docs/contribute/review/for-approvers.md new file mode 100644 index 0000000000..3a96595ea8 --- /dev/null +++ b/content/ja/docs/contribute/review/for-approvers.md @@ -0,0 +1,195 @@ +--- +title: approverとreviewer向けのレビュー +linktitle: approverとreviewer向け +slug: for-approvers +content_type: concept +weight: 20 +--- + + + +SIG Docsの[Reviewer(レビュアー)](/docs/contribute/participate/#reviewers)と[Approver(承認者)](/docs/contribute/participate/#approvers)は、変更をレビューする時にいくつか追加の作業を行います。 + +毎週、docsのメンバーの特定のapproverのボランティアは、pull requestのトリアージとレビューを担当します。この担当者は、その週の「PR Wrangler(PRの世話人)」と呼ばれます。詳しい情報は、[PR Wrangler scheduler](https://github.com/kubernetes/website/wiki/PR-Wranglers)を参照してください。PR Wranglerになるには、週次のSIG Docsミーティングに参加し、ボランティアをします。もしその週にスケジュールされていなくても、活発なレビューが行われていないpull request(PR)をレビューすることは問題ありません。 + +このローテーションに加えて、変更されたファイルのオーナーに基づいて、botがPRにreviewerとapproverを割り当てます。 + + + +## PRをレビューする + +Kubernetesのドキュメントは[Kubernetesコードレビュープロセス](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process)に従います。 + +[pull requestのレビュー](/ja/docs/contribute/review/reviewing-prs/)に書かれているすべてのことが適用されますが、ReviewerとApproverはそれに加えて次のことも行います。 + +- 必要に応じて、`/assign`Prowコマンドを使用して、特定のreviewerにPRを割り当てる。これは、コードのコントリビューターからの技術的なレビューが必要な場合には特に重要です。 + + {{< note >}} + 技術的なレビューを行える人物を知るには、Markdownファイル上部にあるfront-matterの`reviewers`フィールドを確認してください。 + {{< /note >}} + +- PRが[コンテンツ](/ja/docs/contribute/style/content-guide/)および[スタイル](/docs/contribute/style/style-guide/)のガイドに従っていることを確認してください。ガイドに従っていない場合は、ガイドの関連する部分にリンクを作者に示してください。 +- PRの作者に変更を提案できるときは、GitHubの**Request Changes**(変更をリクエスト)オプションを利用してください。 +- 提案したことが反映されたら、`/approve`や`/lgtm`コマンドを使用して、GitHubのレビューステータスを変更してください。 + +## 他の作者のPRにコミットを追加する + +PRにコメントを残すのは助けになりますが、まれに他の作者のPRに代わりにコミットを追加する必要がある場合があります。 + +あなたが明示的に作者から頼まれたり、長い間放置されたPRを蘇らせるような場合でない限り、他の作者のPRを「乗っ取る」ようなことはしないでください。短期的に見ればそのほうが短時間で終わるかもしれませんが、そのようなことをするとその人が貢献するチャンスを奪ってしまうことになります。 + +あなたが取る方法は、編集する必要のあるファイルがすでにPRのスコープに入っているか、あるいはPRがまだ触れていないファイルであるかによって変わります。 + +以下のいずれかが当てはまる場合、他の作者のPRにあなたがコミットを追加することはできません。 + +- PRの作者が自分のブランチを直接[https://github.com/kubernetes/website/](https://github.com/kubernetes/website/)リポジトリにpushした場合。この場合、pushアクセス権限を持つreviewerしか他のユーザーのPRにコミットを追加することはできません。 + + {{< note >}} + 次回PRを作成するとき、自分のブランチを自分のforkに対してpushするように作者に促してください。 + {{< /note >}} + +- PRの作者が明示的にapproverからの編集を禁止している場合。 + +## レビュー向けのProwコマンド + +[Prow](https://github.com/kubernetes/test-infra/blob/master/prow/README.md)は、pull request(PR)に対してジョブを実行するKubernetesベースのCI/CDシステムです。Prowは、Kubernetes organization全体でchatbotスタイルのコマンドを利用してGitHub actionsを扱えるようにします。たとえば、[ラベルの追加と削除](#adding-and-removing-issue-labels)、issueのclose、approverの割り当てなどが行なえます。Prowコマンドは、GitHubのコメントに`/`という形式で入力します。 + +reviewerとapproverが最もよく使うprowコマンドには、以下のようなものがあります。 + +{{< table caption="Prow commands for reviewing" >}} +Prowコマンド | Roleの制限 | 説明 +:------------|:------------------|:----------- +`/lgtm` | 誰でも。ただし、オートメーションがトリガされるのはReviewerまたはApproverが使用したときのみ。 | PRのレビューが完了し、変更に納得したことを知らせる。 +`/approve` | Approver | PRをマージすることを承認する。 +`/assign` | ReviewerまたはApprover | PRのレビューまたは承認するひとを割り当てる。 +`/close` | ReviewerまたはApprover | issueまたはPRをcloseする。 +`/hold` | 誰でも | `do-not-merge/hold`ラベルを追加して、自動的にマージできないPRであることを示す。 +`/hold cancel` | 誰でも | `do-not-merge/hold`ラベルを削除する。 +{{< /table >}} + +PRで利用できるすべてのコマンド一覧を確認するには、[Prowコマンドリファレンス](https://prow.k8s.io/command-help)を参照してください。 + +## issueのトリアージとカテゴリー分類 + +一般に、SIG Docsは[Kubernetes issue triage](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md)のプロセスに従い、同じラベルを使用しています。 + +このGitHub issueの[フィルター](https://github.com/kubernetes/website/issues?q=is%3Aissue+is%3Aopen+-label%3Apriority%2Fbacklog+-label%3Apriority%2Fimportant-longterm+-label%3Apriority%2Fimportant-soon+-label%3Atriage%2Fneeds-information+-label%3Atriage%2Fsupport+sort%3Acreated-asc)は、トリアージが必要な可能性があるissueを表示します。 + +### issueをトリアージする + +1. issueを検証する + - issueがドキュメントのウェブサイトに関係するものであることを確かめる。質問に答えたりリソースの場所を報告者に教えることですぐに閉じられるissueもあります。詳しくは、[サポートリクエストまたはコードのバグレポート](#support-requests-or-code-bug-reports)のセクションを読んでください。 + - issueにメリットがあるかどうか評価する。 + - issueに行動を取るのに十分な詳細情報がない場合や、テンプレートが十分埋められていない場合は、`triage/needs-information`ラベルを追加する。 + - `lifecycle/stale`と`triage/needs-information`の両方のラベルがあるときは、issueをcloseする。 + +2. 優先度(priority)ラベルを追加する([issueトリアージガイドライン](https://github.com/kubernetes/community/blob/master/contributors/guide/issue-triage.md#define-priority)は、priorityラベルについて詳しく定義しています。) + + {{< table caption="issueのラベル" >}} + ラベル | 説明 + :------------|:------------------ + `priority/critical-urgent` | 今すぐに作業する。 + `priority/important-soon` | 3ヶ月以内に取り組む。 + `priority/important-longterm` | 6ヶ月以内に取り組む。 + `priority/backlog` | 無期限に延期可能。リソースに余裕がある時に取り組む。 + `priority/awaiting-more-evidence` | よいissueの可能性があるissueを見失わないようにするためのプレースホルダー。 + `help`または`good first issue` | KubernetesまたはSIG Docsでほとんど経験がない人に適したissue。より詳しい情報は、[Help WantedとGood First Issueラベル](https://github.com/kubernetes/community/blob/master/contributors/guide/help-wanted.md)を読んでください。 + {{< /table >}} + + あなたの裁量で、issueのオーナーシップを取り、issueに対するPRを提出してください(簡単なissueや、自分がすでに行った作業に関連するissueである場合は特に)。 + +issueのトリアージについて質問があるときは、Slackの`#sig-docs`か[kubernetes-sig-docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)で質問してください。 + +## issueラベルの追加と削除 {#adding-and-removing-issue-labels} + +ラベルを追加するには、以下のいずれかの形式でコメントします。 + +- `/`(たとえば、`/good-first-issue`) +- `/ `(たとえば、`/triage needs-information`や`/language ja`) + +ラベルを削除するには、以下のいずれかの形式でコメントします。 + +- `/remove-`(たとえば、`/remove-help`) +- `/remove- `(たとえば、`/remove-triage needs-information`) + +いずれの場合でも、ラベルは既存のものでなければなりません。存在しないラベルを追加しようとした場合、コマンドは無視されます。 + +すべてのラベル一覧は、[websiteリポジトリーのラベルセクション](https://github.com/kubernetes/website/labels)で確認できます。SIG Docsですべてのラベルが使われているわけではありません。 + +### issueのライフサイクルに関するラベル + +issueは一般にopen後に短期間でcloseされます。しかし、issueがopenされた後にアクティブでなくなったり、issueが90日以上openのままである場合もあります。 + +{{< table caption="issueのライブラリに関するラベル" >}} +ラベル | 説明 +:------------|:------------------ +`lifecycle/stale` | 90日間活動がない場合、issueは自動的にstaleとラベル付けされます。`/remove-lifecycle stale`コマンドを使って手動でlifecycleをリバートしない限り、issueは自動的にcloseされます。 +`lifecycle/frozen` | このラベルが付けられたissueは、90日間活動がなくてもstaleになりません。`priority/important-longterm`ラベルを付けたissueなど、90日以上openにしておく必要があるissueには、このラベルを手動で追加します。 +{{< /table >}} + +## 特別な種類のissueに対処する + +SIG Docsでは、対処方法をドキュメントに書いても良いくらい頻繁に、以下のような種類のissueに出会います。 + +### 重服したissue + +1つの問題に対して1つ以上のissueがopenしている場合、1つのissueに統合します。あなたはどちらのissueをopenにしておくか(あるいは新しいissueを作成するか)を決断して、すべての関連する情報を移動し、関連するすべてのissueにリンクしなければなりません。最後に、同じ問題について書かれたすべての他のissueに`triage/duplicate`ラベルを付けて、それらをcloseします。作業対象のissueを1つだけにすることで、混乱を減らし、同じ問題に対して作業が重複することを避けられます。 + +### リンク切れに関するissue + +リンク切れのissueがAPIまたは`kubectl`のドキュメントにあるものは、問題が完全に理解されるまでは`/priority critical-urgent`を割り当ててください。その他のすべてのリンク切れに関するissueには、手動で修正が必要であるため、`/priority important-longterm`を付けます。 + +### Blogに関するissue + +[Kubernetes Blog](https://kubernetes.io/blog/)のエントリーは時間が経つと情報が古くなるものだと考えています。そのため、ブログのエントリーは1年以内のものだけをメンテナンスします。1年以上前のブログエントリーに関するissueは修正せずにcloseします。 + +### サポートリクエストまたはコードのバグレポート {#support-requests-or-code-bug-reports} + +一部のドキュメントのissueは、実際には元になっているコードの問題や、何か(たとえば、チュートリアル)がうまく動かないときにサポートをリクエストするものです。ドキュメントに関係のない問題は、`kind/support`ラベルを付け、サポートチャンネル(SlackやStack Overflowなど)へ報告者を導くコメントをして、もし関連があれば機能のバグに対するissueを報告するリポジトリ(`kubernetes/kubernetes`は始めるのに最適な場所です)を教えて、closeします。 + +サポートリクエストに対する返答の例を示します。(リクエストを行う際は英語で行うことが想定されるため、英文とその日本語訳を記載しています) + +```none +This issue sounds more like a request for support and less +like an issue specifically for docs. I encourage you to bring +your question to the `#kubernetes-users` channel in +[Kubernetes slack](https://slack.k8s.io/). You can also search +resources like +[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes) +for answers to similar questions. + +You can also open issues for Kubernetes functionality in +https://github.com/kubernetes/kubernetes. + +If this is a documentation issue, please re-open this issue. +``` + +```none +このissueは特定のドキュメントに関するissueではなく、サポートリクエストのようです。 +Kubernetesに関する質問については、[Kubernetes slack](https://slack.k8s.io/)の +`#kubernetes-users`チャンネルに投稿することをおすすめします。同様の質問に対する回答を +[Stack Overflow](https://stackoverflow.com/questions/tagged/kubernetes)などの +リソースで検索することもできます。 + +Kubernetesの機能に関するissueについては、https://github.com/kubernetes/kubernetes +でissueを作成できます。 + +もしこれがドキュメントに関するissueの場合、このissueを再びopenしてください。 +``` + +コードのバグに対する返答の例を示します。 + +```none +This sounds more like an issue with the code than an issue with +the documentation. Please open an issue at +https://github.com/kubernetes/kubernetes/issues. + +If this is a documentation issue, please re-open this issue. +``` + +```none +こちらのissueは、ドキュメントではなくコードに関係するissueのようです。 +https://github.com/kubernetes/kubernetes/issues でissueを作成してください。 + +もしこれがドキュメントに関するissueの場合、このissueを再びopenしてください。 +``` diff --git a/content/ja/docs/contribute/style/content-guide.md b/content/ja/docs/contribute/style/content-guide.md index eb165ca733..4161d1c489 100644 --- a/content/ja/docs/contribute/style/content-guide.md +++ b/content/ja/docs/contribute/style/content-guide.md @@ -31,7 +31,7 @@ Kubernetesのドキュメントにサードパーティーのコンテンツを - コンテンツがプロジェクト外のソフトウェアのドキュメントとなるが、Kubernetesを機能させるために必要である場合 - コンテンツがkubernetes.ioの正規のコンテンツであるか、他の場所の正規のコンテンツへのリンクである場合 -### サードパーティーのコンテンツ +### サードパーティーのコンテンツ {#third-party-content} Kubernetesのドキュメントには、Kubernetesプロジェクト([kubernetes](https://github.com/kubernetes)および[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizationsに存在するプロジェクト)の適用例が含まれています。 diff --git a/content/ja/docs/home/_index.md b/content/ja/docs/home/_index.md index 7f8837ce60..44419b4890 100644 --- a/content/ja/docs/home/_index.md +++ b/content/ja/docs/home/_index.md @@ -18,7 +18,7 @@ menu: description: > Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています。 overview: > - Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundationによってホストされています(CNCF)。 + Kubernetesは、コンテナ化されたアプリケーションの展開、スケーリング、また管理を自動化するためのオープンソースコンテナプラットフォームです。このオープンソースプロジェクトは、Cloud Native Computing Foundation(CNCF)によってホストされています。 cards: - name: concepts title: "基本を理解する" @@ -31,7 +31,7 @@ cards: button: "チュートリアルを見る" button_path: "/docs/tutorials" - name: setup - title: "クラスターを構築する" + title: "K8sクラスターを構築する" description: "リソースと要求に基づいて、Kubernetesを実行します。" button: "Kubernetesを構築する" button_path: "/docs/setup" @@ -55,9 +55,11 @@ cards: description: "プロジェクトに不慣れでも、長い間関わっていたとしても、誰でもコントリビュートすることができます。" button: "ドキュメントにコントリビュートする" button_path: /docs/contribute -- name: download - title: "Kubernetesをダウンロードする" +- name: release-notes + title: "K8sリリースノート" description: "もしKubernetesをインストールする、また最新バージョンにアップグレードする場合、最新のリリースノートを参照してください。" + button: "Kubernetesをダウンロードする" + button_path: "/docs/setup/release/notes" - name: about title: ドキュメントについて description: このWebサイトには、Kubernetesの最新バージョンと過去4世代のドキュメントが含まれています。 diff --git a/content/ja/docs/reference/_index.md b/content/ja/docs/reference/_index.md index 0496a730c4..aca4c278b5 100644 --- a/content/ja/docs/reference/_index.md +++ b/content/ja/docs/reference/_index.md @@ -16,7 +16,7 @@ content_type: concept ## APIリファレンス -* [Kubernetes API概要](/docs/reference/using-api/api-overview/) - Kubernetes APIの概要です。 +* [Kubernetes API概要](/docs/reference/using-api/) - Kubernetes APIの概要です。 * [Kubernetes APIリファレンス {{< latest-version >}}](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/) ## APIクライアントライブラリー @@ -30,9 +30,9 @@ content_type: concept ## CLIリファレンス -* [kubectl](/docs/reference/kubectl/overview/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。 +* [kubectl](/ja/docs/reference/kubectl/overview/) - コマンドの実行やKubernetesクラスターの管理に使う主要なCLIツールです。 * [JSONPath](/ja/docs/reference/kubectl/jsonpath/) - kubectlで[JSONPath記法](https://goessner.net/articles/JsonPath/)を使うための構文ガイドです。 -* [kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。 +* [kubeadm](ja/docs/reference/setup-tools/kubeadm/) - セキュアなKubernetesクラスターを簡単にプロビジョニングするためのCLIツールです。 ## コンポーネントリファレンス diff --git a/content/ja/docs/reference/access-authn-authz/rbac.md b/content/ja/docs/reference/access-authn-authz/rbac.md index fee25f323e..04409b3b8e 100644 --- a/content/ja/docs/reference/access-authn-authz/rbac.md +++ b/content/ja/docs/reference/access-authn-authz/rbac.md @@ -43,7 +43,7 @@ ClusterRolesにはいくつかの用途があります。ClusterRoleを利用し 2. Namespaceに属するリソースに対する権限を定義し、すべてのNamespaceにわたって付与する 3. クラスター単位でスコープされているリソースに対するアクセス許可を定義する -NamespaceでRoleを定義する場合は、Roleを使用します。クラスター全体でRoleを定義する婆は、ClusterRoleを使用します +NamespaceでRoleを定義する場合は、Roleを使用します。クラスター全体でRoleを定義する場合は、ClusterRoleを使用します #### Roleの例 diff --git a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md index 11334045fc..caab3b8c11 100644 --- a/content/ja/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ja/docs/reference/command-line-tools-reference/feature-gates.md @@ -136,7 +136,8 @@ content_type: concept | `TokenRequest` | `true` | Beta | 1.12 | | | `TokenRequestProjection` | `false` | Alpha | 1.11 | 1.11 | | `TokenRequestProjection` | `true` | Beta | 1.12 | | -| `TTLAfterFinished` | `false` | Alpha | 1.12 | | +| `TTLAfterFinished` | `false` | Alpha | 1.12 | 1.20 | +| `TTLAfterFinished` | `true` | Beta | 1.21 | | | `TopologyManager` | `false` | Alpha | 1.16 | 1.17 | | `TopologyManager` | `true` | Beta | 1.18 | | | `ValidateProxyRedirects` | `false` | Alpha | 1.12 | 1.13 | @@ -203,6 +204,7 @@ content_type: concept | `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - | | `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 | | `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - | +| `EnableAggregatedDiscoveryTimeout` | `true` | Deprecated | 1.16 | - | | `EnableEquivalenceClassCache` | `false` | Alpha | 1.8 | 1.14 | | `EnableEquivalenceClassCache` | - | Deprecated | 1.15 | - | | `ExperimentalCriticalPodAnnotation` | `false` | Alpha | 1.5 | 1.12 | diff --git a/content/ja/docs/reference/glossary/cloud-controller-manager.md b/content/ja/docs/reference/glossary/cloud-controller-manager.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/cluster-operator.md b/content/ja/docs/reference/glossary/cluster-operator.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/cncf.md b/content/ja/docs/reference/glossary/cncf.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/configmap.md b/content/ja/docs/reference/glossary/configmap.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/contributor.md b/content/ja/docs/reference/glossary/contributor.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/controller.md b/content/ja/docs/reference/glossary/controller.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/daemonset.md b/content/ja/docs/reference/glossary/daemonset.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/deployment.md b/content/ja/docs/reference/glossary/deployment.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/docker.md b/content/ja/docs/reference/glossary/docker.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/etcd.md b/content/ja/docs/reference/glossary/etcd.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/image.md b/content/ja/docs/reference/glossary/image.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/index.md b/content/ja/docs/reference/glossary/index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/ingress.md b/content/ja/docs/reference/glossary/ingress.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/kube-apiserver.md b/content/ja/docs/reference/glossary/kube-apiserver.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/kube-controller-manager.md b/content/ja/docs/reference/glossary/kube-controller-manager.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/kube-proxy.md b/content/ja/docs/reference/glossary/kube-proxy.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/kube-scheduler.md b/content/ja/docs/reference/glossary/kube-scheduler.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/kubelet.md b/content/ja/docs/reference/glossary/kubelet.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/label.md b/content/ja/docs/reference/glossary/label.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/member.md b/content/ja/docs/reference/glossary/member.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/mirror-pod.md b/content/ja/docs/reference/glossary/mirror-pod.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/name.md b/content/ja/docs/reference/glossary/name.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/namespace.md b/content/ja/docs/reference/glossary/namespace.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/node.md b/content/ja/docs/reference/glossary/node.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/platform-developer.md b/content/ja/docs/reference/glossary/platform-developer.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/pod.md b/content/ja/docs/reference/glossary/pod.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/secret.md b/content/ja/docs/reference/glossary/secret.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/selector.md b/content/ja/docs/reference/glossary/selector.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/service-catalog.md b/content/ja/docs/reference/glossary/service-catalog.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/service.md b/content/ja/docs/reference/glossary/service.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/sig.md b/content/ja/docs/reference/glossary/sig.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/statefulset.md b/content/ja/docs/reference/glossary/statefulset.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/uid.md b/content/ja/docs/reference/glossary/uid.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/glossary/workload.md b/content/ja/docs/reference/glossary/workload.md new file mode 100644 index 0000000000..810eeedc78 --- /dev/null +++ b/content/ja/docs/reference/glossary/workload.md @@ -0,0 +1,19 @@ +--- +title: ワークロード +id: workloads +date: 2019-02-13 +full_link: /docs/concepts/workloads/ +short_description: > + ワークロードとは、Kubernetes上で実行中のアプリケーションです。 + +aka: +tags: +- fundamental +--- + ワークロードとは、Kubernetes上で実行中のアプリケーションです。 + + + +異なる種類のワークロードやその一部を表すコアオブジェクトはさまざまなものがあり、DaemonSet、Deployment、Job、ReplicaSet、StatefulSetオブジェクトなどがあります。 + +たとえば、ウェブサーバーとデータベースを含むワークロードの場合、データベースを1つの{{< glossary_tooltip term_id="StatefulSet" >}}で実行し、ウェブサーバーを{{< glossary_tooltip term_id="Deployment" >}}で実行するという構成が考えられます。 diff --git a/content/ja/docs/reference/kubectl/_index.md b/content/ja/docs/reference/kubectl/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/reference/kubectl/overview.md b/content/ja/docs/reference/kubectl/overview.md index 2ddd60b62e..c5855ce4af 100644 --- a/content/ja/docs/reference/kubectl/overview.md +++ b/content/ja/docs/reference/kubectl/overview.md @@ -457,8 +457,6 @@ error: one plugin warning was found cat ./kubectl-whoami ``` 次の例では、下記の内容を含んだ`kubectl-whoami`が既に作成済であることを前提としています。 -The next few examples assume that you already made `kubectl-whoami` have -the following contents: ```shell #!/bin/bash diff --git a/content/ja/docs/reference/setup-tools/kubeadm/_index.md b/content/ja/docs/reference/setup-tools/kubeadm/_index.md old mode 100755 new mode 100644 index e1dfa5650c..552f54302d --- a/content/ja/docs/reference/setup-tools/kubeadm/_index.md +++ b/content/ja/docs/reference/setup-tools/kubeadm/_index.md @@ -8,7 +8,7 @@ card: weight: 40 --- -kubeadmは、`kubeadm init`や`kubeadm join`などのコマンドを提供するツールで、Kubernetesクラスターを構築する上でのベストプラクティスを反映した「近道」を提供するものとして開発されました。 +kubeadmは、`kubeadm init`や`kubeadm join`などのコマンドを提供するツールで、Kubernetesクラスターを構築する上でのベストプラクティスを反映した「近道」を提供するものとして開発されました。 kubeadmは実用最小限のクラスターをセットアップするための処理を実行します。設計上、kubeadmはブートストラップのみを行い、マシンのプロビジョニングは行いません。同様に、Kubernetesダッシュボード、モニタリングソリューション、クラウド向けのアドオンなど、あれば便利でもなくても支障のない各種アドオンのインストールも範囲外です。 diff --git a/content/ja/docs/reference/tools.md b/content/ja/docs/reference/tools.md index 0fedb1cf9d..c64b1e74f7 100644 --- a/content/ja/docs/reference/tools.md +++ b/content/ja/docs/reference/tools.md @@ -11,7 +11,7 @@ Kubernetesには、Kubernetesシステムの操作に役立ついくつかの組 [`kubectl`](/docs/tasks/tools/install-kubectl/)は、Kubernetesのためのコマンドラインツールです。このコマンドはKubernetes cluster managerを操作します。 ## Kubeadm -[`kubeadm`](docs/setup/production-environment/tools/kubeadm/install-kubeadm/)は、物理サーバやクラウドサーバ、仮想マシン上にKubenetesクラスタを容易にプロビジョニングするためのコマンドラインツールです(現在はアルファ版です)。 +[`kubeadm`](docs/setup/production-environment/tools/kubeadm/install-kubeadm/)は、物理サーバやクラウドサーバ、仮想マシン上にKubernetesクラスタを容易にプロビジョニングするためのコマンドラインツールです(現在はアルファ版です)。 ## Minikube [`minikube`](https://minikube.sigs.k8s.io/docs/)は、開発やテストのためにワークステーション上でシングルノードのKubernetesクラスタをローカルで実行するツールです。 diff --git a/content/ja/docs/search.md b/content/ja/docs/search.md deleted file mode 100644 index c6f961cdfb..0000000000 --- a/content/ja/docs/search.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -layout: search -title: 検索結果 ---- - diff --git a/content/ja/docs/setup/best-practices/cluster-large.md b/content/ja/docs/setup/best-practices/cluster-large.md index bc59b1b8ee..5a1f45b662 100644 --- a/content/ja/docs/setup/best-practices/cluster-large.md +++ b/content/ja/docs/setup/best-practices/cluster-large.md @@ -7,10 +7,10 @@ weight: 20 At {{< param "version" >}}, Kubernetes supports clusters with up to 5000 nodes. More specifically, we support configurations that meet *all* of the following criteria: +* No more than 110 pods per node * No more than 5000 nodes * No more than 150000 total pods * No more than 300000 total containers -* No more than 100 pods per node ## 構築 diff --git a/content/ja/docs/setup/learning-environment/minikube.md b/content/ja/docs/setup/learning-environment/minikube.md index c197a03081..171d2b1b1e 100644 --- a/content/ja/docs/setup/learning-environment/minikube.md +++ b/content/ja/docs/setup/learning-environment/minikube.md @@ -342,7 +342,7 @@ Could not read CA certificate "/etc/docker/ca.pem": open /etc/docker/ca.pem: no ### Kubernetesの設定 -Minikubeにはユーザーが任意の値でKubenetesコンポーネントを設定することを可能にする "configurator" 機能があります。 +Minikubeにはユーザーが任意の値でKubernetesコンポーネントを設定することを可能にする "configurator" 機能があります。 この機能を使うには、`minikube start` コマンドに `--extra-config` フラグを使うことができます。 このフラグは繰り返されるので、複数のオプションを設定するためにいくつかの異なる値を使って何度も渡すことができます。 diff --git a/content/ja/docs/setup/production-environment/tools/kops.md b/content/ja/docs/setup/production-environment/tools/kops.md index dfd2eec406..0b40a6540b 100644 --- a/content/ja/docs/setup/production-environment/tools/kops.md +++ b/content/ja/docs/setup/production-environment/tools/kops.md @@ -56,10 +56,10 @@ To download a specific version, replace the following portion of the command wit $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4) ``` -For example, to download kops version v1.15.0 type: +For example, to download kops version v1.20.0 type: ```shell -curl -LO https://github.com/kubernetes/kops/releases/download/1.15.0/kops-darwin-amd64 +curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-darwin-amd64 ``` Make the kops binary executable. @@ -94,10 +94,10 @@ To download a specific version of kops, replace the following portion of the com $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4) ``` -For example, to download kops version v1.15.0 type: +For example, to download kops version v1.20.0 type: ```shell -curl -LO https://github.com/kubernetes/kops/releases/download/1.15.0/kops-linux-amd64 +curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-linux-amd64 ``` Make the kops binary executable diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index b2b41f9128..58cd1ca133 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -75,7 +75,7 @@ kind: ClusterConfiguration kubernetesVersion: v1.16.0 scheduler: extraArgs: - address: 0.0.0.0 + bind-address: 0.0.0.0 config: /home/johndoe/schedconfig.yaml kubeconfig: /home/johndoe/kubeconfig.yaml ``` diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index 9a47644bf6..540f5f3fc7 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -6,7 +6,7 @@ weight: 30 -ベストプラクティスに準拠した実用最小限のKubernetesクラスターを作成します。実際、`kubeadm`を使用すれば、[Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification)に通るクラスターをセットアップすることができます。`kubeadm`は、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)やクラスターのアップグレードなどのその他のクラスターのライフサイクルの機能もサポートします。 +ベストプラクティスに準拠した実用最小限のKubernetesクラスターを作成します。実際、`kubeadm`を使用すれば、[Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification)に通るクラスターをセットアップすることができます。`kubeadm`は、[ブートストラップトークン](/docs/reference/access-authn-authz/bootstrap-tokens/)やクラスターのアップグレードなどのその他のクラスターのライフサイクルの機能もサポートします。 `kubeadm`ツールは、次のようなときに適しています。 diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 155ce30fd1..01fdd3a29a 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -10,7 +10,7 @@ card: - + このページでは`kubeadm`コマンドをインストールする方法を示します。このインストール処理実行後にkubeadmを使用してクラスターを作成する方法については、[kubeadmを使用したシングルマスタークラスターの作成](/ja/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)を参照してください。 @@ -223,26 +223,27 @@ CNIプラグインをインストールする(ほとんどのPodのネットワ ```bash CNI_VERSION="v0.8.2" +ARCH="amd64" mkdir -p /opt/cni/bin -curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz +curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | tar -C /opt/cni/bin -xz ``` crictlをインストールする (kubeadm / Kubelet Container Runtime Interface (CRI)に必要です) ```bash -CRICTL_VERSION="v1.16.0" -mkdir -p /opt/bin -curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | tar -C /opt/bin -xz +CRICTL_VERSION="v1.17.0" +ARCH="amd64" +curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz ``` `kubeadm`、`kubelet`、`kubectl`をインストールし`kubelet`をsystemd serviceに登録します: ```bash RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)" - +ARCH="amd64" mkdir -p /opt/bin cd /opt/bin -curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl} +curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl} chmod +x {kubeadm,kubelet,kubectl} curl -sSL "https://raw.githubusercontent.com/kubernetes/kubernetes/${RELEASE}/build/debs/kubelet.service" | sed "s:/usr/bin:/opt/bin:g" > /etc/systemd/system/kubelet.service diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md index 356101574d..319be36bbd 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md @@ -242,8 +242,8 @@ this example. ```sh root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml - root@HOST1 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml - root@HOST2 $ kubeadm init phase etcd local --config=/home/ubuntu/kubeadmcfg.yaml + root@HOST1 $ kubeadm init phase etcd local --config=/tmp/${HOST1}/kubeadmcfg.yaml + root@HOST2 $ kubeadm init phase etcd local --config=/tmp/${HOST2}/kubeadmcfg.yaml ``` 1. Optional: Check the cluster health diff --git a/content/ja/docs/setup/production-environment/tools/kubespray.md b/content/ja/docs/setup/production-environment/tools/kubespray.md index e8c49078fd..b254e63c60 100644 --- a/content/ja/docs/setup/production-environment/tools/kubespray.md +++ b/content/ja/docs/setup/production-environment/tools/kubespray.md @@ -51,7 +51,7 @@ Kubespray provides the following utilities to help provision your environment: ### (2/5) インベントリファイルの用意 -After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/intro_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". +After you provision your servers, create an [inventory file for Ansible](https://docs.ansible.com/ansible/latest/network/getting_started/first_inventory.html). You can do this manually or via a dynamic inventory script. For more information, see "[Building your own inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)". ### (3/5) クラスタ作成の計画 diff --git a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md index 6f1ed4558e..2868afb182 100644 --- a/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ja/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -134,7 +134,7 @@ Kubernetes v1.14以降、Windowsコンテナワークロードは、Group Manage Podの仕様で`"kubernetes.io/os": windows`のようなnodeSelectorが指定されていない場合、PodをWindowsまたはLinuxの任意のホストでスケジュールすることができます。WindowsコンテナはWindowsでのみ実行でき、LinuxコンテナはLinuxでのみ実行できるため、これは問題になる可能性があります。ベストプラクティスは、nodeSelectorを使用することです。 -ただし、多くの場合、ユーザーには既存の多数のLinuxコンテナのdepolyment、およびコミュニティHelmチャートのような既成構成のエコシステムやOperatorのようなプログラム的にPodを生成するケースがあることを理解しています。このような状況では、nodeSelectorsを追加するための構成変更をためらう可能性があります。代替策は、Taintsを使用することです。kubeletは登録中にTaintsを設定できるため、Windowsだけで実行する時に自動的にTaintを追加するように簡単に変更できます。 +ただし、多くの場合、ユーザーには既存の多数のLinuxコンテナのdeployment、およびコミュニティHelmチャートのような既成構成のエコシステムやOperatorのようなプログラム的にPodを生成するケースがあることを理解しています。このような状況では、nodeSelectorsを追加するための構成変更をためらう可能性があります。代替策は、Taintsを使用することです。kubeletは登録中にTaintsを設定できるため、Windowsだけで実行する時に自動的にTaintを追加するように簡単に変更できます。 例:`--register-with-taints='os=windows:NoSchedule'` diff --git a/content/ja/docs/setup/release/_index.md b/content/ja/docs/setup/release/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/sitemap.md b/content/ja/docs/sitemap.md deleted file mode 100644 index 287642c004..0000000000 --- a/content/ja/docs/sitemap.md +++ /dev/null @@ -1,114 +0,0 @@ ---- ---- - - - -ページ上のタグをクリックするか、カラムのドロップダウンを使って記事をフィルターできます。テーブルヘッダーをクリックすると並び順をソートすることができます。 - -

    -コンセプトでフィルター:
    -オブジェクトでフィルター:
    -コマンドでフィルター: -

    - -
    diff --git a/content/ja/docs/tasks/access-application-cluster/_index.md b/content/ja/docs/tasks/access-application-cluster/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index d5f6b72296..e250155f2d 100644 --- a/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -232,7 +232,7 @@ contexts: 上記の設定ファイルは、`dev-ramp-up`というコンテキストを表します。 -## KUBECONFIG環境変数を設定する +## KUBECONFIG環境変数を設定する {#set-the-kubeconfig-environment-variable} `KUBECONFIG`という環境変数が存在するかを確認してください。もし存在する場合は、後で復元できるようにバックアップしてください。例えば: diff --git a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md index 8235e113ae..ba78ba15fa 100644 --- a/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ja/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -55,7 +55,7 @@ kubectl proxy kubectlは、ダッシュボードを http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ で利用できるようにします。 -UIはコマンドを実行しているマシンから_のみ_ アクセスできます。オプションについては`kubectl proxy --help`を参照してください。 +UIはコマンドを実行しているマシンから _のみ_ アクセスできます。オプションについては`kubectl proxy --help`を参照してください。 {{< note >}} Kubeconfigの認証方法は、外部IDプロバイダーやx509証明書ベースの認証には対応していません。 diff --git a/content/ja/docs/tasks/administer-cluster/_index.md b/content/ja/docs/tasks/administer-cluster/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/tasks/administer-cluster/topology-manager.md b/content/ja/docs/tasks/administer-cluster/topology-manager.md new file mode 100644 index 0000000000..6478323e1a --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/topology-manager.md @@ -0,0 +1,248 @@ +--- +title: ノードのトポロジー管理ポリシーを制御する +content_type: task +min-kubernetes-server-version: v1.18 +--- + + + +{{< feature-state state="beta" for_k8s_version="v1.18" >}} + +近年、CPUやハードウェア・アクセラレーターの組み合わせによって、レイテンシーが致命的となる実行や高いスループットを求められる並列計算をサポートするシステムが増えています。このようなシステムには、通信、科学技術計算、機械学習、金融サービス、データ分析などの分野のワークロードが含まれます。このようなハイブリッドシステムは、高い性能の環境で構成されます。 + +最高のパフォーマンスを引き出すために、CPUの分離やメモリーおよびデバイスの位置に関する最適化が求められます。しかしながら、Kubernetesでは、これらの最適化は分断されたコンポーネントによって処理されます。 + +_トポロジーマネージャー_ はKubeletコンポーネントの1つで最適化の役割を担い、コンポーネント群を調和して機能させます。 + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +## トポロジーマネージャーはどのように機能するか + +トポロジーマネージャー導入前は、KubernetesにおいてCPUマネージャーやデバイスマネージャーはそれぞれ独立してリソースの割り当てを決定します。 +これは、マルチソケットのシステムでは望ましくない割り当てとなり、パフォーマンスやレイテンシーが求められるアプリケーションは、この望ましくない割り当てに悩まされます。 +この場合の望ましくない例として、CPUやデバイスが異なるNUMAノードに割り当てられ、それによりレイテンシー悪化を招くことが挙げられます。 + +トポロジーマネージャーはKubeletコンポーネントであり、信頼できる情報源として振舞います。それによって、他のKubeletコンポーネントはトポロジーに沿ったリソース割り当ての選択を行うことができます。 + +トポロジーマネージャーは *Hint Providers* と呼ばれるコンポーネントのインターフェースを提供し、トポロジー情報を送受信します。トポロジーマネージャーは、ノード単位のポリシー群を保持します。ポリシーについて以下で説明します。 + +トポロジーマネージャーは *Hint Providers* からトポロジー情報を受け取ります。トポロジー情報は、利用可能なNUMAノードと優先割り当て表示を示すビットマスクです。トポロジーマネージャーのポリシーは、提供されたヒントに対して一連の操作を行い、ポリシーに沿ってヒントをまとめて最適な結果を得ます。もし、望ましくないヒントが保存された場合、ヒントの優先フィールドがfalseに設定されます。現在のポリシーでは、最も狭い優先マスクが優先されます。 + +選択されたヒントはトポロジーマネージャーの一部として保存されます。設定されたポリシーにしたがい、選択されたヒントに基づいてノードがPodを許可したり、拒否することができます。 +トポロジーマネージャーに保存されたヒントは、*Hint Providers* が使用しリソース割り当てを決定します。 + +### トポロジーマネージャーの機能を有効にする + +トポロジーマネージャーをサポートするには、`TopologyManager` [フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にする必要があります。Kubernetes 1.18ではデフォルトで有効です。 + +## トポロジーマネージャーのスコープとポリシー + +トポロジーマネージャは現在: + + - 全てのQoAクラスのPodを調整する + - Hint Providerによって提供されたトポロジーヒントから、要求されたリソースを調整する + +これらの条件が合致した場合、トポロジーマネージャーは要求されたリソースを調整します。 + +この調整をどのように実行するかカスタマイズするために、トポロジーマネージャーは2つのノブを提供します: `スコープ` と`ポリシー`です。 + +`スコープ`はリソースの配置を行う粒度を定義します(例:`pod`や`container`)。そして、`ポリシー`は調整を実行するための実戦略を定義します(`best-effort`, `restricted`, `single-numa-node`等)。 + +現在利用可能な`スコープ`と`ポリシー`の値について詳細は以下の通りです。 + +{{< note >}} +PodのSpecにある他の要求リソースとCPUリソースを調整するために、CPUマネージャーを有効にし、適切なCPUマネージャーのポリシーがノードに設定されるべきです。[CPU管理ポリシー](/docs/tasks/administer-cluster/cpu-management-policies/)を参照してください。 +{{< /note >}} + +{{< note >}} +PodのSpecにある他の要求リソースとメモリー（およびhugepage）リソースを調整するために、メモリーマネージャーを有効にし、適切なメモリーマネージャーポリシーがノードに設定されるべきです。[メモリーマネージャー](/docs/tasks/administer-cluster/memory-manager/) のドキュメントを確認してください。 +{{< /note >}} + +### トポロジーマネージャーのスコープ + +トポロジーマネージャーは、以下の複数の異なるスコープでリソースの調整を行う事が可能です: + +* `container` (デフォルト) +* `pod` + +いずれのオプションも、`--topology-manager-scope`フラグによって、kubelet起動時に選択できます。 + +### containerスコープ + +`container`スコープはデフォルトで使用されます。 + +このスコープでは、トポロジーマネージャーは連続した複数のリソース調整を実行します。つまり、Pod内の各コンテナは、分離された配置計算がされます。言い換えると、このスコープでは、コンテナを特定のNUMAノードのセットにグループ化するという概念はありません。実際には、トポロジーマネージャーは各コンテナのNUMAノードへの配置を任意に実行します。 + +コンテナをグループ化するという概念は、以下のスコープで設定・実行されます。例えば、`pod`スコープが挙げられます。 + +### podスコープ + +`pod`スコープを選択するには、コマンドラインで`--topology-manager-scope=pod`オプションを指定してkubeletを起動します。 + +このスコープでは、Pod内全てのコンテナを共通のNUMAノードのセットにグループ化することができます。トポロジーマネージャーはPodをまとめて1つとして扱い、ポッド全体（全てのコンテナ）を単一のNUMAノードまたはNUMAノードの共通セットのいずれかに割り当てようとします。以下の例は、さまざまな場面でトポロジーマネージャーが実行する調整を示します: + +* 全てのコンテナは、単一のNUMAノードに割り当てられます。 +* 全てのコンテナは、共有されたNUMAノードのセットに割り当てられます。 + +Pod全体に要求される特定のリソースの総量は[有効なリクエスト／リミット](/ja/docs/concepts/workloads/pods/init-containers/#resources)の式に従って計算されるため、この総量の値は以下の最大値となります。 +* 全てのアプリケーションコンテナのリクエストの合計。 +* リソースに対するinitコンテナのリクエストの最大値。 + +`pod`スコープと`single-numa-node`トポロジーマネージャーポリシーを併用することは、レイテンシーが重要なワークロードやIPCを行う高スループットのアプリケーションに対して特に有効です。両方のオプションを組み合わせることで、Pod内の全てのコンテナを単一のNUMAノードに配置できます。そのため、PodのNUMA間通信によるオーバーヘッドを排除することができます。 + +`single-numa-node`ポリシーの場合、可能な割り当ての中に適切なNUMAノードのセットが存在する場合にのみ、Podが許可されます。上の例をもう一度考えてみましょう: + +* 1つのNUMAノードのみを含むセット - Podが許可されます。 +* 2つ以上のNUMAノードを含むセット - Podが拒否されます(1つのNUMAノードの代わりに、割り当てを満たすために2つ以上のNUMAノードが必要となるため)。 + + +要約すると、トポロジーマネージャーはまずNUMAノードのセットを計算し、それをトポロジーマネージャーのポリシーと照合し、Podの拒否または許可を検証します。 + +### トポロジーマネージャーのポリシー + +トポロジーマネージャーは4つの調整ポリシーをサポートします。`--topology-manager-policy`というKubeletフラグを通してポリシーを設定できます。 +4つのサポートされるポリシーがあります: + +* `none` (デフォルト) +* `best-effort` +* `restricted` +* `single-numa-node` + +{{< note >}} +トポロジーマネージャーが **pod** スコープで設定された場合、コンテナはポリシーによって、Pod全体の要求として反映します。 +したがって、Podの各コンテナは **同じ** トポロジー調整と同じ結果となります。 +{{< /note >}} + +### none ポリシー {#policy-none} + +これはデフォルトのポリシーで、トポロジーの調整を実行しません。 + +### best-effort ポリシー {#policy-best-effort} + +Pod内の各コンテナに対して、`best-effort` トポロジー管理ポリシーが設定されたkubeletは、各Hint Providerを呼び出してそれらのリソースの可用性を検出します。 +トポロジーマネージャーはこの情報を使用し、そのコンテナの推奨されるNUMAノードのアフィニティーを保存します。アフィニティーが優先されない場合、トポロジーマネージャーはこれを保存し、Podをノードに許可します。 + +*Hint Providers* はこの情報を使ってリソースの割り当てを決定します。 + +### restricted ポリシー {#policy-restricted} + +Pod内の各コンテナに対して、`restricted` トポロジー管理ポリシーが設定されたkubeletは各Hint Providerを呼び出してそれらのリソースの可用性を検出します。 +トポロジーマネージャーはこの情報を使用し、そのコンテナの推奨されるNUMAノードのアフィニティーを保存します。アフィニティーが優先されない場合、トポロジーマネージャーはPodをそのノードに割り当てることを拒否します。この結果、PodはPodの受付失敗となり`Terminated` 状態になります。 + +Podが一度`Terminated`状態になると、KubernetesスケジューラーはPodの再スケジューリングを試み **ません** 。Podの再デプロイをするためには、ReplicasetかDeploymenを使用してください。`Topology Affinity`エラーとなったpodを再デプロイするために、外部のコントロールループを実行することも可能です。 + +Podが許可されれば、 *Hint Providers* はこの情報を使ってリソースの割り当てを決定します。 + +### single-numa-node ポリシー {#policy-single-numa-node} + +Pod内の各コンテナに対して、`single-numa-node`トポロジー管理ポリシーが設定されたkubeletは各Hint Prociderを呼び出してそれらのリソースの可用性を検出します。 +トポロジーマネージャーはこの情報を使用し、単一のNUMAノードアフィニティが可能かどうか決定します。 +可能な場合、トポロジーマネージャーは、この情報を保存し、*Hint Providers* はこの情報を使ってリソースの割り当てを決定します。 +不可能な場合、トポロジーマネージャーは、Podをそのノードに割り当てることを拒否します。この結果、Pod は Pod の受付失敗となり`Terminated`状態になります。 + +Podが一度`Terminated`状態になると、KubernetesスケジューラーはPodの再スケジューリングを試み**ません**。Podの再デプロイをするためには、ReplicasetかDeploymentを使用してください。`Topology Affinity`エラーとなったpodを再デプロイするために、外部のコントロールループを実行することも可能です。 + +### Podとトポロジー管理ポリシーの関係 + +以下のようなpodのSpecで定義されるコンテナを考えます: + +```yaml +spec: + containers: + - name: nginx + image: nginx +``` + +`requests`も`limits`も定義されていないため、このPodは`BestEffort`QoSクラスで実行します。 + +```yaml +spec: + containers: + - name: nginx + image: nginx + resources: + limits: + memory: "200Mi" + requests: + memory: "100Mi" +``` + +requestsがlimitsより小さい値のため、このPodは`Burstable`QoSクラスで実行します。 + +選択されたポリシーが`none`以外の場合、トポロジーマネージャーは、これらのPodのSpecを考慮します。トポロジーマネージャーは、Hint Providersからトポロジーヒントを取得します。CPUマネージャーポリシーが`static`の場合、デフォルトのトポロジーヒントを返却します。これらのPodは明示的にCPUリソースを要求していないからです。 + + +```yaml +spec: + containers: + - name: nginx + image: nginx + resources: + limits: + memory: "200Mi" + cpu: "2" + example.com/device: "1" + requests: + memory: "200Mi" + cpu: "2" + example.com/device: "1" +``` + +整数値でCPUリクエストを指定されたこのPodは、`requests`が`limits`が同じ値のため、`Guaranteed`QoSクラスで実行します。 + + +```yaml +spec: + containers: + - name: nginx + image: nginx + resources: + limits: + memory: "200Mi" + cpu: "300m" + example.com/device: "1" + requests: + memory: "200Mi" + cpu: "300m" + example.com/device: "1" +``` + +CPUの一部をリクエストで指定されたこのPodは、`requests`が`limits`が同じ値のため、`Guaranteed`QoSクラスで実行します。 + + +```yaml +spec: + containers: + - name: nginx + image: nginx + resources: + limits: + example.com/deviceA: "1" + example.com/deviceB: "1" + requests: + example.com/deviceA: "1" + example.com/deviceB: "1" +``` +CPUもメモリもリクエスト値がないため、このPodは `BestEffort` QoSクラスで実行します。 + +トポロジーマネージャーは、上記Podを考慮します。トポロジーマネージャーは、Hint ProvidersとなるCPUマネージャーとデバイスマネージャーに問い合わせ、トポロジーヒントを取得します。 + +整数値でCPU要求を指定された`Guaranteed`QoSクラスのPodの場合、`static`が設定されたCPUマネージャーポリシーは、排他的なCPUに関するトポロジーヒントを返却し、デバイスマネージャーは要求されたデバイスのヒントを返します。 + +CPUの一部を要求を指定された`Guaranteed`QoSクラスのPodの場合、排他的ではないCPU要求のため`static`が設定されたCPUマネージャーポリシーはデフォルトのトポロジーヒントを返却します。デバイスマネージャーは要求されたデバイスのヒントを返します。 + +上記の`Guaranteed`QoSクラスのPodに関する2ケースでは、`none`で設定されたCPUマネージャーポリシーは、デフォルトのトポロジーヒントを返却します。 + +`BestEffort`QoSクラスのPodの場合、`static`が設定されたCPUマネージャーポリシーは、CPUの要求がないためデフォルトのトポロジーヒントを返却します。デバイスマネージャーは要求されたデバイスごとのヒントを返します。 + +トポロジーマネージャーはこの情報を使用してPodに最適なヒントを計算し保存します。保存されたヒントは Hint Providersが使用しリソースを割り当てます。 + +### 既知の制限 +1. トポロジーマネージャーが許容するNUMAノードの最大値は8です。8より多いNUMAノードでは、可能なNUMAアフィニティを列挙しヒントを生成する際に、生成する状態数が爆発的に増加します。 + +2. スケジューラーはトポロジーを意識しません。そのため、ノードにスケジュールされた後に実行に失敗する可能性があります。 diff --git a/content/ja/docs/tasks/configmap-secret/_index.md b/content/ja/docs/tasks/configmap-secret/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/tasks/configmap-secret/managing-secret-using-config-file.md b/content/ja/docs/tasks/configmap-secret/managing-secret-using-config-file.md new file mode 100644 index 0000000000..e4c19098fe --- /dev/null +++ b/content/ja/docs/tasks/configmap-secret/managing-secret-using-config-file.md @@ -0,0 +1,183 @@ +--- +title: 設定ファイルを使用してSecretを管理する +content_type: task +weight: 20 +description: リソース設定ファイルを使用してSecretを作成する +--- + + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + + + +## 設定ファイルを作成する + +あらかじめYAMLまたはJSON形式でSecretのマニフェストを作成したうえで、オブジェクトを作成することができます。 +[Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)リソースには、`data`と`stringData`の2つのマップが含まれています。 +`data`フィールドは任意のデータを格納するのに使用され、base64でエンコードされます。 +`stringData`フィールドは利便性のために用意されており、Secretデータをエンコードされていない文字列として提供することができます。 +`data`と`stringData`のキーは、英数字、`-`、`_`、`.`で構成されている必要があります。 + +たとえば、`data`フィールドを使用して2つの文字列をSecretに格納するには、次のように文字列をbase64に変換します: + +```shell +echo -n 'admin' | base64 +``` + +出力は次のようになります: + +``` +YWRtaW4= +``` + +```shell +echo -n '1f2d1e2e67df' | base64 +``` + +出力は次のようになります: + +``` +MWYyZDFlMmU2N2Rm +``` + +以下のようなSecret設定ファイルを記述します: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +``` + +なお、Secretオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。 + +{{< note >}} +SecretデータのシリアライズされたJSONおよびYAMLの値は、base64文字列としてエンコードされます。 +文字列中の改行は不正で、含まれていてはなりません。 +Darwin/macOSで`base64`ユーティリティーを使用する場合、長い行を分割するために`-b`オプションを使用するのは避けるべきです。 +逆に、Linux ユーザーは、`base64` コマンドにオプション`-w 0`を追加するか、`-w`オプションが利用できない場合には、パイプライン`base64 | tr -d '\n'`を追加する*必要があります*。 +{{< /note >}} + +特定のシナリオでは、代わりに`stringData`フィールドを使用できます。 +このフィールドでは、base64エンコードされていない文字列を直接Secretに入れることができ、Secretの作成時や更新時には、その文字列がエンコードされます。 + +たとえば、設定ファイルを保存するためにSecretを使用しているアプリケーションをデプロイする際に、デプロイプロセス中に設定ファイルの一部を入力したい場合などが考えられます。 + +たとえば、次のような設定ファイルを使用しているアプリケーションの場合: + +```yaml +apiUrl: "https://my.api.com/api/v1" +username: "" +password: "" +``` + +次のような定義でSecretに格納できます: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +stringData: + config.yaml: | + apiUrl: "https://my.api.com/api/v1" + username: + password: +``` + +## Secretを作成する + +[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)でSecretを作成します: + +```shell +kubectl apply -f ./secret.yaml +``` + +出力は次のようになります: + +``` +secret/mysecret created +``` + +## Secretを確認する + +`stringData`フィールドは、書き込み専用の便利なフィールドです。Secretを取得する際には決して出力されません。たとえば、次のようなコマンドを実行した場合: + +```shell +kubectl get secret mysecret -o yaml +``` + +出力は次のようになります: + +```yaml +apiVersion: v1 +data: + config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19 +kind: Secret +metadata: + creationTimestamp: 2018-11-15T20:40:59Z + name: mysecret + namespace: default + resourceVersion: "7225" + uid: c280ad2e-e916-11e8-98f2-025000000001 +type: Opaque +``` + +`kubectl get`と`kubectl describe`コマンドはデフォルトではSecretの内容を表示しません。 +これは、Secretが不用意に他人にさらされたり、ターミナルログに保存されたりしないようにするためです。 +エンコードされたデータの実際の内容を確認するには、[Secretのデコード](/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret)を参照してください。 + +`username`などのフィールドが`data`と`stringData`の両方に指定されている場合は、`stringData`の値が使われます。 +たとえば、以下のようなSecretの定義の場合: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + username: YWRtaW4= +stringData: + username: administrator +``` + +結果は以下の通りです: + +```yaml +apiVersion: v1 +data: + username: YWRtaW5pc3RyYXRvcg== +kind: Secret +metadata: + creationTimestamp: 2018-11-15T20:46:46Z + name: mysecret + namespace: default + resourceVersion: "7579" + uid: 91460ecb-e917-11e8-98f2-025000000001 +type: Opaque +``` + +`YWRtaW5pc3RyYXRvcg==`をデコードすると`administrator`となります。 + +## クリーンアップ + +作成したSecretを削除するには次のコマンドを実行します: + +```shell +kubectl delete secret mysecret +``` + +## {{% heading "whatsnext" %}} + +- [Secretのコンセプト](/ja/docs/concepts/configuration/secret/)を読む +- [kubectlを使用してSecretを管理する](/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl/)方法を知る +- [kustomizeを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を知る diff --git a/content/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl.md b/content/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl.md index fb8c89c1e3..7be8c0b890 100644 --- a/content/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl.md +++ b/content/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl.md @@ -58,7 +58,7 @@ kubectl create secret generic db-user-pass \ たとえば、実際のパスワードが`S!B\*d$zDsb=`の場合、次のようにコマンドを実行します: ```shell -kubectl create secret generic dev-db-secret \ +kubectl create secret generic db-user-pass \ --from-literal=username=devuser \ --from-literal=password='S!B\*d$zDsb=' ``` @@ -114,10 +114,10 @@ kubectl get secret db-user-pass -o jsonpath='{.data}' 出力は次のようになります: ```json -{"password.txt":"MWYyZDFlMmU2N2Rm","username.txt":"YWRtaW4="} +{"password":"MWYyZDFlMmU2N2Rm","username":"YWRtaW4="} ``` -`password.txt`のデータをデコードします: +`password`のデータをデコードします: ```shell echo 'MWYyZDFlMmU2N2Rm' | base64 --decode @@ -142,5 +142,5 @@ kubectl delete secret db-user-pass ## {{% heading "whatsnext" %}} - [Secretのコンセプト](/ja/docs/concepts/configuration/secret/)を読む -- [設定ファイルを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-config-file/)方法を知る +- [設定ファイルを使用してSecretを管理する](/ja/docs/tasks/configmap-secret/managing-secret-using-config-file/)方法を知る - [kustomizeを使用してSecretを管理する](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)方法を知る diff --git a/content/ja/docs/tasks/configmap-secret/managing-secret-using-kustomize.md b/content/ja/docs/tasks/configmap-secret/managing-secret-using-kustomize.md new file mode 100644 index 0000000000..9d4df475f3 --- /dev/null +++ b/content/ja/docs/tasks/configmap-secret/managing-secret-using-kustomize.md @@ -0,0 +1,129 @@ +--- +title: Kustomizeを使用してSecretを管理する +content_type: task +weight: 30 +description: kustomization.yamlを使用してSecretを作成する +--- + + + +Kubernetes v1.14以降、`kubectl`は[Kustomizeを使ったオブジェクト管理](/docs/tasks/manage-kubernetes-objects/kustomization/)をサポートしています。 +KustomizeはSecretやConfigMapを作成するためのリソースジェネレーターを提供します。 +Kustomizeジェネレーターは、ディレクトリ内の`kustomization.yaml`ファイルで指定します。 +Secretを生成したら、`kubectl apply`でAPIサーバー上にSecretを作成します。 + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + + + +## Kustomizationファイルを作成する + +`kustomization.yaml`ファイルの中で`secretGenerator`を定義し、他の既存のファイルを参照することで、Secretを生成することができます。 +たとえば、以下のkustomizationファイルは`./username.txt`と`./password.txt`を参照しています。 + +```yaml +secretGenerator: +- name: db-user-pass + files: + - username.txt + - password.txt +``` + +また、`kustomization.yaml`ファイルの中でリテラルを指定して`secretGenerator`を定義することもできます。 +たとえば、以下の`kustomization.yaml`ファイルには`username`と`password`の2つのリテラルが含まれています。 + +```yaml +secretGenerator: +- name: db-user-pass + literals: + - username=admin + - password=1f2d1e2e67df +``` + +また、`kustomization.yaml`ファイルに`.env`ファイルを用意して`secretGenerator`を定義することもできます。 +たとえば、以下の`kustomization.yaml`ファイルは、`.env.secret`ファイルからデータを取り込みます。 + +```yaml +secretGenerator: +- name: db-user-pass + envs: + - .env.secret +``` + +なお、いずれの場合も、値をbase64エンコードする必要はありません。 + +## Secretを作成する + +`kustomization.yaml`を含むディレクトリを適用して、Secretを作成します。 + +```shell +kubectl apply -k . +``` + +出力は次のようになります: + +``` +secret/db-user-pass-96mffmfh4k created +``` + +なお、Secretを生成する際には、データをハッシュ化し、そのハッシュ値を付加することでSecret名を生成します。 +これにより、データが変更されるたびに、新しいSecretが生成されます。 + +## 作成したSecretを確認する + +Secretが作成されたことを確認できます: + +```shell +kubectl get secrets +``` + +出力は次のようになります: + +``` +NAME TYPE DATA AGE +db-user-pass-96mffmfh4k Opaque 2 51s +``` + +Secretの説明を参照できます: + +```shell +kubectl describe secrets/db-user-pass-96mffmfh4k +``` + +出力は次のようになります: + +``` +Name: db-user-pass-96mffmfh4k +Namespace: default +Labels: +Annotations: + +Type: Opaque + +Data +==== +password.txt: 12 bytes +username.txt: 5 bytes +``` + +`kubectl get`と`kubectl describe`コマンドはデフォルトではSecretの内容を表示しません。 +これは、Secretが不用意に他人にさらされたり、ターミナルログに保存されたりしないようにするためです。 +エンコードされたデータの実際の内容を確認するには、[Secretのデコード](/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret)を参照してください。 + +## クリーンアップ + +作成したSecretを削除するには次のコマンドを実行します: + +```shell +kubectl delete secret db-user-pass-96mffmfh4k +``` + + +## {{% heading "whatsnext" %}} + +- [Secretのコンセプト](/ja/docs/concepts/configuration/secret/)を読む +- [kubectlを使用してSecretを管理する](/ja/docs/tasks/configmap-secret/managing-secret-using-kubectl/)方法を知る +- [設定ファイルを使用してSecretを管理する](/ja/docs/tasks/configmap-secret/managing-secret-using-config-file/)方法を知る + diff --git a/content/ja/docs/tasks/configure-pod-container/_index.md b/content/ja/docs/tasks/configure-pod-container/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/tasks/debug-application-cluster/_index.md b/content/ja/docs/tasks/debug-application-cluster/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index 570134b84d..89e927aff9 100644 --- a/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/ja/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -47,7 +47,7 @@ Podをスケジュールできない理由に関するスケジューラーか クラスター内のCPUまたはメモリーの供給を使い果たした可能性があります。 この場合、いくつかのことを試すことができます。 -* クラスターに[ノードを追加します](/docs/tasks/administer-cluster/cluster-management/#resizing-a-cluster)。 +* クラスターにノードを追加します。 * [不要なPodを終了](/docs/concepts/workloads/pods/#pod-termination)して、 `Pending`状態のPodのための空きリソースを作ります。 diff --git a/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md index fdddb859ce..1fbdb763aa 100644 --- a/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md +++ b/content/ja/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md @@ -33,7 +33,7 @@ content_type: task kubectl apply -f https://k8s.io/examples/debug/termination.yaml - YAMLファイルの`cmd`フィールドと`args`フィールドで、コンテナが10秒間スリープしてから`/dev/termination-log`ファイルに「Sleep expired」と書いているのがわかります。コンテナが「Sleep expired」メッセージを書き込んだ後、コンテナは終了します。 + YAMLファイルの`command`フィールドと`args`フィールドで、コンテナが10秒間スリープしてから`/dev/termination-log`ファイルに「Sleep expired」と書いているのがわかります。コンテナが「Sleep expired」メッセージを書き込んだ後、コンテナは終了します。 1. Podに関する情報を表示します: diff --git a/content/ja/docs/tasks/job/_index.md b/content/ja/docs/tasks/job/_index.md new file mode 100644 index 0000000000..bde073017b --- /dev/null +++ b/content/ja/docs/tasks/job/_index.md @@ -0,0 +1,6 @@ +--- +title: "Jobの実行" +description: 並列処理を使用してJobを実行します。 +weight: 50 +--- + diff --git a/content/ja/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/ja/docs/tasks/job/automated-tasks-with-cron-jobs.md new file mode 100644 index 0000000000..17855a66d6 --- /dev/null +++ b/content/ja/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -0,0 +1,175 @@ +--- +title: CronJobを使用して自動化タスクを実行する +min-kubernetes-server-version: v1.21 +content_type: task +weight: 10 +--- + + + +CronJobは、Kubernetes v1.21で一般利用(GA)に昇格しました。古いバージョンのKubernetesを使用している場合、正確な情報を参照できるように、使用しているバージョンのKubernetesのドキュメントを参照してください。古いKubernetesのバージョンでは、`batch/v1` CronJob APIはサポートされていません。 + +{{< glossary_tooltip text="CronJob" term_id="cronjob" >}}を使用すると、{{< glossary_tooltip text="Job" term_id="job" >}}を時間ベースのスケジュールで実行できるようになります。この自動化されたJobは、LinuxまたはUNIXシステム上の[Cron](https://ja.wikipedia.org/wiki/Cron)のように実行されます。 + +CronJobは、バックアップやメールの送信など、定期的なタスクや繰り返しのタスクを作成する時に便利です。CronJobはそれぞれのタスクを、たとえばアクティビティが少ない期間など、特定の時間にスケジューリングすることもできます。 + +CronJobには制限と特性があります。たとえば、特定の状況下では、1つのCronJobが複数のJobを作成する可能性があるため、Jobは冪等性を持つようにしなければいけません。 + +制限に関する詳しい情報については、[CronJob](/ja/docs/concepts/workloads/controllers/cron-jobs/)を参照してください。 + +## {{% heading "prerequisites" %}} + +* {{< include "task-tutorial-prereqs.md" >}} + + + +## CronJobを作成する + +CronJobには設定ファイルが必要です。次の例のCronJobの`.spec`は、現在の時刻とhelloというメッセージを1分ごとに表示します。 + +{{< codenew file="application/job/cronjob.yaml" >}} + +次のコマンドで例のCronJobを実行します。 + +```shell +kubectl create -f https://k8s.io/examples/application/job/cronjob.yaml +``` + +出力は次のようになります。 + +``` +cronjob.batch/hello created +``` + +CronJobを作成したら、次のコマンドで状態を取得します。 + +```shell +kubectl get cronjob hello +``` + +出力は次のようになります。 + +``` +NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE +hello */1 * * * * False 0 10s +``` + +コマンドの結果からわかるように、CronJobはまだスケジュールされておらず、まだ何のJobも実行していません。約1分以内にJobが作成されるのを見てみましょう。 + +```shell +kubectl get jobs --watch +``` + +出力は次のようになります。 + +``` +NAME COMPLETIONS DURATION AGE +hello-4111706356 0/1 0s +hello-4111706356 0/1 0s 0s +hello-4111706356 1/1 5s 5s +``` + +"hello"CronJobによってスケジュールされたJobが1つ実行中になっていることがわかります。Jobを見るのをやめて、再度CronJobを表示して、Jobがスケジュールされたことを確認してみます。 + +```shell +kubectl get cronjob hello +``` + +出力は次のようになります。 + +``` +NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE +hello */1 * * * * False 0 50s 75s +``` + +CronJob`hello`が、`LAST SCHEDULE`で指定された時間にJobを正しくスケジュールしたことが確認できるはずです。現在、activeなJobの数は0です。つまり、Jobは完了または失敗したことがわかります。 + +それでは、最後にスケジュールされたJobの作成と、Podの1つの標準出力を表示してみましょう。 + +{{< note >}} +Jobの名前とPodの名前は異なります。 +{{< /note >}} + +```shell +# "hello-4111706356" の部分は、あなたのシステム上のJobの名前に置き換えてください。 +pods=$(kubectl get pods --selector=job-name=hello-4111706356 --output=jsonpath={.items[*].metadata.name}) +``` + +Podのログを表示します。 + +```shell +kubectl logs $pods +``` + +出力は次のようになります。 + +``` +Fri Feb 22 11:02:09 UTC 2019 +Hello from the Kubernetes cluster +``` + +## CronJobの削除 + +CronJobが必要なくなったときは、`kubectl delete cronjob `で削除します。 + +```shell +kubectl delete cronjob hello +``` + +CronJobを削除すると、すべてのJobと、そのJobが作成したPodが削除され、追加のJobの作成が停止されます。Jobの削除について詳しく知りたい場合は、[ガベージコレクション](/ja/docs/concepts/workloads/controllers/garbage-collection/)を読んでください。 + +## CronJobのspecを書く {#writing-a-cron-job-spec} + +すべてのKubernetesの設定と同じように、CronJobにも`apiVersion`、`kind`、`metadata`のフィールドが必要です。設定ファイルの扱い方についての一般的な情報については、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)と[kubectlを使用してリソースを管理する](/ja/docs/concepts/overview/working-with-objects/object-management/)を読んでください。 + +CronJobの設定には、[`.spec`セクション](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)も必要です。 + +{{< note >}} +CronJobの特に`spec`へのすべての修正は、それ以降の実行にのみ適用されます。 +{{< /note >}} + +### Schedule + +`.spec.schedule`は、`.spec`には必須のフィールドです。`0 * * * *`や`@hourly`などの[Cron](https://ja.wikipedia.org/wiki/Cron)形式の文字列を取り、Jobの作成と実行のスケジュール時間を指定します。 + +フォーマットにはVixie cronのステップ値(step value)も指定できます。[FreeBSDのマニュアル](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)では次のように説明されています。 + +> ステップ値は範囲指定と組み合わせて使用できます。範囲の後ろに`/`を付けると、範囲全体で指定したnumberの値ごとにスキップすることを意味します。たとえば、`0-23/2`をhoursフィールドに指定すると、2時間毎にコマンド実行を指定することになります(V7標準では代わりに`0,2,4,6,8,10,12,14,16,18,20,22`と指定する必要があります)。ステップはアスタリスクの後ろにつけることもできます。そのため、「2時間毎に実行」したい場合は、単純に`*/2`と指定できます。 + +{{< note >}} +スケジュール内の疑問符`?`はアスタリスク`*`と同じ意味を持ちます。つまり、与えられたフィールドには任意の値が使えるという意味になります。 +{{< /note >}} + +### Job Template + +`.spec.jobTemplate`はJobのテンプレートであり、必須です。[Job](/docs/concepts/workloads/controllers/job/)と完全に同一のスキーマを持ちますが、フィールドがネストされている点と、`apiVersion`と`kind`が存在しない点だけが異なります。Jobの`.spec`を書くための情報については、[JobのSpecを書く](/docs/concepts/workloads/controllers/job/#writing-a-job-spec)を参照してください。 + +### Starting Deadline + +`.spec.startingDeadlineSeconds`フィールドはオプションです。何かの理由でスケジュールに間に合わなかった場合に適用される、Jobの開始のデッドライン(締め切り)を秒数で指定します。デッドラインを過ぎると、CronJobはJobを開始しません。この場合にデッドラインに間に合わなかったJobは、失敗したJobとしてカウントされます。もしこのフィールドが指定されなかった場合、Jobはデッドラインを持ちません。 + +`.spec.startingDeadlineSeconds`フィールドがnull以外に設定された場合、CronJobコントローラーはJobの作成が期待される時間と現在時刻との間の時間を計測します。もしその差が制限よりも大きかった場合、その実行はスキップされます。 + +たとえば、この値が`200`に設定された場合、実際のスケジュールの最大200秒後までに作成されるJobだけが許可されます。 + +### Concurrency Policy + +`.spec.concurrencyPolicy`フィールドもオプションです。このフィールドは、このCronJobで作成されたJobの並列実行をどのように扱うかを指定します。specには以下のconcurrency policyのいずれかを指定します。 + +* `Allow` (デフォルト): CronJobがJobを並列に実行することを許可します。 +* `Forbid`: CronJobの並列実行を禁止します。もし新しいJobの実行時に過去のJobがまだ完了していなかった場合、CronJobは新しいJobの実行をスキップします。 +* `Replace`: もし新しいJobの実行の時間になっても過去のJobの実行が完了していなかった場合、CronJobは現在の実行中のJobを新しいJobで置換します。 + +concurrency policyは、同じCronJobが作成したJobにのみ適用されます。もし複数のCronJobがある場合、それぞれのJobの並列実行は常に許可されます。 + +### Suspend + +`.spec.suspend`フィールドもオプションです。このフィールドを`true`に設定すると、すべての後続の実行がサスペンド(一時停止)されます。この設定はすでに実行開始したJobには適用されません。デフォルトはfalseです。 + +{{< caution >}} +スケジュールされた時間中にサスペンドされた実行は、見逃されたJob(missed job)としてカウントされます。[starting deadline](#starting-deadline)が設定されていない既存のCronJob`.spec.suspend`が`true`から`false`に変更されると、見逃されたJobは即座にスケジュールされます。 +{{< /caution >}} + +### Job History Limit + +`.spec.successfulJobsHistoryLimit`と`.spec.failedJobsHistoryLimit`フィールドはオプションです。これらのフィールドには、完了したJobと失敗したJobをいくつ保持するかを指定します。デフォルトでは、それぞれ3と1に設定されます。リミットを`0`に設定すると、対応する種類のJobを実行完了後に何も保持しなくなります。 diff --git a/content/ja/docs/tasks/job/indexed-parallel-processing-static.md b/content/ja/docs/tasks/job/indexed-parallel-processing-static.md new file mode 100644 index 0000000000..b3d8b5d6e4 --- /dev/null +++ b/content/ja/docs/tasks/job/indexed-parallel-processing-static.md @@ -0,0 +1,147 @@ +--- +title: 静的な処理の割り当てを使用した並列処理のためのインデックス付きJob +content_type: task +min-kubernetes-server-version: v1.21 +weight: 30 +--- + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + + + +この例では、複数の並列ワーカープロセスを使用するKubernetesのJobを実行します。各ワーカーは、それぞれが自分のPod内で実行される異なるコンテナです。Podはコントロールプレーンが自動的に設定する*インデックス値*を持ち、この値を利用することで、各Podは処理するタスク全体のどの部分を処理するのかを特定できます。 + +Podのインデックスは、{{< glossary_tooltip text="アノテーション" term_id="annotation" >}}内の`batch.kubernetes.io/job-completion-index`を整数値の文字列表現として利用できます。コンテナ化されたタスクプロセスがこのインデックスを取得できるようにするために、このアノテーションの値は[downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)の仕組みを利用することで公開できます。利便性のために、コントロールプレーンは自動的にdownward APIを設定して、`JOB_COMPLETION_INDEX`環境変数にインデックスを公開します。 + +以下に、この例で実行するステップの概要を示します。 + +1. **completionのインデックスを使用してJobのマニフェストを定義する**。downward APIはPodのインデックスのアノテーションを環境変数またはファイルとしてコンテナに渡してくれます。 +2. **そのマニフェストに基づいてインデックス付き(Indexed)のJobを開始する**。 + +## {{% heading "prerequisites" %}} + +あらかじめ基本的な非並列の[Job](/docs/concepts/workloads/controllers/job/)の使用に慣れている必要があります。 + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +インデックス付きJobを作成できるようにするには、[APIサーバー](/docs/reference/command-line-tools-reference/kube-apiserver/)と[コントローラーマネージャー](/docs/reference/command-line-tools-reference/kube-controller-manager/)上で`IndexedJob`[フィーチャーゲート](/ja/docs/reference/command-line-tools-reference/feature-gates/)を有効にしていることを確認してください。 + + + +## アプローチを選択する + +ワーカープログラムから処理アイテムにアクセスするには、いくつかの選択肢があります。 + +1. `JOB_COMPLETION_INDEX`環境変数を読み込む。Job{{< glossary_tooltip text="コントローラー" term_id="controller" >}}は、この変数をcompletion indexを含むアノテーションに自動的にリンクします。 +1. completion indexを含むファイルを読み込む。 +1. プログラムを修正できない場合、プログラムをスクリプトでラップし、上のいずれかの方法でインデックスを読み取り、プログラムが入力として使用できるものに変換する。 + +この例では、3番目のオプションを選択肢して、[rev](https://man7.org/linux/man-pages/man1/rev.1.html)ユーティリティを実行したいと考えているとしましょう。このプログラムはファイルを引数として受け取り、内容を逆さまに表示します。 + +```shell +rev data.txt +``` + +`rev`ツールは[`busybox`](https://hub.docker.com/_/busybox)コンテナイメージから利用できます。 + +これは単なる例であるため、各Podはごく簡単な処理(短い文字列を逆にする)をするだけです。現実のワークロードでは、たとえば、シーンデータをもとに60秒の動画を生成するというようなタスクを記述したJobを作成するかもしれません。ビデオレンダリングJobの各処理アイテムは、ビデオクリップの特定のフレームのレンダリングを行うものになるでしょう。その場合、インデックス付きの完了が意味するのは、クリップの最初からフレームをカウントすることで、Job内の各Podがレンダリングと公開をするのがどのフレームであるかがわかるということです。 + +## インデックス付きJobを定義する + +以下は、completion modeとして`Indexed`を使用するJobのマニフェストの例です。 + +{{< codenew language="yaml" file="application/job/indexed-job.yaml" >}} + +上記の例では、Jobコントローラーがすべてのコンテナに設定する組み込みの`JOB_COMPLETION_INDEX`環境変数を使っています。[initコンテナ](/ja/docs/concepts/workloads/pods/init-containers/)がインデックスを静的な値にマッピングし、その値をファイルに書き込み、ファイルを[emptyDir volume](/docs/concepts/storage/volumes/#emptydir)を介してワーカーを実行しているコンテナと共有します。オプションとして、インデックスとコンテナに公開するために[downward APIを使用して独自の環境変数を定義する](/ja/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)こともできます。[環境変数やファイルとして設定したConfigMap](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)から値のリストを読み込むという選択肢もあります。 + +他には、以下の例のように、直接[downward APIを使用してアノテーションの値をボリュームファイルとして渡す](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#store-pod-fields)こともできます。 + +{{< codenew language="yaml" file="application/job/indexed-job-vol.yaml" >}} + +## Jobを実行する + +次のコマンドでJobを実行します。 + +```shell +# このコマンドでは1番目のアプローチを使っています ($JOB_COMPLETION_INDEX に依存しています) +kubectl apply -f https://kubernetes.io/examples/application/job/indexed-job.yaml +``` + +このJobを作成したら、コントロールプレーンは指定した各インデックスごとに一連のPodを作成します。`.spec.parallelism`の値が同時に実行できるPodの数を決定し、`.spec.completions`の値がJobが作成するPodの合計数を決定します。 + +`.spec.parallelism`は`.spec.completions`より小さいため、コントロールプレーンは別のPodを開始する前に最初のPodの一部が完了するまで待機します。 + +Jobを作成したら、少し待ってから進行状況を確認します。 + +```shell +kubectl describe jobs/indexed-job +``` + +出力は次のようになります。 + +``` +Name: indexed-job +Namespace: default +Selector: controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756 +Labels: controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756 + job-name=indexed-job +Annotations: +Parallelism: 3 +Completions: 5 +Start Time: Thu, 11 Mar 2021 15:47:34 +0000 +Pods Statuses: 2 Running / 3 Succeeded / 0 Failed +Completed Indexes: 0-2 +Pod Template: + Labels: controller-uid=bf865e04-0b67-483b-9a90-74cfc4c3e756 + job-name=indexed-job + Init Containers: + input: + Image: docker.io/library/bash + Port: + Host Port: + Command: + bash + -c + items=(foo bar baz qux xyz) + echo ${items[$JOB_COMPLETION_INDEX]} > /input/data.txt + + Environment: + Mounts: + /input from input (rw) + Containers: + worker: + Image: docker.io/library/busybox + Port: + Host Port: + Command: + rev + /input/data.txt + Environment: + Mounts: + /input from input (rw) + Volumes: + input: + Type: EmptyDir (a temporary directory that shares a pod's lifetime) + Medium: + SizeLimit: +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 4s job-controller Created pod: indexed-job-njkjj + Normal SuccessfulCreate 4s job-controller Created pod: indexed-job-9kd4h + Normal SuccessfulCreate 4s job-controller Created pod: indexed-job-qjwsz + Normal SuccessfulCreate 1s job-controller Created pod: indexed-job-fdhq5 + Normal SuccessfulCreate 1s job-controller Created pod: indexed-job-ncslj +``` + +この例では、各インデックスごとにカスタムの値を使用してJobを実行します。次のコマンドでPodの1つの出力を確認できます。 + +```shell +kubectl logs indexed-job-fdhq5 # これを対象のJobのPodの名前に一致するように変更してください。 +``` + +出力は次のようになります。 + +``` +xuq +``` diff --git a/content/ja/docs/tasks/manage-kubernetes-objects/_index.md b/content/ja/docs/tasks/manage-kubernetes-objects/_index.md new file mode 100644 index 0000000000..16150cf3d7 --- /dev/null +++ b/content/ja/docs/tasks/manage-kubernetes-objects/_index.md @@ -0,0 +1,5 @@ +--- +title: "Kubernetesオブジェクトの管理" +description: Kubernetes APIと対話するための宣言型および命令型のパラダイム。 +weight: 25 +--- diff --git a/content/ja/docs/tasks/network/_index.md b/content/ja/docs/tasks/network/_index.md new file mode 100644 index 0000000000..1d5796f7b7 --- /dev/null +++ b/content/ja/docs/tasks/network/_index.md @@ -0,0 +1,6 @@ +--- +title: "ネットワーク" +description: クラスターのネットワークの設定方法を学びます。 +weight: 160 +--- + diff --git a/content/ja/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/ja/docs/tasks/network/customize-hosts-file-for-pods.md similarity index 99% rename from content/ja/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md rename to content/ja/docs/tasks/network/customize-hosts-file-for-pods.md index 5c89abf5e7..f644fc575a 100644 --- a/content/ja/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/ja/docs/tasks/network/customize-hosts-file-for-pods.md @@ -1,6 +1,6 @@ --- title: HostAliasesを使用してPodの/etc/hostsにエントリーを追加する -content_type: concept +content_type: task weight: 60 min-kubernetes-server-version: 1.7 --- @@ -13,7 +13,7 @@ Podの`/etc/hosts`ファイルにエントリーを追加すると、DNSやそ HostAliasesを使用せずにファイルを修正することはおすすめできません。このファイルはkubeletが管理しており、Podの作成や再起動時に上書きされる可能性があるためです。 - + ## デフォルトのhostsファイルの内容 diff --git a/content/ja/docs/tasks/network/validate-dual-stack.md b/content/ja/docs/tasks/network/validate-dual-stack.md new file mode 100644 index 0000000000..9ab51d8701 --- /dev/null +++ b/content/ja/docs/tasks/network/validate-dual-stack.md @@ -0,0 +1,232 @@ +--- +min-kubernetes-server-version: v1.20 +title: IPv4/IPv6デュアルスタックの検証 +content_type: task +--- + + +このドキュメントでは、IPv4/IPv6デュアルスタックが有効化されたKubernetesクラスターを検証する方法について共有します。 + + +## {{% heading "prerequisites" %}} + + +* プロバイダーがデュアルスタックのネットワークをサポートしていること (クラウドプロバイダーか、ルーティングできるIPv4/IPv6ネットワークインターフェイスを持つKubernetesノードが提供できること) +* (KubenetやCalicoなど)デュアルスタックをサポートする[ネットワークプラグイン](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +* [デュアルスタックを有効化](/ja/docs/concepts/services-networking/dual-stack/)したクラスター + +{{< version-check >}} + + + + + +## アドレスの検証 + +### ノードアドレスの検証 + +各デュアルスタックのノードは、1つのIPv4ブロックと1つのIPv6ブロックを割り当てる必要があります。IPv4/IPv6のPodアドレスの範囲が設定されていることを検証するには、次のコマンドを実行します。例の中のノード名は、自分のクラスターの有効なデュアルスタックのノードの名前に置換してください。この例では、ノードの名前は`k8s-linuxpool1-34450317-0`になっています。 + +```shell +kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .spec.podCIDRs}}{{printf "%s\n" .}}{{end}}' +``` +``` +10.244.1.0/24 +a00:100::/24 +``` + +IPv4ブロックとIPv6ブロックがそれぞれ1つずつ割り当てられているはずです。 + +ノードが検出されたIPv4とIPv6のインターフェイスを持っていることを検証します。ノード名は自分のクラスター内の有効なノード名に置換してください。この例では、ノード名は`k8s-linuxpool1-34450317-0`になっています。 + +```shell +kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .status.addresses}}{{printf "%s: %s\n" .type .address}}{{end}}' +``` +``` +Hostname: k8s-linuxpool1-34450317-0 +InternalIP: 10.240.0.5 +InternalIP: 2001:1234:5678:9abc::5 +``` + +### Podアドレスの検証 + +PodにIPv4とIPv6のアドレスが割り当てられていることを検証します。Podの名前は自分のクラスター内の有効なPodの名前と置換してください。この例では、Podの名前は`pod01`になっています。 + +```shell +kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{printf "%s\n" .ip}}{{end}}' +``` +``` +10.244.1.4 +a00:100::4 +``` + +Downward APIを使用して、`status.podIPs`のfieldPath経由でPod IPを検証することもできます。次のスニペットは、Pod IPを`MY_POD_IPS`という名前の環境変数経由でコンテナ内に公開する方法を示しています。 + +``` + env: + - name: MY_POD_IPS + valueFrom: + fieldRef: + fieldPath: status.podIPs +``` + +次のコマンドを実行すると、`MY_POD_IPS`環境変数の値をコンテナ内から表示できます。値はカンマ区切りのリストであり、PodのIPv4とIPv6のアドレスに対応しています。 + +```shell +kubectl exec -it pod01 -- set | grep MY_POD_IPS +``` +``` +MY_POD_IPS=10.244.1.4,a00:100::4 +``` + +PodのIPアドレスは、コンテナ内の`/etc/hosts`にも書き込まれます。次のコマンドは、デュアルスタックのPod上で`/etc/hosts`に対してcatコマンドを実行します。出力を見ると、Pod用のIPv4およびIPv6のIPアドレスの両方が確認できます。 + +```shell +kubectl exec -it pod01 -- cat /etc/hosts +``` +``` +# Kubernetes-managed hosts file. +127.0.0.1 localhost +::1 localhost ip6-localhost ip6-loopback +fe00::0 ip6-localnet +fe00::0 ip6-mcastprefix +fe00::1 ip6-allnodes +fe00::2 ip6-allrouters +10.244.1.4 pod01 +a00:100::4 pod01 +``` + +## Serviceの検証 + +`.spec.isFamilyPolicy`を明示的に定義していない、以下のようなServiceを作成してみます。Kubernetesは最初に設定した`service-cluster-ip-range`の範囲からServiceにcluster IPを割り当てて、`.spec.ipFamilyPolicy`を`SingleStack`に設定します。 + +{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} + +`kubectl`を使ってServiceのYAMLを表示します。 + +```shell +kubectl get svc my-service -o yaml +``` + +Serviceの`.spec.ipFamilyPolicy`は`SingleStack`に設定され、`.spec.clusterIP`にはkube-controller-manager上の`--service-cluster-ip-range`フラグで最初に設定した範囲から1つのIPv4アドレスが設定されているのがわかります。 + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service + namespace: default +spec: + clusterIP: 10.0.217.164 + clusterIPs: + - 10.0.217.164 + ipFamilies: + - IPv4 + ipFamilyPolicy: SingleStack + ports: + - port: 80 + protocol: TCP + targetPort: 9376 + selector: + app: MyApp + sessionAffinity: None + type: ClusterIP +status: + loadBalancer: {} +``` + +`.spec.ipFamilies`内の配列の1番目の要素に`IPv6`を明示的に指定した、次のようなServiceを作成してみます。Kubernetesは`service-cluster-ip-range`で設定したIPv6の範囲からcluster IPを割り当てて、`.spec.ipFamilyPolicy`を`SingleStack`に設定します。 + +{{< codenew file="service/networking/dual-stack-ipfamilies-ipv6.yaml" >}} + +`kubectl`を使ってServiceのYAMLを表示します。 + +```shell +kubectl get svc my-service -o yaml +``` + +Serviceの`.spec.ipFamilyPolicy`は`SingleStack`に設定され、`.spec.clusterIP`には、kube-controller-manager上の`--service-cluster-ip-range`フラグで指定された最初の設定範囲から1つのIPv6アドレスが設定されているのがわかります。 + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + app: MyApp + name: my-service +spec: + clusterIP: fd00::5118 + clusterIPs: + - fd00::5118 + ipFamilies: + - IPv6 + ipFamilyPolicy: SingleStack + ports: + - port: 80 + protocol: TCP + targetPort: 80 + selector: + app: MyApp + sessionAffinity: None + type: ClusterIP +status: + loadBalancer: {} +``` + +`.spec.ipFamiliePolicy`に`PreferDualStack`を明示的に指定した、次のようなServiceを作成してみます。Kubernetesは(クラスターでデュアルスタックを有効化しているため)IPv4およびIPv6のアドレスの両方を割り当て、`.spec.ClusterIPs`のリストから、`.spec.ipFamilies`配列の最初の要素のアドレスファミリーに基づいた`.spec.ClusterIP`を設定します。 + +{{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}} + +{{< note >}} +`kubectl get svc`コマンドは、`CLUSTER-IP`フィールドにプライマリーのIPだけしか表示しません。 + +```shell +kubectl get svc -l app=MyApp + +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-service ClusterIP 10.0.216.242 80/TCP 5s +``` +{{< /note >}} + +`kubectl describe`を使用して、ServiceがIPv4およびIPv6アドレスのブロックからcluster IPを割り当てられていることを検証します。その後、ServiceにIPアドレスとポートを使用してアクセスできることを検証することもできます。 + +```shell +kubectl describe svc -l app=MyApp +``` + +``` +Name: my-service +Namespace: default +Labels: app=MyApp +Annotations: +Selector: app=MyApp +Type: ClusterIP +IP Family Policy: PreferDualStack +IP Families: IPv4,IPv6 +IP: 10.0.216.242 +IPs: 10.0.216.242,fd00::af55 +Port: 80/TCP +TargetPort: 9376/TCP +Endpoints: +Session Affinity: None +Events: +``` + +### デュアルスタックのLoadBalancer Serviceを作成する + +クラウドプロバイダーがIPv6を有効化した外部ロードバランサーのプロビジョニングをサポートする場合、`.spec.ipFamilyPolicy`に`PreferDualStack`を指定し、`.spec.ipFamilies`の最初の要素を`IPv6`にして、`type`フィールドに`LoadBalancer`を指定したServiceを作成できます。 + +{{< codenew file="service/networking/dual-stack-prefer-ipv6-lb-svc.yaml" >}} + +Serviceを確認します。 + +```shell +kubectl get svc -l app=MyApp +``` + +ServiceがIPv6アドレスブロックから`CLUSTER-IP`のアドレスと`EXTERNAL-IP`を割り当てられていることを検証します。その後、IPとポートを用いたServiceへのアクセスを検証することもできます。 + +```shell +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +my-service LoadBalancer fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s +``` diff --git a/content/ja/docs/tasks/run-application/_index.md b/content/ja/docs/tasks/run-application/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/tasks/run-application/delete-stateful-set.md b/content/ja/docs/tasks/run-application/delete-stateful-set.md index 659dabec17..81142068ed 100644 --- a/content/ja/docs/tasks/run-application/delete-stateful-set.md +++ b/content/ja/docs/tasks/run-application/delete-stateful-set.md @@ -37,13 +37,13 @@ StatefulSet自体が削除された後で、関連するヘッドレスサービ kubectl delete service ``` -kubectlを使ってStatefulSetを削除すると0にスケールダウンされ、すべてのPodが削除されます。PodではなくStatefulSetだけを削除したい場合は、`--cascade=false`を使用してください。 +kubectlを使ってStatefulSetを削除すると0にスケールダウンされ、すべてのPodが削除されます。PodではなくStatefulSetだけを削除したい場合は、`--cascade=orphan`を使用してください。 ```shell -kubectl delete -f --cascade=false +kubectl delete -f --cascade=orphan ``` -`--cascade=false`を`kubectl delete`に渡すことで、StatefulSetオブジェクト自身が削除された後でも、StatefulSetによって管理されていたPodは残ります。Podに`app=myapp`というラベルが付いている場合は、次のようにして削除できます: +`--cascade=orphan`を`kubectl delete`に渡すことで、StatefulSetオブジェクト自身が削除された後でも、StatefulSetによって管理されていたPodは残ります。Podに`app=myapp`というラベルが付いている場合は、次のようにして削除できます: ```shell kubectl delete pods -l app=myapp diff --git a/content/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 445742e1d6..a395a412ba 100644 --- a/content/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -10,7 +10,7 @@ Horizontal Pod Autoscalerは、Deployment、ReplicaSetまたはStatefulSetとい このドキュメントはphp-apacheサーバーに対しHorizontal Pod Autoscalerを有効化するという例に沿ってウォークスルーで説明していきます。Horizontal Pod Autoscalerの動作についてのより詳細な情報を知りたい場合は、[Horizontal Pod Autoscalerユーザーガイド](/docs/tasks/run-application/horizontal-pod-autoscale/)をご覧ください。 -## {{% heading "前提条件" %}} +## {{% heading "prerequisites" %}} この例ではバージョン1.2以上の動作するKubernetesクラスターおよびkubectlが必要です。 [Metrics API](https://github.com/kubernetes/metrics)を介してメトリクスを提供するために、[Metrics server](https://github.com/kubernetes-sigs/metrics-server)によるモニタリングがクラスター内にデプロイされている必要があります。 diff --git a/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md b/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md index 963df78524..da7c286f89 100644 --- a/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md +++ b/content/ja/docs/tasks/run-application/run-stateless-application-deployment.md @@ -49,7 +49,6 @@ Kubernetes Deploymentオブジェクトを作成することでアプリケー 出力はこのようになります: - user@computer:~/website$ kubectl describe deployment nginx-deployment Name: nginx-deployment Namespace: default CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700 diff --git a/content/ja/docs/tasks/service-catalog/_index.md b/content/ja/docs/tasks/service-catalog/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md index eced279efc..ff894fba29 100644 --- a/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md +++ b/content/ja/docs/tasks/service-catalog/install-service-catalog-using-helm.md @@ -33,7 +33,7 @@ Helmをインストールし、以下のコマンドを実行することでロ ```shell -helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com +helm repo add svc-cat https://kubernetes-sigs.github.io/service-catalog ``` 以下のコマンドを実行し、インストールに成功していることを確認します。 diff --git a/content/ja/docs/tasks/tls/_index.md b/content/ja/docs/tasks/tls/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/tasks/tools/_index.md b/content/ja/docs/tasks/tools/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/tutorials/clusters/_index.md b/content/ja/docs/tutorials/clusters/_index.md new file mode 100644 index 0000000000..0f3a08fdda --- /dev/null +++ b/content/ja/docs/tutorials/clusters/_index.md @@ -0,0 +1,4 @@ +--- +title: "クラスター" +weight: 60 +--- diff --git a/content/ja/docs/tutorials/clusters/apparmor.md b/content/ja/docs/tutorials/clusters/apparmor.md new file mode 100644 index 0000000000..5ee0201d71 --- /dev/null +++ b/content/ja/docs/tutorials/clusters/apparmor.md @@ -0,0 +1,375 @@ +--- +title: AppArmorを使用してコンテナのリソースへのアクセスを制限する +content_type: tutorial +weight: 10 +--- + + + +{{< feature-state for_k8s_version="v1.4" state="beta" >}} + +AppArmorは、Linux標準のユーザー・グループをベースとしたパーミッションを補完するLinuxカーネルのセキュリティモジュールであり、プログラムのアクセスを限定されたリソースセットに制限するために利用されます。AppArmorを設定することで、任意のアプリケーションの攻撃サーフェイスとなりうる面を減らしたり、より優れた多重の防御を提供できます。AppArmorは、たとえばLinuxのcapability、ネットワークアクセス、ファイルのパーミッションなど、特定のプログラムやコンテナに必要なアクセスを許可するようにチューニングされたプロファイルにより設定を行います。各プロファイルは、許可されなかったリソースへのアクセスをブロックする*enforcing*モードと、ルール違反を報告するだけの*complain*モードのいずれかで実行できます。 + +AppArmorを利用すれば、コンテナに許可することを制限したりシステムログを通してよりよい監査を提供することで、デプロイをよりセキュアにする助けになります。しかし、AppArmorは銀の弾丸ではなく、アプリケーションコードの悪用からの防御を強化できるだけであることを心に留めておくことが重要です。制限の強い優れたプロファイルを提供し、アプリケーションとクラスターを別の角度から強化することが重要です。 + +## {{% heading "objectives" %}} + +* プロファイルをノードに読み込む方法の例を見る +* Pod上でプロファイルを矯正する方法を学ぶ +* プロファイルが読み込まれたかを確認する方法を学ぶ +* プロファイルに違反した場合に何が起こるのかを見る +* プロファイルが読み込めなかった場合に何が起こるのかを見る + +## {{% heading "prerequisites" %}} + +以下のことを確認してください。 + +1. Kubernetesのバージョンがv1.4以上であること。KubernetesのAppArmorのサポートはv1.4で追加されました。v1.4より古いバージョンのKubernetesのコンポーネントは、新しいAppArmorのアノテーションを認識できないため、AppArmorの設定を与えたとしても**黙って無視されてしまいます**。Podが期待した保護を確実に受けられるようにするためには、次のようにノードのKubeletのバージョンを確認することが重要です。 + + ```shell + kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {@.status.nodeInfo.kubeletVersion}\n{end}' + ``` + ``` + gke-test-default-pool-239f5d02-gyn2: v1.4.0 + gke-test-default-pool-239f5d02-x1kf: v1.4.0 + gke-test-default-pool-239f5d02-xwux: v1.4.0 + ``` + +2. AppArmorカーネルモジュールが有効であること。LinuxカーネルがAppArmorプロファイルを強制するためには、AppArmorカーネルモジュールのインストールと有効化が必須です。UbuntuやSUSEなどのディストリビューションではデフォルトで有効化されますが、他の多くのディストリビューションでのサポートはオプションです。モジュールが有効になっているかチェックするには、次のように`/sys/module/apparmor/parameters/enabled`ファイルを確認します。 + + ```shell + cat /sys/module/apparmor/parameters/enabled + Y + ``` + + KubeletがAppArmorをサポートしていれば(>= v1.4)、カーネルモジュールが有効になっていない場合にはAppArmorオプションが付いたPodを拒否します。 + + {{< note >}} + UbuntuはAppArmorに対して、アップストリームのLinuxにマージしていない多数のパッチを当てています。その中には、追加のフックや機能を加えるパッチも含まれます。Kubernetesはアップストリームのバージョンでのみテストされており、その他の機能に対するサポートを約束していません。 + {{< /note >}} + +3. コンテナランタイムがAppArmorをサポートしていること。現在、Kubernetesがサポートするすべての一般的なコンテナランタイム、{{< glossary_tooltip term_id="docker">}}、{{< glossary_tooltip term_id="cri-o" >}}、{{< glossary_tooltip term_id="containerd" >}}などは、AppArmorをサポートしています。関連するランタイムのドキュメントを参照して、クラスターがAppArmorを利用するための要求を満たしているかどうかを検証してください。 + +4. プロファイルが読み込まれていること。AppArmorがPodに適用されるのは、各コンテナが実行されるべきAppArmorプロファイルを指定したときです。もし指定されたプロファイルがまだカーネルに読み込まれていなければ、Kubelet(>= v1.4)はPodを拒否します。どのプロファイルがノードに読み込まれているのかを確かめるには、次のようなコマンドを実行して`/sys/kernel/security/apparmor/profiles`をチェックします。 + + ```shell + ssh gke-test-default-pool-239f5d02-gyn2 "sudo cat /sys/kernel/security/apparmor/profiles | sort" + ``` + ``` + apparmor-test-deny-write (enforce) + apparmor-test-audit-write (enforce) + docker-default (enforce) + k8s-nginx (enforce) + ``` + + ノード上でのプロファイルの読み込みの詳細については、[プロファイルを使用したノードのセットアップ](#setting-up-nodes-with-profiles)を参照してください。 + +KubeletのバージョンがAppArmorサポートに対応しているもの(>= v1.4)である限り、Kubeletは必要条件を1つでも満たさないAppArmorオプションが付けられたPodをリジェクトします。また、ノード上のAppArmorのサポートは、次のようにready conditionのメッセージで確認することもできます(ただし、この機能は将来のリリースで削除される可能性があります)。 + +```shell +kubectl get nodes -o=jsonpath=$'{range .items[*]}{@.metadata.name}: {.status.conditions[?(@.reason=="KubeletReady")].message}\n{end}' +``` +``` +gke-test-default-pool-239f5d02-gyn2: kubelet is posting ready status. AppArmor enabled +gke-test-default-pool-239f5d02-x1kf: kubelet is posting ready status. AppArmor enabled +gke-test-default-pool-239f5d02-xwux: kubelet is posting ready status. AppArmor enabled +``` + + + +## Podをセキュアにする + +{{< note >}} +AppArmorは現在beta版であるため、オプションはアノテーションとして指定します。将来サポートが一般利用可能(GA)になれば、アノテーションは第1級のフィールドで置き換えられます(詳細については、[一般利用可能(General Availability)への更新パス](#upgrade-path-to-general-availability)を参照してください)。 +{{< /note >}} + +AppArmorのプロファイルは*各コンテナごとに*指定します。Podのコンテナで実行するAppArmorのプロファイルを指定するには、Podのメタデータに次のようなアノテーションを追加します。 + +```yaml +container.apparmor.security.beta.kubernetes.io/: +``` + +ここで、``はプロファイルを適用するコンテナの名前であり、``には適用するプロファイルを指定します。`profile_ref`は次の値のうち1つを指定します。 + +* `runtime/default`: ランタイムのデフォルトのプロファイルを適用する +* `localhost/`: ``という名前でホストにロードされたプロファイルを適用する +* `unconfined`: いかなるプロファイルもロードされないことを示す + +アノテーションとプロファイルの名前のフォーマットの詳細については、[APIリファレンス](#api-reference)を参照してください。 + +KubernetesのAppArmorの強制では、まずはじめにすべての前提条件が満たされているかどうかをチェックします。その後、強制を行うためにプロファイルの選択をコンテナランタイムに委ねます。前提条件が満たされなかった場合、Podはリジェクトされ、実行されません。 + +プロファイルが適用されたかどうか確認するには、AppArmor securityオプションがコンテナ作成イベントに一覧されているかどうかを確認します。 + +```shell +kubectl get events | grep Created +``` +``` +22s 22s 1 hello-apparmor Pod spec.containers{hello} Normal Created {kubelet e2e-test-stclair-node-pool-31nt} Created container with docker id 269a53b202d3; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write] +``` + +proc attrを調べることで、コンテナのルートプロセスが正しいプロファイルで実行されているかどうかを直接確認することもできます。 + +```shell +kubectl exec cat /proc/1/attr/current +``` +``` +k8s-apparmor-example-deny-write (enforce) +``` + +## 例 {#example} + +*この例は、クラスターがすでにAppArmorのサポート付きでセットアップ済みであることを前提としています。* + +まず、使用したいプロファイルをノード上に読み込む必要があります。このプロファイルは、すべてのファイル書き込みを拒否します。 + +```shell +#include + +profile k8s-apparmor-example-deny-write flags=(attach_disconnected) { + #include + + file, + + # Deny all file writes. + deny /** w, +} +``` + +Podがどのノードにスケジュールされるかは予測できないため、プロファイルはすべてのノードに読み込ませる必要があります。この例では、単純にSSHを使ってプロファイルをインストールしますが、[プロファイルを使用したノードのセットアップ](#setting-up-nodes-with-profiles)では、他のアプローチについて議論しています。 + +```shell +NODES=( + # SSHでアクセス可能なノードのドメイン名 + gke-test-default-pool-239f5d02-gyn2.us-central1-a.my-k8s + gke-test-default-pool-239f5d02-x1kf.us-central1-a.my-k8s + gke-test-default-pool-239f5d02-xwux.us-central1-a.my-k8s) +for NODE in ${NODES[*]}; do ssh $NODE 'sudo apparmor_parser -q < + +profile k8s-apparmor-example-deny-write flags=(attach_disconnected) { + #include + + file, + + # Deny all file writes. + deny /** w, +} +EOF' +done +``` + +次に、deny-writeプロファイルを使用した単純な "Hello AppArmor" Podを実行します。 + +{{< codenew file="pods/security/hello-apparmor.yaml" >}} + +```shell +kubectl create -f ./hello-apparmor.yaml +``` + +Podイベントを確認すると、PodコンテナがAppArmorプロファイル "k8s-apparmor-example-deny-write" を使用して作成されたことがわかります。 + +```shell +kubectl get events | grep hello-apparmor +``` +``` +14s 14s 1 hello-apparmor Pod Normal Scheduled {default-scheduler } Successfully assigned hello-apparmor to gke-test-default-pool-239f5d02-gyn2 +14s 14s 1 hello-apparmor Pod spec.containers{hello} Normal Pulling {kubelet gke-test-default-pool-239f5d02-gyn2} pulling image "busybox" +13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Pulled {kubelet gke-test-default-pool-239f5d02-gyn2} Successfully pulled image "busybox" +13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Created {kubelet gke-test-default-pool-239f5d02-gyn2} Created container with docker id 06b6cd1c0989; Security:[seccomp=unconfined apparmor=k8s-apparmor-example-deny-write] +13s 13s 1 hello-apparmor Pod spec.containers{hello} Normal Started {kubelet gke-test-default-pool-239f5d02-gyn2} Started container with docker id 06b6cd1c0989 +``` + +コンテナがこのプロファイルで実際に実行されていることを確認するために、コンテナのproc attrをチェックします。 + +```shell +kubectl exec hello-apparmor cat /proc/1/attr/current +``` +``` +k8s-apparmor-example-deny-write (enforce) +``` + +最後に、ファイルへの書き込みを行おうとすることで、プロファイルに違反すると何が起こるか見てみましょう。 + +```shell +kubectl exec hello-apparmor touch /tmp/test +``` +``` +touch: /tmp/test: Permission denied +error: error executing remote command: command terminated with non-zero exit code: Error executing in Docker Container: 1 +``` + +まとめとして、読み込まれていないプロファイルを指定しようとするとどうなるのか見てみましょう。 + +```shell +kubectl create -f /dev/stdin < +Annotations: container.apparmor.security.beta.kubernetes.io/hello=localhost/k8s-apparmor-example-allow-write +Status: Pending +Reason: AppArmor +Message: Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded +IP: +Controllers: +Containers: + hello: + Container ID: + Image: busybox + Image ID: + Port: + Command: + sh + -c + echo 'Hello AppArmor!' && sleep 1h + State: Waiting + Reason: Blocked + Ready: False + Restart Count: 0 + Environment: + Mounts: + /var/run/secrets/kubernetes.io/serviceaccount from default-token-dnz7v (ro) +Conditions: + Type Status + Initialized True + Ready False + PodScheduled True +Volumes: + default-token-dnz7v: + Type: Secret (a volume populated by a Secret) + SecretName: default-token-dnz7v + Optional: false +QoS Class: BestEffort +Node-Selectors: +Tolerations: +Events: + FirstSeen LastSeen Count From SubobjectPath Type Reason Message + --------- -------- ----- ---- ------------- -------- ------ ------- + 23s 23s 1 {default-scheduler } Normal Scheduled Successfully assigned hello-apparmor-2 to e2e-test-stclair-node-pool-t1f5 + 23s 23s 1 {kubelet e2e-test-stclair-node-pool-t1f5} Warning AppArmor Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded +``` + +PodのステータスはPendingとなり、`Pod Cannot enforce AppArmor: profile +"k8s-apparmor-example-allow-write" is not loaded`(PodはAppArmorを強制できません: プロファイル "k8s-apparmor-example-allow-write" はロードされていません)という役に立つエラーメッセージが表示されています。同じメッセージのイベントも記録されています。 + +## 管理 + +### プロファイルを使用したノードのセットアップ {#setting-up-nodes-with-profiles} + +現在、KubernetesはAppArmorのプロファイルをノードに読み込むネイティブの仕組みは提供していません。しかし、プロファイルをセットアップする方法は、以下のように様々な方法があります。 + +* 各ノード上に正しいプロファイルがロードされていることを保証するPodを実行する[DaemonSet](/ja/docs/concepts/workloads/controllers/daemonset/)を利用する方法。[ここ](https://git.k8s.io/kubernetes/test/images/apparmor-loader)に実装例があります。 +* ノードの初期化時に初期化スクリプト(例: Salt、Ansibleなど)や初期化イメージを使用する。 +* [例](#example)で示したような方法で、プロファイルを各ノードにコピーし、SSHで読み込む。 + +スケジューラーはどのプロファイルがどのノードに読み込まれているのかがわからないため、すべてのプロファイルがすべてのノードに読み込まれていなければなりません。もう1つのアプローチとしては、各プロファイル(あるいはプロファイルのクラス)ごとにノードラベルを追加し、[node selector](/ja/docs/concepts/scheduling-eviction/assign-pod-node/)を用いてPodが必要なプロファイルを読み込んだノードで実行されるようにする方法もあります。 + +### PodSecurityPolicyを使用したプロファイルの制限 + +PodSecurityPolicy extensionが有効になっている場合、クラスタ全体でAppArmorn制限が適用されます。PodSecurityPolicyを有効にするには、`apiserver`上で次のフラグを設定する必要があります。 + +``` +--enable-admission-plugins=PodSecurityPolicy[,others...] +``` + +AppArmorのオプションはPodSecurityPolicy上でアノテーションとして指定します。 + +```yaml +apparmor.security.beta.kubernetes.io/defaultProfileName: +apparmor.security.beta.kubernetes.io/allowedProfileNames: [,others...] +``` + +defaultProfileNameオプションには、何も指定されなかった場合にコンテナにデフォルトで適用されるプロファイルを指定します。allowedProfileNamesオプションには、Podコンテナの実行が許可されるプロファイルのリストを指定します。両方のオプションが指定された場合、デフォルトは許可されなければいけません。プロファイルはコンテナ上で同じフォーマットで指定されます。完全な仕様については、[APIリファレンス](#api-reference)を参照してください。 + +### AppArmorの無効化 + +クラスタ上でAppArmorを利用可能にしたくない場合、次のコマンドラインフラグで無効化できます。 + +``` +--feature-gates=AppArmor=false +``` + +無効化すると、AppArmorプロファイルを含むPodは"Forbidden"エラーで検証に失敗します。ただし、デフォルトのdockerは非特権Pod上では"docker-default"というプロファイルを常に有効化し(AppArmorカーネルモジュールが有効である場合)、フィーチャーゲートで無効化したとしても有効化し続けることに注意してください。AppArmorを無効化するオプションは、AppArmorが一般利用(GA)になったときに削除される予定です。 + +### AppArmorを使用するKubernetes v1.4にアップグレードする + +クラスタをv1.4にアップグレードするために、AppArmorに関する操作は必要ありません。ただし、既存のPodがAppArmorのアノテーションを持っている場合、検証(またはPodSecurityPolicy admission)は行われません。もしpermissiveなプロファイルがノードに読み込まれていた場合、悪意のあるユーザーがPodの権限を上述のdocker-defaultより昇格させるために、permissiveなプロファイルを再適用する恐れがあります。これが問題となる場合、`apparmor.security.beta.kubernetes.io`のアノテーションを含むすべてのPodのクラスターをクリーンアップすることを推奨します。 + +### 一般利用可能(General Availability)への更新パス {#upgrade-path-to-general-availability} + +AppArmorが一般利用可能(GA)になったとき、現在アノテーションで指定しているオプションはフィールドに変換されます。移行中のすべてのアップグレードとダウングレードの経路をサポートするのは非常に微妙であるため、以降が必要になったときに詳細に説明する予定です。最低2リリースの間はフィールドとアノテーションの両方がサポートされるようにする予定です。最低2リリースの後は、アノテーションは明示的に拒否されるようになります。 + +## Profilesの作成 + +AppArmorのプロファイルを正しく指定するのはやっかいな作業です。幸い、その作業を補助するツールがいくつかあります。 + +* `aa-genprof`および`aa-logprof`は、アプリケーションの動作とログを監視することによりプロファイルのルールを生成します。詳しい説明については、[AppArmor documentation](https://gitlab.com/apparmor/apparmor/wikis/Profiling_with_tools)を参照してください。 +* [bane](https://github.com/jfrazelle/bane)は、Docker向けのAppArmorのプロファイル・ジェネレータです。簡略化されたプロファイル言語を使用しています。 + +プロファイルの生成には、アプリケーションを開発用ワークステーション上でDockerで実行することを推奨します。しかし、実際にPodが実行されるKubernetesノード上でツールを実行してはいけない理由はありません。 + +AppArmorに関する問題をデバッグするには、システムログをチェックして、特に何が拒否されたのかを確認できます。AppArmorのログは`dmesg`にverboseメッセージを送り、エラーは通常システムログまたは`journalctl`で確認できます。詳しい情報は、[AppArmor failures](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures)で提供されています。 + +## APIリファレンス {#api-reference} + +### Podアノテーション + +コンテナが実行するプロファイルを指定します。 + +- **key**: `container.apparmor.security.beta.kubernetes.io/` + ここで、``はPod内のコンテナの名前を一致させます。Pod内の各コンテナごとに別々のプロファイルを指定できます。 +- **value**: 下で説明するプロファイルのリファレンス + +### プロファイルのリファレンス + +- `runtime/default`: デフォルトのランタイムプロファイルを指します。 + - (PodSecurityPolicyのデフォルトを設定せずに)プロファイルを指定しない場合と同等ですが、AppArmorを有効化する必要があります。 + - Dockerの場合、非特権コンテナでは[`docker-default`](https://docs.docker.com/engine/security/apparmor/)プロファイルが選択され、特権コンテナではunconfined(プロファイルなし)が選択されます。 +- `localhost/`: 名前で指定されたノード(localhost)に読み込まれたプロファイルを指します。 + - 利用できるプロファイル名の詳細は[core policy reference](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications)で説明されています。 +- `unconfined`: これは実質的にコンテナ上のAppArmorを無効化します。 + +これ以外のプロファイルリファレンスはすべて無効です。 + +### PodSecurityPolicyアノテーション + +何も指定されなかった場合にコンテナに適用するデフォルトのプロファイルは、以下のように指定します。 + +* **key**: `apparmor.security.beta.kubernetes.io/defaultProfileName` +* **value**: 上で説明したプロファイルのリファレンス + +Podコンテナが指定することを許可するプロファイルのリストは、以下のように指定します。 + +* **key**: `apparmor.security.beta.kubernetes.io/allowedProfileNames` +* **value**: カンマ区切りの上述のプロファイルリファレンスのリスト + - プロファイル名ではエスケープしたカンマは不正な文字ではありませんが、ここでは明示的に許可されません。 + +## {{% heading "whatsnext" %}} + +追加のリソースとしては以下のものがあります。 + +* [Quick guide to the AppArmor profile language](https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage) +* [AppArmor core policy reference](https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout) diff --git a/content/ja/docs/tutorials/configuration/_index.md b/content/ja/docs/tutorials/configuration/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/tutorials/services/_index.md b/content/ja/docs/tutorials/services/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/tutorials/services/source-ip.md b/content/ja/docs/tutorials/services/source-ip.md index 505ba8ef45..6e52a1c9b3 100644 --- a/content/ja/docs/tutorials/services/source-ip.md +++ b/content/ja/docs/tutorials/services/source-ip.md @@ -392,7 +392,7 @@ client_address=198.51.100.79 2. クライアントからロードバランサーのVIPに送信されたリクエストが、中間のプロキシーではなく、クライアントの送信元IPとともにノードまで到達するようなパケット転送が使用される。 -1つめのカテゴリーのロードバランサーの場合、真のクライアントIPと通信するために、 HTTPの[Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)ヘッダーや[X-FORWARDED-FOR](https://ja.wikipedia.org/wiki/X-Forwarded-For)ヘッダー、[proxy protocol](https://www.haproxy.org/download/1.5/doc/proxy-protocol.txt)などの、ロードバランサーとバックエンドの間で合意されたプロトコルを使用する必要があります。2つ目のカテゴリーのロードバランサーの場合、Serviceの`service.spec.healthCheckNodePort`フィールドに保存されたポートを指すHTTPのヘルスチェックを作成することで、上記の機能を活用できます。 +1つめのカテゴリーのロードバランサーの場合、真のクライアントIPと通信するために、 HTTPの[Forwarded](https://tools.ietf.org/html/rfc7239#section-5.2)ヘッダーや[X-FORWARDED-FOR](https://ja.wikipedia.org/wiki/X-Forwarded-For)ヘッダー、[proxy protocol](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)などの、ロードバランサーとバックエンドの間で合意されたプロトコルを使用する必要があります。2つ目のカテゴリーのロードバランサーの場合、Serviceの`service.spec.healthCheckNodePort`フィールドに保存されたポートを指すHTTPのヘルスチェックを作成することで、上記の機能を活用できます。 ## {{% heading "cleanup" %}} diff --git a/content/ja/docs/tutorials/stateful-application/_index.md b/content/ja/docs/tutorials/stateful-application/_index.md old mode 100755 new mode 100644 diff --git a/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md index d8a0acbdf6..6b9d8da5a8 100644 --- a/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ja/docs/tutorials/stateful-application/basic-stateful-set.md @@ -45,13 +45,13 @@ StatefulSetはステートフルアプリケーションや分散システムで 上の例をダウンロードして、`web.yaml`という名前で保存します。 -ここでは、ターミナルウィンドウを2つ使う必要があります。1つ目のターミナルでは、[`kubectl get`](/ja/docs/reference/generated/kubectl/kubectl-commands/#get)を使って、StatefulSetのPodの作成を監視します。 +ここでは、ターミナルウィンドウを2つ使う必要があります。1つ目のターミナルでは、[`kubectl get`](/docs/reference/generated/kubectl/kubectl-commands/#get)を使って、StatefulSetのPodの作成を監視します。 ```shell kubectl get pods -w -l app=nginx ``` -2つ目のターミナルでは、[`kubectl apply`](/ja/docs/reference/generated/kubectl/kubectl-commands/#apply)を使って、`web.yaml`に定義されたheadless ServiceとStatefulSetを作成します。 +2つ目のターミナルでは、[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands/#apply)を使って、`web.yaml`に定義されたheadless ServiceとStatefulSetを作成します。 ```shell kubectl apply -f web.yaml @@ -120,7 +120,7 @@ web-1 1/1 Running 0 1m ### 安定したネットワーク識別子の使用 -各Podは、順序インデックスに基づいた安定したホスト名を持ちます。[`kubectl exec`](/ja/docs/reference/generated/kubectl/kubectl-commands/#exec)を使用して、各Pod内で`hostname`コマンドを実行してみましょう。 +各Podは、順序インデックスに基づいた安定したホスト名を持ちます。[`kubectl exec`](/docs/reference/generated/kubectl/kubectl-commands/#exec)を使用して、各Pod内で`hostname`コマンドを実行してみましょう。 ```shell for i in 0 1; do kubectl exec "web-$i" -- sh -c 'hostname'; done @@ -130,7 +130,7 @@ web-0 web-1 ``` -[`kubectl run`](/ja/docs/reference/generated/kubectl/kubectl-commands/#run)を使用して、`dnsutils`パッケージの`nslookup`コマンドを提供するコンテナを実行します。Podのホスト名に対して`nslookup`を実行すると、クラスター内のDNSアドレスが確認できます。 +[`kubectl run`](/docs/reference/generated/kubectl/kubectl-commands/#run)を使用して、`dnsutils`パッケージの`nslookup`コマンドを提供するコンテナを実行します。Podのホスト名に対して`nslookup`を実行すると、クラスター内のDNSアドレスが確認できます。 ```shell kubectl run -i --tty --image busybox:1.28 dns-test --restart=Never --rm @@ -165,7 +165,7 @@ headless serviceのCNAMEは、SRVレコードを指しています(1つのレコ ```shell kubectl get pod -w -l app=nginx ``` -2つ目のターミナルで、[`kubectl delete`](/ja/docs/reference/generated/kubectl/kubectl-commands/#delete)を使用して、StatefulSetのすべてのPodを削除します。 +2つ目のターミナルで、[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete)を使用して、StatefulSetのすべてのPodを削除します。 ```shell kubectl delete pod -l app=nginx @@ -316,8 +316,8 @@ web-1 ## StatefulSetをスケールする -StatefulSetのスケールとは、レプリカ数を増減することを意味します。これは、`replicas`フィールドを更新することによって実現できます。StatefulSetのスケールには、[`kubectl scale`](/ja/docs/reference/generated/kubectl/kubectl-commands/#scale)と -[`kubectl patch`](/ja/docs/reference/generated/kubectl/kubectl-commands/#patch)のどちらも使用できます。 +StatefulSetのスケールとは、レプリカ数を増減することを意味します。これは、`replicas`フィールドを更新することによって実現できます。StatefulSetのスケールには、[`kubectl scale`](/docs/reference/generated/kubectl/kubectl-commands/#scale)と +[`kubectl patch`](/docs/reference/generated/kubectl/kubectl-commands/#patch)のどちらも使用できます。 ### スケールアップ @@ -421,7 +421,7 @@ www-web-4 Bound pvc-e11bb5f8-b508-11e6-932f-42010a800002 1Gi RWO まだ、5つのPersistentVolumeClaimと5つのPersistentVolumeが残っています。[安定したストレージへの書き込み](#writing-to-stable-storage)を読むと、StatefulSetのPodが削除されても、StatefulSetのPodにマウントされたPersistentVolumeは削除されないと書かれています。このことは、StatefulSetのスケールダウンによってPodが削除された場合にも当てはまります。 -## StatefulSetsを更新する +## StatefulSetsを更新する {#updating-statefulsets} Kubernetes 1.7以降では、StatefulSetコントローラーは自動アップデートをサポートしています。使われる戦略は、StatefulSet APIオブジェクトの`spec.updateStrategy`フィールドによって決まります。この機能はコンテナイメージのアップグレード、リソースのrequestsやlimits、ラベル、StatefulSet内のPodのアノテーションの更新時に利用できます。有効なアップデートの戦略は、`RollingUpdate`と`OnDelete`の2種類です。 @@ -711,10 +711,10 @@ StatefulSetは、非カスケードな削除とカスケードな削除の両方 kubectl get pods -w -l app=nginx ``` -[`kubectl delete`](/ja/docs/reference/generated/kubectl/kubectl-commands/#delete)を使用して、StatefulSetを削除します。このとき、`--cascade=false`パラメーターをコマンドに与えてください。このパラメーターは、Kubernetesに対して、StatefulSetだけを削除して配下のPodは削除しないように指示します。 +[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete)を使用して、StatefulSetを削除します。このとき、`--cascade=orphan`パラメーターをコマンドに与えてください。このパラメーターは、Kubernetesに対して、StatefulSetだけを削除して配下のPodは削除しないように指示します。 ```shell -kubectl delete statefulset web --cascade=false +kubectl delete statefulset web --cascade=orphan ``` ``` statefulset.apps "web" deleted @@ -814,7 +814,7 @@ web-1 kubectl get pods -w -l app=nginx ``` -2つ目のターミナルで、StatefulSetをもう一度削除します。今回は、`--cascade=false`パラメーターを省略します。 +2つ目のターミナルで、StatefulSetをもう一度削除します。今回は、`--cascade=orphan`パラメーターを省略します。 ```shell kubectl delete statefulset web diff --git a/content/ja/docs/tutorials/stateful-application/cassandra.md b/content/ja/docs/tutorials/stateful-application/cassandra.md index c5f8ed3986..4283a378b5 100644 --- a/content/ja/docs/tutorials/stateful-application/cassandra.md +++ b/content/ja/docs/tutorials/stateful-application/cassandra.md @@ -246,7 +246,7 @@ StatefulSetに関連するすべてのリソースを自動的に破棄するよ ## Cassandraコンテナの環境変数 -このチュートリアルのPodでは、Googleの[コンテナレジストリ](https://cloud.google.com/container-registry/docs/)の[`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile)イメージを使用しました。このDockerイメージは[debian-base](https://github.com/kubernetes/kubernetes/tree/master/build/debian-base)をベースにしており、OpenJDK 8が含まれています。 +このチュートリアルのPodでは、Googleの[コンテナレジストリ](https://cloud.google.com/container-registry/docs/)の[`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile)イメージを使用しました。このDockerイメージは[debian-base](https://github.com/kubernetes/release/tree/master/images/build/debian-base)をベースにしており、OpenJDK 8が含まれています。 このイメージには、Apache Debianリポジトリの標準のCassandraインストールが含まれます。 環境変数を利用すると、`cassandra.yaml`に挿入された値を変更できます。 diff --git a/content/ja/docs/tutorials/stateless-application/guestbook.md b/content/ja/docs/tutorials/stateless-application/guestbook.md index e08abdb62c..82e38a56d2 100644 --- a/content/ja/docs/tutorials/stateless-application/guestbook.md +++ b/content/ja/docs/tutorials/stateless-application/guestbook.md @@ -185,7 +185,7 @@ Deploymentはマニフェストファイル内に書かれた設定に基づい 1. Podのリストを問い合わせて、3つのフロントエンドのレプリカが実行中になっていることを確認します。 ```shell - kubectl get pods -l app=guestbook -l tier=frontend + kubectl get pods -l app.kubernetes.io/name=guestbook -l app.kubernetes.io/component=frontend ``` 結果は次のようになるはずです。 @@ -199,7 +199,7 @@ Deploymentはマニフェストファイル内に書かれた設定に基づい ### フロントエンドのServiceを作成する -適用した`redis-slave`および`redis-master` Serviceは、コンテナクラスター内部からのみアクセス可能です。これは、デフォルトのServiceのtypeが[ClusterIP](/docs/concepts/services-networking/service/#publishing-services---service-types)であるためです。`ClusterIP`は、Serviceが指している一連のPodに対して1つのIPアドレスを提供します。このIPアドレスはクラスター内部からのみアクセスできます。 +適用した`redis-slave`および`redis-master` Serviceは、コンテナクラスター内部からのみアクセス可能です。これは、デフォルトのServiceのtypeが[ClusterIP](/docs/concepts/services-networking/service/#publishing-services-service-types)であるためです。`ClusterIP`は、Serviceが指している一連のPodに対して1つのIPアドレスを提供します。このIPアドレスはクラスター内部からのみアクセスできます。 もしゲストの人にゲストブックにアクセスしてほしいのなら、フロントエンドServiceを外部から見えるように設定しなければなりません。そうすれば、クライアントはコンテナクラスターの外部からServiceにリクエストを送れるようになります。Minikubeでは、Serviceを`NodePort`でのみ公開できます。 diff --git a/content/ja/examples/admin/cloud/ccm-example.yaml b/content/ja/examples/admin/cloud/ccm-example.yaml index 4c98162a70..96b7833174 100644 --- a/content/ja/examples/admin/cloud/ccm-example.yaml +++ b/content/ja/examples/admin/cloud/ccm-example.yaml @@ -1,4 +1,4 @@ -# This is an example of how to setup cloud-controller-manger as a Daemonset in your cluster. +# This is an example of how to setup cloud-controller-manager as a Daemonset in your cluster. # It assumes that your masters can run pods and has the role node-role.kubernetes.io/master # Note that this Daemonset will not work straight out of the box for your cloud, this is # meant to be a guideline. diff --git a/content/ja/examples/application/job/cronjob.yaml b/content/ja/examples/application/job/cronjob.yaml index 2ce31233c3..34ab2a3f06 100644 --- a/content/ja/examples/application/job/cronjob.yaml +++ b/content/ja/examples/application/job/cronjob.yaml @@ -1,4 +1,4 @@ -apiVersion: batch/v1beta1 +apiVersion: batch/v1 kind: CronJob metadata: name: hello diff --git a/content/ja/examples/application/job/indexed-job-vol.yaml b/content/ja/examples/application/job/indexed-job-vol.yaml new file mode 100644 index 0000000000..ed40e1cc44 --- /dev/null +++ b/content/ja/examples/application/job/indexed-job-vol.yaml @@ -0,0 +1,27 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: 'indexed-job' +spec: + completions: 5 + parallelism: 3 + completionMode: Indexed + template: + spec: + restartPolicy: Never + containers: + - name: 'worker' + image: 'docker.io/library/busybox' + command: + - "rev" + - "/input/data.txt" + volumeMounts: + - mountPath: /input + name: input + volumes: + - name: input + downwardAPI: + items: + - path: "data.txt" + fieldRef: + fieldPath: metadata.annotations['batch.kubernetes.io/job-completion-index'] \ No newline at end of file diff --git a/content/ja/examples/application/job/indexed-job.yaml b/content/ja/examples/application/job/indexed-job.yaml new file mode 100644 index 0000000000..5b80d35264 --- /dev/null +++ b/content/ja/examples/application/job/indexed-job.yaml @@ -0,0 +1,35 @@ +apiVersion: batch/v1 +kind: Job +metadata: + name: 'indexed-job' +spec: + completions: 5 + parallelism: 3 + completionMode: Indexed + template: + spec: + restartPolicy: Never + initContainers: + - name: 'input' + image: 'docker.io/library/bash' + command: + - "bash" + - "-c" + - | + items=(foo bar baz qux xyz) + echo ${items[$JOB_COMPLETION_INDEX]} > /input/data.txt + volumeMounts: + - mountPath: /input + name: input + containers: + - name: 'worker' + image: 'docker.io/library/busybox' + command: + - "rev" + - "/input/data.txt" + volumeMounts: + - mountPath: /input + name: input + volumes: + - name: input + emptyDir: {} diff --git a/content/ja/examples/application/job/redis/worker.py b/content/ja/examples/application/job/redis/worker.py index 49e5dae798..87d90bde18 100644 --- a/content/ja/examples/application/job/redis/worker.py +++ b/content/ja/examples/application/job/redis/worker.py @@ -8,11 +8,11 @@ host="redis" # import os # host = os.getenv("REDIS_SERVICE_HOST") -q = rediswq.RedisWQ(name="job2", host="redis") +q = rediswq.RedisWQ(name="job2", host=host) print("Worker with sessionID: " + q.sessionID()) print("Initial queue state: empty=" + str(q.empty())) while not q.empty(): - item = q.lease(lease_secs=10, block=True, timeout=2) + item = q.lease(lease_secs=10, block=True, timeout=2) if item is not None: itemstr = item.decode("utf=8") print("Working on " + itemstr) diff --git a/content/ja/examples/controllers/daemonset.yaml b/content/ja/examples/controllers/daemonset.yaml index 1bfa082833..375391826d 100644 --- a/content/ja/examples/controllers/daemonset.yaml +++ b/content/ja/examples/controllers/daemonset.yaml @@ -16,6 +16,7 @@ spec: spec: tolerations: - key: node-role.kubernetes.io/master + operator: Exists effect: NoSchedule containers: - name: fluentd-elasticsearch diff --git a/content/ja/examples/service/networking/dual-stack-default-svc.yaml b/content/ja/examples/service/networking/dual-stack-default-svc.yaml index 00ed87ba19..86eadd5478 100644 --- a/content/ja/examples/service/networking/dual-stack-default-svc.yaml +++ b/content/ja/examples/service/networking/dual-stack-default-svc.yaml @@ -2,10 +2,11 @@ apiVersion: v1 kind: Service metadata: name: my-service + labels: + app: MyApp spec: selector: app: MyApp ports: - protocol: TCP port: 80 - targetPort: 9376 \ No newline at end of file diff --git a/content/zh/examples/service/networking/dual-stack-ipv4-svc.yaml b/content/ja/examples/service/networking/dual-stack-ipfamilies-ipv6.yaml similarity index 73% rename from content/zh/examples/service/networking/dual-stack-ipv4-svc.yaml rename to content/ja/examples/service/networking/dual-stack-ipfamilies-ipv6.yaml index a875f44d6d..7c7239cae6 100644 --- a/content/zh/examples/service/networking/dual-stack-ipv4-svc.yaml +++ b/content/ja/examples/service/networking/dual-stack-ipfamilies-ipv6.yaml @@ -2,11 +2,13 @@ apiVersion: v1 kind: Service metadata: name: my-service + labels: + app: MyApp spec: - ipFamily: IPv4 + ipFamilies: + - IPv6 selector: app: MyApp ports: - protocol: TCP port: 80 - targetPort: 9376 \ No newline at end of file diff --git a/content/zh/examples/service/networking/dual-stack-ipv6-lb-svc.yaml b/content/ja/examples/service/networking/dual-stack-prefer-ipv6-lb-svc.yaml similarity index 76% rename from content/zh/examples/service/networking/dual-stack-ipv6-lb-svc.yaml rename to content/ja/examples/service/networking/dual-stack-prefer-ipv6-lb-svc.yaml index 2586ec9b39..0949a75428 100644 --- a/content/zh/examples/service/networking/dual-stack-ipv6-lb-svc.yaml +++ b/content/ja/examples/service/networking/dual-stack-prefer-ipv6-lb-svc.yaml @@ -5,11 +5,12 @@ metadata: labels: app: MyApp spec: - ipFamily: IPv6 + ipFamilyPolicy: PreferDualStack + ipFamilies: + - IPv6 type: LoadBalancer selector: app: MyApp ports: - protocol: TCP port: 80 - targetPort: 9376 \ No newline at end of file diff --git a/content/ja/examples/service/networking/dual-stack-preferred-ipfamilies-svc.yaml b/content/ja/examples/service/networking/dual-stack-preferred-ipfamilies-svc.yaml new file mode 100644 index 0000000000..c31acfec58 --- /dev/null +++ b/content/ja/examples/service/networking/dual-stack-preferred-ipfamilies-svc.yaml @@ -0,0 +1,16 @@ +apiVersion: v1 +kind: Service +metadata: + name: my-service + labels: + app: MyApp +spec: + ipFamilyPolicy: PreferDualStack + ipFamilies: + - IPv6 + - IPv4 + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 diff --git a/content/ja/examples/service/networking/dual-stack-preferred-svc.yaml b/content/ja/examples/service/networking/dual-stack-preferred-svc.yaml new file mode 100644 index 0000000000..8fb5bfa3d3 --- /dev/null +++ b/content/ja/examples/service/networking/dual-stack-preferred-svc.yaml @@ -0,0 +1,13 @@ +apiVersion: v1 +kind: Service +metadata: + name: my-service + labels: + app: MyApp +spec: + ipFamilyPolicy: PreferDualStack + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 diff --git a/content/ja/examples/service/networking/external-lb.yaml b/content/ja/examples/service/networking/external-lb.yaml new file mode 100644 index 0000000000..adcf7a2fd0 --- /dev/null +++ b/content/ja/examples/service/networking/external-lb.yaml @@ -0,0 +1,10 @@ +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + name: external-lb +spec: + controller: example.com/ingress-controller + parameters: + apiGroup: k8s.example.com + kind: IngressParameters + name: external-lb diff --git a/content/ja/examples/service/networking/ingress-resource-backend.yaml b/content/ja/examples/service/networking/ingress-resource-backend.yaml new file mode 100644 index 0000000000..87b6bbd0f3 --- /dev/null +++ b/content/ja/examples/service/networking/ingress-resource-backend.yaml @@ -0,0 +1,20 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: ingress-resource-backend +spec: + defaultBackend: + resource: + apiGroup: k8s.example.com + kind: StorageBucket + name: static-assets + rules: + - http: + paths: + - path: /icons + pathType: ImplementationSpecific + backend: + resource: + apiGroup: k8s.example.com + kind: StorageBucket + name: icon-assets diff --git a/content/ja/examples/service/networking/ingress-wildcard-host.yaml b/content/ja/examples/service/networking/ingress-wildcard-host.yaml new file mode 100644 index 0000000000..2be7016706 --- /dev/null +++ b/content/ja/examples/service/networking/ingress-wildcard-host.yaml @@ -0,0 +1,26 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: ingress-wildcard-host +spec: + rules: + - host: "foo.bar.com" + http: + paths: + - pathType: Prefix + path: "/bar" + backend: + service: + name: service1 + port: + number: 80 + - host: "*.foo.com" + http: + paths: + - pathType: Prefix + path: "/foo" + backend: + service: + name: service2 + port: + number: 80 diff --git a/content/ja/examples/service/networking/minimal-ingress.yaml b/content/ja/examples/service/networking/minimal-ingress.yaml new file mode 100644 index 0000000000..76640b9447 --- /dev/null +++ b/content/ja/examples/service/networking/minimal-ingress.yaml @@ -0,0 +1,17 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: minimal-ingress + annotations: + nginx.ingress.kubernetes.io/rewrite-target: / +spec: + rules: + - http: + paths: + - path: /testpath + pathType: Prefix + backend: + service: + name: test + port: + number: 80 diff --git a/content/ja/examples/service/networking/name-virtual-host-ingress-no-third-host.yaml b/content/ja/examples/service/networking/name-virtual-host-ingress-no-third-host.yaml new file mode 100644 index 0000000000..16a560b1ff --- /dev/null +++ b/content/ja/examples/service/networking/name-virtual-host-ingress-no-third-host.yaml @@ -0,0 +1,35 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: name-virtual-host-ingress-no-third-host +spec: + rules: + - host: first.bar.com + http: + paths: + - pathType: Prefix + path: "/" + backend: + service: + name: service1 + port: + number: 80 + - host: second.bar.com + http: + paths: + - pathType: Prefix + path: "/" + backend: + service: + name: service2 + port: + number: 80 + - http: + paths: + - pathType: Prefix + path: "/" + backend: + service: + name: service3 + port: + number: 80 diff --git a/content/ja/examples/service/networking/name-virtual-host-ingress.yaml b/content/ja/examples/service/networking/name-virtual-host-ingress.yaml new file mode 100644 index 0000000000..213a73d261 --- /dev/null +++ b/content/ja/examples/service/networking/name-virtual-host-ingress.yaml @@ -0,0 +1,26 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: name-virtual-host-ingress +spec: + rules: + - host: foo.bar.com + http: + paths: + - pathType: Prefix + path: "/" + backend: + service: + name: service1 + port: + number: 80 + - host: bar.foo.com + http: + paths: + - pathType: Prefix + path: "/" + backend: + service: + name: service2 + port: + number: 80 diff --git a/content/ja/examples/service/networking/simple-fanout-example.yaml b/content/ja/examples/service/networking/simple-fanout-example.yaml new file mode 100644 index 0000000000..19fef9455b --- /dev/null +++ b/content/ja/examples/service/networking/simple-fanout-example.yaml @@ -0,0 +1,23 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: simple-fanout-example +spec: + rules: + - host: foo.bar.com + http: + paths: + - path: /foo + pathType: Prefix + backend: + service: + name: service1 + port: + number: 4200 + - path: /bar + pathType: Prefix + backend: + service: + name: service2 + port: + number: 8080 diff --git a/content/ja/examples/service/networking/test-ingress.yaml b/content/ja/examples/service/networking/test-ingress.yaml new file mode 100644 index 0000000000..acd384ab56 --- /dev/null +++ b/content/ja/examples/service/networking/test-ingress.yaml @@ -0,0 +1,10 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: test-ingress +spec: + defaultBackend: + service: + name: test + port: + number: 80 diff --git a/content/ja/examples/service/networking/tls-example-ingress.yaml b/content/ja/examples/service/networking/tls-example-ingress.yaml new file mode 100644 index 0000000000..fe5d52a0cb --- /dev/null +++ b/content/ja/examples/service/networking/tls-example-ingress.yaml @@ -0,0 +1,20 @@ +apiVersion: networking.k8s.io/v1 +kind: Ingress +metadata: + name: tls-example-ingress +spec: + tls: + - hosts: + - https-example.foo.com + secretName: testsecret-tls + rules: + - host: https-example.foo.com + http: + paths: + - path: / + pathType: Prefix + backend: + service: + name: service1 + port: + number: 80 diff --git a/content/ja/includes/task-tutorial-prereqs.md b/content/ja/includes/task-tutorial-prereqs.md index e8ba679a99..09e7dda1b2 100644 --- a/content/ja/includes/task-tutorial-prereqs.md +++ b/content/ja/includes/task-tutorial-prereqs.md @@ -1,5 +1,6 @@ Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 -まだクラスターがない場合、[Minikube](/ja/docs/setup/learning-environment/minikube/)を使って作成するか、 +このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 +まだクラスターがない場合、[minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/)を使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます: * [Katacoda](https://www.katacoda.com/courses/kubernetes/playground) diff --git a/content/ko/_index.html b/content/ko/_index.html index 9aa0ab3cd3..c6350f1559 100644 --- a/content/ko/_index.html +++ b/content/ko/_index.html @@ -10,7 +10,7 @@ sitemap: {{% blocks/feature image="flower" %}} K8s라고도 알려진 [쿠버네티스]({{< relref "/docs/concepts/overview/what-is-kubernetes" >}})는 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 및 관리해주는 오픈소스 시스템입니다. -애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](http://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다. +애플리케이션을 구성하는 컨테이너들의 쉬운 관리 및 발견을 위해서 컨테이너들을 논리적인 단위로 그룹화합니다. 쿠버네티스는 [Google에서 15년간 프로덕션 워크로드 운영한 경험](https://queue.acm.org/detail.cfm?id=2898444)을 토대로 구축되었으며, 커뮤니티에서 제공한 최상의 아이디어와 방법들이 결합되어 있습니다. {{% /blocks/feature %}} {{% blocks/feature image="scalable" %}} @@ -43,12 +43,12 @@ Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해준

    - Attend KubeCon NA virtually on November 17-20, 2020 + Attend KubeCon North America on October 11-15, 2021



    - Attend KubeCon EU virtually on May 4 – 7, 2021 + Attend KubeCon Europe on May 17-20, 2022
    diff --git a/content/ko/blog/_posts/2021-08-04-kubernetes-release-1.22.md b/content/ko/blog/_posts/2021-08-04-kubernetes-release-1.22.md new file mode 100644 index 0000000000..d936d7c767 --- /dev/null +++ b/content/ko/blog/_posts/2021-08-04-kubernetes-release-1.22.md @@ -0,0 +1,157 @@ +--- +layout: blog +title: '쿠버네티스 1.22: 새로운 정점에 도달(Reaching New Peaks)' +date: 2021-08-04 +slug: kubernetes-1-22-release-announcement +--- + +**저자:** [쿠버네티스 1.22 릴리스 팀](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.22/release-team.md) + +**번역:** [손석호(ETRI)](https://github.com/seokho-son), [서지훈(ETRI)](https://github.com/jihoon-seo), [쿠버네티스 문서 한글화 팀](https://kubernetes.slack.com/archives/CA1MMR86S) + +2021년의 두 번째 릴리스인 쿠버네티스 1.22 릴리스를 발표하게 되어 기쁘게 생각합니다! + +이번 릴리스는 53개의 개선 사항(enhancement)으로 구성되어 있습니다. 13개의 개선 사항은 스테이블(stable)로 졸업하였으며(graduated), 24개의 개선 사항은 베타(beta)로 이동하였고, 16개는 알파(alpha)에 진입하였습니다. 또한, 3개의 기능(feature)을 더 이상 사용하지 않게 되었습니다(deprecated). + +이번 해 4월에는 쿠버네티스 릴리스 케이던스(cadence)가 1년에 4회에서 3회로 공식적으로 변경되었습니다. 이번 릴리스가 해당 방식에 따라 긴 주기를 가진 첫 번째 릴리스입니다. 쿠버네티스 프로젝트가 성숙해짐에 따라, 사이클(cycle) 당 개선 사항도 늘어나고 있습니다. 이것은 기여자 커뮤니티 및 릴리스 엔지니어링 팀에게, 버전과 버전 사이에 더 많은 작업이 필요하다는 것을 의미합니다. 또한 점점 더 많은 기능을 포함하는 릴리스로 최신 상태를 유지하려는 최종-사용자 커뮤니티에도 부담을 줄 수 있습니다. + +연간 4회에서 3회로의 릴리스 케이던스 변경을 통해 프로젝트의 다양한 측면(기여와 릴리스가 관리되는 방법, 업그레이드 및 최신 릴리스 유지에 대한 커뮤니티의 역량 등)에 대한 균형을 이루고자 하였습니다. + +더 자세한 사항은 공식 블로그 포스트 [쿠버네티스 릴리스 케이던스 변경: 알아두어야 할 사항](https://kubernetes.io/blog/2021/07/20/new-kubernetes-release-cadence/)에서 확인할 수 있습니다. + + +## 주요 주제 + +### 서버-사이드 어플라이(Server-side Apply)가 GA로 졸업 + +[서버-사이드 어플라이](https://kubernetes.io/docs/reference/using-api/server-side-apply/)는 쿠버네티스 API 서버에서 동작하는 신규 필드 오너십이며 오브젝트 병합 알고리즘입니다. 서버-사이드 어플라이는 사용자와 컨트롤러가 선언적인 구성을 통해서 자신의 리소스를 관리할 수 있도록 돕습니다. 이 기능은 단순히 fully specified intent를 전송하는 것만으로 자신의 오브젝트를 선언적으로 생성 또는 수정할 수 있도록 허용합니다. 몇 릴리스에 걸친 베타 과정 이후, 서버-사이드 어플라이는 이제 GA(generally available)가 되었습니다. + +### 외부 크리덴셜 제공자가 이제 스테이블이 됨 + +쿠버네티스 클라이언트 [크리덴셜 플러그인](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins)에 대한 지원은 1.11부터 베타였으나, 쿠버네티스 1.22 릴리스에서 스테이블로 졸업하였습니다. 해당 GA 기능 집합은 인터랙티브 로그인 플로우(interactive login flow)를 제공하는 플러그인에 대한 향상된 지원을 포함합니다. 또한, 많은 버그가 수정되었습니다. 플러그인 개발은 [sample-exec-plugin](https://github.com/ankeesler/sample-exec-plugin)을 통해 시작할 수 있습니다. + +### etcd 3.5.0으로 변경 + +쿠버네티스의 기본 백엔드 저장소인 etcd 3.5.0이 신규로 릴리스되었습니다. 신규 릴리스에는 보안, 성능, 모니터링, 개발자 경험 측면의 개선 사항이 포함되어 있습니다. 많은 버그가 수정되었으며 구조화된 로깅으로 마이그레이션(migration to structured logging) 및 빌트-인 로그 순환(built-in log rotation)과 같은 신규 중요 기능들도 일부 포함되었습니다. 해당 릴리스는 트래픽 부하에 대한 솔루션 구현을 위한 자세한 차기 로드맵도 제시하고 있습니다. [3.5.0 릴리스 발표](https://etcd.io/blog/2021/announcing-etcd-3.5/)에서 변경에 대한 자세한 항목을 확인할 수 있습니다. + +### 메모리 리소스에 대한 서비스 품질(Quality of Service) + +쿠버네티스는 원래 v1 cgroups API를 사용했습니다. 해당 디자인에 의해서, `Pod`에 대한 QoS 클래스는 CPU 리소스(예를 들면, `cpu_shares`)에만 적용되었습니다. 알파 기능으로, 쿠버네티스 v1.22에서는 메모리 할당(allocation)과 격리(isolation)를 제어하기 위한 cgroups v2 API를 사용할 수 있습니다. 이 기능은 메모리 리소스에 대한 컨텐션(contention)이 있을 때 워크로드와 노드의 가용성을 향상시키고, 컨테이너 라이프사이클에 대한 예측 가능성을 향상시킬 수 있도록 디자인되었습니다. + +### 노드 시스템 스왑(swap) 지원 + +모든 시스템 관리자나 쿠버네티스 사용자는 쿠버네티스를 설정하거나 사용할 때 스왑 공간(space)을 비활성화해야 한다는 동일한 상황에 놓여 있었습니다. 쿠버네티스 1.22 릴리스에서는 노드의 스왑 메모리를 지원합니다(알파). 이 변경은 블록 스토리지의 일부를 추가적인 가상 메모리로 취급하도록, 관리자의 옵트인(opt in)을 받아서 리눅스 노드에 스왑을 구성합니다. + +### 윈도우(Windows) 개선 사항 및 기능 + +SIG Windows는 계속해서 성장하는 개발자 커뮤니티를 지원하기 위해서 [개발 환경](https://github.com/kubernetes-sigs/sig-windows-dev-tools/)을 릴리스하였습니다. 이 새로운 도구는 여러 CNI 제공자를 지원하며, 여러 플랫폼에서 구동할 수 있습니다. 윈도우 kubelet과 kube-proxy를 컴파일하고, 다른 쿠버네티스 컴포넌트와 함께 빌드될 수 있도록 하는 새로운 방법을 제공하여, 최신(bleeding-edge) 윈도우 기능을 스크래치(scratch)부터 실행할 수 있도록 지원합니다. + +1.22 릴리스에서 윈도우 노드의 CSI 지원이 GA 상태가 되었습니다. 쿠버네티스 v1.22에서는 특권을 가진(privileged) 윈도우 컨테이너가 알파가 되었습니다. 윈도우 노드에서 CSI 스토리지를 사용하도록, 노드에서의 스토리지 작업에 대한 특권을 가진(privileged) [CSIProxy](https://github.com/kubernetes-csi/csi-proxy)가 CSI 노드 플러그인을 특권을 가지지 않은(unprivileged) 파드로 배치되도록 합니다. + +### 기본(default) seccomp 프로파일 + +알파 기능인 기본 seccomp 프로파일이 신규 커맨드라인 플래그 및 설정과 함께 kubelet에 추가되었습니다. 이 신규 기능을 사용하면, `Unconfined`대신 `RuntimeDefault` seccomp 프로파일을 기본으로 사용하는 seccomp이 클러스터 전반에서 기본이 됩니다. 이는 쿠버네티스 디플로이먼트(Deployment)의 기본 보안을 강화합니다. 워크로드에 대한 보안이 기본으로 더 강화되었으므로, 이제 보안 관리자도 조금 더 안심하고 쉴 수 있습니다. 이 기능에 대한 자세한 사항은 공식적인 [seccomp 튜토리얼](https://kubernetes.io/docs/tutorials/clusters/seccomp/#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads)을 참고하시기 바랍니다. + +### kubeadm을 통한 보안성이 더 높은 컨트롤 플레인 + +이 신규 알파 기능을 사용하면 `kubeadm` 컨트롤 플레인 컴포넌트들을 루트가 아닌(non-root) 사용자로 동작시킬 수 있습니다. 이것은 `kubeadm`에 오랫동안 요청되어 온 보안 조치 사항입니다. 이 기능을 사용하려면 `kubeadm`에 한정된 RootlessControlPlane 기능 게이트를 활성화해야 합니다. 이 알파 기능을 사용하여 클러스터를 배치하는 경우, 사용자의 컨트롤 플레인은 더 낮은 특권(privileges)을 가지고 동작하게 됩니다. + +또한 쿠버네티스 1.22는 `kubeadm`의 신규 [v1beta3 구성 API](/docs/reference/config-api/kubeadm-config.v1beta3/)를 제공합니다. 이 버전에는 오랫동안 요청되어 온 몇 가지 기능들이 추가되었고, 기존의 일부 기능들은 사용 중단(deprecated)되었습니다. 이제 v1beta3 버전이 선호되는(preferred) API 버전입니다. 그러나, v1beta2 API도 여전히 사용 가능하며 아직 사용 중단(deprecated)되지 않았습니다. + +## 주요 변경 사항 + +### 사용 중단된(deprecated) 일부 베타 APIs의 제거 + +GA 버전과 중복된 사용 중단(deprecated)된 여러 베타 API가 1.22에서 제거되었습니다. 기존의 모든 오브젝트는 스테이블 APIs를 통해 상호 작용할 수 있습니다. 이 제거에는 `Ingress`, `IngressClass`, `Lease`, `APIService`, `ValidatingWebhookConfiguration`, `MutatingWebhookConfiguration`, `CustomResourceDefinition`, `TokenReview`, `SubjectAccessReview`, `CertificateSigningRequest` API의 베타 버전이 포함되었습니다. + +전체 항목은 [사용 중단된 API에 대한 마이그레이션 지침](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-22)과 블로그 포스트 [1.22에서 쿠버네티스 API와 제거된 기능: 알아두어야 할 사항](https://blog.k8s.io/2021/07/14/upcoming-changes-in-kubernetes-1-22/)에서 확인 가능합니다. + +### 임시(ephemeral) 컨테이너에 대한 API 변경 및 개선 + +1.22에서 [임시 컨테이너](https://kubernetes.io/ko/docs/concepts/workloads/pods/ephemeral-containers/)를 생성하기 위한 API가 변경되었습니다. 임시 컨테이너 기능은 알파이며 기본적으로 비활성화되었습니다. 신규 API는 예전 API를 사용하려는 클라이언트에 대해 동작하지 않습니다. + +스테이블 기능에 대해서, kubectl 도구는 쿠버네티스의 [버전 차이(skew) 정책](https://kubernetes.io/ko/releases/version-skew-policy/)을 따릅니다. 그러나, kubectl v1.21 이하의 버전은 임시 컨테이너에 대한 신규 API를 지원하지 않습니다. 만약 `kubectl debug`를 사용하여 임시 컨테이너를 생성할 계획이 있고 클러스터에서 쿠버네티스 v1.22로 구동하고 있는 경우, kubectl v1.21 이하의 버전에서는 그렇게 할 수 없다는 것을 알아두어야 합니다. 따라서 만약 클러스터 버전을 혼합하여 `kubectl debug`를 사용하려면 kubectl를 1.22로 업데이트하길 바랍니다. + +## 기타 업데이트 + +### 스테이블로 졸업 + +* [바운드 서비스 어카운트 토큰 볼륨(Bound Service Account Token Volumes)](https://github.com/kubernetes/enhancements/issues/542) +* [CSI 서비스 어카운트 토큰(CSI Service Account Token)](https://github.com/kubernetes/enhancements/issues/2047) +* [윈도우의 CSI 플러그인 지원](https://github.com/kubernetes/enhancements/issues/1122) +* [사용 중단된 API 사용에 대한 경고(warning) 메커니즘](https://github.com/kubernetes/enhancements/issues/1693) +* [PodDisruptionBudget 축출(eviction)](https://github.com/kubernetes/enhancements/issues/85) + +### 주목할만한 기능 업데이트 + +* 파드시큐리티폴리시(PodSecurityPolicy)를 대체하기 위한 새로운 [파드시큐리티(PodSecurity) 어드미션(admission)](https://github.com/kubernetes/enhancements/issues/2579) 알파 기능이 소개됨. +* [메모리 관리자(manager)](https://github.com/kubernetes/enhancements/issues/1769)가 베타가 됨. +* [API 서버 트레이싱(tracing)](https://github.com/kubernetes/enhancements/issues/647)을 활성화하는 새로운 알파 기능. +* [kubeadm 설정(configuration)](https://github.com/kubernetes/enhancements/issues/970) 포맷의 신규 v1beta3 버전. +* 퍼시스턴트볼륨(PersistentVolume)을 위한 [Generic data populators](https://github.com/kubernetes/enhancements/issues/1495)를 알파로 활용 가능. +* 쿠버네티스 컨트롤 플레인이 이제 [크론잡 v2 컨트롤러(CronJobs v2 controller)](https://github.com/kubernetes/enhancements/issues/19)를 사용하게 됨. +* 알파 기능으로, 모든 쿠버네티스 노드 컴포넌트(kubelet, kube-proxy, 컨테이너 런타임을 포함)는 [루트가 아닌 사용자로](https://github.com/kubernetes/enhancements/issues/2033) 동작시킬 수 있음. + +# 릴리스 노트 + +1.22 릴리스의 자세한 전체 사항은 [릴리스 노트](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md)에서 확인할 수 있습니다. + +# 릴리스 위치 + +쿠버네티스 1.22는 [여기](https://kubernetes.io/releases/download/)에서 다운로드할 수 있고, [GitHub 프로젝트](https://github.com/kubernetes/kubernetes/releases/tag/v1.22.0)에서도 찾을 수 있습니다. + +쿠버네티스를 시작하는 데 도움이 되는 좋은 자료가 많이 있습니다. 쿠버네티스 사이트에서 [상호 작용형 튜토리얼](https://kubernetes.io/ko/docs/tutorials/)을 수행할 수도 있고, [kind](https://kind.sigs.k8s.io)와 도커 컨테이너를 사용하여 로컬 클러스터를 사용자의 머신에서 구동해볼 수도 있습니다. 클러스터를 스크래치(scratch)부터 구축해보고 싶다면, Kelsey Hightower의 [쿠버네티스 어렵게 익히기(the Hard Way)](https://github.com/kelseyhightower/kubernetes-the-hard-way) 튜토리얼을 확인해보시기 바랍니다. + +# 릴리스 팀 + +이 릴리스는 쿠버네티스 릴리스에 포함되는 모든 기술 콘텐츠, 문서, 코드, 기타 구성 요소 등을 제공하기 위해 팀들로 모인 매우 헌신적인 개인 그룹에 의해 가능했습니다. + +팀을 성공적인 릴리스로 이끈 릴리스 리드 Savitha Raghunathan에게 감사드리며, 릴리스 팀 이외에도 커뮤니티에 1.22 릴리스를 제공하기 위해 열심히 작업하고 지원한 모든 사람들에게 감사드립니다. + +우리는 또한 이 자리를 빌려 올해 초에 생을 마감한 팀 멤버 Peeyush Gupta를 추모하고 싶습니다. Peeyush Gupta는 SIG ContribEx 및 쿠버네티스 릴리스 팀에 활발히 참여했으며, 최근에는 1.22 커뮤니케이션 리드를 역임하였습니다. 그의 기여와 노력은 앞으로도 커뮤니티에 지속적으로 영향을 줄 것입니다. 그에 대한 추억과 추모를 공유하기 위한 [CNCF 추모](https://github.com/cncf/memorials/blob/main/peeyush-gupta.md) 페이지가 생성되어 있습니다. + +# 릴리스 로고 + +![쿠버네티스 1.22 릴리스 로고](/images/blog/2021-08-04-kubernetes-release-1.22/kubernetes-1.22.png) + +진행 중인 팬데믹, 자연재해 및 항상 존재하는 번아웃의 그림자 속에서도, 쿠버네티스 1.22 릴리스는 53개의 개선 사항을 제공하였습니다. 이것은 현재까지 가장 큰 릴리스입니다. 이 성과는 열심히 일하고 열정적인 릴리스 팀 구성원과 쿠버네티스 생태계의 대단한 기여자들 덕분에 달성할 수 있었습니다. 이 릴리스 로고는 새로운 마일스톤과 새로운 기록을 세우기 위한 리마인더입니다. 이 로고를 모든 릴리스 팀 구성원, 등산객, 별을 보는 사람들에게 바칩니다! + +이 로고는 [Boris Zotkin](https://www.instagram.com/boris.z.man/)가 디자인하였습니다. Boris는 MathWorks에서 Mac/Linux 관리자 역할을 맡고 있습니다. 그는 인생에서의 소소한 재미를 즐기고 가족과 함께 시간을 보내는 것을 사랑합니다. 이 기술에 정통(tech-savvy)한 개인은 항상 도전을 준비하며 친구를 돕는 것에 행복을 느낍니다! + +# 사용자 하이라이트 + +- 5월에 CNCF가 전 세계에 걸친 27 기관을 다양한 클라우드 네이티브 생태계의 신규 멤버로 받았습니다. 이 신규 [멤버](https://www.cncf.io/announcements/2021/05/05/27-new-members-join-the-cloud-native-computing-foundation/)는 다가오는 [KubeCon + CloudNativeCon NA in Los Angeles (October 12 – 15, 2021)](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/)를 포함한 CNCF 이벤트들에 참여할 것입니다. +- CNCF는 [KubeCon + CloudNativeCon EU – Virtual 2021](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/)에서 Spotify에 [최고 엔드 유저 상(Top End User Award)](https://www.cncf.io/announcements/2021/05/05/cloud-native-computing-foundation-grants-spotify-the-top-end-user-award/)을 수여했습니다. + +# 프로젝트 속도(Velocity) + +[CNCF K8s DevStats 프로젝트](https://k8s.devstats.cncf.io/)는 쿠버네티스와 다양한 서브-프로젝트에 대한 흥미로운 데이터를 수집하고 있습니다. 여기에는 개인 기여부터 기여하는 회사 수에 이르기까지 모든 것이 포함되며, 이 생태계를 발전시키는 데 필요한 노력의 깊이와 넓이를 보여줍니다. + +우리는 15주(4월 26일에서 8월 4일) 간 진행된 v1.22 릴리스 주기에서, [1063개의 기업](https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1&var-period_name=v1.21.0%20-%20now&var-metric=contributions)과 [2054명의 개인](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)의 기여를 보았습니다. + +# 생태계 업데이트 + +- 세 번째 가상 이벤트인 [KubeCon + CloudNativeCon Europe 2021](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/)이 5월에 열렸습니다. 모든 발표가 [온디맨드로 확인 가능](https://www.youtube.com/playlist?list=PLj6h78yzYM2MqBm19mRz9SYLsw4kfQBrC)합니다. +- [Spring Term LFX 프로그램](https://www.cncf.io/blog/2021/07/13/spring-term-lfx-program-largest-graduating-class-with-28-successful-cncf-interns)이 28명의 성공적인 인턴을 배출한 최대 규모의 졸업반을 가졌습니다! +- CNCF가 연초에 클라우드 네이티브 커뮤니티와 함께 배우고, 성장하고, 협업하기를 원하는 전 세계 누구에게나 상호 작용형 미디어 경험을 제공하고자, [Twitch에서 라이브스트리밍](https://www.cncf.io/blog/2021/06/03/cloud-native-community-goes-live-with-10-shows-on-twitch/)을 시작하였습니다. + +# 이벤트 업데이트 + +- [KubeCon + CloudNativeCon North America 2021](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/)가 October 12 – 15, 2021에 Los Angeles에서 열립니다! 컨퍼런스와 등록에 대한 더 자세한 정보는 이벤트 사이트에서 찾을 수 있습니다. +- [쿠버네티스 커뮤니티 Days](https://community.cncf.io/kubernetes-community-days/about-kcd/)가 Italy, UK, Washington DC에서 이벤트를 앞두고 있습니다. + +# 다가오는 릴리스 웨비나 + +이번 릴리스에 대한 중요 기능뿐만 아니라 업그레이드 계획을 위해 필요한 사용 중지된 사항이나 제거에 대한 사항을 학습하고 싶다면, 2021년 9월 7일에 쿠버네티스 1.22 릴리스 팀 웨비나에 참여하세요. 더 자세한 정보와 등록에 대해서는 CNCF 온라인 프로그램 사이트의 [이벤트 페이지](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kubernetes-122-release/)를 확인하세요. + +# 참여하기 + +만약 쿠버네티스 커뮤니티 기여에 관심이 있다면, 특별 관심 그룹(Special Interest Groups, SIGs)이 좋은 시작 지점이 될 수 있습니다. 그중 많은 SIG가 당신의 관심사와 일치될 수 있습니다! 만약 커뮤니티와 공유하고 싶은 것이 있다면, 주간 커뮤니티 미팅에 참석할 수 있습니다. 또한 다음 중 어떠한 채널이라도 활용할 수 있습니다. + +* [쿠버네티스 기여자](https://www.kubernetes.dev/) 웹사이트에서 기여에 대한 더 자세한 사항을 확인 +* 최신 정보 업데이트를 위해 [@Kubernetesio](https://twitter.com/kubernetesio) 트위터 팔로우 +* [논의(discuss)](https://discuss.kubernetes.io/)에서 커뮤니티 논의에 참여 +* [슬랙](http://slack.k8s.io/)에서 커뮤니티에 참여 +* 쿠버네티스 [사용기](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform) 공유 +* 쿠버네티스에서 일어나는 일에 대한 자세한 사항을 [블로그](https://kubernetes.io/blog/)를 통해 읽기 +* [쿠버네티스 릴리스 팀](https://github.com/kubernetes/sig-release/tree/master/release-team)에 대해 더 알아보기 diff --git a/content/ko/case-studies/adform/adform_featured_logo.png b/content/ko/case-studies/adform/adform_featured_logo.png deleted file mode 100644 index 7e3be727e3..0000000000 Binary files a/content/ko/case-studies/adform/adform_featured_logo.png and /dev/null differ diff --git a/content/ko/case-studies/adform/index.html b/content/ko/case-studies/adform/index.html deleted file mode 100644 index 1de43d0637..0000000000 --- a/content/ko/case-studies/adform/index.html +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: Adform Case Study -linkTitle: Adform -case_study_styles: true -cid: caseStudies -logo: adform_featured_logo.png -draft: false -featured: true -weight: 47 -quote: > - Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier. - -new_case_study_styles: true -heading_background: /images/case-studies/adform/banner1.jpg -heading_title_logo: /images/adform_logo.png -subheading: > - Improving Performance and Morale with Cloud Native -case_study_details: - - Company: AdForm - - Location: Copenhagen, Denmark - - Industry: Adtech ---- - -

    Challenge

    - -

    Adform's mission is to provide a secure and transparent full stack of advertising technology to enable digital ads across devices. The company has a large infrastructure: OpenStack-based private clouds running on 1,100 physical servers in 7 data centers around the world, 3 of which were opened in the past year. With the company's growth, the infrastructure team felt that "our private cloud was not really flexible enough," says IT System Engineer Edgaras Apšega. "The biggest pain point is that our developers need to maintain their virtual machines, so rolling out technology and new software takes time. We were really struggling with our releases, and we didn't have self-healing infrastructure."

    - -

    Solution

    - -

    The team, which had already been using Prometheus for monitoring, embraced Kubernetes and cloud native practices in 2017. "To start our Kubernetes journey, we had to adapt all our software, so we had to choose newer frameworks," says Apšega. "We also adopted the microservices way, so observability is much better because you can inspect the bug or the services separately."

    - -

    Impact

    - -

    "Kubernetes helps our business a lot because our features are coming to market faster," says Apšega. The release process went from several hours to several minutes. Autoscaling has been at least 6 times faster than the semi-manual VM bootstrapping and application deployment required before. The team estimates that the company has experienced cost savings of 4-5x due to less hardware and fewer man hours needed to set up the hardware and virtual machines, metrics, and logging. Utilization of the hardware resources has been reduced as well, with containers notching 2-3 times more efficiency over virtual machines. "The deployments are very easy because developers just push the code and it automatically appears on Kubernetes," says Apšega. Prometheus has also had a positive impact: "It provides high availability for metrics and alerting. We monitor everything starting from hardware to applications. Having all the metrics in Grafana dashboards provides great insight on your systems."

    - -{{< case-studies/quote author="Edgaras Apšega, IT Systems Engineer, Adform" >}} -"Kubernetes enabled the self-healing and immutable infrastructure. We can do faster releases, so our developers are really happy. They can ship our features faster than before, and that makes our clients happier." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -Adform made headlines last year when it detected the HyphBot ad fraud network that was costing some businesses hundreds of thousands of dollars a day. -{{< /case-studies/lead >}} - -

    With its mission to provide a secure and transparent full stack of advertising technology to enable an open internet, Adform published a white paper revealing what it did—and others could too—to limit customers' exposure to the scam.

    - -

    In that same spirit, Adform is sharing its cloud native journey. "When you see that everyone shares their best practices, it inspires you to contribute back to the project," says IT Systems Engineer Edgaras Apšega.

    - -

    The company has a large infrastructure: OpenStack-based private clouds running on 1,100 physical servers in their own seven data centers around the world, three of which were opened in the past year. With the company's growth, the infrastructure team felt that "our private cloud was not really flexible enough," says Apšega. "The biggest pain point is that our developers need to maintain their virtual machines, so rolling out technology and new software really takes time. We were really struggling with our releases, and we didn't have self-healing infrastructure."

    - -{{< case-studies/quote - image="/images/case-studies/adform/banner3.jpg" - author="Edgaras Apšega, IT Systems Engineer, Adform" ->}} -"The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral. And we can see that a community really gathers around it. Everyone shares their experiences, their knowledge, and the fact that it's open source, you can contribute." -{{< /case-studies/quote >}} - -

    The team, which had already been using Prometheus for monitoring, embraced Kubernetes, microservices, and cloud native practices. "The fact that Cloud Native Computing Foundation incubated Kubernetes was a really big point for us because it was vendor neutral," says Apšega. "And we can see that a community really gathers around it."

    - -

    A proof of concept project was started, with a Kubernetes cluster running on bare metal in the data center. When developers saw how quickly containers could be spun up compared to the virtual machine process, "they wanted to ship their containers in production right away, and we were still doing proof of concept," says IT Systems Engineer Andrius Cibulskis.

    - -

    Of course, a lot of work still had to be done. "First of all, we had to learn Kubernetes, see all of the moving parts, how they glue together," says Apšega. "Second of all, the whole CI/CD part had to be redone, and our DevOps team had to invest more man hours to implement it. And third is that developers had to rewrite the code, and they're still doing it."

    - -

    The first production cluster was launched in the spring of 2018, and is now up to 20 physical machines dedicated for pods throughout three data centers, with plans for separate clusters in the other four data centers. The user-facing Adform application platform, data distribution platform, and back ends are now all running on Kubernetes. "Many APIs for critical applications are being developed for Kubernetes," says Apšega. "Teams are rewriting their applications to .NET core, because it supports containers, and preparing to move to Kubernetes. And new applications, by default, go in containers."

    - -{{< case-studies/quote - image="/images/case-studies/adform/banner4.jpg" - author="Andrius Cibulskis, IT Systems Engineer, Adform" ->}} -"Releases are really nice for them, because they just push their code to Git and that's it. They don't have to worry about their virtual machines anymore." -{{< /case-studies/quote >}} - -

    This big push has been driven by the real impact that these new practices have had. "Kubernetes helps our business a lot because our features are coming to market faster," says Apšega. "The deployments are very easy because developers just push the code and it automatically appears on Kubernetes." The release process went from several hours to several minutes. Autoscaling is at least six times faster than the semi-manual VM bootstrapping and application deployment required before.

    - -

    The team estimates that the company has experienced cost savings of 4-5x due to less hardware and fewer man hours needed to set up the hardware and virtual machines, metrics, and logging. Utilization of the hardware resources has been reduced as well, with containers notching two to three times more efficiency over virtual machines.

    - -

    Prometheus has also had a positive impact: "It provides high availability for metrics and alerting," says Apšega. "We monitor everything starting from hardware to applications. Having all the metrics in Grafana dashboards provides great insight on our systems."

    - -{{< case-studies/quote author="Edgaras Apšega, IT Systems Engineer, Adform" >}} -"I think that our company just started our cloud native journey. It seems like a huge road ahead, but we're really happy that we joined it." -{{< /case-studies/quote >}} - -

    All of these benefits have trickled down to individual team members, whose working lives have been changed for the better. "They used to have to get up at night to re-start some services, and now Kubernetes handles all of that," says Apšega. Adds Cibulskis: "Releases are really nice for them, because they just push their code to Git and that's it. They don't have to worry about their virtual machines anymore." Even the security teams have been impacted. "Security teams are always not happy," says Apšega, "and now they're happy because they can easily inspect the containers."

    - -

    The company plans to remain in the data centers for now, "mostly because we want to keep all the data, to not share it in any way," says Cibulskis, "and it's cheaper at our scale." But, Apšega says, the possibility of using a hybrid cloud for computing is intriguing: "One of the projects we're interested in is the Virtual Kubelet that lets you spin up the working nodes on different clouds to do some computing."

    - -

    Apšega, Cibulskis and their colleagues are keeping tabs on how the cloud native ecosystem develops, and are excited to contribute where they can. "I think that our company just started our cloud native journey," says Apšega. "It seems like a huge road ahead, but we're really happy that we joined it."

    diff --git a/content/ko/case-studies/amadeus/amadeus_featured.png b/content/ko/case-studies/amadeus/amadeus_featured.png deleted file mode 100644 index d23d7b0163..0000000000 Binary files a/content/ko/case-studies/amadeus/amadeus_featured.png and /dev/null differ diff --git a/content/ko/case-studies/amadeus/amadeus_logo.png b/content/ko/case-studies/amadeus/amadeus_logo.png deleted file mode 100644 index 6191c7f681..0000000000 Binary files a/content/ko/case-studies/amadeus/amadeus_logo.png and /dev/null differ diff --git a/content/ko/case-studies/amadeus/index.html b/content/ko/case-studies/amadeus/index.html deleted file mode 100644 index bd647003ec..0000000000 --- a/content/ko/case-studies/amadeus/index.html +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: Amadeus Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/amadeus/banner1.jpg -heading_title_logo: /images/amadeus_logo.png -subheading: > - Another Technical Evolution for a 30-Year-Old Company -case_study_details: - - Company: Amadeus IT Group - - Location: Madrid, Spain - - Industry: Travel Technology ---- - -

    Challenge

    - -

    In the past few years, Amadeus, which provides IT solutions to the travel industry around the world, found itself in need of a new platform for the 5,000 services supported by its service-oriented architecture. The 30-year-old company operates its own data center in Germany, and there were growing demands internally and externally for solutions that needed to be geographically dispersed. And more generally, "we had objectives of being even more highly available," says Eric Mountain, Senior Expert, Distributed Systems at Amadeus. Among the company's goals: to increase automation in managing its infrastructure, optimize the distribution of workloads, use data center resources more efficiently, and adopt new technologies more easily.

    - -

    Solution

    - -

    Mountain has been overseeing the company's migration to Kubernetes, using OpenShift Container Platform, Red Hat's enterprise container platform.

    - -

    Impact

    - -

    One of the first projects the team deployed in Kubernetes was the Amadeus Airline Cloud Availability solution, which helps manage ever-increasing flight-search volume. "It's now handling in production several thousand transactions per second, and it's deployed in multiple data centers throughout the world," says Mountain. "It's not a migration of an existing workload; it's a whole new workload that we couldn't have done otherwise. [This platform] gives us access to market opportunities that we didn't have before."

    - -{{< case-studies/quote author="Eric Mountain, Senior Expert, Distributed Systems at Amadeus IT Group" >}} -"We want multi-data center capabilities, and we want them for our mainstream system as well. We didn't think that we could achieve them with our existing system. We need new automation, things that Kubernetes and OpenShift bring." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -In his two decades at Amadeus, Eric Mountain has been the migrations guy. -{{< /case-studies/lead >}} - -

    Back in the day, he worked on the company's move from Unix to Linux, and now he's overseeing the journey to cloud native. "Technology just keeps changing, and we embrace it," he says. "We are celebrating our 30 years this year, and we continue evolving and innovating to stay cost-efficient and enhance everyone's travel experience, without interrupting workflows for the customers who depend on our technology."

    - -

    That was the challenge that Amadeus—which provides IT solutions to the travel industry around the world, from flight searches to hotel bookings to customer feedback—faced in 2014. The technology team realized it was in need of a new platform for the 5,000 services supported by its service-oriented architecture.

    - -

    The tipping point occurred when they began receiving many requests, internally and externally, for solutions that needed to be geographically outside the company's main data center in Germany. "Some requests were for running our applications on customer premises," Mountain says. "There were also new services we were looking to offer that required response time to the order of a few hundred milliseconds, which we couldn't achieve with transatlantic traffic. Or at least, not without eating into a considerable portion of the time available to our applications for them to process individual queries."

    - -

    More generally, the company was interested in leveling up on high availability, increasing automation in managing infrastructure, optimizing the distribution of workloads and using data center resources more efficiently. "We have thousands and thousands of servers," says Mountain. "These servers are assigned roles, so even if the setup is highly automated, the machine still has a given role. It's wasteful on many levels. For instance, an application doesn't necessarily use the machine very optimally. Virtualization can help a bit, but it's not a silver bullet. If that machine breaks, you still want to repair it because it has that role and you can't simply say, 'Well, I'll bring in another machine and give it that role.' It's not fast. It's not efficient. So we wanted the next level of automation."

    - -{{< case-studies/quote image="/images/case-studies/amadeus/banner3.jpg" >}} -"We hope that if we build on what others have built, what we do might actually be upstream-able. As Kubernetes and OpenShift progress, we see that we are indeed able to remove some of the additional layers we implemented to compensate for gaps we perceived earlier." -{{< /case-studies/quote >}} - -

    While mainly a C++ and Java shop, Amadeus also wanted to be able to adopt new technologies more easily. Some of its developers had started using languages like Python and databases like Couchbase, but Mountain wanted still more options, he says, "in order to better adapt our technical solutions to the products we offer, and open up entirely new possibilities to our developers." Working with recent technologies and cool new things would also make it easier to attract new talent.

    - -

    All of those needs led Mountain and his team on a search for a new platform. "We did a set of studies and proofs of concept over a fairly short period, and we considered many technologies," he says. "In the end, we were left with three choices: build everything on premise, build on top of Kubernetes whatever happens to be missing from our point of view, or go with OpenShift and build whatever remains there."

    - -

    The team decided against building everything themselves—though they'd done that sort of thing in the past—because "people were already inventing things that looked good," says Mountain.

    - -

    Ultimately, they went with OpenShift Container Platform, Red Hat's Kubernetes-based enterprise offering, instead of building on top of Kubernetes because "there was a lot of synergy between what we wanted and the way Red Hat was anticipating going with OpenShift," says Mountain. "They were clearly developing Kubernetes, and developing certain things ahead of time in OpenShift, which were important to us, such as more security."

    - -

    The hope was that those particular features would eventually be built into Kubernetes, and, in the case of security, Mountain feels that has happened. "We realize that there's always a certain amount of automation that we will probably have to develop ourselves to compensate for certain gaps," says Mountain. "The less we do that, the better for us. We hope that if we build on what others have built, what we do might actually be upstream-able. As Kubernetes and OpenShift progress, we see that we are indeed able to remove some of the additional layers we implemented to compensate for gaps we perceived earlier."

    - -{{< case-studies/quote image="/images/case-studies/amadeus/banner4.jpg" >}} -"It's not a migration of an existing workload; it's a whole new workload that we couldn't have done otherwise. [This platform] gives us access to market opportunities that we didn't have before." -{{< /case-studies/quote >}} - -

    The first project the team tackled was one that they knew had to run outside the data center in Germany. Because of the project's needs, "We couldn't rely only on the built-in Kubernetes service discovery; we had to layer on top of that an extra service discovery level that allows us to load balance at the operation level within our system," says Mountain. They also built a stream dedicated to monitoring, which at the time wasn't offered in the Kubernetes or OpenShift ecosystem. Now that Prometheus and other products are available, Mountain says the company will likely re-evaluate their monitoring system: "We obviously always like to leverage what Kubernetes and OpenShift can offer." -

    - -

    The second project ended up going into production first: the Amadeus Airline Cloud Availability solution, which helps manage ever-increasing flight-search volume and was deployed in public cloud. Launched in early 2016, it is "now handling in production several thousand transactions per second, and it's deployed in multiple data centers throughout the world," says Mountain. "It's not a migration of an existing workload; it's a whole new workload that we couldn't have done otherwise. [This platform] gives us access to market opportunities that we didn't have before."

    - -

    Having been through this kind of technical evolution more than once, Mountain has advice on how to handle the cultural changes. "That's one aspect that we can tackle progressively," he says. "We have to go on supplying our customers with new features on our pre-existing products, and we have to keep existing products working. So we can't simply do absolutely everything from one day to the next. And we mustn't sell it that way."

    - -

    The first order of business, then, is to pick one or two applications to demonstrate that the technology works. Rather than choosing a high-impact, high-risk project, Mountain's team selected a smaller application that was representative of all the company's other applications in its complexity: "We just made sure we picked something that's complex enough, and we showed that it can be done."

    - -{{< case-studies/quote >}} -"The bottom line is we want these multi-data center capabilities, and we want them as well for our mainstream system," he says. "And we don't think that we can implement them with our previous system. We need the new automation, homogeneity, and scale that Kubernetes and OpenShift bring." -{{< /case-studies/quote >}} - -

    Next comes convincing people. "On the operations side and on the R&D side, there will be people who say quite rightly, 'There is a system, and it works, so why change?'" Mountain says. "The only thing that really convinces people is showing them the value." For Amadeus, people realized that the Airline Cloud Availability product could not have been made available on the public cloud with the company's existing system. The question then became, he says, "Do we go into a full-blown migration? Is that something that is justified?"

    - -

    "The bottom line is we want these multi-data center capabilities, and we want them as well for our mainstream system," he says. "And we don't think that we can implement them with our previous system. We need the new automation, homogeneity, and scale that Kubernetes and OpenShift bring."

    - -

    So how do you get everyone on board? "Make sure you have good links between your R&D and your operations," he says. "Also make sure you're going to talk early on to the investors and stakeholders. Figure out what it is that they will be expecting from you, that will convince them or not, that this is the right way for your company."

    - -

    His other advice is simply to make the technology available for people to try it. "Kubernetes and OpenShift Origin are open source software, so there's no complicated license key for the evaluation period and you're not limited to 30 days," he points out. "Just go and get it running." Along with that, he adds, "You've got to be prepared to rethink how you do things. Of course making your applications as cloud native as possible is how you'll reap the most benefits: 12 factors, CI/CD, which is continuous integration, continuous delivery, but also continuous deployment."

    - -

    And while they explore that aspect of the technology, Mountain and his team will likely be practicing what he preaches to others taking the cloud native journey. "See what happens when you break it, because it's important to understand the limits of the system," he says. Or rather, he notes, the advantages of it. "Breaking things on Kube is actually one of the nice things about it—it recovers. It's the only real way that you'll see that you might be able to do things."

    diff --git a/content/ko/case-studies/ancestry/ancestry_featured.png b/content/ko/case-studies/ancestry/ancestry_featured.png deleted file mode 100644 index 6d63daae32..0000000000 Binary files a/content/ko/case-studies/ancestry/ancestry_featured.png and /dev/null differ diff --git a/content/ko/case-studies/ancestry/ancestry_logo.png b/content/ko/case-studies/ancestry/ancestry_logo.png deleted file mode 100644 index 5fbade8dec..0000000000 Binary files a/content/ko/case-studies/ancestry/ancestry_logo.png and /dev/null differ diff --git a/content/ko/case-studies/ancestry/index.html b/content/ko/case-studies/ancestry/index.html deleted file mode 100644 index 8cab3c19c6..0000000000 --- a/content/ko/case-studies/ancestry/index.html +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: Ancestry Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/ancestry/banner1.jpg -heading_title_logo: /images/ancestry_logo.png -subheading: > - Digging Into the Past With New Technology -case_study_details: - - Company: Ancestry - - Location: Lehi, Utah - - Industry: Internet Company, Online Services ---- - -

    Challenge

    - -

    Ancestry, the global leader in family history and consumer genomics, uses sophisticated engineering and technology to help everyone, everywhere discover the story of what led to them. The company has spent more than 30 years innovating and building products and technologies that at their core, result in real and emotional human responses. Ancestry currently serves more than 2.6 million paying subscribers, holds 20 billion historical records, 90 million family trees and more than four million people are in its AncestryDNA network, making it the largest consumer genomics DNA network in the world. The company's popular website, ancestry.com, has been working with big data long before the term was popularized. The site was built on hundreds of services, technologies and a traditional deployment methodology. "It's worked well for us in the past," says Paul MacKay, software engineer and architect at Ancestry, "but had become quite cumbersome in its processing and is time-consuming. As a primarily online service, we are constantly looking for ways to accelerate to be more agile in delivering our solutions and our products."

    - -

    Solution

    - -

    The company is transitioning to cloud native infrastructure, using Docker containerization, Kubernetes orchestration and Prometheus for cluster monitoring.

    - -

    Impact

    - -

    "Every single product, every decision we make at Ancestry, focuses on delighting our customers with intimate, sometimes life-changing discoveries about themselves and their families," says MacKay. "As the company continues to grow, the increased productivity gains from using Kubernetes has helped Ancestry make customer discoveries faster. With the move to Dockerization for example, instead of taking between 20 to 50 minutes to deploy a new piece of code, we can now deploy in under a minute for much of our code. We've truly experienced significant time savings in addition to the various features and benefits from cloud native and Kubernetes-type technologies."

    - -{{< case-studies/quote author="PAUL MACKAY, SOFTWARE ENGINEER AND ARCHITECT AT ANCESTRY" >}} -"At a certain point, you have to step back if you're going to push a new technology and get key thought leaders with engineers within the organization to become your champions for new technology adoption. At training sessions, the development teams were always the ones that were saying, 'Kubernetes saved our time tremendously; it's an enabler. It really is incredible.'" -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -It started with a Shaky Leaf. -{{< /case-studies/lead >}} - -

    Since its introduction a decade ago, the Shaky Leaf icon has become one of Ancestry's signature features, which signals to users that there's a helpful hint you can use to find out more about your family tree.

    - -

    So when the company decided to begin moving its infrastructure to cloud native technology, the first service that was launched on Kubernetes, the open source platform for managing application containers across clusters of hosts, was this hint system. Think of it as Amazon's recommended products, but instead of recommending products the company recommends records, stories, or familial connections. "It was a very important part of the site," says Ancestry software engineer and architect Paul MacKay, "but also small enough for a pilot project that we knew we could handle in a very appropriate, secure way."

    - -

    And when it went live smoothly in early 2016, "our deployment time for this service literally was cut down from 50 minutes to 2 or 5 minutes," MacKay adds. "The development team was just thrilled because we're focused on supplying a great experience for our customers. And that means features, it means stability, it means all those things that we need for a first-in-class type operation."

    - -

    The stability of that Shaky Leaf was a signal for MacKay and his team that their decision to embrace cloud native technologies was the right one for the company. With a private data center, Ancestry built its website (which launched in 1996) on hundreds of services and technologies and a traditional deployment methodology. "It worked well for us in the past, but the sum of the legacy systems became quite cumbersome in its processing and was time-consuming," says MacKay. "We were looking for other ways to accelerate, to be more agile in delivering our solutions and our products."

    - -{{< case-studies/quote image="/images/case-studies/ancestry/banner3.jpg" >}} -"And when it [Kubernetes] went live smoothly in early 2016, 'our deployment time for this service literally was cut down from 50 minutes to 2 or 5 minutes,' MacKay adds. 'The development team was just thrilled because we're focused on supplying a great experience for our customers. And that means features, it means stability, it means all those things that we need for a first-in-class type operation.'" -{{< /case-studies/quote >}} - -

    That need led them in 2015 to explore containerization. Ancestry engineers had already been using technology like Java and Python on Linux, so part of the decision was about making the infrastructure more Linux-friendly. They quickly decided that they wanted to go with Docker for containerization, "but it always comes down to the orchestration part of it to make it really work," says MacKay.

    - -

    His team looked at orchestration platforms offered by Docker Compose, Mesos and OpenStack, and even started to prototype some homegrown solutions. And then they started hearing rumblings of the imminent release of Kubernetes v1.0. "At the forefront, we were looking at the secret store, so we didn't have to manage that all ourselves, the config maps, the methodology of seamless deployment strategy," he says. "We found that how Kubernetes had done their resources, their types, their labels and just their interface was so much further advanced than the other things we had seen. It was a feature fit."

    - -{{< case-studies/lead >}} -Plus, MacKay says, "I just believed in the confidence that comes with the history that Google has with containerization. So we started out right on the leading edge of it. And we haven't looked back since." -{{< /case-studies/lead >}} - -

    Which is not to say that adopting a new technology hasn't come with some challenges. "Change is hard," says MacKay. "Not because the technology is hard or that the technology is not good. It's just that people like to do things like they had done [before]. You have the early adopters and you have those who are coming in later. It was a learning experience on both sides."

    - -

    Figuring out the best deployment operations for Ancestry was a big part of the work it took to adopt cloud native infrastructure. "We want to make sure the process is easy and also controlled in the manner that allows us the highest degree of security that we demand and our customers demand," says MacKay. "With Kubernetes and other products, there are some good solutions, but a little bit of glue is needed to bring it into corporate processes and governances. It's like having a set of gloves that are generic, but when you really do want to grab something you have to make it so it's customized to you. That's what we had to do."

    - -

    Their best practices include allowing their developers to deploy into development stage and production, but then controlling the aspects that need governance and auditing, such as secrets. They found that having one namespace per service is useful for achieving that containment of secrets and config maps. And for their needs, having one container per pod makes it easier to manage and to have a smaller unit of deployment. -

    - -{{< case-studies/quote image="/images/case-studies/ancestry/banner4.jpg" >}} -"The success of Ancestry's first deployment of the hint system on Kubernetes helped create momentum for greater adoption of the technology." -{{< /case-studies/quote >}} - -

    With that process established, the time spent on deployment was cut down to under a minute for some services. "As programmers, we have what's called REPL: read, evaluate, print, and loop, but with Kubernetes, we have CDEL: compile, deploy, execute, and loop," says MacKay. "It's a very quick loop back and a great benefit to understand that when our services are deployed in production, they're the same as what we tested in the pre-production environments. The approach of cloud native for Ancestry provides us a better ability to scale and to accommodate the business needs as work loads occur."

    - -

    The success of Ancestry's first deployment of the hint system on Kubernetes helped create momentum for greater adoption of the technology. "Engineers like to code, they like to do features, they don't like to sit around waiting for things to be deployed and worrying about scaling up and out and down," says MacKay. "After a while the engineers became our champions. At training sessions, the development teams were always the ones saying, 'Kubernetes saved our time tremendously; it's an enabler; it really is incredible.' Over time, we were able to convince our management that this was a transition that the industry is making and that we needed to be a part of it."

    - -

    A year later, Ancestry has transitioned a good number of applications to Kubernetes. "We have many different services that make up the rich environment that [the website] has from both the DNA side and the family history side," says MacKay. "We have front-end stacks, back-end stacks and back-end processing type stacks that are in the cluster."

    - -

    The company continues to weigh which services it will move forward to Kubernetes, which ones will be kept as is, and which will be replaced in the future and thus don't have to be moved over. MacKay estimates that the company is "approaching halfway on those features that are going forward. We don't have to do a lot of convincing anymore. It's more of an issue of timing with getting product management and engineering staff the knowledge and information that they need."

    - -{{< case-studies/quote >}} -"... 'I believe in Kubernetes. I believe in containerization. I think if we can get there and establish ourselves in that world, we will be further along and far better off being agile and all the things we talk about, and it'll go forward.'" -{{< /case-studies/quote >}} - -

    Looking ahead, MacKay sees Ancestry maximizing the benefits of Kubernetes in 2017. "We're very close to having everything that should be or could be in a Linux-friendly world in Kubernetes by the end of the year," he says, adding that he's looking forward to features such as federation and horizontal pod autoscaling that are currently in the works. "Kubernetes has been very wonderful for us and we continue to ride the wave."

    - -

    That wave, he points out, has everything to do with the vibrant Kubernetes community, which has grown by leaps and bounds since Ancestry joined it as an early adopter. "This is just a very rough way of judging it, but on Slack in June 2015, there were maybe 500 on there," MacKay says. "The last time I looked there were maybe 8,500 just on the Slack channel. There are so many major companies and different kinds of companies involved now. It's the variety of contributors, the number of contributors, the incredibly competent and friendly community."

    - -

    As much as he and his team at Ancestry have benefited from what he calls "the goodness and the technical abilities of many" in the community, they've also contributed information about best practices, logged bug issues and participated in the open source conversation. And they've been active in attending meetups to help educate and give back to the local tech community in Utah. Says MacKay: "We're trying to give back as far as our experience goes, rather than just code."

    - -

    When he meets with companies considering adopting cloud native infrastructure, the best advice he has to give from Ancestry's Kubernetes journey is this: "Start small, but with hard problems," he says. And "you need a patron who understands the vision of containerization, to help you tackle the political as well as other technical roadblocks that can occur when change is needed."

    - -

    With the changes that MacKay's team has led over the past year and a half, cloud native will be part of Ancestry's technological genealogy for years to come. MacKay has been such a champion of the technology that he says people have jokingly accused him of having a Kubernetes tattoo.

    - -

    "I really don't," he says with a laugh. "But I'm passionate. I'm not exclusive to any technology; I use whatever I need that's out there that makes us great. If it's something else, I'll use it. But right now I believe in Kubernetes. I believe in containerization. I think if we can get there and establish ourselves in that world, we will be further along and far better off being agile and all the things we talk about, and it'll go forward."

    - -

    He pauses. "So, yeah, I guess you can say I'm an evangelist for Kubernetes," he says. "But I'm not getting a tattoo!"

    diff --git a/content/ko/case-studies/blablacar/blablacar_featured.png b/content/ko/case-studies/blablacar/blablacar_featured.png deleted file mode 100644 index cfe37257b9..0000000000 Binary files a/content/ko/case-studies/blablacar/blablacar_featured.png and /dev/null differ diff --git a/content/ko/case-studies/blablacar/blablacar_logo.png b/content/ko/case-studies/blablacar/blablacar_logo.png deleted file mode 100644 index 14606e0360..0000000000 Binary files a/content/ko/case-studies/blablacar/blablacar_logo.png and /dev/null differ diff --git a/content/ko/case-studies/blablacar/index.html b/content/ko/case-studies/blablacar/index.html deleted file mode 100644 index e6537a672f..0000000000 --- a/content/ko/case-studies/blablacar/index.html +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: BlaBlaCar Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/blablacar/banner1.jpg -heading_title_logo: /images/blablacar_logo.png -subheading: > - Turning to Containerization to Support Millions of Rideshares -case_study_details: - - Company: BlaBlaCar - - Location: Paris, France - - Industry: Ridesharing Company ---- - -

    Challenge

    - -

    The world's largest long-distance carpooling community, BlaBlaCar, connects 40 million members across 22 countries. The company has been experiencing exponential growth since 2012 and needed its infrastructure to keep up. "When you're thinking about doubling the number of servers, you start thinking, 'What should I do to be more efficient?'" says Simon Lallemand, Infrastructure Engineer at BlaBlaCar. "The answer is not to hire more and more people just to deal with the servers and installation." The team knew they had to scale the platform, but wanted to stay on their own bare metal servers.

    - -

    Solution

    - -

    Opting not to shift to cloud virtualization or use a private cloud on their own servers, the BlaBlaCar team became early adopters of containerization, using the CoreOs runtime rkt, initially deployed using fleet cluster manager. Last year, the company switched to Kubernetes orchestration, and now also uses Prometheus for monitoring.

    - -

    Impact

    - -

    "Before using containers, it would take sometimes a day, sometimes two, just to create a new service," says Lallemand. "With all the tooling that we made around the containers, copying a new service now is a matter of minutes. It's really a huge gain. We are better at capacity planning in our data center because we have fewer constraints due to this abstraction between the services and the hardware we run on. For the developers, it also means they can focus only on the features that they're developing, and not on the infrastructure."

    - -{{< case-studies/quote author="Simon Lallemand, Infrastructure Engineer at BlaBlaCar" >}} -"When you're switching to this cloud-native model and running everything in containers, you have to make sure that at any moment you can reboot without any downtime and without losing traffic. [With Kubernetes] our infrastructure is much more resilient and we have better availability than before." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -For the 40 million users of BlaBlaCar, it's easy to find strangers headed in the same direction to share rides and costs. You can even choose how much "bla bla" chatter you want from a long-distance ride mate. -{{< /case-studies/lead >}} - -

    Behind the scenes, though, the infrastructure was falling woefully behind the rider community's exponential growth. Founded in 2006, the company hit its current stride around 2012. "Our infrastructure was very traditional," says Infrastructure Engineer Simon Lallemand, who began working at the company in 2014. "In the beginning, it was a bit chaotic because we had to [grow] fast. But then comes the time when you have to design things to make it manageable."

    - -

    By 2015, the company had about 50 bare metal servers. The team was using a MySQL database and PHP, but, Lallemand says, "it was a very static way." They also utilized the configuration management system, Chef, but had little automation in its process. "When you're thinking about doubling the number of servers, you start thinking, 'What should I do to be more efficient?'" says Lallemand. "The answer is not to hire more and more people just to deal with the servers and installation."

    - -

    Instead, BlaBlaCar began its cloud-native journey but wasn't sure which route to take. "We could either decide to go into cloud virtualization or even use a private cloud on our own servers," says Lallemand. "But going into the cloud meant we had to make a lot of changes in our application work, and we were just not ready to make the switch from on premise to the cloud." They wanted to keep the great performance they got on bare metal, so they didn't want to go to virtualization on premise.

    - -

    The solution: containerization. This was early 2015 and containers were still relatively new. "It was a bold move at the time," says Lallemand. "We decided that the next servers that we would buy in the new data center would all be the same model, so we could outsource the maintenance of the servers. And we decided to go with containers and with CoreOS Container Linux as an abstraction for this hardware. It seemed future-proof to go with containers because we could see what companies were already doing with containers."

    - -{{< case-studies/quote image="/images/case-studies/blablacar/banner3.jpg">}} -"With all the tooling that we made around the containers, copying a new service is a matter of minutes. It's a huge gain. For the developers, it means they can focus only on the features that they're developing and not on the infrastructure or the hour they would test their code, or the hour that it would get deployed." -{{< /case-studies/quote >}} - -

    Next, they needed to choose a runtime for the containers, but "there were very few deployments in production at that time," says Lallemand. They experimented with Docker but decided to go with rkt. Lallemand explains that for BlaBlaCar, it was "much simpler to integrate things that are on rkt." At the time, the project was still pre-v1.0, so "we could speak with the developers of rkt and give them feedback. It was an advantage." Plus, he notes, rkt was very stable, even at this early stage.

    - -

    Once those decisions were made that summer, the company came up with a plan for implementation. First, they formed a task force to create a workflow that would be tested by three of the 10 members on Lallemand's team. But they took care to run regular workshops with all 10 members to make sure everyone was on board. "When you're focused on your product sometimes you forget if it's really user friendly, whether other people can manage to create containers too," Lallemand says. "So we did a lot of iterations to find a good workflow."

    - -

    After establishing the workflow, Lallemand says with a smile that "we had this strange idea that we should try the most difficult thing first. Because if it works, it will work for everything." So the first project the team decided to containerize was the database. "Nobody did that at the time, and there were really no existing tools for what we wanted to do, including building container images," he says. So the team created their own tools, such as dgr, which builds container images so that the whole team has a common framework to build on the same images with the same standards. They also revamped the service-discovery tools Nerve and Synapse; their versions, Go-Nerve and Go-Synapse, were written in Go and built to be more efficient and include new features. All of these tools were open-sourced.

    - -

    At the same time, the company was working to migrate its entire platform to containers with a deadline set for Christmas 2015. With all the work being done in parallel, BlaBlaCar was able to get about 80 percent of its production into containers by its deadline with live traffic running on containers during December. (It's now at 100 percent.) "It's a really busy time for traffic," says Lallemand. "We knew that by using those new servers with containers, it would help us handle the traffic."

    - -

    In the middle of that peak season for carpooling, everything worked well. "The biggest impact that we had was for the deployment of new services," says Lallemand. "Before using containers, we had to first deploy a new server and create configurations with Chef. It would take sometimes a day, sometimes two, just to create a new service. And with all the tooling that we made around the containers, copying a new service is a matter of minutes. So it's really a huge gain. For the developers, it means they can focus only on the features that they're developing and not on the infrastructure or the hour they would test their code, or the hour that it would get deployed."

    - -{{< case-studies/quote image="/images/case-studies/blablacar/banner4.jpg" >}} -"We realized that there was a really strong community around it [Kubernetes], which meant we would not have to maintain a lot of tools of our own," says Lallemand. "It was better if we could contribute to some bigger project like Kubernetes." -{{< /case-studies/quote >}} - -

    In order to meet their self-imposed deadline, one of the decisions they made was to not do any "orchestration magic" for containers in the first production alignment. Instead, they used the basic fleet tool from CoreOS to deploy their containers. (They did build a tool called GGN, which they've open-sourced, to make it more manageable for their system engineers to use.)

    - -

    Still, the team knew that they'd want more orchestration. "Our tool was doing a pretty good job, but at some point you want to give more autonomy to the developer team," Lallemand says. "We also realized that we don't want to be the single point of contact for developers when they want to launch new services." By the summer of 2016, they found their answer in Kubernetes, which had just begun supporting rkt implementation.

    - -

    After discussing their needs with their contacts at CoreOS and Google, they were convinced that Kubernetes would work for BlaBlaCar. "We realized that there was a really strong community around it, which meant we would not have to maintain a lot of tools of our own," says Lallemand. "It was better if we could contribute to some bigger project like Kubernetes." They also started using Prometheus, as they were looking for "service-oriented monitoring that could be updated nightly." Production on Kubernetes began in December 2016. "We like to do crazy stuff around Christmas," he adds with a laugh.

    - -

    BlaBlaCar now has about 3,000 pods, with 1200 of them running on Kubernetes. Lallemand leads a "foundations team" of 25 members who take care of the networks, databases and systems for about 100 developers. There have been some challenges getting to this point. "The rkt implementation is still not 100 percent finished," Lallemand points out. "It's really good, but there are some features still missing. We have questions about how we do things with stateful services, like databases. We know how we will be migrating some of the services; some of the others are a bit more complicated to deal with. But the Kubernetes community is making a lot of progress on that part."

    - -

    The team is particularly happy that they're now able to plan capacity better in the company's data center. "We have fewer constraints since we have this abstraction between the services and the hardware we run on," says Lallemand. "If we lose a server because there's a hardware problem on it, we just move the containers onto another server. It's much more efficient. We do that by just changing a line in the configuration file. And with Kubernetes, it should be automatic, so we would have nothing to do."

    - -{{< case-studies/quote >}} -"If we lose a server because there's a hardware problem on it, we just move the containers onto another server. It's much more efficient. We do that by just changing a line in the configuration file. With Kubernetes, it should be automatic, so we would have nothing to do." -{{< /case-studies/quote >}} - -

    And these advances ultimately trickle down to BlaBlaCar's users. "We have improved availability overall on our website," says Lallemand. "When you're switching to this cloud-native model with running everything in containers, you have to make sure that you can at any moment reboot a server or a data container without any downtime, without losing traffic. So now our infrastructure is much more resilient and we have better availability than before."

    - -

    Within BlaBlaCar's technology department, the cloud-native journey has created some profound changes. Lallemand thinks that the regular meetings during the conception stage and the training sessions during implementation helped. "After that everybody took part in the migration process," he says. "Then we split the organization into different 'tribes'—teams that gather developers, product managers, data analysts, all the different jobs, to work on a specific part of the product. Before, they were organized by function. The idea is to give all these tribes access to the infrastructure directly in a self-service way without having to ask. These people are really autonomous. They have responsibility of that part of the product, and they can make decisions faster."

    - -

    This DevOps transformation turned out to be a positive one for the company's staffers. "The team was very excited about the DevOps transformation because it was new, and we were working to make things more reliable, more future-proof," says Lallemand. "We like doing things that very few people are doing, other than the internet giants."

    - -

    With these changes already making an impact, BlaBlaCar is looking to split up more and more of its application into services. "I don't say microservices because they're not so micro," Lallemand says. "If we can split the responsibilities between the development teams, it would be easier to manage and more reliable, because we can easily add and remove services if one fails. You can handle it easily, instead of adding a big monolith that we still have."

    - -

    When Lallemand speaks to other European companies curious about what BlaBlaCar has done with its infrastructure, he tells them to come along for the ride. "I tell them that it's such a pleasure to deal with the infrastructure that we have today compared to what we had before," he says. "They just need to keep in mind their real motive, whether it's flexibility in development or reliability or so on, and then go step by step towards reaching those objectives. That's what we've done. It's important not to do technology for the sake of technology. Do it for a purpose. Our focus was on helping the developers."

    diff --git a/content/ko/case-studies/blackrock/blackrock_featured.png b/content/ko/case-studies/blackrock/blackrock_featured.png deleted file mode 100644 index 3898b88c9f..0000000000 Binary files a/content/ko/case-studies/blackrock/blackrock_featured.png and /dev/null differ diff --git a/content/ko/case-studies/blackrock/blackrock_logo.png b/content/ko/case-studies/blackrock/blackrock_logo.png deleted file mode 100644 index 51e914a63b..0000000000 Binary files a/content/ko/case-studies/blackrock/blackrock_logo.png and /dev/null differ diff --git a/content/ko/case-studies/blackrock/index.html b/content/ko/case-studies/blackrock/index.html deleted file mode 100644 index 725d6bc057..0000000000 --- a/content/ko/case-studies/blackrock/index.html +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: BlackRock Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/blackrock/banner1.jpg -heading_title_logo: /images/blackrock_logo.png -subheading: > - Rolling Out Kubernetes in Production in 100 Days -case_study_details: - - Company: BlackRock - - Location: New York, NY - - Industry: Financial Services ---- - -

    Challenge

    - -

    The world's largest asset manager, BlackRock operates a very controlled static deployment scheme, which has allowed for scalability over the years. But in their data science division, there was a need for more dynamic access to resources. "We want to be able to give every investor access to data science, meaning Python notebooks, or even something much more advanced, like a MapReduce engine based on Spark," says Michael Francis, a Managing Director in BlackRock's Product Group, which runs the company's investment management platform. "Managing complex Python installations on users' desktops is really hard because everyone ends up with slightly different environments. We have existing environments that do these things, but we needed to make it real, expansive and scalable. Being able to spin that up on demand, tear it down, make that much more dynamic, became a critical thought process for us. It's not so much that we had to solve our main core production problem, it's how do we extend that? How do we evolve?"

    - -

    Solution

    - -

    Drawing from what they learned during a pilot done last year using Docker environments, Francis put together a cross-sectional team of 20 to build an investor research web app using Kubernetes with the goal of getting it into production within one quarter.

    - -

    Impact

    - -

    "Our goal was: How do you give people tools rapidly without having to install them on their desktop?" says Francis. And the team hit the goal within 100 days. Francis is pleased with the results and says, "We're going to use this infrastructure for lots of other application workloads as time goes on. It's not just data science; it's this style of application that needs the dynamism. But I think we're 6-12 months away from making a [large scale] decision. We need to gain experience of running the system in production, we need to understand failure modes and how best to manage operational issues. What's interesting is that just having this technology there is changing the way our developers are starting to think about their future development."

    - -{{< case-studies/quote author="Michael Francis, Managing Director, BlackRock">}} -"My message to other enterprises like us is you can actually integrate Kubernetes into an existing, well-orchestrated machinery. You don't have to throw out everything you do. And using Kubernetes made a complex problem significantly easier." -{{< /case-studies/quote >}} - -

    One of the management objectives for BlackRock's Product Group employees in 2017 was to "build cool stuff." Led by Managing Director Michael Francis, a cross-sectional group of 20 did just that: They rolled out a full production Kubernetes environment and released a new investor research web app on it. In 100 days.

    - -

    For a company that's the world's largest asset manager, "just equipment procurement can take 100 days sometimes, let alone from inception to delivery," says Karl Wieman, a Senior System Administrator. "It was an aggressive schedule. But it moved the dial." In fact, the project achieved two goals: It solved a business problem (creating the needed web app) as well as provided real-world, in-production experience with Kubernetes, a cloud-native technology that the company was eager to explore. "It's not so much that we had to solve our main core production problem, it's how do we extend that? How do we evolve?" says Francis. The ultimate success of this project, beyond delivering the app, lies in the fact that "we've managed to integrate a radically new thought process into a controlled infrastructure that we didn't want to change."

    - -

    After all, in its three decades of existence, BlackRock has "a very well-established environment for managing our compute resources," says Francis. "We manage large cluster processes on machines, so we do a lot of orchestration and management for our main production processes in a way that's very cloudish in concept. We're able to manage them in a very controlled, static deployment scheme, and that has given us a huge amount of scalability."

    - -

    Though that works well for the core production, the company has found that some data science workloads require more dynamic access to resources. "It's a very bursty process," says Francis, who is head of data for the company's Aladdin investment management platform division.

    - -

    Aladdin, which connects the people, information and technology needed for money management in real time, is used internally and is also sold as a platform to other asset managers and insurance companies. "We want to be able to give every investor access to data science, meaning Python notebooks, or even something much more advanced, like a MapReduce engine based on Spark," says Francis. But "managing complex Python installations on users' desktops is really hard because everyone ends up with slightly different environments. Docker allows us to flatten that environment."

    - -{{< case-studies/quote image="/images/case-studies/blackrock/banner3.jpg">}} -"We manage large cluster processes on machines, so we do a lot of orchestration and management for our main production processes in a way that's very cloudish in concept. We're able to manage them in a very controlled, static deployment scheme, and that has given us a huge amount of scalability." -{{< /case-studies/quote >}} - -

    Still, challenges remain. "If you have a shared cluster, you get this storming herd problem where everyone wants to do the same thing at the same time," says Francis. "You could put limits on it, but you'd have to build an infrastructure to define limits for our processes, and the Python notebooks weren't really designed for that. We have existing environments that do these things, but we needed to make it real, expansive, and scalable. Being able to spin that up on demand, tear it down, and make that much more dynamic, became a critical thought process for us."

    - -

    Made up of managers from technology, infrastructure, production operations, development and information security, Francis's team was able to look at the problem holistically and come up with a solution that made sense for BlackRock. "Our initial straw man was that we were going to build everything using Ansible and run it all using some completely different distributed environment," says Francis. "That would have been absolutely the wrong thing to do. Had we gone off on our own as the dev team and developed this solution, it would have been a very different product. And it would have been very expensive. We would not have gone down the route of running under our existing orchestration system. Because we don't understand it. These guys [in operations and infrastructure] understand it. Having the multidisciplinary team allowed us to get to the right solutions and that actually meant we didn't build anywhere near the amount we thought we were going to end up building."

    - -

    In search of a solution in which they could manage usage on a user-by-user level, Francis's team gravitated to Red Hat's OpenShift Kubernetes offering. The company had already experimented with other cloud-native environments, but the team liked that Kubernetes was open source, and "we felt the winds were blowing in the direction of Kubernetes long term," says Francis. "Typically we make technology choices that we believe are going to be here in 5-10 years' time, in some form. And right now, in this space, Kubernetes feels like the one that's going to be there." Adds Uri Morris, Vice President of Production Operations: "When you see that the non-Google committers to Kubernetes overtook the Google committers, that's an indicator of the momentum."

    - -

    Once that decision was made, the major challenge was figuring out how to make Kubernetes work within BlackRock's existing framework. "It's about understanding how we can operate, manage and support a platform like this, in addition to tacking it onto our existing technology platform," says Project Manager Michael Maskallis. "All the controls we have in place, the change management process, the software development lifecycle, onboarding processes we go through—how can we do all these things?"

    - -

    The first (anticipated) speed bump was working around issues behind BlackRock's corporate firewalls. "One of our challenges is there are no firewalls in most open source software," says Francis. "So almost all install scripts fail in some bizarre way, and pulling down packages doesn't necessarily work." The team ran into these types of problems using Minikube and did a few small pushes back to the open source project.

    - -{{< case-studies/quote image="/images/case-studies/blackrock/banner4.jpg">}} -"Typically we make technology choices that we believe are going to be here in 5-10 years' time, in some form. And right now, in this space, Kubernetes feels like the one that's going to be there." -{{< /case-studies/quote >}} - -

    There were also questions about service discovery. "You can think of Aladdin as a cloud of services with APIs between them that allows us to build applications rapidly," says Francis. "It's all on a proprietary message bus, which gives us all sorts of advantages but at the same time, how does that play in a third party [platform]?"

    - -

    Another issue they had to navigate was that in BlackRock's existing system, the messaging protocol has different instances in the different development, test and production environments. While Kubernetes enables a more DevOps-style model, it didn't make sense for BlackRock. "I think what we are very proud of is that the ability for us to push into production is still incredibly rapid in this [new] infrastructure, but we have the control points in place, and we didn't have to disrupt everything," says Francis. "A lot of the cost of this development was thinking how best to leverage our internal tools. So it was less costly than we actually thought it was going to be."

    - -

    The project leveraged tools associated with the messaging bus, for example. "The way that the Kubernetes cluster will talk to our internal messaging platform is through a gateway program, and this gateway program already has built-in checks and throttles," says Morris. "We can use them to control and potentially throttle the requests coming in from Kubernetes's very elastic infrastructure to the production infrastructure. We'll continue to go in that direction. It enables us to scale as we need to from the operational perspective."

    - -

    The solution also had to be complementary with BlackRock's centralized operational support team structure. "The core infrastructure components of Kubernetes are hooked into our existing orchestration framework, which means that anyone in our support team has both control and visibility to the cluster using the existing operational tools," Morris explains. "That means that I don't need to hire more people."

    - -

    With those points established, the team created a procedure for the project: "We rolled this out first to a development environment, then moved on to a testing environment and then eventually to two production environments, in that sequential order," says Maskallis. "That drove a lot of our learning curve. We have all these moving parts, the software components on the infrastructure side, the software components with Kubernetes directly, the interconnectivity with the rest of the environment that we operate here at BlackRock, and how we connect all these pieces. If we came across issues, we fixed them, and then moved on to the different environments to replicate that until we eventually ended up in our production environment where this particular cluster is supposed to live."

    - -

    The team had weekly one-hour working sessions with all the members (who are located around the world) participating, and smaller breakout or deep-dive meetings focusing on specific technical details. Possible solutions would be reported back to the group and debated the following week. "I think what made it a successful experiment was people had to work to learn, and they shared their experiences with others," says Vice President and Software Developer Fouad Semaan. Then, Francis says, "We gave our engineers the space to do what they're good at. This hasn't been top-down."

    - -{{< case-studies/quote >}} -"The core infrastructure components of Kubernetes are hooked into our existing orchestration framework, which means that anyone in our support team has both control and visibility to the cluster using the existing operational tools. That means that I don't need to hire more people." -{{< /case-studies/quote >}} - -

    They were led by one key axiom: To stay focused and avoid scope creep. This meant that they wouldn't use features that weren't in the core of Kubernetes and Docker. But if there was a real need, they'd build the features themselves. Luckily, Francis says, "Because of the rapidity of the development, a lot of things we thought we would have to build ourselves have been rolled into the core product. [The package manager Helm is one example]. People have similar problems."

    - -

    By the end of the 100 days, the app was up and running for internal BlackRock users. The initial capacity of 30 users was hit within hours, and quickly increased to 150. "People were immediately all over it," says Francis. In the next phase of this project, they are planning to scale up the cluster to have more capacity.

    - -

    Even more importantly, they now have in-production experience with Kubernetes that they can continue to build on—and a complete framework for rolling out new applications. "We're going to use this infrastructure for lots of other application workloads as time goes on. It's not just data science; it's this style of application that needs the dynamism," says Francis. "Is it the right place to move our core production processes onto? It might be. We're not at a point where we can say yes or no, but we felt that having real production experience with something like Kubernetes at some form and scale would allow us to understand that. I think we're 6-12 months away from making a [large scale] decision. We need to gain experience of running the system in production, we need to understand failure modes and how best to manage operational issues."

    - -

    For other big companies considering a project like this, Francis says commitment and dedication are key: "We got the signoff from [senior management] from day one, with the commitment that we were able to get the right people. If I had to isolate what makes something complex like this succeed, I would say senior hands-on people who can actually drive it make a huge difference." With that in place, he adds, "My message to other enterprises like us is you can actually integrate Kubernetes into an existing, well-orchestrated machinery. You don't have to throw out everything you do. And using Kubernetes made a complex problem significantly easier."

    diff --git a/content/ko/case-studies/box/index.html b/content/ko/case-studies/box/index.html index 058ff7f9a2..392e3d66bb 100644 --- a/content/ko/case-studies/box/index.html +++ b/content/ko/case-studies/box/index.html @@ -23,7 +23,7 @@ case_study_details:

    Solution

    -

    Over the past couple of years, Box has been decomposing its infrastructure into microservices, and became an early adopter of, as well as contributor to, Kubernetes container orchestration. Kubernetes, Ghods says, has allowed Box's developers to "target a universal set of concepts that are portable across all clouds."

    +

    Over the past couple of years, Box has been decomposing its infrastructure into microservices, and became an early adopter of, as well as contributor to, Kubernetes container orchestration. Kubernetes, Ghods says, has allowed Box's developers to "target a universal set of concepts that are portable across all clouds."

    Impact

    @@ -37,7 +37,7 @@ case_study_details: In the summer of 2014, Box was feeling the pain of a decade's worth of hardware and software infrastructure that wasn't keeping up with the company's needs. {{< /case-studies/lead >}} -

    A platform that allows its more than 50 million users (including governments and big businesses like General Electric) to manage and share content in the cloud, Box was originally a PHP monolith of millions of lines of code built exclusively with bare metal inside of its own data centers. It had already begun to slowly chip away at the monolith, decomposing it into microservices. And "as we've been expanding into regions around the globe, and as the public cloud wars have been heating up, we've been focusing a lot more on figuring out how we run our workload across many different environments and many different cloud infrastructure providers," says Box Cofounder and Services Architect Sam Ghods. "It's been a huge challenge thus far because of all these different providers, especially bare metal, have very different interfaces and ways in which you work with them."

    +

    A platform that allows its more than 50 million users (including governments and big businesses like General Electric) to manage and share content in the cloud, Box was originally a PHP monolith of millions of lines of code built exclusively with bare metal inside of its own data centers. It had already begun to slowly chip away at the monolith, decomposing it into microservices. And "as we've been expanding into regions around the globe, and as the public cloud wars have been heating up, we've been focusing a lot more on figuring out how we run our workload across many different environments and many different cloud infrastructure providers," says Box Cofounder and Services Architect Sam Ghods. "It's been a huge challenge thus far because of all these different providers, especially bare metal, have very different interfaces and ways in which you work with them."

    Box's cloud native journey accelerated that June, when Ghods attended DockerCon. The company had come to the realization that it could no longer run its applications only off bare metal, and was researching containerizing with Docker, virtualizing with OpenStack, and supporting public cloud.

    diff --git a/content/ko/case-studies/buffer/buffer_featured.png b/content/ko/case-studies/buffer/buffer_featured.png deleted file mode 100644 index cd6aaba4ca..0000000000 Binary files a/content/ko/case-studies/buffer/buffer_featured.png and /dev/null differ diff --git a/content/ko/case-studies/buffer/buffer_logo.png b/content/ko/case-studies/buffer/buffer_logo.png deleted file mode 100644 index 1b4b3b7e52..0000000000 Binary files a/content/ko/case-studies/buffer/buffer_logo.png and /dev/null differ diff --git a/content/ko/case-studies/buffer/index.html b/content/ko/case-studies/buffer/index.html deleted file mode 100644 index bcf0896445..0000000000 --- a/content/ko/case-studies/buffer/index.html +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: Buffer Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/buffer/banner3.jpg -heading_title_logo: /images/buffer.png -subheading: > - Making Deployments Easy for a Small, Distributed Team -case_study_details: - - Company: Buffer - - Location: Around the World - - Industry: Social Media Technology ---- - -

    Challenge

    - -

    With a small but fully distributed team of 80 working across almost a dozen time zones, Buffer—which offers social media management to agencies and marketers—was looking to solve its "classic monolithic code base problem," says Architect Dan Farrelly. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary."

    - -

    Solution

    - -

    Embracing containerization, Buffer moved its infrastructure from Amazon Web Services' Elastic Beanstalk to Docker on AWS, orchestrated with Kubernetes.

    - -

    Impact

    - -

    The new system "leveled up our ability with deployment and rolling out new changes," says Farrelly. "Building something on your computer and knowing that it's going to work has shortened things up a lot. Our feedback cycles are a lot faster now too."

    - -{{< case-studies/quote author="DAN FARRELLY, BUFFER ARCHITECT" >}} -"It's amazing that we can use the Kubernetes solution off the shelf with our team. And it just keeps getting better. Before we even know that we need something, it's there in the next release or it's coming in the next few months." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -Dan Farrelly uses a carpentry analogy to explain the problem his company, Buffer, began having as its team of developers grew over the past few years. -{{< /case-studies/lead >}} - -

    "If you're building a table by yourself, it's fine," the company's architect says. "If you bring in a second person to work on the table, maybe that person can start sanding the legs while you're sanding the top. But when you bring a third or fourth person in, someone should probably work on a different table." Needing to work on more and more different tables led Buffer on a path toward microservices and containerization made possible by Kubernetes.

    - -

    Since around 2012, Buffer had already been using Elastic Beanstalk, the orchestration service for deploying infrastructure offered by Amazon Web Services. "We were deploying a single monolithic PHP application, and it was the same application across five or six environments," says Farrelly. "We were very much a product-driven company. It was all about shipping new features quickly and getting things out the door, and if something was not broken, we didn't spend too much time on it. If things were getting a little bit slow, we'd maybe use a faster server or just scale up one instance, and it would be good enough. We'd move on."

    - -

    But things came to a head in 2016. With the growing number of committers on staff, Farrelly and Buffer's then-CTO, Sunil Sadasivan, decided it was time to re-architect and rethink their infrastructure. "It was a classic monolithic code base problem," says Farrelly.

    Some of the company's team was already successfully using Docker in their development environment, but the only application running on Docker in production was a marketing website that didn't see real user traffic. They wanted to go further with Docker, and the next step was looking at options for orchestration.

    - -{{< case-studies/quote image="/images/case-studies/buffer/banner1.jpg" >}} -And all the things Kubernetes did well suited Buffer's needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it [Kubernetes]." -{{< /case-studies/quote >}} - -

    First they considered Mesosphere, DC/OS and Amazon Elastic Container Service (which their data systems team was already using for some data pipeline jobs). While they were impressed by these offerings, they ultimately went with Kubernetes. "We run on AWS still, so spinning up, creating services and creating load balancers on demand for us without having to configure them manually was a great way for our team to get into this," says Farrelly. "We didn't need to figure out how to configure this or that, especially coming from a former Elastic Beanstalk environment that gave us an automatically-configured load balancer. I really liked Kubernetes' controls of the command line. It just took care of ports. It was a lot more flexible. Kubernetes was designed for doing what it does, so it does it very well."

    - -

    And all the things Kubernetes did well suited Buffer's needs. "We wanted to have the kind of liquid infrastructure where a developer could create an app and deploy it and scale it horizontally as necessary," says Farrelly. "We quickly used some scripts to set up a couple of test clusters, we built some small proof-of-concept applications in containers, and we deployed things within an hour. We had very little experience in running containers in production. It was amazing how quickly we could get a handle on it [Kubernetes]."

    - -

    Above all, it provided a powerful solution for one of the company's most distinguishing characteristics: their remote team that's spread across a dozen different time zones. "The people with deep knowledge of our infrastructure live in time zones different from our peak traffic time zones, and most of our product engineers live in other places," says Farrelly. "So we really wanted something where anybody could get a grasp of the system early on and utilize it, and not have to worry that the deploy engineer is asleep. Otherwise people would sit around for 12 to 24 hours for something. It's been really cool to see people moving much faster."

    - -

    With a relatively small engineering team—just 25 people, and only a handful working on infrastructure, with the majority front-end developers—Buffer needed "something robust for them to deploy whatever they wanted," says Farrelly. Before, "it was only a couple of people who knew how to set up everything in the old way. With this system, it was easy to review documentation and get something out extremely quickly. It lowers the bar for us to get everything in production. We don't have the big team to build all these tools or manage the infrastructure like other larger companies might."

    - -{{< case-studies/quote image="/images/case-studies/buffer/banner4.jpg" >}} -"In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it's out the door." -{{< /case-studies/quote >}} - -

    To help with this, Buffer developers wrote a deploy bot that wraps the Kubernetes deploy process and can be used by every team. "Before, our data analysts would update, say, a Python analysis script and have to wait for the lead on that team to click the button and deploy it," Farrelly explains. "Now our data analysts can make a change, enter a Slack command, '/deploy,' and it goes out instantly. They don't need to wait on these slow turnaround times. They don't even know where it's running; it doesn't matter."

    - -

    One of the first applications the team built from scratch using Kubernetes was a new image resizing service. As a social media management tool that allows marketing teams to collaborate on posts and send updates across multiple social media profiles and networks, Buffer has to be able to resize photographs as needed to meet the varying limitations of size and format posed by different social networks. "We always had these hacked together solutions," says Farrelly.

    - -

    To create this new service, one of the senior product engineers was assigned to learn Docker and Kubernetes, then build the service, test it, deploy it and monitor it—which he was able to do relatively quickly. "In our old way of working, the feedback loop was a lot longer, and it was delicate because if you deployed something, the risk was high to potentially break something else," Farrelly says. "With the kind of deploys that we built around Kubernetes, we were able to detect bugs and fix them, and get them deployed super fast. The second someone is fixing [a bug], it's out the door."

    - -

    Plus, unlike with their old system, they could scale things horizontally with one command. "As we rolled it out," Farrelly says, "we could anticipate and just click a button. This allowed us to deal with the demand that our users were placing on the system and easily scale it to handle it."

    - -

    Another thing they weren't able to do before was a canary deploy. This new capability "made us so much more confident in deploying big changes," says Farrelly. "Before, it took a lot of testing, which is still good, but it was also a lot of 'fingers crossed.' And this is something that gets run 800,000 times a day, the core of our business. If it doesn't work, our business doesn't work. In a Kubernetes world, I can do a canary deploy to test it for 1 percent and I can shut it down very quickly if it isn't working. This has leveled up our ability to deploy and roll out new changes quickly while reducing risk."

    - -{{< case-studies/quote >}} -"If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We're a relatively small team that's actually running Kubernetes, and we've never run anything like it before. So it's more approachable than you might think. That's the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this way." -{{< /case-studies/quote >}} - -

    By October 2016, 54 percent of Buffer's traffic was going through their Kubernetes cluster. "There's a lot of our legacy functionality that still runs alright, and those parts might move to Kubernetes or stay in our old setup forever," says Farrelly. But the company made the commitment at that time that going forward, "all new development, all new features, will be running on Kubernetes."

    - -

    The plan for 2017 is to move all the legacy applications to a new Kubernetes cluster, and run everything they've pulled out of their old infrastructure, plus the new services they're developing in Kubernetes, on another cluster. "I want to bring all the benefits that we've seen on our early services to everyone on the team," says Farrelly.

    - -{{< case-studies/lead >}} -For Buffer's engineers, it's an exciting process. "Every time we're deploying a new service, we need to figure out: OK, what's the architecture? How do these services communicate? What's the best way to build this service?" Farrelly says. "And then we use the different features that Kubernetes has to glue all the pieces together. It's enabling us to experiment as we're learning how to design a service-oriented architecture. Before, we just wouldn't have been able to do it. This is actually giving us a blank white board so we can do whatever we want on it." -{{< /case-studies/lead >}} - -

    Part of that blank slate is the flexibility that Kubernetes offers should the time come when Buffer may want or need to change its cloud. "It's cloud agnostic so maybe one day we could switch to Google or somewhere else," Farrelly says. "We're very deep in Amazon but it's nice to know we could move away if we need to."

    - -

    At this point, the team at Buffer can't imagine running their infrastructure any other way—and they're happy to spread the word. "If you want to run containers in production, with nearly the power that Google uses internally, this [Kubernetes] is a great way to do that," Farrelly says. "We're a relatively small team that's actually running Kubernetes, and we've never run anything like it before. So it's more approachable than you might think. That's the one big thing that I tell people who are experimenting with it. Pick a couple of things, roll it out, kick the tires on this for a couple of months and see how much it can handle. You start learning a lot this way."

    diff --git a/content/ko/case-studies/capital-one/capitalone_featured_logo.png b/content/ko/case-studies/capital-one/capitalone_featured_logo.png deleted file mode 100644 index f57c7697e3..0000000000 Binary files a/content/ko/case-studies/capital-one/capitalone_featured_logo.png and /dev/null differ diff --git a/content/ko/case-studies/capital-one/index.html b/content/ko/case-studies/capital-one/index.html deleted file mode 100644 index 7474b71b10..0000000000 --- a/content/ko/case-studies/capital-one/index.html +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: Capital One Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/capitalone/banner1.jpg -heading_title_logo: /images/capitalone-logo.png -subheading: > - Supporting Fast Decisioning Applications with Kubernetes -case_study_details: - - Company: Capital One - - Location: McLean, Virginia - - Industry: Retail banking ---- - -

    Challenge

    - -

    The team set out to build a provisioning platform for Capital One applications deployed on AWS that use streaming, big-data decisioning, and machine learning. One of these applications handles millions of transactions a day; some deal with critical functions like fraud detection and credit decisioning. The key considerations: resilience and speed—as well as full rehydration of the cluster from base AMIs.

    - -

    Solution

    - -

    The decision to run Kubernetes "is very strategic for us," says John Swift, Senior Director Software Engineering. "We use Kubernetes as a substrate or an operating system, if you will. There's a degree of affinity in our product development."

    - -

    Impact

    - -

    "Kubernetes is a significant productivity multiplier," says Lead Software Engineer Keith Gasser, adding that to run the platform without Kubernetes would "easily see our costs triple, quadruple what they are now for the amount of pure AWS expense." Time to market has been improved as well: "Now, a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer." Deployments increased by several orders of magnitude. Plus, the rehydration/cluster-rebuild process, which took a significant part of a day to do manually, now takes a couple hours with Kubernetes automation and declarative configuration.

    - -{{< case-studies/quote author="Jamil Jadallah, Scrum Master" >}} - -
    -"With the scalability, the management, the coordination, Kubernetes really empowers us and gives us more time back than we had before." -{{< /case-studies/quote >}} - -

    As a top 10 U.S. retail bank, Capital One has applications that handle millions of transactions a day. Big-data decisioning—for fraud detection, credit approvals and beyond—is core to the business. To support the teams that build applications with those functions for the bank, the cloud team led by Senior Director Software Engineering John Swift embraced Kubernetes for its provisioning platform. "Kubernetes and its entire ecosystem are very strategic for us," says Swift. "We use Kubernetes as a substrate or an operating system, if you will. There's a degree of affinity in our product development."

    - -

    Almost two years ago, the team embarked on this journey by first working with Docker. Then came Kubernetes. "We wanted to put streaming services into Kubernetes as one feature of the workloads for fast decisioning, and to be able to do batch alongside it," says Lead Software Engineer Keith Gasser. "Once the data is streamed and batched, there are so many tool sets in Flink that we use for decisioning. We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled."

    - -{{< case-studies/quote image="/images/case-studies/capitalone/banner3.jpg" >}} -"We want to provide the tools in the same ecosystem, in a consistent way, rather than have a large custom snowflake ecosystem where every tool needs its own custom deployment. Kubernetes gives us the ability to bring all of these together, so the richness of the open source and even the license community dealing with big data can be corralled." -{{< /case-studies/quote >}} - -

    In this first year, the impact has already been great. "Time to market is really huge for us," says Gasser. "Especially with fraud, you have to be very nimble in the way you respond to threats in the marketplace—being able to add and push new rules, detect new patterns of behavior, detect anomalies in account and transaction flows." With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier."

    - -

    Teams now have the tools to be autonomous in their deployments, and as a result, deployments have increased by two orders of magnitude. "And that was with just seven dedicated resources, without needing a whole group sitting there watching everything," says Scrum Master Jamil Jadallah. "That's a huge cost savings. With the scalability, the management, the coordination, Kubernetes really empowers us and gives us more time back than we had before."

    - -{{< case-studies/quote image="/images/case-studies/capitalone/banner4.jpg" >}} -With Kubernetes, "a team can come to us and we can have them up and running with a basic decisioning app in a fortnight, which before would have taken a whole quarter, if not longer. Kubernetes is a manifold productivity multiplier." -{{< /case-studies/quote >}} - -

    Kubernetes has also been a great time-saver for Capital One's required period "rehydration" of clusters from base AMIs. To minimize the attack vulnerability profile for applications in the cloud, "Our entire clusters get rebuilt from scratch periodically, with new fresh instances and virtual server images that are patched with the latest and greatest security patches," says Gasser. This process used to take the better part of a day, and personnel, to do manually. It's now a quick Kubernetes job.

    - -

    Savings extend to both capital and operating expenses. "It takes very little to get into Kubernetes because it's all open source," Gasser points out. "We went the DIY route for building our cluster, and we definitely like the flexibility of being able to embrace the latest from the community immediately without waiting for a downstream company to do it. There's capex related to those licenses that we don't have to pay for. Moreover, there's capex savings for us from some of the proprietary software that we get to sunset in our particular domain. So that goes onto our ledger in a positive way as well." (Some of those open source technologies include Prometheus, Fluentd, gRPC, Istio, CNI, and Envoy.)

    - -{{< case-studies/quote >}} -"If we had to do all of this without Kubernetes, on underlying cloud services, I could easily see our costs triple, quadruple what they are now for the amount of pure AWS expense. That doesn't account for personnel to deploy and maintain all the additional infrastructure." -{{< /case-studies/quote >}} - -

    And on the opex side, Gasser says, the savings are high. "We run dozens of services, we have scores of pods, many daemon sets, and since we're data-driven, we take advantage of EBS-backed volume claims for all of our stateful services. If we had to do all of this without Kubernetes, on underlying cloud services, I could easily see our costs triple, quadruple what they are now for the amount of pure AWS expense. That doesn't account for personnel to deploy and maintain all the additional infrastructure."

    - -

    The team is confident that the benefits will continue to multiply—without a steep learning curve for the engineers being exposed to the new technology. "As we onboard additional tenants in this ecosystem, I think the need for folks to understand Kubernetes may not necessarily go up. In fact, I think it goes down, and that's good," says Gasser. "Because that really demonstrates the scalability of the technology. You start to reap the benefits, and they can concentrate on all the features they need to build for great decisioning in the business— fraud decisions, credit decisions—and not have to worry about, 'Is my AWS server broken? Is my pod not running?'"

    diff --git a/content/ko/case-studies/crowdfire/crowdfire_featured_logo.png b/content/ko/case-studies/crowdfire/crowdfire_featured_logo.png deleted file mode 100644 index ef84b16ea0..0000000000 Binary files a/content/ko/case-studies/crowdfire/crowdfire_featured_logo.png and /dev/null differ diff --git a/content/ko/case-studies/crowdfire/index.html b/content/ko/case-studies/crowdfire/index.html deleted file mode 100644 index 98caae2830..0000000000 --- a/content/ko/case-studies/crowdfire/index.html +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: Crowdfire Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/crowdfire/banner1.jpg -heading_title_logo: /images/crowdfire_logo.png -subheading: > - How to Keep Iterating a Fast-Growing App With a Cloud-Native Approach -case_study_details: - - Company: Crowdfire - - Location: Mumbai, India - - Industry: Social Media Software ---- - -

    Challenge

    - -

    Crowdfire helps content creators create their content anywhere on the Internet and publish it everywhere else in the right format. Since its launch in 2010, it has grown to 16 million users. The product began as a monolith app running on Google App Engine, and in 2015, the company began a transformation to microservices running on Amazon Web Services Elastic Beanstalk. "It was okay for our use cases initially, but as the number of services, development teams and scale increased, the deploy times, self-healing capabilities and resource utilization started to become problems for us," says Software Engineer Amanpreet Singh, who leads the infrastructure team for Crowdfire.

    - -

    Solution

    - -

    "We realized that we needed a more cloud-native approach to deal with these issues," says Singh. The team decided to implement a custom setup of Kubernetes based on Terraform and Ansible.

    - -

    Impact

    - -

    "Kubernetes has helped us reduce the deployment time from 15 minutes to less than a minute," says Singh. "Due to Kubernetes's self-healing nature, the operations team doesn't need to do any manual intervention in case of a node or pod failure." Plus, he says, "Dev-Prod parity has improved since developers can experiment with options in dev/staging clusters, and when it's finalized, they just commit the config changes in the respective code repositories. These changes automatically get replicated on the production cluster via CI/CD pipelines."

    - -{{< case-studies/quote author="Amanpreet Singh, Software Engineer at Crowdfire" >}} -"In the 15 months that we've been using Kubernetes, it has been amazing for us. It enabled us to iterate quickly, increase development speed, and continuously deliver new features and bug fixes to our users, while keeping our operational costs and infrastructure management overhead under control." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -"If you build it, they will come." -{{< /case-studies/lead >}} - -

    For most content creators, only half of that movie quote may ring true. Sure, platforms like Wordpress, YouTube and Shopify have made it simple for almost anyone to start publishing new content online, but attracting an audience isn't as easy. Crowdfire "helps users publish their content to all possible places where their audience exists," says Amanpreet Singh, a Software Engineer at the company based in Mumbai, India. Crowdfire has gained more than 16 million users—from bloggers and artists to makers and small businesses—since its launch in 2010.

    - -

    With that kind of growth—and a high demand from users for new features and continuous improvements—the Crowdfire team struggled to keep up behind the scenes. In 2015, they moved their monolith Java application to Amazon Web Services Elastic Beanstalk and started breaking it down into microservices.

    - -

    It was a good first step, but the team soon realized they needed to go further down the cloud-native path, which would lead them to Kubernetes. "It was okay for our use cases initially, but as the number of services and development teams increased and we scaled further, deploy times, self-healing capabilities and resource utilization started to become problematic," says Singh, who leads the infrastructure team at Crowdfire. "We realized that we needed a more cloud-native approach to deal with these issues."

    - -

    As he looked around for solutions, Singh had a checklist of what Crowdfire needed. "We wanted to keep some things separate so they could be shipped independent of other things; this would help remove blockers and let different teams work at their own pace," he says. "We also make a lot of data-driven decisions, so shipping a feature and its iterations quickly was a must."

    - -

    Kubernetes checked all the boxes and then some. "One of the best things was the built-in service discovery," he says. "When you have a bunch of microservices that need to call each other, having internal DNS readily available and service IPs and ports automatically set as environment variables help a lot." Plus, he adds, "Kubernetes's opinionated approach made it easier to get started."

    - -{{< case-studies/quote image="/images/case-studies/crowdfire/banner3.jpg" >}} -"We realized that we needed a more cloud-native approach to deal with these issues," says Singh. The team decided to implement a custom setup of Kubernetes based on Terraform and Ansible." -{{< /case-studies/quote >}} - -

    There was another compelling business reason for the cloud-native approach. "In today's world of ever-changing business requirements, using cloud native technology provides a variety of options to choose from—even the ability to run services in a hybrid cloud environment," says Singh. "Businesses can keep services in a region closest to the users, and thus benefit from high-availability and resiliency."

    - -

    So in February 2016, Singh set up a test Kubernetes cluster using the kube-up scripts provided. "I explored the features and was able to deploy an application pretty easily," he says. "However, it seemed like a black box since I didn't understand the components completely, and had no idea what the kube-up script did under the hood. So when it broke, it was hard to find the issue and fix it."

    - -

    To get a better understanding, Singh dove into the internals of Kubernetes, reading the docs and even some of the code. And he looked to the Kubernetes community for more insight. "I used to stay up a little late every night (a lot of users were active only when it's night here in India) and would try to answer questions on the Kubernetes community Slack from users who were getting started," he says. "I would also follow other conversations closely. I must admit I was able to avoid a lot of issues in our setup because I knew others had faced the same issues."

    - -

    Based on the knowledge he gained, Singh decided to implement a custom setup of Kubernetes based on Terraform and Ansible. "I wrote Terraform to launch Kubernetes master and nodes (Auto Scaling Groups) and an Ansible playbook to install the required components," he says. (The company recently switched to using prebaked AMIs to make the node bringup faster, and is planning to change its networking layer.)

    - -{{< case-studies/quote image="/images/case-studies/crowdfire/banner4.jpg" >}} -"Kubernetes helped us reduce the deployment time from 15 minutes to less than a minute. Due to Kubernetes's self-healing nature, the operations team doesn't need to do any manual intervention in case of a node or pod failure." -{{< /case-studies/quote >}} - -

    First, the team migrated a few staging services from Elastic Beanstalk to the new Kubernetes staging cluster, and then set up a production cluster a month later to deploy some services. The results were convincing. "By the end of March 2016, we established that all the new services must be deployed on Kubernetes," says Singh. "Kubernetes helped us reduce the deployment time from 15 minutes to less than a minute. Due to Kubernetes's self-healing nature, the operations team doesn't need to do any manual intervention in case of a node or pod failure." On top of that, he says, "Dev-Prod parity has improved since developers can experiment with options in dev/staging clusters, and when it's finalized, they just commit the config changes in the respective code repositories. These changes automatically get replicated on the production cluster via CI/CD pipelines. This brings more visibility into the changes being made, and keeping an audit trail."

    - -

    Over the next six months, the team worked on migrating all the services from Elastic Beanstalk to Kubernetes, except for the few that were deprecated and would soon be terminated anyway. The services were moved one at a time, and their performance was monitored for two to three days each. Today, "We're completely migrated and we run all new services on Kubernetes," says Singh.

    - -

    The impact has been considerable: With Kubernetes, the company has experienced a 90% cost savings on Elastic Load Balancer, which is now only used for their public, user-facing services. Their EC2 operating expenses have been decreased by as much as 50%.

    - -

    All 30 engineers at Crowdfire were onboarded at once. "I gave an internal talk where I shared the basic components and demoed the usage of kubectl," says Singh. "Everyone was excited and happy about using Kubernetes. Developers have more control and visibility into their applications running in production now. Most of all, they're happy with the low deploy times and self-healing services."

    - -

    And they're much more productive, too. "Where we used to do about 5 deployments per day," says Singh, "now we're doing 30+ production and 50+ staging deployments almost every day."

    - -{{< case-studies/quote >}} -The impact has been considerable: With Kubernetes, the company has experienced a 90% cost savings on Elastic Load Balancer, which is now only used for their public, user-facing services. Their EC2 operating expenses have been decreased by as much as 50%. -{{< /case-studies/quote >}} - -

    Singh notes that almost all of the engineers interact with the staging cluster on a daily basis, and that has created a cultural change at Crowdfire. "Developers are more aware of the cloud infrastructure now," he says. "They've started following cloud best practices like better health checks, structured logs to stdout [standard output], and config via files or environment variables."

    - -

    With Crowdfire's commitment to Kubernetes, Singh is looking to expand the company's cloud-native stack. The team already uses Prometheus for monitoring, and he says he is evaluating Linkerd and Envoy Proxy as a way to "get more metrics about request latencies and failures, and handle them better." Other CNCF projects, including OpenTracing and gRPC are also on his radar.

    - -

    Singh has found that the cloud-native community is growing in India, too, particularly in Bangalore. "A lot of startups and new companies are starting to run their infrastructure on Kubernetes," he says.

    - -

    And when people ask him about Crowdfire's experience, he has this advice to offer: "Kubernetes is a great piece of technology, but it might not be right for you, especially if you have just one or two services or your app isn't easy to run in a containerized environment," he says. "Assess your situation and the value that Kubernetes provides before going all in. If you do decide to use Kubernetes, make sure you understand the components that run under the hood and what role they play in smoothly running the cluster. Another thing to consider is if your apps are 'Kubernetes-ready,' meaning if they have proper health checks and handle termination signals to shut down gracefully."

    - -

    And if your company fits that profile, go for it. Crowdfire clearly did—and is now reaping the benefits. "In the 15 months that we've been using Kubernetes, it has been amazing for us," says Singh. "It enabled us to iterate quickly, increase development speed and continuously deliver new features and bug fixes to our users, while keeping our operational costs and infrastructure management overhead under control."

    diff --git a/content/ko/case-studies/golfnow/golfnow_featured.png b/content/ko/case-studies/golfnow/golfnow_featured.png deleted file mode 100644 index 0b99ac3b8f..0000000000 Binary files a/content/ko/case-studies/golfnow/golfnow_featured.png and /dev/null differ diff --git a/content/ko/case-studies/golfnow/golfnow_logo.png b/content/ko/case-studies/golfnow/golfnow_logo.png deleted file mode 100644 index dbeb127b02..0000000000 Binary files a/content/ko/case-studies/golfnow/golfnow_logo.png and /dev/null differ diff --git a/content/ko/case-studies/golfnow/index.html b/content/ko/case-studies/golfnow/index.html deleted file mode 100644 index 9e82d90cd1..0000000000 --- a/content/ko/case-studies/golfnow/index.html +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: GolfNow Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/golfnow/banner1.jpg -heading_title_logo: /images/golfnow_logo.png -subheading: > - Saving Time and Money with Cloud Native Infrastructure -case_study_details: - - Company: GolfNow - - Location: Orlando, Florida - - Industry: Golf Industry Technology and Services Provider ---- - -

    Challenge

    - -

    A member of the NBC Sports Group, GolfNow is the golf industry's technology and services leader, managing 10 different products, as well as the largest e-commerce tee time marketplace in the world. As its business began expanding rapidly and globally, GolfNow's monolithic application became problematic. "We kept growing our infrastructure vertically rather than horizontally, and the cost of doing business became problematic," says Sheriff Mohamed, GolfNow's Director, Architecture. "We wanted the ability to more easily expand globally."

    - -

    Solution

    - -

    Turning to microservices and containerization, GolfNow began moving its applications and databases from third-party services to its own clusters running on Docker and Kubernetes.

    - -

    Impact

    - -

    The results were immediate. While maintaining the same capacity—and beyond, during peak periods—GolfNow saw its infrastructure costs for the first application virtually cut in half.

    - -{{< case-studies/quote author="SHERIFF MOHAMED, DIRECTOR, ARCHITECTURE AT GOLFNOW" >}} -"With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally. We were basically wasting money and doubling the cost of our infrastructure." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -It's not every day that you can say you've slashed an operating expense by half. -{{< /case-studies/lead >}} - -

    But Sheriff Mohamed and Josh Chandler did just that when they helped lead their company, GolfNow, on a journey from a monolithic to a containerized, cloud native infrastructure managed by Kubernetes.

    - -

    A top-performing business within the NBC Sports Group, GolfNow is a technology and services company with the largest tee time marketplace in the world. GolfNow serves 5 million active golfers across 10 different products. In recent years, the business had grown so fast that the infrastructure supporting their giant monolithic application (written in C#.NET and backed by SQL Server database management system) could not keep up. "With our growth we obviously needed to expand our infrastructure, and we kept growing vertically rather than horizontally," says Sheriff, GolfNow's Director, Architecture. "Our costs were growing exponentially. And on top of that, we had to build a Disaster Recovery (DR) environment, which then meant we'd have to copy exactly what we had in our original data center to another data center that was just the standby. We were basically wasting money and doubling the cost of our infrastructure."

    - -

    In moving just the first of GolfNow's important applications—a booking engine for golf courses and B2B marketing platform—from third-party services to their own Kubernetes environment, "our bill went down drastically," says Sheriff.

    - -

    The path to those stellar results began in late 2014. In order to support GolfNow's global growth, the team decided that the company needed to have multiple data centers and the ability to quickly and easily re-route traffic as needed. "From there we knew that we needed to go in a direction of breaking things apart, microservices, and containerization," says Sheriff. "At the time we were trying to get away from C#.NET and SQL Server since it didn't run very well on Linux, where everything container was running smoothly."

    - -

    To that end, the team shifted to working with Node.js, the open-source, cross-platform JavaScript runtime environment for developing tools and applications, and MongoDB, the open-source database program. At the time, Docker, the platform for deploying applications in containers, was still new. But once the team began experimenting with it, Sheriff says, "we realized that was the way we wanted to go, especially since that's the way the industry is heading."

    - -{{< case-studies/quote image="/images/case-studies/golfnow/banner3.jpg" >}} -"The team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, 'Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn't have to pay extra money at all.'" -{{< /case-studies/quote >}} - -

    GolfNow's dev team ran an "internal, low-key" proof of concept and were won over. "We really liked how easy it was to be able to pass containers around to each other and have them up and running in no time, exactly the way it was running on my machine," says Sheriff. "Because that is always the biggest gripe that Ops has with developers, right? 'It worked on my machine!' But then we started getting to the point of, 'How do we make sure that these things stay up and running?'"

    - -

    That led the team on a quest to find the right orchestration system for the company's needs. Sheriff says the first few options they tried were either too heavy or "didn't feel quite right." In late summer 2015, they discovered the just-released Kubernetes, which Sheriff immediately liked for its ease of use. "We did another proof of concept," he says, "and Kubernetes won because of the fact that the community backing was there, built on top of what Google had already done."

    - -

    But before they could go with Kubernetes, NBC, GolfNow's parent company, also asked them to comparison shop with another company. Sheriff and his team liked the competing company's platform user interface, but didn't like that its platform would not allow containers to run natively on Docker. With no clear decision in sight, Sheriff's VP at GolfNow, Steve McElwee, set up a three-month trial during which a GolfNow team (consisting of Sheriff and Josh, who's now Lead Architect, Open Platforms) would build out a Kubernetes environment, and a large NBC team would build out one with the other company's platform.

    - -

    "We spun up the cluster and we tried to get everything to run the way we wanted it to run," Sheriff says. "The biggest thing that we took away from it is that not only did we want our applications to run within Kubernetes and Docker, we also wanted our databases to run there. We literally wanted our entire infrastructure to run within Kubernetes."

    - -

    At the time there was nothing in the community to help them get Kafka and MongoDB clusters running within a Kubernetes and Docker environment, so Sheriff and Josh figured it out on their own, taking a full month to get it right. "Everything started rolling from there," Sheriff says. "We were able to get all our applications connected, and we finished our side of the proof of concept a month in advance. My VP was like, 'Alright, it's over. Kubernetes wins.'"

    - -

    The next step, beginning in January 2016, was getting everything working in production. The team focused first on one application that was already written in Node.js and MongoDB. A booking engine for golf courses and B2B marketing platform, the application was already going in the microservice direction but wasn't quite finished yet. At the time, it was running in Heroku Compose and other third-party services—resulting in a large monthly bill.

    - -{{< case-studies/quote image="/images/case-studies/golfnow/banner4.jpg" >}} -"'The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven't come from the Kubernetes world you wouldn't believe me.' Sheriff puts it in these terms: 'Before Kubernetes I wasn't sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I've been sleeping at night.'" -{{< /case-studies/quote >}} - -

    "The goal was to take all of that out and put it within this new platform we've created with Kubernetes on Google Compute Engine (GCE)," says Sheriff. "So we ended up building piece by piece, in parallel, what was out in Heroku and Compose, in our Kubernetes cluster. Then, literally, just switched configs in the background. So in Heroku we had the app running hitting a Compose database. We'd take the config, change it and make it hit the database that was running in our cluster."

    - -

    Using this procedure, they were able to migrate piecemeal, without any downtime. The first migration was done during off hours, but to test the limits, the team migrated the second database in the middle of the day, when lots of users were running the application. "We did it," Sheriff says, "and again it was successful. Nobody noticed."

    - -

    After three weeks of monitoring to make sure everything was running stable, the team migrated the rest of the application into their Kubernetes cluster. And the impact was immediate: On top of cutting monthly costs by a large percentage, says Sheriff, "Running at the same capacity and during our peak time, we were able to horizontally grow. Since we were using our VMs more efficiently with containers, we didn't have to pay extra money at all."

    - -

    Not only were they saving money, but they were also saving time. "I had a meeting this morning about migrating some applications from one cluster to another," says Josh. "I spent about 2 hours explaining the process. The time I spent actually moving the applications was under 30 seconds! We can move data centers in just incredible amounts of time. If you haven't come from the Kubernetes world you wouldn't believe me." Sheriff puts it in these terms: "Before Kubernetes I wasn't sleeping at night, literally. I was woken up all the time, because things were down. After Kubernetes, I've been sleeping at night."

    - -

    A small percentage of the applications on GolfNow have been migrated over to the Kubernetes environment. "Our Core Team is rewriting a lot of the .NET applications into .NET Core [which is compatible with Linux and Docker] so that we can run them within containers," says Sheriff.

    - -

    Looking ahead, Sheriff and his team want to spend 2017 continuing to build a whole platform around Kubernetes with Drone, an open-source continuous delivery platform, to make it more developer-centric. "Now they're able to manage configuration, they're able to manage their deployments and things like that, making all these subteams that are now creating all these microservices, be self sufficient," he says. "So it can pull us away from applications and allow us to just make sure the cluster is running and healthy, and then actually migrate that over to our Ops team."

    - -{{< case-studies/quote >}} -"Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. 'This is The Six Million Dollar Man of the cloud right now,' adds Josh. 'Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They're faster, they're more resilient.'" -{{< /case-studies/quote >}} - -

    And long-term, Sheriff has an even bigger goal for getting more people into the Kubernetes fold. "We're actually trying to make this platform generic enough so that any of our sister companies can use it if they wish," he says. "Most definitely I think it can be used as a model. I think the way we migrated into it, the way we built it out, are all ways that I think other companies can learn from, and should not be afraid of."

    - -

    The GolfNow team is also giving back to the Kubernetes community by open-sourcing a bot framework that Josh built. "We noticed that the dashboard user interface is actually moving a lot faster than when we started," says Sheriff. "However we realized what we needed was something that's more of a bot that really helps us administer Kubernetes as a whole through Slack." Josh explains: "With the Kubernetes-Slack integration, you can essentially hook into a cluster and the issue commands and edit configurations. We've tried to simplify the security configuration as much as possible. We hope this will be our major thank you to Kubernetes, for everything you've given us."

    - -

    Having gone from complete newbies to production-ready in three months, the GolfNow team is eager to encourage other companies to follow their lead. The lessons they've learned: "You've got to have buy-in from your boss," says Sheriff. "Another big deal is having two to three people dedicated to this type of endeavor. You can't have people who are half in, half out." And if you don't have buy-in from the get go, proving it out will get you there.

    - -

    "This is The Six Million Dollar Man of the cloud right now," adds Josh. "Just try it out, watch it happen. I feel like the proof is in the pudding when you look at these kinds of application stacks. They're faster, they're more resilient."

    diff --git a/content/ko/case-studies/haufegroup/haufegroup_featured.png b/content/ko/case-studies/haufegroup/haufegroup_featured.png deleted file mode 100644 index 08b09ec9db..0000000000 Binary files a/content/ko/case-studies/haufegroup/haufegroup_featured.png and /dev/null differ diff --git a/content/ko/case-studies/haufegroup/haufegroup_logo.png b/content/ko/case-studies/haufegroup/haufegroup_logo.png deleted file mode 100644 index 5d8245b0f6..0000000000 Binary files a/content/ko/case-studies/haufegroup/haufegroup_logo.png and /dev/null differ diff --git a/content/ko/case-studies/haufegroup/index.html b/content/ko/case-studies/haufegroup/index.html deleted file mode 100644 index 580a282683..0000000000 --- a/content/ko/case-studies/haufegroup/index.html +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: Haufe Group Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/haufegroup/banner1.jpg -heading_title_logo: /images/haufegroup_logo.png -subheading: > - Paving the Way for Cloud Native for Midsize Companies -case_study_details: - - Company: Haufe Group - - Location: Freiburg, Germany - - Industry: Media and Software ---- - -

    Challenge

    - -

    Founded in 1930 as a traditional publisher, Haufe Group has grown into a media and software company with 95 percent of its sales from digital products. Over the years, the company has gone from having "hardware in the basement" to outsourcing its infrastructure operations and IT. More recently, the development of new products, from Internet portals for tax experts to personnel training software, has created demands for increased speed, reliability and scalability. "We need to be able to move faster," says Solution Architect Martin Danielsson. "Adapting workloads is something that we really want to be able to do."

    - -

    Solution

    -

    Haufe Group began its cloud-native journey when Microsoft Azure became available in Europe; the company needed cloud deployments for its desktop apps with bandwidth-heavy download services. "After that, it has been different projects trying out different things," says Danielsson. Two years ago, Holger Reinhardt joined Haufe Group as CTO and rapidly re-oriented the traditional host provider-based approach toward a cloud and API-first strategy.

    - -

    A core part of this strategy was a strong mandate to embrace infrastructure-as-code across the entire software deployment lifecycle via Docker. The company is now getting ready to go live with two services in production using Kubernetes orchestration on Microsoft Azure and Amazon Web Services. The team is also working on breaking up one of their core Java Enterprise desktop products into microservices to allow for better evolvability and dynamic scaling in the cloud.

    - -

    Impact

    -

    With the ability to adapt workloads, Danielsson says, teams "will be able to scale down to around half the capacity at night, saving 30 percent of the hardware cost." Plus, shorter release times have had a major impact. "Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," he says. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days."

    - -{{< case-studies/quote author="Martin Danielsson, Solution Architect, Haufe Group" >}} -"Over the next couple of years, people won't even think that much about it when they want to run containers. Kubernetes is going to be the go-to solution." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -More than 80 years ago, Haufe Group was founded as a traditional publishing company, printing books and commentary on paper. -{{< /case-studies/lead >}} - -

    By the 1990s, though, the company's leaders recognized that the future was digital, and to their credit, were able to transform Haufe Group into a media and software business that now gets 95 percent of its sales from digital products. "Among the German companies doing this, we were one of the early adopters," says Martin Danielsson, Solution Architect for Haufe Group.

    - -

    And now they're leading the way for midsize companies embracing cloud-native technology like Kubernetes. "The really big companies like Ticketmaster and Google get it right, and the startups get it right because they're faster," says Danielsson. "We're in this big lump of companies in the middle with a lot of legacy, a lot of structure, a lot of culture that does not easily fit the cloud technologies. We're just 1,500 people, but we have hundreds of customer-facing applications. So we're doing things that will be relevant for many companies of our size or even smaller."

    - -

    Many of those legacy challenges stemmed from simply following the technology trends of the times. "We used to do full DevOps," he says. In the 1990s and 2000s, "that meant that you had your hardware in the basement. And then 10 years ago, the hype of the moment was to outsource application operations, outsource everything, and strip down your IT department to take away the distraction of all these hardware things. That's not our area of expertise. We didn't want to be an infrastructure provider. And now comes the backlash of that."

    - -

    Haufe Group began feeling the pain as they were developing more new products, from Internet portals for tax experts to personnel training software, that have created demands for increased speed, reliability and scalability. "Right now, we have this break in workflows, where we go from writing concepts to developing, handing it over to production and then handing that over to your host provider," he says. "And then when things go bad we have no clue what went wrong. We definitely want to take back control, and we want to move a lot faster. Adapting workloads is something that we really want to be able to do."

    - -

    Those needs led them to explore cloud-native technology. Their first foray into the cloud was doing deployments in Microsoft Azure, once it became available in Europe, for desktop products that had built-in download services. Hosting expenses for such bandwidth-heavy services were too high, so the company turned to the cloud. "After that, it has been different projects trying out different things," says Danielsson.

    - -{{< case-studies/quote image="/images/case-studies/haufegroup/banner3.jpg" >}} -"We have been doing containers for the last two years, and we really got the hang of how they work," says Danielsson. "But it was always for development and test, never in production, because we didn't fully understand how that would work. And to me, Kubernetes was definitely the technology that solved that." -{{< /case-studies/quote >}} - -

    Two years ago, Holger Reinhardt joined Haufe Group as CTO and rapidly re-oriented the traditional host provider-based approach toward a cloud and API-first strategy. A core part of this strategy was a strong mandate to embrace infrastructure-as-code across the entire software deployment lifecycle via Docker. Some experiments went further than others; German regulations about sensitive data proved to be a road block in moving some workloads to Azure and Amazon Web Services. "Due to our history, Germany is really strict with things like personally identifiable data," Danielsson says.

    - -

    These experiments took on new life with the arrival of the Azure Sovereign Cloud for Germany (an Azure clone run by the German T-Systems provider). With the availability of Azure.de—which conforms to Germany's privacy regulations—teams started to seriously consider deploying production loads in Docker into the cloud. "We have been doing containers for the last two years, and we really got the hang of how they work," says Danielsson. "But it was always for development and test, never in production, because we didn't fully understand how that would work. And to me, Kubernetes was definitely the technology that solved that."

    - -

    In parallel, Danielsson had built an API management system with the aim of supporting CI/CD scenarios, aspects of which were missing in off-the-shelf API management products. With a foundation based on Mashape's Kong gateway, it is open-sourced as wicked.haufe.io. He put wicked.haufe.io to use with his product team.

    Otherwise, Danielsson says his philosophy was "don't try to reinvent the wheel all the time. Go for what's there and 99 percent of the time it will be enough. And if you think you really need something custom or additional, think perhaps once or twice again. One of the things that I find so amazing with this cloud-native framework is that everything ties in."

    - -

    Currently, Haufe Group is working on two projects using Kubernetes in production. One is a new mobile application for researching legislation and tax laws. "We needed a way to take out functionality from a legacy core and put an application on top of that with an API gateway—a lot of moving parts that screams containers," says Danielsson. So the team moved the build pipeline away from "deploying to some old, huge machine that you could deploy anything to" and onto a Kubernetes cluster where there would be automatic CI/CD "with feature branches and all these things that were a bit tedious in the past."

    - -{{< case-studies/quote image="/images/case-studies/haufegroup/banner4.jpg" >}} -"Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," says Danielsson. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days." -{{< /case-studies/quote >}} - -

    It was a proof of concept effort, and the proof was in the pudding. "Everyone was really impressed at what we accomplished in a week," says Danielsson. "We did these kinds of integrations just to make sure that we got a handle on how Kubernetes works. If you can create optimism and buzz around something, it's half won. And if the developers and project managers know this is working, you're more or less done." Adds Reinhardt: "You need to create some very visible, quick wins in order to overcome the status quo."

    - -

    The impact on the speed of deployment was clear: "Before, we had to announce at least a week in advance when we wanted to do a release because there was a huge checklist of things that you had to do," says Danielsson. "By going cloud native, we have the infrastructure in place to be able to automate all of these things. Now we can get a new release done in half an hour instead of days."

    - -

    The potential impact on cost was another bonus. "Hosting applications is quite expensive, so moving to the cloud is something that we really want to be able to do," says Danielsson. With the ability to adapt workloads, teams "will be able to scale down to around half the capacity at night, saving 30 percent of the hardware cost."

    - -

    Just as importantly, Danielsson says, there's added flexibility: "When we try to move or rework applications that are really crucial, it's often tricky to validate whether the path we want to take is going to work out well. In order to validate that, we would need to reproduce the environment and really do testing, and that's prohibitively expensive and simply not doable with traditional host providers. Cloud native gives us the ability to do risky changes and validate them in a cost-effective way."

    - -

    As word of the two successful test projects spread throughout the company, interest in Kubernetes has grown. "We want to be able to support our developers in running Kubernetes clusters but we're not there yet, so we allow them to do it as long as they're aware that they are on their own," says Danielsson. "So that's why we are also looking at things like [the managed Kubernetes platform] CoreOS Tectonic, Azure Container Service, ECS, etc. These kinds of services will be a lot more relevant to midsize companies that want to leverage cloud native but don't have the IT departments or the structure around that."

    - -

    In the next year and a half, Danielsson says the company will be working on moving one of their legacy desktop products, a web app for researching legislation and tax laws originally built in Java Enterprise, onto cloud-native technology. "We're doing a microservice split out right now so that we can independently deploy the different parts," he says. The main website, which provides free content for customers, is also moving to cloud native.

    - -{{< case-studies/quote >}} -"the execution of a strategy requires alignment of culture, structure and technology. Only if those three dimensions are aligned can you successfully execute a transformation into microservices and cloud-native architectures. And it is only then that the Cloud will pay the dividends in much faster speeds in product innovation and much lower operational costs." -{{< /case-studies/quote >}} - -

    But with these goals, Danielsson believes there are bigger cultural challenges that need to be constantly addressed. The move to new technology, not to mention a shift toward DevOps, means a lot of change for employees. "The roles were rather fixed in the past," he says. "You had developers, you had project leads, you had testers. And now you get into these really, really important things like test automation. Testers aren't actually doing click testing anymore, and they have to write automated testing. And if you really want to go full-blown CI/CD, all these little pieces have to work together so that you get the confidence to do a check in, and know this check in is going to land in production, because if I messed up, some test is going to break. This is a really powerful thing because whatever you do, whenever you merge something into the trunk or to the master, this is going live. And that's where you either get the people or they run away screaming." Danielsson understands that it may take some people much longer to get used to the new ways.

    - -

    "Culture is nothing that you can force on people," he says. "You have to live it for yourself. You have to evangelize. You have to show the advantages time and time again: This is how you can do it, this is what you get from it." To that end, his team has scheduled daylong workshops for the staff, bringing in outside experts to talk about everything from API to Devops to cloud.

    - -

    For every person who runs away screaming, many others get drawn in. "Get that foot in the door and make them really interested in this stuff," says Danielsson. "Usually it catches on. We have people you never would have expected chanting, 'Docker Docker Docker' now. It's cool to see them realize that there is a world outside of their Python libraries. It's awesome to see them really work with Kubernetes."

    - -

    Ultimately, Reinhardt says, "the execution of a strategy requires alignment of culture, structure and technology. Only if those three dimensions are aligned can you successfully execute a transformation into microservices and cloud-native architectures. And it is only then that the Cloud will pay the dividends in much faster speeds in product innovation and much lower operational costs."

    diff --git a/content/ko/case-studies/huawei/huawei_featured.png b/content/ko/case-studies/huawei/huawei_featured.png deleted file mode 100644 index 22071b4691..0000000000 Binary files a/content/ko/case-studies/huawei/huawei_featured.png and /dev/null differ diff --git a/content/ko/case-studies/huawei/huawei_logo.png b/content/ko/case-studies/huawei/huawei_logo.png deleted file mode 100644 index 94361a27eb..0000000000 Binary files a/content/ko/case-studies/huawei/huawei_logo.png and /dev/null differ diff --git a/content/ko/case-studies/huawei/index.html b/content/ko/case-studies/huawei/index.html deleted file mode 100644 index ec1cd212f2..0000000000 --- a/content/ko/case-studies/huawei/index.html +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Huawei Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/huawei/banner1.jpg -heading_title_logo: /images/huawei_logo.png -subheading: > - Embracing Cloud Native as a User – and a Vendor -case_study_details: - - Company: Huawei - - Location: Shenzhen, China - - Industry: Telecommunications Equipment ---- - -

    Challenge

    - -

    A multinational company that's the largest telecommunications equipment manufacturer in the world, Huawei has more than 180,000 employees. In order to support its fast business development around the globe, Huawei has eight data centers for its internal I.T. department, which have been running 800+ applications in 100K+ VMs to serve these 180,000 users. With the rapid increase of new applications, the cost and efficiency of management and deployment of VM-based apps all became critical challenges for business agility. "It's very much a distributed system so we found that managing all of the tasks in a more consistent way is always a challenge," says Peixin Hou, the company's Chief Software Architect and Community Director for Open Source. "We wanted to move into a more agile and decent practice."

    - -

    Solution

    - -

    After deciding to use container technology, Huawei began moving the internal I.T. department's applications to run on Kubernetes. So far, about 30 percent of these applications have been transferred to cloud native.

    - -

    Impact

    - -

    "By the end of 2016, Huawei's internal I.T. department managed more than 4,000 nodes with tens of thousands containers using a Kubernetes-based Platform as a Service (PaaS) solution," says Hou. "The global deployment cycles decreased from a week to minutes, and the efficiency of application delivery has been improved 10 fold." For the bottom line, he says, "We also see significant operating expense spending cut, in some circumstances 20-30 percent, which we think is very helpful for our business." Given the results Huawei has had internally – and the demand it is seeing externally – the company has also built the technologies into FusionStage™, the PaaS solution it offers its customers.

    - -{{< case-studies/quote author="Peixin Hou, chief software architect and community director for open source" >}} -"If you're a vendor, in order to convince your customer, you should use it yourself. Luckily because Huawei has a lot of employees, we can demonstrate the scale of cloud we can build using this technology." -{{< /case-studies/quote >}} - -

    Huawei's Kubernetes journey began with one developer. Over two years ago, one of the engineers employed by the networking and telecommunications giant became interested in Kubernetes, the technology for managing application containers across clusters of hosts, and started contributing to its open source community. As the technology developed and the community grew, he kept telling his managers about it.

    - -

    And as fate would have it, at the same time, Huawei was looking for a better orchestration system for its internal enterprise I.T. department, which supports every business flow processing. "We have more than 180,000 employees worldwide, and a complicated internal procedure, so probably every week this department needs to develop some new applications," says Peixin Hou, Huawei's Chief Software Architect and Community Director for Open Source. "Very often our I.T. departments need to launch tens of thousands of containers, with tasks running across thousands of nodes across the world. It's very much a distributed system, so we found that managing all of the tasks in a more consistent way is always a challenge."

    - -

    In the past, Huawei had used virtual machines to encapsulate applications, but "every time when we start a VM," Hou says, "whether because it's a new service or because it was a service that was shut down because of some abnormal node functioning, it takes a lot of time." Huawei turned to containerization, so the timing was right to try Kubernetes. It took a year to adopt that engineer's suggestion – the process "is not overnight," says Hou – but once in use, he says, "Kubernetes basically solved most of our problems. Before, the time of deployment took about a week, now it only takes minutes. The developers are happy. That department is also quite happy."

    - -

    Hou sees great benefits to the company that come with using this technology: "Kubernetes brings agility, scale-out capability, and DevOps practice to the cloud-based applications," he says. "It provides us with the ability to customize the scheduling architecture, which makes possible the affinity between container tasks that gives greater efficiency. It supports multiple container formats. It has extensive support for various container networking solutions and container storage."

    - -{{< case-studies/quote image="/images/case-studies/huawei/banner3.jpg" >}} -"Kubernetes basically solved most of our problems. Before, the time of deployment took about a week, now it only takes minutes. The developers are happy. That department is also quite happy." -{{< /case-studies/quote >}} - -

    And not least of all, there's an impact on the bottom line. Says Hou: "We also see significant operating expense spending cut in some circumstances 20-30 percent, which is very helpful for our business."

    - -

    Pleased with those initial results, and seeing a demand for cloud native technologies from its customers, Huawei doubled down on Kubernetes. In the spring of 2016, the company became not only a user but also a vendor.

    - -

    "We built the Kubernetes technologies into our solutions," says Hou, referring to Huawei's FusionStage™ PaaS offering. "Our customers, from very big telecommunications operators to banks, love the idea of cloud native. They like Kubernetes technology. But they need to spend a lot of time to decompose their applications to turn them into microservice architecture, and as a solution provider, we help them. We've started to work with some Chinese banks, and we see a lot of interest from our customers like China Mobile and Deutsche Telekom."

    - -

    "If you're just a user, you're just a user," adds Hou. "But if you're a vendor, in order to even convince your customers, you should use it yourself. Luckily because Huawei has a lot of employees, we can demonstrate the scale of cloud we can build using this technology. We provide customer wisdom." While Huawei has its own private cloud, many of its customers run cross-cloud applications using Huawei's solutions. It's a big selling point that most of the public cloud providers now support Kubernetes. "This makes the cross-cloud transition much easier than with other solutions," says Hou.

    - -{{< case-studies/quote image="/images/case-studies/huawei/banner4.jpg" >}} -"Our customers, from very big telecommunications operators to banks, love the idea of cloud native. They like Kubernetes technology. But they need to spend a lot of time to decompose their applications to turn them into microservice architecture, and as a solution provider, we help them." -{{< /case-studies/quote >}} - -

    Within Huawei itself, once his team completes the transition of the internal business procedure department to Kubernetes, Hou is looking to convince more departments to move over to the cloud native development cycle and practice. "We have a lot of software developers, so we will provide them with our platform as a service solution, our own product," he says. "We would like to see significant cuts in their iteration cycle."

    - -

    Having overseen the initial move to Kubernetes at Huawei, Hou has advice for other companies considering the technology: "When you start to design the architecture of your application, think about cloud native, think about microservice architecture from the beginning," he says. "I think you will benefit from that."

    - -

    But if you already have legacy applications, "start from some microservice-friendly part of those applications first, parts that are relatively easy to be decomposed into simpler pieces and are relatively lightweight," Hou says. "Don't think from day one that within how many days I want to move the whole architecture, or move everything into microservices. Don't put that as a kind of target. You should do it in a gradual manner. And I would say for legacy applications, not every piece would be suitable for microservice architecture. No need to force it."

    - -

    After all, as enthusiastic as Hou is about Kubernetes at Huawei, he estimates that "in the next 10 years, maybe 80 percent of the workload can be distributed, can be run on the cloud native environments. There's still 20 percent that's not, but it's fine. If we can make 80 percent of our workload really be cloud native, to have agility, it's a much better world at the end of the day."

    - -{{< case-studies/quote >}} -"In the next 10 years, maybe 80 percent of the workload can be distributed, can be run on the cloud native environments. There's still 20 percent that's not, but it's fine. If we can make 80 percent of our workload really be cloud native, to have agility, it's a much better world at the end of the day." -{{< /case-studies/quote >}} - -

    In the nearer future, Hou is looking forward to new features that are being developed around Kubernetes, not least of all the ones that Huawei is contributing to. Huawei engineers have worked on the federation feature (which puts multiple Kubernetes clusters in a single framework to be managed seamlessly), scheduling, container networking and storage, and a just-announced technology called Container Ops, which is a DevOps pipeline engine. "This will put every DevOps job into a container," he explains. "And then this container mechanism is running using Kubernetes, but is also used to test Kubernetes. With that mechanism, we can make the containerized DevOps jobs be created, shared and managed much more easily than before."

    - -

    Still, Hou sees this technology as only halfway to its full potential. First and foremost, he'd like to expand the scale it can orchestrate, which is important for supersized companies like Huawei – as well as some of its customers.

    - -

    Hou proudly notes that two years after that first Huawei engineer became a contributor to and evangelist for Kubernetes, Huawei is now a top contributor to the community. "We've learned that the more you contribute to the community," he says, "the more you get back."

    diff --git a/content/ko/case-studies/ibm/ibm_featured_logo.png b/content/ko/case-studies/ibm/ibm_featured_logo.png deleted file mode 100644 index adb07a8cdf..0000000000 Binary files a/content/ko/case-studies/ibm/ibm_featured_logo.png and /dev/null differ diff --git a/content/ko/case-studies/ibm/ibm_featured_logo.svg b/content/ko/case-studies/ibm/ibm_featured_logo.svg deleted file mode 100644 index 577d8e97d9..0000000000 --- a/content/ko/case-studies/ibm/ibm_featured_logo.svg +++ /dev/null @@ -1 +0,0 @@ -ibm_featured_logo \ No newline at end of file diff --git a/content/ko/case-studies/ibm/index.html b/content/ko/case-studies/ibm/index.html deleted file mode 100644 index aa3f108e1c..0000000000 --- a/content/ko/case-studies/ibm/index.html +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: IBM Case Study -linkTitle: IBM -case_study_styles: true -cid: caseStudies -logo: ibm_featured_logo.svg -featured: false - -new_case_study_styles: true -heading_background: /images/case-studies/ibm/banner1.jpg -heading_title_logo: /images/ibm_logo.png -subheading: > - Building an Image Trust Service on Kubernetes with Notary and TUF -case_study_details: - - Company: IBM - - Location: Armonk, New York - - Industry: Cloud Computing ---- - -

    Challenge

    - -

    IBM Cloud offers public, private, and hybrid cloud functionality across a diverse set of runtimes from its OpenWhisk-based function as a service (FaaS) offering, managed Kubernetes and containers, to Cloud Foundry platform as a service (PaaS). These runtimes are combined with the power of the company's enterprise technologies, such as MQ and DB2, its modern artificial intelligence (AI) Watson, and data analytics services. Users of IBM Cloud can exploit capabilities from more than 170 different cloud native services in its catalog, including capabilities such as IBM's Weather Company API and data services. In the later part of 2017, the IBM Cloud Container Registry team wanted to build out an image trust service.

    - -

    Solution

    - -

    The work on this new service culminated with its public availability in the IBM Cloud in February 2018. The image trust service, called Portieris, is fully based on the Cloud Native Computing Foundation (CNCF) open source project Notary, according to Michael Hough, a software developer with the IBM Cloud Container Registry team. Portieris is a Kubernetes admission controller for enforcing content trust. Users can create image security policies for each Kubernetes namespace, or at the cluster level, and enforce different levels of trust for different images. Portieris is a key part of IBM's trust story, since it makes it possible for users to consume the company's Notary offering from within their IKS clusters. The offering is that Notary server runs in IBM's cloud, and then Portieris runs inside the IKS cluster. This enables users to be able to have their IKS cluster verify that the image they're loading containers from contains exactly what they expect it to, and Portieris is what allows an IKS cluster to apply that verification.

    - -

    Impact

    - -

    IBM's intention in offering a managed Kubernetes container service and image registry is to provide a fully secure end-to-end platform for its enterprise customers. "Image signing is one key part of that offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem," Hough says. The company had not been offering image signing before, and Notary is the tool it used to implement that capability. "We had a multi-tenant Docker Registry with private image hosting," Hough says. "The Docker Registry uses hashes to ensure that image content is correct, and data is encrypted both in flight and at rest. But it does not provide any guarantees of who pushed an image. We used Notary to enable users to sign images in their private registry namespaces if they so choose."

    - -{{< case-studies/quote author="Michael Hough, a software developer with the IBM Container Registry team" >}} -"We see CNCF as a safe haven for cloud native open source, providing stability, longevity, and expected maintenance for member projects—no matter the originating vendor or project." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -Docker had already created the Notary project as an implementation of The Update Framework (TUF), and this implementation of TUF provided the capabilities for Docker Content Trust. -{{< /case-studies/lead >}} - -

    "After contribution to CNCF of both TUF and Notary, we perceived that it was becoming the de facto standard for image signing in the container ecosystem", says Michael Hough, a software developer with the IBM Cloud Container Registry team.

    - -

    The key reason for selecting Notary was that it was already compatible with the existing authentication stack IBM's container registry was using. So was the design of TUF, which does not require the registry team to have to enter the business of key management. Both of these were "attractive design decisions that confirmed our choice of Notary," he says.

    - -

    The introduction of Notary to implement image signing capability in IBM Cloud encourages increased security across IBM's cloud platform, "where we expect it will include both the signing of official IBM images as well as expected use by security-conscious enterprise customers," Hough says. "When combined with security policy implementations, we expect an increased use of deployment policies in CI/CD pipelines that allow for fine-grained control of service deployment based on image signers."

    - -

    The availability of image signing "is a huge benefit to security-conscious customers who require this level of image provenance and security," Hough says. "With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment."

    - -{{< case-studies/quote - image="/images/case-studies/ibm/banner3.jpg" - author="Michael Hough, a software developer with the IBM Cloud Container Registry team" ->}} -"Image signing is one key part of our Kubernetes container service offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem" -{{< /case-studies/quote >}} - -

    Now that the Notary-implemented service is generally available in IBM's public cloud as a component of its existing IBM Cloud Container Registry, it is deployed as a highly available service across five IBM Cloud regions. This high-availability deployment has three instances across two zones in each of the five regions, load balanced with failover support. "We have also deployed it with end-to-end TLS support through to our back-end IBM Cloudant persistence storage service," Hough says.

    - -

    The IBM team has created and open sourced a Kubernetes admission controller called Portieris, which uses Notary signing information combined with customer-defined security policies to control image deployment into their cluster. "We are hoping to drive adoption of Portieris through its use of our Notary offering," Hough says.

    - -

    IBM has been a key player in the creation and support of open source foundations, including CNCF. Todd Moore, IBM's vice president of Open Technology, is the current CNCF governing board chair and a number of IBMers are active across many of the CNCF member projects.

    - -{{< case-studies/quote - image="/images/case-studies/ibm/banner4.jpg" - author="Michael Hough, a software developer with the IBM Cloud Container Registry team" ->}} -"With our IBM Cloud Kubernetes as-a-service offering and the admission controller we have made available, it allows both IBM services as well as customers of the IBM public cloud to use security policies to control service deployment." -{{< /case-studies/quote >}} - -

    "Given that, we see CNCF as a safe haven for cloud native open source, providing stability, longevity, and expected maintenance for member projects—no matter the originating vendor or project," Hough says. Because the entire cloud native world is a fast-moving area with many competing vendors and solutions, "we see the CNCF model as an arbiter of openness and fair play across the ecosystem," he says.

    - -

    With both TUF and Notary as part of CNCF, IBM expects there to be standardization around these capabilities beyond just de facto standards for signing and provenance. IBM has determined to not simply consume Notary, but also to contribute to the open source project where applicable. "IBMers have contributed a CouchDB backend to support our use of IBM Cloudant as the persistent store; and are working on generalization of the pkcs11 provider, allowing support of other security hardware devices beyond Yubikey," Hough says.

    - -{{< case-studies/quote author="Michael Hough, a software developer with the IBM Cloud Container Registry team" >}} -"There are new projects addressing these challenges, including within CNCF. We will definitely be following these advancements with interest. We found the Notary community to be an active and friendly community open to changes, such as our addition of a CouchDB backend for persistent storage." -{{< /case-studies/quote >}} - -

    The company has used other CNCF projects containerd, Envoy, Prometheus, gRPC, and CNI, and is looking into SPIFFE and SPIRE as well for potential future use.

    - -

    What advice does Hough have for other companies that are looking to deploy Notary or a cloud native infrastructure?

    - -

    "While this is true for many areas of cloud native infrastructure software, we found that a high-availability, multi-region deployment of Notary requires a solid implementation to handle certificate management and rotation," he says. "There are new projects addressing these challenges, including within CNCF. We will definitely be following these advancements with interest. We found the Notary community to be an active and friendly community open to changes, such as our addition of a CouchDB backend for persistent storage."

    diff --git a/content/ko/case-studies/ing/index.html b/content/ko/case-studies/ing/index.html deleted file mode 100644 index 037ba9775d..0000000000 --- a/content/ko/case-studies/ing/index.html +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: ING Case Study -linkTitle: ING -case_study_styles: true -cid: caseStudies -weight: 50 -featured: true -quote: > - The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that's quite feasible to us. - -new_case_study_styles: true -heading_background: /images/case-studies/ing/banner1.jpg -heading_title_logo: /images/ing_logo.png -subheading: > - Driving Banking Innovation with Cloud Native -case_study_details: - - Company: ING - - Location: Amsterdam, Netherlands - - Industry: Finance ---- - -

    Challenge

    - -

    After undergoing an agile transformation, ING realized it needed a standardized platform to support the work their developers were doing. "Our DevOps teams got empowered to be autonomous," says Infrastructure Architect Thijs Ebbers. "It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with Docker, Docker Swarm, Kubernetes, Mesos. Well, it's not really useful for a company to have one hundred wheels, instead of one good wheel.

    - -

    Solution

    - -

    Using Kubernetes for container orchestration and Docker for containerization, the ING team began building an internal public cloud for its CI/CD pipeline and green-field applications. The pipeline, which has been built on Mesos Marathon, will be migrated onto Kubernetes. The bank-account management app Yolt in the U.K. (and soon France and Italy) market already is live hosted on a Kubernetes framework. At least two greenfield projects currently on the Kubernetes framework will be going into production later this year. By the end of 2018, the company plans to have converted a number of APIs used in the banking customer experience to cloud native APIs and host these on the Kubernetes-based platform.

    - -

    Impact

    - -

    "Cloud native technologies are helping our speed, from getting an application to test to acceptance to production," says Infrastructure Architect Onno Van der Voort. "If you walk around ING now, you see all these DevOps teams, doing stand-ups, demoing. They try to get new functionality out there really fast. We held a hackathon for one of our existing components and basically converted it to cloud native within 2.5 days, though of course the tail takes more time before code is fully production ready."

    - -{{< case-studies/quote author="Thijs Ebbers, Infrastructure Architect, ING">}} -"The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that's quite feasible to us." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -ING has long embraced innovation in banking, launching the internet-based ING Direct in 1997. -{{< /case-studies/lead >}} - -

    In that same spirit, the company underwent an agile transformation a few years ago. "Our DevOps teams got empowered to be autonomous," says Infrastructure Architect Thijs Ebbers. "It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with Docker, Docker Swarm, Kubernetes, Mesos. Well, it's not really useful for a company to have one hundred wheels, instead of one good wheel."

    - -

    Looking to standardize the deployment process within the company's strict security guidelines, the team looked at several solutions and found that in the past year, "Kubernetes won the container management framework wars," says Ebbers. "We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That's one of the reasons we got Kubernetes."

    - -

    They also embraced Docker to address a major pain point in ING's CI/CD pipeline. Before containerization, "Every development team had to order a VM, and it was quite a heavy delivery model for them," says Infrastructure Architect Onno Van der Voort. "Another use case for containerization is when the application travels through the pipeline, they fire up Docker containers to do test work against the applications and after they've done the work, the containers get killed again."

    - -{{< case-studies/quote - image="/images/case-studies/ing/banner3.jpg" - author="Thijs Ebbers, Infrastructure Architect, ING" ->}} -"We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That's one of the reasons we got Kubernetes." -{{< /case-studies/quote >}} - -

    Because of industry regulations, applications are only allowed to go through the pipeline, where compliance is enforced, rather than be deployed directly into a container. "We have to run the complete platform of services we need, many routing from different places," says Van der Voort. "We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It's complex." For that reason, ING has chosen to start on the OpenShift Origin Kubernetes distribution.

    - -

    Already, "cloud native technologies are helping our speed, from getting an application to test to acceptance to production," says Van der Voort. "If you walk around ING now, you see all these DevOps teams, doing stand-ups, demoing. They try to get new functionality out there really fast. We held a hackathon for one of our existing components and basically converted it to cloud native within 2.5 days, though of course the tail takes more time before code is fully production ready."

    - -

    The pipeline, which has been built on Mesos Marathon, will be migrated onto Kubernetes. Some legacy applications are also being rewritten as cloud native in order to run on the framework. At least two smaller greenfield projects built on Kubernetes will go into production this year. By the end of 2018, the company plans to have converted a number of APIs used in the banking customer experience to cloud native APIs and host these on the Kubernetes-based platform.

    - -{{< case-studies/quote - image="/images/case-studies/ing/banner4.jpg" - author="Onno Van der Voort, Infrastructure Architect, ING" ->}} -"We have to run the complete platform of services we need, many routing from different places. We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It's complex." -{{< /case-studies/quote >}} - -

    The team, however, doesn't see the bank's back-end systems going onto the Kubernetes platform. "Our philosophy is it only makes sense to move things to cloud if they are cloud native," says Van der Voort. "If you have traditional architecture, build traditional patterns, it doesn't hold any value to go to the cloud." Adds Cloud Platform Architect Alfonso Fernandez-Barandiaran: "ING has a strategy about where we will go, in order to improve our agility. So it's not about how cool this technology is, it's about finding the right technology and the right approach."

    - -

    The Kubernetes framework will be hosting some greenfield projects that are high priority for ING: applications the company is developing in response to PSD2, the European Commission directive requiring more innovative online and mobile payments that went into effect at the beginning of 2018. For example, a bank-account management app called Yolt, serving the U.K. market (and soon France and Italy), was built on a Kubernetes platform and has gone into production. ING is also developing blockchain-enabled applications that will live on the Kubernetes platform. "We've been contacted by a lot of development teams that have ideas with what they want to do with containers," says Ebbers.

    - -{{< case-studies/quote author="Alfonso Fernandez-Barandiaran, Cloud Platform Architect, ING" >}} -Even with the particular requirements that come in banking, ING has managed to take a lead in technology and innovation. "Every time we have constraints, we look for maybe a better way that we can use this technology." -{{< /case-studies/quote >}} - -

    Even with the particular requirements that come in banking, ING has managed to take a lead in technology and innovation. "Every time we have constraints, we look for maybe a better way that we can use this technology," says Fernandez-Barandiaran.

    - -

    The results, after all, are worth the effort. "The big cloud native promise to our business is the ability to go from idea to production within 48 hours," says Ebbers. "That would require all these projects to be mature. We are some years away from this, but that's quite feasible to us."

    diff --git a/content/ko/case-studies/ing/ing_featured_logo.png b/content/ko/case-studies/ing/ing_featured_logo.png deleted file mode 100644 index f6d4489715..0000000000 Binary files a/content/ko/case-studies/ing/ing_featured_logo.png and /dev/null differ diff --git a/content/ko/case-studies/naic/index.html b/content/ko/case-studies/naic/index.html deleted file mode 100644 index 89ef6cb8de..0000000000 --- a/content/ko/case-studies/naic/index.html +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: NAIC Case Study -linkTitle: NAIC -case_study_styles: true -cid: caseStudies -logo: naic_featured_logo.png -featured: false - -new_case_study_styles: true -heading_background: /images/case-studies/naic/banner1.jpg -heading_title_logo: /images/naic_logo.png -subheading: > - A Culture and Technology Transition Enabled by Kubernetes -case_study_details: - - Company: NAIC - - Location: Washington, DC - - Industry: Regulatory ---- - -

    Challenge

    - -

    The National Association of Insurance Commissioners (NAIC), the U.S. standard-setting and regulatory support organization, was looking for a way to deliver new services faster to provide more value for members and staff. It also needed greater agility to improve productivity internally.

    - -

    Solution

    - -

    Beginning in 2016, they started using Cloud Native Computing Foundation (CNCF) tools such as Prometheus. NAIC began hosting internal systems and development systems on Kubernetes at the beginning of 2018, as part of a broad move toward the public cloud. "Our culture and technology transition is a strategy embraced by our top leaders," says Dan Barker, Chief Enterprise Architect. "It has already proven successful by allowing us to accelerate our value pipeline by more than double while decreasing our costs by more than half. We are also seeing customer satisfaction increase as we add more and more applications to these new technologies."

    - -

    Impact

    - -

    Leveraging Kubernetes, "our development teams can create rapid prototypes far faster than they used to," Barker said. Applications running on Kubernetes are more resilient than those running in other environments. The deployment of open source solutions is helping influence company culture, as NAIC becomes a more open and transparent organization.

    - -

    "We completed a small prototype in two days that would have previously taken at least a month," Barker says. Resiliency is currently measured in how much downtime systems have. "They've basically had none, and the occasional issue is remedied in minutes," he says.

    - -{{< case-studies/quote author="Dan Barker, Chief Enterprise Architect, NAIC" >}} -"Our culture and technology transition is a strategy embraced by our top leaders. It has already proven successful by allowing us to accelerate our value pipeline by more than double while decreasing our costs by more than half. We are also seeing customer satisfaction increase as we add more and more applications to these new technologies." -{{< /case-studies/quote >}} - -

    NAIC—which was created and overseen by the chief insurance regulators from the 50 states, the District of Columbia and five U.S. territories—provides a means through which state insurance regulators establish standards and best practices, conduct peer reviews, and coordinate their regulatory oversight. Their staff supports these efforts and represents the collective views of regulators in the United States and internationally. NAIC members, together with the organization's central resources, form the national system of state-based insurance regulation in the United States.

    - -

    The organization has been using the cloud for years, and wanted to find more ways to quickly deliver new services that provide more value for members and staff. They looked to Kubernetes for a solution. Within NAIC, several groups are leveraging Kubernetes, one being the Platform Engineering Team. "The team building out these tools are not only deploying and operating Kubernetes, but they're also using them," Barker says. "In fact, we're using GitLab to deploy Kubernetes with a pipeline using kops. This team was created from developers, operators, and quality engineers from across the company, so their jobs have changed quite a bit."

    - -

    In addition, NAIC is onboarding teams to the new platform, and those teams have seen a lot of change in how they work and what they can do. "They now have more power in creating their own infrastructure and deploying their own applications," Barker says. They also use pipelines to facilitate their currently manual processes. NAIC has consumers who are using GitLab heavily, and they're starting to use Kubernetes to deploy simple applications that help their internal processes.

    - -{{< case-studies/quote - image="/images/case-studies/naic/banner3.jpg" - author="Dan Barker, Chief Enterprise Architect, NAIC" ->}} -"In our experience, vendor lock-in and tooling that is highly specific results in less resilient technology with fewer minds working to solve problems and grow the community." -{{< /case-studies/quote >}} - -

    "We needed greater agility to enable our own productivity internally," he says. "We decided it was right for us to move everything to the public cloud [Amazon Web Services] to help with that process and be able to access many of the native tools that allows us to move faster by not needing to build everything." -The NAIC also wanted to be cloud-agnostic, "and Kubernetes helps with this for our compute layer," Barker says. "Compute is pretty standard across the clouds, and now we can take advantage of any of them while getting all of the other features Kubernetes offers."

    - -

    The NAIC currently hosts internal systems and development systems on Kubernetes, and has already seen how impactful it can be. "Our development teams can create rapid prototypes in minutes instead of weeks," Barker says. "This recently happened with an internal tool that had no measurable wait time on the infrastructure. It was solely development bound. There is now a central shared resource that lives in AWS, which means it can grow as needed."

    - -

    The native integrations into Kubernetes at NAIC has made it easy to write code and have it running in minutes instead of weeks. Applications running on Kubernetes have also proven to be more resilient than those running in other environments. "We even have teams using this to create more internal tools to help with communication or automating some of their current tasks," Barker says.

    - -

    "We knew that Kubernetes had become the de facto standard for container orchestration," he says. "Two major factors for selecting this were the three major cloud vendors hosting their own versions and having it hosted in a neutral party as fully open source."

    - -

    As for other CNCF projects, NAIC is using Prometheus on a small scale and hopes to continue using it moving forward because of the seamless integration with Kubernetes. The Association also is considering gRPC as its internal communications standard, Envoy in conjunction with Istio for service mesh, OpenTracing and Jaeger for tracing aggregation, and Fluentd with its Elasticsearch cluster.

    - -{{< case-studies/quote - image="/images/case-studies/naic/banner4.jpg" - author="Dan Barker, Chief Enterprise Architect, NAIC" ->}} -"We knew that Kubernetes had become the de facto standard for container orchestration. Two major factors for selecting this were the three major cloud vendors hosting their own versions and having it hosted in a neutral party as fully open source." -{{< /case-studies/quote >}} - -

    The open governance and broad industry participation in CNCF provided a comfort level with the technology, Barker says. "We also see it as helping to influence our own company culture," he says. "We're moving to be a more open and transparent company, and we are encouraging our staff to get involved with the different working groups and codebases. We recently became CNCF members to help further our commitment to community contribution and transparency."

    - -

    Factors such as vendor-neutrality and cross-industry investment were important in the selection. "In our experience, vendor lock-in and tooling that is highly specific results in less resilient technology with fewer minds working to solve problems and grow the community," Barker says.

    - -

    NAIC is a largely Oracle shop, Barker says, and has been running mostly Java on JBoss. "However, we have years of history with other applications," he says. "Some of these have been migrated by completely rewriting the application, while others are just being modified slightly to fit into this new paradigm."

    - -

    Running on AWS cloud, the Association has not specifically taken a microservices approach. "We are moving to microservices where practical, but we haven't found that it's a necessity to operate them within Kubernetes," Barker says.

    - -

    All of its databases are currently running within public cloud services, but they have explored eventually running those in Kubernetes, as it makes sense. "We're doing this to get more reuse from common components and to limit our failure domains to something more manageable and observable," Barker says.

    - -{{< case-studies/quote author="Dan Barker, Chief Enterprise Architect, NAIC" >}} -"We have been able to move much faster at lower cost than we were able to in the past," Barker says. "We were able to complete one of our projects in a year, when the previous version took over two years. And the new project cost $500,000 while the original required $3 million, and with fewer defects. We are also able to push out new features much faster." -{{< /case-studies/quote >}} - -

    NAIC has seen a significant business impact from its efforts. "We have been able to move much faster at lower cost than we were able to in the past," Barker says. "We were able to complete one of our projects in a year, when the previous version took over two years. And the new project cost $500,000 while the original required $3 million, and with fewer defects. We are also able to push out new features much faster."

    - -

    He says the organization is moving toward continuous deployment "because the business case makes sense. The research is becoming very hard to argue with. We want to reduce our batch sizes and optimize on delivering value to customers and not feature count. This is requiring a larger cultural shift than just a technology shift."

    - -

    NAIC is "becoming more open and transparent, as well as more resilient to failure," Barker says. "Even our customers are wanting more and more of this and trying to figure out how they can work with us to accomplish our mutual goals faster. Members of the insurance industry have reached out so that we can better learn together and grow as an industry."

    diff --git a/content/ko/case-studies/naic/naic_featured_logo.png b/content/ko/case-studies/naic/naic_featured_logo.png deleted file mode 100644 index f2497114bf..0000000000 Binary files a/content/ko/case-studies/naic/naic_featured_logo.png and /dev/null differ diff --git a/content/ko/case-studies/newyorktimes/index.html b/content/ko/case-studies/newyorktimes/index.html deleted file mode 100644 index f79278e84c..0000000000 --- a/content/ko/case-studies/newyorktimes/index.html +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: New York Times Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/newyorktimes/banner1.jpg -heading_title_logo: /images/newyorktimes_logo.png -subheading: > - The New York Times: From Print to the Web to Cloud Native -case_study_details: - - Company: New York Times - - Location: New York, N.Y. - - Industry: News Media ---- - -

    Challenge

    - -

    When the company decided a few years ago to move out of its data centers, its first deployments on the public cloud were smaller, less critical applications managed on virtual machines. "We started building more and more tools, and at some point we realized that we were doing a disservice by treating Amazon as another data center," says Deep Kapadia, Executive Director, Engineering at The New York Times. Kapadia was tapped to lead a Delivery Engineering Team that would "design for the abstractions that cloud providers offer us."

    - -

    Solution

    - -

    The team decided to use Google Cloud Platform and its Kubernetes-as-a-service offering, GKE.

    - -

    Impact

    - -

    Speed of delivery increased. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes," says Engineering Manager Brian Balser. Adds Li: "Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary." Adopting Cloud Native Computing Foundation technologies allows for a more unified approach to deployment across the engineering staff, and portability for the company.

    - -{{< case-studies/quote author="Deep Kapadia, Executive Director, Engineering at The New York Times" >}} -{{< youtube DqS_IPw-c6o youtube-quote-sm >}} -{{< youtube Tm4VfJtOHt8 youtube-quote-sm >}} -
    -"I think once you get over the initial hump, things get a lot easier and actually a lot faster." -{{< /case-studies/quote >}} - -

    Founded in 1851 and known as the newspaper of record, The New York Times is a digital pioneer: Its first website launched in 1996, before Google even existed. After the company decided a few years ago to move out of its private data centers—including one located in the pricy real estate of Manhattan. It recently took another step into the future by going cloud native.

    - -

    At first, the infrastructure team "managed the virtual machines in the Amazon cloud, and they deployed more critical applications in our data centers and the less critical ones on AWS as an experiment," says Deep Kapadia, Executive Director, Engineering at The New York Times. "We started building more and more tools, and at some point we realized that we were doing a disservice by treating Amazon as another data center."

    - -

    To get the most out of the cloud, Kapadia was tapped to lead a new Delivery Engineering Team that would "design for the abstractions that cloud providers offer us." In mid-2016, they began looking at the Google Cloud Platform and its Kubernetes-as-a-service offering, GKE.

    - -

    At the time, says team member Tony Li, a Site Reliability Engineer, "We had some internal tooling that attempted to do what Kubernetes does for containers, but for VMs. We asked why are we building and maintaining these tools ourselves?"

    - -

    In early 2017, the first production application—the nytimes.com mobile homepage—began running on Kubernetes, serving just 1% of the traffic. Today, almost 100% of the nytimes.com site's end-user facing applications run on GCP, with the majority on Kubernetes.

    - -{{< case-studies/quote image="/images/case-studies/newyorktimes/banner3.jpg" >}} -"We had some internal tooling that attempted to do what Kubernetes does for containers, but for VMs. We asked why are we building and maintaining these tools ourselves?" -{{< /case-studies/quote >}} - -

    The team found that the speed of delivery was immediately impacted. "Deploying Docker images versus spinning up VMs was quite a lot faster," says Engineering Manager Brian Balser. Some of the legacy VM-based deployments took 45 minutes; with Kubernetes, that time was "just a few seconds to a couple of minutes."

    - -

    The plan is to get as much as possible, not just the website, running on Kubernetes, and beyond that, moving toward serverless deployments. For instance, The New York Times crossword app was built on Google App Engine, which has been the main platform for the company's experimentation with serverless. "The hardest part was getting the engineers over the hurdle of how little they had to do," Chief Technology Officer Nick Rockwell recently told The CTO Advisor. "Our experience has been very, very good. We have invested a lot of work into deploying apps on container services, and I'm really excited about experimenting with deploying those on App Engine Flex and AWS Fargate and seeing how that feels, because that's a great migration path."

    - -

    There are some exceptions to the move to cloud native, of course. "We have the print publishing business as well," says Kapadia. "A lot of that is definitely not going down the cloud-native path because they're using vendor software and even special machinery that prints the physical paper. But even those teams are looking at things like App Engine and Kubernetes if they can."

    - -

    Kapadia acknowledges that there was a steep learning curve for some engineers, but "I think once you get over the initial hump, things get a lot easier and actually a lot faster."

    - -{{< case-studies/quote image="/images/case-studies/newyorktimes/banner4.jpg" >}} -"Right now, every team is running a small Kubernetes cluster, but it would be nice if we could all live in a larger ecosystem," says Kapadia. "Then we can harness the power of things like service mesh proxies that can actually do a lot of instrumentation between microservices, or service-to-service orchestration. Those are the new things that we want to experiment with as we go forward." -{{< /case-studies/quote >}} - -

    At The New York Times, they did. As teams started sharing their own best practices with each other, "We're no longer the bottleneck for figuring out certain things," Kapadia says. "Most of the infrastructure and systems were managed by a centralized function. We've sort of blown that up, partly because Google and Amazon have tools that allow us to do that. We provide teams with complete ownership of their Google Cloud Platform projects, and give them a set of sensible defaults or standards. We let them know, 'If this works for you as is, great! If not, come talk to us and we'll figure out how to make it work for you.'"

    - -

    As a result, "It's really allowed teams to move at a much more rapid pace than they were able to in the past," says Kapadia. Adds Li: "The use of GKE means each team can get their own compute cluster, reducing the number of individual instances they have to care about since developers can treat the cluster as a whole. Because the ticket-based workflow was removed from requesting resources and connections, developers can just call an API to get what they want. Teams that used to deploy on weekly schedules or had to coordinate schedules with the infrastructure team now deploy their updates independently, and can do it daily when necessary."

    - -

    Another benefit to adopting Kubernetes: allowing for a more unified approach to deployment across the engineering staff. "Before, many teams were building their own tools for deployment," says Balser. With Kubernetes—as well as the other CNCF projects The New York Times uses, including Fluentd to collect logs for all of its AWS servers, gRPC for its Publishing Pipeline, Prometheus, and Envoy—"we can benefit from the advances that each of these technologies make, instead of trying to catch up."

    - -{{< case-studies/quote >}} -Li calls the Cloud Native Computing Foundation's projects "a northern star that we can all look at and follow." -{{< /case-studies/quote >}} - -

    These open-source technologies have given the company more portability. "CNCF has enabled us to follow an industry standard," says Kapadia. "It allows us to think about whether we want to move away from our current service providers. Most of our applications are connected to Fluentd. If we wish to switch our logging provider from provider A to provider B we can do that. We're running Kubernetes in GCP today, but if we want to run it in Amazon or Azure, we could potentially look into that as well."

    - -

    Li calls the Cloud Native Computing Foundation's projects "a northern star that we can all look at and follow." Led by that star, the team is looking ahead to a year of onboarding the remaining half of the 40 or so product engineering teams to extract even more value out of the technology. "Right now, every team is running a small Kubernetes cluster, but it would be nice if we could all live in a larger ecosystem," says Kapadia. "Then we can harness the power of things like service mesh proxies that can actually do a lot of instrumentation between microservices, or service-to-service orchestration. Those are the new things that we want to experiment with as we go forward."

    diff --git a/content/ko/case-studies/newyorktimes/newyorktimes_featured.png b/content/ko/case-studies/newyorktimes/newyorktimes_featured.png deleted file mode 100644 index fad0927883..0000000000 Binary files a/content/ko/case-studies/newyorktimes/newyorktimes_featured.png and /dev/null differ diff --git a/content/ko/case-studies/newyorktimes/newyorktimes_logo.png b/content/ko/case-studies/newyorktimes/newyorktimes_logo.png deleted file mode 100644 index 693a742c3e..0000000000 Binary files a/content/ko/case-studies/newyorktimes/newyorktimes_logo.png and /dev/null differ diff --git a/content/ko/case-studies/nordstrom/index.html b/content/ko/case-studies/nordstrom/index.html deleted file mode 100644 index 73bc4e147e..0000000000 --- a/content/ko/case-studies/nordstrom/index.html +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: Nordstrom Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/nordstrom/banner1.jpg -heading_title_logo: /images/nordstrom_logo.png -subheading: > - Finding Millions in Potential Savings in a Tough Retail Climate -case_study_details: - - Company: Nordstrom - - Location: Seattle, Washington - - Industry: Retail ---- - -

    Challenge

    - -

    Nordstrom wanted to increase the efficiency and speed of its technology operations, which includes the Nordstrom.com e-commerce site. At the same time, Nordstrom Technology was looking for ways to tighten its technology operational costs.

    - -

    Solution

    - -

    After embracing a DevOps transformation and launching a continuous integration/continuous deployment (CI/CD) project four years ago, the company reduced its deployment time from three months to 30 minutes. But they wanted to go even faster across environments, so they began their cloud native journey, adopting Docker containers orchestrated with Kubernetes.

    - -

    Impact

    - -

    Nordstrom Technology developers using Kubernetes now deploy faster and can "just focus on writing applications," says Dhawal Patel, a senior engineer on the team building a Kubernetes enterprise platform for Nordstrom. Furthermore, the team has increased Ops efficiency, improving CPU utilization from 5x to 12x depending on the workload. "We run thousands of virtual machines (VMs), but aren't effectively using all those resources," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at a 10x increase."

    - -{{< case-studies/quote author="Dhawal Patel, senior engineer at Nordstrom" >}} -"We are always looking for ways to optimize and provide more value through technology. With Kubernetes we are showcasing two types of efficiency that we can bring: Dev efficiency and Ops efficiency. It's a win-win." -{{< /case-studies/quote >}} - -

    When Dhawal Patel joined Nordstrom five years ago as an application developer for the retailer's website, he realized there was an opportunity to help speed up development cycles.

    - -

    In those early DevOps days, Nordstrom Technology still followed a traditional model of silo teams and functions. "As a developer, I was spending more time fixing environments than writing code and adding value to business," Patel says. "I was passionate about that—so I was given the opportunity to help fix it."

    - -

    The company was eager to move faster, too, and in 2013 launched the first continuous integration/continuous deployment (CI/CD) project. That project was the first step in Nordstrom's cloud native journey.

    - -

    Dev and Ops team members built a CI/CD pipeline, working with the company's servers on premise. The team chose Chef, and wrote cookbooks that automated virtual IP creation, servers, and load balancing. "After we completed the project, deployment went from three months to 30 minutes," says Patel. "We still had multiple environments—dev, test, staging, then production—so with each environment running the Chef cookbooks, it took 30 minutes. It was a huge achievement at that point."

    - -

    But new environments still took too long to turn up, so the next step was working in the cloud. Today, Nordstrom Technology has built an enterprise platform that allows the company's 1,500 developers to deploy applications running as Docker containers in the cloud, orchestrated with Kubernetes.

    - -{{< case-studies/quote image="/images/case-studies/nordstrom/banner3.jpg" >}} -"We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core," -{{< /case-studies/quote >}} - -

    "The cloud provided faster access to resources, because it took weeks for us to get a virtual machine (VM) on premises," says Patel. "But now we can do the same thing in only five minutes."

    - -

    Nordstrom's first foray into scheduling containers on a cluster was a homegrown system based on CoreOS fleet. They began doing a few proofs of concept projects with that system until Kubernetes 1.0 was released when they made the switch. "We made a bet that Kubernetes was going to take off, informed by early indicators of community support and project velocity, so we rebuilt our system with Kubernetes at the core," says Marius Grigoriu, Sr. Manager of the Kubernetes team at Nordstrom.

    - -

    While Kubernetes is often thought as a platform for microservices, the first application to launch on Kubernetes in a critical production role at Nordstrom was Jira. "It was not the ideal microservice we were hoping to get as our first application," Patel admits, "but the team that was working on it was really passionate about Docker and Kubernetes, and they wanted to try it out. They had their application running on premises, and wanted to move it to Kubernetes."

    - -

    The benefits were immediate for the teams that came on board. "Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn't need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with."

    - -{{< case-studies/quote image="/images/case-studies/nordstrom/banner4.jpg">}} -"Teams running on our Kubernetes cluster loved the fact that they had fewer issues to worry about. They didn't need to manage infrastructure or operating systems," says Grigoriu. "Early adopters loved the declarative nature of Kubernetes. They loved the reduced surface area they had to deal with." -{{< /case-studies/quote >}} - -

    To support these early adopters, Patel's team began growing the cluster and building production-grade services. "We integrated with Prometheus for monitoring, with a Grafana front end; we used Fluentd to push logs to Elasticsearch, so that gives us log aggregation," says Patel. The team also added dozens of open-source components, including CNCF projects and has made contributions to Kubernetes, Terraform, and kube2iam.

    - -

    There are now more than 60 development teams running Kubernetes in Nordstrom Technology, and as success stories have popped up, more teams have gotten on board. "Our initial customer base, the ones who were willing to try this out, are now going and evangelizing to the next set of users," says Patel. "One early adopter had Docker containers and he was not sure how to run it in production. We sat with him and within 15 minutes we deployed it in production. He thought it was amazing, and more people in his org started coming in."

    - -

    For Nordstrom Technology, going cloud-native has vastly improved development and operational efficiency. The developers using Kubernetes now deploy faster and can focus on building value in their applications. One such team started with a 25-minute merge to deploy by launching virtual machines in the cloud. Switching to Kubernetes was a 5x speedup in their process, improving their merge to deploy time to 5 minutes.

    - -{{< case-studies/quote >}} -"With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. we are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that's a huge reduction in operational overhead." -{{< /case-studies/quote >}} - -

    Speed is great, and easily demonstrated, but perhaps the bigger impact lies in the operational efficiency. "We run thousands of VMs on AWS, and their overall average CPU utilization is about four percent," says Patel. "With Kubernetes, without even trying to make our cluster efficient, we are currently at 40 percent CPU utilization—a 10x increase. We are running 2600+ customer pods that would have been 2600+ VMs if they had gone directly to the cloud. We are running them on 40 VMs now, so that's a huge reduction in operational overhead."

    - -

    Nordstrom Technology is also exploring running Kubernetes on bare metal on premises. "If we can build an on-premises Kubernetes cluster," says Patel, "we could bring the power of cloud to provision resources fast on-premises. Then for the developer, their interface is Kubernetes; they might not even realize or care that their services are now deployed on premises because they're only working with Kubernetes."

    - -

    For that reason, Patel is eagerly following Kubernetes' development of multi-cluster capabilities. "With cluster federation, we can have our on-premise as the primary cluster and the cloud as a secondary burstable cluster," he says. "So, when there is an anniversary sale or Black Friday sale, and we need more containers - we can go to the cloud."

    - -

    That kind of possibility—as well as the impact that Grigoriu and Patel's team has already delivered using Kubernetes—is what led Nordstrom on its cloud native journey in the first place. "The way the retail environment is today, we are trying to build responsiveness and flexibility where we can," says Grigoriu. "Kubernetes makes it easy to: bring efficiency to both the Dev and Ops side of the equation. It's a win-win."

    diff --git a/content/ko/case-studies/nordstrom/nordstrom_featured_logo.png b/content/ko/case-studies/nordstrom/nordstrom_featured_logo.png deleted file mode 100644 index a557ffa82f..0000000000 Binary files a/content/ko/case-studies/nordstrom/nordstrom_featured_logo.png and /dev/null differ diff --git a/content/ko/case-studies/northwestern-mutual/index.html b/content/ko/case-studies/northwestern-mutual/index.html deleted file mode 100644 index a25d25484c..0000000000 --- a/content/ko/case-studies/northwestern-mutual/index.html +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Northwestern Mutual Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/northwestern/banner1.jpg -heading_title_logo: /images/northwestern_logo.png -subheading: > - Cloud Native at Northwestern Mutual -case_study_details: - - Company: Northwestern Mutual - - Location: Milwaukee, WI - - Industry: Insurance and Financial Services ---- - -

    Challenge

    - -

    In the spring of 2015, Northwestern Mutual acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual's leading products and services and meld it with LearnVest's digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company's existing infrastructure had been optimized for batch workflows hosted on on-prem networks; deployments were very traditional, focused on following a process instead of providing deployment agility. "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website so our end-customers have the experience they expect," says Williams.

    - -

    Solution

    - -

    The platform team came up with a plan for using the public cloud (AWS), Docker containers, and Kubernetes for orchestration. "Kubernetes gave us that base framework so teams can be very autonomous in what they're building and deliver very quickly and frequently," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. The team also built and open-sourced Kanali, a Kubernetes-native API management tool that uses OpenTracing, Jaeger, and gRPC.

    - -

    Impact

    - -

    Before, infrastructure deployments could take weeks; now, it is done in a matter of minutes. The number of deployments has increased dramatically, from about 24 a year to over 500 in just the first 10 months of 2017. Availability has also increased: There used to be a six-hour control window for commits every Sunday morning, as well as other periods of general maintenance, during which outages could happen. "Now we have eliminated the planned outage windows," says Bryan Pfremmer, App Platform Teams Manager, Northwestern Mutual. Kanali has had an impact on the bottom line. The vendor API management product that the company previously used required 23 servers, "dedicated, to only API management," says Pfremmer. "Now it's all integrated in the existing stack and running as another deployment on Kubernetes. And that's just one environment. Between the three that we had plus the test, that's hard dollar savings."

    - -{{< case-studies/quote author="Frank Greco Jr., Cloud Native Engineer at Northwestern Mutual">}} -"In a large enterprise, you're going to have people using Kubernetes, but then you're also going to have people using WAS and .NET. You may not be at a point where your whole stack can be cloud native. What if you can take your API management tool and make it cloud native, but still proxy to legacy systems? Using different pieces that are cloud native, open source and Kubernetes native, you can do pretty innovative stuff." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -For more than 160 years, Northwestern Mutual has maintained its industry leadership in part by keeping a strong focus on risk management. -{{< /case-studies/lead >}} - -

    For many years, the company took a similar approach to managing its technology and has recently undergone a digital transformation to advance the company's digital strategy - including making a lot of noise in the cloud-native world.

    - -

    In the spring of 2015, this insurance and financial services company acquired a fintech startup, LearnVest, and decided to take "Northwestern Mutual's leading products and services and meld it with LearnVest's digital experience and innovative financial planning platform," says Brad Williams, Director of Engineering for Client Experience, Northwestern Mutual. The company's existing infrastructure had been optimized for batch workflows hosted on an on-premise datacenter; deployments were very traditional and had to many manual steps that were error prone.

    - -

    In order to give the company's 4.5 million clients the digital experience they'd come to expect, says Williams, "We had to build a platform that was elastically scalable, but also much more responsive, so we could quickly get data to the client website. We essentially said, 'You build the system that you think is necessary to support a new, modern-facing one.' That's why we departed from anything legacy."

    - -{{< case-studies/quote image="/images/case-studies/northwestern/banner3.jpg" >}} -"Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they're building and deliver very quickly and frequently." -{{< /case-studies/quote >}} - -

    Williams and the rest of the platform team decided that the first step would be to start moving from private data centers to AWS. With a new microservice architecture in mind—and the freedom to implement what was best for the organization—they began using Docker containers. After looking into the various container orchestration options, they went with Kubernetes, even though it was still in beta at the time. "There was some debate whether we should build something ourselves, or just leverage that product and evolve with it," says Northwestern Mutual Cloud Native Engineer Frank Greco Jr. "Kubernetes has definitely been the right choice for us. It gave us that base framework so teams can be autonomous in what they're building and deliver very quickly and frequently."

    - -

    As early adopters, the team had to do a lot of work with Ansible scripts to stand up the cluster. "We had a lot of hard security requirements given the nature of our business," explains Bryan Pfremmer, App Platform Teams Manager, Northwestern Mutual. "We found ourselves running a configuration that very few other people ever tried." The client experience group was the first to use the new platform; today, a few hundred of the company's 1,500 engineers are using it and more are eager to get on board.

    - -

    The results have been dramatic. Before, infrastructure deployments could take two weeks; now, it is done in a matter of minutes. Now with a focus on Infrastructure automation, and self-service, "You can take an app to production in that same day if you want to," says Pfremmer.

    - -{{< case-studies/quote image="/images/case-studies/northwestern/banner4.jpg" >}} -"Now, developers have autonomy, they can use this whenever they want, however they want. It becomes more valuable the more instrumentation downstream that happens, as we mature in it." -{{< /case-studies/quote >}} - -

    The process used to be so cumbersome that minor bug releases would be bundled with feature releases. With the new streamlined system enabled by Kubernetes, the number of deployments has increased from about 24 a year to more than 500 in just the first 10 months of 2017. Availability has also been improved: There used to be a six-hour control window for commits every early Sunday morning, as well as other periods of general maintenance, during which outages could happen. "Now there's no planned outage window," notes Pfremmer.

    - -

    Northwestern Mutual built that API management tool—called Kanali—and open sourced it in the summer of 2017. The team took on the project because it was a key capability for what they were building and prior the solution worked in an "anti-cloud native way that was different than everything else we were doing," says Greco. Now API management is just another container deployed to Kubernetes along with a separate Jaeger deployment.

    - -

    Now the engineers using the Kubernetes deployment platform have the added benefit of visibility in production—and autonomy. Before, a centralized team and would have to run a trace. "Now, developers have autonomy, they can use this whenever they want, however they want. It becomes more valuable the more instrumentation downstream that happens, as we mature in it." says Greco.

    - -{{< case-studies/quote >}} -"We're trying to make what we're doing known so that we can find people who are like, 'Yeah, that's interesting. I want to come do it!'" -{{< /case-studies/quote >}} - -

    But the team didn't stop there. "In a large enterprise, you're going to have people using Kubernetes, but then you're also going to have people using WAS and .NET," says Greco. "You may not be at a point where your whole stack can be cloud native. What if you can take your API management tool and make it cloud native, but still proxy to legacy systems? Using different pieces that are cloud native, open source and Kubernetes native, you can do pretty innovative stuff."

    - -

    As the team continues to improve its stack and share its Kubernetes best practices, it feels that Northwestern Mutual's reputation as a technology-first company is evolving too. "No one would think a company that's 160-plus years old is foraying this deep into the cloud and infrastructure stack," says Pfremmer. And they're hoping that means they'll be able to attract new talent. "We're trying to make what we're doing known so that we can find people who are like, 'Yeah, that's interesting. I want to come do it!'"

    diff --git a/content/ko/case-studies/northwestern-mutual/northwestern_featured_logo.png b/content/ko/case-studies/northwestern-mutual/northwestern_featured_logo.png deleted file mode 100644 index 7c1422f32b..0000000000 Binary files a/content/ko/case-studies/northwestern-mutual/northwestern_featured_logo.png and /dev/null differ diff --git a/content/ko/case-studies/ocado/index.html b/content/ko/case-studies/ocado/index.html deleted file mode 100644 index 59374f820e..0000000000 --- a/content/ko/case-studies/ocado/index.html +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: Ocado Case Study -linkTitle: Ocado -case_study_styles: true -cid: caseStudies -logo: ocado_featured_logo.png -featured: true -weight: 4 -quote: > - People at Ocado Technology have been quite amazed. They ask, 'Can we do this on a Dev cluster?' and 10 minutes later we have rolled out something that is deployed across the cluster. The speed from idea to implementation to deployment is amazing. - -new_case_study_styles: true -heading_background: /images/case-studies/ocado/banner1.jpg -heading_title_logo: /images/ocado_logo.png -subheading: > - Ocado: Running Grocery Warehouses with a Cloud Native Platform -case_study_details: - - Company: Ocado Technology - - Location: Hatfield, England - - Industry: Grocery retail technology and platforms ---- - -

    Challenge

    - -

    The world's largest online-only grocery retailer, Ocado developed the Ocado Smart Platform to manage its own operations, from websites to warehouses, and is now licensing the technology to other retailers such as Kroger. To set up the first warehouses for the platform, Ocado shifted from virtual machines and Puppet infrastructure to Docker containers, using CoreOS's fleet scheduler to provision all the services on its OpenStack-based private cloud on bare metal. As the Smart Platform grew and "fleet was going end-of-life," says Platform Engineer Mike Bryant, "we started looking for a more complete platform, with all of these disparate infrastructure services being brought together in one unified API."

    - -

    Solution

    - -

    The team decided to migrate from fleet to Kubernetes on Ocado's private cloud. The Kubernetes stack currently uses kubeadm for bootstrapping, CNI with Weave Net for networking, Prometheus Operator for monitoring, Fluentd for logging, and OpenTracing for distributed tracing. The first app on Kubernetes, a business-critical service in the warehouses, went into production in the summer of 2017, with a mass migration continuing into 2018. Hundreds of Ocado engineers working on the Smart Platform are now deploying on Kubernetes.

    - -

    Impact

    - -

    With Kubernetes, "the speed from idea to implementation to deployment is amazing," says Bryant. "I've seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month." And because there are no longer restrictive deployment windows in the warehouses, the rate of deployments has gone from as few as two per week to dozens per week. Ocado has also achieved cost savings because Kubernetes gives the team the ability to have more fine-grained resource allocation. Says DevOps Team Leader Kevin McCormack: "We have more confidence in the resource allocation/separation features of Kubernetes, so we have been able to migrate from around 10 fleet clusters to one Kubernetes cluster." The team also uses Prometheus and Grafana to visualize resource allocation, and makes the data available to developers. "The increased visibility offered by Prometheus means developers are more aware of what they are using and how their use impacts others, especially since we now have one shared cluster," says McCormack. "I'd estimate that we use about 15-25% less hardware resources to host the same applications in Kubernetes in our test environments."

    - -{{< case-studies/quote author="Mike Bryant, Platform Engineer, Ocado" >}} -"People at Ocado Technology have been quite amazed. They ask, 'Can we do this on a Dev cluster?' and 10 minutes later we have rolled out something that is deployed across the cluster. The speed from idea to implementation to deployment is amazing." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -When it was founded in 2000, Ocado was an online-only grocery retailer in the U.K. In the years since, it has expanded from delivering produce to families to providing technology to other grocery retailers. -{{< /case-studies/lead >}} - -

    The company began developing its Ocado Smart Platform to manage its own operations, from websites to warehouses, and is now licensing the technology to other grocery chains around the world, such as Kroger. To set up the first warehouses on the platform, Ocado shifted from virtual machines and Puppet infrastructure to Docker containers, using CoreOS's fleet scheduler to provision all the services on its OpenStack-based private cloud on bare metal. As the Smart Platform grew, and "fleet was going end-of-life," says Platform Engineer Mike Bryant, "we started looking for a more complete platform, with all of these disparate infrastructure services being brought together in one unified API."

    - -

    Bryant had already been using Kubernetes with Code for Life, a children's education project that's part of Ocado's charity arm. "We really liked it, so we started looking at it seriously for our production workloads," says Bryant. The team that managed fleet had researched orchestration solutions and landed on Kubernetes as well. "We were looking for a platform with wide adoption, and that was where the momentum was," says DevOps Team Leader Kevin McCormack. The two paths converged, and "We didn't even go through any proof-of-concept stage. The Code for Life work served that purpose," says Bryant.

    - -{{< case-studies/quote - image="/images/case-studies/ocado/banner3.jpg" - author="Kevin McCormack, DevOps Team Leader, Ocado" ->}} -"We were looking for a platform with wide adoption, and that was where the momentum was, the two paths converged, and we didn't even go through any proof-of-concept stage. The Code for Life work served that purpose," -{{< /case-studies/quote >}} - -

    In the summer of 2016, the team began migrating from fleet to Kubernetes on Ocado's private cloud. The Kubernetes stack currently uses kubeadm for bootstrapping, CNI with Weave Net for networking, Prometheus Operator for monitoring, Fluentd for logging, and OpenTracing for distributed tracing.

    - -

    The first app on Kubernetes, a business-critical service in the warehouses, went into production a year later. Once that app was running smoothly, a mass migration continued into 2018. Hundreds of Ocado engineers working on the Smart Platform are now deploying on Kubernetes, and the platform is live in Ocado's warehouses, managing tens of thousands of orders a week. At full capacity, Ocado's latest warehouse in Erith, southeast London, will deliver more than 200,000 orders per week, making it the world's largest facility for online grocery.

    - -

    There are about 150 microservices now running on Kubernetes, with multiple instances of many of them. "We're not just deploying all these microservices at once. We're deploying them all for one warehouse, and then they're all being deployed again for the next warehouse, and again and again," says Bryant.

    - -

    The move to Kubernetes was eye-opening for many people at Ocado Technology. "In the early days of putting the platform into our test infrastructure, the technical architect asked what network performance was like on Weave Net with encryption turned on," recalls Bryant. "So we found a Docker container for iPerf, wrote a daemon set, deployed it. A few moments later, we've deployed the entire thing across this cluster. He was pretty blown away by that."

    - -{{< case-studies/quote - image="/images/case-studies/ocado/banner4.jpg" - author="Mike Bryant, Platform Engineer, Ocado" ->}} -"The unified API of Kubernetes means this is all in one place, and it's one flow for approval and rollout. I've seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month." -{{< /case-studies/quote >}} - -

    Indeed, the impact has been profound. "Prior to containerization, we had quite restrictive deployment windows in our warehouses," says Bryant. "Moving to microservices, we've been able to deploy much more frequently. We've been able to move towards continuous delivery in a number of areas. In our older warehouse, new application deployments involve talking to a bunch of different teams for different levels of the stack: from VM provisioning, to storage, to load balancers, and so on. The unified API of Kubernetes means this is all in one place, and it's one flow for approval and rollout. I've seen features go from development to production inside of a week now. In the old world, a new application deployment could easily take over a month."

    - -

    The rate of deployment has gone from as few as two per week to dozens per week. "With Kubernetes, some of our development teams have been able to deploy their application to production on the new platform without us noticing," says Bryant, "which means they're faster at doing what they need to do and we have less work."

    - -

    Ocado has also achieved cost savings because Kubernetes gives the team the ability to have more fine-grained resource allocation. "That lets us shrink quite a lot of our deployments from being per-core VM deployments to having fractions of the core," says Bryant. Adds McCormack: "We have more confidence in the resource allocation/separation features of Kubernetes, so we have been able to migrate from around 10 fleet clusters to one Kubernetes cluster. This means we use our hardware better since if we have to always have two nodes of excess capacity available in case of node failures then we only need two extra instead of 20."

    - -{{< case-studies/quote author="Mike Bryant, Platform Engineer, Ocado" >}} -"CNCF have provided us with support of different technologies. We've been able to adopt those in a very easy fashion. We do like that CNCF is vendor agnostic. We're not being asked to commit to this one way of doing things. The vast diversity of viewpoints in CNCF lead to better technology." -{{< /case-studies/quote >}} - -

    The team also uses Prometheus and Grafana to visualize resource allocation, and makes the data available to developers. "The increased visibility offered by Prometheus means developers are more aware of what they are using and how their use impacts others, especially since we now have one shared cluster," says McCormack. "I'd estimate that we use about 15-25% less hardware resource to host the same applications in Kubernetes in our test environments."

    - -

    One of the broader benefits of cloud native, says Bryant, is the unified API. "We have one method of doing our deployments that covers the wide range of things we need to do, and we can extend the API," he says. In addition to using Prometheus Operator, the Ocado team has started writing its own operators, some of which have been open sourced. Plus, "CNCF has provided us with support of these different technologies. We've been able to adopt those in a very easy fashion. We do like that CNCF is vendor agnostic. We're not being asked to commit to this one way of doing things. The vast diversity of viewpoints in the CNCF leads to better technology."

    - -

    Ocado's own technology, in the form of its Smart Platform, will soon be used around the world. And cloud native plays a crucial role in this global expansion. "I wouldn't have wanted to try it without Kubernetes," says Bryant. "Kubernetes has made it so much nicer, especially to have that consistent way of deploying all of the applications, then taking the same thing and being able to replicate it. It's very valuable."

    diff --git a/content/ko/case-studies/ocado/ocado_featured_logo.png b/content/ko/case-studies/ocado/ocado_featured_logo.png deleted file mode 100644 index 0c2ef19ec3..0000000000 Binary files a/content/ko/case-studies/ocado/ocado_featured_logo.png and /dev/null differ diff --git a/content/ko/case-studies/openAI/index.html b/content/ko/case-studies/openAI/index.html deleted file mode 100644 index 543c1dee64..0000000000 --- a/content/ko/case-studies/openAI/index.html +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: OpenAI Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/openAI/banner1.jpg -heading_title_logo: /images/openAI_logo.png -subheading: > - Launching and Scaling Up Experiments, Made Simple -case_study_details: - - Company: OpenAI - - Location: San Francisco, California - - Industry: Artificial Intelligence Research ---- - -

    Challenge

    - -

    An artificial intelligence research lab, OpenAI needed infrastructure for deep learning that would allow experiments to be run either in the cloud or in its own data center, and to easily scale. Portability, speed, and cost were the main drivers.

    - -

    Solution

    - -

    OpenAI began running Kubernetes on top of AWS in 2016, and in early 2017 migrated to Azure. OpenAI runs key experiments in fields including robotics and gaming both in Azure and in its own data centers, depending on which cluster has free capacity. "We use Kubernetes mainly as a batch scheduling system and rely on our autoscaler to dynamically scale up and down our cluster," says Christopher Berner, Head of Infrastructure. "This lets us significantly reduce costs for idle nodes, while still providing low latency and rapid iteration."

    - -

    Impact

    - -

    The company has benefited from greater portability: "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters," says Berner. Being able to use its own data centers when appropriate is "lowering costs and providing us access to hardware that we wouldn't necessarily have access to in the cloud," he adds. "As long as the utilization is high, the costs are much lower there." Launching experiments also takes far less time: "One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days. In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work."

    - -{{< case-studies/quote >}} - -
    -Check out "Building the Infrastructure that Powers the Future of AI" presented by Vicki Cheung, Member of Technical Staff & Jonas Schneider, Member of Technical Staff at OpenAI from KubeCon/CloudNativeCon Europe 2017. -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -From experiments in robotics to old-school video game play research, OpenAI's work in artificial intelligence technology is meant to be shared. -{{< /case-studies/lead >}} - -

    With a mission to ensure powerful AI systems are safe, OpenAI cares deeply about open source—both benefiting from it and contributing safety technology into it. "The research that we do, we want to spread it as widely as possible so everyone can benefit," says OpenAI's Head of Infrastructure Christopher Berner. The lab's philosophy—as well as its particular needs—lent itself to embracing an open source, cloud native strategy for its deep learning infrastructure.

    - -

    OpenAI started running Kubernetes on top of AWS in 2016, and a year later, migrated the Kubernetes clusters to Azure. "We probably use Kubernetes differently from a lot of people," says Berner. "We use it for batch scheduling and as a workload manager for the cluster. It's a way of coordinating a large number of containers that are all connected together. We rely on our autoscaler to dynamically scale up and down our cluster. This lets us significantly reduce costs for idle nodes, while still providing low latency and rapid iteration."

    - -

    In the past year, Berner has overseen the launch of several Kubernetes clusters in OpenAI's own data centers. "We run them in a hybrid model where the control planes—the Kubernetes API servers, etcd and everything—are all in Azure, and then all of the Kubernetes nodes are in our own data center," says Berner. "The cloud is really convenient for managing etcd and all of the masters, and having backups and spinning up new nodes if anything breaks. This model allows us to take advantage of lower costs and have the availability of more specialized hardware in our own data center."

    - -{{< case-studies/quote image="/images/case-studies/openAI/banner3.jpg" >}} -OpenAI's experiments take advantage of Kubernetes' benefits, including portability. "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters..." -{{< /case-studies/quote >}} - -

    Different teams at OpenAI currently run a couple dozen projects. While the largest-scale workloads manage bare cloud VMs directly, most of OpenAI's experiments take advantage of Kubernetes' benefits, including portability. "Because Kubernetes provides a consistent API, we can move our research experiments very easily between clusters," says Berner. The on-prem clusters are generally "used for workloads where you need lots of GPUs, something like training an ImageNet model. Anything that's CPU heavy, that's run in the cloud. But we also have a number of teams that run their experiments both in Azure and in our own data centers, just depending on which cluster has free capacity, and that's hugely valuable."

    - -

    Berner has made the Kubernetes clusters available to all OpenAI teams to use if it's a good fit. "I've worked a lot with our games team, which at the moment is doing research on classic console games," he says. "They had been running a bunch of their experiments on our dev servers, and they had been trying out Google cloud, managing their own VMs. We got them to try out our first on-prem Kubernetes cluster, and that was really successful. They've now moved over completely to it, and it has allowed them to scale up their experiments by 10x, and do that without needing to invest significant engineering time to figure out how to manage more machines. A lot of people are now following the same path."

    - -{{< case-studies/quote image="/images/case-studies/openAI/banner4.jpg" >}} -"One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days," says Berner. "In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work." -{{< /case-studies/quote >}} - -

    That path has been simplified by frameworks and tools that two of OpenAI's teams have developed to handle interaction with Kubernetes. "You can just write some Python code, fill out a bit of configuration with exactly how many machines you need and which types, and then it will prepare all of those specifications and send it to the Kube cluster so that it gets launched there," says Berner. "And it also provides a bit of extra monitoring and better tooling that's designed specifically for these machine learning projects."

    - -

    The impact that Kubernetes has had at OpenAI is impressive. With Kubernetes, the frameworks and tooling, including the autoscaler, in place, launching experiments takes far less time. "One of our researchers who is working on a new distributed training system has been able to get his experiment running in two or three days," says Berner. "In a week or two he scaled it out to hundreds of GPUs. Previously, that would have easily been a couple of months of work."

    - -

    Plus, the flexibility they now have to use their on-prem Kubernetes cluster when appropriate is "lowering costs and providing us access to hardware that we wouldn't necessarily have access to in the cloud," he says. "As long as the utilization is high, the costs are much lower in our data center. To an extent, you can also customize your hardware to exactly what you need."

    - -{{< case-studies/quote author="CHRISTOPHER BERNER, HEAD OF INFRASTRUCTURE FOR OPENAI" >}} -"Research teams can now take advantage of the frameworks we've built on top of Kubernetes, which make it easy to launch experiments, scale them by 10x or 50x, and take little effort to manage." -{{< /case-studies/quote >}} - -

    OpenAI is also benefiting from other technologies in the CNCF cloud-native ecosystem. gRPC is used by many of its systems for communications between different services, and Prometheus is in place "as a debugging tool if things go wrong," says Berner. "We actually haven't had any real problems in our Kubernetes clusters recently, so I don't think anyone has looked at our Prometheus monitoring in a while. If something breaks, it will be there."

    - -

    One of the things Berner continues to focus on is Kubernetes' ability to scale, which is essential to deep learning experiments. OpenAI has been able to push one of its Kubernetes clusters on Azure up to more than 2,500 nodes. "I think we'll probably hit the 5,000-machine number that Kubernetes has been tested at before too long," says Berner, adding, "We're definitely hiring if you're excited about working on these things!"

    diff --git a/content/ko/case-studies/openAI/openai_featured.png b/content/ko/case-studies/openAI/openai_featured.png deleted file mode 100644 index b2b667c0bb..0000000000 Binary files a/content/ko/case-studies/openAI/openai_featured.png and /dev/null differ diff --git a/content/ko/case-studies/openAI/openai_logo.png b/content/ko/case-studies/openAI/openai_logo.png deleted file mode 100644 index a85a81ea06..0000000000 Binary files a/content/ko/case-studies/openAI/openai_logo.png and /dev/null differ diff --git a/content/ko/case-studies/peardeck/index.html b/content/ko/case-studies/peardeck/index.html deleted file mode 100644 index 4398277677..0000000000 --- a/content/ko/case-studies/peardeck/index.html +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Pear Deck Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/peardeck/banner3.jpg -heading_title_logo: /images/peardeck_logo.png -subheading: > - Infrastructure for a Growing EdTech Startup -case_study_details: - - Company: Pear Deck - - Location: Iowa City, Iowa - - Industry: Educational Software ---- - -

    Challenge

    - -

    The three-year-old startup provides a web app for teachers to interact with their students in the classroom. The JavaScript app was built on Google's web app development platform Firebase, using Heroku. As the user base steadily grew, so did the development team. "We outgrew Heroku when we started wanting to have multiple services, and the deploying story got pretty horrendous. We were frustrated that we couldn't have the developers quickly stage a version," says CEO Riley Eynon-Lynch. "Tracing and monitoring became basically impossible." On top of that, many of Pear Deck's customers are behind government firewalls and connect through Firebase, not Pear Deck's servers, making troubleshooting even more difficult.

    - -

    Solution

    - -

    In 2016, the company began moving their code from Heroku to Docker containers running on Google Kubernetes Engine, orchestrated by Kubernetes and monitored with Prometheus.

    - -

    Impact

    - -

    The new cloud native stack immediately improved the development workflow, speeding up deployments. Prometheus gave Pear Deck "a lot of confidence, knowing that people are still logging into the app and using it all the time," says Eynon-Lynch. "The biggest impact is being able to work as a team on the configuration in git in a pull request, and the biggest confidence comes from the solidity of the abstractions and the trust that we have in Kubernetes actually making our yaml files a reality."

    - -{{< case-studies/quote author="RILEY EYNON-LYNCH, CEO OF PEAR DECK" >}} -"We didn't even realize how stressed out we were about our lack of insight into what was happening with the app. I'm really excited and have more and more confidence in the actual state of our application for our actual users, and not just what the CPU graphs are saying, because of Prometheus and Kubernetes." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -With the speed befitting a startup, Pear Deck delivered its first prototype to customers within three months of incorporating. -{{< /case-studies/lead >}} - -

    As a former high school math teacher, CEO Riley Eynon-Lynch felt an urgency to provide a tech solution to classes where instructors struggle to interact with every student in a short amount of time. "Pear Deck is an app that students can use to interact with the teacher all at once," he says. "When the teacher asks a question, instead of just the kid at the front of the room answering again, everybody can answer every single question. It's a huge fundamental shift in the messaging to the students about how much we care about them and how much they are a part of the classroom."

    - -

    Eynon-Lynch and his partners quickly built a JavaScript web app on Google's web app development platform Firebase, and launched the minimum viable product [MVP] on Heroku "because it was fast and easy," he says. "We made everything as easy as we could."

    - -

    But once it launched, the user base began growing steadily at a rate of 30 percent a month. "Our Heroku bill was getting totally insane," Eynon-Lynch says. But even more crucially, as the company hired more developers to keep pace, "we outgrew Heroku. We wanted to have multiple services and the deploying story got pretty horrendous. We were frustrated that we couldn't have the developers quickly stage a version. Tracing and monitoring became basically impossible."

    - -

    On top of that, many of Pear Deck's customers are behind government firewalls and connect through Firebase, not Pear Deck's servers, making troubleshooting even more difficult.

    - -

    The team began looking around for another solution, and finally decided in early 2016 to start moving the app from Heroku to Docker containers running on Google Kubernetes Engine, orchestrated by Kubernetes and monitored with Prometheus.

    - -{{< case-studies/quote image="/images/case-studies/peardeck/banner1.jpg" >}} -"When it became clear that Google Kubernetes Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch. -{{< /case-studies/quote >}} - -

    They had considered other options like Google's App Engine (which they were already using for one service) and Amazon's Elastic Compute Cloud (EC2), while experimenting with running one small service that wasn't accessible to the Internet in Kubernetes. "When it became clear that Google Kubernetes Engine was going to have a lot of support from Google and be a fully-managed Kubernetes platform, it seemed very obvious to us that was the way to go," says Eynon-Lynch. "We didn't really consider Terraform and the other competitors because the abstractions offered by Kubernetes just jumped off the page to us."

    - -

    Once the team started porting its Heroku apps into Kubernetes, which was "super easy," he says, the impact was immediate. "Before, to make a new version of the app meant going to Heroku and reconfiguring 10 new services, so basically no one was willing to do it, and we never staged things," he says. "Now we can deploy our exact same configuration in lots of different clusters in 30 seconds. We have a full set up that's always running, and then any of our developers or designers can stage new versions with one command, including their recent changes. We stage all the time now, and everyone stopped talking about how cool it is because it's become invisible how great it is."

    - -

    Along with Kubernetes came Prometheus. "Until pretty recently we didn't have any kind of visibility into aggregate server metrics or performance," says Eynon-Lynch. The team had tried to use Google Kubernetes Engine's Stackdriver monitoring, but had problems making it work, and considered New Relic. When they started looking at Prometheus in the fall of 2016, "the fit between the abstractions in Prometheus and the way we think about how our system works, was so clear and obvious," he says.

    - -

    The integration with Kubernetes made set-up easy. Once Helm installed Prometheus, "We started getting a graph of the health of all our Kubernetes nodes and pods immediately. I think we were pretty hooked at that point," Eynon-Lynch says. "Then we got our own custom instrumentation working in 15 minutes, and had an actively updated count of requests that we could do, rate on and get a sense of how many users are connected at a given point. And then it was another hour before we had alarms automatically showing up in our Slack channel. All that was in one afternoon. And it was an afternoon of gasping with delight, basically!"

    - -{{< case-studies/quote image="/images/case-studies/peardeck/banner2.jpg" >}} -"We started getting a graph of the health of all our Kubernetes nodes and pods immediately. I think we were pretty hooked at that point," Eynon-Lynch says. "Then we got our own custom instrumentation working in 15 minutes, and had an actively updated count of requests that we could do, rate on and get a sense of how many users are connected at a given point. And then it was another hour before we had alarms automatically showing up in our Slack channel. All that was in one afternoon. And it was an afternoon of gasping with delight, basically!" -{{< /case-studies/quote >}} - -

    With Pear Deck's specific challenges—traffic through Firebase as well as government firewalls—Prometheus was a game-changer. "We didn't even realize how stressed out we were about our lack of insight into what was happening with the app," Eynon-Lynch says. Before, when a customer would report that the app wasn't working, the team had to manually investigate the problem without knowing whether customers were affected all over the world, or whether Firebase was down, and where.

    - -

    To help solve that problem, the team wrote a script that pings Firebase from several different geographical locations, and then reports the responses to Prometheus in a histogram. "A huge impact that Prometheus had on us was just an amazing sigh of relief, of feeling like we knew what was happening," he says. "It took 45 minutes to implement [the Firebase alarm] because we knew that we had this trustworthy metrics platform in Prometheus. We weren't going to have to figure out, 'Where do we send these metrics? How do we aggregate the metrics? How do we understand them?'"

    - -

    Plus, Prometheus has allowed Pear Deck to build alarms for business goals. One measures the rate of successful app loads and goes off if the day's loads are less than 90 percent of the loads from seven days before. "We run a JavaScript app behind ridiculous firewalls and all kinds of crazy browser extensions messing with it—Chrome will push a feature that breaks some CSS that we're using," Eynon-Lynch says. "So that gives us a lot of confidence, and we at least know that people are still logging into the app and using it all the time."

    - -

    Now, when a customer complains, and none of the alarms have gone off, the team can feel confident that it's not a widespread problem. "Just to be sure, we can go and double check the graphs and say, 'Yep, there's currently 10,000 people connected to that Firebase node. It's definitely working. Let's investigate your network settings, customer,'" he says. "And we can pass that back off to our support reps instead of the whole development team freaking out that Firebase is down."

    - -

    Pear Deck is also giving back to the community, building and open-sourcing a metrics aggregator that enables end-user monitoring in Prometheus. "We can measure, for example, the time to interactive-dom on the web clients," he says. "The users all report that to our aggregator, then the aggregator reports to Prometheus. So we can set an alarm for some client side errors."

    - -

    Most of Pear Deck's services have now been moved onto Kubernetes. And all of the team's new code is going on Kubernetes. "Kubernetes lets us experiment with service configurations and stage them on a staging cluster all at once, and test different scenarios and talk about them as a development team looking at code, not just talking about the steps we would eventually take as humans," says Eynon-Lynch.

    - -{{< case-studies/quote >}} -"A huge impact that Prometheus had on us was just an amazing sigh of relief, of feeling like we knew what was happening. It took 45 minutes to implement [the Firebase alarm] because we knew that we had this trustworthy metrics platform in Prometheus...in terms of the cloud, Kubernetes and Prometheus have so much to offer," he says. -{{< /case-studies/quote >}} - -

    Looking ahead, the team is planning to explore autoscaling on Kubernetes. With users all over the world but mostly in the United States, there are peaks and valleys in the traffic. One service that's still on App Engine can get as many as 10,000 requests a second during the day but far less at night. "We pay for the same servers at night, so I understand there's autoscaling that we can be taking advantage of," he says. "Implementing it is a big worry, exposing the rest of our Kubernetes cluster to us and maybe messing that up. But it's definitely our intention to move everything over, because now none of the developers want to work on that app anymore because it's such a pain to deploy it."

    - -

    They're also eager to explore the work that Kubernetes is doing with stateful sets. "Right now all of the services we run in Kubernetes are stateless, and Google basically runs our databases for us and manages backups," Eynon-Lynch says. "But we're interested in building our own web-socket solution that doesn't have to be super stateful but will have maybe an hour's worth of state on it."

    - -

    That project will also involve Prometheus, for a dark launch of web socket connections. "We don't know how reliable web socket connections behind all these horrible firewalls will be to our servers," he says. "We don't know what work Firebase has done to make them more reliable. So I'm really looking forward to trying to get persistent connections with web sockets to our clients and have optional tools to understand if it's working. That's our next new adventure, into stateful servers."

    - -

    As for Prometheus, Eynon-Lynch thinks the company has only gotten started. "We haven't instrumented all our important features, especially those that depend on third parties," he says. "We have to wait for those third parties to tell us they're down, which sometimes they don't do for a long time. So I'm really excited and have more and more confidence in the actual state of our application for our actual users, and not just what the CPU graphs are saying, because of Prometheus and Kubernetes."

    - -

    For a spry startup that's continuing to grow rapidly—and yes, they're hiring!—Pear Deck is notably satisfied with how its infrastructure has evolved in the cloud native ecosystem. "Usually I have some angsty thing where I want to get to the new, better technology," says Eynon-Lynch, "but in terms of the cloud, Kubernetes and Prometheus have so much to offer."

    diff --git a/content/ko/case-studies/peardeck/peardeck_featured.png b/content/ko/case-studies/peardeck/peardeck_featured.png deleted file mode 100644 index ce87ee2d47..0000000000 Binary files a/content/ko/case-studies/peardeck/peardeck_featured.png and /dev/null differ diff --git a/content/ko/case-studies/peardeck/peardeck_logo.png b/content/ko/case-studies/peardeck/peardeck_logo.png deleted file mode 100644 index c1b9772ec4..0000000000 Binary files a/content/ko/case-studies/peardeck/peardeck_logo.png and /dev/null differ diff --git a/content/ko/case-studies/pearson/index.html b/content/ko/case-studies/pearson/index.html deleted file mode 100644 index 501bcea8e7..0000000000 --- a/content/ko/case-studies/pearson/index.html +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: Pearson Case Study -linkTitle: Pearson -case_study_styles: true -cid: caseStudies -featured: false -quote: > - We're already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online. - -new_case_study_styles: true -heading_background: /images/case-studies/pearson/banner1.jpg -heading_title_logo: /images/pearson_logo.png -subheading: > - Reinventing the World's Largest Education Company With Kubernetes -case_study_details: - - Company: Pearson - - Location: Global - - Industry: Education ---- - -

    Challenge

    - -

    A global education company serving 75 million learners, Pearson set a goal to more than double that number, to 200 million, by 2025. A key part of this growth is in digital learning experiences, and Pearson was having difficulty in scaling and adapting to its growing online audience. They needed an infrastructure platform that would be able to scale quickly and deliver products to market faster.

    - -

    Solution

    - -

    "To transform our infrastructure, we had to think beyond simply enabling automated provisioning," says Chris Jackson, Director for Cloud Platforms & SRE at Pearson. "We realized we had to build a platform that would allow Pearson developers to build, manage and deploy applications in a completely different way." The team chose Docker container technology and Kubernetes orchestration "because of its flexibility, ease of management and the way it would improve our engineers' productivity."

    - -

    Impact

    - -

    With the platform, there has been substantial improvements in productivity and speed of delivery. "In some cases, we've gone from nine months to provision physical assets in a data center to just a few minutes to provision and get a new idea in front of a customer," says John Shirley, Lead Site Reliability Engineer for the Cloud Platform Team. Jackson estimates they've achieved 15-20% developer productivity savings. Before, outages were an issue during their busiest time of year, the back-to-school period. Now, there's high confidence in their ability to meet aggressive customer SLAs.

    - -{{< case-studies/quote author="Chris Jackson, Director for Cloud Platforms & SRE at Pearson" >}} -"We're already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure. But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online." -{{< /case-studies/quote >}} - -

    In 2015, Pearson was already serving 75 million learners as the world's largest education company, offering curriculum and assessment tools for Pre-K through college and beyond. Understanding that innovating the digital education experience was the key to the future of all forms of education, the company set out to increase its reach to 200 million people by 2025.

    - -

    That goal would require a transformation of its existing infrastructure, which was in data centers. In some cases, it took nine months to provision physical assets. In order to adapt to the demands of its growing online audience, Pearson needed an infrastructure platform that would be able to scale quickly and deliver business-critical products to market faster. "We had to think beyond simply enabling automated provisioning," says Chris Jackson, Director for Cloud Platforms & SRE at Pearson. "We realized we had to build a platform that would allow Pearson developers to build, manage and deploy applications in a completely different way."

    - -

    With 400 development groups and diverse brands with varying business and technical needs, Pearson embraced Docker container technology so that each brand could experiment with building new types of content using their preferred technologies, and then deliver it using containers. Jackson chose Kubernetes orchestration "because of its flexibility, ease of management and the way it would improve our engineers' productivity," he says.

    - -

    The team adopted Kubernetes when it was still version 1.2 and are still going strong now on 1.7; they use Terraform and Ansible to deploy it on to basic AWS primitives. "We were trying to understand how we can create value for Pearson from this technology," says Ben Somogyi, Principal Architect for the Cloud Platforms. "It turned out that Kubernetes' benefits are huge. We're trying to help our applications development teams that use our platform go faster, so we filled that gap with a CI/CD pipeline that builds their images for them, standardizes them, patches everything up, allows them to deploy their different environments onto the cluster, and obfuscating the details of how difficult the work underneath the covers is."

    - -{{< case-studies/quote - image="/images/case-studies/pearson/banner3.jpg" - author="Chris Jackson, Director for Cloud Platforms & SRE at Pearson" ->}} -"Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service." -{{< /case-studies/quote >}} - -

    That work resulted in two tools for building and deploying applications in the cluster that Pearson has open sourced. "We're an education company, so we want to share what we can," says Somogyi.

    - -

    Now that development teams no longer have to worry about infrastructure, there have been substantial improvements in productivity and speed of delivery. "In some cases, we've gone from nine months to provision physical assets in a data center to just a few minutes to provision and to get a new idea in front of a customer," says John Shirley, Lead Site Reliability Engineer for the Cloud Platform Team.

    - -

    According to Jackson, the Cloud Platforms team can "provision a new proof-of-concept environment for a development team in minutes, and then they can take that to production as quickly as they are able to. This is the value proposition of all major technology services, and we had to compete like one to become our developers' preferred choice. Just because you work for the same company, you do not have the right to force people into a mediocre service. Your internal customers need to feel like they are choosing the very best option for them. We are experiencing this first hand in the growth of adoption. We are seeing triple-digit, year-on-year growth of the service."

    - -

    Jackson estimates they've achieved a 15-20% boost in productivity for developer teams who adopt the platform. They also see a reduction in the number of customer-impacting incidents. Plus, says Jackson, "Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!"

    - -{{< case-studies/quote - image="/images/case-studies/pearson/banner4.jpg" - author="Chris Jackson, Director for Cloud Platforms & SRE at Pearson" ->}} -"Teams who were previously limited to 1-2 releases per academic year can now ship code multiple times per day!" -{{< /case-studies/quote >}} - -

    Availability has also been positively impacted. The back-to-school period is the company's busiest time of year, and "you have to keep applications up," says Somogyi. Before, this was a pain point for the legacy infrastructure. Now, for the applications that have been migrated to the Kubernetes platform, "We have 100% uptime. We're not worried about 9s. There aren't any. It's 100%, which is pretty astonishing for us, compared to some of the existing platforms that have legacy challenges," says Shirley.

    - -

    "You can't even begin to put a price on how much that saves the company," Jackson explains. "A reduction in the number of support cases takes load out of our operations. The customer sentiment of having a reliable product drives customer retention and growth. It frees us to think about investing more into our digital transformation and taking a better quality of education to a global scale."

    - -

    The platform itself is also being broken down, "so we can quickly release smaller pieces of the platform, like upgrading our Kubernetes or all the different modules that make up our platform," says Somogyi. "One of the big focuses in 2018 is this scheme of delivery to update the platform itself."

    - -

    Guided by Pearson's overarching goal of getting to 200 million users, the team has run internal tests of the platform's scalability. "We had a challenge: 28 million requests within a 10 minute period," says Shirley. "And we demonstrated that we can hit that, with an acceptable latency. We saw that we could actually get that pretty readily, and we scaled up in just a few seconds, using open source tools entirely. Shout out to Locustfor that one. So that's amazing."

    - -{{< case-studies/quote author="Benjamin Somogyi, Principal Systems Architect at Pearson" >}} -"We have 100% uptime. We're not worried about 9s. There aren't any. It's 100%, which is pretty astonishing for us, compared to some of the existing platforms that have legacy challenges. You can't even begin to put a price on how much that saves the company." -{{< /case-studies/quote >}} - -

    In just two years, "We're already seeing tremendous benefits with Kubernetes—improved engineering productivity, faster delivery of applications and a simplified infrastructure," says Jackson. "But this is just the beginning. Kubernetes will help transform the way that educational content is delivered online."

    - -

    So far, about 15 production products are running on the new platform, including Pearson's new flagship digital education service, the Global Learning Platform. The Cloud Platform team continues to prepare, onboard and support customers that are a good fit for the platform. Some existing products will be refactored into 12-factor apps, while others are being developed so that they can live on the platform from the get-go. "There are challenges with bringing in new customers of course, because we have to help them to see a different way of developing, a different way of building," says Shirley.

    - -

    But, he adds, "It is our corporate motto: Always Learning. We encourage those teams that haven't started a cloud native journey, to see the future of technology, to learn, to explore. It will pique your interest. Keep learning."

    diff --git a/content/ko/case-studies/pearson/pearson_featured.png b/content/ko/case-studies/pearson/pearson_featured.png deleted file mode 100644 index 6f8ffec49e..0000000000 Binary files a/content/ko/case-studies/pearson/pearson_featured.png and /dev/null differ diff --git a/content/ko/case-studies/pearson/pearson_logo.png b/content/ko/case-studies/pearson/pearson_logo.png deleted file mode 100644 index 57e586f3eb..0000000000 Binary files a/content/ko/case-studies/pearson/pearson_logo.png and /dev/null differ diff --git a/content/ko/case-studies/pinterest/index.html b/content/ko/case-studies/pinterest/index.html deleted file mode 100644 index b95fff054a..0000000000 --- a/content/ko/case-studies/pinterest/index.html +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: Pinterest Case Study -linkTitle: Pinterest -case_study_styles: true -cid: caseStudies -featured: false -weight: 30 -quote: > - We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do. - -new_case_study_styles: true -heading_background: /images/case-studies/pinterest/banner1.jpg -heading_title_logo: /images/pinterest_logo.png -subheading: > - Pinning Its Past, Present, and Future on Cloud Native -case_study_details: - - Company: Pinterest - - Location: San Francisco, California - - Industry: Web and Mobile App ---- - -

    Challenge

    - -

    After eight years in existence, Pinterest had grown into 1,000 microservices and multiple layers of infrastructure and diverse set-up tools and platforms. In 2016 the company launched a roadmap towards a new compute platform, led by the vision of creating the fastest path from an idea to production, without making engineers worry about the underlying infrastructure.

    - -

    Solution

    - -

    The first phase involved moving services to Docker containers. Once these services went into production in early 2017, the team began looking at orchestration to help create efficiencies and manage them in a decentralized way. After an evaluation of various solutions, Pinterest went with Kubernetes.

    - -

    Impact

    - -

    "By moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins," says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest. "We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster."

    - -{{< case-studies/quote author="Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest" >}} - -
    -"So far it's been good, especially the elasticity around how we can configure our Jenkins workloads on that Kubernetes shared cluster. That is the win we were pushing for." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -Pinterest was born on the cloud—running on AWS since day one in 2010—but even cloud native companies can experience some growing pains. -{{< /case-studies/lead >}} - -

    Since its launch, Pinterest has become a household name, with more than 200 million active monthly users and 100 billion objects saved. Underneath the hood, there are 1,000 microservices running and hundreds of thousands of data jobs.

    - -

    With such growth came layers of infrastructure and diverse set-up tools and platforms for the different workloads, resulting in an inconsistent and complex end-to-end developer experience, and ultimately less velocity to get to production. So in 2016, the company launched a roadmap toward a new compute platform, led by the vision of having the fastest path from an idea to production, without making engineers worry about the underlying infrastructure.

    - -

    The first phase involved moving to Docker. "Pinterest has been heavily running on virtual machines, on EC2 instances directly, for the longest time," says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group. "To solve the problem around packaging software and not make engineers own portions of the fleet and those kinds of challenges, we standardized the packaging mechanism and then moved that to the container on top of the VM. Not many drastic changes. We didn't want to boil the ocean at that point."

    - -{{< case-studies/quote - image="/images/case-studies/pinterest/banner3.jpg" - author="MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST" ->}} -"Though Kubernetes lacked certain things we wanted, we realized that by the time we get to productionizing many of those things, we'll be able to leverage what the community is doing." -{{< /case-studies/quote >}} - -

    The first service that was migrated was the monolith API fleet that powers most of Pinterest. At the same time, Benedict's infrastructure governance team built chargeback and capacity planning systems to analyze how the company uses its virtual machines on AWS. "It became clear that running on VMs is just not sustainable with what we're doing," says Benedict. "A lot of resources were underutilized. There were efficiency efforts, which worked fine at a certain scale, but now you have to move to a more decentralized way of managing that. So orchestration was something we thought could help solve that piece."

    - -

    That led to the second phase of the roadmap. In July 2017, after an eight-week evaluation period, the team chose Kubernetes over other orchestration platforms. "Kubernetes lacked certain things at the time—for example, we wanted Spark on Kubernetes," says Benedict. "But we realized that the dev cycles we would put in to even try building that is well worth the outcome, both for Pinterest as well as the community. We've been in those conversations in the Big Data SIG. We realized that by the time we get to productionizing many of those things, we'll be able to leverage what the community is doing."

    - -

    At the beginning of 2018, the team began onboarding its first use case into the Kubernetes system: Jenkins workloads. "Although we have builds happening during a certain period of the day, we always need to allocate peak capacity," says Benedict. "They don't have any auto-scaling capabilities, so that capacity stays constant. It is difficult to speed up builds because ramping up takes more time. So given those kind of concerns, we thought that would be a perfect use case for us to work on."

    - -{{< case-studies/quote - image="/images/case-studies/pinterest/banner4.jpg" - author="MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST" ->}} -"So far it's been good, especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for." -{{< /case-studies/quote >}} - -

    They ramped up the cluster, and working with a team of four people, got the Jenkins Kubernetes cluster ready for production. "We still have our static Jenkins cluster," says Benedict, "but on Kubernetes, we are doing similar builds, testing the entire pipeline, getting the artifact ready and just doing the comparison to see, how much time did it take to build over here. Is the SLA okay, is the artifact generated correct, are there issues there?"

    - -

    "So far it's been good," he adds, "especially the elasticity around how we can configure our Jenkins workloads on Kubernetes shared cluster. That is the win we were pushing for."

    - -

    By the end of Q1 2018, the team successfully migrated Jenkins Master to run natively on Kubernetes and also collaborated on the Jenkins Kubernetes Plugin to manage the lifecycle of workers. "We're currently building the entire Pinterest JVM stack (one of the larger monorepos at Pinterest which was recently bazelized) on this new cluster," says Benedict. "At peak, we run thousands of pods on a few hundred nodes. Overall, by moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins. We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster."

    - -{{< case-studies/quote author="MICHEAL BENEDICT, PRODUCT MANAGER FOR THE CLOUD AND THE DATA INFRASTRUCTURE GROUP AT PINTEREST">}} -"We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do." -{{< /case-studies/quote >}} - -

    Benedict points to a "pretty robust roadmap" going forward. In addition to the Pinterest big data team's experiments with Spark on Kubernetes, the company collaborated with Amazon's EKS team on an ENI/CNI plug in.

    - -

    Once the Jenkins cluster is up and running out of dark mode, Benedict hopes to establish best practices, including having governance primitives established—including integration with the chargeback system—before moving on to migrating the next service. "We have a healthy pipeline of use-cases to be on-boarded. After Jenkins, we want to enable support for Tensorflow and Apache Spark. At some point, we aim to move the company's monolithic API service. If we move that and understand the complexity around that, it builds our confidence," says Benedict. "It sets us up for migration of all our other services."

    - -

    After years of being a cloud native pioneer, Pinterest is eager to share its ongoing journey. "We are in the position to run things at scale, in a public cloud environment, and test things out in way that a lot of people might not be able to do," says Benedict. "We're in a great position to contribute back some of those learnings."

    diff --git a/content/ko/case-studies/pinterest/pinterest_feature.png b/content/ko/case-studies/pinterest/pinterest_feature.png deleted file mode 100644 index ea5d625789..0000000000 Binary files a/content/ko/case-studies/pinterest/pinterest_feature.png and /dev/null differ diff --git a/content/ko/case-studies/pinterest/pinterest_logo.png b/content/ko/case-studies/pinterest/pinterest_logo.png deleted file mode 100644 index 0f744e7828..0000000000 Binary files a/content/ko/case-studies/pinterest/pinterest_logo.png and /dev/null differ diff --git a/content/ko/case-studies/slingtv/index.html b/content/ko/case-studies/slingtv/index.html deleted file mode 100644 index 6de46f35ff..0000000000 --- a/content/ko/case-studies/slingtv/index.html +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: SlingTV Case Study -linkTitle: Sling TV -case_study_styles: true -cid: caseStudies -featured: true -weight: 49 -quote: > - I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables. - -new_case_study_styles: true -heading_background: /images/case-studies/slingtv/banner1.jpg -heading_title_logo: /images/slingtv_logo.png -subheading: > - Sling TV: Marrying Kubernetes and AI to Enable Proper Web Scale -case_study_details: - - Company: Sling TV - - Location: Englewood, Colorado - - Industry: Streaming television ---- - -

    Challenge

    - -

    Launched by DISH Network in 2015, Sling TV experienced great customer growth from the beginning. After just a year, "we were going through some growing pains of some of the legacy systems and trying to find the right architecture to enable our future," says Brad Linder, Sling TV's Cloud Native & Big Data Evangelist. The company has particular challenges: "We take live TV and distribute it over the internet out to a user's device that we do not control," says Linder. "In a lot of ways, we are working in the Wild West: The internet is what it is going to be, and if a customer's service does not work for whatever reason, they do not care why. They just want things to work. Those are the variables of the equation that we have to try to solve. We really have to try to enable optionality and good customer experience at web scale."

    - -

    Solution

    - -

    Led by the belief that "the cloud native architectures and patterns really give us a lot of flexibility in meeting the needs of that sort of customer base," Linder partnered with Rancher Labs to build Sling TV's next-generation platform around Kubernetes. "We are going to need to enable a hybrid cloud strategy including multiple public clouds and an on-premise VMWare multi data center environment to meet the needs of the business at some point, so getting that sort of abstraction was a real goal," he says. "That is one of the biggest reasons why we picked Kubernetes." The team launched its first applications on Kubernetes in Sling TV's two internal data centers. The push to enable AWS as a data center option is underway and should be available by the end of 2018. The team has added Prometheus for monitoring and Jaeger for tracing, to work alongside the company's existing tool sets: Zenoss, New Relic and ELK.

    - -

    Impact

    - -

    "We are getting to the place where we can one-click deploy an entire data center – the compute, network, Kubernetes, logging, monitoring and all the apps," says Linder. "We have really enabled a platform thinking based approach to allowing applications to consume common tools. A new application can be onboarded in about an hour using common tooling and CI/CD processes. The gains on that side have been huge. Before, it took at least a few days to get things sorted for a new application to deploy. That does not consider the training of our operations staff to manage this new application. It is two or three orders of magnitude of savings in time and cost, and operationally it has given us the opportunity to let a core team of talented operations engineers manage common infrastructure and tooling to make our applications available at web scale."

    - -{{< case-studies/quote author="Brad Linder, Cloud Native & Big Data Evangelist for Sling TV" >}} -"I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -The beauty of streaming television, like the service offered by Sling TV, is that you can watch it from any device you want, wherever you want. -{{< /case-studies/lead >}} - - -

    Of course, from the provider side of things, that creates a particular set of challenges "We take live TV and distribute it over the internet out to a user's device that we do not control," says Brad Linder, Sling TV's Cloud Native & Big Data Evangelist. "In a lot of ways, we are working in the Wild West: The internet is what it is going to be, and if a customer's service does not work for whatever reason, they do not care why. They just want things to work. Those are the variables of the equation that we have to try to solve. We really have to try to enable optionality and we have to do it at web scale."

    - -

    Indeed, Sling TV experienced great customer growth from the beginning of its launch by DISH Network in 2015. After just a year, "we were going through some growing pains of some of the legacy systems and trying to find the right architecture to enable our future," says Linder. Tasked with building a next-generation web scale platform for the "personalized customer experience," Linder has spent the past year bringing Kubernetes to Sling TV.

    - -

    Led by the belief that "the cloud native architectures and patterns really give us a lot of flexibility in meeting the needs of our customers," Linder partnered with Rancher Labs to build the platform around Kubernetes. "They have really helped us get our head around how to use Kubernetes," he says. "We needed the flexibility to enable our use case versus just a simple orchestrater. Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value proposition."

    - -{{< case-studies/quote - image="/images/case-studies/slingtv/banner3.jpg" - author="Brad Linder, Cloud Native & Big Data Evangelist for Sling TV" ->}} -"We needed the flexibility to enable our use case versus just a simple orchestrater. Enabling our future in a way that did not give us vendor lock-in was also a key part of our strategy. I think that is part of the Rancher value proposition." -{{< /case-studies/quote >}} - -

    One big reason he chose Kubernetes was getting a level of abstraction that would enable the company to "enable a hybrid cloud strategy including multiple public clouds and an on-premise VMWare multi data center environment to meet the needs of the business," he says. Another factor was how much the Kubernetes ecosystem has matured over the past couple of years. "We have spent a lot of time and energy around making logging, monitoring and alerting production ready to give us insights into applications' well-being," says Linder. The team has added Prometheus for monitoring and Jaeger for tracing, to work alongside the company's existing tool sets: Zenoss, New Relic and ELK.

    - -

    With the emphasis on common tooling, "We are getting to the place where we can one-click deploy an entire data center – the compute, network, Kubernetes, logging, monitoring and all the apps," says Linder. "We have really enabled a platform thinking based approach to allowing applications to consume common tools and services. A new application can be onboarded in about an hour using common tooling and CI/CD processes. The gains on that side have been huge. Before, it took at least a few days to get things sorted for a new application to deploy. That does not consider the training of our operations staff to manage this new application. It is two or three orders of magnitude of savings in time and cost, and operationally it has given us the opportunity to let a core team of talented operations engineers manage common infrastructure and tooling to make our applications available at web scale."

    - -{{< case-studies/quote - image="/images/case-studies/slingtv/banner4.jpg" - author="Brad Linder, Cloud Native & Big Data Evangelist for Sling TV" ->}} -"We have to be able to react to changes and hiccups in the matrix. It is the foundation for our ability to deliver a high-quality service for our customers." -{{< /case-studies/quote >}} - -

    The team launched its first applications on Kubernetes in Sling TV's two internal data centers in the early part of Q1 2018 and began to enable AWS as a data center option. The company plans to expand into other public clouds in the future.

    - -

    The first application that went into production is a web socket-based back-end notification service. "It allows back-end changes to trigger messages to our clients in the field without the polling," says Linder. "We are talking about very high volumes of messages with this application. Without something like Kubernetes to be able to scale up and down, as well as just support that overall workload, that is pretty hard to do. I would almost be so bold as to say that most of these applications that we are building now would not have been possible without the cloud native patterns and the flexibility that Kubernetes enables."

    - -

    Linder oversees three teams working together on building the next-generation platform: a platform engineering team; an enterprise middleware services team; and a big data and analytics team. "We have really tried to bring everything together to be able to have a client application interact with a cloud native middleware layer. That middleware layer must run on a platform, consume platform services and then have logs and events monitored by an artificial agent to keep things running smoothly," says Linder.

    - -{{< case-studies/quote author="BRAD LINDER, CLOUD NATIVE & BIG DATA EVANGELIST FOR SLING TV">}} -This undertaking is about "trying to marry Kubernetes with AI to enable web scale that just works". -{{< /case-studies/quote >}} - -

    Ultimately, this undertaking is about "trying to marry Kubernetes with AI to enable web scale that just works," he adds. "We want the artificial agents and the big data platform using the actual logs and events coming out of the applications, Kubernetes, the infrastructure, backing services and changes to the environment to make decisions like, 'Hey we need more capacity for this service so please add more nodes.' From a platform perspective, if you are truly doing web scale stuff and you are not using AI and big data, in my opinion, you are going to implode under your own weight. It is not a question of if, it is when. If you are in a 'millions of users' sort of environment, that implosion is going to be catastrophic. We are on our way to this goal and have learned a lot along the way."

    - -

    For Sling TV, moving to cloud native has been exactly what they needed. "We have to be able to react to changes and hiccups in the matrix," says Linder. "It is the foundation for our ability to deliver a high-quality service for our customers. Building intelligent platforms, tools and clients in the field consuming those services has got to be part of all of this. In my eyes that is a big part of what cloud native is all about. It is taking these distributed, potentially unreliable entities and enabling a robust customer experience they expect."

    diff --git a/content/ko/case-studies/slingtv/slingtv_featured_logo.png b/content/ko/case-studies/slingtv/slingtv_featured_logo.png deleted file mode 100644 index b52143ee8b..0000000000 Binary files a/content/ko/case-studies/slingtv/slingtv_featured_logo.png and /dev/null differ diff --git a/content/ko/case-studies/squarespace/index.html b/content/ko/case-studies/squarespace/index.html deleted file mode 100644 index 461e466d8c..0000000000 --- a/content/ko/case-studies/squarespace/index.html +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: Squarespace Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/squarespace/banner1.jpg -heading_title_logo: /images/squarespace_logo.png -subheading: > - Squarespace: Gaining Productivity and Resilience with Kubernetes -case_study_details: - - Company: Squarespace - - Location: New York, N.Y. - - Industry: Software as a Service, Website-Building Platform ---- - -

    Challenge

    - -

    Moving from a monolith to microservices in 2014 "solved a problem on the development side, but it pushed that problem to the infrastructure team," says Kevin Lynch, Staff Engineer on the Site Reliability team at Squarespace. "The infrastructure deployment process on our 5,000 VM hosts was slowing everyone down."

    - -

    Solution

    - -

    The team experimented with container orchestration platforms, and found that Kubernetes "answered all the questions that we had," says Lynch. The company began running Kubernetes in its data centers in 2016.

    - -

    Impact

    - -

    Since Squarespace moved to Kubernetes, in conjunction with modernizing its networking stack, deployment time has been reduced by almost 85%. Before, their VM deployment would take half an hour; now, says Lynch, "someone can generate a templated application, deploy it within five minutes, and have actual instances containerized, running in our staging environment at that point." Because of that, "productivity time is the big cost saver," he adds. "When we started the Kubernetes project, we had probably a dozen microservices. Today there are twice that in the pipeline being actively worked on." Resilience has also been improved with Kubernetes: "If a node goes down, it's rescheduled immediately and there's no performance impact."

    - -{{< case-studies/quote author="Kevin Lynch, Staff Engineer on the Site Reliability team at Squarespace" >}} - -
    -"Once you prove that Kubernetes solves one problem, everyone immediately starts solving other problems without you even having to evangelize it." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -Since it was started in a dorm room in 2003, Squarespace has made it simple for millions of people to create their own websites. -{{< /case-studies/lead >}} - -

    Behind the scenes, though, the company's monolithic Java application was making things not so simple for its developers to keep improving the platform. So in 2014, the company decided to "go down the microservices path," says Kevin Lynch, staff engineer on Squarespace's Site Reliability team. "But we were always deploying our applications in vCenter VMware VMs [in our own data centers]. Microservices solved a problem on the development side, but it pushed that problem to the Infrastructure team. The infrastructure deployment process on our 5,000 VM hosts was slowing everyone down."

    - -

    After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had." Deploying it in the data center rather than the public cloud was their biggest challenge, and at the time, not a lot of other companies were doing that. "We had to figure out how to deploy this in our infrastructure for ourselves, and we had to integrate it with our other applications," says Lynch.

    - -

    At the same time, Squarespace's Network Engineering team was modernizing its networking stack, switching from a traditional layer-two network to a layer-three spine-and-leaf network. "It mapped beautifully with what we wanted to do with Kubernetes," says Lynch. "It gives us the ability to have our servers communicate directly with the top-of-rack switches. We use Calico for CNI networking for Kubernetes, so we can announce all these individual Kubernetes pod IP addresses and have them integrate seamlessly with our other services that are still provisioned in the VMs."

    - -{{< case-studies/quote image="/images/case-studies/squarespace/banner3.jpg" >}} -After experimenting with another container orchestration platform and "breaking it in very painful ways," Lynch says, the team began experimenting with Kubernetes in mid-2016 and found that it "answered all the questions that we had." -{{< /case-studies/quote >}} - -

    Within a couple months, they had a stable cluster for their internal use, and began rolling out Kubernetes for production. They also added Zipkin and CNCF projects Prometheus and fluentd to their cloud native stack. "We switched to Kubernetes, a new world, and we revamped all our other tooling as well," says Lynch. "It allowed us to streamline our process, so we can now easily create an entire microservice project from templates, generate the code and deployment pipeline for that, generate the Docker file, and then immediately just ship a workable, deployable project to Kubernetes." Deployments across Dev/QA/Stage/Prod were also "simplified drastically," Lynch adds. "Now there is little configuration variation."

    - -

    And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment. "From end to end that probably took half an hour, and that's not accounting for the fact that an infrastructure engineer would be responsible for doing that, so there's some business delay in there as well."

    - -

    With faster deployments, "productivity time is the big cost saver," says Lynch. "We had a team that was implementing a new file storage service, and they just started integrating that with our storage back end without our involvement"—which wouldn't have been possible before Kubernetes. He adds: "When we started the Kubernetes project, we had probably a dozen microservices. Today there are twice that in the pipeline being actively worked on."

    - -{{< case-studies/quote image="/images/case-studies/squarespace/banner4.jpg" >}} -"We switched to Kubernetes, a new world....It allowed us to streamline our process, so we can now easily create an entire microservice project from templates," Lynch says. And the whole process takes only five minutes, an almost 85% reduction in time compared to their VM deployment. -{{< /case-studies/quote >}} - -

    There's also been a positive impact on the application's resilience. "When we're deploying VMs, we have to build tooling to ensure that a service is spread across racks appropriately and can withstand failure," he says. "Kubernetes just does it. If a node goes down, it's rescheduled immediately and there's no performance impact."

    - -

    Another big benefit is autoscaling. "It wasn't really possible with the way we've been using VMware," says Lynch, "but now we can just add the appropriate autoscaling features via Kubernetes directly, and boom, it's scaling up as demand increases. And it worked out of the box."

    - -

    For others starting out with Kubernetes, Lynch says his best advice is to "fail fast": "Once you've planned things out, just execute. Kubernetes has been really great for trying something out quickly and seeing if it works or not."

    - -{{< case-studies/quote >}} -"When we're deploying VMs, we have to build tooling to ensure that a service is spread across racks appropriately and can withstand failure," he says. "Kubernetes just does it. If a node goes down, it's rescheduled immediately and there's no performance impact." -{{< /case-studies/quote >}} - -

    Lynch and his team are planning to open source some of the tools they've developed to extend Kubernetes and use it as an API itself. The first tool injects dependent applications as containers in a pod. "When you ship an application, usually it comes along with a whole bunch of dependent applications that need to be shipped with that, for example, fluentd for logging," he explains. With this tool, the developer doesn't need to worry about the configurations.

    - -

    Going forward, all new services at Squarespace are going into Kubernetes, and the end goal is to convert everything it can. About a quarter of existing services have been migrated. "Our monolithic application is going to be the last one, just because it's so big and complex," says Lynch. "But now I'm seeing other services get moved over, like the file storage service. Someone just did it and it worked—painlessly. So I believe if we tackle it, it's probably going to be a lot easier than we fear. Maybe I should just take my own advice and fail fast!"

    diff --git a/content/ko/case-studies/squarespace/squarespace_featured_logo.png b/content/ko/case-studies/squarespace/squarespace_featured_logo.png deleted file mode 100644 index 551b6da321..0000000000 Binary files a/content/ko/case-studies/squarespace/squarespace_featured_logo.png and /dev/null differ diff --git a/content/ko/case-studies/wikimedia/index.html b/content/ko/case-studies/wikimedia/index.html deleted file mode 100644 index b10002af83..0000000000 --- a/content/ko/case-studies/wikimedia/index.html +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: Wikimedia Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_title_text: Wikimedia -use_gradient_overlay: true -subheading: > - Using Kubernetes to Build Tools to Improve the World's Wikis -case_study_details: - - Company: Wikimedia - - Location: San Francisco, CA ---- - -

    The non-profit Wikimedia Foundation operates some of the largest collaboratively edited reference projects in the world, including Wikipedia. To help users maintain and use wikis, it runs Wikimedia Tool Labs, a hosting environment for community developers working on tools and bots to help editors and other volunteers do their work, including reducing vandalism. The community around Wikimedia Tool Labs began forming nearly 10 years ago.

    - -{{< case-studies/quote author="Yuvi Panda, operations engineer at Wikimedia Foundation and Wikimedia Tool Labs">}} -Wikimedia -
    -
    -"Wikimedia Tool Labs is vital for making sure wikis all around the world work as well as they possibly can. Because it's grown organically for almost 10 years, it has become an extremely challenging environment and difficult to maintain. It's like a big ball of mud — you really can't see through it. With Kubernetes, we're simplifying the environment and making it easier for developers to build the tools that make wikis run better." -{{< /case-studies/quote >}} - -

    Challenges

    - -
      -
    • Simplify a complex, difficult-to-manage infrastructure
      • -
    • Allow developers to continue writing tools and bots using existing techniques
      • -
    - -

    Why Kubernetes

    - -
      -
    • Wikimedia Tool Labs chose Kubernetes because it can mimic existing workflows, while reducing complexity
      • -
    - -

    Approach

    - -
      -
    • Migrate old systems and a complex infrastructure to Kubernetes
      • -
    - -

    Results

    - -
      -
    • 20 percent of web tools that account for more than 40 percent of web traffic now run on Kubernetes
      • -
    • A 25-node cluster that keeps up with each new Kubernetes release
      • -
    • Thousands of lines of old code have been deleted, thanks to Kubernetes
      • -
    - -

    Using Kubernetes to provide tools for maintaining wikis

    - -

    Wikimedia Tool Labs is run by a staff of four-and-a-half paid employees and two volunteers. The infrastructure didn't make it easy or intuitive for developers to build bots and other tools to make wikis work more easily. Yuvi says, "It's incredibly chaotic. We have lots of Perl and Bash duct tape on top of it. Everything is super fragile."

    - -

    To solve the problem, Wikimedia Tool Labs migrated parts of its infrastructure to Kubernetes, in preparation for eventually moving its entire system. Yuvi said Kubernetes greatly simplifies maintenance. The goal is to allow developers creating bots and other tools to use whatever development methods they want, but make it easier for the Wikimedia Tool Labs to maintain the required infrastructure for hosting and sharing them.

    - -

    "With Kubernetes, I've been able to remove a lot of our custom-made code, which makes everything easier to maintain. Our users' code also runs in a more stable way than previously," says Yuvi.

    - -

    Simplifying infrastructure and keeping wikis running better

    - -

    Wikimedia Tool Labs has seen great success with the initial Kubernetes deployment. Old code is being simplified and eliminated, contributing developers don't have to change the way they write their tools and bots, and those tools and bots run in a more stable fashion than they have in the past. The paid staff and volunteers are able to better keep up with fixing issues.

    - -

    In the future, with a more complete migration to Kubernetes, Wikimedia Tool Labs expects to make it even easier to host and maintain the bots and tools that help run wikis across the world. The tool labs already host approximately 1,300 tools and bots from 800 volunteers, with many more being submitted every day. Twenty percent of the tool labs' web tools that account for more than 60 percent of web traffic now run on Kubernetes. The tool labs has a 25-node cluster that keeps up with each new Kubernetes release. Many existing web tools are migrating to Kubernetes.

    - -

    "Our goal is to make sure that people all over the world can share knowledge as easily as possible. Kubernetes helps with that, by making it easier for wikis everywhere to have the tools they need to thrive," says Yuvi.

    diff --git a/content/ko/case-studies/wikimedia/wikimedia_featured.png b/content/ko/case-studies/wikimedia/wikimedia_featured.png deleted file mode 100644 index 7b1f89ac98..0000000000 Binary files a/content/ko/case-studies/wikimedia/wikimedia_featured.png and /dev/null differ diff --git a/content/ko/case-studies/wikimedia/wikimedia_logo.png b/content/ko/case-studies/wikimedia/wikimedia_logo.png deleted file mode 100644 index 3ad5b63034..0000000000 Binary files a/content/ko/case-studies/wikimedia/wikimedia_logo.png and /dev/null differ diff --git a/content/ko/case-studies/wink/index.html b/content/ko/case-studies/wink/index.html deleted file mode 100644 index 1f8ea4c89d..0000000000 --- a/content/ko/case-studies/wink/index.html +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Wink Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/wink/banner1.jpg -heading_title_logo: /images/wink_logo.png -subheading: > - Cloud-Native Infrastructure Keeps Your Smart Home Connected -case_study_details: - - Company: Wink - - Location: New York, N.Y. - - Industry: Internet of Things Platform ---- - -

    Challenge

    - -

    Building a low-latency, highly reliable infrastructure to serve communications between millions of connected smart-home devices and the company's consumer hubs and mobile app, with an emphasis on horizontal scalability, the ability to encrypt everything quickly and connections that could be easily brought back up if anything went wrong.

    - -

    Solution

    - -

    Across-the-board use of a Kubernetes-Docker-CoreOS Container Linux stack.

    - -

    Impact

    - -

    "Two of the biggest American retailers [Home Depot and Walmart] are carrying and promoting the brand and the hardware," Wink Head of Engineering Kit Klein says proudly – though he adds that "it really comes with a lot of pressure. It's not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses." And that's further testament to how much faith Klein has in the infrastructure that the Wink team has built. With 80 percent of Wink's workload running on a unified stack of Kubernetes-Docker-CoreOS, the company has put itself in a position to continually innovate and improve its products and services. Committing to this technology, says Klein, "makes building on top of the infrastructure relatively easy."

    - -{{< case-studies/quote author="KIT KLEIN, HEAD OF ENGINEERING, WINK" >}} -"It's not proprietary, it's totally open, it's really portable. You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That's the benefit of having everything unified on one open source Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro/machine image to validate. The benefits are enormous because you save money, and you save time." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -How many people does it take to turn on a light bulb? -{{< /case-studies/lead >}} - -

    Kit Klein whips out his phone to demonstrate. With a few swipes, the head of engineering at Wink pulls up the smart-home app created by the New York City-based company and taps the light button. "Honestly when you're holding the phone and you're hitting the light," he says, "by the time you feel the pressure of your finger on the screen, it's on. It takes as long as the signal to travel to your brain."

    - -

    Sure, it takes just one finger and less than 200 milliseconds to turn on the light – or lock a door or change a thermostat. But what allows Wink to help consumers manage their connected smart-home products with such speed and ease is a sophisticated, cloud native infrastructure that Klein and his team built and continue to develop using a unified stack of CoreOS, the open-source operating system designed for clustered deployments, and Kubernetes, an open-source platform for automating deployment, scaling, and operations of application containers across clusters of hosts, providing container-centric infrastructure. "When you have a big, complex network of interdependent microservices that need to be able to discover each other, and need to be horizontally scalable and tolerant to failure, that's what this is really optimized for," says Klein. "A lot of people end up relying on proprietary services [offered by some big cloud providers] to do some of this stuff, but what you get by adopting CoreOS/Kubernetes is portability, to not be locked in to anyone. You can really make your own fate."

    - -

    Indeed, Wink did. The company's mission statement is to make the connected home accessible – that is, user-friendly for non-technical owners, affordable and perhaps most importantly, reliable. "If you can't trust that when you hit the switch, you know a light is going to go on, or if you're remote and you're checking on your house and that information isn't accurate, then the convenience of the system is lost," says Klein. "So that's where the infrastructure comes in."

    - -

    Wink was incubated within Quirky, a company that developed crowd-sourced inventions. The Wink app was first introduced in 2013, and at the time, it controlled only a few consumer products such as the PivotPower Strip that Quirky produced in collaboration with GE. As smart-home products proliferated, Wink was launched in 2014 in Home Depot stores nationwide. Its first project: a hub that could integrate with smart products from about a dozen brands like Honeywell and Chamberlain. The biggest challenge would be to build the infrastructure to serve all those communications between the hub and the products, with a focus on maximizing reliability and minimizing latency.

    - -

    "When we originally started out, we were moving very fast trying to get the first product to market, the minimum viable product," says Klein. "Lots of times you go down a path and end up having to backtrack and try different things. But in this particular case, we did a lot of the work up front, which led to us making a really sound decision to deploy it on CoreOS Container Linux. And that was very early in the life of it."

    - -{{< case-studies/quote image="/images/case-studies/wink/banner3.jpg">}} -"...what you get by adopting CoreOS/Kubernetes is portability, to not be locked in to anyone. You can really make your own fate." -{{< /case-studies/quote >}} - -

    Concern number one: Wink's products need to connect to consumer devices in people's homes, behind a firewall. "You don't have an end point like a URL, and you don't even know what ports are open behind that firewall," Klein explains. "So you essentially need to have this thing wake up and talk to your system and then open real-time, bidirectional communication between the cloud and the device. And it's really, really important that it's persistent because you want to decrease as much as possible the overhead of sending a message – you never know when someone is going to turn on the lights."

    - -

    With the earliest version of the Wink Hub, when you decided to turn your lights on or off, the request would be sent to the cloud and then executed. Subsequent updates to Wink's software enabled local control, cutting latency down to about 10 milliseconds for many devices. But with the need for cloud-enabled integrations of an ever-growing ecosystem of smart home products, low-latency internet connectivity is still a critical consideration.

    - -{{< case-studies/lead >}} -"You essentially need to have this thing wake up and talk to your system and then open real-time, bidirectional communication between the cloud and the device. And it's really, really important that it's persistent...you never know when someone is going to turn on the lights." -{{< /case-studies/lead >}} - -

    In addition, Wink had other requirements: horizontal scalability, the ability to encrypt everything quickly, connections that could be easily brought back up if something went wrong. "Looking at this whole structure we started, we decided to make a secure socket-based service," says Klein. "We've always used, I would say, some sort of clustering technology to deploy our services and so the decision we came to was, this thing is going to be containerized, running on Docker."

    - -

    At the time – just over two years ago – Docker wasn't yet widely used, but as Klein points out, "it was certainly understood by the people who were on the frontier of technology. We started looking at potential technologies that existed. One of the limiting factors was that we needed to deploy multi-port non-http/https services. It wasn't really appropriate for some of the early cluster technology. We liked the project a lot and we ended up using it on other stuff for a while, but initially it was too targeted toward http workloads."

    - -

    Once Wink's backend engineering team decided on a Dockerized workload, they had to make decisions about the OS and the container orchestration platform. "Obviously you can't just start the containers and hope everything goes well," Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure."

    - -{{< case-studies/quote image="/images/case-studies/wink/banner4.jpg" >}} -"Obviously you can't just start the containers and hope everything goes well," Klein says with a laugh. "You need to have a system that is helpful [in order] to manage where the workloads are being distributed out to. And when the container inevitably dies or something like that, to restart it, you have a load balancer. All sorts of housekeeping work is needed to have a robust infrastructure." -{{< /case-studies/quote >}} - -

    Wink considered building directly on a general purpose Linux distro like Ubuntu (which would have required installing tools to run a containerized workload) and cluster management systems like Mesos (which was targeted toward enterprises with larger teams/workloads), but ultimately set their sights on CoreOS Container Linux. "A container-optimized Linux distribution system was exactly what we needed," he says. "We didn't have to futz around with trying to take something like a Linux distro and install everything. It's got a built-in container orchestration system, which is Fleet, and an easy-to-use API. It's not as feature-rich as some of the heavier solutions, but we realized that, at that moment, it was exactly what we needed."

    - -

    Wink's hub (along with a revamped app) was introduced in July 2014 with a short-term deployment, and within the first month, they had moved the service to the Dockerized CoreOS deployment. Since then, they've moved almost every other piece of their infrastructure – from third-party cloud-to-cloud integrations to their customer service and payment portals – onto CoreOS Container Linux clusters.

    - -

    Using this setup did require some customization. "Fleet is really nice as a basic container orchestration system, but it doesn't take care of routing, sharing configurations, secrets, et cetera, among instances of a service," Klein says. "All of those layers of functionality can be implemented, of course, but if you don't want to spend a lot of time writing unit files manually – which of course nobody does – you need to create a tool to automate some of that, which we did."

    - -

    Wink quickly embraced the Kubernetes container cluster manager when it was launched in 2015 and integrated with CoreOS core technology, and as promised, it ended up providing the features Wink wanted and had planned to build. "If not for Kubernetes, we likely would have taken the logic and library we implemented for the automation tool that we created, and would have used it in a higher level abstraction and tool that could be used by non-DevOps engineers from the command line to create and manage clusters," Klein says. "But Kubernetes made that totally unnecessary – and is written and maintained by people with a lot more experience in cluster management than us, so all the better." Now, an estimated 80 percent of Wink's workload is run on Kubernetes on top of CoreOS Container Linux.

    - -{{< case-studies/quote >}} -"Stay close to the development. Understand why decisions are being made. If you understand the intent behind the project, from the technological intent to a certain philosophical intent, then it helps you understand how to build your system in harmony with those systems as opposed to trying to work against it." -{{< /case-studies/quote >}} - -

    Wink's reasons for going all in are clear: "It's not proprietary, it's totally open, it's really portable," Klein says. "You can run all the workloads across different cloud providers. You can easily run a hybrid AWS or even bring in your own data center. That's the benefit of having everything unified on one Kubernetes-Docker-CoreOS Container Linux stack. There are massive security benefits if you only have one Linux distro to try to validate. The benefits are enormous because you save money, you save time."

    - -

    Klein concedes that there are tradeoffs in every technology decision. "Cutting-edge technology is going to be scary for some people," he says. "In order to take advantage of this, you really have to keep up with the technology. You can't treat it like it's a black box. Stay close to the development. Understand why decisions are being made. If you understand the intent behind the project, from the technological intent to a certain philosophical intent, then it helps you understand how to build your system in harmony with those systems as opposed to trying to work against it."

    - -

    Wink, which was acquired by Flex in 2015, now controls 2.3 million connected devices in households all over the country. What's next for the company? A new version of the hub - Wink Hub 2 - hit shelves last November – and is being offered for the first time at Walmart stores in addition to Home Depot. "Two of the biggest American retailers are carrying and promoting the brand and the hardware," Klein says proudly – though he adds that "it really comes with a lot of pressure. It's not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses." And that's further testament to how much faith Klein has in the infrastructure that the Wink team has have built.

    - -

    Wink's engineering team has grown exponentially since its early days, and behind the scenes, Klein is most excited about the machine learning Wink is using. "We built [a system of] containerized small sections of the data pipeline that feed each other and can have multiple outputs," he says. "It's like data pipelines as microservices." Again, Klein points to having a unified stack running on CoreOS Container Linux and Kubernetes as the primary driver for the innovations to come. "You're not reinventing the wheel every time," he says. "You can just get down to work."

    diff --git a/content/ko/case-studies/wink/wink_featured.png b/content/ko/case-studies/wink/wink_featured.png deleted file mode 100644 index 3c01133bef..0000000000 Binary files a/content/ko/case-studies/wink/wink_featured.png and /dev/null differ diff --git a/content/ko/case-studies/wink/wink_logo.png b/content/ko/case-studies/wink/wink_logo.png deleted file mode 100644 index ef2ee30bf3..0000000000 Binary files a/content/ko/case-studies/wink/wink_logo.png and /dev/null differ diff --git a/content/ko/case-studies/workiva/index.html b/content/ko/case-studies/workiva/index.html deleted file mode 100644 index d8945bfd34..0000000000 --- a/content/ko/case-studies/workiva/index.html +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Workiva Case Study -linkTitle: Workiva -case_study_styles: true -cid: caseStudies -draft: true -featured: true -weight: 20 -quote: > - With OpenTracing, my team was able to look at a trace and make optimization suggestions to another team without ever looking at their code. - -new_case_study_styles: true -heading_background: /images/case-studies/workiva/banner1.jpg -heading_title_logo: /images/workiva_logo.png -subheading: > - Using OpenTracing to Help Pinpoint the Bottlenecks -case_study_details: - - Company: Workiva - - Location: Ames, Iowa - - Industry: Enterprise Software ---- - -

    Challenge

    - -

    Workiva offers a cloud-based platform for managing and reporting business data. This SaaS product, Wdesk, is used by more than 70 percent of the Fortune 500 companies. As the company made the shift from a monolith to a more distributed, microservice-based system, "We had a number of people working on this, all on different teams, so we needed to identify what the issues were and where the bottlenecks were," says Senior Software Architect MacLeod Broad. With back-end code running on Google App Engine, Google Compute Engine, as well as Amazon Web Services, Workiva needed a tracing system that was agnostic of platform. While preparing one of the company's first products utilizing AWS, which involved a "sync and link" feature that linked data from spreadsheets built in the new application with documents created in the old application on Workiva's existing system, Broad's team found an ideal use case for tracing: There were circular dependencies, and optimizations often turned out to be micro-optimizations that didn't impact overall speed.

    - -

    Solution

    - -

    Broad's team introduced the platform-agnostic distributed tracing system OpenTracing to help them pinpoint the bottlenecks.

    - -

    Impact

    - -

    Now used throughout the company, OpenTracing produced immediate results. Software Engineer Michael Davis reports: "Tracing has given us immediate, actionable insight into how to improve our service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."

    - -{{< case-studies/quote author="MacLeod Broad, Senior Software Architect at Workiva" >}} -"With OpenTracing, my team was able to look at a trace and make optimization suggestions to another team without ever looking at their code." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -Last fall, MacLeod Broad's platform team at Workiva was prepping one of the company's first products utilizing Amazon Web Services when they ran into a roadblock. -{{< /case-studies/lead >}} - -

    Early on, Workiva's backend had run mostly on Google App Engine. But things changed along the way as Workiva's SaaS offering, Wdesk, a cloud-based platform for managing and reporting business data, grew its customer base to more than 70 percent of the Fortune 500 companies. "As customer needs grew and the product offering expanded, we started to leverage a wider offering of services such as Amazon Web Services as well as other Google Cloud Platform services, creating a multi-vendor environment."

    - -

    With this new product, there was a "sync and link" feature by which data "went through a whole host of services starting with the new spreadsheet system [Amazon Aurora] into what we called our linking system, and then pushed through http to our existing system, and then a number of calculations would go on, and the results would be transmitted back into the new system," says Broad. "We were trying to optimize that for speed. We thought we had made this great optimization and then it would turn out to be a micro optimization, which didn't really affect the overall speed of things."

    - -

    The challenges faced by Broad's team may sound familiar to other companies that have also made the shift from monoliths to more distributed, microservice-based systems. "We had a number of people working on this, all on different teams, so it was difficult to get our head around what the issues were and where the bottlenecks were," says Broad.

    - -

    "Each service team was going through different iterations of their architecture and it was very hard to follow what was actually going on in each teams' system," he adds. "We had circular dependencies where we'd have three or four different service teams unsure of where the issues really were, requiring a lot of back and forth communication. So we wasted a lot of time saying, 'What part of this is slow? Which part of this is sometimes slow depending on the use case? Which part is degrading over time? Which part of this process is asynchronous so it doesn't really matter if it's long-running or not? What are we doing that's redundant, and which part of this is buggy?'"

    - -{{< case-studies/quote - image="/images/case-studies/workiva/banner3.jpg" - author="MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA" ->}} -"A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level. Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it's a lot faster than never figuring out the problem and just moving on." -{{< /case-studies/quote >}} - -

    Simply put, it was an ideal use case for tracing. "A tracing system can at a glance explain an architecture, narrow down a performance bottleneck and zero in on it, and generally just help direct an investigation at a high level," says Broad. "Being able to do that at a glance is much faster than at a meeting or with three days of debugging, and it's a lot faster than never figuring out the problem and just moving on."

    - -

    With Workiva's back-end code running on Google Compute Engine as well as App Engine and AWS, Broad knew that he needed a tracing system that was platform agnostic. "We were looking at different tracing solutions," he says, "and we decided that because it seemed to be a very evolving market, we didn't want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use."

    - -

    Once they introduced OpenTracing into this first use case, Broad says, "The trace made it super obvious where the bottlenecks were." Even though everyone had assumed it was Workiva's existing code that was slowing things down, that wasn't exactly the case. "It looked like the existing code was slow only because it was reaching out to our next-generation services, and they were taking a very long time to service all those requests," says Broad. "On the waterfall graph you can see the exact same work being done on every request when it was calling back in. So every service request would look the exact same for every response being paged out. And then it was just a no-brainer of, 'Why is it doing all this work again?'"

    - -

    Using the insight OpenTracing gave them, "My team was able to look at a trace and make optimization suggestions to another team without ever looking at their code," says Broad. "The way we named our traces gave us insight whether it's doing a SQL call or it's making an RPC. And so it was really easy to say, 'OK, we know that it's going to page through all these requests. Do the work once and stuff it in cache.' And we were done basically. All those calls became sub-second calls immediately."

    - -{{< case-studies/quote - image="/images/case-studies/workiva/banner4.jpg" - author="MACLEOD BROAD, SENIOR SOFTWARE ARCHITECT AT WORKIVA" ->}} -"We were looking at different tracing solutions and we decided that because it seemed to be a very evolving market, we didn't want to get stuck with one vendor. So OpenTracing seemed like the cleanest way to avoid vendor lock-in on what backend we actually had to use." -{{< /case-studies/quote >}} - -

    After the success of the first use case, everyone involved in the trial went back and fully instrumented their products. Tracing was added to a few more use cases. "We wanted to get through the initial implementation pains early without bringing the whole department along for the ride," says Broad. "Now, a lot of teams add it when they're starting up a new service. We're really pushing adoption now more than we were before."

    - -

    Some teams were won over quickly. "Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service," says Software Engineer Michael Davis. "Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix."

    - -

    Most of Workiva's major products are now traced using OpenTracing, with data pushed into Google StackDriver. Even the products that aren't fully traced have some components and libraries that are.

    - -

    Broad points out that because some of the engineers were working on App Engine and already had experience with the platform's Appstats library for profiling performance, it didn't take much to get them used to using OpenTracing. But others were a little more reluctant. "The biggest hindrance to adoption I think has been the concern about how much latency is introducing tracing [and StackDriver] going to cost," he says. "People are also very concerned about adding middleware to whatever they're working on. Questions about passing the context around and how that's done were common. A lot of our Go developers were fine with it, because they were already doing that in one form or another. Our Java developers were not super keen on doing that because they'd used other systems that didn't require that."But the benefits clearly outweighed the concerns, and today, Workiva's official policy is to use tracing."

    - -

    In fact, Broad believes that tracing naturally fits in with Workiva's existing logging and metrics systems. "This was the way we presented it internally, and also the way we designed our use," he says. "Our traces are logged in the exact same mechanism as our app metric and logging data, and they get pushed the exact same way. So we treat all that data exactly the same when it's being created and when it's being recorded. We have one internal library that we use for logging, telemetry, analytics and tracing."

    - -{{< case-studies/quote author="Michael Davis, Software Engineer, Workiva" >}} -"Tracing has given us immediate, actionable insight into how to improve our [Workspaces] service. Through a combination of seeing where each call spends its time, as well as which calls are most often used, we were able to reduce our average response time by 95 percent (from 600ms to 30ms) in a single fix." -{{< /case-studies/quote >}} - -

    For Workiva, OpenTracing has become an essential tool for zeroing in on optimizations and determining what's actually a micro-optimization by observing usage patterns. "On some projects we often assume what the customer is doing, and we optimize for these crazy scale cases that we hit 1 percent of the time," says Broad. "It's been really helpful to be able to say, 'OK, we're adding 100 milliseconds on every request that does X, and we only need to add that 100 milliseconds if it's the worst of the worst case, which only happens one out of a thousand requests or one out of a million requests."

    - -

    Unlike many other companies, Workiva also traces the client side. "For us, the user experience is important—it doesn't matter if the RPC takes 100 milliseconds if it still takes 5 seconds to do the rendering to show it in the browser," says Broad. "So for us, those client times are important. We trace it to see what parts of loading take a long time. We're in the middle of working on a definition of what is 'loaded.' Is it when you have it, or when it's rendered, or when you can interact with it? Those are things we're planning to use tracing for to keep an eye on and to better understand."

    - -

    That also requires adjusting for differences in external and internal clocks. "Before time correcting, it was horrible; our traces were more misleading than anything," says Broad. "So we decided that we would return a timestamp on the response headers, and then have the client reorient its time based on that—not change its internal clock but just calculate the offset on the response time to when the client got it. And if you end up in an impossible situation where a client RPC spans 210 milliseconds but the time on the response time is outside of that window, then we have to reorient that."

    - -

    Broad is excited about the impact OpenTracing has already had on the company, and is also looking ahead to what else the technology can enable. One possibility is using tracing to update documentation in real time. "Keeping documentation up to date with reality is a big challenge," he says. "Say, we just ran a trace simulation or we just ran a smoke test on this new deploy, and the architecture doesn't match the documentation. We can find whose responsibility it is and let them know and have them update it. That's one of the places I'd like to get in the future with tracing."

    diff --git a/content/ko/case-studies/workiva/workiva_featured_logo.png b/content/ko/case-studies/workiva/workiva_featured_logo.png deleted file mode 100644 index 9998b47104..0000000000 Binary files a/content/ko/case-studies/workiva/workiva_featured_logo.png and /dev/null differ diff --git a/content/ko/case-studies/yahoo-japan/index.html b/content/ko/case-studies/yahoo-japan/index.html deleted file mode 100644 index 724a41ae01..0000000000 --- a/content/ko/case-studies/yahoo-japan/index.html +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Yahoo! Japan -content_url: https://kubernetes.io/blog/2016/10/kubernetes-and-openstack-at-yahoo-japan ---- \ No newline at end of file diff --git a/content/ko/case-studies/yahoo-japan/yahooJapan_logo.png b/content/ko/case-studies/yahoo-japan/yahooJapan_logo.png deleted file mode 100644 index 3cbea39598..0000000000 Binary files a/content/ko/case-studies/yahoo-japan/yahooJapan_logo.png and /dev/null differ diff --git a/content/ko/case-studies/ygrene/index.html b/content/ko/case-studies/ygrene/index.html deleted file mode 100644 index 9afc1ec45b..0000000000 --- a/content/ko/case-studies/ygrene/index.html +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: Ygrene Case Study -linkTitle: Ygrene -case_study_styles: true -cid: caseStudies -logo: ygrene_featured_logo.png -featured: true -weight: 48 -quote: > - We had to change some practices and code, and the way things were built, but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That's very fast for a finance company. - -new_case_study_styles: true -heading_background: /images/case-studies/ygrene/banner1.jpg -heading_title_logo: /images/ygrene_logo.png -subheading: > - Ygrene: Using Cloud Native to Bring Security and Scalability to the Finance Industry -case_study_details: - - Company: Ygrene - - Location: Petaluma, Calif. - - Industry: Clean energy financing ---- - -

    Challenge

    - -

    A PACE (Property Assessed Clean Energy) financing company, Ygrene has funded more than $1 billion in loans since 2010. In order to approve and process those loans, "We have lots of data sources that are being aggregated, and we also have lots of systems that need to churn on that data," says Ygrene Development Manager Austin Adams. The company was utilizing massive servers, and "we just reached the limit of being able to scale them vertically. We had a really unstable system that became overwhelmed with requests just for doing background data processing in real time. The performance the users saw was very poor. We needed a solution that wouldn't require us to make huge refactors to the code base." As a finance company, Ygrene also needed to ensure that they were shipping their applications securely.

    - -

    Solution

    - -

    Moving from an Engine Yard platform and Amazon Elastic Beanstalk, the Ygrene team embraced cloud native technologies and practices: Kubernetes to help scale out vertically and distribute workloads, Notary to put in build-time controls and get trust on the Docker images being used with third-party dependencies, and Fluentd for "observing every part of our stack," all running on Amazon EC2 Spot.

    - -

    Impact

    - -

    Before, deployments typically took three to four hours, and two or three months' worth of work would be deployed at low-traffic times every week or two weeks. Now, they take five minutes for Kubernetes, and an hour for the overall deploy with smoke testing. And "we're able to deploy three or four times a week, with just one week's or two days' worth of work," Adams says. "We're deploying during the work week, in the daytime and without any downtime. We had to ask for business approval to take the systems down, even in the middle of the night, because people could be doing loans. Now we can deploy, ship code, and migrate databases, all without taking the system down. The company gets new features without worrying that some business will be lost or delayed." Additionally, by using the kops project, Ygrene can now run its Kubernetes clusters with AWS EC2 Spot, at a tenth of the previous cost. These cloud native technologies have "changed the game for scalability, observability, and security—we're adding new data sources that are very secure," says Adams. "Without Kubernetes, Notary, and Fluentd, we couldn't tell our investors and team members that we knew what was going on."

    - -{{< case-studies/quote author="Austin Adams, Development Manager, Ygrene Energy Fund" >}} -"CNCF projects are helping Ygrene determine the security and observability standards for the entire PACE industry. We're an emerging finance industry, and without these projects, especially Kubernetes, we couldn't be the industry leader that we are today." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -In less than a decade, Ygrene has funded more than $1 billion in loans for renewable energy projects. -{{< /case-studies/lead >}} - -

    A PACE (Property Assessed Clean Energy) financing company, "We take the equity in a home or a commercial building, and use it to finance property improvements for anything that saves electricity, produces electricity, saves water, or reduces carbon emissions," says Development Manager Austin Adams.

    - -

    In order to approve those loans, the company processes an enormous amount of underwriting data. "We have tons of different points that we have to validate about the property, about the company, or about the person," Adams says. "So we have lots of data sources that are being aggregated, and we also have lots of systems that need to churn on that data in real time."

    - -

    By 2017, deployments and scalability had become pain points. The company was utilizing massive servers, and "we just reached the limit of being able to scale them vertically," he says. Migrating to AWS Elastic Beanstalk didn't solve the problem: "The Scala services needed a lot of data from the main Ruby on Rails services and from different vendors, so they were asking for information from our Ruby services at a rate that those services couldn't handle. We had lots of configuration misses with Elastic Beanstalk as well. It just came to a head, and we realized we had a really unstable system."

    - -{{< case-studies/quote - image="/images/case-studies/ygrene/banner3.jpg" - author="Austin Adams, Development Manager, Ygrene Energy Fund" ->}} -"CNCF has been an amazing incubator for so many projects. Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It's actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable." -{{< /case-studies/quote >}} - -

    Adams along with the rest of the team set out to find a solution that would be transformational, but "wouldn't require us to make huge refactors to the code base," he says. And as a finance company, Ygrene needed security as much as scalability. They found the answer by embracing cloud native technologies: Kubernetes to help scale out vertically and distribute workloads, Notary to achieve reliable security at every level, and Fluentd for observability. "Kubernetes was where the community was going, and we wanted to be future proof," says Adams.

    - -

    With Kubernetes, the team was able to quickly containerize the Ygrene application with Docker. "We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That's very fast for a finance company."

    - -

    How? Cloud native has "changed the game for scalability, observability, and security—we're adding new data sources that are very secure," says Adams. "Without Kubernetes, Notary, and Fluentd, we couldn't tell our investors and team members that we knew what was going on."

    - -

    Notary, in particular, "has been a godsend," says Adams. "We need to know that our attack surface on third-party dependencies is low, or at least managed. We use it as a trust system and we also use it as a separation, so production images are signed by Notary, but some development images we don't sign. That is to ensure that they can't get into the production cluster. We've been using it in the test cluster to feel more secure about our builds."

    - -{{< case-studies/quote image="/images/case-studies/ygrene/banner4.jpg">}} -"We had to change some practices and code, and the way things were built," Adams says, "but we were able to get our main systems onto Kubernetes in a month or so, and then into production within two months. That's very fast for a finance company." -{{< /case-studies/quote >}} - -

    By using the kops project, Ygrene was able to move from Elastic Beanstalk to running its Kubernetes clusters on AWS EC2 Spot, at a tenth of the previous cost. "In order to scale before, we would need to up our instance sizes, incurring high cost for low value," says Adams. "Now with Kubernetes and kops, we are able to scale horizontally on Spot with multiple instance groups."

    - -

    That also helped them mitigate the risk that comes with running in the public cloud. "We figured out, essentially, that if we're able to select instance classes using EC2 Spot that had an extremely low likelihood of interruption and zero history of interruption, and we're willing to pay a price high enough, that we could virtually get the same guarantee using Kubernetes because we have enough nodes," says Software Engineer Zach Arnold, who led the migration to Kubernetes. "Now that we've re-architected these pieces of the application to not live on the same server, we can push out to many different servers and have a more stable deployment."

    - -

    As a result, the team can now ship code any time of day. "That was risky because it could bring down your whole loan management software with it," says Arnold. "But we now can deploy safely and securely during the day."

    - -{{< case-studies/quote >}} -"In order to scale before, we would need to up our instance sizes, incurring high cost for low value," says Adams. "Now with Kubernetes and kops, we are able to scale horizontally on Spot with multiple instance groups." -{{< /case-studies/quote >}} - -

    Before, deployments typically took three to four hours, and two or three months' worth of work would be deployed at low-traffic times every week or two weeks. Now, they take five minutes for Kubernetes, and an hour for an overall deploy with smoke testing. And "we're able to deploy three or four times a week, with just one week's or two days' worth of work," Adams says. "We're deploying during the work week, in the daytime and without any downtime. We had to ask for business approval to take the systems down for 30 minutes to an hour, even in the middle of the night, because people could be doing loans. Now we can deploy, ship code, and migrate databases, all without taking the system down. The company gets new features without worrying that some business will be lost or delayed."

    - -

    Cloud native also affected how Ygrene's 50+ developers and contractors work. Adams and Arnold spent considerable time "teaching people to think distributed out of the box," says Arnold. "We ended up picking what we call the Four S's of Shipping: safely, securely, stably, and speedily." (For more on the security piece of it, see their article on their "continuous hacking" strategy.) As for the engineers, says Adams, "they have been able to advance as their software has advanced. I think that at the end of the day, the developers feel better about what they're doing, and they also feel more connected to the modern software development community."

    - -

    Looking ahead, Adams is excited to explore more CNCF projects, including SPIFFE and SPIRE. "CNCF has been an amazing incubator for so many projects," he says. "Now we look at its webpage regularly to find out if there are any new, awesome, high-quality projects we can implement into our stack. It's actually become a hub for us for knowing what software we need to be looking at to make our systems more secure or more scalable."

    diff --git a/content/ko/case-studies/ygrene/ygrene_featured_logo.png b/content/ko/case-studies/ygrene/ygrene_featured_logo.png deleted file mode 100644 index d0d6911478..0000000000 Binary files a/content/ko/case-studies/ygrene/ygrene_featured_logo.png and /dev/null differ diff --git a/content/ko/case-studies/zalando/index.html b/content/ko/case-studies/zalando/index.html deleted file mode 100644 index 23363da401..0000000000 --- a/content/ko/case-studies/zalando/index.html +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: Zalando Case Study -case_study_styles: true -cid: caseStudies - -new_case_study_styles: true -heading_background: /images/case-studies/zalando/banner1.jpg -heading_title_logo: /images/zalando_logo.png -subheading: > - Europe's Leading Online Fashion Platform Gets Radical with Cloud Native -case_study_details: - - Company: Zalando - - Location: Berlin, Germany - - Industry: Online Fashion ---- - -

    Challenge

    - -

    Zalando, Europe's leading online fashion platform, has experienced exponential growth since it was founded in 2008. In 2015, with plans to further expand its original e-commerce site to include new services and products, Zalando embarked on a radical transformation resulting in autonomous self-organizing teams. This change requires an infrastructure that could scale with the growth of the engineering organization. Zalando's technology department began rewriting its applications to be cloud-ready and started moving its infrastructure from on-premise data centers to the cloud. While orchestration wasn't immediately considered, as teams migrated to Amazon Web Services (AWS): "We saw the pain teams were having with infrastructure and Cloud Formation on AWS," says Henning Jacobs, Head of Developer Productivity. "There's still too much operational overhead for the teams and compliance. " To provide better support, cluster management was brought into play.

    - -

    Solution

    - -

    The company now runs its Docker containers on AWS using Kubernetes orchestration.

    - -

    Impact

    - -

    With the old infrastructure "it was difficult to properly embrace new technologies, and DevOps teams were considered to be a bottleneck," says Jacobs. "Now, with this cloud infrastructure, they have this packaging format, which can contain anything that runs on the Linux kernel. This makes a lot of people pretty happy. The engineers love autonomy."

    - -{{< case-studies/quote author="Henning Jacobs, Head of Developer Productivity at Zalando" >}} -"We envision all Zalando delivery teams running their containerized applications on a state-of-the-art, reliable and scalable cluster infrastructure provided by Kubernetes." -{{< /case-studies/quote >}} - -{{< case-studies/lead >}} -When Henning Jacobs arrived at Zalando in 2010, the company was just two years old with 180 employees running an online store for European shoppers to buy fashion items. -{{< /case-studies/lead >}} - -

    "It started as a PHP e-commerce site which was easy to get started with, but was not scaling with the business' needs" says Jacobs, Head of Developer Productivity at Zalando.

    - -

    At that time, the company began expanding beyond its German origins into other European markets. Fast-forward to today and Zalando now has more than 14,000 employees, 3.6 billion Euro in revenue for 2016 and operates across 15 countries. "With growth in all dimensions, and constant scaling, it has been a once-in-a-lifetime experience," he says.

    - -

    Not to mention a unique opportunity for an infrastructure specialist like Jacobs. Just after he joined, the company began rewriting all their applications in-house. "That was generally our strategy," he says. "For example, we started with our own logistics warehouses but at first you don't know how to do logistics software, so you have some vendor software. And then we replaced it with our own because with off-the-shelf software you're not competitive. You need to optimize these processes based on your specific business needs."

    - -

    In parallel to rewriting their applications, Zalando had set a goal of expanding beyond basic e-commerce to a platform offering multi-tenancy, a dramatic increase in assortments and styles, same-day delivery and even your own personal online stylist.

    - -

    The need to scale ultimately led the company on a cloud-native journey. As did its embrace of a microservices-based software architecture that gives engineering teams more autonomy and ownership of projects. "This move to the cloud was necessary because in the data center you couldn't have autonomous teams. You have the same infrastructure and it was very homogeneous, so you could only run your Java or Python app," Jacobs says.

    - -{{< case-studies/quote image="/images/case-studies/zalando/banner3.jpg" >}} -"This move to the cloud was necessary because in the data center you couldn't have autonomous teams. You have the same infrastructure and it was very homogeneous, so you could only run your Java or Python app." -{{< /case-studies/quote >}} - -

    Zalando began moving its infrastructure from two on-premise data centers to the cloud, requiring the migration of older applications for cloud-readiness. "We decided to have a clean break," says Jacobs. "Our Amazon Web Services infrastructure was set up like so: Every team has its own AWS account, which is completely isolated, meaning there's no 'lift and shift.' You basically have to rewrite your application to make it cloud-ready even down to the persistence layer. We bravely went back to the drawing board and redid everything, first choosing Docker as a common containerization, then building the infrastructure from there."

    - -

    The company decided to hold off on orchestration at the beginning, but as teams were migrated to AWS, "we saw the pain teams were having with infrastructure and cloud formation on AWS," says Jacobs.

    - -

    Zalandos 200+ autonomous engineering teams decide what technologies to use and could operate their own applications using their own AWS accounts. This setup proved to be a compliance challenge. Even with strict rules-of-play and automated compliance checks in place, engineering teams and IT-compliance were overburdened addressing compliance issues. "Violations appear for non-compliant behavior, which we detect when scanning the cloud infrastructure," says Jacobs. "Everything is possible and nothing enforced, so you have to live with violations (and resolve them) instead of preventing the error in the first place. This means overhead for teams—and overhead for compliance and operations. It also takes time to spin up new EC2 instances on AWS, which affects our deployment velocity."

    - -

    The team realized they needed to "leverage the value you get from cluster management," says Jacobs. When they first looked at Platform as a Service (PaaS) options in 2015, the market was fragmented; but "now there seems to be a clear winner. It seemed like a good bet to go with Kubernetes."

    - -

    The transition to Kubernetes started in 2016 during Zalando's Hack Week where participants deployed their projects to a Kubernetes cluster. From there 60 members of the tech infrastructure department were on-boarded - and then engineering teams were brought on one at a time. "We always start by talking with them and make sure everyone's expectations are clear," says Jacobs. "Then we conduct some Kubernetes training, which is mostly training for our CI/CD setup, because the user interface for our users is primarily through the CI/CD system. But they have to know fundamental Kubernetes concepts and the API. This is followed by a weekly sync with each team to check their progress. Once they have something in production, we want to see if everything is fine on top of what we can improve."

    - -{{< case-studies/quote image="/images/case-studies/zalando/banner4.jpg" >}} -Once Zalando began migrating applications to Kubernetes, the results were immediate. "Kubernetes is a cornerstone for our seamless end-to-end developer experience. We are able to ship ideas to production using a single consistent and declarative API," says Jacobs. -{{< /case-studies/quote >}} - -

    At the moment, Zalando is running an initial 40 Kubernetes clusters with plans to scale for the foreseeable future. Once Zalando began migrating applications to Kubernetes, the results were immediate. "Kubernetes is a cornerstone for our seamless end-to-end developer experience. We are able to ship ideas to production using a single consistent and declarative API," says Jacobs. "The self-healing infrastructure provides a frictionless experience with higher-level abstractions built upon low-level best practices. We envision all Zalando delivery teams will run their containerized applications on a state-of-the-art reliable and scalable cluster infrastructure provided by Kubernetes."

    - -

    With the old on-premise infrastructure "it was difficult to properly embrace new technologies, and DevOps teams were considered to be a bottleneck," says Jacobs. "Now, with this cloud infrastructure, they have this packaging format, which can contain anything that runs in the Linux kernel. This makes a lot of people pretty happy. The engineers love the autonomy."

    - -

    There were a few challenges in Zalando's Kubernetes implementation. "We are a team of seven people providing clusters to different engineering teams, and our goal is to provide a rock-solid experience for all of them," says Jacobs. "We don't want pet clusters. We don't want to have to understand what workload they have; it should just work out of the box. With that in mind, cluster autoscaling is important. There are many different ways of doing cluster management, and this is not part of the core. So we created two components to provision clusters, have a registry for clusters, and to manage the whole cluster life cycle."

    - -

    Jacobs's team also worked to improve the Kubernetes-AWS integration. "Thus you're very restricted. You need infrastructure to scale each autonomous team's idea." Plus, "there are still a lot of best practices missing," says Jacobs. The team, for example, recently solved a pod security policy issue. "There was already a concept in Kubernetes but it wasn't documented, so it was kind of tricky," he says. The large Kubernetes community was a big help to resolve the issue. To help other companies start down the same path, Jacobs compiled his team's learnings in a document called Running Kubernetes in Production.

    - -{{< case-studies/quote >}} -"The Kubernetes API allows us to run applications in a cloud provider-agnostic way, which gives us the freedom to revisit IaaS providers in the coming years... We expect the Kubernetes API to be the global standard for PaaS infrastructure and are excited about the continued journey." -{{< /case-studies/quote >}} - -

    In the end, Kubernetes made it possible for Zalando to introduce and maintain the new products the company envisioned to grow its platform. "The fashion advice product used Scala, and there were struggles to make this possible with our former infrastructure," says Jacobs. "It was a workaround, and that team needed more and more support from the platform team, just because they used different technologies. Now with Kubernetes, it's autonomous. Whatever the workload is, that team can just go their way, and Kubernetes prevents other bottlenecks."

    - -

    Looking ahead, Jacobs sees Zalando's new infrastructure as a great enabler for other things the company has in the works, from its new logistics software, to a platform feature connecting brands, to products dreamed up by data scientists. "One vision is if you watch the next James Bond movie and see the suit he's wearing, you should be able to automatically order it, and have it delivered to you within an hour," says Jacobs. "It's about connecting the full fashion sphere. This is definitely not possible if you have a bottleneck with everyone running in the same data center and thus very restricted. You need infrastructure to scale each autonomous team's idea."

    - -

    For other companies considering this technology, Jacobs says he wouldn't necessarily advise doing it exactly the same way Zalando did. "It's okay to do so if you're ready to fail at some things," he says. "You need to set the right expectations. Not everything will work. Rewriting apps and this type of organizational change can be disruptive. The first product we moved was critical. There were a lot of dependencies, and it took longer than expected. Maybe we should have started with something less complicated, less business critical, just to get our toes wet."

    - -

    But once they got to the other side "it was clear for everyone that there's no big alternative," Jacobs adds. "The Kubernetes API allows us to run applications in a cloud provider-agnostic way, which gives us the freedom to revisit IaaS providers in the coming years. Zalando Technology benefits from migrating to Kubernetes as we are able to leverage our existing knowledge to create an engineering platform offering flexibility and speed to our engineers while significantly reducing the operational overhead. We expect the Kubernetes API to be the global standard for PaaS infrastructure and are excited about the continued journey."

    diff --git a/content/ko/case-studies/zalando/zalando_feature_logo.png b/content/ko/case-studies/zalando/zalando_feature_logo.png deleted file mode 100644 index ba6251050d..0000000000 Binary files a/content/ko/case-studies/zalando/zalando_feature_logo.png and /dev/null differ diff --git a/content/ko/community/_index.html b/content/ko/community/_index.html index 40bea7b523..0fa8d8658a 100644 --- a/content/ko/community/_index.html +++ b/content/ko/community/_index.html @@ -24,7 +24,8 @@ cid: community 비디오      토론      이벤트와 모임들      -새소식 +새소식      +릴리즈


    diff --git a/content/ko/docs/concepts/architecture/cloud-controller.md b/content/ko/docs/concepts/architecture/cloud-controller.md index f7666ef0c3..e5e7d315c5 100644 --- a/content/ko/docs/concepts/architecture/cloud-controller.md +++ b/content/ko/docs/concepts/architecture/cloud-controller.md @@ -206,9 +206,11 @@ rules: [클라우드 컨트롤러 매니저 관리](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)에는 클라우드 컨트롤러 매니저의 실행과 관리에 대한 지침이 있다. +클라우드 컨트롤러 매니저를 사용하기 위해 HA 컨트롤 플레인을 업그레이드하려면, [클라우드 컨트롤러 매니저를 사용하기 위해 복제된 컨트롤 플레인 마이그레이션 하기](/docs/tasks/administer-cluster/controller-manager-leader-migration/)를 참고한다. + 자체 클라우드 컨트롤러 매니저를 구현하거나 기존 프로젝트를 확장하는 방법을 알고 싶은가? -클라우드 컨트롤러 매니저는 Go 인터페이스를 사용해서 모든 클라우드 플러그인을 구현할 수 있다. 구체적으로, [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)의 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)에 정의된 `CloudProvider` 인터페이스를 사용한다. +클라우드 컨트롤러 매니저는 Go 인터페이스를 사용함으로써, 어떠한 클라우드에 대한 구현체(implementation)라도 플러그인 될 수 있도록 한다. 구체적으로는, [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)의 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69)에 정의된 `CloudProvider` 인터페이스를 사용한다. 이 문서(노드, 라우트와 서비스)에서 강조된 공유 컨트롤러의 구현과 공유 cloudprovider 인터페이스와 함께 일부 스캐폴딩(scaffolding)은 쿠버네티스 핵심의 일부이다. 클라우드 공급자 전용 구현은 쿠버네티스의 핵심 바깥에 있으며 `CloudProvider` 인터페이스를 구현한다. diff --git a/content/ko/docs/concepts/architecture/control-plane-node-communication.md b/content/ko/docs/concepts/architecture/control-plane-node-communication.md index 1831692bdf..52fa728043 100644 --- a/content/ko/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/ko/docs/concepts/architecture/control-plane-node-communication.md @@ -8,14 +8,15 @@ aliases: -이 문서는 컨트롤 플레인(실제로는 API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다. +이 문서는 컨트롤 플레인(API 서버)과 쿠버네티스 클러스터 사이에 대한 통신 경로의 목록을 작성한다. 이는 사용자가 신뢰할 수 없는 네트워크(또는 클라우드 공급자의 완전한 퍼블릭 IP)에서 클러스터를 실행할 수 있도록 네트워크 구성을 강화하기 위한 맞춤 설치를 할 수 있도록 한다. ## 노드에서 컨트롤 플레인으로의 통신 -쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다(다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다). API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다. +쿠버네티스에는 "허브 앤 스포크(hub-and-spoke)" API 패턴을 가지고 있다. 노드(또는 노드에서 실행되는 파드들)의 모든 API 사용은 API 서버에서 종료된다. 다른 컨트롤 플레인 컴포넌트 중 어느 것도 원격 서비스를 노출하도록 설계되지 않았다. API 서버는 하나 이상의 클라이언트 [인증](/docs/reference/access-authn-authz/authentication/) 형식이 활성화된 보안 HTTPS 포트(일반적으로 443)에서 원격 연결을 수신하도록 구성된다. + 특히 [익명의 요청](/docs/reference/access-authn-authz/authentication/#anonymous-requests) 또는 [서비스 어카운트 토큰](/docs/reference/access-authn-authz/authentication/#service-account-tokens)이 허용되는 경우, 하나 이상의 [권한 부여](/ko/docs/reference/access-authn-authz/authorization/) 형식을 사용해야 한다. 노드는 유효한 클라이언트 자격 증명과 함께 API 서버에 안전하게 연결할 수 있도록 클러스터에 대한 공개 루트 인증서로 프로비전해야 한다. 예를 들어, 기본 GKE 배포에서, kubelet에 제공되는 클라이언트 자격 증명은 클라이언트 인증서 형식이다. kubelet 클라이언트 인증서의 자동 프로비저닝은 [kubelet TLS 부트스트랩](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 참고한다. @@ -50,20 +51,20 @@ API 서버에서 kubelet으로의 연결은 다음의 용도로 사용된다. ### API 서버에서 노드, 파드 및 서비스로의 통신 -API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 `https:` 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않으므로 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** . +API 서버에서 노드, 파드 또는 서비스로의 연결은 기본적으로 일반 HTTP 연결로 연결되므로 인증되거나 암호화되지 않는다. API URL에서 노드, 파드 또는 서비스 이름을 접두어 `https:` 로 사용하여 보안 HTTPS 연결을 통해 실행될 수 있지만, HTTPS 엔드포인트가 제공한 인증서의 유효성을 검증하지 않거나 클라이언트 자격 증명을 제공하지 않는다. 그래서 연결이 암호화되는 동안 무결성을 보장하지 않는다. 이러한 연결은 신뢰할 수 없는 네트워크 및/또는 공용 네트워크에서 실행하기에 **현재는 안전하지 않다** . ### SSH 터널 쿠버네티스는 SSH 터널을 지원하여 컨트롤 플레인에서 노드로의 통신 경로를 보호한다. 이 구성에서, API 서버는 클러스터의 각 노드에 SSH 터널을 시작하고(포트 22에서 수신 대기하는 ssh 서버에 연결) 터널을 통해 kubelet, 노드, 파드 또는 서비스로 향하는 모든 트래픽을 전달한다. 이 터널은 트래픽이 노드가 실행 중인 네트워크 외부에 노출되지 않도록 한다. -SSH 터널은 현재 더 이상 사용되지 않으므로 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다. +SSH 터널은 현재 더 이상 사용되지 않으므로, 수행 중인 작업이 어떤 것인지 모른다면 사용하면 안된다. Konnectivity 서비스는 이 통신 채널을 대체한다. ### Konnectivity 서비스 {{< feature-state for_k8s_version="v1.18" state="beta" >}} -SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크와 노드 네트워크에서 각각 실행되는 Konnectivity 서버와 Konnectivity 에이전트의 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다. +SSH 터널을 대체하는 Konnectivity 서비스는 컨트롤 플레인에서 클러스터 통신에 TCP 레벨 프록시를 제공한다. Konnectivity 서비스는 컨트롤 플레인 네트워크의 Konnectivity 서버와 노드 네트워크의 Konnectivity 에이전트, 두 부분으로 구성된다. Konnectivity 에이전트는 Konnectivity 서버에 대한 연결을 시작하고 네트워크 연결을 유지한다. Konnectivity 서비스를 활성화한 후, 모든 컨트롤 플레인에서 노드로의 트래픽은 이 연결을 통과한다. [Konnectivity 서비스 태스크](/docs/tasks/extend-kubernetes/setup-konnectivity/)에 따라 클러스터에서 Konnectivity 서비스를 설정한다. diff --git a/content/ko/docs/concepts/architecture/controller.md b/content/ko/docs/concepts/architecture/controller.md index e516dd9cc5..92afd615b6 100644 --- a/content/ko/docs/concepts/architecture/controller.md +++ b/content/ko/docs/concepts/architecture/controller.md @@ -159,11 +159,11 @@ IP 주소 관리 도구, 스토리지 서비스, 클라우드 제공자의 API 또는 쿠버네티스 외부에서 실행할 수 있다. 가장 적합한 것은 특정 컨트롤러의 기능에 따라 달라진다. - - ## {{% heading "whatsnext" %}} * [쿠버네티스 컨트롤 플레인](/ko/docs/concepts/overview/components/#컨트롤-플레인-컴포넌트)에 대해 읽기 * [쿠버네티스 오브젝트](/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/)의 몇 가지 기본 사항을 알아보자. * [쿠버네티스 API](/ko/docs/concepts/overview/kubernetes-api/)에 대해 더 배워 보자. -* 만약 자신만의 컨트롤러를 작성하기 원한다면, 쿠버네티스 확장하기의 [확장 패턴](/ko/docs/concepts/extend-kubernetes/extend-cluster/#익스텐션-패턴)을 본다. +* 만약 자신만의 컨트롤러를 작성하기 원한다면, + 쿠버네티스 확장하기의 [확장 패턴](/ko/docs/concepts/extend-kubernetes/#익스텐션-패턴)을 + 본다. diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md index cb65b2832a..3ab89472d8 100644 --- a/content/ko/docs/concepts/architecture/nodes.md +++ b/content/ko/docs/concepts/architecture/nodes.md @@ -1,4 +1,7 @@ --- + + + title: 노드 content_type: concept weight: 10 @@ -8,7 +11,8 @@ weight: 10 쿠버네티스는 컨테이너를 파드내에 배치하고 _노드_ 에서 실행함으로 워크로드를 구동한다. 노드는 클러스터에 따라 가상 또는 물리적 머신일 수 있다. 각 노드는 -{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에 의해 관리되며 +{{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에 +의해 관리되며 {{< glossary_tooltip text="파드" term_id="pod" >}}를 실행하는 데 필요한 서비스를 포함한다. @@ -63,6 +67,16 @@ kubelet이 노드의 `metadata.name` 필드와 일치하는 API 서버에 등록 노드 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. +### 노드 이름 고유성 + +[이름](/ko/docs/concepts/overview/working-with-objects/names#names)은 노드를 식별한다. 두 노드는 +동시에 같은 이름을 가질 수 없다. 쿠버네티스는 또한 같은 이름의 리소스가 +동일한 객체라고 가정한다. 노드의 경우, 동일한 이름을 사용하는 인스턴스가 동일한 +상태(예: 네트워크 설정, 루트 디스크 내용)를 갖는다고 암시적으로 가정한다. 인스턴스가 +이름을 변경하지 않고 수정된 경우 이로 인해 불일치가 발생할 수 있다. 노드를 대폭 교체하거나 +업데이트해야 하는 경우, 기존 노드 오브젝트를 먼저 API 서버에서 제거하고 +업데이트 후 다시 추가해야 한다. + ### 노드에 대한 자체-등록 kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API 서버에 @@ -233,6 +247,7 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳 - 노드가 계속 접근 불가할 경우 나중에 노드로부터 정상적인 종료를 이용해서 모든 파드를 축출 한다. ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고, 파드를 축출하기 시작하는 값은 5분이다. + 노드 컨트롤러는 매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다. #### 하트비트 @@ -261,18 +276,20 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할 #### 안정성 대부분의 경우, 노드 컨트롤러는 초당 `--node-eviction-rate`(기본값 0.1)로 -축출 비율을 제한한다. 이 말은 10초당 1개의 노드를 초과하여 +축출 속도를 제한한다. 이 말은 10초당 1개의 노드를 초과하여 파드 축출을 하지 않는다는 의미가 된다. 노드 축출 행위는 주어진 가용성 영역 내 하나의 노드가 상태가 불량할 경우 변화한다. 노드 컨트롤러는 영역 내 동시에 상태가 불량한 노드의 퍼센티지가 얼마나 되는지 체크한다(NodeReady 컨디션은 ConditionUnknown 또는 -ConditionFalse 다.). -- 상태가 불량한 노드의 일부가 최소 `--unhealthy-zone-threshold` - (기본값 0.55)가 되면 축출 비율은 감소한다. +ConditionFalse 다). +- 상태가 불량한 노드의 비율이 최소 `--unhealthy-zone-threshold` + (기본값 0.55)가 되면 축출 속도가 감소한다. - 클러스터가 작으면 (즉 `--large-cluster-size-threshold` - 노드 이하면 - 기본값 50) 축출은 중지되고, 그렇지 않으면 축출 비율은 초당 + 노드 이하면 - 기본값 50) 축출이 중지된다. +- 이외의 경우, 축출 속도는 초당 `--secondary-node-eviction-rate`(기본값 0.01)로 감소된다. + 이 정책들이 가용성 영역 단위로 실행되어지는 이유는 나머지가 연결되어 있는 동안 하나의 가용성 영역이 마스터로부터 분할되어 질 수도 있기 때문이다. 만약 클러스터가 여러 클라우드 제공사업자의 가용성 영역에 걸쳐 있지 않으면, @@ -281,7 +298,7 @@ ConditionFalse 다.). 노드가 가용성 영역들에 걸쳐 퍼져 있는 주된 이유는 하나의 전체 영역이 장애가 발생할 경우 워크로드가 상태 양호한 영역으로 이전되어질 수 있도록 하기 위해서이다. 그러므로, 하나의 영역 내 모든 노드들이 상태가 불량하면 노드 컨트롤러는 -`--node-eviction-rate` 의 정상 비율로 축출한다. 코너 케이스란 모든 영역이 +`--node-eviction-rate` 의 정상 속도로 축출한다. 코너 케이스란 모든 영역이 완전히 상태불량 (즉 클러스터 내 양호한 노드가 없는 경우) 한 경우이다. 이러한 경우, 노드 컨트롤러는 마스터 연결에 문제가 있어 일부 연결이 복원될 때까지 모든 축출을 중지하는 것으로 여긴다. @@ -292,13 +309,6 @@ ConditionFalse 다.). {{< glossary_tooltip text="테인트" term_id="taint" >}}를 추가한다. 이는 스케줄러가 비정상적인 노드에 파드를 배치하지 않게 된다. - -{{< caution >}} -`kubectl cordon` 은 노드를 'unschedulable'로 표기하는데, 이는 -서비스 컨트롤러가 이전에 자격 있는 로드밸런서 노드 대상 목록에서 해당 노드를 제거하기에 -사실상 cordon 된 노드에서 들어오는 로드 밸런서 트래픽을 제거하는 부작용을 갖는다. -{{< /caution >}} - ### 노드 용량 노드 오브젝트는 노드 리소스 용량에 대한 정보: 예를 들어, 사용 가능한 메모리의 @@ -329,14 +339,28 @@ ConditionFalse 다.). 자세한 내용은 [노드의 컨트롤 토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)을 본다. -## 그레이스풀(Graceful) 노드 셧다운 +## 그레이스풀(Graceful) 노드 셧다운 {#graceful-node-shutdown} -{{< feature-state state="alpha" for_k8s_version="v1.20" >}} +{{< feature-state state="beta" for_k8s_version="v1.21" >}} + +kubelet은 노드 시스템 셧다운을 감지하고 노드에서 실행 중인 파드를 종료하려고 시도한다. -`GracefulNodeShutdown` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한 경우 kubelet은 노드 시스템 종료를 감지하고 노드에서 실행 중인 파드를 종료한다. Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로세스](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를 따르도록 한다. -`GracefulNodeShutdown` 기능 게이트가 활성화되면 kubelet은 [systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)를 사용하여 주어진 기간 동안 노드 종료를 지연시킨다. 종료 중에 kubelet은 두 단계로 파드를 종료시킨다. +그레이스풀 노드 셧다운 기능은 +[systemd inhibitor locks](https://www.freedesktop.org/wiki/Software/systemd/inhibit/)를 +사용하여 주어진 기간 동안 노드 종료를 지연시키므로 systemd에 의존한다. + +그레이스풀 노드 셧다운은 1.21에서 기본적으로 활성화된 `GracefulNodeShutdown` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)로 +제어된다. + +기본적으로, 아래 설명된 두 구성 옵션, +`ShutdownGracePeriod` 및 `ShutdownGracePeriodCriticalPods` 는 모두 0으로 설정되어 있으므로, +그레이스풀 노드 셧다운 기능이 활성화되지 않는다. +기능을 활성화하려면, 두 개의 kubelet 구성 설정을 적절하게 구성하고 0이 아닌 값으로 설정해야 한다. + +그레이스풀 셧다운 중에 kubelet은 다음의 두 단계로 파드를 종료한다. 1. 노드에서 실행 중인 일반 파드를 종료시킨다. 2. 노드에서 실행 중인 [중요(critical) 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료시킨다. @@ -345,10 +369,28 @@ Kubelet은 노드가 종료되는 동안 파드가 일반 [파드 종료 프로 * `ShutdownGracePeriod`: * 노드가 종료를 지연해야 하는 총 기간을 지정한다. 이것은 모든 일반 및 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 파드 종료에 필요한 총 유예 기간에 해당한다. * `ShutdownGracePeriodCriticalPods`: - * 노드 종료 중에 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료하는 데 사용되는 기간을 지정한다. 이는 `ShutdownGracePeriod`보다 작아야 한다. + * 노드 종료 중에 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)를 종료하는 데 사용되는 기간을 지정한다. 이 값은 `ShutdownGracePeriod` 보다 작아야 한다. -예를 들어 `ShutdownGracePeriod=30s`, `ShutdownGracePeriodCriticalPods=10s` 인 경우 kubelet은 노드 종료를 30 초까지 지연시킨다. 종료하는 동안 처음 20(30-10) 초는 일반 파드의 유예 종료에 할당되고, 마지막 10 초는 [중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 종료에 할당된다. +예를 들어, `ShutdownGracePeriod=30s`, +`ShutdownGracePeriodCriticalPods=10s` 인 경우, kubelet은 노드 종료를 30초까지 +지연시킨다. 종료하는 동안 처음 20(30-10)초는 일반 파드의 +유예 종료에 할당되고, 마지막 10초는 +[중요 파드](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)의 종료에 할당된다. +{{< note >}} +그레이스풀 노드 셧다운 과정에서 축출된 파드는 `Failed` 라고 표시된다. +`kubectl get pods` 명령을 실행하면 축출된 파드의 상태가 `Shutdown`으로 표시된다. +그리고 `kubectl describe pod` 명령을 실행하면 노드 셧다운으로 인해 파드가 축출되었음을 알 수 있다. + +``` +Status: Failed +Reason: Shutdown +Message: Node is shutting, evicting pods +``` + +실패한 파드 오브젝트는 명시적으로 삭제하거나 [가비지 콜렉션에 의해 정리](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)되기 전까지는 보존된다. +이는 갑작스러운 노드 종료의 경우와 비교했을 때 동작에 차이가 있다. +{{< /note >}} ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/cluster-administration/_index.md b/content/ko/docs/concepts/cluster-administration/_index.md old mode 100755 new mode 100644 index 9870704596..f5363a45c2 --- a/content/ko/docs/concepts/cluster-administration/_index.md +++ b/content/ko/docs/concepts/cluster-administration/_index.md @@ -45,7 +45,7 @@ no_list: true ## 클러스터 보안 -* [인증서 생성](/ko/docs/tasks/administer-cluster/certificates/)는 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다. +* [인증서 생성](/ko/docs/tasks/administer-cluster/certificates/)은 다른 툴 체인을 사용하여 인증서를 생성하는 단계를 설명한다. * [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet으로 관리하는 컨테이너에 대한 환경을 설명한다. diff --git a/content/ko/docs/concepts/cluster-administration/addons.md b/content/ko/docs/concepts/cluster-administration/addons.md index 811f773626..270063a737 100644 --- a/content/ko/docs/concepts/cluster-administration/addons.md +++ b/content/ko/docs/concepts/cluster-administration/addons.md @@ -16,13 +16,14 @@ content_type: concept ## 네트워킹과 네트워크 폴리시 * [ACI](https://www.github.com/noironetworks/aci-containers)는 Cisco ACI로 통합 컨테이너 네트워킹 및 네트워크 보안을 제공한다. +* [Antrea](https://antrea.io/)는 레이어 3/4에서 작동하여 쿠버네티스를 위한 네트워킹 및 보안 서비스를 제공하며, Open vSwitch를 네트워킹 데이터 플레인으로 활용한다. * [Calico](https://docs.projectcalico.org/latest/introduction/)는 네트워킹 및 네트워크 폴리시 제공자이다. Calico는 유연한 네트워킹 옵션을 지원하므로 BGP 유무에 관계없이 비-오버레이 및 오버레이 네트워크를 포함하여 가장 상황에 맞는 옵션을 선택할 수 있다. Calico는 동일한 엔진을 사용하여 서비스 메시 계층(service mesh layer)에서 호스트, 파드 및 (이스티오(istio)와 Envoy를 사용하는 경우) 애플리케이션에 대한 네트워크 폴리시를 적용한다. * [Canal](https://github.com/tigera/canal/tree/master/k8s-install)은 Flannel과 Calico를 통합하여 네트워킹 및 네트워크 폴리시를 제공한다. * [Cilium](https://github.com/cilium/cilium)은 L3 네트워크 및 네트워크 폴리시 플러그인으로 HTTP/API/L7 폴리시를 투명하게 시행할 수 있다. 라우팅 및 오버레이/캡슐화 모드를 모두 지원하며, 다른 CNI 플러그인 위에서 작동할 수 있다. * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie)를 사용하면 쿠버네티스는 Calico, Canal, Flannel, Romana 또는 Weave와 같은 CNI 플러그인을 완벽하게 연결할 수 있다. * [Contiv](https://contiv.github.io)는 다양한 유스케이스와 풍부한 폴리시 프레임워크를 위해 구성 가능한 네트워킹(BGP를 사용하는 네이티브 L3, vxlan을 사용하는 오버레이, 클래식 L2 그리고 Cisco-SDN/ACI)을 제공한다. Contiv 프로젝트는 완전히 [오픈소스](https://github.com/contiv)이다. [인스톨러](https://github.com/contiv/install)는 kubeadm을 이용하거나, 그렇지 않은 경우에 대해서도 설치 옵션을 모두 제공한다. * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/)은 [Tungsten Fabric](https://tungsten.io)을 기반으로 하며, 오픈소스이고, 멀티 클라우드 네트워크 가상화 및 폴리시 관리 플랫폼이다. Contrail과 Tungsten Fabric은 쿠버네티스, OpenShift, OpenStack 및 Mesos와 같은 오케스트레이션 시스템과 통합되어 있으며, 가상 머신, 컨테이너/파드 및 베어 메탈 워크로드에 대한 격리 모드를 제공한다. -* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다. +* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually)은 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 제공자이다. * [Knitter](https://github.com/ZTE/Knitter/)는 쿠버네티스 파드에서 여러 네트워크 인터페이스를 지원하는 플러그인이다. * [Multus](https://github.com/Intel-Corp/multus-cni)는 쿠버네티스에서 SRIOV, DPDK, OVS-DPDK 및 VPP 기반 워크로드 외에 모든 CNI 플러그인(예: Calico, Cilium, Contiv, Flannel)을 지원하기 위해 쿠버네티스에서 다중 네트워크 지원을 위한 멀티 플러그인이다. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/)는 Open vSwitch(OVS) 프로젝트에서 나온 가상 네트워킹 구현인 [OVN(Open Virtual Network)](https://github.com/ovn-org/ovn/)을 기반으로 하는 쿠버네티스용 네트워킹 제공자이다. OVN-Kubernetes는 OVS 기반 로드 밸런싱과 네트워크 폴리시 구현을 포함하여 쿠버네티스용 오버레이 기반 네트워킹 구현을 제공한다. diff --git a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md index 95ea899cbb..c64dd127b3 100644 --- a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md +++ b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md @@ -1,5 +1,4 @@ --- - title: kubelet 가비지(Garbage) 수집 설정하기 content_type: concept weight: 70 @@ -7,12 +6,13 @@ weight: 70 -가비지 수집은 사용되지 않는 [이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 [컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다. - -별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써 kubelet 을 중단시킬 수도 있으므로 권장하지 않는다. - - +가비지 수집은 사용되지 않는 +[이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과 +[컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은 +1분마다 컨테이너들에 대하여 가비지 수집을 수행하며, 5분마다 이미지들에 대하여 가비지 수집을 수행한다. +별도의 가비지 수집 도구들을 사용하는 것은, 이러한 도구들이 존재할 수도 있는 컨테이너들을 제거함으로써 +kubelet을 중단시킬 수도 있으므로 권장하지 않는다. @@ -28,10 +28,24 @@ weight: 70 ## 컨테이너 수집 -컨테이너에 대한 가비지 수집 정책은 세 가지 사용자 정의 변수들을 고려한다: `MinAge` 는 컨테이너를 가비지 수집 할 수 있는 최소 연령이다. `MaxPerPodContainer` 는 모든 단일 파드 (UID, 컨테이너 이름) 쌍이 가질 수 있는 -최대 비활성 컨테이너의 수량이다. `MaxContainers` 죽은 컨테이너의 최대 수량이다. 이러한 변수는 `MinAge` 를 0으로 설정하고, `MaxPerPodContainer` 와 `MaxContainers` 를 각각 0 보다 작게 설정해서 비활성화 할 수 있다. +컨테이너에 대한 가비지 수집 정책은 세 가지 사용자 정의 변수들을 고려한다. +`MinAge` 는 컨테이너를 가비지 수집할 수 있는 최소 연령이다. +`MaxPerPodContainer` 는 모든 단일 파드(UID, 컨테이너 이름) +쌍이 가질 수 있는 최대 비활성 컨테이너의 수량이다. +`MaxContainers` 는 죽은 컨테이너의 최대 수량이다. +이러한 변수는 `MinAge` 를 0으로 설정하고, +`MaxPerPodContainer` 와 `MaxContainers` 를 각각 0 보다 작게 설정해서 비활성화할 수 있다. -Kubelet은 미확인, 삭제 또는 앞에서 언급 한 플래그가 설정 한 경계를 벗어나거나, 확인되지 않은 컨테이너에 대해 조치를 취한다. 일반적으로 가장 오래된 컨테이너가 먼저 제거된다. `MaxPerPodContainer` 와 `MaxContainer` 는 파드 당 최대 컨테이너 수 (`MaxPerPodContainer`)가 허용 가능한 범위의 전체 죽은 컨테이너의 수(`MaxContainers`)를 벗어나는 상황에서 잠재적으로 서로 충돌할 수 있습니다. 이러한 상황에서 `MaxPerPodContainer` 가 조정된다: 최악의 시나리오는 `MaxPerPodContainer` 를 1로 다운그레이드하고 가장 오래된 컨테이너를 제거하는 것이다. 추가로, 삭제된 파드가 소유 한 컨테이너는 `MinAge` 보다 오래된 컨테이너가 제거된다. +Kubelet은 미확인, 삭제 또는 앞에서 언급한 +플래그가 설정한 경계를 벗어나거나, 확인되지 않은 컨테이너에 대해 조치를 취한다. +일반적으로 가장 오래된 컨테이너가 먼저 제거된다. `MaxPerPodContainer` 와 `MaxContainer` 는 +파드 당 최대 +컨테이너 수(`MaxPerPodContainer`)가 허용 가능한 범위의 +전체 죽은 컨테이너의 수(`MaxContainers`)를 벗어나는 상황에서 잠재적으로 서로 충돌할 수 있다. +다음의 상황에서 `MaxPerPodContainer` 가 조정된다. +최악의 시나리오는 `MaxPerPodContainer` 를 1로 다운그레이드하고 +가장 오래된 컨테이너를 제거하는 것이다. 추가로, 삭제된 파드가 소유한 컨테이너는 +`MinAge` 보다 오래되면 제거된다. kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대상이 아니다. @@ -40,9 +54,9 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대 여러분은 후술될 kubelet 플래그들을 통하여 이미지 가비지 수집을 조정하기 위하여 다음의 임계값을 조정할 수 있다. 1. `image-gc-high-threshold`, 이미지 가비지 수집을 발생시키는 디스크 사용량의 비율로 -기본값은 85% 이다. + 기본값은 85% 이다. 2. `image-gc-low-threshold`, 이미지 가비지 수집을 더 이상 시도하지 않는 디스크 사용량의 비율로 -기본값은 80% 이다. + 기본값은 80% 이다. 다음의 kubelet 플래그를 통해 가비지 수집 정책을 사용자 정의할 수 있다. @@ -77,9 +91,7 @@ kubelet이 관리하지 않는 컨테이너는 컨테이너 가비지 수집 대 | `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | 축출이 다른 리소스에 대한 디스크 임계값을 일반화 함 | | `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | 축출이 다른 리소스로의 디스크 압력전환을 일반화 함 | - - ## {{% heading "whatsnext" %}} - -자세한 내용은 [리소스 부족 처리 구성](/docs/tasks/administer-cluster/out-of-resource/)를 본다. +자세한 내용은 [리소스 부족 처리 구성](/docs/concepts/scheduling-eviction/node-pressure-eviction/)를 +본다. diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md index 695c747a5d..d4e0119c41 100644 --- a/content/ko/docs/concepts/cluster-administration/logging.md +++ b/content/ko/docs/concepts/cluster-administration/logging.md @@ -83,12 +83,18 @@ kubectl logs counter [`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)를 통해 자세히 알 수 있다. +**CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다. +kubelet은 이 정보를 CRI 컨테이너 런타임에 전송하고 런타임은 컨테이너 로그를 지정된 위치에 기록한다. +[kubelet config file](/docs/tasks/administer-cluster/kubelet-config-file/)에 있는 +두 개의 kubelet 파라미터 [`containerLogMaxSize` 및 `containerLogMaxFiles`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)를 +사용하여 각 로그 파일의 최대 크기와 각 컨테이너에 허용되는 최대 파일 수를 각각 구성할 수 있다. + 기본 로깅 예제에서와 같이 [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs)를 실행하면, 노드의 kubelet이 요청을 처리하고 로그 파일에서 직접 읽는다. kubelet은 로그 파일의 내용을 반환한다. {{< note >}} -만약, 일부 외부 시스템이 로테이션을 수행한 경우, +만약, 일부 외부 시스템이 로테이션을 수행했거나 CRI 컨테이너 런타임이 사용된 경우, `kubectl logs` 를 통해 최신 로그 파일의 내용만 사용할 수 있다. 예를 들어, 10MB 파일이 있으면, `logrotate` 가 로테이션을 수행하고 두 개의 파일이 생긴다. (크기가 10MB인 파일 하나와 비어있는 파일) diff --git a/content/ko/docs/concepts/cluster-administration/manage-deployment.md b/content/ko/docs/concepts/cluster-administration/manage-deployment.md index d61d111274..7e3093d51e 100644 --- a/content/ko/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/ko/docs/concepts/cluster-administration/manage-deployment.md @@ -50,7 +50,7 @@ kubectl apply -f https://k8s.io/examples/application/nginx/ URL을 구성 소스로 지정할 수도 있다. 이는 GitHub에 체크인된 구성 파일에서 직접 배포하는 데 편리하다. ```shell -kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/application/nginx/nginx-deployment.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/application/nginx/nginx-deployment.yaml ``` ```shell @@ -278,7 +278,7 @@ pod/my-nginx-2035384211-u3t6x labeled ``` 먼저 "app=nginx" 레이블이 있는 모든 파드를 필터링한 다음, "tier=fe" 레이블을 지정한다. -방금 레이블을 지정한 파드를 보려면, 다음을 실행한다. +레이블을 지정한 파드를 보려면, 다음을 실행한다. ```shell kubectl get pods -l app=nginx -L tier diff --git a/content/ko/docs/concepts/cluster-administration/proxies.md b/content/ko/docs/concepts/cluster-administration/proxies.md index df43157578..ab1f6611fd 100644 --- a/content/ko/docs/concepts/cluster-administration/proxies.md +++ b/content/ko/docs/concepts/cluster-administration/proxies.md @@ -39,7 +39,7 @@ weight: 90 - UDP, TCP, SCTP를 이용하여 프락시 한다. - HTTP는 이해하지 못한다. - 로드 밸런싱을 제공한다. - - 단지 서비스에 도달하는데 사용한다. + - 서비스에 도달하는데만 사용한다. 1. API 서버 앞단의 프락시/로드밸런서 @@ -61,7 +61,3 @@ weight: 90 ## 요청을 리다이렉트하기 프락시는 리다이렉트 기능을 대체했다. 리다이렉트는 더 이상 사용하지 않는다. - - - - diff --git a/content/ko/docs/concepts/cluster-administration/system-logs.md b/content/ko/docs/concepts/cluster-administration/system-logs.md new file mode 100644 index 0000000000..eff3c05a65 --- /dev/null +++ b/content/ko/docs/concepts/cluster-administration/system-logs.md @@ -0,0 +1,148 @@ +--- + + + +title: 시스템 로그 +content_type: concept +weight: 60 +--- + + + +시스템 컴포넌트 로그는 클러스터에서 발생하는 이벤트를 기록하며, 이는 디버깅에 아주 유용하다. +더 많거나 적은 세부 정보를 표시하도록 다양하게 로그를 설정할 수 있다. +로그는 컴포넌트 내에서 오류를 표시하는 것 처럼 간단하거나, 이벤트의 단계적 추적(예: HTTP 엑세스 로그, 파드의 상태 변경, 컨트롤러 작업 또는 스케줄러의 결정)을 표시하는 것처럼 세밀할 수 있다. + + + +## Klog + +klog는 쿠버네티스의 로깅 라이브러리다. [klog](https://github.com/kubernetes/klog) +는 쿠버네티스 시스템 컴포넌트의 로그 메시지를 생성한다. + +klog 설정에 대한 더 많은 정보는, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다. + +klog 네이티브 형식 예 : +``` +I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756] +``` + +### 구조화된 로깅 + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +{{}} +구조화된 로그메시지로 마이그레이션은 진행중인 작업이다. 이 버전에서는 모든 로그 메시지가 구조화되지 않는다. 로그 파일을 +파싱할 때, 구조화되지 않은 로그 메시지도 처리해야 한다. + +로그 형식 및 값 직렬화는 변경될 수 있다. +{{< /warning>}} + +구조화된 로깅은 로그 메시지에 통일된 구조를 적용하여 정보를 쉽게 추출하고, +로그를 보다 쉽고 저렴하게 저장하고 처리하는 작업이다. +새로운 메시지 형식은 이전 버전과 호환되며 기본적으로 활성화 된다. + +구조화된 로그 형식: + +```ini + "" ="" ="" ... +``` + +예시: + +```ini +I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready" +``` + + +### JSON 로그 형식 + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +{{}} + +JSON 출력은 많은 표준 klog 플래그를 지원하지 않는다. 지원하지 않는 klog 플래그 목록은, [커맨드라인 툴](/ko/docs/reference/command-line-tools-reference/)을 참고한다. + +모든 로그가 JSON 형식으로 작성되는 것은 아니다(예: 프로세스 시작 중). 로그를 파싱하려는 경우 +JSON 형식이 아닌 로그 행을 처리할 수 있는지 확인해야 한다. + +필드 이름과 JSON 직렬화는 변경될 수 있다. +{{< /warning >}} + +`--logging-format=json` 플래그는 로그 형식을 klog 기본 형식에서 JSON 형식으로 변경한다. +JSON 로그 형식 예시(보기좋게 출력된 형태): + +```json +{ + "ts": 1580306777.04728, + "v": 4, + "msg": "Pod status updated", + "pod":{ + "name": "nginx-1", + "namespace": "default" + }, + "status": "ready" +} +``` + +특별한 의미가 있는 키: +* `ts` - Unix 시간의 타임스탬프 (필수, 부동 소수점) +* `v` - 자세한 정도 (필수, 정수, 기본 값 0) +* `err` - 오류 문자열 (선택 사항, 문자열) +* `msg` - 메시지 (필수, 문자열) + + +현재 JSON 형식을 지원하는 컴포넌트 목록: +* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} +* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} +* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} + +### 로그 정리(sanitization) + +{{< feature-state for_k8s_version="v1.20" state="alpha" >}} + +{{}} +로그 정리(sanitization)는 상당한 오버 헤드를 발생시킬 수 있으므로 프로덕션 환경에서는 사용하지 않아야한다. +{{< /warning >}} + + `--experimental-logging-sanitization` 플래그는 klog 정리(sanitization) 필터를 활성화 한다. +활성화된 경우 모든 로그 인자에서 민감한 데이터(예: 비밀번호, 키, 토큰)가 표시된 필드를 검사하고 +이러한 필드의 로깅이 방지된다. + +현재 로그 정리(sanitization)를 지원하는 컴포넌트 목록: +* kube-controller-manager +* kube-apiserver +* kube-scheduler +* kubelet + +{{< note >}} +로그 정리(sanitization) 필터는 사용자 작업 로그로부터 민감한 데이터가 유출되는 것을 방지할 수 없다. +{{< /note >}} + +### 로그 상세 레벨(verbosity) + +`-v` 플래그로 로그 상세 레벨(verbosity)을 제어한다. 값을 늘리면 기록된 이벤트 수가 증가한다. 값을 줄이면 +기록된 이벤트 수가 줄어든다. +로그 상세 레벨(verbosity)를 높이면 점점 덜 심각한 이벤트가 기록된다. 로그 상세 레벨(verbosity)을 0으로 설정하면 중요한 이벤트만 기록된다. + +### 로그 위치 + +시스템 컴포넌트에는 컨테이너에서 실행되는 것과 컨테이너에서 실행되지 않는 두 가지 유형이 있다. 예를 들면 다음과 같다. + +* 쿠버네티스 스케줄러와 kube-proxy는 컨테이너에서 실행된다. +* kubelet과 컨테이너 런타임(예: 도커)은 컨테이너에서 실행되지 않는다. + +systemd를 사용하는 시스템에서는, kubelet과 컨테이너 런타임은 jounald에 기록한다. +그 외 시스템에서는, `/var/log` 디렉터리의 `.log` 파일에 기록한다. +컨테이너 내부의 시스템 컴포넌트들은 기본 로깅 메커니즘을 무시하고, +항상 `/var/log` 디렉터리의 `.log` 파일에 기록한다. +컨테이너 로그와 마찬가지로, `/var/log` 디렉터리의 시스템 컴포넌트 로그들은 로테이트해야 한다. +`kube-up.sh` 스크립트로 생성된 쿠버네티스 클러스터에서는, `logrotate` 도구로 로그가 로테이트되도록 설정된다. +`logrotate` 도구는 로그가 매일 또는 크기가 100MB 보다 클 때 로테이트된다. + +## {{% heading "whatsnext" %}} + +* [쿠버네티스 로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/) 알아보기 +* [구조화된 로깅](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) 알아보기 +* [로깅 심각도(serverity) 규칙](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) 알아보기 diff --git a/content/ko/docs/concepts/cluster-administration/system-metrics.md b/content/ko/docs/concepts/cluster-administration/system-metrics.md index 08b7b79d0d..88ae6adacc 100644 --- a/content/ko/docs/concepts/cluster-administration/system-metrics.md +++ b/content/ko/docs/concepts/cluster-administration/system-metrics.md @@ -130,7 +130,7 @@ cloudprovider_gce_api_request_duration_seconds { request = "list_disk"} ### kube-scheduler 메트릭 -{{< feature-state for_k8s_version="v1.20" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} 스케줄러는 실행 중인 모든 파드의 요청(request)된 리소스와 요구되는 제한(limit)을 보고하는 선택적 메트릭을 노출한다. 이러한 메트릭은 용량 계획(capacity planning) 대시보드를 구축하고, 현재 또는 과거 스케줄링 제한을 평가하고, 리소스 부족으로 스케줄할 수 없는 워크로드를 빠르게 식별하고, 실제 사용량을 파드의 요청과 비교하는 데 사용할 수 있다. @@ -148,8 +148,27 @@ kube-scheduler는 각 파드에 대해 구성된 리소스 [요청과 제한](/k 메트릭은 HTTP 엔드포인트 `/metrics/resources`에 노출되며 스케줄러의 `/metrics` 엔드포인트 와 동일한 인증이 필요하다. 이러한 알파 수준의 메트릭을 노출시키려면 `--show-hidden-metrics-for-version=1.20` 플래그를 사용해야 한다. +## 메트릭 비활성화 + +커맨드 라인 플래그 `--disabled-metrics` 를 통해 메트릭을 명시적으로 끌 수 있다. 이 방법이 필요한 이유는 메트릭이 성능 문제를 일으키는 경우을 예로 들 수 있다. 입력값은 비활성화되는 메트릭 목록이다(예: `--disabled-metrics=metric1,metric2`). + +## 메트릭 카디널리티(cardinality) 적용 + +제한되지 않은 차원의 메트릭은 계측하는 컴포넌트에서 메모리 문제를 일으킬 수 있다. 리소스 사용을 제한하려면, `--allow-label-value` 커맨드 라인 옵션을 사용하여 메트릭 항목에 대한 레이블 값의 허용 목록(allow-list)을 동적으로 구성한다. + +알파 단계에서, 플래그는 메트릭 레이블 허용 목록으로 일련의 매핑만 가져올 수 있다. +각 매핑은 `,=` 형식이다. 여기서 +`` 는 허용되는 레이블 이름의 쉼표로 구분된 목록이다. + +전체 형식은 다음과 같다. +`--allow-label-value ,=', ...', ,=', ...', ...`. + +예시는 다음과 같다. +`--allow-label-value number_count_metric,odd_number='1,3,5', number_count_metric,even_number='2,4,6', date_gauge_metric,weekend='Saturday,Sunday'` + ## {{% heading "whatsnext" %}} * 메트릭에 대한 [프로메테우스 텍스트 형식](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format)에 대해 읽어본다 +* [안정 버전의 쿠버네티스 메트릭](https://github.com/kubernetes/kubernetes/blob/master/test/instrumentation/testdata/stable-metrics-list.yaml) 목록을 살펴본다 * [쿠버네티스 사용 중단 정책](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)에 대해 읽어본다 diff --git a/content/ko/docs/concepts/configuration/_index.md b/content/ko/docs/concepts/configuration/_index.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/concepts/configuration/configmap.md b/content/ko/docs/concepts/configuration/configmap.md index 50ef8b3632..841feb8fb3 100644 --- a/content/ko/docs/concepts/configuration/configmap.md +++ b/content/ko/docs/concepts/configuration/configmap.md @@ -223,7 +223,7 @@ spec: 현재 볼륨에서 사용된 컨피그맵이 업데이트되면, 프로젝션된 키도 마찬가지로 업데이트된다. kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최신 상태인지 확인한다. 그러나, kubelet은 로컬 캐시를 사용해서 컨피그맵의 현재 값을 가져온다. -캐시 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의 +캐시 유형은 [KubeletConfiguration 구조체](/docs/reference/config-api/kubelet-config.v1beta1/)의 `ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용해서 구성할 수 있다. 컨피그맵은 watch(기본값), ttl 기반 또는 API 서버로 직접 모든 요청을 리디렉션할 수 있다. @@ -233,11 +233,12 @@ kubelet은 모든 주기적인 동기화에서 마운트된 컨피그맵이 최 지연을 지켜보거나, 캐시의 ttl 또는 0에 상응함). 환경 변수로 사용되는 컨피그맵은 자동으로 업데이트되지 않으며 파드를 다시 시작해야 한다. + ## 변경할 수 없는(immutable) 컨피그맵 {#configmap-immutable} -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} -쿠버네티스 베타 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은 개별 시크릿과 +쿠버네티스 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은 개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 컨피그맵을 광범위하게 사용하는 클러스터(최소 수만 개의 고유한 컨피그맵이 파드에 마운트)의 경우 데이터 변경을 방지하면 다음과 같은 이점이 있다. diff --git a/content/ko/docs/concepts/configuration/manage-resources-containers.md b/content/ko/docs/concepts/configuration/manage-resources-containers.md index 8f499fbc6a..3084651390 100644 --- a/content/ko/docs/concepts/configuration/manage-resources-containers.md +++ b/content/ko/docs/concepts/configuration/manage-resources-containers.md @@ -21,9 +21,6 @@ feature: 컨테이너가 사용할 수 있도록 해당 시스템 리소스의 최소 _요청_ 량을 예약한다. - - - ## 요청 및 제한 @@ -72,7 +69,7 @@ Huge page는 노드 커널이 기본 페이지 크기보다 훨씬 큰 메모리 이것은 `memory` 및 `cpu` 리소스와는 다르다. {{< /note >}} -CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 그냥 *리소스* 라고 한다. 컴퓨트 +CPU와 메모리를 통칭하여 *컴퓨트 리소스* 또는 *리소스* 라고 한다. 컴퓨트 리소스는 요청, 할당 및 소비될 수 있는 측정 가능한 수량이다. 이것은 [API 리소스](/ko/docs/concepts/overview/kubernetes-api/)와는 다르다. 파드 및 @@ -108,9 +105,9 @@ CPU 리소스에 대한 제한 및 요청은 *cpu* 단위로 측정된다. 컨테이너는 CPU 1개를 요구하는 컨테이너의 절반만큼 CPU를 보장한다. `0.1` 이라는 표현은 "백 밀리cpu"로 읽을 수 있는 `100m` 표현과 동일하다. 어떤 사람들은 "백 밀리코어"라고 말하는데, 같은 것을 의미하는 것으로 이해된다. -`0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 로 변환되며, -`1m` 도 허용되지 않게 정밀하다. 이러한 이유로, `100m` 형식이 -선호될 수 있다. +`0.1` 과 같이 소수점이 있는 요청은 API에 의해 `100m` 으로 변환되며, +`1m` 보다 더 정밀한 단위는 허용되지 않는다. 이러한 이유로, +`100m` 과 같은 형식이 선호될 수 있다. CPU는 항상 절대 수량으로 요청되며, 상대적 수량은 아니다. 0.1은 단일 코어, 이중 코어 또는 48코어 시스템에서 동일한 양의 CPU이다. @@ -441,7 +438,9 @@ kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기 프로젝트 쿼터를 사용하려면, 다음을 수행해야 한다. -* kubelet 구성에서 `LocalStorageCapacityIsolationFSQuotaMonitoring=true` +* [kubelet 구성](/docs/reference/config-api/kubelet-config.v1beta1/)의 + `featureGates` 필드 또는 `--feature-gates` 커맨드 라인 플래그를 사용하여 + `LocalStorageCapacityIsolationFSQuotaMonitoring=true` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다. @@ -449,6 +448,7 @@ kubelet은 각 `emptyDir` 볼륨, 컨테이너 로그 디렉터리 및 쓰기 프로젝트 쿼터가 활성화되어 있는지 확인한다. 모든 XFS 파일시스템은 프로젝트 쿼터를 지원한다. ext4 파일시스템의 경우, 파일시스템이 마운트되지 않은 상태에서 프로젝트 쿼터 추적 기능을 활성화해야 한다. + ```bash # ext4인 /dev/block-device가 마운트되지 않은 경우 sudo tune2fs -O project -Q prjquota /dev/block-device @@ -518,9 +518,8 @@ JSON-Pointer로 해석된다. 더 자세한 내용은, 클러스터-레벨의 확장된 리소스는 노드에 연결되지 않는다. 이들은 일반적으로 리소스 소비와 리소스 쿼터를 처리하는 스케줄러 익스텐더(extender)에 의해 관리된다. -[스케줄러 정책 구성](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31)에서 -스케줄러 익스텐더가 -처리하는 확장된 리소스를 지정할 수 있다. +[스케줄러 정책 구성](/docs/reference/config-api/kube-scheduler-policy-config.v1/)에서 +스케줄러 익스텐더가 처리하는 확장된 리소스를 지정할 수 있다. **예제:** @@ -743,23 +742,13 @@ LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-0 컨테이너가 `reason:OOM Killed`(`OOM` 은 메모리 부족(Out Of Memory)의 약자) 때문에 종료된 것을 알 수 있다. - - - - - ## {{% heading "whatsnext" %}} - * [컨테이너와 파드에 메모리 리소스를 할당](/ko/docs/tasks/configure-pod-container/assign-memory-resource/)하는 핸즈온 경험을 해보자. - * [컨테이너와 파드에 CPU 리소스를 할당](/docs/tasks/configure-pod-container/assign-cpu-resource/)하는 핸즈온 경험을 해보자. - * 요청과 제한의 차이점에 대한 자세한 내용은, [리소스 QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md)를 참조한다. - * [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) API 레퍼런스 읽어보기 - * [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) API 레퍼런스 읽어보기 - * XFS의 [프로젝트 쿼터](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)에 대해 읽어보기 +* [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)에 대해 더 읽어보기 diff --git a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index a002414b67..aa739b381c 100644 --- a/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -17,6 +17,11 @@ kubeconfig 파일들을 사용하여 클러스터, 사용자, 네임스페이스 `kubeconfig`라는 이름의 파일이 있다는 의미는 아니다. {{< /note >}} +{{< warning >}} +신뢰할 수 있는 소스의 kubeconfig 파일만 사용한다. 특수 제작된 kubeconfig 파일을 사용하면 악성 코드가 실행되거나 파일이 노출될 수 있다. +신뢰할 수 없는 kubeconfig 파일을 사용해야 하는 경우 셸 스크립트를 사용하는 경우처럼 먼저 신중하게 검사한다. +{{< /warning>}} + 기본적으로 `kubectl`은 `$HOME/.kube` 디렉터리에서 `config`라는 이름의 파일을 찾는다. `KUBECONFIG` 환경 변수를 설정하거나 [`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/) 플래그를 지정해서 @@ -154,4 +159,3 @@ kubeconfig 파일에서 파일과 경로 참조는 kubeconfig 파일의 위치 - diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md index 4637c1a63d..06be7d5a54 100644 --- a/content/ko/docs/concepts/configuration/secret.md +++ b/content/ko/docs/concepts/configuration/secret.md @@ -31,7 +31,7 @@ weight: 30 시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다. 1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/). -2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다. +2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다. {{< /caution >}} @@ -48,7 +48,7 @@ weight: 30 - 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용. 시크릿 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. 사용자는 시크릿을 위한 파일을 구성할 때 `data` 및 (또는) `stringData` 필드를 명시할 수 있다. 해당 `data` 와 `stringData` 필드는 선택적으로 명시할 수 있다. `data` 필드의 모든 키(key)에 해당하는 값(value)은 base64로 인코딩된 문자열이어야 한다. @@ -109,7 +109,7 @@ empty-secret Opaque 0 2m6s ``` 해당 `DATA` 열은 시크릿에 저장된 데이터 아이템의 수를 보여준다. -이 경우, `0` 은 비어 있는 시크릿을 방금 하나 생성하였다는 것을 의미한다. +이 경우, `0` 은 비어 있는 시크릿을 하나 생성하였다는 것을 의미한다. ### 서비스 어카운트 토큰 시크릿 @@ -667,7 +667,7 @@ cat /etc/foo/password 볼륨에서 현재 사용되는 시크릿이 업데이트되면, 투영된 키도 결국 업데이트된다. kubelet은 마운트된 시크릿이 모든 주기적인 동기화에서 최신 상태인지 여부를 확인한다. 그러나, kubelet은 시크릿의 현재 값을 가져 오기 위해 로컬 캐시를 사용한다. -캐시의 유형은 [KubeletConfiguration 구조체](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go)의 +캐시의 유형은 [KubeletConfiguration 구조체](/docs/reference/config-api/kubelet-config.v1beta1/)의 `ConfigMapAndSecretChangeDetectionStrategy` 필드를 사용하여 구성할 수 있다. 시크릿은 watch(기본값), ttl 기반 또는 API 서버로 모든 요청을 직접 리디렉션하여 전파할 수 있다. @@ -749,9 +749,9 @@ echo $SECRET_PASSWORD ## 변경할 수 없는(immutable) 시크릿 {#secret-immutable} -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} -쿠버네티스 베타 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은 +쿠버네티스 기능인 _변경할 수 없는 시크릿과 컨피그맵_ 은 개별 시크릿과 컨피그맵을 변경할 수 없는 것으로 설정하는 옵션을 제공한다. 시크릿을 광범위하게 사용하는 클러스터(최소 수만 개의 고유한 시크릿이 파드에 마운트)의 경우, 데이터 변경을 방지하면 다음과 같은 이점이 있다. @@ -760,8 +760,8 @@ echo $SECRET_PASSWORD - immutable로 표시된 시크릿에 대한 감시를 중단하여, kube-apiserver의 부하를 크게 줄임으로써 클러스터의 성능을 향상시킴 -이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes` [기능 -게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에 +이 기능은 v1.19부터 기본적으로 활성화된 `ImmutableEphemeralVolumes` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에 의해 제어된다. `immutable` 필드를 `true` 로 설정하여 변경할 수 없는 시크릿을 생성할 수 있다. 다음은 예시이다. ```yaml @@ -865,6 +865,7 @@ LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT ### 사용 사례: 컨테이너 환경 변수로 사용하기 시크릿 정의를 작성한다. + ```yaml apiVersion: v1 kind: Secret @@ -877,6 +878,7 @@ data: ``` 시크릿을 생성한다. + ```shell kubectl apply -f mysecret.yaml ``` @@ -1154,10 +1156,10 @@ HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음, ### 시크릿 API를 사용하는 클라이언트 -시크릿 API와 상호 작용하는 애플리케이션을 배포할 때, [RBAC]( -/docs/reference/access-authn-authz/rbac/)과 같은 [인가 정책]( -/docs/reference/access-authn-authz/authorization/)을 -사용하여 접근를 제한해야 한다. +시크릿 API와 상호 작용하는 애플리케이션을 배포할 때, +[RBAC](/docs/reference/access-authn-authz/rbac/)과 같은 +[인가 정책](/ko/docs/reference/access-authn-authz/authorization/)을 +사용하여 접근을 제한해야 한다. 시크릿은 종종 다양한 중요도에 걸친 값을 보유하며, 이 중 많은 부분이 쿠버네티스(예: 서비스 어카운트 토큰)와 외부 시스템으로 단계적으로 @@ -1173,14 +1175,12 @@ HTTP 요청을 처리하고, 복잡한 비즈니스 로직을 수행한 다음, 시크릿 API에 접근해야 하는 애플리케이션은 필요한 시크릿에 대한 `get` 요청을 수행해야 한다. 이를 통해 관리자는 앱에 필요한 -[개별 인스턴스에 대한 접근을 허용 목록에 추가]( -/docs/reference/access-authn-authz/rbac/#referring-to-resources)하면서 모든 시크릿에 대한 접근을 +[개별 인스턴스에 대한 접근을 허용 목록에 추가](/docs/reference/access-authn-authz/rbac/#referring-to-resources)하면서 모든 시크릿에 대한 접근을 제한할 수 있다. `get` 반복을 통한 성능 향상을 위해, 클라이언트는 시크릿을 참조한 다음 리소스를 감시(`watch`)하고, 참조가 변경되면 시크릿을 다시 요청하는 리소스를 -설계할 수 있다. 덧붙여, 클라이언트에게 개별 리소스를 감시(`watch`)하도록 하는 ["대량 감시" API]( -https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md)도 +설계할 수 있다. 덧붙여, 클라이언트에게 개별 리소스를 감시(`watch`)하도록 하는 ["대량 감시" API](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/bulk_watch.md)도 제안되었으며, 쿠버네티스의 후속 릴리스에서 사용할 수 있을 것이다. @@ -1235,10 +1235,6 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다. - 시크릿을 사용하는 파드를 생성할 수 있는 사용자는 해당 시크릿의 값도 볼 수 있다. API 서버 정책이 해당 사용자가 시크릿을 읽을 수 있도록 허용하지 않더라도, 사용자는 시크릿을 노출하는 파드를 실행할 수 있다. - - 현재, 모든 노드에 대한 루트 권한이 있는 모든 사용자는 kubelet을 가장하여 - API 서버에서 _모든_ 시크릿을 읽을 수 있다. 단일 노드에 대한 루트 취약점 공격의 - 영향을 제한하기 위해, 실제로 필요한 노드에만 시크릿을 보내는 것이 앞으로 계획된 - 기능이다. ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/containers/_index.md b/content/ko/docs/concepts/containers/_index.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md index fe7aca59aa..886f8247a3 100644 --- a/content/ko/docs/concepts/containers/images.md +++ b/content/ko/docs/concepts/containers/images.md @@ -77,6 +77,20 @@ weight: 10 `imagePullPolicy` 가 특정값 없이 정의되면, `Always` 로 설정된다. +### 이미지풀백오프(ImagePullBackOff) + +kubelet이 컨테이너 런타임을 사용하여 파드의 컨테이너 생성을 시작할 때, +`ImagePullBackOff`로 인해 컨테이너가 +[Waiting](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-state-waiting) 상태에 있을 수 있다. + +`ImagePullBackOff`라는 상태는 (이미지 이름이 잘못됨, 또는 `imagePullSecret` 없이 +비공개 레지스트리에서 풀링 시도 등의 이유로) 쿠버네티스가 컨테이너 이미지를 +가져올 수 없기 때문에 컨테이너를 실행할 수 없음을 의미한다. `BackOff`라는 단어는 +쿠버네티스가 백오프 딜레이를 증가시키면서 이미지 풀링을 계속 시도할 것임을 나타낸다. + +쿠버네티스는 시간 간격을 늘려가면서 시도를 계속하며, 시간 간격의 상한은 쿠버네티스 코드에 +300초(5분)로 정해져 있다. + ## 이미지 인덱스가 있는 다중 아키텍처 이미지 바이너리 이미지를 제공할 뿐만 아니라, 컨테이너 레지스트리는 [컨테이너 이미지 인덱스](https://github.com/opencontainers/image-spec/blob/master/image-index.md)를 제공할 수도 있다. 이미지 인덱스는 컨테이너의 아키텍처별 버전에 대한 여러 [이미지 매니페스트](https://github.com/opencontainers/image-spec/blob/master/manifest.md)를 가리킬 수 있다. 아이디어는 이미지의 이름(예를 들어, `pause`, `example/mycontainer`, `kube-apiserver`)을 가질 수 있다는 것이다. 그래서 다른 시스템들이 사용하고 있는 컴퓨터 아키텍처에 적합한 바이너리 이미지를 가져올 수 있다. @@ -116,7 +130,7 @@ weight: 10 도커는 프라이빗 레지스트리를 위한 키를 `$HOME/.dockercfg` 또는 `$HOME/.docker/config.json` 파일에 저장한다. 만약 동일한 파일을 -아래의 검색 경로 리스트에 넣으면, kubelete은 이미지를 풀 할 때 해당 파일을 자격 증명 공급자로 사용한다. +아래의 검색 경로 리스트에 넣으면, kubelet은 이미지를 풀 할 때 해당 파일을 자격 증명 공급자로 사용한다. * `{--root-dir:-/var/lib/kubelet}/config.json` * `{cwd of kubelet}/config.json` diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md index 3d7c89b65c..953571ec62 100644 --- a/content/ko/docs/concepts/containers/runtime-class.md +++ b/content/ko/docs/concepts/containers/runtime-class.md @@ -11,7 +11,7 @@ weight: 20 이 페이지는 런타임클래스 리소스와 런타임 선택 메커니즘에 대해서 설명한다. 런타임클래스는 컨테이너 런타임을 구성을 선택하는 기능이다. 컨테이너 런타임 -구성은 파드의 컨테이너를 실행하는데 사용된다. +구성은 파드의 컨테이너를 실행하는 데 사용된다. @@ -21,7 +21,7 @@ weight: 20 ## 동기 서로 다른 파드간에 런타임클래스를 설정하여 -성능대 보안의 균형을 유지할 수 있다. +성능과 보안의 균형을 유지할 수 있다. 예를 들어, 일부 작업에서 높은 수준의 정보 보안 보증이 요구되는 경우, 하드웨어 가상화를 이용하는 컨테이너 런타임으로 파드를 실행하도록 예약하는 선택을 할 수 있다. 그러면 몇가지 추가적인 오버헤드는 있지만 @@ -68,7 +68,7 @@ handler: myconfiguration # 상응하는 CRI 설정의 이름임 ``` 런타임클래스 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)어이야 한다. +[DNS 레이블 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-레이블-이름)어이야 한다. {{< note >}} 런타임클래스 쓰기 작업(create/update/patch/delete)은 @@ -106,7 +106,8 @@ CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/p #### dockershim -쿠버네티스의 내장 dockershim CRI는 런타임 핸들러를 지원하지 않는다. +dockershim을 사용하는 경우 RuntimeClass는 런타임 핸들러를 `docker`로 고정한다. +dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다. #### {{< glossary_tooltip term_id="containerd" >}} @@ -131,7 +132,7 @@ https://github.com/containerd/cri/blob/master/docs/config.md runtime_path = "${PATH_TO_BINARY}" ``` -더 자세한 것은 CRI-O의 [설정 문서](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)를 본다. +더 자세한 것은 CRI-O의 [설정 문서](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md)를 본다. ## 스케줄 @@ -174,5 +175,5 @@ PodOverhead를 사용하려면, PodOverhead [기능 게이트](/ko/docs/referenc - [런타임클래스 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md) - [런타임클래스 스케줄링 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling) -- [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기 -- [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) +- [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/) 개념에 대해 읽기 +- [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) diff --git a/content/ko/docs/concepts/extend-kubernetes/_index.md b/content/ko/docs/concepts/extend-kubernetes/_index.md index 81cc38337f..95c61079dd 100644 --- a/content/ko/docs/concepts/extend-kubernetes/_index.md +++ b/content/ko/docs/concepts/extend-kubernetes/_index.md @@ -2,6 +2,10 @@ title: 쿠버네티스 확장 weight: 110 description: 쿠버네티스 클러스터의 동작을 변경하는 다양한 방법 +feature: + title: 확장성을 고려하여 설계됨 + description: > + 쿠버네티스 업스트림 소스 코드 수정 없이 쿠버네티스 클러스터에 기능을 추가할 수 있다. content_type: concept no_list: true --- @@ -17,7 +21,7 @@ no_list: true 조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를 대상으로 한다. 잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도 어떤 익스텐션(extension) 포인트와 패턴이 있는지, -그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다. +그리고 그것의 트레이드오프와 제약을 이해하는 데 도움이 될 것이다. @@ -76,19 +80,18 @@ kubectl에서 아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을 보여주는 다이어그램이다. - - +![익스텐션 포인트와 컨트롤 플레인](/ko/docs/concepts/extend-kubernetes/control-plane.png) ## 익스텐션 포인트 이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다. - - +![익스텐션 포인트](/docs/concepts/extend-kubernetes/extension-points.png) + 1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. 2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](#api-접근-익스텐션) 섹션에 설명되어 있다. 3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다. @@ -99,11 +102,10 @@ kubectl에서 어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다. - - - +![익스텐션 플로우차트](/ko/docs/concepts/extend-kubernetes/flowchart.png) + ## API 익스텐션 ### 사용자 정의 유형 @@ -141,7 +143,7 @@ API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치 ### 인가 -[인가](/docs/reference/access-authn-authz/webhook/)은 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다. +[인가](/docs/reference/access-authn-authz/webhook/)는 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인가 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다. ### 동적 어드미션 컨트롤 diff --git a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index d549060108..0357ac7619 100644 --- a/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -44,7 +44,7 @@ _선언_ 하거나 지정할 수 있게 해주며 쿠버네티스 오브젝트 클러스터 라이프사이클과 관계없이 실행 중인 클러스터에 커스텀 컨트롤러를 배포하고 업데이트할 수 있다. 커스텀 컨트롤러는 모든 종류의 리소스와 함께 작동할 수 있지만 커스텀 리소스와 결합할 때 특히 효과적이다. -[오퍼레이터 패턴](https://coreos.com/blog/introducing-operators.html)은 사용자 정의 +[오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)은 사용자 정의 리소스와 커스텀 컨트롤러를 결합한다. 커스텀 컨트롤러를 사용하여 특정 애플리케이션에 대한 도메인 지식을 쿠버네티스 API의 익스텐션으로 인코딩할 수 있다. @@ -128,7 +128,7 @@ CRD를 사용하면 다른 API 서버를 추가하지 않고도 새로운 타입 ## 커스텀리소스데피니션 -[커스텀리소스데피니션](/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/) +[커스텀리소스데피니션](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) API 리소스를 사용하면 커스텀 리소스를 정의할 수 있다. CRD 오브젝트를 정의하면 지정한 이름과 스키마를 사용하여 새 커스텀 리소스가 만들어진다. 쿠버네티스 API는 커스텀 리소스의 스토리지를 제공하고 처리한다. diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 5f58604cd7..13313adf58 100644 --- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -193,9 +193,69 @@ kubelet은 gRPC 서비스를 제공하여 사용 중인 장치를 검색하고, // 사용한 노드 리소스에 대한 정보를 제공한다. service PodResourcesLister { rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {} + rpc GetAllocatableResources(AllocatableResourcesRequest) returns (AllocatableResourcesResponse) {} } ``` +`List` 엔드포인트는 독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID, +이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보와 함께 +실행 중인 파드의 리소스에 대한 정보를 제공한다. + +```gRPC +// ListPodResourcesResponse는 List 함수가 반환하는 응답이다 +message ListPodResourcesResponse { + repeated PodResources pod_resources = 1; +} + +// PodResources에는 파드에 할당된 노드 리소스에 대한 정보가 포함된다 +message PodResources { + string name = 1; + string namespace = 2; + repeated ContainerResources containers = 3; +} + +// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보를 포함한다 +message ContainerResources { + string name = 1; + repeated ContainerDevices devices = 2; + repeated int64 cpu_ids = 3; +} + +// 토폴로지는 리소스의 하드웨어 토폴로지를 설명한다 +message TopologyInfo { + repeated NUMANode nodes = 1; +} + +// NUMA 노드의 NUMA 표현 +message NUMANode { + int64 ID = 1; +} + +// ContainerDevices는 컨테이너에 할당된 장치에 대한 정보를 포함한다 +message ContainerDevices { + string resource_name = 1; + repeated string device_ids = 2; + TopologyInfo topology = 3; +} +``` + +GetAllocatableResources는 워커 노드에서 처음 사용할 수 있는 리소스에 대한 정보를 제공한다. +kubelet이 APIServer로 내보내는 것보다 더 많은 정보를 제공한다. + +```gRPC +// AllocatableResourcesResponses에는 kubelet이 알고 있는 모든 장치에 대한 정보가 포함된다. +message AllocatableResourcesResponse { + repeated ContainerDevices devices = 1; + repeated int64 cpu_ids = 2; +} + +``` + +`ContainerDevices` 는 장치가 어떤 NUMA 셀과 연관되는지를 선언하는 토폴로지 정보를 노출한다. +NUMA 셀은 불분명한(opaque) 정수 ID를 사용하여 식별되며, 이 값은 +[kubelet에 등록할 때](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#토폴로지-관리자로-장치-플러그인-통합) 장치 플러그인이 보고하는 것과 일치한다. + + gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 소켓을 통해 제공된다. 장치 플러그인 리소스에 대한 모니터링 에이전트는 데몬 또는 데몬셋으로 배포할 수 있다. 표준 디렉터리 `/var/lib/kubelet/pod-resources` 에는 특권을 가진 접근이 필요하므로, 모니터링 @@ -204,9 +264,10 @@ gRPC 서비스는 `/var/lib/kubelet/pod-resources/kubelet.sock` 의 유닉스 `/var/lib/kubelet/pod-resources` 를 {{< glossary_tooltip text="볼륨" term_id="volume" >}}으로 마운트해야 한다. -"PodResources 서비스"를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. +`PodResourcesLister service` 를 지원하려면 `KubeletPodResources` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. +이것은 쿠버네티스 1.15부터 기본으로 활성화되어 있으며, 쿠버네티스 1.20부터는 v1 상태이다. -## 토폴로지 관리자와 장치 플러그인 통합 +## 토폴로지 관리자로 장치 플러그인 통합 {{< feature-state for_k8s_version="v1.18" state="beta" >}} diff --git a/content/ko/docs/concepts/extend-kubernetes/control-plane.png b/content/ko/docs/concepts/extend-kubernetes/control-plane.png new file mode 100644 index 0000000000..df95778fdb Binary files /dev/null and b/content/ko/docs/concepts/extend-kubernetes/control-plane.png differ diff --git a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md b/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md deleted file mode 100644 index ee9763a769..0000000000 --- a/content/ko/docs/concepts/extend-kubernetes/extend-cluster.md +++ /dev/null @@ -1,201 +0,0 @@ ---- -title: 쿠버네티스 클러스터 확장 -content_type: concept -weight: 10 ---- - - - -쿠버네티스는 매우 유연하게 구성할 수 있고 확장 가능하다. 결과적으로 -쿠버네티스 프로젝트를 포크하거나 코드에 패치를 제출할 필요가 -거의 없다. - -이 가이드는 쿠버네티스 클러스터를 사용자 정의하기 위한 옵션을 설명한다. -쿠버네티스 클러스터를 업무 환경의 요구에 맞게 -조정하는 방법을 이해하려는 {{< glossary_tooltip text="클러스터 운영자" term_id="cluster-operator" >}}를 -대상으로 한다. -잠재적인 {{< glossary_tooltip text="플랫폼 개발자" term_id="platform-developer" >}} 또는 -쿠버네티스 프로젝트 {{< glossary_tooltip text="컨트리뷰터" term_id="contributor" >}}인 개발자에게도 -어떤 익스텐션 포인트와 패턴이 있는지, -그리고 그것들의 트레이드오프와 제약에 대한 소개 자료로 유용할 것이다. - - - - -## 개요 - -사용자 정의 방식은 크게 플래그, 로컬 구성 파일 또는 API 리소스 변경만 포함하는 *구성* 과 추가 프로그램이나 서비스 실행과 관련된 *익스텐션* 으로 나눌 수 있다. 이 문서는 주로 익스텐션에 관한 것이다. - -## 구성 - -*구성 파일* 및 *플래그* 는 온라인 문서의 레퍼런스 섹션에 각 바이너리 별로 문서화되어 있다. - -* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) -* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) -* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) -* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). - -호스팅된 쿠버네티스 서비스 또는 매니지드 설치 환경의 배포판에서 플래그 및 구성 파일을 항상 변경할 수 있는 것은 아니다. 변경 가능한 경우 일반적으로 클러스터 관리자만 변경할 수 있다. 또한 향후 쿠버네티스 버전에서 변경될 수 있으며, 이를 설정하려면 프로세스를 다시 시작해야 할 수도 있다. 이러한 이유로 다른 옵션이 없는 경우에만 사용해야 한다. - -[리소스쿼터](/ko/docs/concepts/policy/resource-quotas/), [PodSecurityPolicy](/ko/docs/concepts/policy/pod-security-policy/), [네트워크폴리시](/ko/docs/concepts/services-networking/network-policies/) 및 역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/))와 같은 *빌트인 정책 API(built-in Policy API)* 는 기본적으로 제공되는 쿠버네티스 API이다. API는 일반적으로 호스팅된 쿠버네티스 서비스 및 매니지드 쿠버네티스 설치 환경과 함께 사용된다. 그것들은 선언적이며 파드와 같은 다른 쿠버네티스 리소스와 동일한 규칙을 사용하므로, 새로운 클러스터 구성을 반복할 수 있고 애플리케이션과 동일한 방식으로 관리할 수 ​​있다. 또한, 이들 API가 안정적인 경우, 다른 쿠버네티스 API와 같이 [정의된 지원 정책](/docs/reference/using-api/deprecation-policy/)을 사용할 수 있다. 이러한 이유로 인해 구성 파일과 플래그보다 선호된다. - -## 익스텐션(Extension) {#익스텐션} - -익스텐션은 쿠버네티스를 확장하고 쿠버네티스와 긴밀하게 통합되는 소프트웨어 컴포넌트이다. -이들 컴포넌트는 쿠버네티스가 새로운 유형과 새로운 종류의 하드웨어를 지원할 수 있게 해준다. - -대부분의 클러스터 관리자는 쿠버네티스의 호스팅 또는 배포판 인스턴스를 사용한다. -결과적으로 대부분의 쿠버네티스 사용자는 익스텐션 기능을 설치할 필요가 없고 -새로운 익스텐션 기능을 작성할 필요가 있는 사람은 더 적다. - -## 익스텐션 패턴 - -쿠버네티스는 클라이언트 프로그램을 작성하여 자동화 되도록 설계되었다. -쿠버네티스 API를 읽고 쓰는 프로그램은 유용한 자동화를 제공할 수 있다. -*자동화* 는 클러스터 상에서 또는 클러스터 밖에서 실행할 수 있다. 이 문서의 지침에 따라 -고가용성과 강력한 자동화를 작성할 수 있다. -자동화는 일반적으로 호스트 클러스터 및 매니지드 설치 환경을 포함한 모든 -쿠버네티스 클러스터에서 작동한다. - -쿠버네티스와 잘 작동하는 클라이언트 프로그램을 작성하기 위한 특정 패턴은 *컨트롤러* 패턴이라고 한다. -컨트롤러는 일반적으로 오브젝트의 `.spec`을 읽고, 가능한 경우 수행한 다음 -오브젝트의 `.status`를 업데이트 한다. - -컨트롤러는 쿠버네티스의 클라이언트이다. 쿠버네티스가 클라이언트이고 -원격 서비스를 호출할 때 이를 *웹훅(Webhook)* 이라고 한다. 원격 서비스를 -*웹훅 백엔드* 라고 한다. 컨트롤러와 마찬가지로 웹훅은 장애 지점을 -추가한다. - -웹훅 모델에서 쿠버네티스는 원격 서비스에 네트워크 요청을 한다. -*바이너리 플러그인* 모델에서 쿠버네티스는 바이너리(프로그램)를 실행한다. -바이너리 플러그인은 kubelet(예: -[Flex 볼륨 플러그인](/ko/docs/concepts/storage/volumes/#flexvolume)과 -[네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/))과 -kubectl에서 -사용한다. - -아래는 익스텐션 포인트가 쿠버네티스 컨트롤 플레인과 상호 작용하는 방법을 -보여주는 다이어그램이다. - - - - - - -## 익스텐션 포인트 - -이 다이어그램은 쿠버네티스 시스템의 익스텐션 포인트를 보여준다. - - - - - -1. 사용자는 종종 `kubectl`을 사용하여 쿠버네티스 API와 상호 작용한다. [Kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)은 kubectl 바이너리를 확장한다. 개별 사용자의 로컬 환경에만 영향을 미치므로 사이트 전체 정책을 적용할 수는 없다. -2. apiserver는 모든 요청을 처리한다. apiserver의 여러 유형의 익스텐션 포인트는 요청을 인증하거나, 콘텐츠를 기반으로 요청을 차단하거나, 콘텐츠를 편집하고, 삭제 처리를 허용한다. 이 내용은 [API 접근 익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#api-접근-익스텐션) 섹션에 설명되어 있다. -3. apiserver는 다양한 종류의 *리소스* 를 제공한다. `pods`와 같은 *빌트인 리소스 종류* 는 쿠버네티스 프로젝트에 의해 정의되며 변경할 수 없다. 직접 정의한 리소스를 추가할 수도 있고, [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/extend-cluster/#사용자-정의-유형) 섹션에 설명된 대로 *커스텀 리소스* 라고 부르는 다른 프로젝트에서 정의한 리소스를 추가할 수도 있다. 커스텀 리소스는 종종 API 접근 익스텐션과 함께 사용된다. -4. 쿠버네티스 스케줄러는 파드를 배치할 노드를 결정한다. 스케줄링을 확장하는 몇 가지 방법이 있다. 이들은 [스케줄러 익스텐션](/ko/docs/concepts/extend-kubernetes/#스케줄러-익스텐션) 섹션에 설명되어 있다. -5. 쿠버네티스의 많은 동작은 API-Server의 클라이언트인 컨트롤러(Controller)라는 프로그램으로 구현된다. 컨트롤러는 종종 커스텀 리소스와 함께 사용된다. -6. kubelet은 서버에서 실행되며 파드가 클러스터 네트워크에서 자체 IP를 가진 가상 서버처럼 보이도록 한다. [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#네트워크-플러그인)을 사용하면 다양한 파드 네트워킹 구현이 가능하다. -7. kubelet은 컨테이너의 볼륨을 마운트 및 마운트 해제한다. 새로운 유형의 스토리지는 [스토리지 플러그인](/ko/docs/concepts/extend-kubernetes/extend-cluster/#스토리지-플러그인)을 통해 지원될 수 있다. - -어디서부터 시작해야 할지 모르겠다면, 이 플로우 차트가 도움이 될 수 있다. 일부 솔루션에는 여러 유형의 익스텐션이 포함될 수 있다. - - - - - - -## API 익스텐션 -### 사용자 정의 유형 - -새 컨트롤러, 애플리케이션 구성 오브젝트 또는 기타 선언적 API를 정의하고 `kubectl`과 같은 쿠버네티스 도구를 사용하여 관리하려면 쿠버네티스에 커스텀 리소스를 추가하자. - -애플리케이션, 사용자 또는 모니터링 데이터의 데이터 저장소로 커스텀 리소스를 사용하지 않는다. - -커스텀 리소스에 대한 자세한 내용은 [커스텀 리소스 개념 가이드](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)를 참고하길 바란다. - - -### 새로운 API와 자동화의 결합 - -사용자 정의 리소스 API와 컨트롤 루프의 조합을 [오퍼레이터(operator) 패턴](/ko/docs/concepts/extend-kubernetes/operator/)이라고 한다. 오퍼레이터 패턴은 특정 애플리케이션, 일반적으로 스테이트풀(stateful) 애플리케이션을 관리하는 데 사용된다. 이러한 사용자 정의 API 및 컨트롤 루프를 사용하여 스토리지나 정책과 같은 다른 리소스를 제어할 수도 있다. - -### 빌트인 리소스 변경 - -사용자 정의 리소스를 추가하여 쿠버네티스 API를 확장하면 추가된 리소스는 항상 새로운 API 그룹에 속한다. 기존 API 그룹을 바꾸거나 변경할 수 없다. -API를 추가해도 기존 API(예: 파드)의 동작에 직접 영향을 미치지는 않지만 API 접근 익스텐션은 영향을 준다. - - -### API 접근 익스텐션 - -요청이 쿠버네티스 API 서버에 도달하면 먼저 인증이 되고, 그런 다음 승인된 후 다양한 유형의 어드미션 컨트롤이 적용된다. 이 흐름에 대한 자세한 내용은 [쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access/)를 참고하길 바란다. - -이러한 각 단계는 익스텐션 포인트를 제공한다. - -쿠버네티스에는 이를 지원하는 몇 가지 빌트인 인증 방법이 있다. 또한 인증 프록시 뒤에 있을 수 있으며 인증 헤더에서 원격 서비스로 토큰을 전송하여 확인할 수 있다(웹훅). 이러한 방법은 모두 [인증 설명서](/docs/reference/access-authn-authz/authentication/)에 설명되어 있다. - -### 인증 - -[인증](/docs/reference/access-authn-authz/authentication/)은 모든 요청의 헤더 또는 인증서를 요청하는 클라이언트의 사용자 이름에 매핑한다. - -쿠버네티스는 몇 가지 빌트인 인증 방법과 필요에 맞지 않는 경우 [인증 웹훅](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 방법을 제공한다. - - -### 승인 - -[승인](/docs/reference/access-authn-authz/webhook/)은 특정 사용자가 API 리소스에서 읽고, 쓰고, 다른 작업을 수행할 수 있는지를 결정한다. 전체 리소스 레벨에서 작동하며 임의의 오브젝트 필드를 기준으로 구별하지 않는다. 빌트인 인증 옵션이 사용자의 요구를 충족시키지 못하면 [인증 웹훅](/docs/reference/access-authn-authz/webhook/)을 통해 사용자가 제공한 코드를 호출하여 인증 결정을 내릴 수 있다. - - -### 동적 어드미션 컨트롤 - -요청이 승인된 후, 쓰기 작업인 경우 [어드미션 컨트롤](/docs/reference/access-authn-authz/admission-controllers/) 단계도 수행된다. 빌트인 단계 외에도 몇 가지 익스텐션이 있다. - -* [이미지 정책 웹훅](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)은 컨테이너에서 실행할 수 있는 이미지를 제한한다. -* 임의의 어드미션 컨트롤 결정을 내리기 위해 일반적인 [어드미션 웹훅](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)을 사용할 수 있다. 어드미션 웹훅은 생성 또는 업데이트를 거부할 수 있다. - -## 인프라스트럭처 익스텐션 - - -### 스토리지 플러그인 - -[Flex 볼륨](/ko/docs/concepts/storage/volumes/#flexvolume)을 사용하면 -Kubelet이 바이너리 플러그인을 호출하여 볼륨을 마운트하도록 함으로써 -빌트인 지원 없이 볼륨 유형을 마운트 할 수 있다. - - -### 장치 플러그인 - -장치 플러그인은 노드가 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)을 -통해 새로운 노드 리소스(CPU 및 메모리와 같은 빌트인 자원 외에)를 -발견할 수 있게 해준다. - -### 네트워크 플러그인 - -노드-레벨의 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 -다양한 네트워킹 패브릭을 지원할 수 있다. - -### 스케줄러 익스텐션 - -스케줄러는 파드를 감시하고 파드를 노드에 할당하는 특수한 유형의 -컨트롤러이다. 다른 쿠버네티스 컴포넌트를 계속 사용하면서 -기본 스케줄러를 완전히 교체하거나, -[여러 스케줄러](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)를 -동시에 실행할 수 있다. - -이것은 중요한 부분이며, 거의 모든 쿠버네티스 사용자는 스케줄러를 수정할 -필요가 없다는 것을 알게 된다. - -스케줄러는 또한 웹훅 백엔드(스케줄러 익스텐션)가 -파드에 대해 선택된 노드를 필터링하고 우선 순위를 지정할 수 있도록 하는 -[웹훅](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)을 -지원한다. - - -## {{% heading "whatsnext" %}} - -* [커스텀 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기 -* [동적 어드미션 컨트롤](/docs/reference/access-authn-authz/extensible-admission-controllers/)에 대해 알아보기 -* 인프라스트럭처 익스텐션에 대해 더 알아보기 - * [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) - * [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) -* [kubectl 플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)에 대해 알아보기 -* [오퍼레이터 패턴](/ko/docs/concepts/extend-kubernetes/operator/)에 대해 알아보기 diff --git a/content/ko/docs/concepts/extend-kubernetes/flowchart.png b/content/ko/docs/concepts/extend-kubernetes/flowchart.png new file mode 100644 index 0000000000..1415903a83 Binary files /dev/null and b/content/ko/docs/concepts/extend-kubernetes/flowchart.png differ diff --git a/content/ko/docs/concepts/extend-kubernetes/operator.md b/content/ko/docs/concepts/extend-kubernetes/operator.md index 21b3183b99..80ed86c2ec 100644 --- a/content/ko/docs/concepts/extend-kubernetes/operator.md +++ b/content/ko/docs/concepts/extend-kubernetes/operator.md @@ -51,8 +51,7 @@ weight: 30 * 내부 멤버 선출 절차없이 분산 애플리케이션의 리더를 선택 -오퍼레이터의 모습을 더 자세하게 볼 수 있는 방법은 무엇인가? 자세한 예는 -다음과 같다. +오퍼레이터의 모습을 더 자세하게 볼 수 있는 방법은 무엇인가? 예시는 다음과 같다. 1. 클러스터에 구성할 수 있는 SampleDB라는 사용자 정의 리소스. 2. 오퍼레이터의 컨트롤러 부분이 포함된 파드의 실행을 @@ -113,15 +112,18 @@ kubectl edit SampleDB/example-database # 일부 설정을 수동으로 변경하 {{% thirdparty-content %}} +* [Charmed Operator Framework](https://juju.is/) * [kubebuilder](https://book.kubebuilder.io/) 사용하기 * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) -* 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.app/)를 +* 웹훅(WebHook)과 함께 [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html)를 사용하여 직접 구현하기 * [오퍼레이터 프레임워크](https://operatorframework.io) +* [shell-operator](https://github.com/flant/shell-operator) ## {{% heading "whatsnext" %}} +* {{< glossary_tooltip text="CNCF" term_id="cncf" >}} [오퍼레이터 백서](https://github.com/cncf/tag-app-delivery/blob/eece8f7307f2970f46f100f51932db106db46968/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md) 읽어보기 * [사용자 정의 리소스](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에 대해 더 알아보기 * [OperatorHub.io](https://operatorhub.io/)에서 유스케이스에 맞는 이미 만들어진 오퍼레이터 찾기 * 다른 사람들이 사용할 수 있도록 자신의 오퍼레이터를 [게시](https://operatorhub.io/)하기 diff --git a/content/ko/docs/concepts/overview/_index.md b/content/ko/docs/concepts/overview/_index.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/concepts/overview/components.md b/content/ko/docs/concepts/overview/components.md index d4b77e9319..b4c6079213 100644 --- a/content/ko/docs/concepts/overview/components.md +++ b/content/ko/docs/concepts/overview/components.md @@ -30,8 +30,9 @@ card: 컨트롤 플레인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작할 수 있다. 그러나 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨트롤 플레인 컴포넌트를 구동시키고, -사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 다중-마스터-VM 설치 예제를 보려면 -[고가용성 클러스터 구성하기](/docs/admin/high-availability/)를 확인해본다. +사용자 컨테이너는 해당 머신 상에 동작시키지 않는다. 여러 VM에서 +실행되는 컨트롤 플레인 설정의 예제를 보려면 +[kubeadm을 사용하여 고가용성 클러스터 만들기](/docs/setup/production-environment/tools/kubeadm/high-availability/)를 확인해본다. ### kube-apiserver diff --git a/content/ko/docs/concepts/overview/kubernetes-api.md b/content/ko/docs/concepts/overview/kubernetes-api.md index 026e0e007c..919d59b459 100644 --- a/content/ko/docs/concepts/overview/kubernetes-api.md +++ b/content/ko/docs/concepts/overview/kubernetes-api.md @@ -20,14 +20,14 @@ card: 쿠버네티스 API를 사용하면 쿠버네티스의 API 오브젝트(예: 파드(Pod), 네임스페이스(Namespace), 컨피그맵(ConfigMap) 그리고 이벤트(Event))를 질의(query)하고 조작할 수 있다. -대부분의 작업은 [kubectl](/docs/reference/kubectl/overview/) +대부분의 작업은 [kubectl](/ko/docs/reference/kubectl/overview/) 커맨드 라인 인터페이스 또는 API를 사용하는 [kubeadm](/ko/docs/reference/setup-tools/kubeadm/)과 같은 다른 커맨드 라인 도구를 통해 수행할 수 있다. 그러나, REST 호출을 사용하여 API에 직접 접근할 수도 있다. 쿠버네티스 API를 사용하여 애플리케이션을 작성하는 경우 -[클라이언트 라이브러리](/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이 좋다. +[클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/) 중 하나를 사용하는 것이 좋다. @@ -130,7 +130,7 @@ API 리소스는 API 그룹, 리소스 유형, 네임스페이스 {{< /note >}} API 버전 수준 정의에 대한 자세한 내용은 -[API 버전 레퍼런스](/ko/docs/reference/using-api/api-overview/#api-버전-규칙)를 참조한다. +[API 버전 레퍼런스](/ko/docs/reference/using-api/#api-버전-규칙)를 참조한다. diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index 344c266d1e..5d2ef83d76 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -21,7 +21,7 @@ sitemap: 쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다. -쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 [15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다. +쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. K8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기이다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 [15년 이상의 구글 경험](/blog/2015/04/borg-predecessor-to-kubernetes/)과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다. ## 여정 돌아보기 diff --git a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md index 09f70af30c..c19ec0b3a9 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/common-labels.md @@ -32,14 +32,15 @@ kubectl과 대시보드와 같은 많은 도구들로 쿠버네티스 오브젝 레이블을 최대한 활용하려면 모든 리소스 오브젝트에 적용해야 한다. -| Key | Description | Example | Type | +| 키 | 설명 | 예시 | 타입 | | ----------------------------------- | --------------------- | -------- | ---- | | `app.kubernetes.io/name` | 애플리케이션 이름 | `mysql` | 문자열 | | `app.kubernetes.io/instance` | 애플리케이션의 인스턴스를 식별하는 고유한 이름 | `mysql-abcxzy` | 문자열 | | `app.kubernetes.io/version` | 애플리케이션의 현재 버전 (예: a semantic version, revision hash 등.) | `5.7.21` | 문자열 | | `app.kubernetes.io/component` | 아키텍처 내 구성요소 | `database` | 문자열 | | `app.kubernetes.io/part-of` | 이 애플리케이션의 전체 이름 | `wordpress` | 문자열 | -| `app.kubernetes.io/managed-by` | 애플리케이션의 작동을 관리하는데 사용되는 도구 | `helm` | 문자열 | +| `app.kubernetes.io/managed-by` | 애플리케이션의 작동을 관리하는 데 사용되는 도구 | `helm` | 문자열 | +| `app.kubernetes.io/created-by` | 이 리소스를 만든 컨트롤러/사용자 | `controller-manager` | 문자열 | 위 레이블의 실제 예시는 다음 스테이트풀셋 오브젝트를 고려한다. @@ -54,6 +55,7 @@ metadata: app.kubernetes.io/component: database app.kubernetes.io/part-of: wordpress app.kubernetes.io/managed-by: helm + app.kubernetes.io/created-by: controller-manager ``` ## 애플리케이션과 애플리케이션 인스턴스 @@ -76,7 +78,7 @@ WordPress가 여러 번 설치되어 각각 서로 다른 웹사이트를 서비 `Deployment` 와 `Service` 오브젝트를 통해 배포된 단순한 스테이트리스 서비스의 경우를 보자. 다음 두 식별자는 레이블을 가장 간단한 형태로 사용하는 방법을 나타낸다. -`Deployment` 는 애플리케이션을 실행하는 파드를 감시하는데 사용한다. +`Deployment` 는 애플리케이션을 실행하는 파드를 감시하는 데 사용한다. ```yaml apiVersion: apps/v1 kind: Deployment @@ -102,9 +104,9 @@ metadata: Helm을 이용해서 데이터베이스(MySQL)을 이용하는 웹 애플리케이션(WordPress)을 설치한 것과 같이 좀 더 복잡한 애플리케이션을 고려할 수 있다. -다음 식별자는 이 애플리케이션을 배포하는데 사용하는 오브젝트의 시작을 보여준다. +다음 식별자는 이 애플리케이션을 배포하는 데 사용하는 오브젝트의 시작을 보여준다. -WordPress를 배포하는데 다음과 같이 `Deployment` 로 시작한다. +WordPress를 배포하는 데 다음과 같이 `Deployment` 로 시작한다. ```yaml apiVersion: apps/v1 @@ -152,7 +154,7 @@ metadata: ... ``` -`Service` 는 WordPress의 일부로 MySQL을 노출하는데 이용한다. +`Service` 는 WordPress의 일부로 MySQL을 노출하는 데 이용한다. ```yaml apiVersion: v1 diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md index da3cff2a89..0583ae0fe3 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/labels.md +++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md @@ -53,9 +53,9 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시 `kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다. 유효한 레이블 값은 다음과 같다. -* 63 자 이하 여야 하고(공백이면 안 됨), -* 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, -* 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)를 중간에 포함할 수 있다. +* 63 자 이하여야 하고 (공백일 수도 있음), +* (공백이 아니라면) 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, +* 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)을 중간에 포함할 수 있다. 유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다. diff --git a/content/ko/docs/concepts/overview/working-with-objects/names.md b/content/ko/docs/concepts/overview/working-with-objects/names.md index 891ad4d07a..78b7addd43 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/names.md +++ b/content/ko/docs/concepts/overview/working-with-objects/names.md @@ -21,11 +21,15 @@ weight: 20 {{< glossary_definition term_id="name" length="all" >}} +{{< note >}} +물리적 호스트를 나타내는 노드와 같이 오브젝트가 물리적 엔티티를 나타내는 경우, 노드를 삭제한 후 다시 생성하지 않은 채 동일한 이름으로 호스트를 다시 생성하면, 쿠버네티스는 새 호스트를 불일치로 이어질 수 있는 이전 호스트로 취급한다. +{{< /note >}} + 다음은 리소스에 일반적으로 사용되는 세 가지 유형의 이름 제한 조건이다. ### DNS 서브도메인 이름 -대부분의 리소스 유형에는 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로 +대부분의 리소스 유형에는 [RFC 1123](https://tools.ietf.org/html/rfc1123)에 정의된 대로 DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다. 이것은 이름이 다음을 충족해야 한다는 것을 의미한다. @@ -83,4 +87,3 @@ UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다. * 쿠버네티스의 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)에 대해 읽기. * [쿠버네티스의 식별자와 이름](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) 디자인 문서 읽기. - diff --git a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md index 905375bdc5..049b30a1f7 100644 --- a/content/ko/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/ko/docs/concepts/overview/working-with-objects/namespaces.md @@ -26,7 +26,7 @@ weight: 30 동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해 여러 네임스페이스를 사용할 필요는 없다. 동일한 네임스페이스 내에서 리소스를 -구별하기 위해 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 +구별하기 위해 {{< glossary_tooltip text="레이블" term_id="label" >}}을 사용한다. ## 네임스페이스 다루기 @@ -35,7 +35,7 @@ weight: 30 [네임스페이스 관리자 가이드 문서](/docs/tasks/administer-cluster/namespaces/)에 기술되어 있다. {{< note >}} - 쿠버네티스 시스템 네임스페이스용으로 예약되어 있으므로, `kube-` 접두사로 네임스페이스를 생성하지 않는다. + `kube-` 접두사로 시작하는 네임스페이스는 쿠버네티스 시스템용으로 예약되어 있으므로, 사용자는 이러한 네임스페이스를 생성하지 않는다. {{< /note >}} ### 네임스페이스 조회 @@ -109,6 +109,16 @@ kubectl api-resources --namespaced=true kubectl api-resources --namespaced=false ``` +## 자동 레이블링 + +{{< feature-state state="beta" for_k8s_version="1.21" >}} + +쿠버네티스 컨트롤 플레인은 `NamespaceDefaultLabelName` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 +활성화된 경우 모든 네임스페이스에 변경할 수 없는(immutable) {{< glossary_tooltip text="레이블" term_id="label" >}} +`kubernetes.io / metadata.name` 을 설정한다. +레이블 값은 네임스페이스 이름이다. + + ## {{% heading "whatsnext" %}} * [신규 네임스페이스 생성](/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)에 대해 더 배우기. diff --git a/content/ko/docs/concepts/policy/node-resource-managers.md b/content/ko/docs/concepts/policy/node-resource-managers.md new file mode 100644 index 0000000000..fb3e5f46f5 --- /dev/null +++ b/content/ko/docs/concepts/policy/node-resource-managers.md @@ -0,0 +1,22 @@ +--- + + + +title: 노드 리소스 매니저 +content_type: 개념 +weight: 50 +--- + + + +쿠버네티스는 지연 시간에 민감하고 처리량이 많은 워크로드를 지원하기 위해 리소스 매니저 세트를 제공한다. 매니저는 CPU, 장치 및 메모리 (hugepages) 리소스와 같은 특정한 요구 사항으로 구성된 파드를 위해 노드의 리소스 할당을 조정하고 최적화하는 것을 목표로 한다. + + + +주 매니저인 토폴로지 매니저는 [정책](/docs/tasks/administer-cluster/topology-manager/)을 통해 전체 리소스 관리 프로세스를 조정하는 Kubelet 컴포넌트이다. + +개별 매니저의 구성은 다음의 문서에 자세히 기술되어 있다. + +- [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/) +- [장치 매니저](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#토폴로지-관리자와-장치-플러그인-통합) +- [메모리 관리 정책](/docs/tasks/administer-cluster/memory-manager/) diff --git a/content/ko/docs/concepts/policy/pod-security-policy.md b/content/ko/docs/concepts/policy/pod-security-policy.md index e3c67a4ff9..ff98e134eb 100644 --- a/content/ko/docs/concepts/policy/pod-security-policy.md +++ b/content/ko/docs/concepts/policy/pod-security-policy.md @@ -9,7 +9,10 @@ weight: 30 -{{< feature-state state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} + +파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더이상 사용되지 않으며, v1.25에서 제거된다. 사용 중단에 대한 상세 사항은 +[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다. 파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을 부여할 수 있다. @@ -46,10 +49,9 @@ _Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는 ## 파드 시큐리티 폴리시 활성화 -파드 시큐리티 폴리시 제어는 선택 사항(하지만 권장함)인 -[어드미션 -컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)로 -구현된다. [어드미션 컨트롤러 활성화](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)하면 +파드 시큐리티 폴리시 제어는 선택 사항인 [어드미션 +컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)로 구현된다. +[어드미션 컨트롤러를 활성화](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)하면 파드시큐리티폴리시가 적용되지만, 정책을 승인하지 않고 활성화하면 클러스터에 **파드가 생성되지 않는다.** @@ -108,11 +110,15 @@ roleRef: name: apiGroup: rbac.authorization.k8s.io subjects: -# Authorize specific service accounts: +# 네임스페이스의 모든 서비스 어카운트 승인(권장): +- kind: Group + apiGroup: rbac.authorization.k8s.io + name: system:serviceaccounts: +# 특정 서비스 어카운트 승인(권장하지 않음): - kind: ServiceAccount name: namespace: -# Authorize specific users (not recommended): +# 특정 사용자 승인(권장하지 않음): - kind: User apiGroup: rbac.authorization.k8s.io name: @@ -122,21 +128,55 @@ subjects: 실행되는 파드에 대해서만 사용 권한을 부여한다. 네임스페이스에서 실행되는 모든 파드에 접근 권한을 부여하기 위해 시스템 그룹과 쌍을 이룰 수 있다. ```yaml -# Authorize all service accounts in a namespace: +# 네임스페이스의 모든 서비스 어카운트 승인: - kind: Group apiGroup: rbac.authorization.k8s.io name: system:serviceaccounts -# Or equivalently, all authenticated users in a namespace: +# 또는 동일하게, 네임스페이스의 모든 승인된 사용자에게 사용 권한 부여 - kind: Group apiGroup: rbac.authorization.k8s.io name: system:authenticated ``` RBAC 바인딩에 대한 자세한 예는, -[역할 바인딩 예제](/docs/reference/access-authn-authz/rbac#role-binding-examples)를 참고하길 바란다. +[역할 바인딩 예제](/docs/reference/access-authn-authz/rbac#role-binding-examples)를 참고한다. 파드시큐리티폴리시 인증에 대한 전체 예제는 -[아래](#예제)를 참고하길 바란다. +[아래](#예제)를 참고한다. +### 추천 예제 + +파드시큐리티폴리시는 새롭고 간결해진 `PodSecurity` {{< glossary_tooltip +text="어드미션 컨트롤러" term_id="admission-controller" >}}로 대체되고 있다. +이 변경에 대한 상세사항은 +[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다. +다음 가이드라인을 참조하여 파드시큐리티폴리시를 새로운 어드미션 컨트롤러로 쉽게 전환할 수 있다. + +1. 파드시큐리티폴리시를 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)에 의해 정의된 폴리시로 한정한다. + - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}} + - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}} + - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}} + +2. `system:serviceaccounts:` (여기서 ``는 타겟 네임스페이스) 그룹을 사용하여 + 파드시큐리티폴리시를 전체 네임스페이스에만 바인드한다. 예시는 다음과 같다. + + ```yaml + apiVersion: rbac.authorization.k8s.io/v1 + # 이 클러스터롤바인딩(ClusterRoleBinding)을 통해 "development" 네임스페이스의 모든 파드가 기준 파드시큐리티폴리시(PSP)를 사용할 수 있다. + kind: ClusterRoleBinding + metadata: + name: psp-baseline-namespaces + roleRef: + kind: ClusterRole + name: psp-baseline + apiGroup: rbac.authorization.k8s.io + subjects: + - kind: Group + name: system:serviceaccounts:development + apiGroup: rbac.authorization.k8s.io + - kind: Group + name: system:serviceaccounts:canary + apiGroup: rbac.authorization.k8s.io + ``` ### 문제 해결 @@ -462,12 +502,12 @@ podsecuritypolicy "example" deleted 예를 들면 다음과 같습니다. ```yaml -allowedHostPaths: - # 이 정책은 "/foo", "/foo/", "/foo/bar" 등을 허용하지만, - # "/fool", "/etc/foo" 등은 허용하지 않는다. - # "/foo/../" 는 절대 유효하지 않다. - - pathPrefix: "/foo" - readOnly: true # 읽기 전용 마운트만 허용 + allowedHostPaths: + # 이 정책은 "/foo", "/foo/", "/foo/bar" 등을 허용하지만, + # "/fool", "/etc/foo" 등은 허용하지 않는다. + # "/foo/../" 는 절대 유효하지 않다. + - pathPrefix: "/foo" + readOnly: true # 읽기 전용 마운트만 허용 ``` {{< warning >}}호스트 파일시스템에 제한없는 접근을 부여하며, 컨테이너가 특권을 에스컬레이션 @@ -565,7 +605,7 @@ spec: 리눅스 기능은 전통적으로 슈퍼유저와 관련된 권한을 보다 세밀하게 분류한다. 이러한 기능 중 일부는 권한 에스컬레이션 또는 컨테이너 분류에 사용될 수 있으며 파드시큐리티폴리시에 의해 제한될 수 있다. 리눅스 기능에 대한 자세한 내용은 -[기능(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html)을 +[기능(7)](https://man7.org/linux/man-pages/man7/capabilities.7.html)을 참고하길 바란다. 다음 필드는 대문자로 표기된 기능 이름 목록을 @@ -659,5 +699,10 @@ spec: ## {{% heading "whatsnext" %}} +- [파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 +미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)에서 +파드시큐리티폴리시의 미래에 대해 알아본다. + - 폴리시 권장 사항에 대해서는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)을 참조한다. + - API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다. diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md index df23da5d57..b5254e4300 100644 --- a/content/ko/docs/concepts/policy/resource-quotas.md +++ b/content/ko/docs/concepts/policy/resource-quotas.md @@ -58,7 +58,8 @@ weight: 20 ## 리소스 쿼터 활성화 많은 쿠버네티스 배포판에 기본적으로 리소스 쿼터 지원이 활성화되어 있다. -{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} `--enable-admission-plugins=` 플래그의 인수 중 하나로 +{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} +`--enable-admission-plugins=` 플래그의 인수 중 하나로 `ResourceQuota`가 있는 경우 활성화된다. 해당 네임스페이스에 리소스쿼터가 있는 경우 특정 네임스페이스에 @@ -66,7 +67,9 @@ weight: 20 ## 컴퓨트 리소스 쿼터 -지정된 네임스페이스에서 요청할 수 있는 총 [컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/) 합을 제한할 수 있다. +지정된 네임스페이스에서 요청할 수 있는 총 +[컴퓨트 리소스](/ko/docs/concepts/configuration/manage-resources-containers/) +합을 제한할 수 있다. 다음과 같은 리소스 유형이 지원된다. @@ -124,6 +127,12 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. | `limits.ephemeral-storage` | 네임스페이스의 모든 파드에서 로컬 임시 스토리지 제한의 합은 이 값을 초과할 수 없음. | | `ephemeral-storage` | `requests.ephemeral-storage` 와 같음. | +{{< note >}} +CRI 컨테이너 런타임을 사용할 때, 컨테이너 로그는 임시 스토리지 쿼터에 포함된다. +이로 인해 스토리지 쿼터를 소진한 파드가 예기치 않게 축출될 수 있다. +자세한 내용은 [로깅 아키텍처](/ko/docs/concepts/cluster-administration/logging/)를 참조한다. +{{< /note >}} + ## 오브젝트 수 쿼터 다음 구문을 사용하여 모든 표준 네임스페이스 처리된(namespaced) 리소스 유형에 대한 @@ -188,7 +197,8 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. | `NotTerminating` | `.spec.activeDeadlineSeconds is nil`에 일치하는 파드 | | `BestEffort` | 최상의 서비스 품질을 제공하는 파드 | | `NotBestEffort` | 서비스 품질이 나쁜 파드 | -| `PriorityClass` | 지정된 [프라이올리티 클래스](/ko/docs/concepts/configuration/pod-priority-preemption)를 참조하여 일치하는 파드. | +| `PriorityClass` | 지정된 [프라이어리티클래스](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)를 참조하여 일치하는 파드. | +| `CrossNamespacePodAffinity` | 크로스-네임스페이스 파드 [(안티)어피니티 용어]가 있는 파드 | `BestEffort` 범위는 다음의 리소스를 추적하도록 쿼터를 제한한다. @@ -243,13 +253,14 @@ GPU 리소스를 다음과 같이 쿼터를 정의할 수 있다. {{< feature-state for_k8s_version="v1.17" state="stable" >}} -특정 [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/#파드-우선순위)로 파드를 생성할 수 있다. +특정 [우선 순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/#파드-우선순위)로 파드를 생성할 수 있다. 쿼터 스펙의 `scopeSelector` 필드를 사용하여 파드의 우선 순위에 따라 파드의 시스템 리소스 사용을 제어할 수 있다. 쿼터 스펙의 `scopeSelector`가 파드를 선택한 경우에만 쿼터가 일치하고 사용된다. -`scopeSelector` 필드를 사용하여 우선 순위 클래스의 쿼터 범위를 지정하면, 쿼터 오브젝트는 다음의 리소스만 추적하도록 제한된다. +`scopeSelector` 필드를 사용하여 우선 순위 클래스의 쿼터 범위를 지정하면, +쿼터 오브젝트는 다음의 리소스만 추적하도록 제한된다. * `pods` * `cpu` @@ -429,6 +440,63 @@ memory 0 20Gi pods 0 10 ``` +### 네임스페이스 간 파드 어피니티 쿼터 + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +오퍼레이터는 네임스페이스를 교차하는 어피니티가 있는 파드를 가질 수 있는 네임스페이스를 +제한하기 위해 `CrossNamespacePodAffinity` 쿼터 범위를 사용할 수 있다. 특히, 파드 어피니티 용어의 +`namespaces` 또는 `namespaceSelector` 필드를 설정할 수 있는 파드를 제어한다. + +안티-어피니티 제약 조건이 있는 파드는 장애 도메인에서 다른 모든 네임스페이스의 파드가 예약되지 않도록 +차단할 수 있으므로 사용자가 네임스페이스 간 어피니티 용어를 +사용하지 못하도록 하는 것이 바람직할 수 있다. + +이 범위 오퍼레이터를 사용하면 `CrossNamespaceAffinity` 범위와 하드(hard) 제한이 0인 +네임스페이스에 리소스 쿼터 오브젝트를 생성하여 특정 네임스페이스(아래 예에서 `foo-ns`)가 네임스페이스 간 파드 어피니티를 +사용하는 파드를 사용하지 못하도록 방지할 수 있다. + +```yaml +apiVersion: v1 +kind: ResourceQuota +metadata: + name: disable-cross-namespace-affinity + namespace: foo-ns +spec: + hard: + pods: "0" + scopeSelector: + matchExpressions: + - scopeName: CrossNamespaceAffinity +``` + +오퍼레이터가 기본적으로 `namespaces` 및 `namespaceSelector` 사용을 허용하지 않고, +특정 네임스페이스에만 허용하려는 경우, kube-apiserver 플래그 --admission-control-config-file를 +다음의 구성 파일의 경로로 설정하여 `CrossNamespaceAffinity` 를 +제한된 리소스로 구성할 수 있다. + +```yaml +apiVersion: apiserver.config.k8s.io/v1 +kind: AdmissionConfiguration +plugins: +- name: "ResourceQuota" + configuration: + apiVersion: apiserver.config.k8s.io/v1 + kind: ResourceQuotaConfiguration + limitedResources: + - resource: pods + matchScopes: + - scopeName: CrossNamespaceAffinity +``` + +위의 구성을 사용하면, 파드는 생성된 네임스페이스에 `CrossNamespaceAffinity` 범위가 있는 리소스 쿼터 오브젝트가 있고, +해당 필드를 사용하는 파드 수보다 크거나 같은 하드 제한이 있는 경우에만 +파드 어피니티에서 `namespaces` 및 `namespaceSelector` 를 사용할 수 있다. + +이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서 +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) +`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다. + ## 요청과 제한의 비교 {#requests-vs-limits} 컴퓨트 리소스를 할당할 때 각 컨테이너는 CPU 또는 메모리에 대한 요청과 제한값을 지정할 수 있다. @@ -492,7 +560,7 @@ kubectl create -f ./object-counts.yaml --namespace=myspace kubectl get quota --namespace=myspace ``` -``` +```none NAME AGE compute-resources 30s object-counts 32s @@ -502,7 +570,7 @@ object-counts 32s kubectl describe quota compute-resources --namespace=myspace ``` -``` +```none Name: compute-resources Namespace: myspace Resource Used Hard @@ -518,7 +586,7 @@ requests.nvidia.com/gpu 0 4 kubectl describe quota object-counts --namespace=myspace ``` -``` +```none Name: object-counts Namespace: myspace Resource Used Hard @@ -615,10 +683,10 @@ plugins: {{< codenew file="policy/priority-class-resourcequota.yaml" >}} ```shell -$ kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system +kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system ``` -``` +```none resourcequota/pods-cluster-services created ``` diff --git a/content/ko/docs/concepts/scheduling-eviction/_index.md b/content/ko/docs/concepts/scheduling-eviction/_index.md index 5cd57c3a29..7128dbe99f 100644 --- a/content/ko/docs/concepts/scheduling-eviction/_index.md +++ b/content/ko/docs/concepts/scheduling-eviction/_index.md @@ -1,7 +1,37 @@ --- -title: "스케줄링과 축출(eviction)" +title: "스케줄링, 선점(Preemption), 축출(Eviction)" weight: 90 +content_type: concept description: > - 쿠버네티스에서, 스케줄링은 kubelet이 파드를 실행할 수 있도록 파드가 노드와 일치하는지 확인하는 것을 말한다. - 축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 장애로 처리하는 프로세스이다. + 쿠버네티스에서, 스케줄링은 kubelet이 파드를 실행할 수 있도록 + 파드를 노드에 할당하는 것을 말한다. + 선점은 우선순위가 높은 파드가 노드에 스케줄될 수 있도록 + 우선순위가 낮은 파드를 종료시키는 과정을 말한다. + 축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 종료시키는 프로세스이다. +no_list: true --- + +쿠버네티스에서, 스케줄링은 {{}}이 파드를 실행할 수 있도록 +{{}}를 +{{}}에 할당하는 것을 말한다. +선점은 {{}}가 높은 파드가 노드에 스케줄될 수 있도록 +우선순위가 낮은 파드를 종료시키는 과정을 말한다. +축출은 리소스가 부족한 노드에서 하나 이상의 파드를 사전에 종료시키는 프로세스이다. + +## 스케줄링 + +* [쿠버네티스 스케줄러](/ko/docs/concepts/scheduling-eviction/kube-scheduler/) +* [노드에 파드 할당하기](/ko/docs/concepts/scheduling-eviction/assign-pod-node/) +* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/) +* [테인트(Taints)와 톨러레이션(Tolerations)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/) +* [스케줄링 프레임워크](/docs/concepts/scheduling-eviction/scheduling-framework/) +* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) +* [확장된 리소스를 위한 리소스 빈 패킹(bin packing)](/ko/docs/concepts/scheduling-eviction/resource-bin-packing/) + +## 파드 중단(disruption) + +{{}} + +* [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/) +* [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/) diff --git a/content/ko/docs/concepts/scheduling-eviction/api-eviction.md b/content/ko/docs/concepts/scheduling-eviction/api-eviction.md new file mode 100644 index 0000000000..53724320b0 --- /dev/null +++ b/content/ko/docs/concepts/scheduling-eviction/api-eviction.md @@ -0,0 +1,18 @@ +--- +title: API를 이용한 축출(Eviction) +content_type: concept +weight: 70 +--- + +{{< glossary_definition term_id="api-eviction" length="short" >}}
    + +`kubectl drain` 명령과 같은 kube-apiserver의 클라이언트를 사용하여, +축출 API를 직접 호출해 축출 요청을 할 수 있다. +그러면 API 서버가 파드를 종료하는 `Eviction` 오브젝트가 생성된다. + +API를 이용한 축출은 구성된 [`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/) 및 [`terminationGracePeriodSeconds`](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)를 준수한다. + +## {{% heading "whatsnext" %}} + +- [노드-압박 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 더 배우기 +- [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 더 배우기 diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md index dba31a6c7f..f46e075b57 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -11,18 +11,17 @@ weight: 20 -{{< glossary_tooltip text="파드" term_id="pod" >}}를 특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}}에서만 동작하도록 하거나, -특정 노드들을 선호하도록 제한할 수 있다. -이를 수행하는 방법에는 여러 가지가 있으며, 권장되는 접근 방식은 모두 -[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택한다. -보통 스케줄러가 자동으로 합리적인 배치(예: 노드들에 걸쳐 파드를 분배하거나, -자원이 부족한 노드에 파드를 배치하지 않는 등)를 수행하기에 이런 제약 조건은 필요하지 않지만 -간혹 파드가 배치되는 노드에 대해 더 많은 제어를 원할 수 있는 상황이 있다. +특정한 {{< glossary_tooltip text="노드(들)" term_id="node" >}} 집합에서만 동작하도록 +{{< glossary_tooltip text="파드" term_id="pod" >}}를 제한할 수 있다. +이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두 +[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택을 용이하게 한다. +보통 스케줄러가 자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록 +노드 간에 파드를 분배하는 등)를 수행하기에 이러한 제약 조건은 필요하지 않지만 +간혹 파드가 배포할 노드를 제어해야 하는 경우가 있다. 예를 들어 SSD가 장착된 머신에 파드가 연결되도록 하거나 또는 동일한 가용성 영역(availability zone)에서 많은 것을 통신하는 두 개의 서로 다른 서비스의 파드를 같이 배치할 수 있다. - ## 노드 셀렉터(nodeSelector) @@ -73,7 +72,7 @@ spec: ## 넘어가기 전에: 내장 노드 레이블들 {#built-in-node-labels} [붙인](#1-단계-노드에-레이블-붙이기) 레이블뿐만 아니라, 노드에는 -표준 레이블 셋이 미리 채워져 있다. 이들 목록은 [잘 알려진 레이블, 어노테이션 및 테인트](/docs/reference/kubernetes-api/labels-annotations-taints/)를 참고한다. +표준 레이블 셋이 미리 채워져 있다. 이들 목록은 [잘 알려진 레이블, 어노테이션 및 테인트](/ko/docs/reference/labels-annotations-taints/)를 참고한다. {{< note >}} 이 레이블들의 값은 클라우드 공급자에 따라 다르고 신뢰성이 보장되지 않는다. @@ -120,13 +119,13 @@ spec: 여기에 현재 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 로 부르는 두 가지 종류의 노드 어피니티가 있다. 전자는 파드가 노드에 스케줄되도록 *반드시* -규칙을 만족해야 하는 것(`nodeSelector` 와 같으나 보다 표현적인 구문을 사용해서)을 지정하고, +규칙을 만족해야 하는 것(`nodeSelector` 와 비슷하나 보다 표현적인 구문을 사용해서)을 지정하고, 후자는 스케줄러가 시도하려고는 하지만, 보증하지 않는 *선호(preferences)* 를 지정한다는 점에서 이를 각각 "엄격함(hard)" 과 "유연함(soft)" 으로 생각할 수 있다. 이름의 "IgnoredDuringExecution" 부분은 `nodeSelector` 작동 방식과 유사하게 노드의 -레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 여전히 그 노드에서 +레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 그 노드에서 동작한다는 의미이다. 향후에는 파드의 노드 어피니티 요구 사항을 충족하지 않는 노드에서 파드를 제거한다는 -점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 같은 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다. +점을 제외하고는 `preferredDuringSchedulingIgnoredDuringExecution` 와 동일한 `requiredDuringSchedulingIgnoredDuringExecution` 를 제공할 계획이다. 따라서 `requiredDuringSchedulingIgnoredDuringExecution` 의 예로는 "인텔 CPU가 있는 노드에서만 파드 실행"이 될 수 있고, `preferredDuringSchedulingIgnoredDuringExecution` 의 예로는 "장애 조치 영역 XYZ에 파드 집합을 실행하려고 @@ -271,6 +270,18 @@ PodSpec에 지정된 NodeAffinity도 적용된다. 파드를 노드에 스케줄하려면 `requiredDuringSchedulingIgnoredDuringExecution` 어피니티와 안티-어피니티와 연관된 `matchExpressions` 가 모두 충족되어야 한다. +#### 네임스페이스 셀렉터 +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +사용자는 네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다. +어피니티 용어는 `namespaceSelector` 에서 선택한 네임스페이스와 `namespaces` 필드에 나열된 네임스페이스의 결합에 적용된다. +빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, null 또는 빈 `namespaces` 목록과 +null `namespaceSelector` 는 "이 파드의 네임스페이스"를 의미한다. + +이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서 +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) +`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다. + #### 더 실용적인 유스케이스 파드간 어피니티와 안티-어피니티는 레플리카셋, 스테이트풀셋, 디플로이먼트 등과 같은 @@ -391,7 +402,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3 `nodeName` 은 PodSpec의 필드이다. 만약 비어있지 않으면, 스케줄러는 파드를 무시하고 명명된 노드에서 실행 중인 kubelet이 파드를 실행하려고 한다. 따라서 만약 PodSpec에 `nodeName` 가 -제공된 경우, 노드 선텍을 위해 위의 방법보다 우선한다. +제공된 경우, 노드 선택을 위해 위의 방법보다 우선한다. `nodeName` 을 사용해서 노드를 선택할 때의 몇 가지 제한은 다음과 같다. diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md index 83059ba931..8c17269a64 100644 --- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -80,12 +80,12 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순 1. [스케줄링 정책](/ko/docs/reference/scheduling/config/#프로파일)을 사용하면 필터링을 위한 _단정(Predicates)_ 및 스코어링을 위한 _우선순위(Priorities)_ 를 구성할 수 있다. 1. [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#프로파일)을 사용하면 `QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 등의 다른 스케줄링 단계를 구현하는 플러그인을 구성할 수 있다. 다른 프로파일을 실행하도록 kube-scheduler를 구성할 수도 있다. - ## {{% heading "whatsnext" %}} * [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기 * [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기 * kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기 +* [kube-scheduler 구성(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽기 * [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기 * [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기 * [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기 diff --git a/content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md b/content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md new file mode 100644 index 0000000000..a3330a1b0d --- /dev/null +++ b/content/ko/docs/concepts/scheduling-eviction/node-pressure-eviction.md @@ -0,0 +1,411 @@ +--- +title: 노드-압박 축출 +content_type: concept +weight: 60 +--- + +{{}}
    + +{{}}은 +클러스터 노드의 CPU, 메모리, 디스크 공간, 파일시스템 inode와 같은 자원을 모니터링한다. +이러한 자원 중 하나 이상이 특정 소모 수준에 도달하면, +kubelet은 하나 이상의 파드를 능동적으로 중단시켜 +자원을 회수하고 고갈 상황을 방지할 수 있다. + +노드-압박 축출 과정에서, kubelet은 축출할 파드의 `PodPhase`를 +`Failed`로 설정한다. 이로써 파드가 종료된다. + +노드-압박 축출은 +[API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)과는 차이가 있다. + +kubelet은 이전에 설정된 `PodDisruptionBudget` 값이나 파드의 `terminationGracePeriodSeconds` 값을 따르지 않는다. +[소프트 축출 임계값](#soft-eviction-thresholds)을 사용하는 경우, +kubelet은 이전에 설정된 `eviction-max-pod-grace-period` 값을 따른다. +[하드 축출 임계값](#hard-eviction-thresholds)을 사용하는 경우, 파드 종료 시 `0s` 만큼 기다린 후 종료한다(즉, 기다리지 않고 바로 종료한다). + +실패한 파드를 새로운 파드로 교체하는 +{{< glossary_tooltip text="워크로드" term_id="workload" >}} 리소스(예: +{{< glossary_tooltip text="스테이트풀셋(StatefulSet)" term_id="statefulset" >}} 또는 +{{< glossary_tooltip text="디플로이먼트(Deployment)" term_id="deployment" >}})가 파드를 관리하는 경우, +컨트롤 플레인이나 `kube-controller-manager`가 축출된 파드를 대신할 새 파드를 생성한다. + +{{}} +kubelet은 최종 사용자 파드를 종료하기 전에 +먼저 [노드 수준 자원을 회수](#reclaim-node-resources)하려고 시도한다. +예를 들어, 디스크 자원이 부족하면 먼저 사용하지 않는 컨테이너 이미지를 제거한다. +{{}} + +kubelet은 축출 결정을 내리기 위해 다음과 같은 다양한 파라미터를 사용한다. + + * 축출 신호 + * 축출 임계값 + * 모니터링 간격 + +### 축출 신호 {#eviction-signals} + +축출 신호는 특정 시점에서 특정 자원의 현재 상태이다. +Kubelet은 노드에서 사용할 수 있는 리소스의 최소량인 +축출 임계값과 축출 신호를 비교하여 +축출 결정을 내린다. + +Kubelet은 다음과 같은 축출 신호를 사용한다. + +| 축출 신호 | 설명 | +|----------------------|---------------------------------------------------------------------------------------| +| `memory.available` | `memory.available` := `node.status.capacity[memory]` - `node.stats.memory.workingSet` | +| `nodefs.available` | `nodefs.available` := `node.stats.fs.available` | +| `nodefs.inodesFree` | `nodefs.inodesFree` := `node.stats.fs.inodesFree` | +| `imagefs.available` | `imagefs.available` := `node.stats.runtime.imagefs.available` | +| `imagefs.inodesFree` | `imagefs.inodesFree` := `node.stats.runtime.imagefs.inodesFree` | +| `pid.available` | `pid.available` := `node.stats.rlimit.maxpid` - `node.stats.rlimit.curproc` | + +이 표에서, `설명` 열은 kubelet이 축출 신호 값을 계산하는 방법을 나타낸다. +각 축출 신호는 백분율 또는 숫자값을 지원한다. +Kubelet은 총 용량 대비 축출 신호의 백분율 값을 +계산한다. + +`memory.available` 값은 `free -m`과 같은 도구가 아니라 cgroupfs로부터 도출된다. +이는 `free -m`이 컨테이너 안에서는 동작하지 않고, 또한 사용자가 +[node allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +기능을 사용하는 경우 자원 부족에 대한 결정은 루트 노드뿐만 아니라 +cgroup 계층 구조의 최종 사용자 파드 부분에서도 지역적으로 이루어지기 때문에 중요하다. +이 [스크립트](/examples/admin/resource/memory-available.sh)는 +kubelet이 `memory.available`을 계산하기 위해 수행하는 동일한 단계들을 재현한다. +kubelet은 메모리 압박 상황에서 메모리가 회수 가능하다고 가정하므로, +inactive_file(즉, 비활성 LRU 목록의 파일 기반 메모리 바이트 수)을 +계산에서 제외한다. + +kubelet은 다음과 같은 파일시스템 파티션을 지원한다. + +1. `nodefs`: 노드의 메인 파일시스템이며, 로컬 디스크 볼륨, emptyDir, + 로그 스토리지 등에 사용된다. 예를 들어 `nodefs`는 `/var/lib/kubelet/`을 포함한다. +1. `imagefs`: 컨테이너 런타임이 컨테이너 이미지 및 + 컨테이너 쓰기 가능 레이어를 저장하는 데 사용하는 선택적 파일시스템이다. + +Kubelet은 이러한 파일시스템을 자동으로 검색하고 다른 파일시스템은 무시한다. +Kubelet은 다른 구성은 지원하지 않는다. + +{{}} +일부 kubelet 가비지 수집 기능은 더 이상 사용되지 않으며 축출로 대체되었다. +사용 중지된 기능의 목록은 [kubelet 가비지 수집 사용 중단](/ko/docs/concepts/cluster-administration/kubelet-garbage-collection/#사용-중단-deprecation)을 참조한다. +{{}} + +### 축출 임계값 + +kubelet이 축출 결정을 내릴 때 사용하는 축출 임계값을 +사용자가 임의로 설정할 수 있다. + +축출 임계값은 `[eviction-signal][operator][quantity]` 형태를 갖는다. + +* `eviction-signal`에는 사용할 [축출 신호](#eviction-signals)를 적는다. +* `operator`에는 [관계연산자](https://ko.wikipedia.org/wiki/관계연산자#표준_관계연산자)를 + 적는다(예: `<` - 미만) +* `quantity`에는 `1Gi`와 같이 축출 임계값 수치를 적는다. + `quantity`에 들어가는 값은 쿠버네티스가 사용하는 수치 표현 방식과 맞아야 한다. + 숫자값 또는 백분율(`%`)을 사용할 수 있다. + +예를 들어, 노드에 총 `10Gi`의 메모리가 있고 +`1Gi` 아래로 내려갔을 때 축출이 시작되도록 만들고 싶으면, 축출 임계값을 +`memory.available<10%` 또는 `memory.available<1Gi` 형태로 정할 수 있다. 둘을 동시에 사용할 수는 없다. + +소프트 축출 임계값과 하드 축출 임계값을 설정할 수 있다. + +#### 소프트 축출 임계값 {#soft-eviction-thresholds} + +소프트 축출 임계값은 관리자가 설정하는 유예 시간(필수)과 함께 정의된다. +kubelet은 유예 시간이 초과될 때까지 파드를 제거하지 않는다. +유예 시간이 지정되지 않으면 kubelet 시작 시 +오류가 반환된다. + +kubelet이 축출 과정에서 사용할 수 있도록, +'소프트 축출 임계값'과 '최대 허용 파드 종료 유예 시간' 둘 다를 설정할 수 있다. +'최대 허용 파드 종료 유예 시간'이 설정되어 있는 상태에서 '소프트 축출 임계값'에 도달하면, +kubelet은 두 유예 시간 중 작은 쪽을 적용한다. +'최대 허용 파드 종료 유예 시간'을 설정하지 않으면, +kubelet은 축출된 파드를 유예 시간 없이 즉시 종료한다. + +소프트 축출 임계값을 설정할 때 다음과 같은 플래그를 사용할 수 있다. + +* `eviction-soft`: 축출 임계값(예: `memory.available<1.5Gi`)의 집합이며, + 지정된 유예 시간동안 이 축출 임계값 조건이 충족되면 파드 축출이 트리거된다. +* `eviction-soft-grace-period`: 축출 유예 시간의 집합이며, + 소프트 축출 임계값 조건이 이 유예 시간동안 충족되면 파드 축출이 트리거된다. +* `eviction-max-pod-grace-period`: '최대 허용 파드 종료 유예 시간(단위: 초)'이며, + 소프트 축출 임계값 조건이 충족되어 파드를 종료할 때 사용한다. + +#### 하드 축출 임계값 {#hard-eviction-thresholds} + +하드 축출 임계값에는 유예 시간이 없다. 하드 축출 임계값 조건이 충족되면, +kubelet은 고갈된 자원을 회수하기 위해 파드를 유예 시간 없이 +즉시 종료한다. + +`eviction-hard` 플래그를 사용하여 하드 축출 +임계값(예: `memory.available<1Gi`)을 설정할 수 있다. + +kubelet은 다음과 같은 하드 축출 임계값을 기본적으로 설정하고 있다. + +* `memory.available<100Mi` +* `nodefs.available<10%` +* `imagefs.available<15%` +* `nodefs.inodesFree<5%` (리눅스 노드) + +### 축출 모니터링 시간 간격 + +kubelet은 `housekeeping-interval`에 설정된 시간 간격(기본값: `10s`)마다 +축출 임계값을 확인한다. + +### 노드 컨디션 {#node-conditions} + +kubelet은 하드/소프트 축출 임계값 조건이 충족되어 +노드 압박이 발생했다는 것을 알리기 위해, +설정된 유예 시간과는 관계없이 노드 컨디션을 보고한다. + +kubelet은 다음과 같이 노드 컨디션과 축출 신호를 매핑한다. + +| 노드 컨디션 | 축출 신호 | 설명 | +|-------------------|---------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------| +| `MemoryPressure` | `memory.available` | 노드의 가용 메모리 양이 축출 임계값에 도달함 | +| `DiskPressure` | `nodefs.available`, `nodefs.inodesFree`, `imagefs.available`, 또는 `imagefs.inodesFree` | 노드의 루트 파일시스템 또는 이미지 파일시스템의 가용 디스크 공간 또는 inode의 수가 축출 임계값에 도달함 | +| `PIDPressure` | `pid.available` | (리눅스) 노드의 가용 프로세스 ID(PID)가 축출 임계값 이하로 내려옴 | + +kubelet은 `--node-status-update-frequency`에 설정된 +시간 간격(기본값: `10s`)마다 노드 컨디션을 업데이트한다. + +#### 노드 컨디션 진동(oscillation) + +경우에 따라, 노드의 축출 신호값이 사전에 설정된 유예 시간 동안 유지되지 않고 +소프트 축출 임계값을 중심으로 진동할 수 있다. 이로 인해 노드 컨디션이 계속 +`true`와 `false`로 바뀌며, 잘못된 축출 결정을 야기할 수 있다. + +이러한 진동을 방지하기 위해, `eviction-pressure-transition-period` 플래그를 +사용하여 kubelet이 노드 컨디션을 다른 상태로 바꾸기 위해 기다려야 하는 시간을 +설정할 수 있다. 기본값은 `5m`이다. + +### 노드-수준 자원 회수하기 {#reclaim-node-resources} + +kubelet은 최종 사용자 파드를 축출하기 전에 노드-수준 자원 회수를 시도한다. + +`DiskPressure` 노드 컨디션이 보고되면, +kubelet은 노드의 파일시스템을 기반으로 노드-수준 자원을 회수한다. + +#### `imagefs`가 있는 경우 + +컨테이너 런타임이 사용할 전용 `imagefs` 파일시스템이 노드에 있으면, +kubelet은 다음 작업을 수행한다. + + * `nodefs` 파일시스템이 축출 임계값 조건을 충족하면, + kubelet은 종료된 파드와 컨테이너에 대해 가비지 수집을 수행한다. + * `imagefs` 파일시스템이 축출 임계값 조건을 충족하면, + kubelet은 모든 사용중이지 않은 이미지를 삭제한다. + +#### `imagefs`가 없는 경우 + +노드에 `nodefs` 파일시스템만 있고 이것이 축출 임계값 조건을 충족한 경우, +kubelet은 다음 순서로 디스크 공간을 확보한다. + +1. 종료된 파드와 컨테이너에 대해 가비지 수집을 수행한다. +1. 사용중이지 않은 이미지를 삭제한다. + +### kubelet 축출을 위한 파드 선택 + +kubelet이 노드-수준 자원을 회수했음에도 축출 신호가 임계값 아래로 내려가지 않으면, +kubelet은 최종 사용자 파드 축출을 시작한다. + +kubelet은 파드 축출 순서를 결정하기 위해 다음의 파라미터를 활용한다. + +1. 파드의 자원 사용량이 요청량을 초과했는지 여부 +1. [파드 우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/) +1. 파드의 자원 요청량 대비 자원 사용량 + +결과적으로, kubelet은 다음과 같은 순서로 파드의 축출 순서를 정하고 축출을 수행한다. + +1. `BestEffort` 또는 `Burstable` 파드 중 자원 사용량이 요청량을 초과한 파드. + 이 파드들은 파드들의 우선순위, 그리고 자원 사용량이 요청량을 + 얼마나 초과했는지에 따라 축출된다. +1. `Guaranteed`, `Burstable` 파드 중 자원 사용량이 요청량보다 낮은 파드는 + 우선순위에 따라 후순위로 축출된다. + +{{}} +kubelet이 파드 축출 순서를 결정할 때 파드의 QoS 클래스는 이용하지 않는다. +메모리 등의 자원을 회수할 때, QoS 클래스를 이용하여 가장 가능성이 높은 파드 축출 순서를 예측할 수는 있다. +QoS는 EphemeralStorage 요청에 적용되지 않으므로, +노드가 예를 들어 `DiskPressure` 아래에 있는 경우 위의 시나리오가 적용되지 않는다. +{{}} + +`Guaranteed` 파드는 모든 컨테이너에 대해 자원 요청량과 제한이 명시되고 +그 둘이 동일할 때에만 보장(guaranteed)된다. 다른 파드의 자원 사용으로 인해 +`Guaranteed` 파드가 축출되는 일은 발생하지 않는다. 만약 시스템 데몬(예: +`kubelet`, `docker`, `journald`)이 `system-reserved` 또는 `kube-reserved` +할당을 통해 예약된 것보다 더 많은 자원을 소비하고, 노드에는 요청량보다 적은 양의 +자원을 사용하고 있는 `Guaranteed` / `Burstable` 파드만 존재한다면, +kubelet은 노드 안정성을 유지하고 자원 고갈이 다른 파드에 미칠 영향을 통제하기 위해 +이러한 파드 중 하나를 골라 축출해야 한다. +이 경우, 가장 낮은 `Priority`를 갖는 파드가 선택된다. + +`inodes`와 `PIDs`에 대한 요청량은 정의하고 있지 않기 때문에, kubelet이 `inode` +또는 `PID` 고갈 때문에 파드를 축출할 때에는 파드의 `Priority`를 이용하여 축출 +순위를 정한다. + +노드에 전용 `imagefs` 파일시스템이 있는지 여부에 따라 kubelet이 파드 축출 순서를 +정하는 방식에 차이가 있다. + +#### `imagefs`가 있는 경우 + +`nodefs`로 인한 축출의 경우, kubelet은 `nodefs` +사용량(`모든 컨테이너의 로컬 볼륨 + 로그`)을 기준으로 축출 순서를 정한다. + +`imagefs`로 인한 축출의 경우, kubelet은 모든 컨테이너의 +쓰기 가능한 레이어(writable layer) 사용량을 기준으로 축출 순서를 정한다. + +#### `imagefs`가 없는 경우 + +`nodefs`로 인한 축출의 경우, kubelet은 각 파드의 총 +디스크 사용량(`모든 컨테이너의 로컬 볼륨 + 로그 + 쓰기 가능한 레이어`)을 기준으로 축출 순서를 정한다. + +### 최소 축출 회수량 + +경우에 따라, 파드를 축출했음에도 적은 양의 자원만이 회수될 수 있다. +이로 인해 kubelet이 반복적으로 축출 임계값 도달을 감지하고 +여러 번의 축출을 수행할 수 있다. + +`--eviction-minimum-reclaim` 플래그 또는 +[kubelet 설정 파일](/docs/tasks/administer-cluster/kubelet-config-file/)을 이용하여 +각 자원에 대한 최소 회수량을 설정할 수 있다. kubelet이 자원 부족 상황을 감지하면, +앞서 설정한 최소 회수량에 도달할때까지 회수를 계속 진행한다. + +예를 들어, 다음 YAML은 최소 회수량을 정의하고 있다. + +```yaml +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +evictionHard: + memory.available: "500Mi" + nodefs.available: "1Gi" + imagefs.available: "100Gi" +evictionMinimumReclaim: + memory.available: "0Mi" + nodefs.available: "500Mi" + imagefs.available: "2Gi" +``` + +이 예제에서, 만약 `nodefs.available` 축출 신호가 축출 임계값 조건에 도달하면, +kubelet은 축출 신호가 임계값인 `1Gi`에 도달할 때까지 자원을 회수하며, +이어서 축출 신호가 `1.5Gi`에 도달할 때까지 최소 `500Mi` 이상의 자원을 +회수한다. + +유사한 방식으로, kubelet은 `imagefs.available` 축출 신호가 +`102Gi`에 도달할 때까지 `imagefs` 자원을 회수한다. + +모든 자원에 대해 `eviction-minimum-reclaim`의 기본값은 `0`이다. + +### 노드 메모리 부족 시의 동작 + +kubelet의 메모리 회수가 가능하기 이전에 +노드에 메모리 부족(out of memory, 이하 OOM) 이벤트가 발생하면, +노드는 [oom_killer](https://lwn.net/Articles/391222/)에 의존한다. + +kubelet은 각 파드에 설정된 QoS를 기반으로 각 컨테이너에 `oom_score_adj` 값을 설정한다. + +| 서비스 품질(Quality of Service) | oom_score_adj | +|--------------------|-----------------------------------------------------------------------------------| +| `Guaranteed` | -997 | +| `BestEffort` | 1000 | +| `Burstable` | min(max(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999) | + +{{}} +또한, kubelet은 `system-node-critical` {{}}를 갖는 파드의 컨테이너에 +`oom_score_adj` 값을 `-997`로 설정한다. +{{}} + +노드가 OOM을 겪기 전에 kubelet이 메모리를 회수하지 못하면, `oom_killer`가 노드의 +메모리 사용률 백분율을 이용하여 `oom_score`를 계산하고, 각 컨테이너의 실질 +`oom_score`를 구하기 위해 `oom_score_adj`를 더한다. 그 뒤 `oom_score`가 가장 높은 +컨테이너부터 종료시킨다. + +이는 곧, 스케줄링 요청에 비해 많은 양의 메모리를 사용하면서 +QoS가 낮은 파드에 속한 컨테이너가 먼저 종료됨을 의미한다. + +파드 축출과 달리, 컨테이너가 OOM으로 인해 종료되면, +`kubelet`이 컨테이너의 `RestartPolicy`를 기반으로 컨테이너를 다시 실행할 수 있다. + +### 추천 예시 {#node-pressure-eviction-good-practices} + +아래 섹션에서 축출 설정에 대한 추천 예시를 소개한다. + +#### 스케줄 가능한 자원과 축출 정책 + +kubelet에 축출 정책을 설정할 때, 만약 어떤 파드 배치가 즉시 메모리 압박을 +야기하기 때문에 축출을 유발한다면 스케줄러가 그 파드 배치를 수행하지 않도록 +설정해야 한다. + +다음 시나리오를 가정한다. + +* 노드 메모리 용량: `10Gi` +* 운영자는 시스템 데몬(커널, `kubelet` 등)을 위해 메모리 용량의 10%를 확보해 놓고 싶어 한다. +* 운영자는 시스템 OOM 발생을 줄이기 위해 메모리 사용률이 95%인 상황에서 파드를 축출하고 싶어한다. + +이것이 실현되도록, kubelet이 다음과 같이 실행된다. + +``` +--eviction-hard=memory.available<500Mi +--system-reserved=memory=1.5Gi +``` + +이 환경 설정에서, `--system-reserved` 플래그는 시스템 용으로 `1.5Gi` 메모리를 +확보하는데, 이는 `총 메모리의 10% + 축출 임계값`에 해당된다. + +파드가 요청량보다 많은 메모리를 사용하거나 시스템이 `1Gi` 이상의 메모리를 +사용하여, `memory.available` 축출 신호가 `500Mi` 아래로 내려가면 노드가 축출 +임계값에 도달할 수 있다. + +#### 데몬셋(DaemonSet) + +파드 우선 순위(Priority)는 파드 축출 결정을 내릴 때의 주요 요소이다. +kubelet이 `DaemonSet`에 속하는 파드를 축출하지 않도록 하려면 +해당 파드의 파드 스펙에 충분히 높은 `priorityClass`를 지정한다. +또는 낮은 `priorityClass`나 기본값을 사용하여 +리소스가 충분할 때만 `DaemonSet` 파드가 실행되도록 허용할 수도 있다. + +### 알려진 이슈 + +다음 섹션에서는 리소스 부족 처리와 관련된 알려진 이슈에 대해 다룬다. + +#### kubelet이 메모리 압박을 즉시 감지하지 못할 수 있음 + +기본적으로 kubelet은 `cAdvisor`를 폴링하여 +일정한 간격으로 메모리 사용량 통계를 수집한다. +해당 타임 윈도우 내에서 메모리 사용량이 빠르게 증가하면 kubelet이 +`MemoryPressure`를 충분히 빠르게 감지하지 못해 `OOMKiller`가 계속 호출될 수 있다. + +`--kernel-memcg-notification` 플래그를 사용하여 +kubelet의 `memcg` 알림 API가 임계값을 초과할 때 즉시 알림을 받도록 +할 수 있다. + +사용률(utilization)을 극단적으로 높이려는 것이 아니라 오버커밋(overcommit)에 대한 합리적인 조치만 원하는 경우, +이 문제에 대한 현실적인 해결 방법은 `--kube-reserved` 및 +`--system-reserved` 플래그를 사용하여 시스템에 메모리를 할당하는 것이다. + +#### `active_file` 메모리가 사용 가능한 메모리로 간주되지 않음 + +리눅스에서, 커널은 활성 LRU 목록의 파일 지원 메모리 바이트 수를 `active_file` +통계로 추적한다. kubelet은 `active_file` 메모리 영역을 회수할 수 없는 것으로 +취급한다. 임시 로컬 스토리지를 포함하여 블록 지원 로컬 스토리지를 집중적으로 +사용하는 워크로드의 경우 파일 및 블록 데이터의 커널 수준 캐시는 최근에 액세스한 +많은 캐시 페이지가 `active_file`로 계산될 가능성이 있음을 의미한다. 활성 LRU +목록에 이러한 커널 블록 버퍼가 충분히 많으면, kubelet은 이를 높은 자원 사용 +상태로 간주하고 노드가 메모리 압박을 겪고 있다고 테인트를 표시할 수 있으며, 이는 +파드 축출을 유발한다. + +더 자세한 사항은 [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916)를 참고한다. + +집중적인 I/O 작업을 수행할 가능성이 있는 컨테이너에 대해 메모리 제한량 및 메모리 +요청량을 동일하게 설정하여 이 문제를 해결할 수 있다. 해당 컨테이너에 대한 최적의 +메모리 제한량을 추정하거나 측정해야 한다. + +## {{% heading "whatsnext" %}} + +* [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)에 대해 알아본다. +* [파드 우선순위와 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 알아본다. +* [PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/)에 대해 알아본다. +* [서비스 품질](/ko/docs/tasks/configure-pod-container/quality-service-pod/)(QoS)에 대해 알아본다. +* [축출 API](/docs/reference/generated/kubernetes-api/{{}}/#create-eviction-pod-v1-core)를 확인한다. diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md index 0f474338d9..b0da80ceae 100644 --- a/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-overhead.md @@ -1,7 +1,7 @@ --- title: 파드 오버헤드 content_type: concept -weight: 20 +weight: 30 --- diff --git a/content/ko/docs/concepts/configuration/pod-priority-preemption.md b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md similarity index 95% rename from content/ko/docs/concepts/configuration/pod-priority-preemption.md rename to content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md index 581525d833..f149290882 100644 --- a/content/ko/docs/concepts/configuration/pod-priority-preemption.md +++ b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -25,7 +25,7 @@ weight: 70 관리자는 리소스쿼터를 사용하여 사용자가 우선순위가 높은 파드를 생성하지 못하게 할 수 있다. -자세한 내용은 [기본적으로 프라이어리티 클래스(Priority Class) 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 +자세한 내용은 [기본적으로 프라이어리티클래스(Priority Class) 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 참고한다. {{< /warning >}} @@ -50,7 +50,7 @@ weight: 70 ## 프라이어리티클래스 -프라이어리티클래스는 프라이어리티 클래스 이름에서 우선순위의 정수 값으로의 매핑을 +프라이어리티클래스는 프라이어리티클래스 이름에서 우선순위의 정수 값으로의 매핑을 정의하는 네임스페이스가 아닌(non-namespaced) 오브젝트이다. 이름은 프라이어리티클래스 오브젝트의 메타데이터의 `name` 필드에 지정된다. 값은 필수 `value` 필드에 지정되어 있다. 값이 클수록, 우선순위가 @@ -96,7 +96,7 @@ metadata: name: high-priority value: 1000000 globalDefault: false -description: "이 프라이어리티 클래스는 XYZ 서비스 파드에만 사용해야 한다." +description: "이 프라이어리티클래스는 XYZ 서비스 파드에만 사용해야 한다." ``` ## 비-선점 프라이어리티클래스 {#non-preempting-priority-class} @@ -142,7 +142,7 @@ metadata: value: 1000000 preemptionPolicy: Never globalDefault: false -description: "이 프라이어리티 클래스는 다른 파드를 축출하지 않는다." +description: "이 프라이어리티클래스는 다른 파드를 축출하지 않는다." ``` ## 파드 우선순위 @@ -150,7 +150,7 @@ description: "이 프라이어리티 클래스는 다른 파드를 축출하지 프라이어리티클래스가 하나 이상 있으면, 그것의 명세에서 이들 프라이어리티클래스 이름 중 하나를 지정하는 파드를 생성할 수 있다. 우선순위 어드미션 컨트롤러는 `priorityClassName` 필드를 사용하고 우선순위의 정수 값을 -채운다. 프라이어리티 클래스를 찾을 수 없으면, 파드가 거부된다. +채운다. 프라이어리티클래스를 찾을 수 없으면, 파드가 거부된다. 다음의 YAML은 이전 예제에서 생성된 프라이어리티클래스를 사용하는 파드 구성의 예이다. 우선순위 어드미션 컨트롤러는 @@ -351,12 +351,12 @@ spec: 축출 대상으로 고려한다. QoS와 파드 우선순위를 모두 고려하는 유일한 컴포넌트는 -[kubelet 리소스 부족 축출](/docs/tasks/administer-cluster/out-of-resource/)이다. +[kubelet 리소스 부족 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)이다. kubelet은 부족한 리소스의 사용이 요청을 초과하는지 여부에 따라, 그런 다음 우선순위에 따라, 파드의 스케줄링 요청에 대한 부족한 컴퓨팅 리소스의 소비에 의해 먼저 축출 대상 파드의 순위를 매긴다. 더 자세한 내용은 -[엔드유저 파드 축출](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)을 +[엔드유저 파드 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/#evicting-end-user-pods)을 참조한다. kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 경우 @@ -367,4 +367,4 @@ kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 ## {{% heading "whatsnext" %}} -* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자. +* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자. diff --git a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md index d11b7fe2ae..1ac3b81262 100644 --- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -5,7 +5,7 @@ title: 확장된 리소스를 위한 리소스 빈 패킹(bin packing) content_type: concept -weight: 30 +weight: 80 --- @@ -26,7 +26,7 @@ kube-scheduler를 미세 조정할 수 있다. 통해 사용자는 적절한 파라미터를 사용해서 확장된 리소스를 빈 팩으로 만들 수 있어 대규모의 클러스터에서 부족한 리소스의 활용도가 향상된다. `RequestedToCapacityRatioResourceAllocation` 우선 순위 기능의 -동작은 `requestedToCapacityRatioArguments`라는 +동작은 `RequestedToCapacityRatioArgs`라는 구성 옵션으로 제어할 수 있다. 이 인수는 `shape`와 `resources` 두 개의 파라미터로 구성된다. `shape` 파라미터는 사용자가 `utilization`과 `score` 값을 기반으로 최소 요청 또는 최대 요청된 대로 기능을 @@ -39,27 +39,29 @@ kube-scheduler를 미세 조정할 수 있다. 설정하는 구성의 예시이다. ```yaml -apiVersion: v1 -kind: Policy +apiVersion: kubescheduler.config.k8s.io/v1beta1 +kind: KubeSchedulerConfiguration +profiles: # ... -priorities: - # ... - - name: RequestedToCapacityRatioPriority - weight: 2 - argument: - requestedToCapacityRatioArguments: - shape: - - utilization: 0 - score: 0 - - utilization: 100 - score: 10 - resources: - - name: intel.com/foo - weight: 3 - - name: intel.com/bar - weight: 5 + pluginConfig: + - name: RequestedToCapacityRatio + args: + shape: + - utilization: 0 + score: 10 + - utilization: 100 + score: 0 + resources: + - name: intel.com/foo + weight: 3 + - name: intel.com/bar + weight: 5 ``` +kube-scheduler 플래그 `--config=/path/to/config/file` 을 사용하여 +`KubeSchedulerConfiguration` 파일을 참조하면 구성이 스케줄러에 +전달된다. + **이 기능은 기본적으로 비활성화되어 있다.** ### 우선 순위 기능 튜닝하기 diff --git a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index 03eec40fae..6be3e204c8 100644 --- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -3,7 +3,7 @@ title: 스케줄러 성능 튜닝 content_type: concept -weight: 80 +weight: 100 --- @@ -24,8 +24,6 @@ API 서버에 해당 결정을 통지한다. 본 페이지에서는 상대적으로 큰 규모의 쿠버네티스 클러스터에 대한 성능 튜닝 최적화에 대해 설명한다. - - 큰 규모의 클러스터에서는 스케줄러의 동작을 튜닝하여 응답 시간 @@ -44,8 +42,10 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해 `percentageOfNodesToScore` 를 100 보다 높게 설정해도 kube-scheduler는 마치 100을 설정한 것처럼 작동한다. -값을 변경하려면, kube-scheduler 구성 파일(이 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` -일 수 있다)을 편집한 다음 스케줄러를 재시작 한다. +값을 변경하려면, +[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta1/)을 +편집한 다음 스케줄러를 재시작한다. +대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다. 이를 변경한 후에 다음을 실행해서 @@ -99,7 +99,6 @@ algorithmSource: percentageOfNodesToScore: 50 ``` - ### percentageOfNodesToScore 튜닝 `percentageOfNodesToScore`는 1과 100 사이의 값이어야 하며 @@ -159,3 +158,7 @@ percentageOfNodesToScore: 50 ``` 모든 노드를 검토한 후, 노드 1로 돌아간다. + +## {{% heading "whatsnext" %}} + +* [kube-scheduler 구성 레퍼런스(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 확인 diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md index bab0803b99..c47f5f995b 100644 --- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -1,4 +1,8 @@ --- + + + + title: 테인트(Taints)와 톨러레이션(Tolerations) content_type: concept weight: 40 @@ -206,9 +210,9 @@ tolerations: `Ready` 가 "`False`"로 됨에 해당한다. * `node.kubernetes.io/unreachable`: 노드가 노드 컨트롤러에서 도달할 수 없다. 이는 NodeCondition `Ready` 가 "`Unknown`"로 됨에 해당한다. - * `node.kubernetes.io/out-of-disk`: 노드에 디스크가 부족하다. * `node.kubernetes.io/memory-pressure`: 노드에 메모리 할당 압박이 있다. * `node.kubernetes.io/disk-pressure`: 노드에 디스크 할당 압박이 있다. + * `node.kubernetes.io/pid-pressure`: 노드에 PID 할당 압박이 있다. * `node.kubernetes.io/network-unavailable`: 노드의 네트워크를 사용할 수 없다. * `node.kubernetes.io/unschedulable`: 노드를 스케줄할 수 없다. * `node.cloudprovider.kubernetes.io/uninitialized`: "외부" 클라우드 공급자로 @@ -260,26 +264,39 @@ tolerations: 이렇게 하면 이러한 문제로 인해 데몬셋 파드가 축출되지 않는다. -## 컨디션별 노드 테인트하기 +## 컨디션을 기준으로 노드 테인트하기 -노드 라이프사이클 컨트롤러는 `NoSchedule` 이펙트가 있는 노드 컨디션에 해당하는 -테인트를 자동으로 생성한다. -마찬가지로 스케줄러는 노드 컨디션을 확인하지 않는다. 대신 스케줄러는 테인트를 확인한다. 이렇게 하면 노드 컨디션이 노드에 스케줄된 내용에 영향을 미치지 않는다. 사용자는 적절한 파드 톨러레이션을 추가하여 노드의 일부 문제(노드 컨디션으로 표시)를 무시하도록 선택할 수 있다. +컨트롤 플레인은 노드 {{}}를 이용하여 +[노드 조건](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다. -쿠버네티스 1.8 버전부터 데몬셋 컨트롤러는 다음의 `NoSchedule` 톨러레이션을 +스케줄러는 스케줄링 결정을 내릴 때 노드 조건을 확인하는 것이 아니라 테인트를 확인한다. +이렇게 하면 노드 조건이 스케줄링에 직접적인 영향을 주지 않는다. +예를 들어 `DiskPressure` 노드 조건이 활성화된 경우 +컨트롤 플레인은 `node.kubernetes.io/disk-pressure` 테인트를 추가하고 영향을 받는 노드에 새 파드를 할당하지 않는다. +`MemoryPressure` 노드 조건이 활성화되면 +컨트롤 플레인이 `node.kubernetes.io/memory-pressure` 테인트를 추가한다. + +새로 생성된 파드에 파드 톨러레이션을 추가하여 노드 조건을 무시하도록 할 수 있다. +또한 컨트롤 플레인은 `BestEffort` 이외의 +{{< glossary_tooltip text="QoS 클래스" term_id="qos-class" >}}를 가지는 파드에 +`node.kubernetes.io/memory-pressure` 톨러레이션을 추가한다. +이는 쿠버네티스가 `Guaranteed` 또는 `Burstable` QoS 클래스를 갖는 파드(메모리 요청이 설정되지 않은 파드 포함)를 +마치 그 파드들이 메모리 압박에 대처 가능한 것처럼 다루는 반면, +새로운 `BestEffort` 파드는 영향을 받는 노드에 할당하지 않기 때문이다. + +데몬셋 컨트롤러는 다음의 `NoSchedule` 톨러레이션을 모든 데몬에 자동으로 추가하여, 데몬셋이 중단되는 것을 방지한다. * `node.kubernetes.io/memory-pressure` * `node.kubernetes.io/disk-pressure` - * `node.kubernetes.io/out-of-disk` (*중요한 파드에만 해당*) + * `node.kubernetes.io/pid-pressure` (1.14 이상) * `node.kubernetes.io/unschedulable` (1.10 이상) * `node.kubernetes.io/network-unavailable` (*호스트 네트워크만 해당*) 이러한 톨러레이션을 추가하면 이전 버전과의 호환성이 보장된다. 데몬셋에 임의의 톨러레이션을 추가할 수도 있다. - ## {{% heading "whatsnext" %}} -* [리소스 부족 다루기](/docs/tasks/administer-cluster/out-of-resource/)와 어떻게 구성하는지에 대해 알아보기 -* [파드 우선순위](/ko/docs/concepts/configuration/pod-priority-preemption/)에 대해 알아보기 +* [리소스 부족 다루기](/docs/concepts/scheduling-eviction/node-pressure-eviction/)와 어떻게 구성하는지에 대해 알아보기 +* [파드 우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 알아보기 diff --git a/content/ko/docs/concepts/security/controlling-access.md b/content/ko/docs/concepts/security/controlling-access.md index 3b45be648c..9612159eb4 100644 --- a/content/ko/docs/concepts/security/controlling-access.md +++ b/content/ko/docs/concepts/security/controlling-access.md @@ -38,7 +38,7 @@ API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다. 인증기는 [여기](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다. 인증 단계로 들어가는 것은 온전한 HTTP 요청이지만 -일반적으로 헤더 그리고/또는 클라이언트 인증서만 검사한다. +일반적으로 헤더 그리고/또는 클라이언트 인증서를 검사한다. 인증 모듈은 클라이언트 인증서, 암호 및 일반 토큰, 부트스트랩 토큰, JWT 토큰(서비스 어카운트에 사용됨)을 포함한다. diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index 9cd48a172c..64ed2675b2 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -149,7 +149,7 @@ TLS를 통한 접근 | 코드가 TCP를 통해 통신해야 한다면, 미리 * [파드에 대한 네트워크 정책](/ko/docs/concepts/services-networking/network-policies/) * [쿠버네티스 API 접근 제어하기](/ko/docs/concepts/security/controlling-access) * [클러스터 보안](/docs/tasks/administer-cluster/securing-a-cluster/) -* 컨트롤 플레인을 위한 [전송 데이터 암호화](/docs/tasks/tls/managing-tls-in-a-cluster/) +* 컨트롤 플레인을 위한 [전송 데이터 암호화](/ko/docs/tasks/tls/managing-tls-in-a-cluster/) * [Rest에서 데이터 암호화](/docs/tasks/administer-cluster/encrypt-data/) * [쿠버네티스 시크릿](/ko/docs/concepts/configuration/secret/) * [런타임 클래스](/ko/docs/concepts/containers/runtime-class) diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index 9002778ede..0848c35772 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -383,7 +383,7 @@ $ curl https://: -k

    Welcome to nginx!

    ``` -이제 클라우드 로드 밸런서를 사용하도록 서비스를 재생성하고, `my-nginx` 서비스의 `Type` 을 `NodePort` 에서 `LoadBalancer` 로 변경한다. +이제 클라우드 로드 밸런서를 사용하도록 서비스를 재생성한다. `my-nginx` 서비스의 `Type` 을 `NodePort` 에서 `LoadBalancer` 로 변경한다. ```shell kubectl edit svc my-nginx diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 006ffba99c..b405617118 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -7,6 +7,7 @@ content_type: concept weight: 20 --- + 쿠버네티스는 파드와 서비스를 위한 DNS 레코드를 생성한다. 사용자는 IP 주소 대신에 일관된 DNS 네임을 통해서 서비스에 접속할 수 있다. @@ -49,7 +50,7 @@ options ndots:5 ``` 요약하면, _test_ 네임스페이스에 있는 파드는 `data.prod` 또는 -`data.prod.cluster.local` 중 하나를 통해 성공적으로 해석될 수 있다. +`data.prod.svc.cluster.local` 중 하나를 통해 성공적으로 해석될 수 있다. ### DNS 레코드 @@ -194,7 +195,7 @@ A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespac 또한 서비스에서 `publishNotReadyAddresses=True` 를 설정하지 않았다면, 파드가 준비 상태가 되어야 레코드를 가질 수 있다. {{< /note >}} -### 파드의 setHostnameAsFQDN 필드 {# pod-sethostnameasfqdn-field} +### 파드의 setHostnameAsFQDN 필드 {#pod-sethostnameasfqdn-field} {{< feature-state for_k8s_version="v1.20" state="beta" >}} @@ -261,6 +262,8 @@ spec: ### 파드의 DNS 설정 {#pod-dns-config} +{{< feature-state for_k8s_version="v1.14" state="stable" >}} + 사용자들은 파드의 DNS 설정을 통해서 직접 파드의 DNS를 세팅할 수 있다. `dnsConfig` 필드는 선택적이고, `dnsPolicy` 세팅과 함께 동작한다. @@ -310,18 +313,6 @@ search default.svc.cluster-domain.example svc.cluster-domain.example cluster-dom options ndots:5 ``` -### 기능 지원 여부 - -파드 DNS 구성 및 DNS 정책 "`None`"에 대한 지원 정보는 아래에서 확인 할 수 있다. - -| k8s 버전 | 기능 지원 | -| :---------: |:-----------:| -| 1.14 | 안정 | -| 1.10 | 베타 (기본)| -| 1.9 | 알파 | - - - ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/concepts/services-networking/dual-stack.md b/content/ko/docs/concepts/services-networking/dual-stack.md index dcfb818650..821ca34989 100644 --- a/content/ko/docs/concepts/services-networking/dual-stack.md +++ b/content/ko/docs/concepts/services-networking/dual-stack.md @@ -11,11 +11,11 @@ weight: 70 -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} - IPv4/IPv6 이중 스택을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}} 와 {{< glossary_tooltip text="서비스" term_id="service" >}} 에 IPv4와 IPv6 주소를 모두 할당 할 수 있다. +IPv4/IPv6 이중 스택 네트워킹을 사용하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 {{< glossary_tooltip text="서비스" term_id="service" >}}에 IPv4와 IPv6 주소를 모두 할당할 수 있다. -만약 쿠버네티스 클러스터에서 IPv4/IPv6 이중 스택 네트워킹을 활성화하면, 클러스터는 IPv4와 IPv6 주소의 동시 할당을 지원하게 된다. +IPv4/IPv6 이중 스택 네트워킹은 1.21부터 쿠버네티스 클러스터에 기본적으로 활성화되어 있고, IPv4 및 IPv6 주소를 동시에 할당할 수 있다. @@ -23,7 +23,7 @@ weight: 70 ## 지원되는 기능 -쿠버네티스 클러스터에서 IPv4/IPv6 이중 스택을 활성화하면 다음의 기능을 제공한다. +쿠버네티스 클러스터의 IPv4/IPv6 이중 스택은 다음의 기능을 제공한다. * 이중 스택 파드 네트워킹(파드 당 단일 IPv4와 IPv6 주소 할당) * IPv4와 IPv6 지원 서비스 @@ -40,34 +40,34 @@ IPv4/IPv6 이중 스택 쿠버네티스 클러스터를 활용하려면 다음 * 이중 스택 네트워킹을 위한 공급자의 지원(클라우드 공급자 또는 다른 방식으로 쿠버네티스 노드에 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공할 수 있어야 한다.) * 이중 스택(예: Kubenet 또는 Calico)을 지원하는 네트워크 플러그인 -## IPv4/IPv6 이중 스택 활성화 +## IPv4/IPv6 이중 스택 구성 -IPv4/IPv6 이중 스택을 활성화 하려면, 클러스터의 관련 구성요소에 대해 `IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 를 활성화 하고, 이중 스택 클러스터 네트워크 할당을 설정한다. +IPv4/IPv6 이중 스택을 사용하려면, 클러스터의 관련 구성 요소에 대해 `IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화한다. (1.21부터 IPv4/IPv6 이중 스택이 기본적으로 활성화된다.) + +IPv4/IPv6 이중 스택을 구성하려면, 이중 스택 클러스터 네트워크 할당을 설정한다. * kube-apiserver: - * `--feature-gates="IPv6DualStack=true"` * `--service-cluster-ip-range=,` * kube-controller-manager: - * `--feature-gates="IPv6DualStack=true"` * `--cluster-cidr=,` * `--service-cluster-ip-range=,` * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` IPv4의 기본값은 /24 이고 IPv6의 기본값은 /64 이다. - * kubelet: - * `--feature-gates="IPv6DualStack=true"` * kube-proxy: * `--cluster-cidr=,` - * `--feature-gates="IPv6DualStack=true"` {{< note >}} IPv4 CIDR의 예: `10.244.0.0/16` (자신의 주소 범위를 제공하더라도) IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, 유효한 주소는 아니다 - [RFC 4193](https://tools.ietf.org/html/rfc4193)을 본다.) +1.21부터, IPv4/IPv6 이중 스택은 기본적으로 활성화된다. +필요한 경우 kube-apiserver, kube-controller-manager, kubelet 및 kube-proxy 커맨드 라인에 +`--feature-gates="IPv6DualStack=false"` 를 지정하여 비활성화할 수 있다. {{< /note >}} ## 서비스 -클러스터에 이중 스택이 활성화된 경우 IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 만들 수 있다. +IPv4, IPv6 또는 둘 다를 사용할 수 있는 {{< glossary_tooltip text="서비스" term_id="service" >}}를 생성할 수 있다. 서비스의 주소 계열은 기본적으로 첫 번째 서비스 클러스터 IP 범위의 주소 계열로 설정된다. (`--service-cluster-ip-range` 플래그를 통해 kube-apiserver에 구성) @@ -76,11 +76,9 @@ IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, * `SingleStack`: 단일 스택 서비스. 컨트롤 플레인은 첫 번째로 구성된 서비스 클러스터 IP 범위를 사용하여 서비스에 대한 클러스터 IP를 할당한다. * `PreferDualStack`: - * 클러스터에 이중 스택이 활성화된 경우에만 사용된다. 서비스에 대해 IPv4 및 IPv6 클러스터 IP를 할당한다. - * 클러스터에 이중 스택이 활성화되지 않은 경우, 이 설정은 `SingleStack`과 동일한 동작을 따른다. + * 서비스에 IPv4 및 IPv6 클러스터 IP를 할당한다. (클러스터에 `--feature-gates="IPv6DualStack=false"` 가 있는 경우, 이 설정은 `SingleStack` 과 동일한 동작을 따른다.) * `RequireDualStack`: IPv4 및 IPv6 주소 범위 모두에서 서비스 `.spec.ClusterIPs`를 할당한다. * `.spec.ipFamilies` 배열의 첫 번째 요소의 주소 계열을 기반으로 `.spec.ClusterIPs` 목록에서 `.spec.ClusterIP`를 선택한다. - * 클러스터에는 이중 스택 네트워킹이 구성되어 있어야 한다. 단일 스택에 사용할 IP 계열을 정의하거나 이중 스택에 대한 IP 군의 순서를 정의하려는 경우, 서비스에서 옵션 필드 `.spec.ipFamilies`를 설정하여 주소 군을 선택할 수 있다. @@ -121,7 +119,7 @@ IPv6 CIDR의 예: `fdXY:IJKL:MNOP:15::/64` (이 형식으로 표시되지만, #### 기존 서비스의 이중 스택 기본값 -이 예제는 서비스가 이미있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. +이 예제는 서비스가 이미 있는 클러스터에서 이중 스택이 새로 활성화된 경우의 기본 동작을 보여준다. (`--feature-gates="IPv6DualStack=false"` 가 설정되지 않은 경우 기존 클러스터를 1.21로 업그레이드하면 이중 스택이 활성화된다.) 1. 클러스터에서 이중 스택이 활성화된 경우 기존 서비스 (`IPv4` 또는 `IPv6`)는 컨트롤 플레인이 `.spec.ipFamilyPolicy`를 `SingleStack`으로 지정하고 `.spec.ipFamilies`를 기존 서비스의 주소 계열로 설정한다. 기존 서비스 클러스터 IP는 `.spec.ClusterIPs`에 저장한다. @@ -237,3 +235,5 @@ spec: * [IPv4/IPv6 이중 스택 검증](/ko/docs/tasks/network/validate-dual-stack) 네트워킹 +* [kubeadm을 사용하여 이중 스택 네트워킹 활성화 +](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/) diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index f75dc819c3..4ea1281faa 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -1,13 +1,13 @@ --- title: 엔드포인트슬라이스 content_type: concept -weight: 35 +weight: 45 --- -{{< feature-state for_k8s_version="v1.17" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} _엔드포인트슬라이스_ 는 쿠버네티스 클러스터 내의 네트워크 엔드포인트를 추적하는 간단한 방법을 제공한다. 이것은 엔드포인트를 더 확장하고, 확장 가능한 @@ -50,7 +50,7 @@ term_id="selector" >}}가 지정되면 컨트롤 플레인은 자동으로 리소스 샘플이 있다. ```yaml -apiVersion: discovery.k8s.io/v1beta1 +apiVersion: discovery.k8s.io/v1 kind: EndpointSlice metadata: name: example-abc @@ -67,13 +67,12 @@ endpoints: conditions: ready: true hostname: pod-1 - topology: - kubernetes.io/hostname: node-1 - topology.kubernetes.io/zone: us-west2-a + nodeName: node-1 + zone: us-west2-a ``` 기본적으로, 컨트롤 플레인은 각각 100개 이하의 엔드포인트를 -갖도록 엔드포인트슬라이스를 +갖도록 엔드포인트슬라이스를 생성하고 관리한다. `--max-endpoints-per-slice` {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}} 플래그를 사용하여, 최대 1000개까지 구성할 수 있다. @@ -98,9 +97,9 @@ endpoints: #### 준비 -`ready`는 파드의 `Ready` 조건에 매핑되는 조건이다. `Ready` 조건이 `True`로 설정된 실행 중인 파드는 -이 엔드포인트슬라이스 조건도 `true`로 설정되어야 한다. 호환성의 -이유로, 파드가 종료될 때 `ready`는 절대 `true`가 되면 안 된다. 컨슈머는 `serving` 조건을 참조하여 +`ready`는 파드의 `Ready` 조건에 매핑되는 조건이다. `Ready` 조건이 `True`로 설정된 실행 중인 파드는 +이 엔드포인트슬라이스 조건도 `true`로 설정되어야 한다. 호환성의 +이유로, 파드가 종료될 때 `ready`는 절대 `true`가 되면 안 된다. 컨슈머는 `serving` 조건을 참조하여 파드 종료 준비 상태(readiness)를 검사해야 한다. 이 규칙의 유일한 예외는 `spec.publishNotReadyAddresses`가 `true`로 설정된 서비스이다. 이러한 서비스의 엔드 포인트는 항상 `ready`조건이 `true`로 설정된다. @@ -110,16 +109,16 @@ endpoints: {{< feature-state for_k8s_version="v1.20" state="alpha" >}} `serving`은 종료 상태를 고려하지 않는다는 점을 제외하면 `ready` 조건과 동일하다. -엔드포인트슬라이스 API 컨슈머는 파드가 종료되는 동안 파드 준비 상태에 관심이 있다면 +엔드포인트슬라이스 API 컨슈머는 파드가 종료되는 동안 파드 준비 상태에 관심이 있다면 이 조건을 확인해야 한다. {{< note >}} `serving`은 `ready`와 거의 동일하지만 `ready`의 기존 의미가 깨지는 것을 방지하기 위해 추가되었다. -엔드포인트를 종료하기 위해 `ready`가 `true` 일 수 있다면 기존 클라이언트에게는 예상치 못한 일이 될 수 있다. +엔드포인트를 종료하기 위해 `ready`가 `true` 일 수 있다면 기존 클라이언트에게는 예상치 못한 일이 될 수 있다. 역사적으로 종료된 엔드포인트는 처음부터 엔드포인트 또는 엔드포인트슬라이스 API에 포함되지 않았기 때문이다. -이러한 이유로 `ready`는 엔드포인트 종료를 위해 _always_ `false`이며, -클라이언트가 `ready`에 대한 기존 의미와 관계없이 파드 종료 준비 상태를 +이러한 이유로 `ready`는 엔드포인트 종료를 위해 _always_ `false`이며, +클라이언트가 `ready`에 대한 기존 의미와 관계없이 파드 종료 준비 상태를 추적 할 수 있도록 v1.20에 새로운 조건 `serving`이 추가되었다. {{< /note >}} @@ -133,33 +132,29 @@ endpoints: ### 토폴로지 정보 {#토폴로지} -{{< feature-state for_k8s_version="v1.20" state="deprecated" >}} +엔드포인트슬라이스 내의 각 엔드 포인트는 관련 토폴로지 정보를 포함할 수 있다. +토폴로지 정보에는 엔드 포인트의 위치와 해당 노드 및 +영역에 대한 정보가 포함된다. 엔드포인트슬라이스의 다음의 엔드 포인트별 +필드에서 사용할 수 있다. + +*`nodeName` - 이 엔드 포인트가 있는 노드의 이름이다. +*`zone` - 이 엔드 포인트가 있는 영역이다. {{< note >}} -엔드포인트슬라이스의 토폴로지 필드는 사용 중단되었으며 향후 릴리스에서 제거된다. -토폴로지에서 `kubernetes.io/hostname`을 설정하는 대신 새로운 `nodeName` 필드가 -사용된다. 영역 및 리전을 커버하는 다른 토폴로지 필드는 -엔드포인트슬라이스 내의 모든 엔드포인트에 적용되는 -엔드포인트슬라이스 레이블을 이용해 더 잘 표현될 수 있다. +v1 API에서는, 전용 필드 `nodeName` 및 `zone` 을 위해 엔드 포인트별 +`topology` 가 효과적으로 제거되었다. + +`EndpointSlice` 리소스의 `endpoint` 필드에 임의의 토폴로지 필드를 +설정하는 것은 더 이상 사용되지 않으며, v1 API에서 지원되지 않는다. 대신, +v1 API는 개별 `nodeName` 및 `zone` 필드 설정을 지원한다. 이러한 +필드는 API 버전 간에 자동으로 번역된다. 예를 들어, +v1beta1 API의 `topology` 필드에 있는 `"topology.kubernetes.io/zone"` +키 값은 v1 API의 `zone` 필드로 접근할 수 있다. {{< /note >}} -엔드포인트슬라이스 내 각 엔드포인트는 연관된 토폴로지 정보를 포함할 수 있다. -이는 해당 노드, 영역 그리고 지역에 대한 정보가 포함된 -엔드포인트가 있는 위치를 나타나는데 사용 한다. 값을 사용할 수 있으면, -컨트롤 플레인은 엔드포인트슬라이스에 대해 다음의 토폴로지 레이블을 설정한다. - -* `kubernetes.io/hostname` - 이 엔드포인트가 있는 노드의 이름. -* `topology.kubernetes.io/zone` - 이 엔드포인트가 있는 영역의 이름. -* `topology.kubernetes.io/region` - 이 엔드포인트가 있는 지역의 이름. - -이런 레이블 값은 슬라이스의 각 엔드포인트와 연관된 리소스에서 -파생된다. 호스트 이름 레이블은 해당 파드의 -NodeName 필드 값을 나타낸다. 영역 및 지역 레이블은 해당 -노드에서 이름이 같은 값을 나타낸다. - ### 관리 -대부분의 경우, 컨트롤 플레인(특히, 엔드포인트 슬라이스 +대부분의 경우, 컨트롤 플레인(특히, 엔드포인트슬라이스 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}})는 엔드포인트슬라이스 오브젝트를 생성하고 관리한다. 다른 엔티티나 컨트롤러가 추가 엔드포인트슬라이스 집합을 관리하게 할 수 있는 서비스 메시 구현과 같이 @@ -170,13 +165,13 @@ NodeName 필드 값을 나타낸다. 영역 및 지역 레이블은 해당 엔티티를 나타내는 `endpointslice.kubernetes.io/managed-by` {{< glossary_tooltip term_id="label" text="레이블" >}}을 정의한다. -엔드포인트 슬라이스 컨트롤러는 관리하는 모든 엔드포인트슬라이스에 레이블의 값으로 +엔드포인트슬라이스 컨트롤러는 관리하는 모든 엔드포인트슬라이스에 레이블의 값으로 `endpointslice-controller.k8s.io` 를 설정한다. 엔드포인트슬라이스를 관리하는 다른 엔티티도 이 레이블에 고유한 값을 설정해야 한다. ### 소유권 -대부분의 유스케이스에서, 엔드포인트 슬라이스 오브젝트가 엔드포인트를 +대부분의 유스케이스에서, 엔드포인트슬라이스 오브젝트가 엔드포인트를 추적하는 서비스가 엔드포인트슬라이스를 소유한다. 이 소유권은 각 엔드포인트슬라이스의 소유자 참조와 서비스에 속한 모든 엔드포인트슬라이스의 간단한 조회를 가능하게 하는 `kubernetes.io/service-name` 레이블로 표시된다. @@ -252,5 +247,4 @@ NodeName 필드 값을 나타낸다. 영역 및 지역 레이블은 해당 ## {{% heading "whatsnext" %}} -* [엔드포인트슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices)에 대해 배우기 -* [애플리케이션을 서비스와 함께 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기 +* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기 diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md index ec705e6a7c..802cc486bf 100644 --- a/content/ko/docs/concepts/services-networking/ingress.md +++ b/content/ko/docs/concepts/services-networking/ingress.md @@ -218,7 +218,19 @@ Events: {{< codenew file="service/networking/external-lb.yaml" >}} IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클래스에 대한 -추가 구성을 참조하는데 사용할 수 있다. +추가 구현 별 구성을 참조하는데 사용할 수 있다. + +#### 네임스페이스 범위의 파라미터 + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +`Parameters` 필드에는 인그레스 클래스 구성을 위해 네임스페이스 별 리소스를 참조하는 데 +사용할 수 있는 `scope` 및 `namespace` 필드가 있다. +`Scope` 필드의 기본값은 `Cluster` 이다. 즉, 기본값은 클러스터 범위의 +리소스이다. `Scope` 를 `Namespace` 로 설정하고 `Namespace` 필드를 +설정하면 특정 네임스페이스의 파라미터 리소스를 참조한다. + +{{< codenew file="service/networking/namespaced-params.yaml" >}} ### 사용중단(Deprecated) 어노테이션 @@ -257,7 +269,7 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클 {{< codenew file="service/networking/test-ingress.yaml" >}} -만약 `kubectl apply -f` 를 사용해서 생성한다면 방금 추가한 인그레스의 +만약 `kubectl apply -f` 를 사용해서 생성한다면 추가한 인그레스의 상태를 볼 수 있어야 한다. ```bash diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index d7872b1d92..5a9b16a309 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -212,26 +212,81 @@ __ipBlock__: 인그레스 소스 또는 이그레스 대상으로 허용할 IP C ## SCTP 지원 -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.20" state="stable" >}} -베타 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에 `--feature-gates=SCTPSupport=false,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다. +안정된 기능으로, 기본 활성화되어 있다. 클러스터 수준에서 SCTP를 비활성화하려면, 사용자(또는 클러스터 관리자)가 API 서버에 `--feature-gates=SCTPSupport=false,…` 를 사용해서 `SCTPSupport` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다. +해당 기능 게이트가 활성화되어 있는 경우, 네트워크폴리시의 `protocol` 필드를 `SCTP`로 지정할 수 있다. {{< note >}} SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용하고 있어야 한다. {{< /note >}} +## 포트 범위 지정 + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +네트워크폴리시를 작성할 때, 단일 포트 대신 포트 범위를 대상으로 지정할 수 있다. + +다음 예와 같이 `endPort` 필드를 사용하면, 이 작업을 수행할 수 있다. + +```yaml +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: multi-port-egress + namespace: default +spec: + podSelector: + matchLabels: + role: db + policyTypes: + - Egress + egress: + - to: + - ipBlock: + cidr: 10.0.0.0/24 + ports: + - protocol: TCP + port: 32000 + endPort: 32768 +``` + +위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우, 네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가 TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다. + +이 필드를 사용할 때 다음의 제한 사항이 적용된다. +* 알파 기능으로, 기본적으로 비활성화되어 있다. 클러스터 수준에서 `endPort` 필드를 활성화하려면, 사용자(또는 클러스터 관리자)가 `--feature-gates=NetworkPolicyEndPort=true,…` 가 있는 API 서버에 대해 `NetworkPolicyEndPort` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. +* `endPort` 필드는 `port` 필드보다 크거나 같아야 한다. +* `endPort` 는 `port` 도 정의된 경우에만 정의할 수 있다. +* 두 포트 모두 숫자여야 한다. + +{{< note >}} +클러스터는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용해야 한다. +네트워크폴리시 명세에서 `endPort` 필드를 지원한다. +{{< /note >}} + +## 이름으로 네임스페이스 지정 + +{{< feature-state state="beta" for_k8s_version="1.21" >}} + +쿠버네티스 컨트롤 플레인은 `NamespaceDefaultLabelName` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우 +모든 네임스페이스에 변경할 수 없는(immutable) 레이블 `kubernetes.io/metadata.name` 을 설정한다. +레이블의 값은 네임스페이스 이름이다. + +네트워크폴리시는 일부 오브젝트 필드가 있는 이름으로 네임스페이스를 대상으로 지정할 수 없지만, 표준화된 레이블을 사용하여 +특정 네임스페이스를 대상으로 지정할 수 있다. + ## 네트워크 정책으로 할 수 없는 것(적어도 아직은 할 수 없는) -쿠버네티스 1.20부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 가치가 있다. 이러한 사용자 스토리 중 일부(전부는 아님)가 네트워크폴리시 API의 향후 릴리스에서 활발히 논의되고 있다. +쿠버네티스 {{< skew latestVersion >}}부터 다음의 기능은 네트워크폴리시 API에 존재하지 않지만, 운영 체제 컴포넌트(예: SELinux, OpenVSwitch, IPTables 등) 또는 Layer 7 기술(인그레스 컨트롤러, 서비스 메시 구현) 또는 어드미션 컨트롤러를 사용하여 제2의 해결책을 구현할 수 있다. 쿠버네티스의 네트워크 보안을 처음 사용하는 경우, 네트워크폴리시 API를 사용하여 다음의 사용자 스토리를 (아직) 구현할 수 없다는 점에 유의할 필요가 있다. - 내부 클러스터 트래픽이 공통 게이트웨이를 통과하도록 강제한다(서비스 메시나 기타 프록시와 함께 제공하는 것이 가장 좋을 수 있음). - TLS와 관련된 모든 것(이를 위해 서비스 메시나 인그레스 컨트롤러 사용). - 노드별 정책(이에 대해 CIDR 표기법을 사용할 수 있지만, 특히 쿠버네티스 ID로 노드를 대상으로 지정할 수 없음). -- 이름으로 네임스페이스나 서비스를 타겟팅한다(그러나, {{< glossary_tooltip text="레이블" term_id="label" >}}로 파드나 네임스페이스를 타겟팅할 수 있으며, 이는 종종 실행할 수 있는 해결 방법임). +- 이름으로 서비스를 타겟팅한다(그러나, {{< glossary_tooltip text="레이블" term_id="label" >}}로 파드나 네임스페이스를 타겟팅할 수 있으며, 이는 종종 실행할 수 있는 해결 방법임). - 타사 공급사가 이행한 "정책 요청"의 생성 또는 관리. - 모든 네임스페이스나 파드에 적용되는 기본 정책(이를 수행할 수 있는 타사 공급사의 쿠버네티스 배포본 및 프로젝트가 있음). - 고급 정책 쿼리 및 도달 가능성 도구. -- 단일 정책 선언에서 포트 범위를 대상으로 하는 기능. - 네트워크 보안 이벤트를 기록하는 기능(예: 차단되거나 수락된 연결). - 명시적으로 정책을 거부하는 기능(현재 네트워크폴리시 모델은 기본적으로 거부하며, 허용 규칙을 추가하는 기능만 있음). - 루프백 또는 들어오는 호스트 트래픽을 방지하는 기능(파드는 현재 로컬 호스트 접근을 차단할 수 없으며, 상주 노드의 접근을 차단할 수 있는 기능도 없음). diff --git a/content/ko/docs/concepts/services-networking/service-topology.md b/content/ko/docs/concepts/services-networking/service-topology.md index 567b998791..47799ba9f7 100644 --- a/content/ko/docs/concepts/services-networking/service-topology.md +++ b/content/ko/docs/concepts/services-networking/service-topology.md @@ -1,10 +1,8 @@ --- -title: 서비스 토폴로지 -feature: - title: 서비스 토폴로지 - description: > - 클러스터 토폴로지를 기반으로 서비스 트래픽 라우팅. + + +title: 토폴로지 키를 사용하여 토폴로지-인지 트래픽 라우팅 content_type: concept weight: 10 --- @@ -12,7 +10,16 @@ weight: 10 -{{< feature-state for_k8s_version="v1.17" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} + +{{< note >}} + +이 기능, 특히 알파 `topologyKeys` API는 쿠버네티스 v1.21부터 +더 이상 사용되지 않는다. +쿠버네티스 v1.21에 도입된 [토폴로지 인지 힌트](/docs/concepts/services-networking/topology-aware-hints/)는 +유사한 기능을 제공한다. + +{{}} _서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노드 토폴로지를 기반으로 트래픽을 라우팅한다. 예를 들어, 서비스는 트래픽을 @@ -20,33 +27,33 @@ _서비스 토폴로지_ 를 활성화 하면 서비스는 클러스터의 노 우선적으로 라우팅되도록 지정할 수 있다. - ## 소개 기본적으로 `ClusterIP` 또는 `NodePort` 서비스로 전송된 트래픽은 서비스의 -모든 백엔드 주소로 라우팅 될 수 있다. 쿠버네티스 1.7부터는 "외부(external)" -트래픽을 수신한 노드에서 실행중인 파드로 라우팅할 수 있었지만, -`ClusterIP` 서비스에서는 지원되지 않으며 더 복잡한 -토폴로지 — 영역별 라우팅과 같은 — 에서는 불가능 했다. -_서비스 토폴로지_ 기능은 서비스 생성자가 발신 노드와 수신 노드에 대해서 -노드 레이블에 기반한 트래픽 라우팅 정책을 정의할 수 있도록 -함으로써 이 문제를 해결한다. +모든 백엔드 주소로 라우팅될 수 있다. 쿠버네티스 1.7을 사용하면 트래픽을 수신한 +동일한 노드에서 실행 중인 파드로 "외부(external)" 트래픽을 라우팅할 수 +있다. `ClusterIP` 서비스의 경우, 라우팅에 대한 동일한 노드 기본 설정이 +불가능했다. 또한 동일한 영역 내의 엔드 포인트에 대한 라우팅을 선호하도록 +클러스터를 구성할 수도 없다. +서비스에 `topologyKeys` 를 설정하면, 출발 및 대상 노드에 대한 +노드 레이블을 기반으로 트래픽을 라우팅하는 정책을 정의할 수 있다. -소스와 목적지의 노드 레이블 일치를 사용하여 운영자는 운영자의 요구 사항에 -적합한 메트릭에 대해서 서로 "근접(closer)" 하거나 "먼(farther)" -노드 그룹을 지정할 수 있다. 공용 클라우드의 많은 운영자들이 서비스 트래픽을 -동일한 영역에서 유지하는 것을 선호하는 것을 필요성의 예제로 볼 수 있다. 그 이유는 -지역간의 트래픽에는 관련 비용이 발생하지만 지역 내의 트래픽은 발생하지 않기 때문이다. -다른 일반적인 필요성으로는 DaemonSet이 관리하는 로컬 파드로 -트래픽을 라우팅 하거나, 대기시간을 최소화하기 위해 동일한 랙 상단(top-of-rack) 스위치에 -연결된 노드로 트래픽을 유지하는 것이 있다. +소스와 목적지 사이의 레이블 일치를 통해 클러스터 운영자는 +서로 "근접(closer)"하거나 "먼(father)" 노드 그룹을 지정할 수 있다. +자신의 요구 사항에 맞는 메트릭을 나타내는 레이블을 정의할 수 있다. +예를 들어, 퍼블릭 클라우드에서는 지역 간의 트래픽에는 관련 비용이 발생(지역 내 +트래픽은 일반적으로 그렇지 않다)하기 때문에, 네트워크 트래픽을 동일한 지역 내에 유지하는 것을 +선호할 수 있다. 다른 일반적인 필요성으로는 데몬셋(DaemonSet)이 관리하는 +로컬 파드로 트래픽을 라우팅하거나, 대기 시간을 최소화하기 위해 +동일한 랙 상단(top-of-rack) 스위치에 연결된 노드로 트래픽을 +유지하는 것이 있다. ## 서비스 토폴로지 사용하기 -만약 클러스터에서 서비스 토폴로지가 활성화된 경우, 서비스 사양에서 +만약 클러스터에서 `ServiceTopology` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우, 서비스 사양에서 `topologyKeys` 필드를 지정해서 서비스 트래픽 라우팅을 제어할 수 있다. 이 필드는 이 서비스에 접근할 때 엔드포인트를 정렬하는데 사용되는 노드 레이블의 우선 순위 목록이다. 트래픽은 첫 번째 레이블 값이 해당 레이블의 @@ -196,5 +203,3 @@ spec: * [서비스 토폴로지 활성화하기](/docs/tasks/administer-cluster/enabling-service-topology)를 읽어보기. * [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 읽어보기. - - diff --git a/content/ko/docs/concepts/services-networking/service-traffic-policy.md b/content/ko/docs/concepts/services-networking/service-traffic-policy.md new file mode 100644 index 0000000000..c4f87e2b3e --- /dev/null +++ b/content/ko/docs/concepts/services-networking/service-traffic-policy.md @@ -0,0 +1,73 @@ +--- + + +title: 서비스 내부 트래픽 정책 +content_type: concept +weight: 45 +--- + + + + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +_서비스 내부 트래픽 정책_ 을 사용하면 내부 트래픽 제한이 트래픽이 시작된 +노드 내의 엔드포인트로만 내부 트래픽을 라우팅하도록 한다. +여기서 "내부" 트래픽은 현재 클러스터의 파드로부터 시작된 트래픽을 지칭한다. +이를 통해 비용을 절감하고 성능을 개선할 수 있다. + + + +## 서비스 내부 트래픽 정책 사용 + + +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에서 +`ServiceInternalTrafficPolicy`를 활성화한 후에 +{{< glossary_tooltip text="서비스" term_id="service" >}}의 +`.spec.internalTrafficPolicy`를 `Local`로 설정하여 내부 전용 트래픽 정책을 활성화 할 수 있다. +이것은 kube-proxy가 클러스터 내부 트래픽을 위해 노드 내부 엔드포인트로만 사용하도록 한다. + +{{< note >}} +지정된 서비스에 대한 엔드포인트가 없는 노드의 파드인 경우에 +서비스는 다른 노드에 엔드포인트가 있더라도 엔드포인트가 없는 것처럼 작동한다. +(이 노드의 파드에 대해서) +{{< /note >}} + +다음 예제는 서비스의 `.spec.internalTrafficPolicy`를 `Local`로 +설정하는 것을 보여 준다: + +```yaml +apiVersion: v1 +kind: Service +metadata: + name: my-service +spec: + selector: + app: MyApp + ports: + - protocol: TCP + port: 80 + targetPort: 9376 + internalTrafficPolicy: Local +``` + +## 작동 방식 + +kube-proxy는 `spec.internalTrafficPolicy` 의 설정에 따라서 라우팅되는 +엔드포인트를 필터링한다. +이것을 `Local`로 설정하면, 노드 내부 엔드포인트만 고려한다. +이 설정이 `Cluster`이거나 누락되었다면 모든 엔드포인트를 고려한다. +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의 +`ServiceInternalTrafficPolicy`를 활성화한다면, `spec.internalTrafficPolicy`는 기본값 "Cluster"로 설정된다. + +## 제약조건 + +* 같은 서비스에서 `externalTrafficPolicy` 가 `Local`로 설정된 경우 +서비스 내부 트래픽 정책이 사용되지 않는다. +클러스터에서 동일하지 않은 다른 서비스에서 이 두 가지 기능은 동시에 사용할 수 있다. + +## {{% heading "whatsnext" %}} + +* [토폴로지 인식 힌트 활성화](/docs/tasks/administer-cluster/enabling-topology-aware-hints)에 대해서 읽기 +* [서비스 외부 트래픽 정책](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)에 대해서 읽기 +* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/) 읽기 diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index b01a971cff..5c4b9edeee 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -187,9 +187,14 @@ ExternalName 서비스는 셀렉터가 없고 DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내용은 이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다. +### 초과 용량 엔드포인트 +엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.21(또는 그 이상) +클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: warning` 어노테이션을 추가한다. +이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했음을 나타낸다. + ### 엔드포인트슬라이스 -{{< feature-state for_k8s_version="v1.17" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} 엔드포인트슬라이스는 엔드포인트에 보다 확장 가능한 대안을 제공할 수 있는 API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만, 엔드포인트슬라이스를 @@ -210,7 +215,7 @@ API 리소스이다. 개념적으로 엔드포인트와 매우 유사하지만, 오브젝트에 의해 미러링된다. 이 필드는 표준 쿠버네티스 레이블 구문을 따른다. 값은 -[IANA 표준 서비스 이름](http://www.iana.org/assignments/service-names) 또는 +[IANA 표준 서비스 이름](https://www.iana.org/assignments/service-names) 또는 `mycompany.com/my-custom-protocol`과 같은 도메인 접두사 이름 중 하나여야 한다. ## 가상 IP와 서비스 프록시 @@ -513,8 +518,12 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하 각 노드는 해당 포트 (모든 노드에서 동일한 포트 번호)를 서비스로 프록시한다. 서비스는 할당된 포트를 `.spec.ports[*].nodePort` 필드에 나타낸다. -포트를 프록시하기 위해 특정 IP를 지정하려면 kube-proxy의 `--nodeport-addresses` 플래그를 특정 IP 블록으로 설정할 수 있다. 이것은 쿠버네티스 v1.10부터 지원된다. -이 플래그는 쉼표로 구분된 IP 블록 목록 (예: 10.0.0.0/8, 192.0.2.0/25)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다. +포트를 프록시하기 위해 특정 IP를 지정하려면, kube-proxy에 대한 +`--nodeport-addresses` 플래그 또는 +[kube-proxy 구성 파일](/docs/reference/config-api/kube-proxy-config.v1alpha1/)의 +동등한 `nodePortAddresses` 필드를 +특정 IP 블록으로 설정할 수 있다. +이 플래그는 쉼표로 구분된 IP 블록 목록(예: `10.0.0.0/8`, `192.0.2.0/25`)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다. 예를 들어, `--nodeport-addresses=127.0.0.0/8` 플래그로 kube-proxy를 시작하면, kube-proxy는 NodePort 서비스에 대하여 루프백(loopback) 인터페이스만 선택한다. `--nodeport-addresses`의 기본 값은 비어있는 목록이다. 이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다. (이는 이전 쿠버네티스 릴리스와도 호환된다). @@ -530,7 +539,9 @@ NodePort를 사용하면 자유롭게 자체 로드 밸런싱 솔루션을 설 하나 이상의 노드 IP를 직접 노출시킬 수 있다. 이 서비스는 `:spec.ports[*].nodePort`와 -`.spec.clusterIP:spec.ports[*].port`로 표기된다. (kube-proxy에서 `--nodeport-addresses` 플래그가 설정되면, 는 NodeIP를 필터링한다.) +`.spec.clusterIP:spec.ports[*].port`로 표기된다. +kube-proxy에 대한 `--nodeport-addresses` 플래그 또는 kube-proxy 구성 파일의 +동등한 필드가 설정된 경우, `` 는 노드 IP를 필터링한다. 예를 들면 @@ -628,6 +639,25 @@ v1.20부터는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정 이러한 노드 포트를 할당 해제하려면 모든 서비스 포트에서 `nodePorts` 항목을 명시적으로 제거해야 한다. 이 필드를 사용하려면 `ServiceLBNodePortControl` 기능 게이트를 활성화해야 한다. +#### 로드 밸런서 구현 클래스 지정 {#load-balancer-class} + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +v1.21부터는, `spec.loadBalancerClass` 필드를 설정하여 `LoadBalancer` 서비스 유형에 +대한 로드 밸런서 구현 클래스를 선택적으로 지정할 수 있다. +기본적으로, `spec.loadBalancerClass` 는 `nil` 이고 `LoadBalancer` 유형의 서비스는 +클라우드 공급자의 기본 로드 밸런서 구현을 사용한다. +`spec.loadBalancerClass` 가 지정되면, 지정된 클래스와 일치하는 로드 밸런서 +구현이 서비스를 감시하고 있다고 가정한다. +모든 기본 로드 밸런서 구현(예: 클라우드 공급자가 제공하는 +로드 밸런서 구현)은 이 필드가 설정된 서비스를 무시한다. +`spec.loadBalancerClass` 는 `LoadBalancer` 유형의 서비스에서만 설정할 수 있다. +한 번 설정하면 변경할 수 없다. +`spec.loadBalancerClass` 의 값은 "`internal-vip`" 또는 +"`example.com/internal-vip`" 와 같은 선택적 접두사가 있는 레이블 스타일 식별자여야 한다. +접두사가 없는 이름은 최종 사용자를 위해 예약되어 있다. +이 필드를 사용하려면 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 한다. + #### 내부 로드 밸런서 혼재된 환경에서는 서비스의 트래픽을 동일한 (가상) 네트워크 주소 블록 내로 @@ -785,8 +815,7 @@ TCP 및 SSL은 4 계층 프록시를 선택한다. ELB는 헤더를 수정하지 ``` 위의 예에서, 서비스에 `80`, `443`, `8443`의 3개 포트가 포함된 경우, -`443`, `8443`은 SSL 인증서를 사용하지만, `80`은 단순히 -프록시만 하는 HTTP이다. +`443`, `8443`은 SSL 인증서를 사용하지만, `80`은 프록시하는 HTTP이다. 쿠버네티스 v1.9부터는 서비스에 대한 HTTPS 또는 SSL 리스너와 함께 [사전에 정의된 AWS SSL 정책](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html)을 사용할 수 있다. 사용 가능한 정책을 확인하려면, `aws` 커맨드라인 툴을 사용한다. @@ -906,11 +935,18 @@ Classic ELB의 연결 드레이닝은 # 값 보다 작아야한다. 기본값은 5이며, 2와 60 사이여야 한다. service.beta.kubernetes.io/aws-load-balancer-security-groups: "sg-53fae93f" - # 생성된 ELB에 추가할 기존 보안 그룹 목록. - # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 어노테이션과 달리, 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체한다. + # 생성된 ELB에 설정할 기존 보안 그룹(security group) 목록. + # service.beta.kubernetes.io/aws-load-balancer-extra-security-groups 어노테이션과 달리, 이는 이전에 ELB에 할당된 다른 모든 보안 그룹을 대체하며, + # '해당 ELB를 위한 고유 보안 그룹 생성'을 오버라이드한다. + # 목록의 첫 번째 보안 그룹 ID는 인바운드 트래픽(서비스 트래픽과 헬스 체크)이 워커 노드로 향하도록 하는 규칙으로 사용된다. + # 여러 ELB가 하나의 보안 그룹 ID와 연결되면, 1줄의 허가 규칙만이 워커 노드 보안 그룹에 추가된다. + # 즉, 만약 여러 ELB 중 하나를 지우면, 1줄의 허가 규칙이 삭제되어, 같은 보안 그룹 ID와 연결된 모든 ELB에 대한 접속이 막힌다. + # 적절하게 사용되지 않으면 이는 다수의 서비스가 중단되는 상황을 유발할 수 있다. service.beta.kubernetes.io/aws-load-balancer-extra-security-groups: "sg-53fae93f,sg-42efd82e" - # ELB에 추가될 추가 보안 그룹(security group) 목록 + # 생성된 ELB에 추가할 추가 보안 그룹 목록 + # 이 방법을 사용하면 이전에 생성된 고유 보안 그룹이 그대로 유지되므로, 각 ELB가 고유 보안 그룹 ID와 그에 매칭되는 허가 규칙 라인을 소유하여 + # 트래픽(서비스 트래픽과 헬스 체크)이 워커 노드로 향할 수 있도록 한다. 여기에 기재되는 보안 그룹은 여러 서비스 간 공유될 수 있다. service.beta.kubernetes.io/aws-load-balancer-target-node-labels: "ingress-gw,gw-name=public-api" # 로드 밸런서의 대상 노드를 선택하는 데 @@ -958,7 +994,7 @@ NLB는 특정 인스턴스 클래스에서만 작동한다. 지원되는 인스 | 규칙 | 프로토콜 | 포트 | IP 범위 | IP 범위 설명 | |------|----------|---------|------------|---------------------| -| 헬스 체크 | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | VPC CIDR | kubernetes.io/rule/nlb/health=\ | +| 헬스 체크 | TCP | NodePort(s) (`.spec.healthCheckNodePort` for `.spec.externalTrafficPolicy = Local`) | Subnet CIDR | kubernetes.io/rule/nlb/health=\ | | 클라이언트 트래픽 | TCP | NodePort(s) | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/client=\ | | MTU 탐색 | ICMP | 3,4 | `.spec.loadBalancerSourceRanges` (defaults to `0.0.0.0/0`) | kubernetes.io/rule/nlb/mtu=\ | diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md index 05997eb0f3..c70b7413ad 100644 --- a/content/ko/docs/concepts/storage/persistent-volumes.md +++ b/content/ko/docs/concepts/storage/persistent-volumes.md @@ -29,7 +29,7 @@ _퍼시스턴트볼륨_ (PV)은 관리자가 프로비저닝하거나 [스토리 _퍼시스턴트볼륨클레임_ (PVC)은 사용자의 스토리지에 대한 요청이다. 파드와 비슷하다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용한다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있다. 클레임은 특정 크기 및 접근 모드를 요청할 수 있다(예: ReadWriteOnce, ReadOnlyMany 또는 ReadWriteMany로 마운트 할 수 있음. [AccessModes](#접근-모드) 참고). -퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 단순히 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다. +퍼시스턴트볼륨클레임을 사용하면 사용자가 추상화된 스토리지 리소스를 사용할 수 있지만, 다른 문제들 때문에 성능과 같은 다양한 속성을 가진 퍼시스턴트볼륨이 필요한 경우가 일반적이다. 클러스터 관리자는 사용자에게 해당 볼륨의 구현 방법에 대한 세부 정보를 제공하지 않고 크기와 접근 모드와는 다른 방식으로 다양한 퍼시스턴트볼륨을 제공할 수 있어야 한다. 이러한 요구에는 _스토리지클래스_ 리소스가 있다. [실습 예제와 함께 상세한 내용](/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)을 참고하길 바란다. @@ -540,11 +540,11 @@ spec: ### 접근 모드 -클레임은 특정 접근 모드로 저장소를 요청할 때 볼륨과 동일한 규칙을 사용한다. +클레임은 특정 접근 모드로 저장소를 요청할 때 [볼륨과 동일한 규칙](#접근-모드)을 사용한다. ### 볼륨 모드 -클레임은 볼륨과 동일한 규칙을 사용하여 파일시스템 또는 블록 장치로 볼륨을 사용함을 나타낸다. +클레임은 [볼륨과 동일한 규칙](#볼륨-모드)을 사용하여 파일시스템 또는 블록 장치로 볼륨을 사용함을 나타낸다. ### 리소스 diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md index 94577ca182..f4385419f1 100644 --- a/content/ko/docs/concepts/storage/storage-classes.md +++ b/content/ko/docs/concepts/storage/storage-classes.md @@ -1,4 +1,9 @@ --- + + + + + title: 스토리지 클래스 content_type: concept weight: 30 @@ -149,9 +154,9 @@ CSI | 1.14 (alpha), 1.16 (beta) ### 볼륨 바인딩 모드 `volumeBindingMode` 필드는 [볼륨 바인딩과 동적 -프로비저닝](/ko/docs/concepts/storage/persistent-volumes/#프로비저닝)의 시작 시기를 제어한다. +프로비저닝](/ko/docs/concepts/storage/persistent-volumes/#프로비저닝)의 시작 시기를 제어한다. 설정되어 있지 않으면, `Immediate` 모드가 기본으로 사용된다. -기본적으로, `Immediate` 모드는 퍼시스턴트볼륨클레임이 생성되면 볼륨 +`Immediate` 모드는 퍼시스턴트볼륨클레임이 생성되면 볼륨 바인딩과 동적 프로비저닝이 즉시 발생하는 것을 나타낸다. 토폴로지 제약이 있고 클러스터의 모든 노드에서 전역적으로 접근할 수 없는 스토리지 백엔드의 경우, 파드의 스케줄링 요구 사항에 대한 지식 없이 퍼시스턴트볼륨이 @@ -183,6 +188,36 @@ CSI | 1.14 (alpha), 1.16 (beta) 사전에 생성된 PV에서도 지원되지만, 지원되는 토폴로지 키와 예시를 보려면 해당 CSI 드라이버에 대한 문서를 본다. +{{< note >}} + `WaitForFirstConsumer`를 사용한다면, 노드 어피니티를 지정하기 위해서 파드 스펙에 `nodeName`을 사용하지는 않아야 한다. + 만약 `nodeName`을 사용한다면, 스케줄러가 바이패스되고 PVC가 `pending` 상태로 있을 것이다. + + 대신, 아래와 같이 호스트네임을 이용하는 노드셀렉터를 사용할 수 있다. +{{< /note >}} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: task-pv-pod +spec: + nodeSelector: + kubernetes.io/hostname: kube-01 + volumes: + - name: task-pv-storage + persistentVolumeClaim: + claimName: task-pv-claim + containers: + - name: task-pv-container + image: nginx + ports: + - containerPort: 80 + name: "http-server" + volumeMounts: + - mountPath: "/usr/share/nginx/html" + name: task-pv-storage +``` + ### 허용된 토폴로지 클러스터 운영자가 `WaitForFirstConsumer` 볼륨 바인딩 모드를 지정하면, 대부분의 상황에서 @@ -623,11 +658,11 @@ metadata: provisioner: kubernetes.io/azure-disk parameters: storageaccounttype: Standard_LRS - kind: Shared + kind: managed ``` * `storageaccounttype`: Azure 스토리지 계정 Sku 계층. 기본값은 없음. -* `kind`: 가능한 값은 `shared` (기본값), `dedicated`, 그리고 `managed` 이다. +* `kind`: 가능한 값은 `shared`, `dedicated`, 그리고 `managed` (기본값) 이다. `kind` 가 `shared` 인 경우, 모든 비관리 디스크는 클러스터와 동일한 리소스 그룹에 있는 몇 개의 공유 스토리지 계정에 생성된다. `kind` 가 `dedicated` 인 경우, 클러스터와 동일한 리소스 그룹에서 새로운 diff --git a/content/ko/docs/concepts/storage/volume-health-monitoring.md b/content/ko/docs/concepts/storage/volume-health-monitoring.md new file mode 100644 index 0000000000..ce149165da --- /dev/null +++ b/content/ko/docs/concepts/storage/volume-health-monitoring.md @@ -0,0 +1,30 @@ +--- +title: 볼륨 헬스 모니터링 +content_type: concept +--- + + + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +{{< glossary_tooltip text="CSI" term_id="csi" >}} 볼륨 헬스 모니터링을 통해 CSI 드라이버는 기본 스토리지 시스템에서 비정상적인 볼륨 상태를 감지하고 이를 {{< glossary_tooltip text="PVC" term_id="persistent-volume-claim" >}} 또는 {{< glossary_tooltip text="파드" term_id="pod" >}}의 이벤트로 보고한다. + + + +## 볼륨 헬스 모니터링 + +쿠버네티스 _볼륨 헬스 모니터링_ 은 쿠버네티스가 CSI(Container Storage Interface)를 구현하는 방법의 일부다. 볼륨 헬스 모니터링 기능은 외부 헬스 모니터 컨트롤러와 {{< glossary_tooltip term_id="kubelet" text="kubelet" >}}, 2가지 컴포넌트로 구현된다. + +CSI 드라이버가 컨트롤러 측의 볼륨 헬스 모니터링 기능을 지원하는 경우, CSI 볼륨에서 비정상적인 볼륨 상태가 감지될 때 관련 {{< glossary_tooltip text="퍼시스턴트볼륨클레임" term_id="persistent-volume-claim" >}}(PersistentVolumeClaim, PVC) 이벤트가 보고된다. + +외부 헬스 모니터 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 노드 장애 이벤트도 감시한다. `enable-node-watcher` 플래그를 true로 설정하여 노드 장애 모니터링을 활성화할 수 있다. 외부 헬스 모니터가 노드 장애 이벤트를 감지하면, 컨트롤러는 이 PVC를 사용하는 파드가 장애 상태인 노드에 있음을 나타내는 이벤트가 PVC에 보고된다고 알린다. + +CSI 드라이버가 노드 측에서 볼륨 헬스 모니터링 기능을 지원하는 경우, CSI 볼륨에서 비정상적인 볼륨 상태가 감지되면 PVC를 사용하는 모든 파드에서 이벤트가 보고된다. + +{{< note >}} +노드 측에서 이 기능을 사용하려면 `CSIVolumeHealth` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. +{{< /note >}} + +## {{% heading "whatsnext" %}} + +이 기능을 구현한 CSI 드라이버를 확인하려면 [CSI 드라이버 문서](https://kubernetes-csi.github.io/docs/drivers.html)를 참고한다. diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md index 5323182966..29f4755172 100644 --- a/content/ko/docs/concepts/storage/volumes.md +++ b/content/ko/docs/concepts/storage/volumes.md @@ -1,4 +1,9 @@ --- + + + + + title: 볼륨 content_type: concept weight: 10 @@ -13,7 +18,6 @@ weight: 10 파일을 공유할 때 발생한다. 쿠버네티스 {{< glossary_tooltip text="볼륨" term_id="volume" >}} 추상화는 이러한 문제를 모두 해결한다. - [파드](/ko/docs/concepts/workloads/pods/)에 대해 익숙해지는 것을 추천한다. @@ -29,19 +33,17 @@ weight: 10 쿠버네티스는 다양한 유형의 볼륨을 지원한다. {{< glossary_tooltip term_id="pod" text="파드" >}}는 여러 볼륨 유형을 동시에 사용할 수 있다. 임시 볼륨 유형은 파드의 수명을 갖지만, 퍼시스턴트 볼륨은 -파드의 수명을 넘어 존재한다. 결과적으로, 볼륨은 파드 내에서 -실행되는 모든 컨테이너보다 오래 지속되며, 컨테이너를 다시 시작해도 데이터가 보존된다. 파드가 -더 이상 존재하지 않으면, 쿠버네티스는 임시(ephemeral) 볼륨을 삭제하지만, +파드의 수명을 넘어 존재한다. 파드가 더 이상 존재하지 않으면, 쿠버네티스는 임시(ephemeral) 볼륨을 삭제하지만, 퍼시스턴트(persistent) 볼륨은 삭제하지 않는다. +볼륨의 종류와 상관없이, 파드 내의 컨테이너가 재시작되어도 데이터는 보존된다. -기본적으로 볼륨은 디렉터리일 뿐이며, 일부 데이터가 있을 수 있으며, 파드 +기본적으로 볼륨은 디렉터리이며, 일부 데이터가 있을 수 있으며, 파드 내 컨테이너에서 접근할 수 있다. 디렉터리의 생성 방식, 이를 지원하는 매체와 내용은 사용된 특정 볼륨의 유형에 따라 결정된다. 볼륨을 사용하려면, `.spec.volumes` 에서 파드에 제공할 볼륨을 지정하고 `.spec.containers[*].volumeMounts` 의 컨테이너에 해당 볼륨을 마운트할 위치를 선언한다. - 컨테이너의 프로세스는 도커 이미지와 볼륨으로 구성된 파일시스템 뷰를 본다. [도커 이미지](https://docs.docker.com/userguide/dockerimages/)는 파일시스템 계층의 루트에 있다. 볼륨은 이미지 내에 지정된 경로에 @@ -118,6 +120,7 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}} 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 `awsElasticBlockStore` 스토리지 @@ -149,14 +152,16 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} `azureFile` 의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서 `file.csi.azure.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [Azure 파일 CSI 드라이버](https://github.com/kubernetes-sigs/azurefile-csi-driver) 를 설치하고 `CSIMigration` 과 `CSIMigrationAzureFile` -알파 기능을 활성화해야 한다. +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다. + +Azure File CSI 드라이버는 동일한 볼륨을 다른 fsgroup에서 사용하는 것을 지원하지 않는다. Azurefile CSI 마이그레이션이 활성화된 경우, 다른 fsgroup에서 동일한 볼륨을 사용하는 것은 전혀 지원되지 않는다. ### cephfs @@ -205,14 +210,17 @@ spec: #### 오픈스택 CSI 마이그레이션 -{{< feature-state for_k8s_version="v1.18" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} -Cinder의 `CSIMigration` 기능이 활성화된 경우, 기존 트리 내 플러그인에서 -`cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI) -드라이버로 모든 플러그인 작업을 수행한다. 이 기능을 사용하려면, 클러스터에 [오픈스택 Cinder CSI -드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)를 -설치하고 `CSIMigration` 과 `CSIMigrationOpenStack` -베타 기능을 활성화해야 한다. +Cinder의`CSIMigration` 기능은 Kubernetes 1.21에서 기본적으로 활성화됩니다. +기존 트리 내 플러그인에서 `cinder.csi.openstack.org` 컨테이너 스토리지 인터페이스(CSI) +드라이버로 모든 플러그인 작업을 수행한다. +[오픈스택 Cinder CSI 드라이버](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)가 +클러스터에 설치되어 있어야 한다. +`CSIMigrationOpenStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 +`false` 로 설정하여 클러스터에 대한 Cinder CSI 마이그레이션을 비활성화할 수 있다. +`CSIMigrationOpenStack` 기능을 비활성화하면, 트리 내 Cinder 볼륨 플러그인이 +Cinder 볼륨 스토리지 관리의 모든 측면을 담당한다. ### 컨피그맵(configMap) {#configmap} @@ -253,6 +261,9 @@ spec: `path` 에서 파생된다. {{< note >}} +* [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)을 사용하기 위해서는 + 먼저 컨피그맵을 생성해야 한다. + * 컨피그맵을 [`subPath`](#subpath-사용하기) 볼륨 마운트로 사용하는 컨테이너는 컨피그맵 업데이트를 수신하지 않는다. @@ -518,6 +529,15 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데 ### hostPath {#hostpath} +{{< warning >}} +HostPath 볼륨에는 많은 보안 위험이 있으며, 가능하면 HostPath를 사용하지 않는 +것이 좋다. HostPath 볼륨을 사용해야 하는 경우, 필요한 파일 또는 디렉터리로만 +범위를 지정하고 ReadOnly로 마운트해야 한다. + +AdmissionPolicy를 사용하여 특정 디렉터리로의 HostPath 액세스를 제한하는 경우, +`readOnly` 마운트를 사용하는 정책이 유효하려면 `volumeMounts` 가 반드시 지정되어야 한다. +{{< /warning >}} + `hostPath` 볼륨은 호스트 노드의 파일시스템에 있는 파일이나 디렉터리를 파드에 마운트 한다. 이것은 대부분의 파드들이 필요한 것은 아니지만, 일부 애플리케이션에 강력한 탈출구를 제공한다. @@ -534,13 +554,12 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데 필드가 `type` 에 지원되는 값은 다음과 같다. - | 값 | 행동 | |:------|:---------| | | 빈 문자열 (기본값)은 이전 버전과의 호환성을 위한 것으로, hostPath 볼륨은 마운트 하기 전에 아무런 검사도 수행되지 않는다. | | `DirectoryOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0755로 설정한 빈 디렉터리를 생성한다. | | `Directory` | 주어진 경로에 디렉터리가 있어야 함 | -| `FileOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0644로 설정한 빈 디렉터리를 생성한다. | +| `FileOrCreate` | 만약 주어진 경로에 아무것도 없다면, 필요에 따라 Kubelet이 가지고 있는 동일한 그룹과 소유권, 권한을 0644로 설정한 빈 파일을 생성한다. | | `File` | 주어진 경로에 파일이 있어야 함 | | `Socket` | 주어진 경로에 UNIX 소캣이 있어야 함 | | `CharDevice` | 주어진 경로에 문자 디바이스가 있어야 함 | @@ -548,6 +567,9 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데 다음과 같은 이유로 이 유형의 볼륨 사용시 주의해야 한다. +* HostPath는 권한있는 시스템 자격 증명 (예 : Kubelet 용) 또는 권한있는 API + (예 : 컨테이너 런타임 소켓)를 노출 할 수 있으며, 이는 컨테이너 이스케이프 또는 + 클러스터의 다른 부분을 공격하는 데 사용될 수 있다. * 동일한 구성(파드템플릿으로 생성한 것과 같은)을 가진 파드는 노드에 있는 파일이 다르기 때문에 노드마다 다르게 동작할 수 있다. * 기본 호스트에 생성된 파일 또는 디렉터리는 root만 쓸 수 있다. @@ -905,12 +927,13 @@ API 서버에 대해 `--service-account-max-token-expiration` 옵션을 지정 상대 경로를 지정한다. {{< note >}} -projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 해당 볼륨 소스의 업데이트를 수신하지 않는다. +projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마운트해서 사용하는 컨테이너는 +해당 볼륨 소스의 업데이트를 수신하지 않는다. {{< /note >}} ### quobyte -`quobyte` 볼륨을 사용하면 기존 [Quobyte](http://www.quobyte.com) 볼륨을 +`quobyte` 볼륨을 사용하면 기존 [Quobyte](https://www.quobyte.com) 볼륨을 파드에 마운트할 수 있다. {{< note >}} @@ -1099,7 +1122,6 @@ vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk {{< /tabs >}} - #### vSphere VMDK 구성 예시 {#vsphere-vmdk-configuration} ```yaml @@ -1129,8 +1151,7 @@ spec: {{< feature-state for_k8s_version="v1.19" state="beta" >}} `vsphereVolume` 용 `CSIMigration` 기능이 활성화되면, 기존 인-트리 플러그인에서 -`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 모든 플러그인 작업을 리디렉션한다. -이 기능을 사용하려면, +`csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버로 모든 플러그인 작업을 리디렉션한다. 이 기능을 사용하려면, [vSphere CSI 드라이버](https://github.com/kubernetes-sigs/vsphere-csi-driver)가 클러스터에 설치되어야 하며 `CSIMigration` 및 `CSIMigrationvSphere` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있어야 한다. diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md index 7756c93cb0..6935cf8fb4 100644 --- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md @@ -10,7 +10,7 @@ weight: 80 -{{< feature-state for_k8s_version="v1.8" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} _크론잡은_ 반복 일정에 따라 {{< glossary_tooltip term_id="job" text="잡" >}}을 만든다. @@ -115,12 +115,17 @@ Cannot determine if job needs to be started. Too many missed start time (> 100). 크론잡은 오직 그 일정에 맞는 잡 생성에 책임이 있고, 잡은 그 잡이 대표하는 파드 관리에 책임이 있다. -## 새 컨트롤러 +## 컨트롤러 버전 {#new-controller} -쿠버네티스 1.20부터 알파 기능으로 사용할 수 있는 크론잡 컨트롤러의 대체 구현이 있다. 크론잡 컨트롤러의 버전 2를 선택하려면, 다음의 [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) 플래그를 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}에 전달한다. +쿠버네티스 v1.21부터 크론잡 컨트롤러의 두 번째 버전이 +기본 구현이다. 기본 크론잡 컨트롤러를 비활성화하고 +대신 원래 크론잡 컨트롤러를 사용하려면, `CronJobControllerV2` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) +플래그를 {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}}에 전달하고, +이 플래그를 `false` 로 설정한다. 예를 들면, 다음과 같다. ``` ---feature-gates="CronJobControllerV2=true" +--feature-gates="CronJobControllerV2=false" ``` diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md index d7d583d142..1496b25ec3 100644 --- a/content/ko/docs/concepts/workloads/controllers/daemonset.md +++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md @@ -1,4 +1,10 @@ --- + + + + + + title: 데몬셋 content_type: concept weight: 40 @@ -26,7 +32,8 @@ _데몬셋_ 은 모든(또는 일부) 노드가 파드의 사본을 실행하도 ### 데몬셋 생성 -YAML 파일로 데몬셋을 설명 할 수 있다. 예를 들어 아래 `daemonset.yaml` 파일은 fluentd-elasticsearch 도커 이미지를 실행하는 데몬셋을 설명한다. +YAML 파일에 데몬셋 명세를 작성할 수 있다. 예를 들어 아래 `daemonset.yaml` 파일은 +fluentd-elasticsearch 도커 이미지를 실행하는 데몬셋을 설명한다. {{< codenew file="controllers/daemonset.yaml" >}} @@ -40,19 +47,23 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml 다른 모든 쿠버네티스 설정과 마찬가지로 데몬셋에는 `apiVersion`, `kind` 그리고 `metadata` 필드가 필요하다. 일반적인 설정파일 작업에 대한 정보는 -[스테이트리스 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/), -[컨테이너 구성하기](/ko/docs/tasks/) 그리고 [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/) 문서를 참고한다. +[스테이트리스 애플리케이션 실행하기](/docs/tasks/run-application/run-stateless-application-deployment/)와 + [kubectl을 사용한 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다. 데몬셋 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. -데몬셋에는 [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 섹션도 필요하다. +데몬셋에는 +[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) +섹션도 필요하다. ### 파드 템플릿 `.spec.template` 는 `.spec` 의 필수 필드 중 하나이다. -`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. 이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 {{< glossary_tooltip text="파드" term_id="pod" >}}와 정확히 같은 스키마를 가진다. +`.spec.template` 는 [파드 템플릿](/ko/docs/concepts/workloads/pods/#파드-템플릿)이다. +이것은 중첩되어 있다는 점과 `apiVersion` 또는 `kind` 를 가지지 않는 것을 제외하면 +{{< glossary_tooltip text="파드" term_id="pod" >}}와 정확히 같은 스키마를 가진다. 데몬셋의 파드 템플릿에는 파드의 필수 필드 외에도 적절한 레이블이 명시되어야 한다([파드 셀렉터](#파드-셀렉터)를 본다). @@ -73,19 +84,22 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml `.spec.selector` 는 다음 2개의 필드로 구성된 오브젝트이다. -* `matchLabels` - [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)의 `.spec.selector` 와 동일하게 작동한다. +* `matchLabels` - [레플리케이션 컨트롤러](/ko/docs/concepts/workloads/controllers/replicationcontroller/)의 +`.spec.selector` 와 동일하게 작동한다. * `matchExpressions` - 키, 값 목록 그리고 키 및 값에 관련된 연산자를 명시해서 보다 정교한 셀렉터를 만들 수 있다. 2개의 필드가 명시되면 두 필드를 모두 만족하는 것(ANDed)이 결과가 된다. -만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. 일치하지 않는 구성은 API에 의해 거부된다. +만약 `.spec.selector` 를 명시하면, 이것은 `.spec.template.metadata.labels` 와 일치해야 한다. +일치하지 않는 구성은 API에 의해 거부된다. ### 오직 일부 노드에서만 파드 실행 만약 `.spec.template.spec.nodeSelector` 를 명시하면 데몬셋 컨트롤러는 [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와 -일치하는 노드에 파드를 생성한다. 마찬가지로 `.spec.template.spec.affinity` 를 명시하면 +일치하는 노드에 파드를 생성한다. +마찬가지로 `.spec.template.spec.affinity` 를 명시하면 데몬셋 컨트롤러는 [노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)와 일치하는 노드에 파드를 생성한다. 만약 둘 중 하나를 명시하지 않으면 데몬셋 컨트롤러는 모든 노드에서 파드를 생성한다. @@ -100,18 +114,19 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml 데몬셋 파드는 데몬셋 컨트롤러에 의해 생성되고 스케줄된다. 이에 대한 이슈를 소개한다. - * 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다. - 그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다. - 이것은 사용자에게 혼란을 준다. - * [파드 선점](/ko/docs/concepts/configuration/pod-priority-preemption/)은 - 기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는 - 파드 우선순위와 선점을 고려하지 않고 스케줄 한다. +* 파드 동작의 불일치: 스케줄 되기 위해서 대기 중인 일반 파드는 `Pending` 상태로 생성된다. + 그러나 데몬셋 파드는 `Pending` 상태로 생성되지 않는다. + 이것은 사용자에게 혼란을 준다. +* [파드 선점](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)은 + 기본 스케줄러에서 처리한다. 선점이 활성화되면 데몬셋 컨트롤러는 + 파드 우선순위와 선점을 고려하지 않고 스케줄 한다. `ScheduleDaemonSetPods` 로 데몬셋 파드에 `.spec.nodeName` 용어 대신 `NodeAffinity` 용어를 추가해서 데몬셋 컨트롤러 대신 기본 스케줄러를 사용해서 데몬셋을 스케줄할 수 있다. 이후에 기본 스케줄러를 사용해서 대상 호스트에 파드를 바인딩한다. 만약 데몬셋 파드에 -이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는 +이미 노드 선호도가 존재한다면 교체한다(대상 호스트를 선택하기 전에 +원래 노드의 어피니티가 고려된다). 데몬셋 컨트롤러는 데몬셋 파드를 만들거나 수정할 때만 이런 작업을 수행하며, 데몬셋의 `spec.template` 은 변경되지 않는다. @@ -152,10 +167,12 @@ nodeAffinity: - **푸시(Push)**: 데몬셋의 파드는 통계 데이터베이스와 같은 다른 서비스로 업데이트를 보내도록 구성되어있다. 그들은 클라이언트들을 가지지 않는다. -- **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, 노드IP를 통해 파드에 접근할 수 있다. 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다. +- **노드IP와 알려진 포트**: 데몬셋의 파드는 `호스트 포트`를 사용할 수 있으며, + 노드IP를 통해 파드에 접근할 수 있다. + 클라이언트는 노드IP를 어떻게든지 알고 있으며, 관례에 따라 포트를 알고 있다. - **DNS**: 동일한 파드 셀렉터로 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)를 만들고, - 그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 DNS에서 여러 A레코드를 - 검색한다. + 그 다음에 `엔드포인트` 리소스를 사용해서 데몬셋을 찾거나 + DNS에서 여러 A레코드를 검색한다. - **서비스**: 동일한 파드 셀렉터로 서비스를 생성하고, 서비스를 사용해서 임의의 노드의 데몬에 도달한다(특정 노드에 도달할 방법이 없다). diff --git a/content/ko/docs/concepts/workloads/controllers/deployment.md b/content/ko/docs/concepts/workloads/controllers/deployment.md index e19720491d..ac782e7008 100644 --- a/content/ko/docs/concepts/workloads/controllers/deployment.md +++ b/content/ko/docs/concepts/workloads/controllers/deployment.md @@ -706,7 +706,7 @@ nginx-deployment-618515232 11 11 11 7m 하나 이상의 업데이트를 트리거하기 전에 디플로이먼트를 일시 중지한 다음 다시 시작할 수 있다. 이렇게 하면 불필요한 롤아웃을 트리거하지 않고 일시 중지와 재개 사이에 여러 수정 사항을 적용할 수 있다. -* 예를 들어, 방금 생성된 디플로이먼트의 경우 +* 예를 들어, 생성된 디플로이먼트의 경우 디플로이먼트 상세 정보를 가져온다. ```shell kubectl get deploy diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md index 64b5d3879d..c24beb0fca 100644 --- a/content/ko/docs/concepts/workloads/controllers/job.md +++ b/content/ko/docs/concepts/workloads/controllers/job.md @@ -16,7 +16,8 @@ weight: 50 잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료될 때까지 계속해서 파드의 실행을 재시도한다. 파드가 성공적으로 완료되면, 성공적으로 완료된 잡을 추적한다. 지정된 수의 성공 완료에 도달하면, 작업(즉, 잡)이 완료된다. 잡을 삭제하면 잡이 생성한 -파드가 정리된다. +파드가 정리된다. 작업을 일시 중지하면 작업이 다시 재개될 때까지 활성 파드가 +삭제된다. 간단한 사례는 잡 오브젝트를 하나 생성해서 파드 하나를 안정적으로 실행하고 완료하는 것이다. 첫 번째 파드가 실패 또는 삭제된 경우(예로는 노드 하드웨어의 실패 또는 @@ -98,8 +99,8 @@ echo $pods pi-5rwd7 ``` -여기서 셀렉터는 잡의 셀렉터와 동일하다. `--output=jsonpath` 옵션은 반환된 목록의 -각각의 파드에서 이름을 가져와서 표현하는 방식을 지정한다. +여기서 셀렉터는 잡의 셀렉터와 동일하다. `--output=jsonpath` 옵션은 반환된 +목록에 있는 각 파드의 이름으로 표현식을 지정한다. 파드 중 하나를 표준 출력으로 본다. @@ -145,8 +146,8 @@ kubectl logs $pods - 파드가 성공적으로 종료하자마자 즉시 잡이 완료된다. 1. *고정적(fixed)인 완료 횟수* 를 가진 병렬 잡: - `.spec.completions` 에 0이 아닌 양수 값을 지정한다. - - 잡은 전체 작업을 나타내며 1에서 `.spec.completions` 까지의 범위의 각 값에 대해 한 개씩 성공한 파드가 있으면 완료된다. - - **아직 구현되지 않음:** 각 파드에게는 1부터 `.spec.completions` 까지의 범위 내의 서로 다른 인덱스가 전달된다. + - 잡은 전체 작업을 나타내며, `.spec.completions` 성공한 파드가 있을 때 완료된다. + - `.spec.completionMode="Indexed"` 를 사용할 때, 각 파드는 0에서 `.spec.completions-1` 범위 내의 서로 다른 인덱스를 가져온다. 1. *작업 큐(queue)* 가 있는 병렬 잡: - `.spec.completions` 를 지정하지 않고, `.spec.parallelism` 를 기본으로 한다. - 파드는 각자 또는 외부 서비스 간에 조정을 통해 각각의 작업을 결정해야 한다. 예를 들어 파드는 작업 큐에서 최대 N 개의 항목을 일괄로 가져올(fetch) 수 있다. @@ -166,7 +167,6 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 다른 유형의 잡을 사용하는 방법에 대한 더 자세한 정보는 [잡 패턴](#잡-패턴) 섹션을 본다. - #### 병렬 처리 제어하기 요청된 병렬 처리(`.spec.parallelism`)는 음수가 아닌 값으로 설정할 수 있다. @@ -185,6 +185,33 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고 - 잡 컨트롤러는 동일한 잡에서 과도하게 실패한 이전 파드들로 인해 새로운 파드의 생성을 조절할 수 있다. - 파드가 정상적으로(gracefully) 종료되면, 중지하는데 시간이 소요된다. +### 완료 모드 + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +{{< note >}} +인덱싱된 잡을 생성하려면, [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/) +및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서 +`IndexedJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 +활성화해야 한다. +{{< /note >}} + +완료 횟수가 _고정적인 완료 횟수_ 즉, null이 아닌 `.spec.completions` 가 있는 잡은 +`.spec.completionMode` 에 지정된 완료 모드를 가질 수 있다. + +- `NonIndexed` (기본값): `.spec.completions` 가 성공적으로 + 완료된 파드가 있는 경우 작업이 완료된 것으로 간주된다. 즉, 각 파드 + 완료는 서로 상동하다(homologous). null `.spec.completions` 가 있는 + 잡은 암시적으로 `NonIndexed` 이다. +- `Indexed`: 잡의 파드는 `batch.kubernetes.io/job-completion-index` + 어노테이션에서 사용할 수 있는 0에서 `.spec.completions-1` 까지 연결된 완료 인덱스를 가져온다. + 각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로 + 간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은 + [정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다. + 참고로, 드물기는 하지만, 동일한 인덱스에 대해 둘 이상의 파드를 시작할 수 + 있지만, 그 중 하나만 완료 횟수에 포함된다. + + ## 파드와 컨테이너 장애 처리하기 파드내 컨테이너의 프로세스가 0이 아닌 종료 코드로 종료되었거나 컨테이너 메모리 제한을 @@ -277,7 +304,7 @@ spec: ### 완료된 잡을 위한 TTL 메커니즘 -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} 완료된 잡 (`Complete` 또는 `Failed`)을 자동으로 정리하는 또 다른 방법은 잡의 `.spec.ttlSecondsAfterFinished` 필드를 지정해서 완료된 리소스에 대해 @@ -315,11 +342,6 @@ spec: 삭제되도록 할 수 있다. 만약 필드를 설정하지 않으면, 이 잡이 완료된 후에 TTL 컨트롤러에 의해 정리되지 않는다. -이 TTL 메커니즘은 기능 게이트 `TTLAfterFinished`와 함께 알파 단계이다. 더 -자세한 정보는 완료된 리소스를 위한 -[TTL 컨트롤러](/ko/docs/concepts/workloads/controllers/ttlafterfinished/) -문서를 본다. - ## 잡 패턴 잡 오브젝트를 사용해서 신뢰할 수 있는 파드의 병렬 실행을 지원할 수 있다. 잡 오브젝트는 과학 @@ -348,12 +370,12 @@ spec: 여기에 트레이드오프가 요약되어있고, 2열에서 4열까지가 위의 트레이드오프에 해당한다. 패턴 이름은 예시와 더 자세한 설명을 위한 링크이다. -| 패턴 | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정하지 않은 앱을 사용하는가? | Kube 1.1에서 작동하는가? | -| -------------------------------------------------------------------- |:-----------------:|:---------------------------:|:-------------------:|:-------------------:| -| [잡 템플릿 확장](/ko/docs/tasks/job/parallel-processing-expansion/) | | | ✓ | ✓ | -| [작업 항목 당 파드가 있는 큐](/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 때때로 | ✓ | -| [가변 파드 수를 가진 큐](/ko/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | | ✓ | -| 정적 작업이 할당된 단일 잡 | ✓ | | ✓ | | +| 패턴 | 단일 잡 오브젝트 | 작업 항목보다 파드가 적은가? | 수정되지 않은 앱을 사용하는가? | +| ----------------------------------------- |:-----------------:|:---------------------------:|:-------------------:| +| [작업 항목 당 파드가 있는 큐] | ✓ | | 때때로 | +| [가변 파드 수를 가진 큐] | ✓ | ✓ | | +| [정적 작업 할당을 사용한 인덱싱된 잡] | ✓ | | ✓ | +| [잡 템플릿 확장] | | | ✓ | `.spec.completions` 로 완료를 지정할 때, 잡 컨트롤러에 의해 생성된 각 파드는 동일한 [`사양`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)을 갖는다. 이 의미는 @@ -364,16 +386,121 @@ spec: 이 표는 각 패턴에 필요한 `.spec.parallelism` 그리고 `.spec.completions` 설정을 보여준다. 여기서 `W` 는 작업 항목의 수이다. -| 패턴 | `.spec.completions` | `.spec.parallelism` | -| -------------------------------------------------------------------- |:-------------------:|:--------------------:| -| [잡 템플릿 확장](/ko/docs/tasks/job/parallel-processing-expansion/) | 1 | 1이어야 함 | -| [작업 항목 당 파드가 있는 큐](/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | any | -| [가변 파드 수를 가진 큐](/ko/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | any | -| 정적 작업이 할당된 단일 잡 | W | any | +| 패턴 | `.spec.completions` | `.spec.parallelism` | +| ----------------------------------------- |:-------------------:|:--------------------:| +| [작업 항목 당 파드가 있는 큐] | W | any | +| [가변 파드 수를 가진 큐] | null | any | +| [정적 작업 할당을 사용한 인덱싱된 잡] | W | any | +| [잡 템플릿 확장] | 1 | 1이어야 함 | +[작업 항목 당 파드가 있는 큐]: /docs/tasks/job/coarse-parallel-processing-work-queue/ +[가변 파드 수를 가진 큐]: /docs/tasks/job/fine-parallel-processing-work-queue/ +[정적 작업 할당을 사용한 인덱싱된 잡]: /docs/tasks/job/indexed-parallel-processing-static/ +[잡 템플릿 확장]: /docs/tasks/job/parallel-processing-expansion/ ## 고급 사용법 +### 잡 일시 중지 + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +{{< note >}} +잡 일시 중지는 쿠버네티스 버전 1.21 이상에서 사용할 수 있다. 이 기능을 +사용하려면 [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/) +및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서 +`SuspendJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 +활성화해야 한다. +{{< /note >}} + +잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해 +즉시 파드 생성을 시작하고 잡이 완료될 때까지 +계속한다. 그러나, 잡의 실행을 일시적으로 중단하고 나중에 +다시 시작할 수도 있다. 잡을 일시 중지하려면, 잡의 `.spec.suspend` 필드를 true로 +업데이트할 수 있다. 나중에, 다시 재개하려면, false로 업데이트한다. +`.spec.suspend` 로 설정된 잡을 생성하면 일시 중지된 상태로 +생성된다. + +잡이 일시 중지에서 재개되면, 해당 `.status.startTime` 필드가 +현재 시간으로 재설정된다. 즉, 잡이 일시 중지 및 재개되면 `.spec.activeDeadlineSeconds` +타이머가 중지되고 재설정된다. + +잡을 일시 중지하면 모든 활성 파드가 삭제된다. 잡이 +일시 중지되면, SIGTERM 시그널로 [파드가 종료된다](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination). +파드의 정상 종료 기간이 적용되며 사용자의 파드는 이 기간 동안에 +이 시그널을 처리해야 한다. 나중에 진행 상황을 저장하거나 +변경 사항을 취소하는 작업이 포함될 수 있다. 이 방법으로 종료된 파드는 +잡의 `completions` 수에 포함되지 않는다. + +일시 중지된 상태의 잡 정의 예시는 다음과 같다. + +```shell +kubectl get job myjob -o yaml +``` + +```yaml +apiVersion: batch/v1 +kind: Job +metadata: + name: myjob +spec: + suspend: true + parallelism: 1 + completions: 5 + template: + spec: + ... +``` + +잡의 상태를 사용하여 잡이 일시 중지되었는지 또는 과거에 일시 중지되었는지 +확인할 수 있다. + +```shell +kubectl get jobs/myjob -o yaml +``` + +```json +apiVersion: batch/v1 +kind: Job +# .metadata and .spec omitted +status: + conditions: + - lastProbeTime: "2021-02-05T13:14:33Z" + lastTransitionTime: "2021-02-05T13:14:33Z" + status: "True" + type: Suspended + startTime: "2021-02-05T13:13:48Z" +``` + +"True" 상태인 "Suspended" 유형의 잡의 컨디션은 잡이 +일시 중지되었음을 의미한다. 이 `lastTransitionTime` 필드는 잡이 일시 중지된 +기간을 결정하는 데 사용할 수 있다. 해당 컨디션의 상태가 "False"이면, 잡이 +이전에 일시 중지되었다가 현재 실행 중이다. 이러한 컨디션이 +잡의 상태에 없으면, 잡이 중지되지 않은 것이다. + +잡이 일시 중지 및 재개될 때에도 이벤트가 생성된다. + +```shell +kubectl describe jobs/myjob +``` + +``` +Name: myjob +... +Events: + Type Reason Age From Message + ---- ------ ---- ---- ------- + Normal SuccessfulCreate 12m job-controller Created pod: myjob-hlrpl + Normal SuccessfulDelete 11m job-controller Deleted pod: myjob-hlrpl + Normal Suspended 11m job-controller Job suspended + Normal SuccessfulCreate 3s job-controller Created pod: myjob-jvb44 + Normal Resumed 3s job-controller Job resumed +``` + +마지막 4개의 이벤트, 특히 "Suspended" 및 "Resumed" 이벤트는 +`.spec.suspend` 필드를 전환한 결과이다. 이 두 이벤트 사이의 시간동안 +파드가 생성되지 않았지만, 잡이 재개되자마자 파드 생성이 다시 +시작되었음을 알 수 있다. + ### 자신의 파드 셀렉터를 지정하기 일반적으로 잡 오브젝트를 생성할 때 `.spec.selector` 를 지정하지 않는다. diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md index 8966029620..7cf399d242 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicaset.md +++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md @@ -222,7 +222,7 @@ pod2 1/1 Running 0 36s ## 레플리카셋 매니페스트 작성하기 레플리카셋은 모든 쿠버네티스 API 오브젝트와 마찬가지로 `apiVersion`, `kind`, `metadata` 필드가 필요하다. -레플리카셋에 대한 kind 필드의 값은 항상 레플리카셋이다. +레플리카셋에 대한 `kind` 필드의 값은 항상 레플리카셋이다. 쿠버네티스 1.9에서의 레플리카셋의 kind에 있는 API 버전 `apps/v1`은 현재 버전이며, 기본으로 활성화 되어있다. API 버전 `apps/v1beta2`은 사용 중단(deprecated)되었다. API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한다. @@ -237,7 +237,7 @@ API 버전에 대해서는 `frontend.yaml` 예제의 첫 번째 줄을 참고한 우리는 `frontend.yaml` 예제에서 `tier: frontend`이라는 레이블을 하나 가지고 있다. 이 파드를 다른 컨트롤러가 취하지 않도록 다른 컨트롤러의 셀렉터와 겹치지 않도록 주의해야 한다. -템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#재시작-정책) 필드인 +템플릿의 [재시작 정책](/ko/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 필드인 `.spec.template.spec.restartPolicy`는 기본값인 `Always`만 허용된다. ### 파드 셀렉터 @@ -307,9 +307,51 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron ### 레플리카셋의 스케일링 -레플리카셋을 손쉽게 스케일 업 또는 다운하는 방법은 단순히 `.spec.replicas` 필드를 업데이트 하면 된다. +레플리카셋을 손쉽게 스케일 업 또는 다운하는 방법은 단순히 `.spec.replicas` 필드를 업데이트하면 된다. 레플리카셋 컨트롤러는 일치하는 레이블 셀렉터가 있는 파드가 의도한 수 만큼 가용하고 운영 가능하도록 보장한다. +스케일 다운할 때, 레플리카셋 컨트롤러는 스케일 다운할 파드의 +우선순위를 정하기 위해 다음의 기준으로 가용 파드를 정렬하여 삭제할 파드를 결정한다. + 1. Pending 상태인 (+ 스케줄링할 수 없는) 파드가 먼저 스케일 다운된다. + 2. `controller.kubernetes.io/pod-deletion-cost` 어노테이션이 설정되어 있는 + 파드에 대해서는, 낮은 값을 갖는 파드가 먼저 스케일 다운된다. + 3. 더 많은 레플리카가 있는 노드의 파드가 더 적은 레플리카가 있는 노드의 파드보다 먼저 스케일 다운된다. + 4. 파드 생성 시간이 다르면, 더 최근에 생성된 파드가 + 이전에 생성된 파드보다 먼저 스케일 다운된다. + (`LogarithmicScaleDown` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되어 있으면 생성 시간이 정수 로그 스케일로 버킷화된다) + +모든 기준에 대해 동등하다면, 스케일 다운할 파드가 임의로 선택된다. + +### 파드 삭제 비용 +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +[`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여, +레플리카셋을 스케일 다운할 때 어떤 파드부터 먼저 삭제할지에 대한 우선순위를 설정할 수 있다. + +이 어노테이션은 파드에 설정되어야 하며, [-2147483647, 2147483647] 범위를 갖는다. +이 어노테이션은 하나의 레플리카셋에 있는 다른 파드와의 상대적 삭제 비용을 나타낸다. +삭제 비용이 낮은 파드는 삭제 비용이 높은 파드보다 삭제 우선순위가 높다. + +파드에 대해 이 값을 명시하지 않으면 기본값은 0이다. 음수로도 설정할 수 있다. +유효하지 않은 값은 API 서버가 거부한다. + +이 기능은 알파 상태이며 기본적으로는 비활성화되어 있다. +kube-apiserver와 kube-controller-manager에서 `PodDeletionCost` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 켜서 활성화할 수 있다. + +{{< note >}} +- 이 기능은 best-effort 방식으로 동작하므로, 파드 삭제 순서를 보장하지는 않는다. +- 이 값을 자주 바꾸는 것은 피해야 한다 (예: 메트릭 값에 따라 변경). +apiserver에서 많은 양의 파드 업데이트를 동반하기 때문이다. +{{< /note >}} + +#### 사용 예시 +한 애플리케이션 내의 여러 파드는 각각 사용률이 다를 수 있다. 스케일 다운 시, +애플리케이션은 사용률이 낮은 파드를 먼저 삭제하고 싶을 수 있다. 파드를 자주 +업데이트하는 것을 피하기 위해, 애플리케이션은 `controller.kubernetes.io/pod-deletion-cost` 값을 +스케일 다운하기 전에 1회만 업데이트해야 한다 (파드 사용률에 비례하는 값으로 설정). +이 방식은 Spark 애플리케이션의 드라이버 파드처럼 애플리케이션이 스스로 다운스케일링을 수행하는 경우에 유효하다. + ### 레플리카셋을 Horizontal Pod Autoscaler 대상으로 설정 레플리카셋은 diff --git a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md index 06ce543012..db69cf921c 100644 --- a/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/ko/docs/concepts/workloads/controllers/replicationcontroller.md @@ -54,7 +54,9 @@ kubectl 명령에서 숏컷으로 사용된다. ```shell kubectl apply -f https://k8s.io/examples/controllers/replication.yaml ``` + 출력 결과는 다음과 같다. + ``` replicationcontroller/nginx created ``` @@ -64,7 +66,9 @@ replicationcontroller/nginx created ```shell kubectl describe replicationcontrollers/nginx ``` + 출력 결과는 다음과 같다. + ``` Name: nginx Namespace: default @@ -103,14 +107,16 @@ Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name}) echo $pods ``` + 출력 결과는 다음과 같다. + ``` nginx-3ntk0 nginx-4ok8v nginx-qrm3m ``` 여기서 셀렉터는 레플리케이션컨트롤러(`kubectl describe` 의 출력에서 보인)의 셀렉터와 같고, -다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 옵션은 -반환된 목록의 각 파드에서 이름을 가져오는 표현식을 지정한다. +다른 형식의 파일인 `replication.yaml` 의 것과 동일하다. `--output=jsonpath` 은 +반환된 목록의 각 파드의 이름을 출력하도록 하는 옵션이다. ## 레플리케이션 컨트롤러의 Spec 작성 @@ -118,7 +124,7 @@ nginx-3ntk0 nginx-4ok8v nginx-qrm3m 다른 모든 쿠버네티스 컨피그와 마찬가지로 레플리케이션 컨트롤러는 `apiVersion`, `kind`, `metadata` 와 같은 필드가 필요하다. 레플리케이션 컨트롤러 오브젝트의 이름은 유효한 [DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. -컨피그 파일의 동작에 관련된 일반적인 정보는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다. +환경설정 파일의 동작에 관련된 일반적인 정보는 [쿠버네티스 오브젝트 관리](/ko/docs/concepts/overview/working-with-objects/object-management/)를 참고한다. 레플리케이션 컨트롤러는 또한 [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)도 필요하다. @@ -198,7 +204,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리 ### 레플리케이션 컨트롤러에서 파드 격리 -파드는 레이블을 변경하여 레플리케이션 컨트롤러의 대상 셋에서 제거될 수 있다. 이 기술은 디버깅, 데이터 복구 등을 위해 서비스에서 파드를 제거하는데 사용될 수 있다. 이 방법으로 제거된 파드는 자동으로 교체된다 (레플리카 수가 변경되지 않는다고 가정). +파드는 레이블을 변경하여 레플리케이션 컨트롤러의 대상 셋에서 제거될 수 있다. 이 기술은 디버깅과 데이터 복구를 위해 서비스에서 파드를 제거하는 데 사용될 수 있다. 이 방법으로 제거된 파드는 자동으로 교체된다 (레플리카 수가 변경되지 않는다고 가정). ## 일반적인 사용법 패턴 @@ -208,8 +214,7 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리 ### 스케일링 -레플리케이션컨트롤러는 `replicas` 필드를 설정하여 레플리카의 수를 늘리거나 줄인다. -레플리카를 수동으로 또는 오토 스케일링 제어 에이전트로 관리하도록 레플리케이션컨트롤러를 구성할 수 있다. +레플리케이션컨트롤러는 `replicas` 필드를 업데이트하여, 수동으로 또는 오토 스케일링 제어 에이전트를 통해, 레플리카의 수를 늘리거나 줄일 수 있다. ### 롤링 업데이트 @@ -246,7 +251,6 @@ REST API나 Go 클라이언트 라이브러리를 사용하는 경우 레플리 레플리케이션 컨트롤러는 조합 가능한 빌딩-블록 프리미티브가 되도록 고안되었다. 향후 사용자의 편의를 위해 더 상위 수준의 API 및/또는 도구와 그리고 다른 보완적인 기본 요소가 그 위에 구축 될 것으로 기대한다. 현재 kubectl이 지원하는 "매크로" 작업 (실행, 스케일)은 개념 증명의 예시이다. 예를 들어 [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html)와 같이 레플리케이션 컨트롤러, 오토 스케일러, 서비스, 정책 스케줄링, 카나리 등을 관리할 수 있다. - ## API 오브젝트 레플리케이션 컨트롤러는 쿠버네티스 REST API의 최상위 수준의 리소스이다. @@ -261,8 +265,7 @@ API 오브젝트에 대한 더 자세한 것은 이것은 주로 [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)에 의해 파드의 생성, 삭제 및 업데이트를 오케스트레이션 하는 메커니즘으로 사용된다. 사용자 지정 업데이트 조정이 필요하거나 업데이트가 필요하지 않은 경우가 아니면 레플리카셋을 직접 사용하는 대신 디플로이먼트를 사용하는 것이 좋다. - -### 디플로이먼트 (권장되는) +### 디플로이먼트 (권장됨) [`Deployment`](/ko/docs/concepts/workloads/controllers/deployment/)는 기본 레플리카셋과 그 파드를 업데이트하는 상위 수준의 API 오브젝트이다. 선언적이며, 서버 사이드이고, 추가 기능이 있기 때문에 롤링 업데이트 기능을 원한다면 디플로이먼트를 권장한다. diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md index 3a1f784259..e231770cc5 100644 --- a/content/ko/docs/concepts/workloads/controllers/statefulset.md +++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md @@ -213,9 +213,9 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가 `OrderedReady` 파드 관리는 스테이트풀셋의 기본이다. 이것은 [위에서](#디플로이먼트와-스케일-보증) 설명한 행위를 구현한다. -#### 병렬 파드 관리 +#### Parallel 파드 관리 -`병렬` 파드 관리는 스테이트풀셋 컨트롤러에게 모든 파드를 +`Parallel` 파드 관리는 스테이트풀셋 컨트롤러에게 모든 파드를 병렬로 실행 또는 종료하게 한다. 그리고 다른 파드의 실행이나 종료에 앞서 파드가 Running 및 Ready 상태가 되거나 완전히 종료되기를 기다리지 않는다. 이 옵션은 오직 스케일링 작업에 대한 동작에만 영향을 미친다. 업데이트는 영향을 diff --git a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md index 5ed869fb57..4703b63b4a 100644 --- a/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/ko/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -6,7 +6,7 @@ weight: 70 -{{< feature-state for_k8s_version="v1.12" state="alpha" >}} +{{< feature-state for_k8s_version="v1.21" state="beta" >}} TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 제한하는 TTL (time to live) 메커니즘을 제공한다. TTL 컨트롤러는 현재 @@ -14,9 +14,9 @@ TTL 컨트롤러는 실행이 완료된 리소스 오브젝트의 수명을 처리하며, 파드와 커스텀 리소스와 같이 실행을 완료할 다른 리소스를 처리하도록 확장될 수 있다. -알파(Alpha) 고지 사항: 이 기능은 현재 알파이고, -kube-apiserver와 kube-controller-manager와 함께 -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)로 `TTLAfterFinished` 를 활성화할 수 있다. +이 기능은 현재 베타이고 기본적으로 활성화되어 있다. +kube-apiserver와 kube-controller-manager에서 `TTLAfterFinished` +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 비활성화할 수 있다. diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md index 8645053bef..22b98b705c 100644 --- a/content/ko/docs/concepts/workloads/pods/_index.md +++ b/content/ko/docs/concepts/workloads/pods/_index.md @@ -32,10 +32,10 @@ _파드_ (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로) ## 파드란 무엇인가? {{< note >}} -[도커](https://www.docker.com/)가 가장 일반적으로 -잘 알려진 런타임이지만, 쿠버네티스는 도커보다 -{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}을 -더 많이 지원하며, 도커의 일부 용어를 사용하면 파드를 설명하는 데 도움이 된다. +[도커](https://www.docker.com/)가 가장 일반적으로 잘 알려진 +{{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이지만, +쿠버네티스는 도커 외에도 다양한 컨테이너 런타임을 지원하며, +파드를 설명할 때 도커 관련 용어를 사용하면 더 쉽게 설명할 수 있다. {{< /note >}} 파드의 공유 콘텍스트는 리눅스 네임스페이스, 컨트롤 그룹(cgroup) 및 diff --git a/content/ko/docs/concepts/workloads/pods/disruptions.md b/content/ko/docs/concepts/workloads/pods/disruptions.md index bcfde559cb..497d857d11 100644 --- a/content/ko/docs/concepts/workloads/pods/disruptions.md +++ b/content/ko/docs/concepts/workloads/pods/disruptions.md @@ -31,7 +31,7 @@ weight: 60 - 클라우드 공급자 또는 하이퍼바이저의 오류로 인한 VM 장애 - 커널 패닉 - 클러스터 네트워크 파티션의 발생으로 클러스터에서 노드가 사라짐 -- 노드의 [리소스 부족](/docs/tasks/administer-cluster/out-of-resource/)으로 파드가 축출됨 +- 노드의 [리소스 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)으로 파드가 축출됨 리소스 부족을 제외한 나머지 조건은 대부분의 사용자가 익숙할 것이다. 왜냐하면 @@ -76,20 +76,23 @@ weight: 60 - 복제된 애플리케이션의 구동 시 훨씬 더 높은 가용성을 위해 랙 전체 ([안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티) 이용) 또는 영역 간 - ([다중 영역 클러스터](/docs/setup/multiple-zones)를 이용한다면)에 + ([다중 영역 클러스터](/ko/docs/setup/best-practices/multiple-zones/)를 이용한다면)에 애플리케이션을 분산해야 한다. -자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자발적인 운영 중단이 전혀 없다. +자발적 중단의 빈도는 다양하다. 기본적인 쿠버네티스 클러스터에서는 자동화된 자발적 중단은 발생하지 않는다(사용자가 지시한 자발적 중단만 발생한다). 그러나 클러스터 관리자 또는 호스팅 공급자가 자발적 중단이 발생할 수 있는 일부 부가 서비스를 운영할 수 있다. 예를 들어 노드 소프트웨어의 업데이트를 출시하는 경우 자발적 중단이 발생할 수 있다. 또한 클러스터(노드) 오토스케일링의 일부 구현에서는 단편화를 제거하고 노드의 효율을 높이는 과정에서 자발적 중단을 야기할 수 있다. 클러스터 관리자 또는 호스팅 공급자는 예측 가능한 자발적 중단 수준에 대해 문서화해야 한다. +파드 스펙 안에 [프라이어리티클래스 사용하기](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)와 같은 특정 환경설정 옵션 +또한 자발적(+ 비자발적) 중단을 유발할 수 있다. + ## 파드 disruption budgets -{{< feature-state for_k8s_version="v1.5" state="beta" >}} +{{< feature-state for_k8s_version="v1.21" state="stable" >}} 쿠버네티스는 자발적인 중단이 자주 발생하는 경우에도 고 가용성 애플리케이션을 실행하는 데 도움이 되는 기능을 제공한다. @@ -135,7 +138,7 @@ PDB는 [비자발적 중단](#자발적-중단과-비자발적-중단)이 발생 Eviction API를 사용하여 파드를 축출하면, [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)의 -`terminationGracePeriodSeconds` 설정을 준수하여 정상적으로 [종료됨](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료) 상태가 된다.) +`terminationGracePeriodSeconds` 설정을 준수하여 정상적으로 [종료됨](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-종료) 상태가 된다. ## PodDisruptionBudget 예시 {#pdb-example} diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md index 56f59c1d30..c8c7055408 100644 --- a/content/ko/docs/concepts/workloads/pods/init-containers.md +++ b/content/ko/docs/concepts/workloads/pods/init-containers.md @@ -313,20 +313,18 @@ myapp-pod 1/1 Running 0 9m 파드는 다음과 같은 사유로, 초기화 컨테이너들의 재-실행을 일으키는, 재시작을 수행할 수 있다. -* 사용자가 초기화 컨테이너 이미지의 변경을 일으키는 파드 스펙 업데이트를 수행했다. - Init Container 이미지를 변경하면 파드가 다시 시작된다. 앱 컨테이너 - 이미지의 변경은 앱 컨테이너만 재시작시킨다. -* 파드 인프라스트럭처 컨테이너가 재시작되었다. 이는 일반적인 상황이 아니며 노드에 +* 파드 인프라스트럭처 컨테이너가 재시작된 상황. 이는 일반적인 상황이 아니며 노드에 대해서 root 접근 권한을 가진 누군가에 의해서 수행됐을 것이다. -* 파드 내의 모든 컨테이너들이, 재시작을 강제하는 `restartPolicy` 가 항상(Always)으로 설정되어 있는, - 동안 종료되었다. 그리고 초기화 컨테이너의 완료 기록이 가비지 수집 - 때문에 유실되었다. - - +* 초기화 컨테이너의 완료 기록이 가비지 수집 때문에 유실된 상태에서, + `restartPolicy`가 Always로 설정된 파드의 모든 컨테이너가 종료되어 + 모든 컨테이너를 재시작해야 하는 상황 +초기화 컨테이너 이미지가 변경되거나 초기화 컨테이너의 완료 기록이 가비지 수집 +때문에 유실된 상태이면 파드는 재시작되지 않는다. 이는 쿠버네티스 버전 1.20 이상에 +적용된다. 이전 버전의 쿠버네티스를 사용하는 경우 해당 쿠버네티스 버전의 문서를 +참고한다. ## {{% heading "whatsnext" %}} - * [초기화 컨테이너를 가진 파드 생성하기](/ko/docs/tasks/configure-pod-container/configure-pod-initialization/#초기화-컨테이너를-갖는-파드-생성) * [초기화 컨테이너 디버깅](/ko/docs/tasks/debug-application-cluster/debug-init-containers/) 알아보기 diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md index aa154a4b42..010694409e 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md @@ -39,7 +39,7 @@ ID([UID](/ko/docs/concepts/overview/working-with-objects/names/#uids))가 파드는 자체적으로 자가 치유되지 않는다. 파드가 {{< glossary_tooltip text="노드" term_id="node" >}}에 스케줄된 후에 해당 노드가 실패하면, 파드는 삭제된다. 마찬가지로, 파드는 -리소스 부족 또는 노드 유지 관리 작업으로 인해 축출되지 않는다. 쿠버네티스는 +리소스 부족 또는 노드 유지 관리 작업으로 인한 축출에서 살아남지 못한다. 쿠버네티스는 {{< glossary_tooltip term_id="controller" text="컨트롤러" >}}라 부르는 하이-레벨 추상화를 사용하여 상대적으로 일회용인 파드 인스턴스를 관리하는 작업을 처리한다. @@ -304,16 +304,26 @@ kubelet은 실행 중인 컨테이너들에 대해서 선택적으로 세 가지 보일 수도 있지만, 스팩에 준비성 프로브가 존재한다는 것은 파드가 트래픽을 받지 않는 상태에서 시작되고 프로브가 성공하기 시작한 이후에만 트래픽을 받는다는 뜻이다. -만약 컨테이너가 대량의 데이터, 설정 파일들, -또는 시동 중 마그레이션을 처리해야 한다면, 준비성 프로브를 지정하길 바란다. -만약 당신의 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면, +만약 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면, 준비성 프로브를 지정하길 바란다. 준비성 프로브는 활성 프로브와는 다르게 준비성에 특정된 엔드포인트를 확인한다. +만약 애플리케이션이 백엔드 서비스에 엄격한 의존성이 있다면, +활성 프로브와 준비성 프로브 모두 활용할 수도 있다. 활성 프로브는 애플리케이션 스스로가 건강한 상태면 +통과하지만, 준비성 프로브는 추가적으로 요구되는 각 백-엔드 서비스가 가용한지 확인한다. 이를 이용하여, +오류 메시지만 응답하는 파드로 +트래픽이 가는 것을 막을 수 있다. + +만약 컨테이너가 시동 시 대량 데이터의 로딩, 구성 파일, 또는 +마이그레이션에 대한 작업을 +수행해야 한다면, [스타트업 프로브](#언제-스타트업-프로브를-사용해야-하는가)를 사용하면 된다. 그러나, 만약 +failed 애플리케이션과 시동 중에 아직 데이터를 처리하고 있는 애플리케이션을 구분하여 탐지하고 +싶다면, 준비성 프로브를 사용하는 것이 더 적합할 것이다. + {{< note >}} -파드가 삭제될 때 단지 요청들을 흘려 보낼(drain) 목적으로, -준비성 프로브가 필요하지는 않다는 점을 유념해야 한다. 삭제 시에, 파드는 +파드가 삭제될 때 요청들을 흘려 보내기(drain) 위해 +준비성 프로브가 꼭 필요한 것은 아니다. 삭제 시에, 파드는 프로브의 존재 여부와 무관하게 자동으로 스스로를 준비되지 않은 상태(unready)로 변경한다. 파드는 파드 내의 모든 컨테이너들이 중지될 때까지 준비되지 않은 상태로 남아 있다. diff --git a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index b927895575..304471bb28 100644 --- a/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -13,9 +13,9 @@ obsolete --> 사용자는 _토폴로지 분배 제약 조건_ 을 사용해서 지역, 영역, 노드 그리고 기타 사용자-정의 토폴로지 도메인과 같이 장애-도메인으로 설정된 클러스터에 걸쳐 파드가 분산되는 방식을 제어할 수 있다. 이를 통해 고가용성뿐만 아니라, 효율적인 리소스 활용의 목적을 이루는 데 도움이 된다. {{< note >}} -v1.19 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면 +v1.18 이전 버전의 쿠버네티스에서는 파드 토폴로지 분배 제약조건을 사용하려면 [API 서버](/ko/docs/concepts/overview/components/#kube-apiserver)와 -[스케줄러](/docs/reference/generated/kube-scheduler/)에서 +[스케줄러](/docs/reference/command-line-tools-reference/kube-scheduler/)에서 `EvenPodsSpread`[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다 {{< /note >}} @@ -58,7 +58,7 @@ graph TB class zoneA,zoneB cluster; {{< /mermaid >}} -레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘-알려진 레이블](/docs/reference/kubernetes-api/labels-annotations-taints/)을 재사용할 수 있다. +레이블을 수동으로 적용하는 대신에, 사용자는 대부분의 클러스터에서 자동으로 생성되고 채워지는 [잘-알려진 레이블](/docs/reference/labels-annotations-taints/)을 재사용할 수 있다. ## 파드의 분배 제약 조건 @@ -82,12 +82,11 @@ spec: 사용자는 하나 또는 다중 `topologySpreadConstraint` 를 정의해서 kube-scheduler 에게 클러스터에 걸쳐 있는 기존 파드와 시작하는 각각의 파드와 연관하여 배치하는 방법을 명령할 수 있다. 필드는 다음과 같다. - **maxSkew** 는 파드가 균등하지 않게 분산될 수 있는 정도를 나타낸다. - 이것은 주어진 토폴로지 유형의 임의의 두 토폴로지 도메인에 일치하는 - 파드의 수 사이에서 허용되는 차이의 최댓값이다. 이것은 0보다는 커야 - 한다. 그 의미는 `whenUnsatisfiable` 의 값에 따라 다르다. + 이것은 0보다는 커야 한다. 그 의미는 `whenUnsatisfiable` 의 값에 따라 다르다. - `whenUnsatisfiable` 이 "DoNotSchedule"과 같을 때, `maxSkew` 는 - 대상 토폴로지에서 일치하는 파드 수와 전역 최솟값 사이에 - 허용되는 최대 차이이다. + 대상 토폴로지에서 일치하는 파드 수와 전역 최솟값 + (토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수. 예를 들어 3개의 영역에 각각 0, 2, 3개의 일치하는 파드가 있으면, 전역 최솟값은 0) + 사이에 허용되는 최대 차이이다. - `whenUnsatisfiable` 이 "ScheduleAnyway"와 같으면, 스케줄러는 왜곡을 줄이는데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다. - **topologyKey** 는 노드 레이블의 키다. 만약 두 노드가 이 키로 레이블이 지정되고, 레이블이 동일한 값을 가진다면 스케줄러는 두 노드를 같은 토폴로지에 있는것으로 여기게 된다. 스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다. @@ -96,6 +95,8 @@ spec: - `ScheduleAnyway` 는 스케줄러에게 차이(skew)를 최소화하는 노드에 높은 우선 순위를 부여하면서, 스케줄링을 계속하도록 지시한다. - **labelSelector** 는 일치하는 파드를 찾는데 사용된다. 이 레이블 셀렉터와 일치하는 파드의 수를 계산하여 해당 토폴로지 도메인에 속할 파드의 수를 결정한다. 자세한 내용은 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 참조한다. +파드에 2개 이상의 `topologySpreadConstraint`가 정의되어 있으면, 각 제약 조건은 AND로 연결된다 - kube-scheduler는 새로운 파드의 모든 제약 조건을 만족하는 노드를 찾는다. + 사용자는 `kubectl explain Pod.spec.topologySpreadConstraints` 를 실행해서 이 필드에 대한 자세한 내용을 알 수 있다. ### 예시: 단수 토폴로지 분배 제약 조건 @@ -387,7 +388,8 @@ profiles: ## 알려진 제한사항 -- 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형이 될 수 있다. +- 파드가 제거된 이후에도 제약 조건이 계속 충족된다는 보장은 없다. 예를 들어 디플로이먼트를 스케일링 다운하면 그 결과로 파드의 분포가 불균형해질 수 있다. +[Descheduler](https://github.com/kubernetes-sigs/descheduler)를 사용하여 파드 분포를 다시 균형있게 만들 수 있다. - 파드와 일치하는 테인트(taint)가 된 노드가 존중된다. [이슈 80921](https://github.com/kubernetes/kubernetes/issues/80921)을 본다. ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/contribute/_index.md b/content/ko/docs/contribute/_index.md index 0582739545..dcb7a68f49 100644 --- a/content/ko/docs/contribute/_index.md +++ b/content/ko/docs/contribute/_index.md @@ -46,7 +46,7 @@ card: 1. CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명합니다. 1. [문서 리포지터리](https://github.com/kubernetes/website)와 웹사이트의 [정적 사이트 생성기](https://gohugo.io)를 숙지합니다. -1. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/new-content/)와 +1. [풀 리퀘스트 열기](/ko/docs/contribute/new-content/open-a-pr/)와 [변경 검토](/ko/docs/contribute/review/reviewing-prs/)의 기본 프로세스를 이해하도록 합니다. @@ -60,7 +60,7 @@ card: 기여할 수 있는 다양한 방법에 대해 알아봅니다. - [`kubernetes/website` 이슈 목록](https://github.com/kubernetes/website/issues/)을 확인하여 좋은 진입점이 되는 이슈를 찾을 수 있습니다. -- 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/ko/docs/contribute/new-content/new-content/#github을-사용하여-변경하기) +- 기존 문서에 대해 [GitHub을 사용해서 풀 리퀘스트 열거나](/ko/docs/contribute/new-content/open-a-pr/#github을-사용하여-변경하기) GitHub에서의 이슈 제기에 대해 자세히 알아봅니다. - 정확성과 언어에 대해 다른 쿠버네티스 커뮤니티 맴버의 [풀 리퀘스트 검토](/ko/docs/contribute/review/reviewing-prs/)를 합니다. @@ -71,7 +71,7 @@ card: ## 다음 단계 -- 리포지터리의 [로컬 복제본에서 작업](/ko/docs/contribute/new-content/new-content/#fork-the-repo)하는 +- 리포지터리의 [로컬 복제본에서 작업](/ko/docs/contribute/new-content/open-a-pr/#fork-the-repo)하는 방법을 배워봅니다. - [릴리스된 기능](/docs/contribute/new-content/new-features/)을 문서화 합니다. - [SIG Docs](/ko/docs/contribute/participate/)에 참여하고, @@ -96,6 +96,6 @@ SIG Docs는 여러가지 방법으로 의견을 나누고 있습니다. ## 다른 기여 방법들 -- [쿠버네티스 커뮤니티 사이트](/community/)를 방문하십시오. 트위터 또는 스택 오버플로우에 참여하고, 현지 쿠버네티스 모임과 이벤트 등에 대해 알아봅니다. +- [쿠버네티스 커뮤니티 사이트](/ko/community/)를 방문하십시오. 트위터 또는 스택 오버플로우에 참여하고, 현지 쿠버네티스 모임과 이벤트 등에 대해 알아봅니다. - [기여자 치트시트](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet)를 읽고 쿠버네티스 기능 개발에 참여합니다. - [블로그 게시물 또는 사례 연구](/docs/contribute/new-content/blogs-case-studies/)를 제출합니다. diff --git a/content/ko/docs/contribute/analytics.md b/content/ko/docs/contribute/analytics.md new file mode 100644 index 0000000000..d96d1ed576 --- /dev/null +++ b/content/ko/docs/contribute/analytics.md @@ -0,0 +1,25 @@ +--- +title: 사이트 분석 보기 +content_type: concept +weight: 100 +card: + name: contribute + weight: 100 +--- + + + +이 페이지는 kubernetes.io 사이트 분석을 제공하는 대시보드에 대한 정보를 담고 있다. + + + + +[대시보드 보기](https://datastudio.google.com/reporting/fede2672-b2fd-402a-91d2-7473bdb10f04). + +이 대시보드는 Google Data Studio를 사용하여 구축되었으며 kubernetes.io에서 Google Analytics를 사용하여 수집한 정보를 보여준다. + +### 대시보드 사용 + +기본적으로 대시보드는 지난 30일 동안 수집된 모든 데이터의 분석을 제공한다. 날짜 선택을 통해 특정 날짜 범위의 데이터를 볼 수 있다. 그 외 필터링 옵션을 사용하면, 사용자의 위치, 사이트에 접속하는데 사용된 장치, 번역된 문서 언어 등을 기준으로 데이터를 확인할 수 있다. + + 이 대시보드에 문제가 있거나 개선을 요청하려면, [이슈를 오픈](https://github.com/kubernetes/website/issues/new/choose) 한다. diff --git a/content/ko/docs/contribute/generate-ref-docs/_index.md b/content/ko/docs/contribute/generate-ref-docs/_index.md index 756c509206..ad9d221f15 100644 --- a/content/ko/docs/contribute/generate-ref-docs/_index.md +++ b/content/ko/docs/contribute/generate-ref-docs/_index.md @@ -1,11 +1,11 @@ --- -title: 참조 문서 개요 +title: 레퍼런스 문서 개요 main_menu: true weight: 80 --- -이 섹션은 쿠버네티스 참조 가이드를 생성하는 방법에 대해 설명한다. +이 섹션은 쿠버네티스 레퍼런스 가이드를 생성하는 방법에 대해 설명한다. -참조 문서화 시스템을 빌드하려면, 다음의 가이드를 참고한다. +레퍼런스 문서를 생성하려면, 다음의 가이드를 참고한다. -* [참조 문서 생성에 대한 퀵스타트 가이드](/docs/contribute/generate-ref-docs/quickstart/) \ No newline at end of file +* [레퍼런스 문서 생성에 대한 퀵스타트 가이드](/ko/docs/contribute/generate-ref-docs/quickstart/) diff --git a/content/ko/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md b/content/ko/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md new file mode 100644 index 0000000000..b7c77889d8 --- /dev/null +++ b/content/ko/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md @@ -0,0 +1,22 @@ + +### 필요 사항: {#Requirements} + +- 리눅스 또는 macOS 로 구동되는 개발 환경이 필요하다. + +- 다음의 도구들이 설치되어 있어야 한다. + + - [Python](https://www.python.org/downloads/) v3.7.x + - [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) + - [Golang](https://golang.org/doc/install) version 1.13+ + - [Pip](https://pypi.org/project/pip/) (PyYAML 설치에 필요함) + - [PyYAML](https://pyyaml.org/) v5.1.2 + - [make](https://www.gnu.org/software/make/) + - [gcc compiler/linker](https://gcc.gnu.org/) + - [Docker](https://docs.docker.com/engine/installation/) (`kubectl` 명령어 레퍼런스 업데이트에만 필요함) + +- 위에 나열된 도구들 (예: `Go` 바이너리나 `python`) 을 사용할 수 있도록 `PATH` 환경 변수를 알맞게 설정해야 한다. + +- GitHub 저장소로 풀 리퀘스트를 생성하는 방법을 알고 있어야 한다. +이를 위해 `kubernetes/website` 저장소를 개인 계정으로 포크해야 한다. +더 자세한 내용은 [로컬 포크에서 작업하기](/ko/docs/contribute/new-content/open-a-pr/#fork-the-repo)를 참조한다. + diff --git a/content/ko/docs/contribute/generate-ref-docs/quickstart.md b/content/ko/docs/contribute/generate-ref-docs/quickstart.md new file mode 100644 index 0000000000..6855696b9d --- /dev/null +++ b/content/ko/docs/contribute/generate-ref-docs/quickstart.md @@ -0,0 +1,257 @@ +--- +title: 퀵스타트 가이드 +content_type: task +weight: 40 +--- + + + +이 문서에서는 `update-imported-docs` 스크립트를 사용하여 +쿠버네티스 레퍼런스 문서를 생성하는 방법에 대해 설명한다. +이 스크립트는 특정 쿠버네티스 릴리스 버전에 대해 빌드 설정을 자동으로 수행하고 레퍼런스 문서를 생성한다. + +## {{% heading "prerequisites" %}} + +{{< include "prerequisites-ref-docs.md" >}} + + + +## `website` 저장소 클론하기 {#Getting-the-docs-repository} + +개인 계정에 있는 포크 버전의 `website` 저장소가 GitHub에 있는 `kubernetes/website` 저장소(`main` 브랜치)의 최신 상태와 일치하는지 확인한 뒤, +개인 계정에 있는 포크 버전의 `website` 저장소를 로컬 개발 환경으로 클론한다. + +```shell +mkdir github.com +cd github.com +git clone git@github.com:/website.git +``` + +아래에서 사용될 '베이스 디렉터리'를 숙지해야 한다. 예를 들어 위에 안내된 대로 +저장소를 클론했다면, 베이스 디렉터리는 +`github.com/website` 가 된다. 이제 이 문서의 나머지 부분에서 `` 라는 구문이 나오면 +이 부분에 당신의 베이스 디렉터리를 대입하면 된다. + +{{< note>}} +만약 쿠버네티스 구성 도구와 API 레퍼런스에 기여하고 싶다면, +[업스트림 코드에 기여하기 (영문)](/docs/contribute/generate-ref-docs/contribute-upstream) 를 참조한다. +{{< /note >}} + +## `update-imported-docs` 스크립트 개요 {#Overview-of-update-imported-docs} + +`update-imported-docs` 스크립트는 `/update-imported-docs/` +디렉터리에 존재한다. + +이 스크립트는 다음 레퍼런스를 생성한다. + +* 구성요소 및 도구 레퍼런스 페이지 +* `kubectl` 명령어 레퍼런스 +* 쿠버네티스 API 레퍼런스 + +`update-imported-docs` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를 +생성한다. 스크립트가 실행되면 개발 머신의 `/tmp` 디렉터리 아래에 임시 디렉터리를 +생성하고, 이 임시 디렉터리 아래에 레퍼런스 문서 생성에 필요한 `kubernetes/kubernetes` 저장소와 +`kubernetes-sigs/reference-docs` 저장소를 클론하며, +`GOPATH` 환경 변수를 이 임시 디렉터리로 지정한다. +또한 이 스크립트는 다음의 환경 변수를 설정한다. + +* `K8S_RELEASE` +* `K8S_ROOT` +* `K8S_WEBROOT` + +스크립트가 정상적으로 실행되려면 인자 2개를 전달해야 한다. + +* 환경설정 YAML 파일 (`reference.yml`) +* 쿠버네티스 릴리스 버전 (예: `1.17`) + +환경설정 파일은 `generate-command` 라는 필드를 포함하는데, +이 필드에는 +`kubernetes-sigs/reference-docs/Makefile` 에 있는 Make 타겟들을 활용하여 빌드하는 일련의 과정이 명시되어 있다. +`K8S_RELEASE` 환경 변수는 릴리스 버전을 결정한다. + +`update-imported-docs` 스크립트는 다음의 과정을 수행한다. + +1. 환경설정 파일에 있는 관련 저장소를 클론한다. + 레퍼런스 문서 생성을 위해 + 기본적으로는 `kubernetes-sigs/reference-docs` 저장소를 클론하도록 되어 있다. +1. 클론한 안에서, 문서 생성에 필요한 사항을 준비하기 위한 명령어를 실행한 뒤, + HTML 파일과 마크다운 파일을 생성한다. +1. 생성된 HTML 파일과 마크다운 파일을 + 환경설정 파일에 명시된 규칙에 따라 `` 로 복사한다. +1. `kubectl`.md 에 있는 `kubectl` 명령어 링크들이 + `kubectl` 명령어 레퍼런스 페이지의 올바른 섹션으로 연결되도록 업데이트한다. + +생성된 파일이 `` 아래에 복사되었으면, +`kubernetes/website` 저장소로 [풀 리퀘스트를 생성](/ko/docs/contribute/new-content/open-a-pr/) +할 수 있다. + +## 환경설정 파일 형식 {#Configuration-file-format} + +각 환경설정 파일은 레퍼런스 생성을 위해 필요한 여러 저장소의 정보를 담을 수 있다. +필요한 경우, 환경설정 파일을 직접 수정하여 사용할 수도 있다. +또는, 다른 그룹의 문서를 임포트하기 위해 새로운 환경설정 파일을 작성할 수도 있다. +다음은 환경설정 YAML 파일의 예시이다. + +```yaml +repos: +- name: community + remote: https://github.com/kubernetes/community.git + branch: master + files: + - src: contributors/devel/README.md + dst: docs/imported/community/devel.md + - src: contributors/guide/README.md + dst: docs/imported/community/guide.md +``` + +이 도구에 의해 처리될 단일 페이지 마크다운 문서는 +[문서 스타일 가이드](/docs/contribute/style/style-guide/)의 내용을 만족해야 한다. + +## reference.yml 환경설정 파일 다루기 {#Customizing-reference-yml} + +`/update-imported-docs/reference.yml` 환경설정 파일을 열어 수정할 수 있다. +레퍼런스 문서 생성을 위해 명령어들이 어떻게 사용되고 있는지 파악하지 못했다면, +`generate-command` 필드의 내용은 수정하지 말아야 한다. +대부분의 경우 `reference.yml` 을 직접 수정해야 할 필요는 없다. +때때로, 업스트림 소스코드 업데이트 때문에 이 환경설정 파일을 수정해야 할 수도 있다. +(예: Golang 버전 의존성, 서드파티 라이브러리 변경 등) +만약 스크립트 사용 시 빌드 문제가 있다면, +[쿠버네티스 슬랙의 #sig-docs 채널](https://kubernetes.slack.com/archives/C1J0BPD2M)에서 SIG-Docs 팀에 문의하면 된다. + +{{< note >}} +`generate-command` 는 특정 저장소로부터 문서를 만들기 위한 +명령어나 스크립트를 실행하기 위해 사용할 수 있는 선택적 필드이다. +{{< /note >}} + +`reference.yml` 환경설정 파일에서, `files` 필드는 `src` 와 `dst` 필드를 포함한다. +`src` 필드에는 `kubernetes-sigs/reference-docs` 디렉터리 아래에 있는 생성된 마크다운 파일의 위치를 명시하고, +`dst` 필드에는 이 파일을 +`kubernetes/website` 디렉터리 아래의 어느 위치로 복사할지를 명시한다. +예시는 다음과 같다. + +```yaml +repos: +- name: reference-docs + remote: https://github.com/kubernetes-sigs/reference-docs.git + files: + - src: gen-compdocs/build/kube-apiserver.md + dst: content/en/docs/reference/command-line-tools-reference/kube-apiserver.md + ... +``` + +만약 하나의 `src` 디렉터리에서 하나의 `dst` 디렉터리로 많은 파일이 복사되어야 한다면, +`src` 필드에 와일드카드를 사용할 수 있다. +이 경우, `dst` 필드에는 단일 파일의 경로가 아니라 디렉터리의 경로를 명시해야 한다. +예시는 다음과 같다. + +```yaml + files: + - src: gen-compdocs/build/kubeadm*.md + dst: content/en/docs/reference/setup-tools/kubeadm/generated/ +``` + +## `update-imported-docs` 도구 실행하기 {#Running-the-update-imported-docs-tool} + +다음과 같이 `update-imported-docs` 도구를 실행할 수 있다. + +```shell +cd /update-imported-docs +./update-imported-docs +``` + +예를 들면 다음과 같다. + +```shell +./update-imported-docs reference.yml 1.17 +``` + + +## 링크 업데이트하기 {#Fixing-Links} + +`release.yml` 환경설정 파일은 상대경로 링크를 수정하는 방법을 포함하고 있다. +임포트하는 파일 안에 있는 상대경로 링크를 수정하려면, `gen-absolute-links` 필드를 +`true` 로 명시한다. 이에 대한 예시는 +[`release.yml`](https://github.com/kubernetes/website/blob/main/update-imported-docs/release.yml) 에서 볼 수 있다. + +## `kubernetes/website` 의 변경사항을 커밋하기 {#Adding-and-committing-changes-in-kubernetes-website} + +다음의 명령을 실행하여, 스크립트에 의해 생성된 뒤 `` 아래에 복사된 파일의 목록을 볼 수 있다. + +```shell +cd +git status +``` + +위의 명령을 실행하면 새로 추가된 파일과 수정된 파일의 목록을 볼 수 있다. +아래의 결과 예시는 업스트림 소스코드의 변경사항에 따라 다르게 나타날 수 있다. + +### 생성된 구성요소 도구 레퍼런스 {#Generated-component-tool-files} + +``` +content/en/docs/reference/command-line-tools-reference/cloud-controller-manager.md +content/en/docs/reference/command-line-tools-reference/kube-apiserver.md +content/en/docs/reference/command-line-tools-reference/kube-controller-manager.md +content/en/docs/reference/command-line-tools-reference/kube-proxy.md +content/en/docs/reference/command-line-tools-reference/kube-scheduler.md +content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm.md +content/en/docs/reference/kubectl/kubectl.md +``` + +### 생성된 kubectl 명령어 레퍼런스 {#Generated-kubectl-command-reference-files} + +``` +static/docs/reference/generated/kubectl/kubectl-commands.html +static/docs/reference/generated/kubectl/navData.js +static/docs/reference/generated/kubectl/scroll.js +static/docs/reference/generated/kubectl/stylesheet.css +static/docs/reference/generated/kubectl/tabvisibility.js +static/docs/reference/generated/kubectl/node_modules/bootstrap/dist/css/bootstrap.min.css +static/docs/reference/generated/kubectl/node_modules/highlight.js/styles/default.css +static/docs/reference/generated/kubectl/node_modules/jquery.scrollto/jquery.scrollTo.min.js +static/docs/reference/generated/kubectl/node_modules/jquery/dist/jquery.min.js +static/docs/reference/generated/kubectl/css/font-awesome.min.css +``` + +### 생성된 쿠버네티스 API 레퍼런스 와 파일 {#Generated-Kubernetes-API-reference-directories-and-files} + +``` +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/index.html +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/navData.js +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/scroll.js +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/js/query.scrollTo.min.js +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/font-awesome.min.css +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/bootstrap.min.css +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/css/stylesheet.css +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/FontAwesome.otf +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.eot +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.svg +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.ttf +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff +static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fontawesome-webfont.woff2 +``` + +`git add` 와 `git commit` 명령을 실행하여 추가/변경된 파일을 커밋한다. + +## 풀 리퀘스트 만들기 {#Creating-a-pull-request} + +`kubernetes/website` 저장소에 풀 리퀘스트를 등록한다. +등록한 풀 리퀘스트를 모니터하고, 리뷰 커멘트가 달리면 그에 대해 대응을 한다. +풀 리퀘스트가 머지될 때 까지 계속 모니터한다. + +풀 리퀘스트가 머지된 뒤 몇 분이 지나면, +변경사항을 +[쿠버네티스 문서 홈페이지](/docs/home/)에서 확인할 수 있다. + + + +## {{% heading "whatsnext" %}} + + +수동으로 빌드 저장소를 설정하고 빌드 타겟을 실행하여 개별 레퍼런스 문서를 생성하려면, +다음의 가이드를 참고한다. + +* [쿠버네티스 구성요소와 도구에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubernetes-components/) +* [kubectl 명령어에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubectl/) +* [쿠버네티스 API에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubernetes-api/) + + diff --git a/content/ko/docs/contribute/localization_ko.md b/content/ko/docs/contribute/localization_ko.md index fe506a7bb1..e2e10f01cc 100644 --- a/content/ko/docs/contribute/localization_ko.md +++ b/content/ko/docs/contribute/localization_ko.md @@ -133,7 +133,7 @@ weight: 10 ### API 오브젝트 용어 한글화 방침 일반적으로 `kubectl api-resources` 결과의 `kind` 에 해당하는 API 오브젝트는 -[국립국어원 외래어 표기법](http://kornorms.korean.go.kr/regltn/regltnView.do?regltn_code=0003#a)에 +[국립국어원 외래어 표기법](https://kornorms.korean.go.kr/regltn/regltnView.do?regltn_code=0003#a)에 따라 한글로 표기하고 영문을 병기한다. 예를 들면 다음과 같다. API 오브젝트(kind) | 한글화(외래어 표기 및 영문 병기) diff --git a/content/ko/docs/contribute/new-content/open-a-pr.md b/content/ko/docs/contribute/new-content/open-a-pr.md index 8697159261..a1f0178b3c 100644 --- a/content/ko/docs/contribute/new-content/open-a-pr.md +++ b/content/ko/docs/contribute/new-content/open-a-pr.md @@ -123,11 +123,11 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우, ```bash origin git@github.com:/website.git (fetch) origin git@github.com:/website.git (push) - upstream https://github.com/kubernetes/website (fetch) - upstream https://github.com/kubernetes/website (push) + upstream https://github.com/kubernetes/website.git (fetch) + upstream https://github.com/kubernetes/website.git (push) ``` -6. 포크의 `origin/master` 와 `kubernetes/website` 의 `upstream/master` 에서 커밋을 가져온다. +6. 포크의 `origin/main` 와 `kubernetes/website` 의 `upstream/main` 에서 커밋을 가져온다. ```bash git fetch origin @@ -137,15 +137,15 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우, 이를 통해 변경을 시작하기 전에 로컬 리포지터리가 최신 상태인지 확인한다. {{< note >}} - 이 워크플로는 [쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)와 다르다. 포크에 업데이트를 푸시하기 전에 로컬의 `master` 복사본을 `upstream/master` 와 병합할 필요가 없다. + 이 워크플로는 [쿠버네티스 커뮤니티 GitHub 워크플로](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md)와 다르다. 포크에 업데이트를 푸시하기 전에 로컬의 `main` 복사본을 `upstream/main` 와 병합할 필요가 없다. {{< /note >}} ### 브랜치 만들기 1. 작업할 브랜치 기반을 결정한다. - - 기존 콘텐츠를 개선하려면, `upstream/master` 를 사용한다. - - 기존 기능에 대한 새로운 콘텐츠를 작성하려면, `upstream/master` 를 사용한다. + - 기존 콘텐츠를 개선하려면, `upstream/main` 를 사용한다. + - 기존 기능에 대한 새로운 콘텐츠를 작성하려면, `upstream/main` 를 사용한다. - 현지화된 콘텐츠의 경우, 현지화 규칙을 사용한다. 자세한 내용은 [쿠버네티스 문서 현지화](/ko/docs/contribute/localization_ko/)를 참고한다. - 다가오는 쿠버네티스 릴리스의 새로운 기능에 대해서는 기능 브랜치(feature branch)를 사용한다. 자세한 정보는 [릴리스 문서화](/docs/contribute/new-content/new-features/)를 참고한다. - 콘텐츠 재구성과 같이 여러 SIG Docs 기여자들이 협업하는 장기적인 작업에는, @@ -154,10 +154,10 @@ git에 익숙하거나, 변경 사항이 몇 줄보다 클 경우, 브랜치 선택에 도움이 필요하면, 슬랙 채널 `#sig-docs` 에 문의한다. -2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다. 이 예에서는 기본 브랜치가 `upstream/master` 라고 가정한다. +2. 1단계에서 식별된 브랜치를 기반으로 새 브랜치를 작성한다. 이 예에서는 기본 브랜치가 `upstream/main` 라고 가정한다. ```bash - git checkout -b upstream/master + git checkout -b upstream/main ``` 3. 텍스트 편집기를 사용하여 변경한다. @@ -264,7 +264,7 @@ website의 컨테이너 이미지를 만들거나 Hugo를 로컬에서 실행할 또는, 컴퓨터에 `hugo` 명령을 설치하여 사용한다. -1. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/master/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다. +1. [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml)에 지정된 [Hugo](https://gohugo.io/getting-started/installing/) 버전을 설치한다. 2. website 리포지터리를 업데이트하지 않았다면, `website/themes/docsy` 디렉터리가 비어 있다. 테마의 로컬 복제본이 없으면 사이트를 빌드할 수 없다. website 테마를 업데이트하려면, 다음을 실행한다. @@ -372,11 +372,11 @@ PR을 연 후, GitHub는 자동 테스트를 실행하고 [Netlify](https://www. git push --force-with-lease origin ``` -2. `kubernetes/website` 의 `upstream/master` 에 대한 변경 사항을 가져오고 브랜치를 리베이스한다. +2. `kubernetes/website` 의 `upstream/main` 에 대한 변경 사항을 가져오고 브랜치를 리베이스한다. ```bash git fetch upstream - git rebase upstream/master + git rebase upstream/main ``` 3. 리베이스의 결과를 검사한다. diff --git a/content/ko/docs/contribute/new-content/overview.md b/content/ko/docs/contribute/new-content/overview.md index 5c8f6569da..540f1e6c12 100644 --- a/content/ko/docs/contribute/new-content/overview.md +++ b/content/ko/docs/contribute/new-content/overview.md @@ -42,7 +42,7 @@ CLA에 서명하지 않은 기여자의 풀 리퀘스트(pull request)는 자동 시나리오 | 브랜치 :---------|:------------ -현재 릴리스의 기존 또는 새로운 영어 콘텐츠 | `master` +현재 릴리스의 기존 또는 새로운 영어 콘텐츠 | `main` 기능 변경 릴리스의 콘텐츠 | `dev-` 패턴을 사용하여 기능 변경이 있는 주 버전과 부 버전에 해당하는 브랜치. 예를 들어, `v{{< skew nextMinorVersion >}}` 에서 기능이 변경된 경우, ``dev-{{< skew nextMinorVersion >}}`` 에 문서 변경을 추가한다. 다른 언어로된 콘텐츠(현지화) | 현지화 규칙을 사용. 자세한 내용은 [현지화 브랜치 전략](/docs/contribute/localization/#branching-strategy)을 참고한다. @@ -60,6 +60,6 @@ PR 당 하나의 언어로 풀 리퀘스트를 제한한다. 여러 언어로 ## 기여자를 위한 도구들 -`kubernetes/website` 리포지터리의 [문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/master/content/en/docs/doc-contributor-tools) 디렉터리에는 기여 여정이 좀 더 순조롭게 진행되도록 도와주는 도구들이 포함되어 있다. +`kubernetes/website` 리포지터리의 [문서 기여자를 위한 도구](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) 디렉터리에는 기여 여정이 좀 더 순조롭게 진행되도록 도와주는 도구들이 포함되어 있다. diff --git a/content/ko/docs/contribute/participate/_index.md b/content/ko/docs/contribute/participate/_index.md index ef271ca31c..c2d9aed771 100644 --- a/content/ko/docs/contribute/participate/_index.md +++ b/content/ko/docs/contribute/participate/_index.md @@ -73,8 +73,8 @@ GitHub의 SIG Docs [팀]에는 두 분류가 있다. - approve 이 두 플러그인은 `kubernetes/website` GitHub 리포지터리 최상위 수준에 있는 -[OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS)와 -[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) +[OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS)와 +[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) 파일을 사용해서 해당 리포지터리에 대해 prow가 작동하는 방식을 제어한다. @@ -94,7 +94,7 @@ PR 소유자에게 조언하는데 활용된다. ## 병합 작업 방식 풀 리퀘스트 요청이 콘텐츠를 발행하는데 사용하는 -브랜치에 병합되면, 해당 콘텐츠는 http://kubernetes.io 에 공개된다. 게시된 콘텐츠의 +브랜치에 병합되면, 해당 콘텐츠는 https://kubernetes.io 에 공개된다. 게시된 콘텐츠의 품질을 높히기 위해 SIG Docs 승인자가 풀 리퀘스트를 병합하는 것을 제한한다. 작동 방식은 다음과 같다. diff --git a/content/ko/docs/contribute/participate/pr-wranglers.md b/content/ko/docs/contribute/participate/pr-wranglers.md index 30c0979969..674696ee90 100644 --- a/content/ko/docs/contribute/participate/pr-wranglers.md +++ b/content/ko/docs/contribute/participate/pr-wranglers.md @@ -19,7 +19,7 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다. - 매일 새로 올라오는 이슈를 심사하고 태그를 지정한다. SIG Docs가 메타데이터를 사용하는 방법에 대한 지침은 [이슈 심사 및 분류](/ko/docs/contribute/review/for-approvers/#이슈-심사와-분류)를 참고한다. - [스타일](/docs/contribute/style/style-guide/)과 [콘텐츠](/docs/contribute/style/content-guide/) 가이드를 준수하는지에 대해 [열린(open) 풀 리퀘스트](https://github.com/kubernetes/website/pulls)를 매일 리뷰한다. - 가장 작은 PR(`size/XS`)부터 시작하고, 가장 큰(`size/XXL`) PR까지 리뷰한다. 가능한 한 많은 PR을 리뷰한다. -- PR 기여자들이 [CLA]()에 서명했는지 확인한다. +- PR 기여자들이 [CLA](https://github.com/kubernetes/community/blob/master/CLA.md)에 서명했는지 확인한다. - CLA에 서명하지 않은 기여자에게 CLA에 서명하도록 알리려면 [이](https://github.com/zparnold/k8s-docs-pr-botherer) 스크립트를 사용한다. - 제안된 변경 사항에 대한 피드백을 제공하고 다른 SIG의 멤버에게 기술 리뷰를 요청한다. - 제안된 콘텐츠 변경에 대해 PR에 인라인 제안(inline suggestion)을 제공한다. @@ -45,8 +45,8 @@ PR 랭글러는 일주일 간 매일 다음의 일을 해야 한다. 지정한다. 콘텐츠에 대한 작업이 필요하다면, 제안하거나 인라인 피드백을 추가한다. - [LGTM 보유, 문서 승인 필요](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge%2Fwork-in-progress+-label%3Ado-not-merge%2Fhold+label%3Alanguage%2Fen+label%3Algtm+): 병합을 위해 `/approve` 코멘트가 필요한 PR을 나열한다. -- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다) -- [메인 브랜치이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amaster): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @` 을 사용하여 [문서 릴리스 관리자](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles)를 할당한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다. +- [퀵윈(Quick Wins)](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amain+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22): 명확한 결격 사유가 없는 메인 브랜치에 대한 PR을 나열한다. ([XS, S, M, L, XL, XXL] 크기의 PR을 작업할 때 크기 레이블에서 "XS"를 변경한다) +- [메인 브랜치이외의 브랜치에 대한 PR](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3Alanguage%2Fen+-base%3Amain): `dev-` 브랜치에 대한 것일 경우, 곧 출시될 예정인 릴리스이다. `/assign @` 을 사용하여 [문서 릴리스 관리자](https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles)를 할당한다. 오래된 브랜치에 대한 PR인 경우, PR 작성자가 가장 적합한 브랜치를 대상으로 하고 있는지 여부를 파악할 수 있도록 도와준다. ### 랭글러를 위한 유용한 Prow 명령어 diff --git a/content/ko/docs/contribute/participate/roles-and-responsibilities.md b/content/ko/docs/contribute/participate/roles-and-responsibilities.md index 448502c0c3..ad27eea6ff 100644 --- a/content/ko/docs/contribute/participate/roles-and-responsibilities.md +++ b/content/ko/docs/contribute/participate/roles-and-responsibilities.md @@ -29,7 +29,7 @@ GitHub 계정을 가진 누구나 쿠버네티스에 기여할 수 있다. SIG D 이슈를 올린다. - 풀 리퀘스트에 대해 구속력 없는 피드백을 제공한다. - 현지화에 기여한다. -- [슬랙](http://slack.k8s.io/) 또는 +- [슬랙](https://slack.k8s.io/) 또는 [SIG docs 메일링 리스트](https://groups.google.com/forum/#!forum/kubernetes-sig-docs)에 개선을 제안한다. [CLA에 서명](/ko/docs/contribute/new-content/overview/#sign-the-cla) 후에 누구나 다음을 할 수 있다. @@ -144,14 +144,14 @@ LGTM은 "Looks good to me"의 약자이며 풀 리퀘스트가 기술적으로 지원하려면, 다음을 수행한다. 1. `kubernetes/website` 리포지터리 내 - [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) 파일의 섹션에 + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) 파일의 섹션에 여러분의 GitHub 사용자 이름을 추가하는 풀 리퀘스트를 연다. - - {{< note >}} - 자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-reviews` 에 추가한다. - {{< /note >}} - -1. PR을 하나 이상의 SIG-Docs 승인자(`sig-docs-{language}-owners` 에 + + {{< note >}} + 자신을 추가할 위치가 확실하지 않으면, `sig-docs-ko-reviews` 에 추가한다. + {{< /note >}} + +2. PR을 하나 이상의 SIG-Docs 승인자(`sig-docs-{language}-owners` 에 나열된 사용자 이름)에게 지정한다. 승인되면, SIG Docs 리더가 적당한 GitHub 팀에 여러분을 추가한다. 일단 추가되면, @@ -203,7 +203,7 @@ PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리 - 주간 로테이션을 위해 [PR Wrangler 로테이션 스케줄](https://github.com/kubernetes/website/wiki/PR-Wranglers)에 참여한다. SIG Docs는 모든 승인자들이 이 로테이션에 참여할 것으로 기대한다. 자세한 내용은 - [PR 랭글러(PR wrangler)](/ko/docs/contribute/participating/pr-wranglers/)를 + [PR 랭글러(PR wrangler)](/ko/docs/contribute/participate/pr-wranglers/)를 참고한다. ## 승인자 되기 @@ -216,7 +216,7 @@ PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리 지원하려면 다음을 수행한다. 1. `kubernetes/website` 리포지터리 내 - [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) + [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) 파일의 섹션에 자신을 추가하는 풀 리퀘스트를 연다. {{< note >}} @@ -231,4 +231,4 @@ PR은 자동으로 병합된다. SIG Docs 승인자는 추가적인 기술 리 ## {{% heading "whatsnext" %}} -- 모든 승인자가 교대로 수행하는 역할인 [PR 랭글러](/ko/docs/contribute/participating/pr-wranglers)에 대해 읽어보기 +- 모든 승인자가 교대로 수행하는 역할인 [PR 랭글러](/ko/docs/contribute/participate/pr-wranglers)에 대해 읽어보기 diff --git a/content/ko/docs/contribute/review/reviewing-prs.md b/content/ko/docs/contribute/review/reviewing-prs.md index f0a164de00..e0b07a79a9 100644 --- a/content/ko/docs/contribute/review/reviewing-prs.md +++ b/content/ko/docs/contribute/review/reviewing-prs.md @@ -18,7 +18,7 @@ weight: 10 - 적합한 코멘트를 남길 수 있도록 [콘텐츠 가이드](/docs/contribute/style/content-guide/)와 [스타일 가이드](/docs/contribute/style/style-guide/)를 읽는다. - 쿠버네티스 문서화 커뮤니티의 다양한 - [역할과 책임](/ko/docs/contribute/participating/#역할과-책임)을 이해한다. + [역할과 책임](/ko/docs/contribute/participate/#역할과-책임)을 이해한다. @@ -87,7 +87,7 @@ weight: 10 - PR이 새로운 페이지를 소개하는가? 그렇다면, - 페이지가 올바른 [페이지 콘텐츠 타입](/docs/contribute/style/page-content-types/)과 연관된 Hugo 단축 코드를 사용하는가? - 섹션의 측면 탐색에 페이지가 올바르게 나타나는가? - - 페이지가 [문서 홈](/ko/docs/home/) 목록에 나타나야 하는가? + - 페이지가 [문서 홈](/docs/home/) 목록에 나타나야 하는가? - 변경 사항이 Netlify 미리보기에 표시되는가? 목록, 코드 블록, 표, 메모 및 이미지에 특히 주의한다. ### 기타 diff --git a/content/ko/docs/contribute/style/write-new-topic.md b/content/ko/docs/contribute/style/write-new-topic.md index 7441882615..9bb3376933 100644 --- a/content/ko/docs/contribute/style/write-new-topic.md +++ b/content/ko/docs/contribute/style/write-new-topic.md @@ -172,4 +172,4 @@ kubectl create -f https://k8s.io/examples/pods/storage/gce-volume.yaml ## {{% heading "whatsnext" %}} * [페이지 콘텐츠 타입 사용](/docs/contribute/style/page-content-types/)에 대해 알아보기. -* [풀 리퀘스트 작성](/ko/docs/contribute/new-content/new-content/)에 대해 알아보기. +* [풀 리퀘스트 작성](/ko/docs/contribute/new-content/open-a-pr/)에 대해 알아보기. diff --git a/content/ko/docs/contribute/suggesting-improvements.md b/content/ko/docs/contribute/suggesting-improvements.md index 7dd9f80a71..e10faf6ea8 100644 --- a/content/ko/docs/contribute/suggesting-improvements.md +++ b/content/ko/docs/contribute/suggesting-improvements.md @@ -10,7 +10,7 @@ card: -쿠버네티스 문서에 문제가 있거나, 새로운 내용에 대한 아이디어가 있으면, 이슈를 연다. [GitHub 계정](https://github.com/join)과 웹 브라우저만 있으면 된다. +쿠버네티스 문서의 문제를 발견하거나 새로운 내용에 대한 아이디어가 있으면, 이슈를 연다. [GitHub 계정](https://github.com/join)과 웹 브라우저만 있으면 된다. 대부분의 경우, 쿠버네티스 문서에 대한 새로운 작업은 GitHub의 이슈로 시작된다. 그런 다음 쿠버네티스 기여자는 필요에 따라 이슈를 리뷰, 분류하고 태그를 지정한다. 다음으로, 여러분이나 @@ -22,7 +22,7 @@ card: ## 이슈 열기 -기존 콘텐츠에 대한 개선을 제안하거나, 오류를 발견하면, 이슈를 연다. +기존 콘텐츠에 대한 개선을 제안하고 싶거나 오류를 발견하면, 이슈를 연다. 1. 오른쪽 사이드바에서 **문서에 이슈 생성** 링크를 클릭한다. 그러면 헤더가 미리 채워진 GitHub 이슈 페이지로 리디렉션된다. diff --git a/content/ko/docs/home/supported-doc-versions.md b/content/ko/docs/home/supported-doc-versions.md index 07d33e49b9..35f6f9a1b0 100644 --- a/content/ko/docs/home/supported-doc-versions.md +++ b/content/ko/docs/home/supported-doc-versions.md @@ -7,3 +7,6 @@ card: weight: 10 title: 사용 가능한 문서 버전 --- + +이 웹사이트에서는 쿠버네티스 최신 버전 및 +이전 4개 버전에 대한 문서를 제공하고 있다. diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md index ff1727ffee..55401988b4 100644 --- a/content/ko/docs/reference/_index.md +++ b/content/ko/docs/reference/_index.md @@ -9,6 +9,7 @@ content_type: concept no_list: true --- + 쿠버네티스 문서의 본 섹션에서는 레퍼런스를 다룬다. @@ -21,13 +22,11 @@ no_list: true * [표준 용어집](/ko/docs/reference/glossary/) - 포괄적이고, 표준화 된 쿠버네티스 용어 목록 - - * [쿠버네티스 API 레퍼런스](/docs/reference/kubernetes-api/) * [쿠버네티스 {{< param "version" >}}용 원페이지(One-page) API 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) * [쿠버네티스 API 사용](/ko/docs/reference/using-api/) - 쿠버네티스 API에 대한 개요 * [API 접근 제어](/ko/docs/reference/access-authn-authz/) - 쿠버네티스가 API 접근을 제어하는 방법에 대한 세부사항 -* [잘 알려진 레이블, 어노테이션과 테인트](/docs/reference/kubernetes-api/labels-annotations-taints/) +* [잘 알려진 레이블, 어노테이션과 테인트](/docs/reference/labels-annotations-taints/) ## 공식적으로 지원되는 클라이언트 라이브러리 @@ -39,7 +38,7 @@ no_list: true - [쿠버네티스 Python 클라이언트 라이브러리](https://github.com/kubernetes-client/python) - [쿠버네티스 Java 클라이언트 라이브러리](https://github.com/kubernetes-client/java) - [쿠버네티스 JavaScript 클라이언트 라이브러리](https://github.com/kubernetes-client/javascript) -- [쿠버네티스 Dotnet 클라이언트 라이브러리](https://github.com/kubernetes-client/csharp) +- [쿠버네티스 C# 클라이언트 라이브러리](https://github.com/kubernetes-client/csharp) - [쿠버네티스 Haskell 클라이언트 라이브러리](https://github.com/kubernetes-client/haskell) ## CLI @@ -50,16 +49,39 @@ no_list: true ## 컴포넌트 -* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각 노드에서 구동되는 주요한 *노드 에이전트*. kubelet은 PodSpecs 집합을 가지며 기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다. -* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - 파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 수행하는 REST API. +* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) - 각 +노드에서 구동되는 주요한 에이전트. kubelet은 PodSpecs 집합을 가지며 +기술된 컨테이너가 구동되고 있는지, 정상 작동하는지를 보장한다. +* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) - +파드, 서비스, 레플리케이션 컨트롤러와 같은 API 오브젝트에 대한 검증과 구성을 +수행하는 REST API. * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) - 쿠버네티스에 탑재된 핵심 제어 루프를 포함하는 데몬. -* [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 할 수 있다. +* [kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/) - 간단한 +TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로빈 TCP/UDP 포워딩을 +할 수 있다. * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/) - 가용성, 성능 및 용량을 관리하는 스케줄러. -## 스케줄링 + * [kube-scheduler 정책](/ko/docs/reference/scheduling/policies) + * [kube-scheduler 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일) -* [kube-scheduler 정책](/ko/docs/reference/scheduling/policies) -* [kube-scheduler 프로파일](/docs/reference/scheduling/config#profiles) +## API 설정 + +이 섹션은 쿠버네티스 구성요소 또는 도구를 환경설정하는 데에 사용되는 +"미발표된" API를 다룬다. 이 API들은 사용자나 관리자가 클러스터를 +사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가 +제공하지 않는다. + +* [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/) +* [kube-scheduler 환경설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) +* [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) +* [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/) +* [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/) +* [클라이언트 인증 API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) +* [WebhookAdmission 환경설정 (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/) + +## kubeadm을 위한 API 설정 + +* [v1beta2](/docs/reference/config-api/kubeadm-config.v1beta2/) ## 설계 문서 diff --git a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md index f9bc6a1112..ca06783465 100644 --- a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md @@ -5,14 +5,15 @@ weight: 50 --- + 이것은 서비스 어카운트에 대한 클러스터 관리자 안내서다. 독자는 [쿠버네티스 서비스 어카운트 설정](/docs/tasks/configure-pod-container/configure-service-account/)에 익숙하다고 가정한다. 인증 및 사용자 어카운트에 대한 지원은 아직 준비 중이다. -가끔은 서비스 어카운트를 더 잘 설명하기 위해 준비 중인 기능을 참조한다. - +서비스 어카운트를 더 잘 설명하기 위해, 때때로 미완성 기능이 언급될 수 있다. + ## 사용자 어카운트와 서비스 어카운트 비교 쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을 @@ -48,37 +49,51 @@ weight: 50 파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다. 이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다. - 1. 파드에 `ServiceAccount` 가 없다면, `ServiceAccount` 를 `default` 로 설정한다. - 1. 파드에 참조되는 `ServiceAccount` 가 있도록 하고, 그렇지 않으면 이를 거부한다. - 1. 파드에 `ImagePullSecrets` 이 없는 경우, `ServiceAccount` 의 `ImagePullSecrets` 이 파드에 추가된다. - 1. 파드에 API 접근을 위한 토큰이 포함된 `volume` 을 추가한다. - 1. `/var/run/secrets/kubernetes.io/serviceaccount` 에 마운트된 파드의 각 컨테이너에 `volumeSource` 를 추가한다. +1. 파드에 `ServiceAccount` 가 없다면, `ServiceAccount` 를 `default` 로 설정한다. +1. 이전 단계는 파드에 참조되는 `ServiceAccount` 가 있도록 하고, 그렇지 않으면 이를 거부한다. +1. 서비스어카운트 `automountServiceAccountToken` 와 파드의 `automountServiceAccountToken` 중 어느 것도 `false` 로 설정되어 있지 않다면, API 접근을 위한 토큰이 포함된 `volume` 을 파드에 추가한다. +1. 이전 단계에서 서비스어카운트 토큰을 위한 볼륨이 만들어졌다면, `/var/run/secrets/kubernetes.io/serviceaccount` 에 마운트된 파드의 각 컨테이너에 `volumeSource` 를 추가한다. +1. 파드에 `imagePullSecrets` 이 없는 경우, `ServiceAccount` 의 `imagePullSecrets` 이 파드에 추가된다. #### 바인딩된 서비스 어카운트 토큰 볼륨 -{{< feature-state for_k8s_version="v1.13" state="alpha" >}} -`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면, 서비스 어카운트 어드미션 컨트롤러가 -시크릿 볼륨 대신 프로젝티드 서비스 어카운트 토큰 볼륨을 추가한다. 서비스 어카운트 토큰은 기본적으로 1시간 후에 만료되거나 파드가 삭제된다. [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한 자세한 내용을 참고한다. +{{< feature-state for_k8s_version="v1.21" state="beta" >}} -이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 활성화된 `RootCAConfigMap` 기능 게이트에 따라 다르다. 이 컨피그맵에는 kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들이 포함되어 있다. +`BoundServiceAccountTokenVolume` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되면, +토큰 컨트롤러에 의해 생성된 무기한 서비스 어카운트 토큰을 위해, 서비스 어카운트 어드미션 컨트롤러가 시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다. -1. 파드에 `serviceAccountName`가 없다면, `serviceAccountName`를 - `default`로 설정한다. -1. 파드에 참조되는 `serviceAccountName`가 있도록 하고, 그렇지 않으면 - 이를 거부한다. -1. 파드에 `imagePullSecrets`이 없는 경우, 서비스어카운트의 - `imagePullSecrets`이 파드에 추가된다. -1. 서비스어카운트 `automountServiceAccountToken` 또는 파드의 - `automountServiceAccountToken` 이 `false` 로 설정되지 않은 경우 - 파드에 API 접근 토큰이 포함된 `volume`을 추가한다. -1. 이전 단계에서 서비스어카운트 토큰에 대한 볼륨을 생성한 경우, - `/var/run/secrets/kubernetes.io/serviceaccount`에 마운트된 - 파드의 각 컨테이너에 `volumeSource`를 추가한다. +```yaml +- name: kube-api-access- + projected: + defaultMode: 420 # 0644 + sources: + - serviceAccountToken: + expirationSeconds: 3600 + path: token + - configMap: + items: + - key: ca.crt + path: ca.crt + name: kube-root-ca.crt + - downwardAPI: + items: + - fieldRef: + apiVersion: v1 + fieldPath: metadata.namespace + path: namespace +``` -`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다. -서비스 어카운트 토큰은 1시간 후에 만료되거나 파드가 삭제된다. -[프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한 -자세한 내용을 참조한다. +프로젝티드 볼륨은 세 가지로 구성된다. + +1. kube-apiserver로부터 TokenRequest API를 통해 얻은 서비스어카운트토큰(ServiceAccountToken). 서비스어카운트토큰은 기본적으로 1시간 뒤에, 또는 파드가 삭제될 때 만료된다. 서비스어카운트토큰은 파드에 연결되며 kube-apiserver를 위해 존재한다. +1. kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들을 포함하는 컨피그맵(ConfigMap). 이 기능은 모든 네임스페이스에 "kube-root-ca.crt" 컨피그맵을 게시하는 기능 게이트인 `RootCAConfigMap`에 의해 동작한다. `RootCAConfigMap` 기능 게이트는 1.21에서 GA로 전환되었으며 기본적으로 활성화되어 있다. (이 플래그는 1.22에서 `--feature-gate` 인자에서 제외될 예정이다.) +1. 파드의 네임스페이스를 참조하는 DownwardAPI. + +상세 사항은 [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)을 참고한다. + +`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되어 있지 않은 경우, +위의 프로젝티드 볼륨을 파드 스펙에 추가하여 +시크릿 기반 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 수동으로 옮길 수 있다. ### 토큰 컨트롤러 diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md index 62fb53396c..97262073a1 100644 --- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md @@ -53,17 +53,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `APIPriorityAndFairness` | `false` | 알파 | 1.17 | 1.19 | | `APIPriorityAndFairness` | `true` | 베타 | 1.20 | | | `APIResponseCompression` | `false` | 알파 | 1.7 | 1.15 | -| `APIResponseCompression` | `false` | 베타 | 1.16 | | +| `APIResponseCompression` | `true` | 베타 | 1.16 | | | `APIServerIdentity` | `false` | 알파 | 1.20 | | | `AllowInsecureBackendProxy` | `true` | 베타 | 1.17 | | | `AnyVolumeDataSource` | `false` | 알파 | 1.18 | | | `AppArmor` | `true` | 베타 | 1.4 | | | `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | | -| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | | +| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | 1.20 | +| `BoundServiceAccountTokenVolume` | `true` | 베타 | 1.21 | | +| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | | | `CPUManager` | `false` | 알파 | 1.8 | 1.9 | | `CPUManager` | `true` | 베타 | 1.10 | | -| `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 | -| `CRIContainerLogRotation` | `true` | 베타| 1.11 | | | `CSIInlineVolume` | `false` | 알파 | 1.15 | 1.15 | | `CSIInlineVolume` | `true` | 베타 | 1.16 | - | | `CSIMigration` | `false` | 알파 | 1.14 | 1.16 | @@ -74,7 +74,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 | | `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | | | `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | | -| `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | | +| `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | 1.19 | +| `CSIMigrationAzureFile` | `false` | 베타 | 1.21 | | | `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | | | `CSIMigrationGCE` | `false` | 알파 | 1.14 | 1.16 | | `CSIMigrationGCE` | `false` | 베타 | 1.17 | | @@ -84,13 +85,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | | | `CSIMigrationvSphere` | `false` | 베타 | 1.19 | | | `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | | -| `CSIServiceAccountToken` | `false` | 알파 | 1.20 | | -| `CSIStorageCapacity` | `false` | 알파 | 1.19 | | +| `CSIServiceAccountToken` | `false` | 알파 | 1.20 | 1.20 | +| `CSIServiceAccountToken` | `true` | 베타 | 1.21 | | +| `CSIStorageCapacity` | `false` | 알파 | 1.19 | 1.20 | +| `CSIStorageCapacity` | `true` | 베타 | 1.21 | | | `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | 1.19 | | `CSIVolumeFSGroupPolicy` | `true` | 베타 | 1.20 | | +| `CSIVolumeHealth` | `false` | 알파 | 1.21 | | | `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 | | `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | | -| `CronJobControllerV2` | `false` | 알파 | 1.20 | | +| `CronJobControllerV2` | `false` | 알파 | 1.20 | 1.20 | +| `CronJobControllerV2` | `true` | 베타 | 1.21 | | | `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | | | `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 | | `DefaultPodTopologySpread` | `true` | 베타 | 1.20 | | @@ -98,14 +103,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `DevicePlugins` | `true` | 베타 | 1.10 | | | `DisableAcceleratorUsageMetrics` | `false` | 알파 | 1.19 | 1.19 | | `DisableAcceleratorUsageMetrics` | `true` | 베타 | 1.20 | | -| `DownwardAPIHugePages` | `false` | 알파 | 1.20 | | +| `DownwardAPIHugePages` | `false` | 알파 | 1.20 | 1.20 | +| `DownwardAPIHugePages` | `false` | 베타 | 1.21 | | | `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 | | `DynamicKubeletConfig` | `true` | 베타 | 1.11 | | | `EfficientWatchResumption` | `false` | 알파 | 1.20 | | -| `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 | -| `EndpointSlice` | `false` | 베타 | 1.17 | | -| `EndpointSlice` | `true` | 베타 | 1.18 | | -| `EndpointSliceNodeName` | `false` | 알파 | 1.20 | | | `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 | | `EndpointSliceProxying` | `true` | 베타 | 1.19 | | | `EndpointSliceTerminatingCondition` | `false` | 알파 | 1.20 | | @@ -117,51 +119,54 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 | | `ExpandPersistentVolumes` | `true` | 베타 | 1.11 | | | `ExperimentalHostUserNamespaceDefaulting` | `false` | 베타 | 1.5 | | -| `GenericEphemeralVolume` | `false` | 알파 | 1.19 | | -| `GracefulNodeShutdown` | `false` | 알파 | 1.20 | | +| `GenericEphemeralVolume` | `false` | 알파 | 1.19 | 1.20 | +| `GenericEphemeralVolume` | `true` | 베타 | 1.21 | | +| `GracefulNodeShutdown` | `false` | 알파 | 1.20 | 1.20 | +| `GracefulNodeShutdown` | `true` | 베타 | 1.21 | | | `HPAContainerMetrics` | `false` | 알파 | 1.20 | | | `HPAScaleToZero` | `false` | 알파 | 1.16 | | | `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 | | `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | | -| `IPv6DualStack` | `false` | 알파 | 1.15 | | -| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 | -| `ImmutableEphemeralVolumes` | `true` | 베타 | 1.19 | | +| `IndexedJob` | `false` | 알파 | 1.21 | | +| `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | | +| `IPv6DualStack` | `false` | 알파 | 1.15 | 1.20 | +| `IPv6DualStack` | `true` | 베타 | 1.21 | | | `KubeletCredentialProviders` | `false` | 알파 | 1.20 | | -| `KubeletPodResources` | `true` | 알파 | 1.13 | 1.14 | -| `KubeletPodResources` | `true` | 베타 | 1.15 | | | `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 | -| `LegacyNodeRoleBehavior` | `true` | True | 1.19 | | +| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 | | `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 | | `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | | | `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | | +| `LogarithmicScaleDown` | `false` | 알파 | 1.21 | | +| `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | | | `MixedProtocolLBService` | `false` | 알파 | 1.20 | | +| `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | | +| `NetworkPolicyEndPort` | `false` | 알파 | 1.21 | | | `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 | -| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | | +| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | 1.20 | | `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 | | `NonPreemptingPriority` | `true` | 베타 | 1.19 | | -| `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 | -| `PodDisruptionBudget` | `true` | 베타 | 1.5 | | +| `PodDeletionCost` | `false` | 알파 | 1.21 | | +| `PodAffinityNamespaceSelector` | `false` | 알파 | 1.21 | | | `PodOverhead` | `false` | 알파 | 1.16 | 1.17 | | `PodOverhead` | `true` | 베타 | 1.18 | | +| `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | | | `ProcMountType` | `false` | 알파 | 1.12 | | | `QOSReserved` | `false` | 알파 | 1.11 | | -| `RemainingItemCount` | `false` | 알파 | 1.15 | | +| `RemainingItemCount` | `false` | 알파 | 1.15 | 1.15 | +| `RemainingItemCount` | `true` | 베타 | 1.16 | | | `RemoveSelfLink` | `false` | 알파 | 1.16 | 1.19 | | `RemoveSelfLink` | `true` | 베타 | 1.20 | | -| `RootCAConfigMap` | `false` | 알파 | 1.13 | 1.19 | -| `RootCAConfigMap` | `true` | 베타 | 1.20 | | | `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 | | `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | | | `RunAsGroup` | `true` | 베타 | 1.14 | | -| `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 | -| `SCTPSupport` | `true` | 베타 | 1.19 | | | `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 | | `ServerSideApply` | `true` | 베타 | 1.16 | | -| `ServiceAccountIssuerDiscovery` | `false` | 알파 | 1.18 | 1.19 | -| `ServiceAccountIssuerDiscovery` | `true` | 베타 | 1.20 | | +| `ServiceInternalTrafficPolicy` | `false` | 알파 | 1.21 | | | `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | | +| `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | | | `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 | -| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | | +| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | 1.20 | | `ServiceTopology` | `false` | 알파 | 1.17 | | | `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 | | `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | | @@ -169,17 +174,21 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `StorageVersionAPI` | `false` | 알파 | 1.20 | | | `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 | | `StorageVersionHash` | `true` | 베타 | 1.15 | | -| `Sysctls` | `true` | 베타 | 1.11 | | -| `TTLAfterFinished` | `false` | 알파 | 1.12 | | +| `SuspendJob` | `false` | 알파 | 1.21 | | +| `TTLAfterFinished` | `false` | 알파 | 1.12 | 1.20 | +| `TTLAfterFinished` | `true` | 베타 | 1.21 | | +| `TopologyAwareHints` | `false` | 알파 | 1.21 | | | `TopologyManager` | `false` | 알파 | 1.16 | 1.17 | | `TopologyManager` | `true` | 베타 | 1.18 | | | `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 | | `ValidateProxyRedirects` | `true` | 베타 | 1.14 | | +| `VolumeCapacityPriority` | `false` | 알파 | 1.21 | - | | `WarningHeaders` | `true` | 베타 | 1.19 | | | `WinDSR` | `false` | 알파 | 1.14 | | | `WinOverlay` | `false` | 알파 | 1.14 | 1.19 | | `WinOverlay` | `true` | 베타 | 1.20 | | -| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | | +| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | 1.20 | +| `WindowsEndpointSliceProxying` | `true` | 베타 | 1.21 | | {{< /table >}} ### GA 또는 사용 중단된 기능을 위한 기능 게이트 @@ -200,6 +209,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `BlockVolume` | `false` | 알파 | 1.9 | 1.12 | | `BlockVolume` | `true` | 베타 | 1.13 | 1.17 | | `BlockVolume` | `true` | GA | 1.18 | - | +| `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 | +| `CRIContainerLogRotation` | `true` | 베타 | 1.11 | 1.20 | +| `CRIContainerLogRotation` | `true` | GA | 1.21 | - | | `CSIBlockVolume` | `false` | 알파 | 1.11 | 1.13 | | `CSIBlockVolume` | `true` | 베타 | 1.14 | 1.17 | | `CSIBlockVolume` | `true` | GA | 1.18 | - | @@ -245,12 +257,19 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `EnableAggregatedDiscoveryTimeout` | `true` | 사용중단 | 1.16 | - | | `EnableEquivalenceClassCache` | `false` | 알파 | 1.8 | 1.14 | | `EnableEquivalenceClassCache` | - | 사용중단 | 1.15 | - | +| `EndpointSlice` | `false` | 알파 | 1.16 | 1.16 | +| `EndpointSlice` | `false` | 베타 | 1.17 | 1.17 | +| `EndpointSlice` | `true` | 베타 | 1.18 | 1.20 | +| `EndpointSlice` | `true` | GA | 1.21 | - | +| `EndpointSliceNodeName` | `false` | 알파 | 1.20 | 1.20 | +| `EndpointSliceNodeName` | `true` | GA | 1.21 | - | | `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 | | `ExperimentalCriticalPodAnnotation` | `false` | 사용중단 | 1.13 | - | | `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 | | `EvenPodsSpread` | `true` | 베타 | 1.18 | 1.18 | | `EvenPodsSpread` | `true` | GA | 1.19 | - | | `ExecProbeTimeout` | `true` | GA | 1.20 | - | +| `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - | | `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 | | `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - | | `HugePages` | `false` | 알파 | 1.8 | 1.9 | @@ -258,6 +277,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `HugePages` | `true` | GA | 1.14 | - | | `HyperVContainer` | `false` | 알파 | 1.10 | 1.19 | | `HyperVContainer` | `false` | 사용중단 | 1.20 | - | +| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 | +| `ImmutableEphemeralVolumes` | `true` | 베타 | 1.19 | 1.20 | +| `ImmutableEphemeralVolumes` | `true` | GA | 1.21 | | | `Initializers` | `false` | 알파 | 1.7 | 1.13 | | `Initializers` | - | 사용중단 | 1.14 | - | | `KubeletConfigFile` | `false` | 알파 | 1.8 | 1.9 | @@ -268,11 +290,13 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 | | `KubeletPodResources` | `true` | 베타 | 1.15 | | | `KubeletPodResources` | `true` | GA | 1.20 | | +| `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | - | | `MountContainers` | `false` | 알파 | 1.9 | 1.16 | | `MountContainers` | `false` | 사용중단 | 1.17 | - | | `MountPropagation` | `false` | 알파 | 1.8 | 1.9 | | `MountPropagation` | `true` | 베타 | 1.10 | 1.11 | | `MountPropagation` | `true` | GA | 1.12 | - | +| `NodeDisruptionExclusion` | `true` | GA | 1.21 | - | | `NodeLease` | `false` | 알파 | 1.12 | 1.13 | | `NodeLease` | `true` | 베타 | 1.14 | 1.16 | | `NodeLease` | `true` | GA | 1.17 | - | @@ -281,6 +305,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 | | `PersistentLocalVolumes` | `true` | 베타 | 1.10 | 1.13 | | `PersistentLocalVolumes` | `true` | GA | 1.14 | - | +| `PodDisruptionBudget` | `false` | 알파 | 1.3 | 1.4 | +| `PodDisruptionBudget` | `true` | 베타 | 1.5 | 1.20 | +| `PodDisruptionBudget` | `true` | GA | 1.21 | - | | `PodPriority` | `false` | 알파 | 1.8 | 1.10 | | `PodPriority` | `true` | 베타 | 1.11 | 1.13 | | `PodPriority` | `true` | GA | 1.14 | - | @@ -291,11 +318,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `PodShareProcessNamespace` | `true` | 베타 | 1.12 | 1.16 | | `PodShareProcessNamespace` | `true` | GA | 1.17 | - | | `RequestManagement` | `false` | 알파 | 1.15 | 1.16 | +| `RequestManagement` | - | 사용중단 | 1.17 | - | | `ResourceLimitsPriorityFunction` | `false` | 알파 | 1.9 | 1.18 | | `ResourceLimitsPriorityFunction` | - | 사용중단 | 1.19 | - | | `ResourceQuotaScopeSelectors` | `false` | 알파 | 1.11 | 1.11 | | `ResourceQuotaScopeSelectors` | `true` | 베타 | 1.12 | 1.16 | | `ResourceQuotaScopeSelectors` | `true` | GA | 1.17 | - | +| `RootCAConfigMap` | `false` | 알파 | 1.13 | 1.19 | +| `RootCAConfigMap` | `true` | 베타 | 1.20 | 1.20 | +| `RootCAConfigMap` | `true` | GA | 1.21 | - | | `RotateKubeletClientCertificate` | `true` | 베타 | 1.8 | 1.18 | | `RotateKubeletClientCertificate` | `true` | GA | 1.19 | - | | `RuntimeClass` | `false` | 알파 | 1.12 | 1.13 | @@ -307,12 +338,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 | | `SCTPSupport` | `true` | 베타 | 1.19 | 1.19 | | `SCTPSupport` | `true` | GA | 1.20 | - | +| `ServiceAccountIssuerDiscovery` | `false` | 알파 | 1.18 | 1.19 | +| `ServiceAccountIssuerDiscovery` | `true` | 베타 | 1.20 | 1.20 | +| `ServiceAccountIssuerDiscovery` | `true` | GA | 1.21 | - | | `ServiceAppProtocol` | `false` | 알파 | 1.18 | 1.18 | -| `ServiceAppProtocol` | `true` | 베타 | 1.19 | | +| `ServiceAppProtocol` | `true` | 베타 | 1.19 | 1.19 | | `ServiceAppProtocol` | `true` | GA | 1.20 | - | | `ServiceLoadBalancerFinalizer` | `false` | 알파 | 1.15 | 1.15 | | `ServiceLoadBalancerFinalizer` | `true` | 베타 | 1.16 | 1.16 | | `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - | +| `ServiceNodeExclusion` | `true` | GA | 1.21 | - | | `StartupProbe` | `false` | 알파 | 1.16 | 1.17 | | `StartupProbe` | `true` | 베타 | 1.18 | 1.19 | | `StartupProbe` | `true` | GA | 1.20 | - | @@ -320,7 +355,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `StorageObjectInUseProtection` | `true` | GA | 1.11 | - | | `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 | | `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.18 | -| `StreamingProxyRedirects` | - | 사용중단| 1.19 | - | +| `StreamingProxyRedirects` | - | GA | 1.19 | - | | `SupportIPVSProxyMode` | `false` | 알파 | 1.8 | 1.8 | | `SupportIPVSProxyMode` | `false` | 베타 | 1.9 | 1.9 | | `SupportIPVSProxyMode` | `true` | 베타 | 1.10 | 1.10 | @@ -331,6 +366,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `SupportPodPidsLimit` | `false` | 알파 | 1.10 | 1.13 | | `SupportPodPidsLimit` | `true` | 베타 | 1.14 | 1.19 | | `SupportPodPidsLimit` | `true` | GA | 1.20 | - | +| `Sysctls` | `true` | 베타 | 1.11 | 1.20 | +| `Sysctls` | `true` | GA | 1.21 | | | `TaintBasedEvictions` | `false` | 알파 | 1.6 | 1.12 | | `TaintBasedEvictions` | `true` | 베타 | 1.13 | 1.17 | | `TaintBasedEvictions` | `true` | GA | 1.18 | - | @@ -343,15 +380,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 | `TokenRequestProjection` | `false` | 알파 | 1.11 | 1.11 | | `TokenRequestProjection` | `true` | 베타 | 1.12 | 1.19 | | `TokenRequestProjection` | `true` | GA | 1.20 | - | -| `VolumeSnapshotDataSource` | `false` | 알파 | 1.12 | 1.16 | -| `VolumeSnapshotDataSource` | `true` | 베타 | 1.17 | 1.19 | -| `VolumeSnapshotDataSource` | `true` | GA | 1.20 | - | | `VolumePVCDataSource` | `false` | 알파 | 1.15 | 1.15 | | `VolumePVCDataSource` | `true` | 베타 | 1.16 | 1.17 | | `VolumePVCDataSource` | `true` | GA | 1.18 | - | | `VolumeScheduling` | `false` | 알파 | 1.9 | 1.9 | | `VolumeScheduling` | `true` | 베타 | 1.10 | 1.12 | | `VolumeScheduling` | `true` | GA | 1.13 | - | +| `VolumeSnapshotDataSource` | `false` | 알파 | 1.12 | 1.16 | +| `VolumeSnapshotDataSource` | `true` | 베타 | 1.17 | 1.19 | +| `VolumeSnapshotDataSource` | `true` | GA | 1.20 | - | | `VolumeSubpath` | `true` | GA | 1.10 | - | | `VolumeSubpathEnvExpansion` | `false` | 알파 | 1.14 | 1.14 | | `VolumeSubpathEnvExpansion` | `true` | 베타 | 1.15 | 1.16 | @@ -418,7 +455,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `APIServerIdentity`: 클러스터의 각 API 서버에 ID를 할당한다. - `Accelerators`: 도커 사용 시 Nvidia GPU 지원 활성화한다. - `AdvancedAuditing`: [고급 감사](/docs/tasks/debug-application-cluster/audit/#advanced-audit) 기능을 활성화한다. -- `AffinityInAnnotations`(*사용 중단됨*): [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) +- `AffinityInAnnotations`: [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity) 설정을 활성화한다. - `AllowExtTrafficLocalEndpoints`: 서비스가 외부 요청을 노드의 로컬 엔드포인트로 라우팅할 수 있도록 한다. - `AllowInsecureBackendProxy`: 사용자가 파드 로그 요청에서 kubelet의 @@ -442,9 +479,16 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 `kube-apiserver`를 시작하여 확장 토큰 기능을 끈다. 자세한 내용은 [바운드 서비스 계정 토큰](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)을 확인한다. +- `ControllerManagerLeaderMigration`: HA 클러스터에서 클러스터 오퍼레이터가 + kube-controller-manager의 컨트롤러들을 외부 controller-manager(예를 들면, + cloud-controller-manager)로 다운타임 없이 라이브 마이그레이션할 수 있도록 허용하도록 + [kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration)와 [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager)의 + 리더 마이그레이션(Leader Migration)을 활성화한다. - `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다. [CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다. -- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. +- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며, +컨테이너 당 최대 로그 파일 수 기본값은 5이다. 이 값은 kubelet 환경설정으로 변경할 수 있다. +더 자세한 내용은 [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다. - `CSIBlockVolume`: 외부 CSI 볼륨 드라이버가 블록 스토리지를 지원할 수 있게 한다. 자세한 내용은 [`csi` 원시 블록 볼륨 지원](/ko/docs/concepts/storage/volumes/#csi-원시-raw-블록-볼륨-지원) 문서를 참고한다. @@ -525,6 +569,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `CSIVolumeFSGroupPolicy`: CSI드라이버가 `fsGroupPolicy` 필드를 사용하도록 허용한다. 이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과 권한 수정을 지원하는지 여부를 제어한다. +- `CSIVolumeHealth`: 노드에서의 CSI 볼륨 상태 모니터링 기능을 활성화한다. - `ConfigurableFSGroupPolicy`: 사용자가 파드에 볼륨을 마운트할 때 fsGroups에 대한 볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은 [파드의 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을 @@ -546,7 +591,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 생성된 리소스에서 스키마 기반 유효성 검사를 활성화한다. - `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서 생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다. - 실행 중인 파드 문제를 해결한다. - `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여 [기본 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/#내부-기본-제약)를 수행한다. - `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) @@ -557,28 +601,28 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 hugepages 사용을 활성화한다. - `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을 요청을 활성화하여 커밋하지 않고 유효성 검사, 병합 및 변화를 테스트할 수 있다. -- `DynamicAuditing`(*사용 중단됨*): v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용된다. +- `DynamicAuditing`: v1.19 이전의 버전에서 동적 감사를 활성화하는 데 사용된다. - `DynamicKubeletConfig`: kubelet의 동적 구성을 활성화한다. [kubelet 재구성](/docs/tasks/administer-cluster/reconfigure-kubelet/)을 참고한다. - `DynamicProvisioningScheduling`: 볼륨 토폴로지를 인식하고 PV 프로비저닝을 처리하도록 기본 스케줄러를 확장한다. 이 기능은 v1.12의 `VolumeScheduling` 기능으로 대체되었다. -- `DynamicVolumeProvisioning`(*사용 중단됨*): 파드에 퍼시스턴트 볼륨의 +- `DynamicVolumeProvisioning`: 파드에 퍼시스턴트 볼륨의 [동적 프로비저닝](/ko/docs/concepts/storage/dynamic-provisioning/)을 활성화한다. - `EfficientWatchResumption`: 스토리지에서 생성된 북마크(진행 알림) 이벤트를 사용자에게 전달할 수 있다. 이것은 감시 작업에만 적용된다. -- `EnableAggregatedDiscoveryTimeout` (*사용 중단됨*): 수집된 검색 호출에서 5초 +- `EnableAggregatedDiscoveryTimeout`: 수집된 검색 호출에서 5초 시간 초과를 활성화한다. - `EnableEquivalenceClassCache`: 스케줄러가 파드를 스케줄링할 때 노드의 동등성을 캐시할 수 있게 한다. - `EndpointSlice`: 보다 스케일링 가능하고 확장 가능한 네트워크 엔드포인트에 대한 - 엔드포인트슬라이스(EndpointSlices)를 활성화한다. [엔드포인트슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다. + 엔드포인트슬라이스(EndpointSlices)를 활성화한다. [엔드포인트슬라이스 활성화](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다. - `EndpointSliceNodeName` : 엔드포인트슬라이스 `nodeName` 필드를 활성화한다. - `EndpointSliceProxying`: 활성화되면, 리눅스에서 실행되는 kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다. - [엔드포인트 슬라이스 활성화](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다. + [엔드포인트슬라이스 활성화](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다. - `EndpointSliceTerminatingCondition`: 엔드포인트슬라이스 `terminating` 및 `serving` 조건 필드를 활성화한다. - `EphemeralContainers`: 파드를 실행하기 위한 @@ -598,11 +642,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `ExperimentalCriticalPodAnnotation`: 특정 파드에 *critical* 로 어노테이션을 달아서 [스케줄링이 보장되도록](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/) 한다. 이 기능은 v1.13부터 파드 우선 순위 및 선점으로 인해 사용 중단되었다. -- `ExperimentalHostUserNamespaceDefaultingGate`: 사용자 네임스페이스를 호스트로 +- `ExperimentalHostUserNamespaceDefaulting`: 사용자 네임스페이스를 호스트로 기본 활성화한다. 이것은 다른 호스트 네임스페이스, 호스트 마운트, 권한이 있는 컨테이너 또는 특정 비-네임스페이스(non-namespaced) 기능(예: `MKNODE`, `SYS_MODULE` 등)을 사용하는 컨테이너를 위한 것이다. 도커 데몬에서 사용자 네임스페이스 재 매핑이 활성화된 경우에만 활성화해야 한다. +- `ExternalPolicyForExternalIP`: ExternalTrafficPolicy가 서비스(Service) ExternalIP에 적용되지 않는 버그를 수정한다. - `GCERegionalPersistentDisk`: GCE에서 지역 PD 기능을 활성화한다. - `GenericEphemeralVolume`: 일반 볼륨의 모든 기능을 지원하는 임시, 인라인 볼륨을 활성화한다(타사 스토리지 공급 업체, 스토리지 용량 추적, 스냅샷으로부터 복원 @@ -624,10 +669,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `HyperVContainer`: 윈도우 컨테이너를 위한 [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container) 기능을 활성화한다. -- `IPv6DualStack`: IPv6에 대한 [듀얼 스택](/ko/docs/concepts/services-networking/dual-stack/) - 지원을 활성화한다. - `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을 변경할 수 없는(immutable) 것으로 표시할 수 있다. +- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가 + 완료 횟수를 기반으로 파드 완료를 관리할 수 있도록 한다. +- `IngressClassNamespacedParams`: `IngressClass` 리소스가 네임스페이스 범위로 + 한정된 파라미터를 이용할 수 있도록 한다. 이 기능은 `IngressClass.spec.parameters` 에 + `Scope` 와 `Namespace` 2개의 필드를 추가한다. +- `Initializers`: Initializers 어드미션 플러그인을 사용하여 오브젝트 생성의 + 비동기 조정을 허용한다. +- `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/) + 기능을 활성화한다. - `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서 kubelet 구성을 로드할 수 있다. 자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을 @@ -638,10 +690,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `KubeletPodResources`: kubelet의 파드 리소스 gPRC 엔드포인트를 활성화한다. 자세한 내용은 [장치 모니터링 지원](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md)을 참고한다. +- `KubeletPodResourcesGetAllocatable`: kubelet의 파드 리소스 `GetAllocatableResources` 기능을 활성화한다. + 이 API는 클라이언트가 노드의 여유 컴퓨팅 자원을 잘 파악할 수 있도록, 할당 가능 자원에 대한 정보를 + [자원 할당 보고](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#장치-플러그인-리소스-모니터링)한다. - `LegacyNodeRoleBehavior`: 비활성화되면, 서비스 로드 밸런서 및 노드 중단의 레거시 동작은 `NodeDisruptionExclusion` 과 `ServiceNodeExclusion` 에 의해 제공된 기능별 레이블을 대신하여 `node-role.kubernetes.io/master` 레이블을 무시한다. -- `LocalStorageCapacityIsolation`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와 +- `LocalStorageCapacityIsolation`: + [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)와 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir)의 `sizeLimit` 속성을 사용할 수 있게 한다. - `LocalStorageCapacityIsolationFSQuotaMonitoring`: [로컬 임시 스토리지](/ko/docs/concepts/configuration/manage-resources-containers/)에 @@ -651,24 +707,32 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 프로젝트 쿼터를 사용하여 [emptyDir 볼륨](/ko/docs/concepts/storage/volumes/#emptydir) 스토리지 사용을 모니터링하여 성능과 정확성을 향상시킨다. +- `LogarithmicScaleDown`: 컨트롤러 스케일 다운 시에 파드 타임스탬프를 로그 스케일로 버켓화하여 + 축출할 파드를 반-랜덤하게 선택하는 기법을 활성화한다. - `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜 사용을 활성화한다. -- `MountContainers` (*사용 중단됨*): 호스트의 유틸리티 컨테이너를 볼륨 마운터로 - 사용할 수 있다. +- `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다. - `MountPropagation`: 한 컨테이너에서 다른 컨테이너 또는 파드로 마운트된 볼륨을 공유할 수 있다. 자세한 내용은 [마운트 전파(propagation)](/ko/docs/concepts/storage/volumes/#마운트-전파-propagation)을 참고한다. +- `NamespaceDefaultLabelName`: API 서버로 하여금 모든 네임스페이스에 대해 변경할 수 없는 (immutable) + {{< glossary_tooltip text="레이블" term_id="label" >}} `kubernetes.io/metadata.name`을 설정하도록 한다. (네임스페이스의 이름도 변경 불가) +- `NetworkPolicyEndPort`: 네트워크폴리시(NetworkPolicy) 오브젝트에서 단일 포트를 지정하는 것 대신에 포트 범위를 지정할 수 있도록, `endPort` 필드의 사용을 활성화한다. - `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption` 사용을 활성화한다. - `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다. - `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 `preemptionPolicy` 필드를 활성화한다. - `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이 삭제되지 않도록 한다. +- `PodDeletionCost`: 레플리카셋 다운스케일 시 삭제될 파드의 우선순위를 사용자가 조절할 수 있도록, + [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용) 기능을 활성화한다. - `PersistentLocalVolumes`: 파드에서 `local` 볼륨 유형의 사용을 활성화한다. `local` 볼륨을 요청하는 경우 파드 어피니티를 지정해야 한다. - `PodDisruptionBudget`: [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) 기능을 활성화한다. +- `PodAffinityNamespaceSelector`: [파드 어피니티 네임스페이스 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#네임스페이스-셀렉터) 기능과 + [CrossNamespacePodAffinity](/ko/docs/concepts/policy/resource-quotas/#네임스페이스-간-파드-어피니티-쿼터) 쿼터 범위 기능을 활성화한다. - `PodOverhead`: 파드 오버헤드를 판단하기 위해 [파드오버헤드(PodOverhead)](/ko/docs/concepts/scheduling-eviction/pod-overhead/) 기능을 활성화한다. -- `PodPriority`: [우선 순위](/ko/docs/concepts/configuration/pod-priority-preemption/)를 +- `PodPriority`: [우선 순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)를 기반으로 파드의 스케줄링 취소와 선점을 활성화한다. - `PodReadinessGates`: 파드 준비성 평가를 확장하기 위해 `PodReadinessGate` 필드 설정을 활성화한다. 자세한 내용은 [파드의 준비성 게이트](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)를 @@ -676,6 +740,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `PodShareProcessNamespace`: 파드에서 실행되는 컨테이너 간에 단일 프로세스 네임스페이스를 공유하기 위해 파드에서 `shareProcessNamespace` 설정을 활성화한다. 자세한 내용은 [파드의 컨테이너 간 프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)에서 확인할 수 있다. +- `ProbeTerminationGracePeriod`: 파드의 [프로브-수준 + `terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds) 기능을 활성화한다. + 더 자세한 사항은 [기능개선 제안](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period)을 참고한다. - `ProcMountType`: SecurityContext의 `procMount` 필드를 설정하여 컨테이너의 proc 타입의 마운트를 제어할 수 있다. - `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가 @@ -686,7 +753,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 응답에서 남은 항목 수를 표시하도록 허용한다. - `RemoveSelfLink`: ObjectMeta 및 ListMeta에서 `selfLink` 를 사용하지 않고 제거한다. -- `ResourceLimitsPriorityFunction` (*사용 중단됨*): 입력 파드의 CPU 및 메모리 한도 중 +- `RequestManagement`: 각 API 서버에서 우선 순위 및 공정성으로 요청 동시성을 + 관리할 수 있다. 1.17 이후 `APIPriorityAndFairness` 에서 사용 중단되었다. +- `ResourceLimitsPriorityFunction`: 입력 파드의 CPU 및 메모리 한도 중 하나 이상을 만족하는 노드에 가능한 최저 점수 1을 할당하는 스케줄러 우선 순위 기능을 활성화한다. 의도는 동일한 점수를 가진 노드 사이의 관계를 끊는 것이다. @@ -700,6 +769,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `RotateKubeletClientCertificate`: kubelet에서 클라이언트 TLS 인증서의 로테이션을 활성화한다. 자세한 내용은 [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 참고한다. - `RotateKubeletServerCertificate`: kubelet에서 서버 TLS 인증서의 로테이션을 활성화한다. + 자세한 사항은 + [kubelet 구성](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)을 확인한다. - `RunAsGroup`: 컨테이너의 init 프로세스에 설정된 기본 그룹 ID 제어를 활성화한다. - `RuntimeClass`: 컨테이너 런타임 구성을 선택하기 위해 [런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/) @@ -714,9 +785,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 JWKS URL)를 활성화한다. 자세한 내용은 [파드의 서비스 어카운트 구성](/docs/tasks/configure-pod-container/configure-service-account/#service-account-issuer-discovery)을 참고한다. -- `ServiceAppProtocol`: 서비스와 엔드포인트에서 `AppProtocol` 필드를 활성화한다. -- `ServiceLBNodePortControl`: 서비스에서`spec.allocateLoadBalancerNodePorts` 필드를 - 활성화한다. +- `ServiceAppProtocol`: 서비스와 엔드포인트에서 `appProtocol` 필드를 활성화한다. +- `ServiceInternalTrafficPolicy`: 서비스에서 `internalTrafficPolicy` 필드를 활성화한다. +- `ServiceLBNodePortControl`: 서비스에서 `allocateLoadBalancerNodePorts` 필드를 활성화한다. +- `ServiceLoadBalancerClass`: 서비스에서 `loadBalancerClass` 필드를 활성화한다. 자세한 내용은 + [로드밸런서 구현체의 종류 확인하기](/ko/docs/concepts/services-networking/service/#load-balancer-class)를 참고한다. - `ServiceLoadBalancerFinalizer`: 서비스 로드 밸런서에 대한 Finalizer 보호를 활성화한다. - `ServiceNodeExclusion`: 클라우드 제공자가 생성한 로드 밸런서에서 노드를 제외할 수 있다. "`node.kubernetes.io/exclude-from-external-load-balancers`"로 @@ -725,11 +798,11 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 있도록 한다. 자세한 내용은 [서비스토폴로지(ServiceTopology)](/ko/docs/concepts/services-networking/service-topology/)를 참고한다. -- `SizeMemoryBackedVolumes`: kubelet 지원을 사용하여 메모리 백업 볼륨의 크기를 조정한다. - 자세한 내용은 [volumes](/ko/docs/concepts/storage/volumes)를 참조한다. - `SetHostnameAsFQDN`: 전체 주소 도메인 이름(FQDN)을 파드의 호스트 이름으로 설정하는 기능을 활성화한다. - [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#파드의-sethostnameasfqdn-필드)를 참고한다. + [파드의 `setHostnameAsFQDN` 필드](/ko/docs/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field)를 참고한다. +- `SizeMemoryBackedVolumes`: memory-backed 볼륨(보통 `emptyDir` 볼륨)의 크기 상한을 + 지정할 수 있도록 kubelets를 활성화한다. - `StartupProbe`: kubelet에서 [스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가) 프로브를 활성화한다. @@ -744,12 +817,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 스트리밍 요청의 예로는 `exec`, `attach` 및 `port-forward` 요청이 있다. - `SupportIPVSProxyMode`: IPVS를 사용하여 클러스터 내 서비스 로드 밸런싱을 제공한다. 자세한 내용은 [서비스 프록시](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시)를 참고한다. -- `SupportPodPidsLimit`: 파드의 PID 제한을 지원한다. - `SupportNodePidsLimit`: 노드에서 PID 제한 지원을 활성화한다. `--system-reserved` 및 `--kube-reserved` 옵션의 `pid=` 파라미터를 지정하여 지정된 수의 프로세스 ID가 시스템 전체와 각각 쿠버네티스 시스템 데몬에 대해 예약되도록 할 수 있다. +- `SupportPodPidsLimit`: 파드의 PID 제한에 대한 지원을 활성화한다. +- `SuspendJob`: 잡 중지/재시작 기능을 활성화한다. + 자세한 내용은 [잡 문서](/ko/docs/concepts/workloads/controllers/job/)를 + 참고한다. - `Sysctls`: 각 파드에 설정할 수 있는 네임스페이스 커널 파라미터(sysctl)를 지원한다. 자세한 내용은 [sysctl](/docs/tasks/administer-cluster/sysctl-cluster/)을 참고한다. @@ -765,15 +841,25 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `TokenRequest`: 서비스 어카운트 리소스에서 `TokenRequest` 엔드포인트를 활성화한다. - `TokenRequestProjection`: [`projected` 볼륨](/ko/docs/concepts/storage/volumes/#projected)을 통해 서비스 어카운트 토큰을 파드에 주입할 수 있다. +- `TopologyAwareHints`: 엔드포인트슬라이스(EndpointSlices)에서 토폴로지 힌트 기반 + 토폴로지-어웨어 라우팅을 활성화한다. 자세한 내용은 + [토폴로지 어웨어 힌트](/docs/concepts/services-networking/topology-aware-hints/) + 를 참고한다. - `TopologyManager`: 쿠버네티스의 다른 컴포넌트에 대한 세분화된 하드웨어 리소스 할당을 조정하는 메커니즘을 활성화한다. [노드의 토폴로지 관리 정책 제어](/docs/tasks/administer-cluster/topology-manager/)를 참고한다. +- `ValidateProxyRedirects`: 이 플래그는 API 서버가 동일한 호스트로만 리디렉션되는가를 + 확인해야 하는지 여부를 제어한다. `StreamingProxyRedirects` + 플래그가 활성화된 경우에만 사용된다. +- `VolumeCapacityPriority`: 가용 PV 용량을 기반으로 + 여러 토폴로지에 있는 노드들의 우선순위를 정하는 기능을 활성화한다. - `VolumePVCDataSource`: 기존 PVC를 데이터 소스로 지정하는 기능을 지원한다. - `VolumeScheduling`: 볼륨 토폴로지 인식 스케줄링을 활성화하고 퍼시스턴트볼륨클레임(PVC) 바인딩이 스케줄링 결정을 인식하도록 한다. 또한 `PersistentLocalVolumes` 기능 게이트와 함께 사용될 때 [`local`](/ko/docs/concepts/storage/volumes/#local) 볼륨 유형을 사용할 수 있다. - `VolumeSnapshotDataSource`: 볼륨 스냅샷 데이터 소스 지원을 활성화한다. +- `VolumeSubpath`: 컨테이너에 볼륨의 하위 경로(subpath)를 마운트할 수 있다. - `VolumeSubpathEnvExpansion`: 환경 변수를 `subPath`로 확장하기 위해 `subPathExpr` 필드를 활성화한다. - `WarningHeaders`: API 응답에서 경고 헤더를 보낼 수 있다. @@ -783,12 +869,12 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 - `WindowsGMSA`: 파드에서 컨테이너 런타임으로 GMSA 자격 증명 스펙을 전달할 수 있다. - `WindowsRunAsUserName` : 기본 사용자가 아닌(non-default) 사용자로 윈도우 컨테이너에서 애플리케이션을 실행할 수 있도록 지원한다. 자세한 내용은 - [RunAsUserName 구성](/docs/tasks/configure-pod-container/configure-runasusername)을 + [RunAsUserName 구성](/ko/docs/tasks/configure-pod-container/configure-runasusername/)을 참고한다. - `WindowsEndpointSliceProxying`: 활성화되면, 윈도우에서 실행되는 kube-proxy는 엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여 확장성과 성능을 향상시킨다. - [엔드포인트 슬라이스 활성화하기](/docs/tasks/administer-cluster/enabling-endpointslices/)를 참고한다. + [엔드포인트슬라이스 활성화하기](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다. ## {{% heading "whatsnext" %}} diff --git a/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md index e4c790c491..29e9deee83 100644 --- a/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md +++ b/content/ko/docs/reference/command-line-tools-reference/kube-proxy.md @@ -5,6 +5,7 @@ weight: 30 auto_generated: true --- + + +`kubectl drain` 명령과 같은 kube-apiserver의 클라이언트를 사용하여 +축출 API를 직접 호출해 축출 요청을 할 수 있다. +`Eviction` 오브젝트가 생성되면, API 서버가 파드를 종료한다. + +API를 이용한 축출은 [노드-압박 축출](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)과 동일하지 않다. diff --git a/content/ko/docs/reference/glossary/certificate.md b/content/ko/docs/reference/glossary/certificate.md index b5bc067015..7c40e48795 100644 --- a/content/ko/docs/reference/glossary/certificate.md +++ b/content/ko/docs/reference/glossary/certificate.md @@ -2,7 +2,7 @@ title: 인증서(Certificate) id: certificate date: 2018-04-12 -full_link: /docs/tasks/tls/managing-tls-in-a-cluster/ +full_link: /ko/docs/tasks/tls/managing-tls-in-a-cluster/ short_description: > 암호화된 안전한 파일로 쿠버네티스 클러스터 접근 검증에 사용한다. diff --git a/content/ko/docs/reference/glossary/cloud-controller-manager.md b/content/ko/docs/reference/glossary/cloud-controller-manager.md index ebfa3d926c..d4eb23111b 100644 --- a/content/ko/docs/reference/glossary/cloud-controller-manager.md +++ b/content/ko/docs/reference/glossary/cloud-controller-manager.md @@ -11,10 +11,10 @@ tags: - architecture - operation --- - 클라우드별 컨트롤 로직을 포함하는 쿠버네티스 +클라우드별 컨트롤 로직을 포함하는 쿠버네티스 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}} 컴포넌트이다. 클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, -해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와 상호 작용하는 컴포넌트를 분리할 수 있다. +해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분할 수 있게 해 준다. diff --git a/content/ko/docs/reference/glossary/cluster.md b/content/ko/docs/reference/glossary/cluster.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/configmap.md b/content/ko/docs/reference/glossary/configmap.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/container-env-variables.md b/content/ko/docs/reference/glossary/container-env-variables.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/container.md b/content/ko/docs/reference/glossary/container.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/cronjob.md b/content/ko/docs/reference/glossary/cronjob.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/customresourcedefinition.md b/content/ko/docs/reference/glossary/customresourcedefinition.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/daemonset.md b/content/ko/docs/reference/glossary/daemonset.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/deployment.md b/content/ko/docs/reference/glossary/deployment.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/docker.md b/content/ko/docs/reference/glossary/docker.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/extensions.md b/content/ko/docs/reference/glossary/extensions.md index caf7bfa226..547cd934bc 100644 --- a/content/ko/docs/reference/glossary/extensions.md +++ b/content/ko/docs/reference/glossary/extensions.md @@ -2,7 +2,7 @@ title: 익스텐션(Extensions) id: Extensions date: 2019-02-01 -full_link: /ko/docs/concepts/extend-kubernetes/extend-cluster/#익스텐션 +full_link: /ko/docs/concepts/extend-kubernetes/#익스텐션 short_description: > 익스텐션은 새로운 타입의 하드웨어를 지원하기 위해 쿠버네티스를 확장하고 깊게 통합시키는 소프트웨어 컴포넌트이다. @@ -15,4 +15,4 @@ tags: -대부분의 클러스터 관리자는 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용할 것이다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/extend-cluster/#익스텐션)의 설치가 필요할 것이며, 일부 사용자만 직접 새로운 것을 만들 것이다. +대부분의 클러스터 관리자는 호스트된 쿠버네티스 또는 쿠버네티스의 배포 인스턴스를 사용할 것이다. 그 결과, 대부분의 쿠버네티스 사용자는 [익스텐션](/ko/docs/concepts/extend-kubernetes/#익스텐션)의 설치가 필요할 것이며, 일부 사용자만 직접 새로운 것을 만들 것이다. diff --git a/content/ko/docs/reference/glossary/image.md b/content/ko/docs/reference/glossary/image.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/index.md b/content/ko/docs/reference/glossary/index.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/ingress.md b/content/ko/docs/reference/glossary/ingress.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/init-container.md b/content/ko/docs/reference/glossary/init-container.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/istio.md b/content/ko/docs/reference/glossary/istio.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/job.md b/content/ko/docs/reference/glossary/job.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/kube-controller-manager.md b/content/ko/docs/reference/glossary/kube-controller-manager.md index e327a6c285..f4cf8f1bd2 100644 --- a/content/ko/docs/reference/glossary/kube-controller-manager.md +++ b/content/ko/docs/reference/glossary/kube-controller-manager.md @@ -4,15 +4,15 @@ id: kube-controller-manager date: 2018-04-12 full_link: /docs/reference/command-line-tools-reference/kube-controller-manager/ short_description: > - {{< glossary_tooltip text="컨트롤러" term_id="controller" >}} 프로세스를 실행하는 컨트롤 플레인 컴포넌트. + 컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트. -aka: +aka: tags: - architecture - fundamental --- - {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}를 구동하는 마스터 상의 컴포넌트. + {{< glossary_tooltip text="컨트롤러" term_id="controller" >}} 프로세스를 실행하는 컨트롤 플레인 컴포넌트. - + -논리적으로, 각 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 개별 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다. +논리적으로, 각 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는 분리된 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행된다. diff --git a/content/ko/docs/reference/glossary/kube-proxy.md b/content/ko/docs/reference/glossary/kube-proxy.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/kube-scheduler.md b/content/ko/docs/reference/glossary/kube-scheduler.md index 38562f6087..33f79adf67 100644 --- a/content/ko/docs/reference/glossary/kube-scheduler.md +++ b/content/ko/docs/reference/glossary/kube-scheduler.md @@ -2,7 +2,7 @@ title: kube-scheduler id: kube-scheduler date: 2018-04-12 -full_link: /docs/reference/generated/kube-scheduler/ +full_link: /docs/reference/command-line-tools-reference/kube-scheduler/ short_description: > 노드가 배정되지 않은 새로 생성된 파드를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트. diff --git a/content/ko/docs/reference/glossary/kubectl.md b/content/ko/docs/reference/glossary/kubectl.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/kubernetes-api.md b/content/ko/docs/reference/glossary/kubernetes-api.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/label.md b/content/ko/docs/reference/glossary/label.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/limitrange.md b/content/ko/docs/reference/glossary/limitrange.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/minikube.md b/content/ko/docs/reference/glossary/minikube.md old mode 100755 new mode 100644 index f43966260e..8efe83c0cd --- a/content/ko/docs/reference/glossary/minikube.md +++ b/content/ko/docs/reference/glossary/minikube.md @@ -2,7 +2,7 @@ title: Minikube id: minikube date: 2018-04-12 -full_link: /ko/docs/setup/learning-environment/minikube/ +full_link: /ko/docs/tasks/tools/#minikube short_description: > 로컬에서 쿠버네티스를 실행하기 위한 도구. diff --git a/content/ko/docs/reference/glossary/mirror-pod.md b/content/ko/docs/reference/glossary/mirror-pod.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/name.md b/content/ko/docs/reference/glossary/name.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/namespace.md b/content/ko/docs/reference/glossary/namespace.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/network-policy.md b/content/ko/docs/reference/glossary/network-policy.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/node-pressure-eviction.md b/content/ko/docs/reference/glossary/node-pressure-eviction.md new file mode 100644 index 0000000000..b0984ab807 --- /dev/null +++ b/content/ko/docs/reference/glossary/node-pressure-eviction.md @@ -0,0 +1,24 @@ +--- +title: 노드-압박 축출 +id: node-pressure-eviction +date: 2021-05-13 +full_link: /ko/docs/concepts/scheduling-eviction/node-pressure-eviction/ +short_description: > + 노드-압박 축출은 kubelet이 노드의 자원을 회수하기 위해 + 파드를 능동적으로 중단시키는 절차이다. +aka: +- kubelet eviction +tags: +- operation +--- +노드-압박 축출은 {{}}이 노드의 자원을 회수하기 위해 +파드를 능동적으로 중단시키는 절차이다. + + + +kubelet은 클러스터 노드의 CPU, 메모리, 디스크 공간, 파일시스템 +inode와 같은 자원을 모니터링한다. 이러한 자원 중 하나 이상이 +특정 소모 수준에 도달하면, kubelet은 하나 이상의 파드를 능동적으로 중단시켜 +자원을 회수하고 고갈 상황을 방지할 수 있다. + +노드-압박 축출은 [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)과는 차이가 있다. diff --git a/content/ko/docs/reference/glossary/node.md b/content/ko/docs/reference/glossary/node.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/pod-disruption.md b/content/ko/docs/reference/glossary/pod-disruption.md new file mode 100644 index 0000000000..93a473035c --- /dev/null +++ b/content/ko/docs/reference/glossary/pod-disruption.md @@ -0,0 +1,19 @@ +--- +id: pod-disruption +title: 파드 중단(Disruption) +full_link: /ko/docs/concepts/workloads/pods/disruptions/ +date: 2021-05-12 +short_description: > + 노드에 있는 파드가 자발적 또는 비자발적으로 종료되는 절차 + +aka: +related: + - pod + - container +tags: + - operation +--- + +[파드 중단](/ko/docs/concepts/workloads/pods/disruptions/)은 노드에 있는 파드가 자발적 또는 비자발적으로 종료되는 절차이다. + +자발적 중단은 애플리케이션 소유자 또는 클러스터 관리자가 의도적으로 시작한다. 비자발적 중단은 의도하지 않은 것이며, 노드의 리소스 부족과 같은 피할 수 없는 문제 또는 우발적인 삭제로 인해 트리거될 수 있다. diff --git a/content/ko/docs/reference/glossary/pod-security-policy.md b/content/ko/docs/reference/glossary/pod-security-policy.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/pod.md b/content/ko/docs/reference/glossary/pod.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/qos-class.md b/content/ko/docs/reference/glossary/qos-class.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/rbac.md b/content/ko/docs/reference/glossary/rbac.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/replica-set.md b/content/ko/docs/reference/glossary/replica-set.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/replication-controller.md b/content/ko/docs/reference/glossary/replication-controller.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/resource-quota.md b/content/ko/docs/reference/glossary/resource-quota.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/selector.md b/content/ko/docs/reference/glossary/selector.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/service-account.md b/content/ko/docs/reference/glossary/service-account.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/service.md b/content/ko/docs/reference/glossary/service.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/statefulset.md b/content/ko/docs/reference/glossary/statefulset.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/static-pod.md b/content/ko/docs/reference/glossary/static-pod.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/uid.md b/content/ko/docs/reference/glossary/uid.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/glossary/volume.md b/content/ko/docs/reference/glossary/volume.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/kubectl/_index.md b/content/ko/docs/reference/kubectl/_index.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/reference/kubectl/cheatsheet.md b/content/ko/docs/reference/kubectl/cheatsheet.md index d5870bba30..71fc5a5f27 100644 --- a/content/ko/docs/reference/kubectl/cheatsheet.md +++ b/content/ko/docs/reference/kubectl/cheatsheet.md @@ -212,6 +212,10 @@ kubectl get nodes -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' # 파드 등에 대해 반환된 모든 키의 마침표로 구분된 트리를 생성한다. kubectl get pods -o json | jq -c 'path(..)|[.[]|tostring]|join(".")' + +# 모든 파드에 대해 ENV를 생성한다(각 파드에 기본 컨테이너가 있고, 기본 네임스페이스가 있고, `env` 명령어가 동작한다고 가정). +# `env` 뿐만 아니라 다른 지원되는 명령어를 모든 파드에 실행할 때에도 참고할 수 있다. +for pod in $(kubectl get po --output=jsonpath={.items..metadata.name}); do echo $pod && kubectl exec -it $pod env; done ``` ## 리소스 업데이트 @@ -357,7 +361,7 @@ API 리소스를 탐색하기 위한 다른 작업: ```bash kubectl api-resources --namespaced=true # 네임스페이스를 가지는 모든 리소스 kubectl api-resources --namespaced=false # 네임스페이스를 가지지 않는 모든 리소스 -kubectl api-resources -o name # 모든 리소스의 단순한 (리소스 이름 만) 출력 +kubectl api-resources -o name # 모든 리소스의 단순한 (리소스 이름만) 출력 kubectl api-resources -o wide # 모든 리소스의 확장된 ("wide"로 알려진) 출력 kubectl api-resources --verbs=list,get # "list"와 "get"의 요청 동사를 지원하는 모든 리소스 출력 kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든 리소스 @@ -384,6 +388,9 @@ kubectl api-resources --api-group=extensions # "extensions" API 그룹의 모든 # 클러스터에서 실행 중인 모든 이미지 kubectl get pods -A -o=custom-columns='DATA:spec.containers[*].image' +# `default` 네임스페이스의 모든 이미지를 파드별로 그룹지어 출력 +kubectl get pods --namespace default --output=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image" + # "k8s.gcr.io/coredns:1.6.2" 를 제외한 모든 이미지 kubectl get pods -A -o=custom-columns='DATA:spec.containers[?(@.image!="k8s.gcr.io/coredns:1.6.2")].image' diff --git a/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md index 12b41b1d98..a367c175cb 100644 --- a/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/ko/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -265,7 +265,7 @@ nginx-app 1/1 1 1 2m ``` ```shell -kubectl get po -l run=nginx-app +kubectl get po -l app=nginx-app ``` ``` NAME READY STATUS RESTARTS AGE @@ -279,7 +279,7 @@ deployment "nginx-app" deleted ``` ```shell -kubectl get po -l run=nginx-app +kubectl get po -l app=nginx-app # 아무것도 반환하지 않는다 ``` diff --git a/content/ko/docs/reference/kubectl/kubectl.md b/content/ko/docs/reference/kubectl/kubectl.md index ede8c85457..81e4d3fa74 100644 --- a/content/ko/docs/reference/kubectl/kubectl.md +++ b/content/ko/docs/reference/kubectl/kubectl.md @@ -9,7 +9,7 @@ weight: 30 kubectl은 쿠버네티스 클러스터 관리자를 제어한다. - 자세한 정보는 https://kubernetes.io/docs/reference/kubectl/overview/ 에서 확인한다. + 자세한 정보는 [kubectl 개요](/ko/docs/reference/kubectl/overview/)를 확인한다. ``` kubectl [flags] diff --git a/content/ko/docs/reference/labels-annotations-taints.md b/content/ko/docs/reference/labels-annotations-taints.md new file mode 100644 index 0000000000..0854c1b5cf --- /dev/null +++ b/content/ko/docs/reference/labels-annotations-taints.md @@ -0,0 +1,325 @@ +--- +title: 잘 알려진 레이블, 어노테이션, 테인트(Taint) +content_type: concept +weight: 20 +--- + + + +쿠버네티스는 모든 레이블과 어노테이션을 `kubernetes.io` 네임스페이스 아래에 정의해 놓았다. + +이 문서는 각 값에 대한 레퍼런스를 제공하며, 값을 할당하기 위한 협력 포인트도 제공한다. + + + + + +## kubernetes.io/arch + +예시: `kubernetes.io/arch=amd64` + +적용 대상: 노드 + +Go에 의해 정의된 `runtime.GOARCH` 값을 kubelet이 읽어서 이 레이블의 값으로 채운다. arm 노드와 x86 노드를 혼합하여 사용하는 경우 유용할 수 있다. + +## kubernetes.io/os + +예시: `kubernetes.io/os=linux` + +적용 대상: 노드 + +Go에 의해 정의된 `runtime.GOOS` 값을 kubelet이 읽어서 이 레이블의 값으로 채운다. 클러스터에서 여러 운영체제를 혼합하여 사용(예: 리눅스 및 윈도우 노드)하는 경우 유용할 수 있다. + +## kubernetes.io/metadata.name + +예시: `kubernetes.io/metadata.name=mynamespace` + +적용 대상: 네임스페이스 + +`NamespaceDefaultLabelName` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 +활성화되어 있으면, +쿠버네티스 API 서버가 모든 네임스페이스에 이 레이블을 적용한다. +레이블의 값은 네임스페이스의 이름으로 적용된다. + +레이블 {{< glossary_tooltip text="셀렉터" term_id="selector" >}}를 이용하여 특정 네임스페이스를 지정하고 싶다면 +이 레이블이 유용할 수 있다. + +## beta.kubernetes.io/arch (사용 중단됨) + +이 레이블은 사용 중단되었다. 대신 `kubernetes.io/arch` 을 사용한다. + +## beta.kubernetes.io/os (사용 중단됨) + +이 레이블은 사용 중단되었다. 대신 `kubernetes.io/os` 을 사용한다. + +## kubernetes.io/hostname {#kubernetesiohostname} + +예시: `kubernetes.io/hostname=ip-172-20-114-199.ec2.internal` + +적용 대상: 노드 + +kubelet이 호스트네임을 읽어서 이 레이블의 값으로 채운다. `kubelet` 에 `--hostname-override` 플래그를 전달하여 실제 호스트네임과 다른 값으로 설정할 수도 있다. + +이 레이블은 토폴로지 계층의 일부로도 사용된다. [`topology.kubernetes.io/zone`](#topologykubernetesiozone)에서 세부 사항을 확인한다. + + +## controller.kubernetes.io/pod-deletion-cost {#pod-deletion-cost} + +예시: `controller.kubernetes.io/pod-deletion-cost=10` + +적용 대상: Pod + +이 어노테이션은 레플리카셋(ReplicaSet) 다운스케일 순서를 조정할 수 있는 요소인 [파드 삭제 비용](/ko/docs/concepts/workloads/controllers/replicaset/#파드-삭제-비용)을 +설정하기 위해 사용한다. 명시된 값은 `int32` 타입으로 파싱된다. + +## beta.kubernetes.io/instance-type (사용 중단됨) + +{{< note >}} v1.17부터, [`node.kubernetes.io/instance-type`](#nodekubernetesioinstance-type)으로 대체되었다. {{< /note >}} + +## node.kubernetes.io/instance-type {#nodekubernetesioinstance-type} + +예시: `node.kubernetes.io/instance-type=m3.medium` + +적용 대상: 노드 + +`클라우드 제공자`에 의해 정의된 인스턴스 타입의 값을 kubelet이 읽어서 이 레이블의 값으로 채운다. +`클라우드 제공자`를 사용하는 경우에만 이 레이블이 설정된다. +특정 워크로드를 특정 인스턴스 타입에 할당하고 싶다면 이 레이블이 유용할 수 있다. +하지만 일반적으로는 자원 기반 스케줄링을 수행하는 쿠버네티스 스케줄러를 이용하게 된다. 인스턴스 타입 보다는 특성을 기준으로 스케줄링을 고려해야 한다(예: `g2.2xlarge` 를 요구하기보다는, GPU가 필요하다고 요구한다). + +## failure-domain.beta.kubernetes.io/region (사용 중단됨) {#failure-domainbetakubernetesioregion} + +[`topology.kubernetes.io/region`](#topologykubernetesioregion)을 확인한다. + +{{< note >}} v1.17부터, [`topology.kubernetes.io/region`](#topologykubernetesioregion)으로 대체되었다. {{< /note >}} + +## failure-domain.beta.kubernetes.io/zone (사용 중단됨) {#failure-domainbetakubernetesiozone} + +[`topology.kubernetes.io/zone`](#topologykubernetesiozone)을 확인한다. + +{{< note >}} v1.17부터, [`topology.kubernetes.io/zone`](#topologykubernetesiozone)으로 대체되었다. {{< /note >}} + +## statefulset.kubernetes.io/pod-name {#statefulsetkubernetesiopod-name} + +예시: + +`statefulset.kubernetes.io/pod-name=mystatefulset-7` + +스테이트풀셋(StatefulSet) 컨트롤러가 파드를 위한 스테이트풀셋을 생성하면, 컨트롤 플레인이 파드에 이 레이블을 설정한다. +생성되는 파드의 이름을 이 레이블의 값으로 설정한다. + +스테이트풀셋 문서의 [파드 이름 레이블](/ko/docs/concepts/workloads/controllers/statefulset/#파드-이름-레이블)에서 +상세 사항을 확인한다. + +## topology.kubernetes.io/region {#topologykubernetesioregion} + +예시: + +`topology.kubernetes.io/region=us-east-1` + +[`topology.kubernetes.io/zone`](#topologykubernetesiozone)을 확인한다. + +## topology.kubernetes.io/zone {#topologykubernetesiozone} + +예시: + +`topology.kubernetes.io/zone=us-east-1c` + +적용 대상: 노드, 퍼시스턴트볼륨(PersistentVolume) + +노드의 경우: `클라우드 제공자`가 제공하는 값을 이용하여 `kubelet` 또는 외부 `cloud-controller-manager`가 이 어노테이션의 값을 설정한다. `클라우드 제공자`를 사용하는 경우에만 이 레이블이 설정된다. 하지만, 토폴로지 내에서 의미가 있는 경우에만 이 레이블을 노드에 설정해야 한다. + +퍼시스턴트볼륨의 경우: 토폴로지 어웨어 볼륨 프로비저너가 자동으로 퍼시스턴트볼륨에 노드 어피니티 제약을 설정한다. + +영역(zone)은 논리적 고장 도메인을 나타낸다. 가용성 향상을 위해 일반적으로 쿠버네티스 클러스터는 여러 영역에 걸쳐 구성된다. 영역에 대한 정확한 정의는 사업자 별 인프라 구현에 따라 다르지만, 일반적으로 영역은 '영역 내 매우 낮은 네트워크 지연시간, 영역 내 네트워크 트래픽 비용 없음, 다른 영역의 고장에 독립적임' 등의 공통적인 특성을 갖는다. 예를 들어, 같은 영역 내의 노드는 하나의 네트워크 스위치를 공유하여 활용할 수 있으며, 반대로 다른 영역에 있는 노드는 하나의 네트워크 스위치를 공유해서는 안 된다. + +지역(region)은 하나 이상의 영역으로 구성된 더 큰 도메인을 나타낸다. 쿠버네티스 클러스터가 여러 지역에 걸쳐 있는 경우는 드물다. 영역이나 지역에 대한 정확한 정의는 사업자 별 인프라 구현에 따라 다르지만, 일반적으로 지역은 '지역 내 네트워크 지연시간보다 지역 간 네트워크 지연시간이 큼, 지역 간 네트워크 트래픽은 비용이 발생함, 다른 영역/지역의 고장에 독립적임' 등의 공통적인 특성을 갖는다. 예를 들어, 같은 지역 내의 노드는 전력 인프라(예: UPS 또는 발전기)를 공유하여 활용할 수 있으며, 반대로 다른 지역에 있는 노드는 일반적으로 전력 인프라를 공유하지 않는다. + +쿠버네티스는 영역과 지역의 구조에 대해 다음과 같이 가정한다. +1) 지역과 영역은 계층적이다. 영역은 지역의 엄격한 부분집합(strict subset)이며, 하나의 영역이 두 개의 지역에 속할 수는 없다. +2) 영역 이름은 모든 지역에 걸쳐서 유일하다. 예를 들어, "africa-east-1" 라는 지역은 "africa-east-1a" 와 "africa-east-1b" 라는 영역으로 구성될 수 있다. + +토폴로지 레이블이 변경되는 일은 없다고 가정할 수 있다. 일반적으로 레이블의 값은 변경될 수 있지만, 특정 노드가 삭제 후 재생성되지 않고서는 다른 영역으로 이동할 수 없기 때문이다. + +쿠버네티스는 이 정보를 다양한 방식으로 활용할 수 있다. 예를 들어, 단일 영역 클러스터에서는 스케줄러가 자동으로 레플리카셋의 파드를 여러 노드에 퍼뜨린다(노드 고장의 영향을 줄이기 위해 - [`kubernetes.io/hostname`](#kubernetesiohostname) 참고). 복수 영역 클러스터에서는, 여러 영역에 퍼뜨린다(영역 고장의 영향을 줄이기 위해). 이는 _SelectorSpreadPriority_ 를 통해 실현된다. + +_SelectorSpreadPriority_ 는 최선 노력(best effort) 배치 방법이다. 클러스터가 위치한 영역들의 특성이 서로 다르다면(예: 노드 숫자가 다름, 노드 타입이 다름, 파드 자원 요구사항이 다름), 파드 숫자를 영역별로 다르게 하여 배치할 수 있다. 필요하다면, 영역들의 특성(노드 숫자/타입)을 일치시켜 불균형 배치의 가능성을 줄일 수 있다. + +스케줄러도 (_VolumeZonePredicate_ 표시자를 이용하여) '파드가 요청하는 볼륨'이 위치하는 영역과 같은 영역에 파드를 배치한다. 여러 영역에서 볼륨에 접근할 수는 없다. + +`PersistentVolumeLabel`이 퍼시스턴트볼륨의 자동 레이블링을 지원하지 않는다면, 레이블을 수동으로 추가하거나 `PersistentVolumeLabel`이 동작하도록 변경할 수 있다. +`PersistentVolumeLabel`이 설정되어 있으면, 스케줄러는 파드가 다른 영역에 있는 볼륨에 마운트하는 것을 막는다. 만약 사용 중인 인프라에 이러한 제약이 없다면, 볼륨에 영역 레이블을 추가할 필요가 전혀 없다. + +## node.kubernetes.io/windows-build {#nodekubernetesiowindows-build} + +예시: `node.kubernetes.io/windows-build=10.0.17763` + +적용 대상: 노드 + +kubelet이 Microsoft 윈도우에서 실행되고 있다면, 사용 중인 Windows Server 버전을 기록하기 위해 kubelet이 노드에 이 레이블을 추가한다. + +이 레이블의 값은 "MajorVersion.MinorVersion.BuildNumber"의 형태를 갖는다. + +## service.kubernetes.io/headless {#servicekubernetesioheadless} + +예시: `service.kubernetes.io/headless=""` + +적용 대상: 서비스 + +서비스가 헤드리스(headless)이면, 컨트롤 플레인이 엔드포인트(Endpoints) 오브젝트에 이 레이블을 추가한다. + +## kubernetes.io/service-name {#kubernetesioservice-name} + +예시: `kubernetes.io/service-name="nginx"` + +적용 대상: 서비스 + +쿠버네티스가 여러 서비스를 구분하기 위해 이 레이블을 사용한다. 현재는 `ELB`(Elastic Load Balancer) 를 위해서만 사용되고 있다. + +## endpointslice.kubernetes.io/managed-by {#endpointslicekubernetesiomanaged-by} + +예시: `endpointslice.kubernetes.io/managed-by="controller"` + +적용 대상: 엔드포인트슬라이스(EndpointSlices) + +이 레이블은 엔드포인트슬라이스(EndpointSlice)를 어떤 컨트롤러나 엔티티가 관리하는지를 나타내기 위해 사용된다. 이 레이블을 사용함으로써 한 클러스터 내에서 여러 엔드포인트슬라이스 오브젝트가 각각 다른 컨트롤러나 엔티티에 의해 관리될 수 있다. + +## endpointslice.kubernetes.io/skip-mirror {#endpointslicekubernetesioskip-mirror} + +예시: `endpointslice.kubernetes.io/skip-mirror="true"` + +적용 대상: 엔드포인트(Endpoints) + +특정 자원에 이 레이블을 `"true"` 로 설정하여, EndpointSliceMirroring 컨트롤러가 엔드포인트슬라이스를 이용하여 해당 자원을 미러링하지 않도록 지시할 수 있다. + +## service.kubernetes.io/service-proxy-name {#servicekubernetesioservice-proxy-name} + +예시: `service.kubernetes.io/service-proxy-name="foo-bar"` + +적용 대상: 서비스 + +kube-proxy 에는 커스텀 프록시를 위한 이와 같은 레이블이 있으며, 이 레이블은 서비스 컨트롤을 커스텀 프록시에 위임한다. + +## experimental.windows.kubernetes.io/isolation-type + +예시: `experimental.windows.kubernetes.io/isolation-type: "hyperv"` + +적용 대상: 파드 + +Hyper-V 격리(isolation)를 사용하여 윈도우 컨테이너를 실행하려면 이 어노테이션을 사용한다. Hyper-V 격리 기능을 활성화하고 Hyper-V 격리가 적용된 컨테이너를 생성하기 위해, kubelet은 기능 게이트 `HyperVContainer=true` 로 설정하여 실행되어야 하며, 파드에는 `experimental.windows.kubernetes.io/isolation-type=hyperv` 어노테이션이 설정되어 있어야 한다. + +{{< note >}} +이 어노테이션은 하나의 컨테이너로 구성된 파드에만 설정할 수 있다. +{{< /note >}} + +## ingressclass.kubernetes.io/is-default-class + +예시: `ingressclass.kubernetes.io/is-default-class: "true"` + +적용 대상: 인그레스클래스(IngressClass) + +하나의 인그레스클래스 리소스에 이 어노테이션이 `"true"`로 설정된 경우, 클래스가 명시되지 않은 새로운 인그레스(Ingress) 리소스는 해당 기본 클래스로 할당될 것이다. + +## kubernetes.io/ingress.class (사용 중단됨) + +{{< note >}} +v1.18부터, `spec.ingressClassName`으로 대체되었다. +{{< /note >}} + +## storageclass.kubernetes.io/is-default-class + +예시: `storageclass.kubernetes.io/is-default-class=true` + +적용 대상: 스토리지클래스(StorageClass) + +하나의 스토리지클래스(StorageClass) 리소스에 이 어노테이션이 `"true"`로 설정된 경우, +클래스가 명시되지 않은 새로운 퍼시스턴트볼륨클레임(PersistentVolumeClaim) 리소스는 해당 기본 클래스로 할당될 것이다. + +## alpha.kubernetes.io/provided-node-ip + +예시: `alpha.kubernetes.io/provided-node-ip: "10.0.0.1"` + +적용 대상: 노드 + +kubelet이 노드에 할당된 IPv4 주소를 명시하기 위해 이 어노테이션을 사용할 수 있다. + +kubelet이 "외부" 클라우드 제공자에 의해 실행되었다면, 명령줄 플래그(`--node-ip`)를 통해 설정된 IP 주소를 명시하기 위해 kubelet이 이 어노테이션을 노드에 설정한다. cloud-controller-manager는 클라우드 제공자에게 이 IP 주소가 유효한지를 검증한다. + +## batch.kubernetes.io/job-completion-index + +예시: `batch.kubernetes.io/job-completion-index: "3"` + +적용 대상: 파드 + +kube-controller-manager의 잡(Job) 컨트롤러는 +`Indexed` [완료 모드](/ko/docs/concepts/workloads/controllers/job/#완료-모드)로 생성된 파드에 이 어노테이션을 추가한다. + +## kubectl.kubernetes.io/default-container + +예시: `kubectl.kubernetes.io/default-container: "front-end-app"` + +파드의 기본 컨테이너로 사용할 컨테이너 이름을 지정하는 어노테이션이다. 예를 들어, `kubectl logs` 또는 `kubectl exec` 명령을 사용할 때 `-c` 또는 `--container` 플래그를 지정하지 않으면, 이 어노테이션으로 명시된 기본 컨테이너를 대상으로 실행될 것이다. + +## endpoints.kubernetes.io/over-capacity + +예시: `endpoints.kubernetes.io/over-capacity:warning` + +적용 대상: 엔드포인트(Endpoints) + +v1.21 이상의 쿠버네티스 클러스터에서, 엔드포인트(Endpoints) 컨트롤러가 1000개 이상의 엔드포인트를 관리하고 있다면 각 엔드포인트 리소스에 이 어노테이션을 추가한다. 이 어노테이션은 엔드포인트 리소스가 용량 초과 되었음을 나타낸다. + +**이 이후로 나오는 테인트는 모두 '적용 대상: 노드' 이다.** + +## node.kubernetes.io/not-ready + +예시: `node.kubernetes.io/not-ready:NoExecute` + +노드 컨트롤러는 노드의 헬스를 모니터링하여 노드가 사용 가능한 상태인지를 감지하고 그에 따라 이 테인트를 추가하거나 제거한다. + +## node.kubernetes.io/unreachable + +예시: `node.kubernetes.io/unreachable:NoExecute` + +노드 컨트롤러는 [노드 컨디션](/ko/docs/concepts/architecture/nodes/#condition)이 `Ready`에서 `Unknown`으로 변경된 노드에 이 테인트를 추가한다. + +## node.kubernetes.io/unschedulable + +예시: `node.kubernetes.io/unschedulable:NoSchedule` + +경쟁 상태(race condition) 발생을 막기 위해, 생성 중인 노드에 이 테인트가 추가된다. + +## node.kubernetes.io/memory-pressure + +예시: `node.kubernetes.io/memory-pressure:NoSchedule` + +kubelet은 노드의 `memory.available`와 `allocatableMemory.available`을 관측하여 메모리 압박을 감지한다. 그 뒤, 관측한 값을 kubelet에 설정된 문턱값(threshold)과 비교하여 노드 컨디션과 테인트의 추가/삭제 여부를 결정한다. + +## node.kubernetes.io/disk-pressure + +예시: `node.kubernetes.io/disk-pressure:NoSchedule` + +kubelet은 노드의 `imagefs.available`, `imagefs.inodesFree`, `nodefs.available`, `nodefs.inodesFree`(리눅스에 대해서만)를 관측하여 디스크 압박을 감지한다. 그 뒤, 관측한 값을 kubelet에 설정된 문턱값(threshold)과 비교하여 노드 컨디션과 테인트의 추가/삭제 여부를 결정한다. + +## node.kubernetes.io/network-unavailable + +예시: `node.kubernetes.io/network-unavailable:NoSchedule` + +사용 중인 클라우드 공급자가 추가 네트워크 환경설정을 필요로 한다고 명시하면, kubelet이 이 테인트를 설정한다. 클라우드 상의 네트워크 경로가 올바르게 구성되어야, 클라우드 공급자가 이 테인트를 제거할 것이다. + +## node.kubernetes.io/pid-pressure + +예시: `node.kubernetes.io/pid-pressure:NoSchedule` + +kubelet은 '`/proc/sys/kernel/pid_max`의 크기의 D-값'과 노드에서 쿠버네티스가 사용 중인 PID를 확인하여, `pid.available` 지표라고 불리는 '사용 가능한 PID 수'를 가져온다. 그 뒤, 관측한 지표를 kubelet에 설정된 문턱값(threshold)과 비교하여 노드 컨디션과 테인트의 추가/삭제 여부를 결정한다. + +## node.cloudprovider.kubernetes.io/uninitialized + +예시: `node.cloudprovider.kubernetes.io/uninitialized:NoSchedule` + +kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드가 '사용 불가능'한 상태라고 표시하기 위해 이 테인트가 추가되며, 추후 cloud-controller-manager가 이 노드를 초기화하고 이 테인트를 제거한다. + +## node.cloudprovider.kubernetes.io/shutdown + +예시: `node.cloudprovider.kubernetes.io/shutdown:NoSchedule` + +노드의 상태가 클라우드 공급자가 정의한 'shutdown' 상태이면, 이에 따라 노드에 `node.cloudprovider.kubernetes.io/shutdown` 테인트가 `NoSchedule` 값으로 설정된다. diff --git a/content/ko/docs/reference/scheduling/config.md b/content/ko/docs/reference/scheduling/config.md index 7b6942e119..2f46c78d8b 100644 --- a/content/ko/docs/reference/scheduling/config.md +++ b/content/ko/docs/reference/scheduling/config.md @@ -18,12 +18,10 @@ weight: 20 각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한 익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다. -컴포넌트 구성 API([`v1alpha1`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha1?tab=doc#KubeSchedulerConfiguration) -또는 [`v1alpha2`](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1alpha2?tab=doc#KubeSchedulerConfiguration))를 -사용하고, `kube-scheduler --config `을 실행하여 +[KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) +구조에 맞게 파일을 작성하고, +`kube-scheduler --config `을 실행하여 스케줄링 프로파일을 지정할 수 있다. -`v1alpha2` API를 사용하면 [여러 프로파일](#여러-프로파일)을 -실행하도록 kube-scheduler를 구성할 수 있다. 최소 구성은 다음과 같다. @@ -149,7 +147,12 @@ profiles: 익스텐션 포인트: `Score`. - `VolumeBinding`: 노드에 요청된 {{< glossary_tooltip text="볼륨" term_id="volume" >}}이 있는지 또는 바인딩할 수 있는지 확인한다. - 익스텐션 포인트: `PreFilter`, `Filter`, `Reserve`, `PreBind`. + 익스텐션 포인트: `PreFilter`, `Filter`, `Reserve`, `PreBind`, `Score`. + {{< note >}} + `Score` 익스텐션 포인트는 `VolumeCapacityPriority` 기능이 + 활성화되어 있어야 활성화되며, + 요청된 볼륨 사이즈를 만족하는 가장 작은 PV들을 우선순위 매긴다. + {{< /note >}} - `VolumeRestrictions`: 노드에 마운트된 볼륨이 볼륨 제공자에 특정한 제한 사항을 충족하는지 확인한다. 익스텐션 포인트: `Filter`. @@ -247,5 +250,6 @@ profiles: ## {{% heading "whatsnext" %}} -* [kube-scheduler 레퍼런스](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기 +* [kube-scheduler 레퍼런스](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기 * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기 +* [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기 diff --git a/content/ko/docs/reference/scheduling/policies.md b/content/ko/docs/reference/scheduling/policies.md index f2cae65b68..c2b9cbbdff 100644 --- a/content/ko/docs/reference/scheduling/policies.md +++ b/content/ko/docs/reference/scheduling/policies.md @@ -8,9 +8,7 @@ weight: 10 스케줄링 정책을 사용하여 {{< glossary_tooltip text="kube-scheduler" term_id="kube-scheduler" >}}가 각각 노드를 필터링하고 스코어링(scoring)하기 위해 실행하는 *단정(predicates)* 및 *우선순위(priorities)* 를 지정할 수 있다. -`kube-scheduler --policy-config-file ` 또는 `kube-scheduler --policy-configmap `을 실행하고 [정책 유형](https://pkg.go.dev/k8s.io/kube-scheduler@v0.18.0/config/v1?tab=doc#Policy)을 사용하여 스케줄링 정책을 설정할 수 있다. - - +`kube-scheduler --policy-config-file ` 또는 `kube-scheduler --policy-configmap `을 실행하고 [정책 유형](/docs/reference/config-api/kube-scheduler-policy-config.v1/)을 사용하여 스케줄링 정책을 설정할 수 있다. @@ -39,20 +37,6 @@ weight: 10 - `MaxCSIVolumeCount`: 연결해야 하는 {{< glossary_tooltip text="CSI" term_id="csi" >}} 볼륨의 수와 구성된 제한을 초과하는지 여부를 결정한다. -- `CheckNodeMemoryPressure`: 노드가 메모리 압박을 보고하고 있고, 구성된 - 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다. - -- `CheckNodePIDPressure`: 노드가 프로세스 ID 부족을 보고하고 있고, 구성된 - 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다. - -- `CheckNodeDiskPressure`: 노드가 스토리지 압박(파일시스템이 가득차거나 - 거의 꽉 참)을 보고하고 있고, 구성된 예외가 없는 경우, 파드가 해당 노드에 스케줄되지 않는다. - -- `CheckNodeCondition`: 노드는 파일시스템이 완전히 가득찼거나, - 네트워킹을 사용할 수 없거나, kubelet이 파드를 실행할 준비가 되지 않았다고 보고할 수 있다. - 노드에 대해 이러한 조건이 설정되고, 구성된 예외가 없는 경우, 파드가 - 해당 노드에 스케줄되지 않는다. - - `PodToleratesNodeTaints`: 파드의 {{< glossary_tooltip text="톨러레이션" term_id="toleration" >}}이 노드의 {{< glossary_tooltip text="테인트" term_id="taint" >}}를 용인할 수 있는지 확인한다. @@ -110,9 +94,9 @@ weight: 10 - `EvenPodsSpreadPriority`: 선호된 [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)을 구현한다. - - ## {{% heading "whatsnext" %}} * [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기 * [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기 +* [kube-scheduler configuration 레퍼런스 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1) 읽어보기 +* [kube-scheduler Policy 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) 읽어보기 diff --git a/content/ko/docs/reference/setup-tools/kubeadm/_index.md b/content/ko/docs/reference/setup-tools/kubeadm/_index.md index 9211da1e0f..17ed75ba38 100644 --- a/content/ko/docs/reference/setup-tools/kubeadm/_index.md +++ b/content/ko/docs/reference/setup-tools/kubeadm/_index.md @@ -8,7 +8,7 @@ card: weight: 40 --- -Kubeadm은 쿠버네티스 클러스터 생성을 위한 모범 사례의 "빠른 경로"로 `kubeadm init` 과 `kubeadm join` 을 제공하도록 만들어진 도구이다. +Kubeadm은 쿠버네티스 클러스터 생성을 위한 모범 사례의 "빠른 경로"로 `kubeadm init` 과 `kubeadm join` 을 제공하도록 만들어진 도구이다. kubeadm은 실행 가능한 최소 클러스터를 시작하고 실행하는 데 필요한 작업을 수행한다. 설계 상, 시스템 프로비저닝이 아닌 부트스트랩(bootstrapping)만 다룬다. 마찬가지로, 쿠버네티스 대시보드, 모니터링 솔루션 및 클라우드별 애드온과 같은 다양한 있으면 좋은(nice-to-have) 애드온을 설치하는 것은 범위에 포함되지 않는다. @@ -26,5 +26,7 @@ kubeadm을 설치하려면, [설치 가이드](/ko/docs/setup/production-environ * [kubeadm config](/docs/reference/setup-tools/kubeadm/kubeadm-config/): kubeadm v1.7.x 이하의 버전을 사용하여 클러스터를 초기화한 경우, `kubeadm upgrade` 를 위해 사용자의 클러스터를 구성한다. * [kubeadm token](/docs/reference/setup-tools/kubeadm/kubeadm-token/): `kubeadm join` 을 위한 토큰을 관리한다. * [kubeadm reset](/docs/reference/setup-tools/kubeadm/kubeadm-reset/): `kubeadm init` 또는 `kubeadm join` 에 의한 호스트의 모든 변경 사항을 되돌린다. +* [kubeadm certs](/docs/reference/setup-tools/kubeadm/kubeadm-certs): 쿠버네티스 인증서를 관리한다. +* [kubeadm kubeconfig](/docs/reference/setup-tools/kubeadm/kubeadm-kubeconfig): kubeconfig 파일을 관리한다. * [kubeadm version](/docs/reference/setup-tools/kubeadm/kubeadm-version/): kubeadm 버전을 출력한다. * [kubeadm alpha](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/): 커뮤니티에서 피드백을 수집하기 위해서 기능 미리 보기를 제공한다. diff --git a/content/ko/docs/reference/tools/_index.md b/content/ko/docs/reference/tools/_index.md index a38158bf14..6ac3b1dc82 100644 --- a/content/ko/docs/reference/tools/_index.md +++ b/content/ko/docs/reference/tools/_index.md @@ -1,8 +1,10 @@ --- - - title: 도구 + + content_type: concept +weight: 80 +no_list: true --- @@ -10,13 +12,6 @@ content_type: concept -## Kubectl - -[`kubectl`](/ko/docs/tasks/tools/install-kubectl/)은 쿠버네티스를 위한 커맨드라인 툴이며, 쿠버네티스 클러스터 매니저을 제어한다. - -## Kubeadm - -[`kubeadm`](/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)은 물리적 환경, 클라우드 서버, 또는 가상머신 상에서 안전한 쿠버네티스를 쉽게 프로비저닝하기 위한 커맨드라인 툴이다(현재는 알파 상태). ## Minikube @@ -31,8 +26,8 @@ content_type: concept ## Helm -[`쿠버네티스 Helm`](https://github.com/kubernetes/helm)은 사전 구성된 쿠버네티스 리소스를 관리하기위한 도구이며 -또한 Helm의 쿠버네티스 차트라고도 한다. +[Helm](https://helm.sh/)은 사전 구성된 쿠버네티스 리소스 패키지를 관리하기 위한 도구이다. +이 패키지는 _Helm charts_ 라고 알려져 있다. Helm의 용도 diff --git a/content/ko/docs/reference/using-api/client-libraries.md b/content/ko/docs/reference/using-api/client-libraries.md index f8c1cb91c8..11d2e793bc 100644 --- a/content/ko/docs/reference/using-api/client-libraries.md +++ b/content/ko/docs/reference/using-api/client-libraries.md @@ -28,12 +28,12 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. | 언어 | 클라이언트 라이브러리 | 예제 프로그램 | |----------|----------------|-----------------| -| Go | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [둘러보기](https://github.com/kubernetes/client-go/tree/master/examples) -| Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [둘러보기](https://github.com/kubernetes-client/python/tree/master/examples) -| Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [둘러보기](https://github.com/kubernetes-client/java#installation) | dotnet | [github.com/kubernetes-client/csharp](https://github.com/kubernetes-client/csharp) | [둘러보기](https://github.com/kubernetes-client/csharp/tree/master/examples/simple) -| JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [둘러보기](https://github.com/kubernetes-client/javascript/tree/master/examples) +| Go | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [둘러보기](https://github.com/kubernetes/client-go/tree/master/examples) | Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | [둘러보기](https://github.com/kubernetes-client/haskell/tree/master/kubernetes-client/example) +| Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [둘러보기](https://github.com/kubernetes-client/java#installation) +| JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [둘러보기](https://github.com/kubernetes-client/javascript/tree/master/examples) +| Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [둘러보기](https://github.com/kubernetes-client/python/tree/master/examples) ## 커뮤니티에 의해 관리되는 클라이언트 라이브러리 @@ -46,6 +46,10 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. | 언어 | 클라이언트 라이브러리 | | -------------------- | ---------------------------------------- | | Clojure | [github.com/yanatan16/clj-kubernetes-api](https://github.com/yanatan16/clj-kubernetes-api) | +| DotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | +| DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | +| Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) | +| Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) | | Go | [github.com/ericchiang/k8s](https://github.com/ericchiang/k8s) | | Java (OSGi) | [bitbucket.org/amdatulabs/amdatu-kubernetes](https://bitbucket.org/amdatulabs/amdatu-kubernetes) | | Java (Fabric8, OSGi) | [github.com/fabric8io/kubernetes-client](https://github.com/fabric8io/kubernetes-client) | @@ -61,20 +65,16 @@ API 호출 또는 요청/응답 타입을 직접 구현할 필요는 없다. | PHP | [github.com/maclof/kubernetes-client](https://github.com/maclof/kubernetes-client) | | PHP | [github.com/travisghansen/kubernetes-client-php](https://github.com/travisghansen/kubernetes-client-php) | | PHP | [github.com/renoki-co/php-k8s](https://github.com/renoki-co/php-k8s) | -| Python | [github.com/eldarion-gondor/pykube](https://github.com/eldarion-gondor/pykube) | | Python | [github.com/fiaas/k8s](https://github.com/fiaas/k8s) | | Python | [github.com/mnubo/kubernetes-py](https://github.com/mnubo/kubernetes-py) | | Python | [github.com/tomplus/kubernetes_asyncio](https://github.com/tomplus/kubernetes_asyncio) | | Python | [github.com/Frankkkkk/pykorm](https://github.com/Frankkkkk/pykorm) | | Ruby | [github.com/abonas/kubeclient](https://github.com/abonas/kubeclient) | | Ruby | [github.com/Ch00k/kuber](https://github.com/Ch00k/kuber) | +| Ruby | [github.com/k8s-ruby/k8s-ruby](https://github.com/k8s-ruby/k8s-ruby) | | Ruby | [github.com/kontena/k8s-client](https://github.com/kontena/k8s-client) | | Rust | [github.com/clux/kube-rs](https://github.com/clux/kube-rs) | | Rust | [github.com/ynqa/kubernetes-rust](https://github.com/ynqa/kubernetes-rust) | | Scala | [github.com/hagay3/skuber](https://github.com/hagay3/skuber) | | Scala | [github.com/joan38/kubernetes-client](https://github.com/joan38/kubernetes-client) | -| DotNet | [github.com/tonnyeremin/kubernetes_gen](https://github.com/tonnyeremin/kubernetes_gen) | | Swift | [github.com/swiftkube/client](https://github.com/swiftkube/client) | -| DotNet (RestSharp) | [github.com/masroorhasan/Kubernetes.DotNet](https://github.com/masroorhasan/Kubernetes.DotNet) | -| Elixir | [github.com/obmarg/kazan](https://github.com/obmarg/kazan/) | -| Elixir | [github.com/coryodaniel/k8s](https://github.com/coryodaniel/k8s) | diff --git a/content/ko/docs/setup/_index.md b/content/ko/docs/setup/_index.md index b09963d0e2..3c6013c590 100644 --- a/content/ko/docs/setup/_index.md +++ b/content/ko/docs/setup/_index.md @@ -1,17 +1,21 @@ --- -no_issue: true + + + + title: 시작하기 main_menu: true weight: 20 content_type: concept +no_list: true card: name: setup weight: 20 anchors: - anchor: "#학습-환경" title: 학습 환경 - - anchor: "#운영-환경" - title: 운영 환경 + - anchor: "#프로덕션-환경" + title: 프로덕션 환경 --- @@ -20,16 +24,40 @@ card: 쿠버네티스를 설치할 때는 유지보수의 용이성, 보안, 제어, 사용 가능한 리소스, 그리고 클러스터를 운영하고 관리하기 위해 필요한 전문성을 기반으로 설치 유형을 선택한다. -쿠버네티스 클러스터를 로컬 머신에, 클라우드에, 온-프레미스 데이터센터에 배포할 수 있고, 아니면 매니지드 쿠버네티스 클러스터를 선택할 수도 있다. 광범위한 클라우드 제공 업체 또는 베어 메탈 환경에 걸쳐 사용할 수 있는 맞춤형 솔루션도 있다. +[쿠버네티스를 다운로드](/releases/download/)하여 +로컬 머신에, 클라우드에, 데이터센터에 쿠버네티스 클러스터를 구축할 수 있다. + +쿠버네티스 클러스터를 직접 관리하고 싶지 않다면, [인증된 플랫폼](/ko/docs/setup/production-environment/turnkey-solutions/)과 +같은 매니지드 서비스를 선택할 수도 있다. +광범위한 클라우드 또는 베어 메탈 환경에 걸쳐 사용할 수 있는 +표준화된/맞춤형 솔루션도 있다. ## 학습 환경 -쿠버네티스를 배우고 있다면, 쿠버네티스 커뮤니티에서 지원하는 도구나, 로컬 머신에서 쿠버네티스를 설치하기 위한 생태계 내의 도구를 사용하자. +쿠버네티스를 배우고 있다면, 쿠버네티스 커뮤니티에서 지원하는 도구나, +로컬 머신에서 쿠버네티스를 설치하기 위한 생태계 내의 도구를 사용한다. +[도구 설치](/ko/docs/tasks/tools/)를 살펴본다. -## 운영 환경 +## 프로덕션 환경 -운영 환경을 위한 솔루션을 평가할 때에는, 쿠버네티스 클러스터 운영에 대한 어떤 측면(또는 _추상적인 개념_)을 스스로 관리하기를 원하는지, 제공자에게 넘기기를 원하는지 고려하자. +[프로덕션 환경](/ko/docs/setup/production-environment/)을 위한 +솔루션을 평가할 때에는, 쿠버네티스 클러스터(또는 _추상화된 객체_) +운영에 대한 어떤 측면을 스스로 관리하기를 원하는지, +또는 제공자에게 넘기기를 원하는지 고려한다. -[쿠버네티스 파트너](https://kubernetes.io/partners/#conformance)에는 [공인 쿠버네티스](https://github.com/cncf/k8s-conformance/#certified-kubernetes) 공급자 목록이 포함되어 있다. +클러스터를 직접 관리하는 경우, 공식적으로 지원되는 쿠버네티스 구축 도구는 +[kubeadm](/ko/docs/setup/production-environment/tools/kubeadm/)이다. + +## {{% heading "whatsnext" %}} + +- [쿠버네티스를 다운로드](/releases/download/)한다. +- `kubectl`을 포함한 [도구를 설치](/ko/docs/tasks/tools/)한다. +- 새로운 클러스터에 사용할 [컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 선택한다. +- 클러스터 구성의 [모범 사례](/ko/docs/setup/best-practices/)를 확인한다. + +쿠버네티스의 {{< glossary_tooltip term_id="control-plane" text="컨트롤 플레인" >}}은 +리눅스에서 실행되도록 설계되었다. 클러스터 내에서는 리눅스 또는 +다른 운영 체제(예: 윈도우)에서 애플리케이션을 실행할 수 있다. +- [윈도우 노드를 포함하는 클러스터 구성하기](/ko/docs/setup/production-environment/windows/)를 살펴본다. diff --git a/content/ko/docs/setup/best-practices/certificates.md b/content/ko/docs/setup/best-practices/certificates.md index 77665edbe2..e6640be52d 100644 --- a/content/ko/docs/setup/best-practices/certificates.md +++ b/content/ko/docs/setup/best-practices/certificates.md @@ -1,23 +1,23 @@ --- -title: PKI 인증서 및 요구 조건 +title: PKI 인증서 및 요구 사항 content_type: concept weight: 40 --- -쿠버네티스는 TLS 위에 인증을 위해 PKI 인증서가 필요하다. -만약 [kubeadm](/ko/docs/reference/setup-tools/kubeadm/)으로 쿠버네티스를 설치했다면, 클러스터에 필요한 인증서는 자동으로 생성된다. +쿠버네티스는 TLS를 통한 인증을 위해서 PKI 인증서가 필요하다. +만약 [kubeadm](/ko/docs/reference/setup-tools/kubeadm/)으로 쿠버네티스를 설치한다면, 클러스터에 필요한 인증서는 자동으로 생성된다. 또한 더 안전하게 자신이 소유한 인증서를 생성할 수 있다. 이를 테면, 개인키를 API 서버에 저장하지 않으므로 더 안전하게 보관할 수 있다. -이 페이지는 클러스터에 필요한 인증서를 설명한다. +이 페이지는 클러스터가 필요로 하는 인증서에 대해서 설명한다. -## 클러스터에서 인증서는 어떻게 이용되나? +## 클러스터에서 인증서가 이용되는 방식 -쿠버네티스는 다음 작업에서 PKI가 필요하다. +쿠버네티스는 다음 작업에서 PKI를 필요로 한다. * kubelet에서 API 서버 인증서를 인증시 사용하는 클라이언트 인증서 * API 서버 엔드포인트를 위한 서버 인증서 @@ -36,7 +36,7 @@ etcd 역시 클라이언트와 피어 간에 상호 TLS 인증을 구현한다. ## 인증서를 저장하는 위치 -만약 쿠버네티스를 kubeadm으로 설치했다면 인증서는 `/etc/kubernets/pki`에 저장된다. 이 문서에 언급된 모든 파일 경로는 그 디렉터리에 상대적이다. +만약 쿠버네티스를 kubeadm으로 설치했다면 인증서는 `/etc/kubernetes/pki`에 저장된다. 이 문서에 언급된 모든 파일 경로는 그 디렉터리에 상대적이다. ## 인증서 수동 설정 diff --git a/content/ko/docs/setup/best-practices/cluster-large.md b/content/ko/docs/setup/best-practices/cluster-large.md index 6f6dbbae0e..899c63f6b7 100644 --- a/content/ko/docs/setup/best-practices/cluster-large.md +++ b/content/ko/docs/setup/best-practices/cluster-large.md @@ -6,13 +6,13 @@ weight: 20 클러스터는 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}에서 관리하는 쿠버네티스 에이전트를 실행하는 {{< glossary_tooltip text="노드" term_id="node" >}}(물리 또는 가상 머신)의 집합이다. -쿠버네티스 {{}}는 노드 5000개까지의 클러스터를 지원한다. 보다 정확하게는, +쿠버네티스 {{}}는 노드 5,000개까지의 클러스터를 지원한다. 보다 정확하게는, 쿠버네티스는 다음 기준을 *모두* 만족하는 설정을 수용하도록 설계되었다. -* 노드 당 파드 100 개 이하 -* 노드 5000개 이하 -* 전체 파드 150000개 이하 -* 전체 컨테이너 300000개 이하 +* 노드 당 파드 110 개 이하 +* 노드 5,000개 이하 +* 전체 파드 150,000개 이하 +* 전체 컨테이너 300,000개 이하 노드를 추가하거나 제거하여 클러스터를 확장할 수 있다. 이를 수행하는 방법은 클러스터 배포 방법에 따라 다르다. @@ -60,16 +60,19 @@ _A_ 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일 클러스터 생성시의 부가 스트립트이다. 클러스터 생성 시에 (사용자 도구를 사용하여) 다음을 수행할 수 있다. -* 추가 ectd 인스턴스 시작 및 설정 +* 추가 etcd 인스턴스 시작 및 설정 * 이벤트를 저장하기 위한 {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}} 설정 +[쿠버네티스를 위한 etcd 클러스터 운영하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/)와 +[kubeadm을 이용하여 고가용성 etcd 생성하기](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)에서 +큰 클러스터를 위한 etcd를 설정하고 관리하는 방법에 대한 상세 사항을 확인한다. + ## 애드온 리소스 쿠버네티스 [리소스 제한](/ko/docs/concepts/configuration/manage-resources-containers/)은 파드와 컨테이너가 다른 컴포넌트에 영향을 줄 수 있는 메모리 누수 및 기타 방식의 영향을 -최소화하는 데 도움이 된다. 이러한 리소스 제한은 애플리케이션 워크로드에 적용되는 것과 마찬가지로 -{{< glossary_tooltip text="애드온" term_id="addons" >}}에도 적용될 수 있으며 -적용되어야 한다. +최소화하는 데 도움이 된다. 이러한 리소스 제한은 애플리케이션 워크로드에 적용될 수 있는 것처럼 +{{< glossary_tooltip text="애드온" term_id="addons" >}} 리소스에도 적용될 수 있다. 예를 들어, 로깅 컴포넌트에 대한 CPU 및 메모리 제한을 설정할 수 있다. diff --git a/content/ko/docs/setup/best-practices/multiple-zones.md b/content/ko/docs/setup/best-practices/multiple-zones.md index 3d825ebd08..93ab353d37 100644 --- a/content/ko/docs/setup/best-practices/multiple-zones.md +++ b/content/ko/docs/setup/best-practices/multiple-zones.md @@ -55,7 +55,7 @@ content_type: concept 특정 kubelet을 나타내는 노드 오브젝트에 {{< glossary_tooltip text="레이블" term_id="label" >}}을 자동으로 추가한다. 이러한 레이블에는 -[영역 정보](/docs/reference/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다. +[영역 정보](/ko/docs/reference/labels-annotations-taints/#topologykubernetesiozone)가 포함될 수 있다. 클러스터가 여러 영역 또는 지역에 걸쳐있는 경우, [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)과 diff --git a/content/ko/docs/setup/production-environment/_index.md b/content/ko/docs/setup/production-environment/_index.md index 5296cfcaf2..1394c2f325 100644 --- a/content/ko/docs/setup/production-environment/_index.md +++ b/content/ko/docs/setup/production-environment/_index.md @@ -1,4 +1,293 @@ --- -title: 운영 환경 +title: "프로덕션 환경" +description: 프로덕션 수준의 쿠버네티스 클러스터 생성 weight: 30 +no_list: true --- + + +프로덕션 수준의 쿠버네티스 클러스터에는 계획과 준비가 필요하다. +쿠버네티스 클러스터에 중요한 워크로드를 실행하려면 클러스터를 탄력적이도록 구성해야 한다. +이 페이지에서는 프로덕션용 클러스터를 설정하거나 기존 클러스터를 프로덕션용으로 업그레이드하기 위해 +수행할 수 있는 단계를 설명한다. +이미 프로덕션 구성 내용에 익숙하여 단지 링크를 찾고 있다면, +[다음 내용](#다음-내용)을 참고한다. + + + +## 프로덕션 고려 사항 + +일반적으로 프로덕션 쿠버네티스 클러스터 환경에는 +개인 학습용, 개발용 또는 테스트 환경용 클러스터보다 더 많은 요구 사항이 있다. +프로덕션 환경에는 많은 사용자의 보안 액세스, 일관된 가용성 및 +변화하는 요구를 충족하기 위한 리소스가 필요할 수 있다. + +프로덕션 쿠버네티스 환경이 상주할 위치(온 프레미스 또는 클라우드)와 +직접 처리하거나 다른 사람에게 맡길 관리의 양을 결정할 때, +쿠버네티스 클러스터에 대한 요구 사항이 +다음 이슈에 의해 어떻게 영향을 받는지 고려해야 한다. + +- *가용성*: 단일 머신 쿠버네티스 [학습 환경](/ko/docs/setup/#학습-환경)은 SPOF(Single Point of Failure, 단일 장애 지점) 이슈를 갖고 있다. +고가용성 클러스터를 만드는 것에는 다음과 같은 고려 사항이 있다. + - 컨트롤 플레인과 워크 노드를 분리 + - 컨트롤 플레인 구성요소를 여러 노드에 복제 + - 클러스터의 {{< glossary_tooltip term_id="kube-apiserver" text="API 서버" >}}로 가는 트래픽을 로드밸런싱 + - 워커 노드를 충분히 운영하거나, 워크로드 변경에 따라 빠르게 제공할 수 있도록 보장 + +- *스케일링*: 프로덕션 쿠버네티스 환경에 들어오는 요청의 양의 +일정할 것으로 예상된다면, 필요한 만큼의 용량(capacity)을 증설하고 +마무리할 수도 있다. 하지만, 요청의 양이 시간에 따라 점점 증가하거나 +계절, 이벤트 등에 의해 극적으로 변동할 것으로 예상된다면, +컨트롤 플레인과 워커 노드로의 요청 증가로 인한 압박을 해소하기 위해 스케일 업 하거나 +잉여 자원을 줄이기 위해 스케일 다운 하는 것에 대해 고려해야 한다. + +- *보안 및 접근 관리*: 학습을 위한 쿠버네티스 클러스터에는 +완전한 관리 권한을 가질 수 있다. 하지만 중요한 워크로드를 실행하며 +두 명 이상의 사용자가 있는 공유 클러스터에는 누가, 그리고 무엇이 클러스터 자원에 +접근할 수 있는지에 대해서 보다 정교한 접근 방식이 필요하다. +역할 기반 접근 제어([RBAC](/docs/reference/access-authn-authz/rbac/)) 및 +기타 보안 메커니즘을 사용하여, 사용자와 워크로드가 필요한 자원에 +액세스할 수 있게 하면서도 워크로드와 클러스터를 안전하게 유지할 수 있다. +[정책](/ko/docs/concepts/policy/)과 +[컨테이너 리소스](/ko/docs/concepts/configuration/manage-resources-containers/)를 +관리하여, 사용자 및 워크로드가 접근할 수 있는 자원에 대한 제한을 설정할 수 있다. + +쿠버네티스 프로덕션 환경을 직접 구축하기 전에, 이 작업의 일부 또는 전체를 +[턴키 클라우드 솔루션](/ko/docs/setup/production-environment/turnkey-solutions/) +제공 업체 또는 기타 [쿠버네티스 파트너](/ko/partners/)에게 +넘기는 것을 고려할 수 있다. +다음과 같은 옵션이 있다. + +- *서버리스*: 클러스터를 전혀 관리하지 않고 +타사 장비에서 워크로드를 실행하기만 하면 된다. +CPU 사용량, 메모리 및 디스크 요청과 같은 항목에 대한 요금이 부과된다. +- *관리형 컨트롤 플레인*: 쿠버네티스 서비스 공급자가 +클러스터 컨트롤 플레인의 확장 및 가용성을 관리하고 패치 및 업그레이드를 처리하도록 한다. +- *관리형 워커 노드*: 필요에 맞는 노드 풀을 정의하면, +쿠버네티스 서비스 공급자는 해당 노드의 가용성 및 +필요 시 업그레이드 제공을 보장한다. +- *통합*: 쿠버네티스를 스토리지, 컨테이너 레지스트리, +인증 방법 및 개발 도구와 같이 +사용자가 필요로 하는 여러 서비스를 통합 제공하는 업체도 있다. + +프로덕션 쿠버네티스 클러스터를 직접 구축하든 파트너와 협력하든, +요구 사항이 *컨트롤 플레인*, *워커 노드*, +*사용자 접근*, *워크로드 자원*과 관련되기 때문에, +다음 섹션들을 검토하는 것이 바람직하다. + +## 프로덕션 클러스터 구성 + +프로덕션 수준 쿠버네티스 클러스터에서, +컨트롤 플레인은 다양한 방식으로 여러 컴퓨터에 분산될 수 있는 서비스들을 통해 +클러스터를 관리한다. +반면, 각 워커 노드는 쿠버네티스 파드를 실행하도록 구성된 단일 엔티티를 나타낸다. + +### 프로덕션 컨트롤 플레인 + +가장 간단한 쿠버네티스 클러스터는 모든 컨트롤 플레인 및 워커 노드 서비스가 +하나의 머신에 실행되는 클러스터이다. +[쿠버네티스 컴포넌트](/ko/docs/concepts/overview/components/) +그림에 명시된 대로, 워커 노드를 추가하여 해당 환경을 확장할 수 있다. +클러스터를 단기간만 사용하거나, +심각한 문제가 발생한 경우 폐기하는 것이 가능하다면, 이 방식을 선택할 수 있다. + +그러나 더 영구적이고 가용성이 높은 클러스터가 필요한 경우 +컨트롤 플레인 확장을 고려해야 한다. +설계 상, 단일 시스템에서 실행되는 단일 시스템 컨트롤 플레인 서비스는 +가용성이 높지 않다. +클러스터를 계속 유지하면서 문제가 발생한 경우 복구할 수 있는지 여부가 중요한 경우, +다음 사항들을 고려한다. + +- *배포 도구 선택*: kubeadm, kops, kubespray와 같은 도구를 이용해 +컨트롤 플레인을 배포할 수 있다. +[배포 도구로 쿠버네티스 설치하기](/ko/docs/setup/production-environment/tools/)에서 +여러 배포 도구를 이용한 프로덕션 수준 배포에 대한 팁을 확인한다. +배포 시, 다양한 +[컨테이너 런타임](/ko/docs/setup/production-environment/container-runtimes/)을 사용할 수 있다. +- *인증서 관리*: 컨트롤 플레인 서비스 간의 보안 통신은 인증서를 사용하여 구현된다. +인증서는 배포 중에 자동으로 생성되거나, 또는 자체 인증 기관을 사용하여 생성할 수 있다. +[PKI 인증서 및 요구 조건](/ko/docs/setup/best-practices/certificates/)에서 +상세 사항을 확인한다. +- *apiserver를 위한 로드밸런서 구성*: 여러 노드에서 실행되는 apiserver 서비스 인스턴스에 +외부 API 호출을 분산할 수 있도록 로드밸런서를 구성한다. +[외부 로드밸런서 생성하기](/docs/tasks/access-application-cluster/create-external-load-balancer/)에서 +상세 사항을 확인한다. +- *etcd 서비스 분리 및 백업*: etcd 서비스는 +다른 컨트롤 플레인 서비스와 동일한 시스템에서 실행되거나, +또는 추가 보안 및 가용성을 위해 별도의 시스템에서 실행될 수 있다. +etcd는 클러스터 구성 데이터를 저장하므로 +필요한 경우 해당 데이터베이스를 복구할 수 있도록 etcd 데이터베이스를 정기적으로 백업해야 한다. +[etcd FAQ](https://etcd.io/docs/v3.4/faq/)에서 etcd 구성 및 사용 상세를 확인한다. +[쿠버네티스를 위한 etcd 클러스터 운영하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/)와 +[kubeadm을 이용하여 고가용성 etcd 생성하기](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)에서 +상세 사항을 확인한다. +- *다중 컨트롤 플레인 시스템 구성*: 고가용성을 위해, +컨트롤 플레인은 단일 머신으로 제한되지 않아야 한다. +컨트롤 플레인 서비스가 init 서비스(예: systemd)에 의해 실행되는 경우, +각 서비스는 최소 3대의 머신에서 실행되어야 한다. +그러나, 컨트롤 플레인 서비스를 쿠버네티스 상의 파드 형태로 실행하면 +각 서비스 복제본 요청이 보장된다. +스케줄러는 내결함성이 있어야 하고, 고가용성은 필요하지 않다. +일부 배포 도구는 쿠버네티스 서비스의 리더 선출을 수행하기 위해 +[Raft](https://raft.github.io/) 합의 알고리즘을 설정한다. +리더를 맡은 서비스가 사라지면 다른 서비스가 스스로 리더가 되어 인계를 받는다. +- *다중 영역(zone)으로 확장*: 클러스터를 항상 사용 가능한 상태로 유지하는 것이 중요하다면 +여러 데이터 센터(클라우드 환경에서는 '영역'이라고 함)에서 실행되는 +클러스터를 만드는 것이 좋다. +영역의 그룹을 지역(region)이라고 한다. +동일한 지역의 여러 영역에 클러스터를 분산하면 +하나의 영역을 사용할 수 없게 된 경우에도 클러스터가 계속 작동할 가능성을 높일 수 있다. +[여러 영역에서 실행](/ko/docs/setup/best-practices/multiple-zones/)에서 상세 사항을 확인한다. +- *구동 중인 기능 관리*: 클러스터를 계속 유지하려면, +상태 및 보안을 유지하기 위해 수행해야 하는 작업이 있다. +예를 들어 kubeadm으로 클러스터를 생성한 경우, +[인증서 관리](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/)와 +[kubeadm 클러스터 업그레이드하기](/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)에 대해 도움이 되는 가이드가 있다. +[클러스터 운영하기](/ko/docs/tasks/administer-cluster/)에서 +더 많은 쿠버네티스 관리 작업을 볼 수 있다. + +컨트롤 플레인 서비스를 실행할 때 사용 가능한 옵션에 대해 보려면, +[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/), +[kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/), +[kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/)를 참조한다. +고가용성 컨트롤 플레인 예제는 +[고가용성 토폴로지를 위한 옵션](/ko/docs/setup/production-environment/tools/kubeadm/ha-topology/), +[kubeadm을 이용하여 고가용성 클러스터 생성하기](/docs/setup/production-environment/tools/kubeadm/high-availability/), +[쿠버네티스를 위한 etcd 클러스터 운영하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/)를 참조한다. +etcd 백업 계획을 세우려면 +[etcd 클러스터 백업하기](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)를 참고한다. + +### 프로덕션 워커 노드 + +프로덕션 수준 워크로드는 복원력이 있어야 하고, +이들이 의존하는 모든 것들(예: CoreDNS)도 복원력이 있어야 한다. +컨트롤 플레인을 자체적으로 관리하든 +클라우드 공급자가 대신 수행하도록 하든 상관없이, +워커 노드(간단히 *노드*라고도 함)를 어떤 방법으로 관리할지 고려해야 한다. + +- *노드 구성하기*: 노드는 물리적 또는 가상 머신일 수 있다. +직접 노드를 만들고 관리하려면 지원되는 운영 체제를 설치한 다음 +적절한 [노드 서비스](/ko/docs/concepts/overview/components/#노드-컴포넌트)를 추가하고 실행한다. +다음을 고려해야 한다. + - 워크로드의 요구 사항 (노드가 적절한 메모리, CPU, 디스크 속도, 저장 용량을 갖도록 구성) + - 일반적인 컴퓨터 시스템이면 되는지, 아니면 GPU, 윈도우 노드, 또는 VM 격리를 필요로 하는 워크로드가 있는지 +- *노드 검증하기*: [노드 구성 검증하기](/ko/docs/setup/best-practices/node-conformance/)에서 +노드가 쿠버네티스 클러스터에 조인(join)에 필요한 요구 사항을 +만족하는지 확인하는 방법을 알아본다. +- *클러스터에 노드 추가하기*: 클러스터를 자체적으로 관리하는 경우, +머신을 준비하고, 클러스터의 apiserver에 이를 수동으로 추가하거나 +또는 머신이 스스로 등록하도록 하여 노드를 추가할 수 있다. +이러한 방식으로 노드를 추가하는 방법을 보려면 [노드](/ko/docs/concepts/architecture/nodes/) 섹션을 확인한다. +- *클러스터에 윈도우 노드 추가하기*: 윈도우 컨테이너로 구현된 워크로드를 +실행할 수 있도록, 쿠버네티스는 윈도우 워커 노드를 지원한다. +[쿠버네티스에서의 윈도우](/ko/docs/setup/production-environment/windows/)에서 상세 사항을 확인한다. +- *노드 스케일링*: 클러스터가 최종적으로 필요로 하게 될 용량만큼 +확장하는 것에 대한 계획이 있어야 한다. +실행해야 하는 파드 및 컨테이너 수에 따라 필요한 노드 수를 판별하려면 +[대형 클러스터에 대한 고려 사항](/ko/docs/setup/best-practices/cluster-large/)을 확인한다. +만약 노드를 직접 관리한다면, 직접 물리적 장비를 구입하고 설치해야 할 수도 있음을 의미한다. +- *노드 자동 스케일링*: 대부분의 클라우드 공급자는 +비정상 노드를 교체하거나 수요에 따라 노드 수를 늘리거나 줄일 수 있도록 +[클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)를 지원한다. +[자주 묻는 질문](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md)에서 +오토스케일러가 어떻게 동작하는지, +[배치](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment) 섹션에서 +각 클라우드 공급자별로 어떻게 구현했는지를 확인한다. +온프레미스의 경우, 필요에 따라 새 노드를 가동하도록 +스크립트를 구성할 수 있는 가상화 플랫폼이 있다. +- *노드 헬스 체크 구성*: 중요한 워크로드의 경우, +해당 노드에서 실행 중인 노드와 파드의 상태가 정상인지 확인하고 싶을 것이다. +[Node Problem Detector](/docs/tasks/debug-application-cluster/monitor-node-health/) +데몬을 사용하면 노드가 정상인지 확인할 수 있다. + +## 프로덕션 사용자 관리 + +프로덕션에서는, 클러스터를 한 명 또는 여러 명이 사용하던 모델에서 +수십에서 수백 명이 사용하는 모델로 바꿔야 하는 경우가 발생할 수 있다. +학습 환경 또는 플랫폼 프로토타입에서는 모든 작업에 대한 단일 관리 계정으로도 +충분할 수 있다. 프로덕션에서는 여러 네임스페이스에 대한, 액세스 수준이 +각각 다른 더 많은 계정이 필요하다. + +프로덕션 수준의 클러스터를 사용한다는 것은 +다른 사용자의 액세스를 선택적으로 허용할 방법을 결정하는 것을 의미한다. +특히 클러스터에 액세스를 시도하는 사용자의 신원을 확인(인증, authentication)하고 +요청한 작업을 수행할 권한이 있는지 결정(인가, authorization)하기 위한 +다음과 같은 전략을 선택해야 한다. + +- *인증*: apiserver는 클라이언트 인증서, 전달자 토큰, 인증 프록시 또는 +HTTP 기본 인증을 사용하여 사용자를 인증할 수 있다. +사용자는 인증 방법을 선택하여 사용할 수 있다. +apiserver는 또한 플러그인을 사용하여 +LDAP 또는 Kerberos와 같은 조직의 기존 인증 방법을 활용할 수 있다. +쿠버네티스 사용자를 인증하는 다양한 방법에 대한 설명은 +[인증](/docs/reference/access-authn-authz/authentication/)을 참조한다. +- *인가*: 일반 사용자 인가를 위해, RBAC 와 ABAC 중 하나를 선택하여 사용할 수 있다. [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)에서 사용자 계정과 서비스 어카운트 인가를 위한 여러 가지 모드를 확인할 수 있다. + - *역할 기반 접근 제어* ([RBAC](/docs/reference/access-authn-authz/rbac/)): 인증된 사용자에게 특정 권한 집합을 허용하여 클러스터에 대한 액세스를 할당할 수 있다. 특정 네임스페이스(Role) 또는 전체 클러스터(ClusterRole)에 권한을 할당할 수 있다. 그 뒤에 RoleBindings 및 ClusterRoleBindings를 사용하여 해당 권한을 특정 사용자에게 연결할 수 있다. + - *속성 기반 접근 제어* ([ABAC](/docs/reference/access-authn-authz/abac/)): 클러스터의 리소스 속성을 기반으로 정책을 생성하고 이러한 속성을 기반으로 액세스를 허용하거나 거부할 수 있다. 정책 파일의 각 줄은 버전 관리 속성(apiVersion 및 종류), 그리고 '대상(사용자 또는 그룹)', '리소스 속성', '비 리소스 속성(`/version` 또는 `/apis`)' 및 '읽기 전용'과 일치하는 사양 속성 맵을 식별한다. 자세한 내용은 [예시](/docs/reference/access-authn-authz/abac/#examples)를 참조한다. + +프로덕션 쿠버네티스 클러스터에 인증과 인가를 설정할 때, 다음의 사항을 고려해야 한다. + +- *인가 모드 설정*: 쿠버네티스 API 서버([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/))를 실행할 때, +*`--authorization-mode`* 플래그를 사용하여 인증 모드를 설정해야 한다. +예를 들어, (*`/etc/kubernetes/manifests`*에 있는) +*`kube-adminserver.yaml`* 파일 안의 플래그를 `Node,RBAC`으로 설정할 수 있다. +이렇게 하여 인증된 요청이 Node 인가와 RBAC 인가를 사용할 수 있게 된다. +- *사용자 인증서와 롤 바인딩 생성(RBAC을 사용하는 경우)*: RBAC 인증을 사용하는 경우, +사용자는 클러스터 CA가 서명한 CSR(CertificateSigningRequest)을 만들 수 있다. +그 뒤에 각 사용자에게 역할 및 ClusterRoles를 바인딩할 수 있다. +자세한 내용은 +[인증서 서명 요청](/docs/reference/access-authn-authz/certificate-signing-requests/)을 참조한다. +- *속성을 포함하는 정책 생성(ABAC을 사용하는 경우)*: ABAC 인증을 사용하는 경우, +속성의 집합으로 정책을 생성하여, 인증된 사용자 또는 그룹이 +특정 리소스(예: 파드), 네임스페이스, 또는 apiGroup에 접근할 수 있도록 한다. +[예시](/docs/reference/access-authn-authz/abac/#examples)에서 +더 많은 정보를 확인한다. +- *어드미션 컨트롤러 도입 고려*: +[웹훅 토큰 인증](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication)은 +API 서버를 통해 들어오는 요청의 인가에 사용할 수 있는 추가적인 방법이다. +웹훅 및 다른 인가 형식을 사용하려면 API 서버에 +[어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)를 +추가해야 한다. + +## 워크로드에 자원 제한 걸기 + +프로덕션 워크로드의 요구 사항이 +쿠버네티스 컨트롤 플레인 안팎의 압박을 초래할 수 있다. +워크로드의 요구 사항을 충족하도록 클러스터를 구성할 때 다음 항목을 고려한다. + +- *네임스페이스 제한 설정*: 메모리, CPU와 같은 자원의 네임스페이스 별 쿼터를 설정한다. +[메모리, CPU 와 API 리소스 관리](/ko/docs/tasks/administer-cluster/manage-resources/)에서 +상세 사항을 확인한다. +[계층적 네임스페이스](/blog/2020/08/14/introducing-hierarchical-namespaces/)를 설정하여 +제한을 상속할 수도 있다. +- *DNS 요청에 대한 대비*: 워크로드가 대규모로 확장될 것으로 예상된다면, +DNS 서비스도 확장할 준비가 되어 있어야 한다. +[클러스터의 DNS 서비스 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/)을 확인한다. +- *추가적인 서비스 어카운트 생성*: 사용자 계정은 *클러스터*에서 사용자가 무엇을 할 수 있는지 결정하는 반면에, +서비스 어카운트는 특정 네임스페이스 내의 파드 접근 권한을 결정한다. +기본적으로, 파드는 자신의 네임스페이스의 기본 서비스 어카운트을 이용한다. +[서비스 어카운트 관리하기](/ko/docs/reference/access-authn-authz/service-accounts-admin/)에서 +새로운 서비스 어카운트을 생성하는 방법을 확인한다. 예를 들어, 다음의 작업을 할 수 있다. + - 파드가 특정 컨테이너 레지스트리에서 이미지를 가져 오는 데 사용할 수 있는 시크릿을 추가한다. [파드를 위한 서비스 어카운트 구성하기](/docs/tasks/configure-pod-container/configure-service-account/)에서 예시를 확인한다. + - 서비스 어카운트에 RBAC 권한을 할당한다. [서비스어카운트 권한](/docs/reference/access-authn-authz/rbac/#service-account-permissions)에서 상세 사항을 확인한다. + +## {{% heading "whatsnext" %}} + +- 프로덕션 쿠버네티스를 직접 구축할지, +아니면 [턴키 클라우드 솔루션](/ko/docs/setup/production-environment/turnkey-solutions/) 또는 +[쿠버네티스 파트너](/ko/partners/)가 제공하는 서비스를 이용할지 결정한다. +- 클러스터를 직접 구축한다면, +[인증서](/ko/docs/setup/best-practices/certificates/)를 어떻게 관리할지, +[etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)와 +[API 서버](/ko/docs/setup/production-environment/tools/kubeadm/ha-topology/) +등의 기능에 대한 고가용성을 +어떻게 보장할지를 계획한다. +- 배포 도구로 [kubeadm](/ko/docs/setup/production-environment/tools/kubeadm/), [kops](/ko/docs/setup/production-environment/tools/kops/), [Kubespray](/ko/docs/setup/production-environment/tools/kubespray/) 중 +하나를 선택한다. +- [인증](/docs/reference/access-authn-authz/authentication/) 및 +[인가](/ko/docs/reference/access-authn-authz/authorization/) 방식을 선택하여 +사용자 관리 방법을 구성한다. +- [자원 제한](/ko/docs/tasks/administer-cluster/manage-resources/), +[DNS 오토스케일링](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/), +[서비스 어카운트](/ko/docs/reference/access-authn-authz/service-accounts-admin/)를 설정하여 +애플리케이션 워크로드의 실행에 대비한다. diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md index 52ab0fc94b..fb749a2346 100644 --- a/content/ko/docs/setup/production-environment/container-runtimes.md +++ b/content/ko/docs/setup/production-environment/container-runtimes.md @@ -48,7 +48,7 @@ Systemd는 cgroup과의 긴밀한 통합을 통해 프로세스당 cgroup을 할 시스템이 안정화된다. 도커에 대해 구성하려면, `native.cgroupdriver=systemd`를 설정한다. {{< caution >}} -클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 강력하게 권장하지 *않는다*. +클러스터에 결합되어 있는 노드의 cgroup 관리자를 변경하는 것은 신중하게 수행해야 한다. 하나의 cgroup 드라이버의 의미를 사용하여 kubelet이 파드를 생성해왔다면, 컨테이너 런타임을 다른 cgroup 드라이버로 변경하는 것은 존재하는 기존 파드에 대해 파드 샌드박스 재생성을 시도할 때, 에러가 발생할 수 있다. kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다. @@ -57,6 +57,11 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다. 교체하거나, 자동화를 사용하여 다시 설치한다. {{< /caution >}} +### kubeadm으로 생성한 클러스터의 드라이버를 `systemd`로 변경하기 + +kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면 +[변경 가이드](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다. + ## 컨테이너 런타임 {{% thirdparty-content %}} @@ -92,7 +97,10 @@ containerd를 설치한다. {{< tabs name="tab-cri-containerd-installation" >}} {{% tab name="Linux" %}} -1. 공식 도커 리포지터리에서 `containerd.io` 패키지를 설치한다. 각 리눅스 배포한에 대한 도커 리포지터리를 설정하고 `containerd.io` 패키지를 설치하는 방법은 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에서 찾을 수 있다. +1. 공식 도커 리포지터리에서 `containerd.io` 패키지를 설치한다. +각 리눅스 배포판에 대한 도커 리포지터리를 설정하고 +`containerd.io` 패키지를 설치하는 방법은 +[도커 엔진 설치](https://docs.docker.com/engine/install/#server)에서 찾을 수 있다. 2. containerd 설정 @@ -110,7 +118,8 @@ containerd를 설치한다. {{% /tab %}} {{% tab name="Windows (PowerShell)" %}} -PowerShell 세션을 시작하고 `$Version`을 원하는 버전(예: `$Version:1.4.3`)으로 설정한 후 다음 명령을 실행한다. +PowerShell 세션을 시작하고 `$Version`을 원하는 버전으로 +설정(예: `$Version:1.4.3`)한 후 다음 명령을 실행한다. 1. containerd 다운로드 @@ -237,7 +246,8 @@ sudo apt-get install cri-o cri-o-runc {{% tab name="Ubuntu" %}} -다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를 아래의 표에서 적절한 필드로 설정한다. +다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를 +아래의 표에서 적절한 필드로 설정한다. | 운영 체제 | `$OS` | | ---------------- | ----------------- | @@ -272,7 +282,8 @@ apt-get install cri-o cri-o-runc {{% tab name="CentOS" %}} -다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를 아래의 표에서 적절한 필드로 설정한다. +다음의 운영 체제에서 CRI-O를 설치하려면, 환경 변수 `OS` 를 +아래의 표에서 적절한 필드로 설정한다. | 운영 체제 | `$OS` | | ---------------- | ----------------- | @@ -352,7 +363,10 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로 ### 도커 -1. 각 노드에서 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에 따라 리눅스 배포판용 도커를 설치한다. 이 [의존성 파일](https://git.k8s.io/kubernetes/build/dependencies.yaml)에서 검증된 최신 버전의 도커를 찾을 수 있다. +1. 각 노드에서 [도커 엔진 설치](https://docs.docker.com/engine/install/#server)에 따라 +리눅스 배포판용 도커를 설치한다. +이 [의존성 파일](https://git.k8s.io/kubernetes/build/dependencies.yaml)에서 +검증된 최신 버전의 도커를 찾을 수 있다. 2. 특히 컨테이너의 cgroup 관리에 systemd를 사용하도록 도커 데몬을 구성한다. @@ -371,7 +385,8 @@ CRI-O의 cgroup 드라이버 구성을 동기화 상태로 ``` {{< note >}} - `overlay2`는 리눅스 커널 4.0 이상 또는 3.10.0-514 버전 이상을 사용하는 RHEL 또는 CentOS를 구동하는 시스템에서 선호하는 스토리지 드라이버이다. + `overlay2`는 리눅스 커널 4.0 이상 또는 3.10.0-514 버전 이상을 사용하는 RHEL + 또는 CentOS를 구동하는 시스템에서 선호하는 스토리지 드라이버이다. {{< /note >}} 3. 도커 재시작과 부팅시 실행되게 설정 diff --git a/content/ko/docs/setup/production-environment/tools/kops.md b/content/ko/docs/setup/production-environment/tools/kops.md index 9c241e496f..3bfb49380e 100644 --- a/content/ko/docs/setup/production-environment/tools/kops.md +++ b/content/ko/docs/setup/production-environment/tools/kops.md @@ -57,10 +57,10 @@ curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https:// $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4) ``` -예를 들어 kops 버전을 v1.15.0을 다운로드 하려면 다음을 입력한다. +예를 들어 kops 버전을 v1.20.0을 다운로드 하려면 다음을 입력한다. ```shell -curl -LO https://github.com/kubernetes/kops/releases/download/1.15.0/kops-darwin-amd64 +curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-darwin-amd64 ``` kops 바이너리를 실행 가능하게 만든다. @@ -94,10 +94,10 @@ curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https:// ```shell $(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4) ``` -예를 들어 kops 버전을 v1.15.0을 다운로드 하려면 다음을 입력한다. +예를 들어 kops 버전을 v1.20.0을 다운로드 하려면 다음을 입력한다. ```shell -curl -LO https://github.com/kubernetes/kops/releases/download/1.15.0/kops-linux-amd64 +curl -LO https://github.com/kubernetes/kops/releases/download/v1.20.0/kops-linux-amd64 ``` kops 바이너리를 실행 가능하게 만든다. diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md index 358274d143..cae9a85b0a 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md @@ -9,7 +9,8 @@ weight: 40 {{< feature-state for_k8s_version="v1.12" state="stable" >}} -kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러와 같은 컨트롤 플레인 구성요소에 전달되는 기본 플래그 `extraArgs` 필드를 노출한다. 이 구성요소는 다음 필드를 사용하도록 정의되어 있다. +kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러와 같은 컨트롤 플레인 구성요소에 전달되는 +기본 플래그 `extraArgs` 필드를 노출한다. 이 구성요소는 다음 필드를 사용하도록 정의되어 있다. - `apiServer` - `controllerManager` @@ -19,10 +20,10 @@ kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니 1. 사용자 구성에서 적절한 필드를 추가한다. 2. 필드에 대체할 플래그를 추가한다. -3. `kubeadm init`에 `--config ` 파라미터를 추가해서 실행한다. +3. `kubeadm init`에 `--config ` 파라미터를 추가해서 실행한다. 각 필드의 구성에서 자세한 정보를 보려면, -[API 참고 문서](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2#ClusterConfiguration)에서 확인해 볼 수 있다. +[API 참고 문서](/docs/reference/config-api/kubeadm-config.v1beta2/)에서 확인해 볼 수 있다. {{< note >}} `kubeadm config print init-defaults`를 실행하고 원하는 파일에 출력을 저장하여 기본값인 `ClusterConfiguration` 오브젝트를 생성할 수 있다. @@ -34,9 +35,9 @@ kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니 ## APIServer 플래그 -자세한 내용은 [kube-apiserver에 대한 참고 문서](/docs/reference/command-line-tools-reference/kube-apiserver/)를 확인한다. +자세한 내용은 [kube-apiserver 레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-apiserver/)를 확인한다. -사용 예: +예시: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration @@ -51,9 +52,9 @@ apiServer: ## 컨트롤러매니저 플래그 -자세한 내용은 [kube-controller-manager에 대한 참고 문서](/docs/reference/command-line-tools-reference/kube-controller-manager/)를 확인한다. +자세한 내용은 [kube-controller-manager 레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-controller-manager/)를 확인한다. -사용 예: +예시: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration @@ -67,16 +68,20 @@ controllerManager: ## 스케줄러 플래그 -자세한 내용은 [kube-scheduler에 대한 참고 문서](/docs/reference/command-line-tools-reference/kube-scheduler/)를 확인한다. +자세한 내용은 [kube-scheduler 레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/)를 확인한다. -사용 예: +예시: ```yaml apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration kubernetesVersion: v1.16.0 scheduler: extraArgs: - bind-address: 0.0.0.0 - config: /home/johndoe/schedconfig.yaml - kubeconfig: /home/johndoe/kubeconfig.yaml + config: /etc/kubernetes/scheduler-config.yaml + extraVolumes: + - name: schedulerconfig + hostPath: /home/johndoe/schedconfig.yaml + mountPath: /etc/kubernetes/scheduler-config.yaml + readOnly: true + pathType: "File" ``` diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 12b48ad17e..d102f5f587 100644 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -10,7 +10,7 @@ card: -이 페이지에서는 `kubeadm` 툴박스를 설치하는 방법을 보여준다. +이 페이지에서는 `kubeadm` 툴박스를 설치하는 방법을 보여준다. 이 설치 프로세스를 수행한 후 kubeadm으로 클러스터를 만드는 방법에 대한 자세한 내용은 [kubeadm을 사용하여 클러스터 생성하기](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) 페이지를 참고한다. @@ -70,7 +70,7 @@ sudo sysctl --system | 프로토콜 | 방향 | 포트 범위 | 목적 | 사용자 | |----------|-----------|------------|-------------------------|---------------------------| -| TCP | 인바운드 | 6443* | 쿠버네티스 API 서버 | 모두 | +| TCP | 인바운드 | 6443\* | 쿠버네티스 API 서버 | 모두 | | TCP | 인바운드 | 2379-2380 | etcd 서버 클라이언트 API | kube-apiserver, etcd | | TCP | 인바운드 | 10250 | kubelet API | 자체, 컨트롤 플레인 | | TCP | 인바운드 | 10251 | kube-scheduler | 자체 | @@ -169,7 +169,7 @@ kubeadm은 `kubelet` 또는 `kubectl` 을 설치하거나 관리하지 **않으 버전 차이에 대한 자세한 내용은 다음을 참고한다. -* 쿠버네티스 [버전 및 버전-차이 정책](/docs/setup/release/version-skew-policy/) +* 쿠버네티스 [버전 및 버전-차이 정책](/ko/releases/version-skew-policy/) * Kubeadm 관련 [버전 차이 정책](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/#version-skew-policy) {{< tabs name="k8s_install" >}} @@ -294,33 +294,17 @@ Flatcar Container Linux 배포판은 `/usr` 디렉터리를 읽기 전용 파일 kubelet은 이제 kubeadm이 수행할 작업을 알려 줄 때까지 크래시루프(crashloop) 상태로 기다려야 하므로 몇 초마다 다시 시작된다. -## 컨트롤 플레인 노드에서 kubelet이 사용하는 cgroup 드라이버 구성 +## cgroup 드라이버 구성 -도커를 사용할 때, kubeadm은 kubelet 용 cgroup 드라이버를 자동으로 감지하여 -런타임 중에 `/var/lib/kubelet/config.yaml` 파일에 설정한다. - -다른 CRI를 사용하는 경우, 다음과 같이 `cgroupDriver` 값을 `kubeadm init` 에 전달해야 한다. - -```yaml -apiVersion: kubelet.config.k8s.io/v1beta1 -kind: KubeletConfiguration -cgroupDriver: -``` - -자세한 내용은 [구성 파일과 함께 kubeadm init 사용](/docs/reference/setup-tools/kubeadm/kubeadm-init/#config-file)을 참고한다. - -`cgroupfs` 가 이미 kubelet의 기본값이기 때문에, 사용자의 -CRI cgroup 드라이버가 `cgroupfs` 가 아닌 **경우에만** 위와 같이 설정해야 한다. - -{{< note >}} -`--cgroup-driver` 플래그가 kubelet에 의해 사용 중단되었으므로, `/var/lib/kubelet/kubeadm-flags.env` -또는 `/etc/default/kubelet`(RPM에 대해서는 `/etc/sysconfig/kubelet`)에 있는 경우, 그것을 제거하고 대신 KubeletConfiguration을 -사용한다(기본적으로 `/var/lib/kubelet/config.yaml` 에 저장됨). -{{< /note >}} - -CRI-O 및 containerd와 같은 다른 컨테이너 런타임에 대한 cgroup 드라이버의 -자동 감지에 대한 작업이 진행 중이다. +컨테이너 런타임과 kubelet은 +["cgroup 드라이버"](/ko/docs/setup/production-environment/container-runtimes/)라는 속성을 갖고 있으며, +cgroup 드라이버는 리눅스 머신의 cgroup 관리 측면에 있어서 중요하다. +{{< warning >}} +컨테이너 런타임과 kubelet의 cgroup 드라이버를 일치시켜야 하며, 그렇지 않으면 kubelet 프로세스에 오류가 발생한다. + +더 자세한 사항은 [cgroup 드라이버 설정하기](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/)를 참고한다. +{{< /warning >}} ## 문제 해결 @@ -328,5 +312,4 @@ kubeadm에 문제가 있는 경우, [문제 해결 문서](/docs/setup/productio ## {{% heading "whatsnext" %}} - * [kubeadm을 사용하여 클러스터 생성](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/self-hosting.md b/content/ko/docs/setup/production-environment/tools/kubeadm/self-hosting.md deleted file mode 100644 index cfa18135b1..0000000000 --- a/content/ko/docs/setup/production-environment/tools/kubeadm/self-hosting.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -reviewers: -title: 컨트롤 플레인을 자체 호스팅하기 위해 쿠버네티스 클러스터 구성하기 -content_type: concept -weight: 100 ---- - - - -### 쿠버네티스 컨트롤 플레인 자체 호스팅하기 {#self-hosting} - -kubeadm은 실험적으로 _자체 호스팅_ 된 쿠버네티스 컨트롤 플레인을 만들 수 있도록 -해준다. API 서버, 컨트롤러 매니저 및 스케줄러와 같은 주요 구성 요소가 정적(static) 파일을 -통해 kubelet에 구성된 [스태틱(static) 파드](/ko/docs/tasks/configure-pod-container/static-pod/) -대신 쿠버네티스 API를 통해 구성된 [데몬셋(DaemonSet) 파드](/ko/docs/concepts/workloads/controllers/daemonset/) -로 실행된다. - -자체 호스팅된 클러스터를 만들려면 [kubeadm alpha selfhosting pivot](/docs/reference/setup-tools/kubeadm/kubeadm-alpha/#cmd-selfhosting) -명령어를 확인한다. - - - -#### 주의사항 - -{{< caution >}} -이 기능은 클러스터를 지원되지 않는 상태로 전환하여 더 이상 클러스터를 관리할 수 없게 만든다. -이것은 `kubeadm upgrade`를 포함한다. -{{< /caution >}} - -1. 1.8 이후 버전에서 자체 호스팅은 몇 가지 중요한 한계가 있다. - 특히 자체 호스팅된 클러스터는 수동 조정 없이는 - _컨트롤 플레인 노드를 재부팅하고 나서 복구할 수 없다._ - -1. 기본적으로 자체 호스팅된 컨트롤 플레인 파드는 - [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) 볼륨에서 불러 온 - 자격 증명에 의존한다. 초기 생성을 제외하고, 이러한 자격 증명은 kubeadm에 의해 - 관리되지 않는다. - -1. 컨트롤 플레인의 자체 호스팅된 부분에는 스태틱 파드로 실행되는 etcd가 - 포함되지 않는다. - -#### 프로세스 - -자체 호스팅 부트스트랩 프로세스는 [kubeadm 설계 -문서](https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.9.md#optional-self-hosting)에 기록되어 있다. - -요약하면 `kubeadm alpha selfhosting`은 다음과 같이 작동한다. - - 1. 부트스트랩 스태틱 컨트롤 플레인이 실행되고 정상 상태가 될 때까지 기다린다. - 이것은 자체 호스팅이 없는 `kubeadm init` 프로세스와 동일하다. - - 1. 스태틱 컨트롤 플레인 파드 매니페스트를 사용하여 자체 호스팅된 컨트롤 - 플레인을 실행할 데몬셋 매니페스트 집합을 구성한다. 또한 필요한 경우 - 해당 매니페스트를 수정한다. 예를 들어, 시크릿을 위한 새로운 볼륨을 - 추가한다. - - 1. `kube-system` 네임스페이스에 데몬셋을 생성하고 결과 파드가 실행될 때까지 - 대기한다. - - 1. 일단 자체 호스팅된 파드가 동작하면 관련 스태틱 파드가 삭제되고 - kubeadm은 계속해서 다음 구성 요소를 설치한다. - 이것은 kubelet이 스태틱 파드를 멈추게 한다. - - 1. 기존의 컨트롤 플레인이 멈추면 새롭게 자체 호스팅된 컨트롤 플레인은 - 리스닝 포트에 바인딩하여 활성화할 수 있다. diff --git a/content/ko/docs/setup/production-environment/tools/kubespray.md b/content/ko/docs/setup/production-environment/tools/kubespray.md index cb0caf175e..6e7d9c8185 100644 --- a/content/ko/docs/setup/production-environment/tools/kubespray.md +++ b/content/ko/docs/setup/production-environment/tools/kubespray.md @@ -50,7 +50,7 @@ Kubespray는 환경에 맞는 프로비저닝을 돕기 위해 아래와 같은 ### (2/5) 인벤토리 파일 구성하기 -서버들을 프로비저닝 한 후, [Ansible의 인벤토리 파일](https://docs.ansible.com/ansible/intro_inventory.html)을 만들어야 한다. 수동으로 만들 수도 있고, 동적인 인벤토리 스크립트를 통해 만들 수도 있다. 더 많이 알고싶다면 " [나만의 인벤토리 만들기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)" 글을 확인하자. +서버들을 프로비저닝 한 후, [Ansible의 인벤토리 파일](https://docs.ansible.com/ansible/latest/network/getting_started/first_inventory.html)을 만들어야 한다. 수동으로 만들 수도 있고, 동적인 인벤토리 스크립트를 통해 만들 수도 있다. 더 많이 알고싶다면 " [나만의 인벤토리 만들기](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/getting-started.md#building-your-own-inventory)" 글을 확인하자. ### (3/5) 클러스터 디플로이먼트 계획하기 @@ -68,7 +68,7 @@ Kubespray에서는 디플로이먼트의 많은 속성들을 사용자가 정의 * {{< glossary_tooltip term_id="cri-o" >}} * 인증서 생성 방법 -Kubespray의 [변수 파일들](https://docs.ansible.com/ansible/playbooks_variables.html)을 사용자가 정의할 수 있다. 만약 Kubespray를 막 시작한 경우, kubespray의 기본 설정값을 이용해 클러스터를 배포하고 Kubernetes를 탐색하는 것이 좋다. +Kubespray의 [변수 파일들](https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html)을 사용자가 정의할 수 있다. 만약 Kubespray를 처음 접하는 경우, kubespray의 기본 설정값을 이용해 클러스터를 배포하고 Kubernetes를 탐색하는 것이 좋다. ### (4/5) 클러스터 배포하기 diff --git a/content/ko/docs/setup/production-environment/turnkey-solutions.md b/content/ko/docs/setup/production-environment/turnkey-solutions.md new file mode 100644 index 0000000000..2feb5de30a --- /dev/null +++ b/content/ko/docs/setup/production-environment/turnkey-solutions.md @@ -0,0 +1,14 @@ +--- +title: 턴키 클라우드 솔루션 +content_type: concept +weight: 30 +--- + + +이 페이지는 인증된 쿠버네티스 솔루션 제공자 목록을 제공한다. 각 제공자 +페이지를 통해서, 프로덕션에 준비된 클러스터를 설치 및 설정하는 방법을 +학습할 수 있다. + + + +{{< cncf-landscape helpers=true category="certified-kubernetes-hosted" >}} diff --git a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md index b488e6c04d..67db901778 100644 --- a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md @@ -2,27 +2,57 @@ title: 쿠버네티스의 윈도우 지원 소개 content_type: concept weight: 65 + + + + + --- -윈도우 애플리케이션은 많은 조직에서 실행되는 서비스 및 애플리케이션의 상당 부분을 구성한다. [윈도우 컨테이너](https://aka.ms/windowscontainers)는 프로세스와 패키지 종속성을 캡슐화하는 현대적인 방법을 제공하여, 데브옵스(DevOps) 사례를 더욱 쉽게 ​​사용하고 윈도우 애플리케이션의 클라우드 네이티브 패턴을 따르도록 한다. 쿠버네티스는 사실상의 표준 컨테이너 오케스트레이터가 되었으며, 쿠버네티스 1.14 릴리스에는 쿠버네티스 클러스터의 윈도우 노드에서 윈도우 컨테이너 스케줄링을 위한 프로덕션 지원이 포함되어 있어, 광범위한 윈도우 애플리케이션 생태계가 쿠버네티스의 강력한 기능을 활용할 수 있다. 윈도우 기반 애플리케이션과 리눅스 기반 애플리케이션에 투자한 조직은 워크로드를 관리하기 위해 별도의 오케스트레이터를 찾을 필요가 없으므로, 운영 체제와 관계없이 배포 전반에 걸쳐 운영 효율성이 향상된다. +윈도우 애플리케이션은 많은 조직에서 실행되는 서비스 및 +애플리케이션의 상당 부분을 구성한다. +[윈도우 컨테이너](https://aka.ms/windowscontainers)는 프로세스와 패키지 종속성을 +캡슐화하는 현대적인 방법을 제공하여, 데브옵스(DevOps) +사례를 더욱 쉽게 사용하고 윈도우 애플리케이션의 클라우드 네이티브 패턴을 따르도록 한다. +쿠버네티스는 사실상의 표준 컨테이너 오케스트레이터가 되었으며, +쿠버네티스 1.14 릴리스에는 쿠버네티스 클러스터의 윈도우 노드에서 윈도우 +컨테이너 스케줄링을 위한 프로덕션 지원이 포함되어 있어, 광범위한 윈도우 애플리케이션 생태계가 +쿠버네티스의 강력한 기능을 활용할 수 있다. 윈도우 기반 애플리케이션과 +리눅스 기반 애플리케이션에 투자한 조직은 워크로드를 관리하기 위해 +별도의 오케스트레이터를 찾을 필요가 없으므로, +운영 체제와 관계없이 배포 전반에 걸쳐 +운영 효율성이 향상된다. ## 쿠버네티스의 윈도우 컨테이너 -쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 리눅스 클러스터에 윈도우 노드를 포함한다. 쿠버네티스의 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 윈도우 컨테이너를 스케줄링하는 것은 리눅스 기반 컨테이너를 스케줄링하는 것과 유사하다. +쿠버네티스에서 윈도우 컨테이너 오케스트레이션을 활성화하려면, 기존 +리눅스 클러스터에 윈도우 노드를 포함한다. 쿠버네티스의 +{{< glossary_tooltip text="파드" term_id="pod" >}}에서 윈도우 컨테이너를 스케줄링하는 것은 +리눅스 기반 컨테이너를 스케줄링하는 것과 유사하다. -윈도우 컨테이너를 실행하려면, 쿠버네티스 클러스터에 리눅스를 실행하는 컨트롤 플레인 노드와 사용자의 워크로드 요구에 따라 윈도우 또는 리눅스를 실행하는 워커가 있는 여러 운영 체제가 포함되어 있어야 한다. 윈도우 서버 2019는 윈도우에서 [쿠버네티스 노드](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)를 활성화하는 유일한 윈도우 운영 체제이다(kubelet, [컨테이너 런타임](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/containerd) 및 kube-proxy 포함). 윈도우 배포 채널에 대한 자세한 설명은 [Microsoft 문서](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)를 참고한다. +윈도우 컨테이너를 실행하려면, 쿠버네티스 클러스터에 리눅스를 +실행하는 컨트롤 플레인 노드와 사용자의 워크로드 요구에 따라 윈도우 또는 리눅스를 +실행하는 워커가 있는 여러 운영 체제가 포함되어 있어야 한다. 윈도우 +서버 2019는 윈도우에서 +[쿠버네티스 노드](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)를 +활성화하는 유일한 윈도우 운영 체제이다(kubelet, +[컨테이너 런타임](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/containerd) +및 kube-proxy 포함). 윈도우 배포 채널에 대한 자세한 설명은 +[Microsoft 문서](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)를 참고한다. -{{< note >}} -[마스터 컴포넌트](/ko/docs/concepts/overview/components/)를 포함한 쿠버네티스 컨트롤 플레인은 리눅스에서 계속 실행된다. 윈도우 전용 쿠버네티스 클러스터는 계획이 없다. -{{< /note >}} +[마스터 컴포넌트](/ko/docs/concepts/overview/components/)를 포함한 +쿠버네티스 컨트롤 플레인은 +리눅스에서 계속 실행된다. +윈도우 전용 쿠버네티스 클러스터는 계획이 없다. -{{< note >}} -이 문서에서 윈도우 컨테이너에 대해 이야기할 때 프로세스 격리된 윈도우 컨테이너를 의미한다. [Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container)가 있는 윈도우 컨테이너는 향후 릴리스로 계획되어 있다. -{{< /note >}} +이 문서에서 윈도우 컨테이너에 대해 이야기할 때 +프로세스 격리된 윈도우 컨테이너를 의미한다. +[Hyper-V 격리](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/hyperv-container)가 +있는 윈도우 컨테이너는 향후 릴리스로 계획되어 있다. ## 지원되는 기능 및 제한 @@ -30,41 +60,70 @@ weight: 65 #### 윈도우 OS 버전 지원 -쿠버네티스의 윈도우 운영 체제 지원은 다음 표를 참조한다. 단일 이기종 쿠버네티스 클러스터에는 윈도우 및 리눅스 워커 노드가 모두 있을 수 있다. 윈도우 컨테이너는 윈도우 노드에서, 리눅스 컨테이너는 리눅스 노드에서 스케줄되어야 한다. +쿠버네티스의 윈도우 운영 체제 지원은 다음 표를 +참조한다. 단일 이기종 쿠버네티스 클러스터에는 윈도우 및 +리눅스 워커 노드가 모두 있을 수 있다. 윈도우 컨테이너는 윈도우 노드에서, +리눅스 컨테이너는 리눅스 노드에서 스케줄되어야 한다. | 쿠버네티스 버전 | 윈도우 서버 LTSC 릴리스 | 윈도우 서버 SAC 릴리스 | | --- | --- | --- | --- | -| *Kubernetes v1.17* | Windows Server 2019 | Windows Server ver 1809 | -| *Kubernetes v1.18* | Windows Server 2019 | Windows Server ver 1809, Windows Server ver 1903, Windows Server ver 1909 | | *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 | | *Kubernetes v1.20* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 | +| *Kubernetes v1.21* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 | -{{< note >}} -지원 모델을 포함한 다양한 윈도우 서버 서비스 채널에 대한 정보는 [윈도우 서버 서비스 채널](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)에서 확인할 수 있다. -{{< /note >}} -{{< note >}} -모든 윈도우 고객이 앱의 운영 체제를 자주 업데이트하는 것은 아니다. 애플리케이션 업그레이드를 위해서는 클러스터에 새 노드를 업그레이드하거나 도입하는 것이 필요하다. 이 문서에서 쿠버네티스에서 실행되는 컨테이너의 운영 체제를 업그레이드하기로 선택한 고객을 위해 새 운영 체제 버전에 대한 지원을 추가할 때의 가이드와 단계별 지침을 제공한다. 이 가이드에는 클러스터 노드와 함께 사용자 애플리케이션을 업그레이드하기 위한 권장 업그레이드 절차가 포함된다. 윈도우 노드는 현재 리눅스 노드와 동일한 방식으로 쿠버네티스 [버전-스큐(skew) 정책](/ko/docs/setup/release/version-skew-policy/)(노드 대 컨트롤 플레인 버전 관리)을 준수한다. -{{< /note >}} -{{< note >}} -윈도우 서버 호스트 운영 체제에는 [윈도우 서버](https://www.microsoft.com/ko-kr/cloud-platform/windows-server-pricing) 라이선스가 적용된다. 윈도우 컨테이너 이미지에는 [윈도우 컨테이너에 대한 추가 사용 조건](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula)이 적용된다. -{{< /note >}} -{{< note >}} -프로세스 격리가 포함된 윈도우 컨테이너에는 엄격한 호환성 규칙이 있으며, [여기서 호스트 OS 버전은 컨테이너 베이스 이미지 OS 버전과 일치해야 한다](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/version-compatibility). 일단 쿠버네티스에서 Hyper-V 격리가 포함된 윈도우 컨테이너를 지원하면, 제한 및 호환성 규칙이 변경될 것이다. -{{< /note >}} + +지원 모델을 포함한 다양한 윈도우 서버 +서비스 채널에 대한 정보는 +[윈도우 서버 서비스 채널](https://docs.microsoft.com/ko-kr/windows-server/get-started-19/servicing-channels-19)에서 확인할 수 있다. + +모든 윈도우 고객이 앱의 운영 체제를 자주 업데이트하는 것은 +아니다. 애플리케이션 업그레이드를 위해서는 클러스터에 새 노드를 +업그레이드하거나 도입하는 것이 필요하다. 이 문서에서 +쿠버네티스에서 실행되는 컨테이너의 운영 체제를 업그레이드하기로 선택한 +고객을 위해 새 운영 체제 버전에 대한 지원을 추가할 때의 가이드와 +단계별 지침을 제공한다. 이 가이드에는 클러스터 노드와 함께 사용자 애플리케이션을 +업그레이드하기 위한 권장 업그레이드 절차가 포함된다. +윈도우 노드는 현재 리눅스 노드와 동일한 방식으로 쿠버네티스 +[버전-차이(skew) 정책](/ko/releases/version-skew-policy/)(노드 대 컨트롤 플레인 +버전 관리)을 준수한다. + + +윈도우 서버 호스트 운영 체제에는 +[윈도우 서버](https://www.microsoft.com/ko-kr/cloud-platform/windows-server-pricing) +라이선스가 적용된다. 윈도우 컨테이너 이미지에는 +[윈도우 컨테이너에 대한 추가 사용 조건](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula)이 적용된다. + +프로세스 격리가 포함된 윈도우 컨테이너에는 엄격한 호환성 규칙이 있으며, +[여기서 호스트 OS 버전은 컨테이너 베이스 이미지 OS 버전과 일치해야 한다](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/deploy-containers/version-compatibility). +일단 쿠버네티스에서 Hyper-V 격리가 포함된 윈도우 컨테이너를 지원하면, +제한 및 호환성 규칙이 변경될 것이다. #### 퍼즈(Pause) 이미지 -Microsoft는 `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`에서 윈도우 퍼즈 인프라 컨테이너를 유지한다. +Microsoft는 `mcr.microsoft.com/oss/kubernetes/pause:3.4.1`에서 +윈도우 퍼즈 인프라 컨테이너를 유지한다. +이외에도 `k8s.gcr.io/pause:3.5`를 통해 쿠버네티스에서 관리하는 다중 아키텍처 이미지를 +사용할 수도 있는데, 이 이미지는 리눅스와 윈도우를 모두 지원한다. #### 컴퓨트 -API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨테이너와 거의 같은 방식으로 작동한다. 그러나 [제한 섹션](#제한)에 요약된 주요 기능에는 몇 가지 눈에 띄는 차이점이 있다. +API 및 kubectl의 관점에서, 윈도우 컨테이너는 +리눅스 기반 컨테이너와 거의 같은 방식으로 작동한다. 그러나 +[제한 섹션](#제한)에 요약된 주요 기능에는 +몇 가지 눈에 띄는 차이점이 있다. -윈도우에서 주요 쿠버네티스 요소는 리눅스와 동일한 방식으로 작동한다. 이 섹션에서는, 주요 워크로드 인에이블러(enabler) 일부와 이들이 윈도우에 매핑되는 방법에 대해 설명한다. +윈도우에서 주요 쿠버네티스 요소는 리눅스와 동일한 방식으로 작동한다. 이 +섹션에서는, 주요 워크로드 인에이블러(enabler) 일부와 이들이 윈도우에 매핑되는 방법에 +대해 설명한다. * [파드](/ko/docs/concepts/workloads/pods/) - 파드는 쿠버네티스의 기본 빌딩 블록이다 - 쿠버네티스 오브젝트 모델에서 생성하고 배포하는 가장 작고 간단한 단위. 동일한 파드에 윈도우 및 리눅스 컨테이너를 배포할 수 없다. 파드의 모든 컨테이너는 단일 노드로 스케줄되며 각 노드는 특정 플랫폼 및 아키텍처를 나타낸다. 다음과 같은 파드 기능, 속성 및 이벤트가 윈도우 컨테이너에서 지원된다. + 파드는 쿠버네티스의 기본 빌딩 블록이다 - 쿠버네티스 오브젝트 모델에서 + 생성하고 배포하는 가장 작고 간단한 단위. 동일한 파드에 + 윈도우 및 리눅스 컨테이너를 배포할 수 없다. 파드의 모든 컨테이너는 + 단일 노드로 스케줄되며 각 노드는 특정 플랫폼 및 + 아키텍처를 나타낸다. 다음과 같은 파드 기능, 속성 및 + 이벤트가 윈도우 컨테이너에서 지원된다. * 프로세스 분리 및 볼륨 공유 기능을 갖춘 파드 당 하나 또는 여러 개의 컨테이너 * 파드 상태 필드 @@ -76,7 +135,8 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨 * 리소스 제한 * [컨트롤러](/ko/docs/concepts/workloads/controllers/) - 쿠버네티스 컨트롤러는 파드의 의도한 상태(desired state)를 처리한다. 윈도우 컨테이너에서 지원되는 워크로드 컨트롤러는 다음과 같다. + 쿠버네티스 컨트롤러는 파드의 의도한 상태(desired state)를 처리한다. 윈도우 + 컨테이너에서 지원되는 워크로드 컨트롤러는 다음과 같다. * 레플리카셋(ReplicaSet) * 레플리케이션컨트롤러(ReplicationController) @@ -87,7 +147,10 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨 * 크론잡(CronJob) * [서비스](/ko/docs/concepts/services-networking/service/) - 쿠버네티스 서비스는 논리적인 파드 집합과 그것에(마이크로 서비스라고도 함) 접근하는 정책을 정의하는 추상화 개념이다. 상호-운영 체제 연결을 위해 서비스를 사용할 수 있다. 윈도우에서 서비스는 다음의 유형, 속성 및 기능을 활용할 수 있다. + 쿠버네티스 서비스는 논리적인 파드 집합과 그것에(마이크로 서비스라고도 함) + 접근하는 정책을 정의하는 추상화 개념이다. 상호-운영 체제 + 연결을 위해 서비스를 사용할 수 있다. 윈도우에서 서비스는 + 다음의 유형, 속성 및 기능을 활용할 수 있다. * 서비스 환경 변수 * 노드포트(NodePort) @@ -96,7 +159,10 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨 * ExternalName * 헤드리스 서비스(Headless services) -파드, 컨트롤러 및 서비스는 쿠버네티스에서 윈도우 워크로드를 관리하는데 중요한 요소이다. 그러나 그 자체로는 동적 클라우드 네이티브 환경에서 윈도우 워크로드의 적절한 수명 주기 관리를 수행하기에 충분하지 않다. 다음 기능에 대한 지원이 추가되었다. +파드, 컨트롤러 및 서비스는 쿠버네티스에서 윈도우 워크로드를 +관리하는데 중요한 요소이다. 그러나 그 자체로는 동적 클라우드 네이티브 환경에서 +윈도우 워크로드의 적절한 수명 주기 관리를 수행하기에 +충분하지 않다. 다음 기능에 대한 지원이 추가되었다. * 파드와 컨테이너 메트릭 * Horizontal Pod Autoscaler 지원 @@ -110,27 +176,42 @@ API 및 kubectl의 관점에서, 윈도우 컨테이너는 리눅스 기반 컨 {{< feature-state for_k8s_version="v1.14" state="stable" >}} -Docker EE-basic 19.03 이상은 모든 윈도우 서버 버전에 대해 권장되는 컨테이너 런타임이다. 이것은 kubelet에 포함된 dockershim 코드와 함께 작동한다. +Docker EE-basic 19.03 이상은 모든 윈도우 서버 버전에 대해 권장되는 +컨테이너 런타임이다. 이것은 kubelet에 포함된 dockershim 코드와 함께 작동한다. ##### CRI-ContainerD {{< feature-state for_k8s_version="v1.20" state="stable" >}} -{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+는 윈도우 쿠버네티스 노드의 컨테이너 런타임으로도 사용할 수 있다. +{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+는 +윈도우 쿠버네티스 노드의 컨테이너 런타임으로도 사용할 수 있다. -[윈도우에 ContainerD 설치](/ko/docs/setup/production-environment/container-runtimes/#containerd-설치) 방법을 확인한다. - -{{< caution >}} -ContainerD와 함께 GMSA를 사용하여 커널 패치가 필요한 윈도우 네트워크 공유에 액세스 할 때 [알려진 제한](/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)이 있다. 이 제한을 해결하기위한 업데이트는 현재 Windows Server, 버전 2004에서 사용할 수 있으며 2021년 초에 Windows Server 2019에서 사용할 수 있다. [Microsoft 윈도우 컨테이너 이슈 트래커](https://github.com/microsoft/Windows-Containers/issues/44)에서 업데이트를 확인한다. -{{< /caution >}} +[윈도우에 ContainerD 설치](/ko/docs/setup/production-environment/container-runtimes/#containerd-설치) +방법을 확인한다. #### 퍼시스턴트 스토리지(Persistent Storage) -쿠버네티스 [볼륨](/ko/docs/concepts/storage/volumes/)을 사용하면 데이터 지속성(persistence) 및 파드 볼륨 공유 요구 사항이 있는 복잡한 애플리케이션을 쿠버네티스에 배포할 수 있다. 특정 스토리지 백엔드 또는 프로토콜과 관련된 퍼시스턴트 볼륨 관리에는 볼륨 프로비저닝/디-프로비저닝/크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 데이터를 유지해야 하는 파드의 개별 컨테이너에 볼륨 마운트/분리와 같은 작업이 포함된다. 특정 스토리지 백엔드 또는 프로토콜에 대해 이러한 볼륨 관리 작업을 구현하는 코드는 쿠버네티스 볼륨 [플러그인](/ko/docs/concepts/storage/volumes/#볼륨-유형들)의 형태로 제공된다. 다음과 같은 광범위한 쿠버네티스 볼륨 플러그인 클래스가 윈도우에서 지원된다. +쿠버네티스 [볼륨](/ko/docs/concepts/storage/volumes/)을 사용하면 +데이터 지속성(persistence) 및 파드 볼륨 공유 요구 사항이 있는 복잡한 애플리케이션을 +쿠버네티스에 배포할 수 있다. 특정 스토리지 백엔드 또는 +프로토콜과 관련된 퍼시스턴트 볼륨 관리에는 +볼륨 프로비저닝/디-프로비저닝/크기 조정, 쿠버네티스 노드에 볼륨 +연결/분리, 데이터를 유지해야 하는 파드의 개별 컨테이너에 볼륨 +마운트/분리와 같은 작업이 포함된다. 특정 스토리지 백엔드 또는 +프로토콜에 대해 이러한 볼륨 관리 작업을 +구현하는 코드는 쿠버네티스 볼륨 +[플러그인](/ko/docs/concepts/storage/volumes/#볼륨-유형들)의 형태로 제공된다. 다음과 같은 +광범위한 쿠버네티스 볼륨 플러그인 클래스가 윈도우에서 지원된다. ##### 인-트리(In-tree) 볼륨 플러그인 -인-트리 볼륨 플러그인과 관련된 코드는 핵심 쿠버네티스 코드 베이스의 일부로 제공된다. 인-트리 볼륨 플러그인 배포는 추가 스크립트를 설치하거나 별도의 컨테이너화된 플러그인 컴포넌트를 배포할 필요가 없다. 이러한 플러그인들은 볼륨 프로비저닝/디-프로비저닝, 스토리지 백엔드 볼륨 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리를 처리할 수 있다. 다음의 인-트리 플러그인은 윈도우 노드를 지원한다. +인-트리 볼륨 플러그인과 관련된 코드는 핵심 쿠버네티스 +코드 베이스의 일부로 제공된다. 인-트리 볼륨 플러그인 배포는 +추가 스크립트를 설치하거나 별도의 컨테이너화된 플러그인 컴포넌트를 +배포할 필요가 없다. 이러한 플러그인들은 +볼륨 프로비저닝/디-프로비저닝, 스토리지 백엔드 볼륨 크기 조정, 쿠버네티스 노드에 +볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리를 +처리할 수 있다. 다음의 인-트리 플러그인은 윈도우 노드를 지원한다. * [awsElasticBlockStore](/ko/docs/concepts/storage/volumes/#awselasticblockstore) * [azureDisk](/ko/docs/concepts/storage/volumes/#azuredisk) @@ -140,7 +221,16 @@ ContainerD와 함께 GMSA를 사용하여 커널 패치가 필요한 윈도우 ##### FlexVolume 플러그인 -[FlexVolume](/ko/docs/concepts/storage/volumes/#flexVolume) 플러그인과 관련된 코드는 아웃-오브-트리(out-of-tree) 스크립트 또는 호스트에 직접 배포해야 하는 바이너리로 제공된다. FlexVolume 플러그인은 쿠버네티스 노드에 볼륨 연결/분리 및 파드의 개별 컨테이너에 볼륨 마운트/분리를 처리한다. FlexVolume 플러그인과 관련된 퍼시스턴트 볼륨의 프로비저닝/디-프로비저닝은 일반적으로 FlexVolume 플러그인과는 별도의 외부 프로비저너를 통해 처리될 수 있다. 호스트에서 powershell 스크립트로 배포된 다음의 FlexVolume [플러그인](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows)은 윈도우 노드를 지원한다. +[FlexVolume](/ko/docs/concepts/storage/volumes/#flexVolume) +플러그인과 관련된 코드는 아웃-오브-트리(out-of-tree) 스크립트 또는 호스트에 직접 배포해야 하는 +바이너리로 제공된다. FlexVolume 플러그인은 쿠버네티스 노드에 볼륨 +연결/분리 및 파드의 개별 컨테이너에 볼륨 마운트/분리를 +처리한다. FlexVolume 플러그인과 관련된 퍼시스턴트 볼륨의 +프로비저닝/디-프로비저닝은 일반적으로 FlexVolume 플러그인과는 별도의 외부 +프로비저너를 통해 처리될 수 있다. 호스트에서 +powershell 스크립트로 배포된 다음의 FlexVolume +[플러그인](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows)은 +윈도우 노드를 지원한다. * [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd) * [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd) @@ -149,13 +239,40 @@ ContainerD와 함께 GMSA를 사용하여 커널 패치가 필요한 윈도우 {{< feature-state for_k8s_version="v1.19" state="beta" >}} -{{< glossary_tooltip text="CSI" term_id="csi" >}} 플러그인과 관련된 코드는 일반적으로 컨테이너 이미지로 배포되고 데몬셋(DaemonSets) 및 스테이트풀셋(StatefulSets)과 같은 표준 쿠버네티스 구성을 사용하여 배포되는 아웃-오브-트리 스크립트 및 바이너리로 제공된다. CSI 플러그인은 쿠버네티스에서 볼륨 프로비저닝/디-프로비저닝, 볼륨 크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 마운트/분리, 스냅샷 및 복제를 사용하여 퍼시스턴트 데이터 백업/복원과 같은 다양한 볼륨 관리 작업을 처리한다. CSI 플러그인은 일반적으로 (각 노드에서 데몬셋으로 실행되는) 노드 플러그인과 컨트롤러 플러그인으로 구성된다. +{{< glossary_tooltip text="CSI" term_id="csi" >}} 플러그인과 +관련된 코드는 일반적으로 컨테이너 이미지로 배포되고 데몬셋(DaemonSets) +및 스테이트풀셋(StatefulSets)과 같은 +표준 쿠버네티스 구성을 사용하여 배포되는 아웃-오브-트리 스크립트 및 +바이너리로 제공된다. CSI 플러그인은 쿠버네티스에서 볼륨 프로비저닝/디-프로비저닝, 볼륨 +크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨 +마운트/분리, 스냅샷 및 복제를 사용하여 퍼시스턴트 데이터 백업/복원과 같은 +다양한 볼륨 관리 작업을 처리한다. CSI 플러그인은 +일반적으로 (각 노드에서 데몬셋으로 실행되는) 노드 플러그인과 컨트롤러 +플러그인으로 구성된다. -CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템으로 노출된 퍼시스턴트 볼륨과 관련된 플러그인)은 디스크 장치 스캔, 파일 시스템 마운트 등과 같은 다양한 특권이 필요한(privileged) 작업을 수행해야 한다. 이러한 작업은 호스트 운영 체제마다 다르다. 리눅스 워커 노드의 경우 컨테이너화된 CSI 노드 플러그인은 일반적으로 특권을 가진 컨테이너로 배포된다. 윈도우 워커 노드의 경우 컨테이너화된 CSI 노드 플러그인에 대한 특권이 필요한 작업은 커뮤니티에서 관리되고, 각 윈도우 노드에 사전 설치되어야 하는 독립형(stand-alone) 바이너리인 [csi-proxy](https://github.com/kubernetes-csi/csi-proxy)를 사용하여 지원된다. 자세한 내용은 배포하려는 CSI 플러그인의 배포 가이드를 참조한다. +CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템으로 노출된 +퍼시스턴트 볼륨과 관련된 플러그인)은 디스크 장치 스캔, 파일 시스템 마운트 등과 같은 +다양한 특권이 필요한(privileged) 작업을 수행해야 +한다. 이러한 작업은 호스트 운영 체제마다 다르다. 리눅스 워커 +노드의 경우 컨테이너화된 CSI 노드 플러그인은 일반적으로 특권을 가진 +컨테이너로 배포된다. 윈도우 워커 노드의 경우 컨테이너화된 +CSI 노드 플러그인에 대한 특권이 필요한 작업은 커뮤니티에서 관리되고, +각 윈도우 노드에 사전 설치되어야 하는 독립형(stand-alone) 바이너리인 +[csi-proxy](https://github.com/kubernetes-csi/csi-proxy)를 사용하여 지원된다. 자세한 +내용은 배포하려는 CSI 플러그인의 배포 가이드를 +참조한다. #### 네트워킹 -윈도우 컨테이너용 네트워킹은 [CNI 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 노출된다. 윈도우 컨테이너는 네트워킹과 관련하여 가상 머신과 유사하게 작동한다. 각 컨테이너에는 Hyper-V 가상 스위치(vSwitch)에 연결된 가상 네트워크 어댑터(vNIC)가 있다. 호스트 네트워킹 서비스(HNS)와 호스트 컴퓨팅 서비스(HCS)는 함께 작동하여 컨테이너를 만들고 컨테이너 vNIC을 네트워크에 연결한다. HCS는 컨테이너 관리를 담당하는 반면 HNS는 다음과 같은 네트워킹 리소스 관리를 담당한다. +윈도우 컨테이너용 네트워킹은 +[CNI 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)을 통해 노출된다. +윈도우 컨테이너는 네트워킹과 관련하여 가상 머신과 유사하게 +작동한다. 각 컨테이너에는 Hyper-V 가상 스위치(vSwitch)에 연결된 +가상 네트워크 어댑터(vNIC)가 있다. 호스트 네트워킹 서비스(HNS)와 +호스트 컴퓨팅 서비스(HCS)는 함께 작동하여 컨테이너를 만들고 +컨테이너 vNIC을 네트워크에 연결한다. HCS는 컨테이너 관리를 +담당하는 반면 HNS는 다음과 같은 네트워킹 리소스 관리를 +담당한다. * 가상 네트워크(vSwitch 생성 포함) * 엔드포인트 / vNIC @@ -171,19 +288,155 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템 ##### 네트워크 모드 -윈도우는 L2bridge, L2tunnel, Overlay, Transparent 및 NAT의 다섯 가지 네트워킹 드라이버/모드를 지원한다. 윈도우와 리눅스 워커 노드가 있는 이기종 클러스터에서는 윈도우와 리눅스 모두에서 호환되는 네트워킹 솔루션을 선택해야 한다. 윈도우에서 다음과 같은 out-of-tree 플러그인이 지원되며 각 CNI 사용 시 권장 사항이 있다. +윈도우는 L2bridge, L2tunnel, Overlay, Transparent 및 +NAT의 다섯 가지 네트워킹 드라이버/모드를 지원한다. 윈도우와 리눅스 워커 노드가 +있는 이기종 클러스터에서는 윈도우와 리눅스 모두에서 호환되는 네트워킹 +솔루션을 선택해야 한다. 윈도우에서 다음과 같은 out-of-tree 플러그인이 지원되며 +각 CNI 사용 시 권장 사항이 있다. -| 네트워크 드라이버 | 설명 | 컨테이너 패킷 수정 | 네트워크 플러그인 | 네트워크 플러그인 특성 | -| -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ | -| L2bridge | 컨테이너는 외부 vSwitch에 연결된다. 컨테이너는 언더레이 네트워크에 연결된다. 하지만 인그레스/이그레스시에 재작성되기 때문에 물리적 네트워크가 컨테이너 MAC을 학습할 필요가 없다. | MAC은 호스트 MAC에 다시 쓰여지고, IP는 HNS OutboundNAT 정책을 사용하여 호스트 IP에 다시 쓰여질 수 있다. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel 호스트 게이트웨이는 win-bridge를 사용한다. | win-bridge는 L2bridge 네트워크 모드를 사용하고, 컨테이너를 호스트의 언더레이에 연결하여 최상의 성능을 제공한다. 노드 간 연결을 위해 사용자 정의 경로(user-defined routes, UDR)가 필요하다. | -| L2Tunnel | 이것은 l2bridge의 특별한 케이스이지만 Azure에서만 사용된다. 모든 패킷은 SDN 정책이 적용되는 가상화 호스트로 전송된다. | MAC 재작성되고, 언더레이 네트워크 상에서 IP가 보인다. | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI를 사용하면 컨테이너를 Azure vNET과 통합할 수 있으며, [Azure Virtual Network에서 제공하는](https://azure.microsoft.com/ko-kr/services/virtual-network/) 기능 집합을 활용할 수 있다. 예를 들어 Azure 서비스에 안전하게 연결하거나 Azure NSG를 사용한다. [azure-cni 예제](https://docs.microsoft.com/ko-kr/azure/aks/concepts-network#azure-cni-advanced-networking)를 참고한다. | -| 오버레이(쿠버네티스에서 윈도우용 오버레이 네트워킹은 *알파* 단계에 있음) | 컨테이너에는 외부 vSwitch에 연결된 vNIC이 제공된다. 각 오버레이 네트워크는 사용자 지정 IP 접두사로 정의된 자체 IP 서브넷을 가져온다. 오버레이 네트워크 드라이버는 VXLAN 캡슐화를 사용한다. | 외부 헤더로 캡슐화된다. | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN(win-overlay 사용) | win-overlay는 가상 컨테이너 네트워크를 호스트의 언더레이에서 격리하려는 경우(예: 보안 상의 이유로) 사용해야 한다. 데이터 센터의 IP에 제한이 있는 경우, (다른 VNID 태그가 있는) 다른 오버레이 네트워크에 IP를 재사용할 수 있다. 이 옵션을 사용하려면 윈도우 서버 2019에서 [KB4489899](https://support.microsoft.com/help/4489899)가 필요하다. | -| Transparent([ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)의 특수한 유스케이스) | 외부 vSwitch가 필요하다. 컨테이너는 논리적 네트워크(논리적 스위치 및 라우터)를 통해 파드 내 통신을 가능하게 하는 외부 vSwitch에 연결된다. | 패킷은 [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) 또는 [STT](https://datatracker.ietf.org/doc/draft-davie-stt)를 통해 캡슐화되는데, 동일한 호스트에 있지 않은 파드에 도달하기 위한 터널링을 한다.
    패킷은 ovn 네트워크 컨트롤러에서 제공하는 터널 메타데이터 정보를 통해 전달되거나 삭제된다.
    NAT는 north-south 통신(데이터 센터와 클라이언트, 네트워크 상의 데이터 센터 외부와의 통신)을 위해 수행된다. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [ansible을 통해 배포](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib)한다. 분산 ACL은 쿠버네티스 정책을 통해 적용할 수 있다. IPAM을 지원한다. kube-proxy 없이 로드 밸런싱을 수행할 수 있다. NAT를 수행할 때 iptables/netsh를 사용하지 않고 수행된다. | -| NAT(*쿠버네티스에서 사용되지 않음*) | 컨테이너에는 내부 vSwitch에 연결된 vNIC이 제공된다. DNS/DHCP는 [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/)라는 내부 컴포넌트를 사용하여 제공된다. | MAC 및 IP는 호스트 MAC/IP에 다시 작성된다. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | 완전성을 위해 여기에 포함되었다. | + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    네트워크 드라이버설명컨테이너 패킷 수정네트워크 플러그인네트워크 플러그인 특성
    L2bridge컨테이너는 외부 vSwitch에 연결된다. 컨테이너는 + 언더레이 네트워크에 연결된다. 하지만 인그레스/이그레스시에 재작성되기 + 때문에 물리적 네트워크가 컨테이너 MAC을 학습할 필요가 없다. + + MAC은 호스트 MAC에 다시 쓰여지고, IP는 HNS OutboundNAT 정책을 사용하여 + 호스트 IP에 다시 쓰여질 수 있다. + + win-bridge, + Azure-CNI, + Flannel 호스트 게이트웨이는 win-bridge를 사용한다. + + win-bridge는 L2bridge 네트워크 모드를 사용하고, + 컨테이너를 호스트의 언더레이에 연결하여 최상의 성능을 제공한다. + 노드 간 연결을 위해 사용자 정의 경로(user-defined routes, UDR)가 필요하다. +
    L2Tunnel + 이것은 l2bridge의 특별한 케이스이지만 Azure에서만 사용된다. 모든 패킷은 + SDN 정책이 적용되는 가상화 호스트로 전송된다. + + MAC 재작성되고, 언더레이 네트워크 상에서 IP가 보인다. + + Azure-CNI + + Azure-CNI를 사용하면 컨테이너를 Azure vNET과 통합할 수 있으며, + Azure Virtual Network에서 + 제공하는 기능 집합을 활용할 수 있다. + 예를 들어, Azure 서비스에 안전하게 연결하거나 Azure NSG를 사용한다. + azure-cni + 예제를 참고한다. +
    오버레이(쿠버네티스에서 윈도우용 오버레이 네트워킹은 알파 단계에 있음) + 컨테이너에는 외부 vSwitch에 연결된 vNIC이 제공된다. 각 오버레이 + 네트워크는 사용자 지정 IP 접두사로 정의된 자체 IP 서브넷을 가져온다. 오버레이 + 네트워크 드라이버는 VXLAN 캡슐화를 사용한다. + + 외부 헤더로 캡슐화된다. + + Win-overlay, + Flannel VXLAN (win-overlay 사용) + + win-overlay는 가상 컨테이너 네트워크를 호스트의 + 언더레이에서 격리하려는 경우(예: 보안 상의 이유로) 사용해야 한다. 데이터 센터의 IP에 + 제한이 있는 경우, (다른 VNID 태그가 있는) 다른 오버레이 + 네트워크에 IP를 재사용할 수 있다. 이 옵션을 사용하려면 + 윈도우 서버 2019에서 KB4489899가 + 필요하다. +
    + Transparent(ovn-kubernetes의 특수한 유스케이스) + + 외부 vSwitch가 필요하다. 컨테이너는 논리적 네트워크(논리적 스위치 및 라우터)를 + 통해 파드 내 통신을 가능하게 하는 외부 vSwitch에 + 연결된다. + + 패킷은 + GENEVE, + STT 터널링을 통해 + 캡슐화되는데, 동일한 호스트에 있지 않은 파드에 도달하기 위한 터널링을 한다.
    패킷은 ovn 네트워크 + 컨트롤러에서 제공하는 터널 메타데이터 정보를 통해 전달되거나 삭제된다. +
    + NAT는 north-south 통신(데이터 센터와 클라이언트, 네트워크 상의 데이터 센터 외부와의 통신)을 위해 수행된다. +     		+ ovn-kubernetes + + Ansible을 통해 배포한다. + 분산 ACL은 쿠버네티스 정책을 통해 적용할 수 있다. IPAM을 지원한다. + kube-proxy 없이 로드 밸런싱을 수행할 수 있다. NAT를 수행할 때 + iptables/netsh를 사용하지 않고 수행된다. +
    NAT (쿠버네티스에서 사용되지 않음) + 컨테이너에는 내부 vSwitch에 연결된 vNIC이 제공된다. DNS/DHCP는 + WinNAT라는 + 내부 컴포넌트를 사용하여 제공된다. + + MAC 및 IP는 호스트 MAC/IP에 다시 작성된다. + + nat + + 완전성을 위해 여기에 포함되었다. +
    -위에서 설명한대로 [플란넬(Flannel)](https://github.com/coreos/flannel) CNI [메타 플러그인](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)은 [VXLAN 네트워크 백엔드](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)(**alpha 지원**, win-overlay에 위임) 및 [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (안정적인 지원, win-bridge에 위임)를 통해 [윈도우](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental)에서도 지원된다. 이 플러그인은 자동 노드 서브넷 임대 할당과 HNS 네트워크 생성을 위해 윈도우 (Flanneld)에서 Flannel 데몬과 함께 작동하도록 참조 CNI 플러그인 (win-overlay, win-bridge) 중 하나에 대한 위임을 지원한다. 이 플러그인은 자체 구성 파일 (cni.conf)을 읽고, 이를 FlannelD 생성하는 subnet.env 파일의 환경 변수와 함께 집계한다. 이후 네트워크 연결을 위한 참조 CNI 플러그인 중 하나에 위임하고 노드 할당 서브넷을 포함하는 올바른 구성을 IPAM 플러그인 (예: 호스트-로컬)으로 보낸다. +위에서 설명한대로 [플란넬(Flannel)](https://github.com/coreos/flannel) CNI +[메타 플러그인](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)은 +[VXLAN 네트워크 백엔드](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) +(**alpha 지원**, win-overlay에 위임) 및 +[host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) +(안정적인 지원, win-bridge에 위임)를 통해 +[윈도우](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental)에서도 +지원된다. 이 플러그인은 자동 노드 서브넷 +임대 할당과 HNS 네트워크 생성을 위해 윈도우 (Flanneld)에서 +Flannel 데몬과 함께 작동하도록 참조 CNI 플러그인 (win-overlay, win-bridge) +중 하나에 대한 위임을 지원한다. 이 플러그인은 자체 +구성 파일 (cni.conf)을 읽고, 이를 FlannelD 생성하는 subnet.env 파일의 환경 변수와 +함께 집계한다. 이후 네트워크 연결을 위한 +참조 CNI 플러그인 중 하나에 위임하고 노드 할당 서브넷을 포함하는 올바른 +구성을 IPAM 플러그인 (예: 호스트-로컬)으로 +보낸다. -노드, 파드, 서비스 오브젝트의 경우 TCP/UDP 트래픽에 대해 다음 네트워크 흐름이 지원된다. +노드, 파드, 서비스 오브젝트의 경우 TCP/UDP 트래픽에 대해 다음 +네트워크 흐름이 지원된다. * 파드 -> 파드(IP) * 파드 -> 파드(Name) @@ -205,81 +458,227 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템 ##### 로드 밸런싱과 서비스 -윈도우에서는 다음 설정을 사용하여 서비스 및 로드 밸런싱 동작을 구성할 수 있다. +윈도우에서는 다음 설정을 사용하여 서비스 및 로드 밸런싱 동작을 +구성할 수 있다. {{< table caption="윈도우 서비스 구성" >}} -| 기능 | 설명 | 지원되는 쿠버네티스 버전 | 지원되는 윈도우 OS 빌드 | 활성화하는 방법 | -| ------- | ----------- | ----------------------------- | -------------------------- | ------------- | -| 세션 어피니티 | 특정 클라이언트의 연결이 매번 동일한 파드로 전달되도록 한다. | v1.19 이상 | [윈도우 서버 vNext Insider Preview Build 19551](https://blogs.windows.com/windowsexperience/2020/01/28/announcing-windows-server-vnext-insider-preview-build-19551/) 이상 | `service.spec.sessionAffinity`를 "ClientIP"로 설정 | -| 직접 서버 반환 | IP 주소 수정 및 LBNAT가 컨테이너 vSwitch 포트에서 직접 발생하는 로드 밸런싱 모드. 서비스 트래픽은 소스 IP가 원래 파드 IP로 설정된 상태로 도착한다. 낮은 지연 시간과 확장성을 약속한다. | v1.15 이상 | 윈도우 서버, 버전 2004 | kube-proxy에서 다음 플래그를 설정한다. `--feature-gates="WinDSR=true" --enable-dsr=true` | -| 대상 보존(Preserve-Destination) | 서비스 트래픽의 DNAT를 스킵하여, 백엔드 파드에 도달하는 패킷에서 대상 서비스의 가상 IP를 보존한다. 이 설정은 또한 수신 패킷의 클라이언트 IP가 보존되도록 한다. | v1.15 이상 | 윈도우 서버, 버전 1903 (이상) | 서비스 어느테이션에서 `"preserve-destination": "true"`를 설정하고 kube-proxy에서 DSR 플래그를 활성화한다. | -| IPv4/IPv6 이중 스택 네트워킹 | 클러스터 내/외부 기본 IPv4-to-IPv4 통신과 함께 IPv6-to-IPv6 통신 | v1.19 이상 | 윈도우 서버 vNext Insider Preview Build 19603(또는 그 이상) | [IPv4/IPv6 이중 스택](#ipv4ipv6-이중-스택)을 참고한다. | + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    기능설명지원되는 쿠버네티스 버전지원되는 윈도우 OS 빌드활성화하는 방법
    세션 어피니티 + 특정 클라이언트의 연결이 매번 동일한 파드로 + 전달되도록 한다. + v1.20 이상 + 윈도우 서버 vNext Insider Preview Build 19551 (또는 그 이상) + + service.spec.sessionAffinity를 "ClientIP"로 설정 +
    직접 서버 반환 (DSR) + IP 주소 수정 및 LBNAT가 컨테이너 vSwitch 포트에서 직접 + 발생하는 로드 밸런싱 모드. 서비스 트래픽은 소스 IP가 원래 파드 IP로 + 설정된 상태로 도착한다. + v1.20 이상 + 윈도우 서버 2019 + + kube-proxy에서 다음 플래그를 설정한다. + --feature-gates="WinDSR=true" --enable-dsr=true +
    대상 보존(Preserve-Destination) + 서비스 트래픽의 DNAT를 스킵하여, 백엔드 파드에 도달하는 패킷에서 대상 + 서비스의 가상 IP를 보존한다. 또한 노드-노드 전달을 비활성화한다. + v1.20 이상윈도우 서버, 버전 1903 (또는 그 이상) + 서비스 어노테이션에서 "preserve-destination": "true"를 설정하고 + kube-proxy에서 DSR을 활성화한다. +
    IPv4/IPv6 이중 스택 네트워킹 + 클러스터 내/외부 기본 IPv4-to-IPv4 통신과 함께 + IPv6-to-IPv6 통신 + v1.19 이상윈도우 서버, 버전 2004 (또는 그 이상) + IPv4/IPv6 이중 스택을 참고한다. +
    클라이언트 IP 보존 + 인그레스 트래픽의 소스 IP가 유지되도록 한다. 또한 + 노드-노드 전달을 비활성화한다. + v1.20 이상윈도우 서버, 버전 2019 (또는 그 이상) + service.spec.externalTrafficPolicy를 "Local"로 설정하고 + kube-proxy에서 DSR을 활성화한다. +
    + {{< /table >}} #### IPv4/IPv6 이중 스택 -`IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하여 `l2bridge` 네트워크에 IPv4/IPv6 이중 스택 네트워킹을 활성화할 수 있다. 자세한 내용은 [IPv4/IPv6 이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/#ipv4-ipv6-이중-스택-활성화)를 참조한다. +`IPv6DualStack` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 +사용하여 `l2bridge` 네트워크에 IPv4/IPv6 이중 스택 네트워킹을 활성화할 수 있다. 자세한 내용은 +[IPv4/IPv6 이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/#ipv4-ipv6-이중-스택-활성화)를 +참조한다. -{{< note >}} -윈도우에서 쿠버네티스와 함께 IPv6를 사용하려면 윈도우 서버 버전 2004 (커널 버전 10.0.19041.610) 이상이 필요하다. -{{< /note >}} +윈도우에서 쿠버네티스와 함께 IPv6를 사용하려면 윈도우 서버 버전 2004 +(커널 버전 10.0.19041.610) 이상이 필요하다. -{{< note >}} 윈도우의 오버레이(VXLAN) 네트워크는 현재 이중 스택 네트워킹을 지원하지 않는다. -{{< /note >}} ### 제한 -#### 컨트롤 플레인 +윈도우는 쿠버네티스 아키텍처 및 컴포넌트 매트릭스에서 워커 +노드로만 지원된다. 즉, 쿠버네티스 클러스터에는 항상 리눅스 마스터 노드가 반드시 +포함되어야 하고, 0개 이상의 리눅스 워커 노드 및 0개 이상의 윈도우 +워커 노드가 포함된다. -윈도우는 쿠버네티스 아키텍처 및 컴포넌트 매트릭스에서 워커 노드로만 지원된다. 즉, 쿠버네티스 클러스터에는 항상 리눅스 마스터 노드가 반드시 포함되어야 하고, 0개 이상의 리눅스 워커 노드 및 0개 이상의 윈도우 워커 노드가 포함된다. +#### 자원 관리 -#### 컴퓨트 {#컴퓨트-제한} +리눅스 cgroup은 리눅스에서 리소스 제어를 위한 파드 경계로 사용된다. +컨테이너는 네트워크, 프로세스 및 파일시스템 격리를 위해 해당 +경계 내에 생성된다. cgroups API는 cpu/io/memory 통계를 수집하는 데 사용할 수 있다. +반대로 윈도우는 시스템 네임스페이스 필터가 있는 컨테이너별로 잡(Job) +오브젝트를 사용하여 컨테이너의 모든 프로세스를 포함하고 호스트와의 +논리적 격리를 제공한다. 네임스페이스 필터링 없이 윈도우 컨테이너를 +실행할 수 있는 방법은 없다. 즉, 시스템 권한은 호스트 컨텍스트에서 삽입될(assert) 수 없으므로 +권한이 있는(privileged) 컨테이너는 윈도우에서 사용할 수 없다. 보안 계정 +매니져(Security Account Manager, SAM)가 분리되어 있으므로 +컨테이너는 호스트의 ID를 가정할 수 없다. -##### 리소스 관리 및 프로세스 격리 +#### 자원 예약 - 리눅스 cgroup은 리눅스에서 리소스 제어를 위한 파드 경계로 사용된다. 컨테이너는 네트워크, 프로세스 및 파일시스템 격리를 위해 해당 경계 내에 생성된다. cgroups API는 cpu/io/memory 통계를 수집하는 데 사용할 수 있다. 반대로 윈도우는 시스템 네임스페이스 필터가 있는 컨테이너별로 잡(Job) 오브젝트를 사용하여 컨테이너의 모든 프로세스를 포함하고 호스트와의 논리적 격리를 제공한다. 네임스페이스 필터링 없이 윈도우 컨테이너를 실행할 수 있는 방법은 없다. 즉, 시스템 권한은 호스트 컨텍스트에서 삽입 될(assert) 수 없으므로 권한이 있는(privileged) 컨테이너는 윈도우에서 사용할 수 없다. 보안 계정 매니져(Security Account Manager, SAM)가 분리되어 있으므로 컨테이너는 호스트의 ID를 가정할 수 없다. +##### 메모리 예약 -##### 운영 체제 제한 +윈도우에는 리눅스에는 있는 메모리 부족 프로세스 킬러가 없다. 윈도우는 +모든 사용자-모드 메모리 할당을 항상 가상 메모리처럼 처리하며, 페이지파일이 +필수이다. 결과적으로 윈도우에서는 리눅스에서 발생할 수 있는 +메모리 부족 상태에 도달하지 않으며, 프로세스는 메모리 부족(out of memory, OOM) 종료를 +겪는 대신 디스크로 페이징한다. 메모리가 오버프로비저닝되고 +모든 물리 메모리가 고갈되면 페이징으로 인해 성능이 저하될 수 있다. -윈도우에는 호스트 OS 버전이 컨테이너 베이스 이미지 OS 버전과 일치해야 하는 엄격한 호환성 규칙이 있다. 윈도우 서버 2019의 컨테이너 운영 체제가 있는 윈도우 컨테이너만 지원된다. 윈도우 컨테이너 이미지 버전의 일부 이전 버전과의 호환성을 가능하게 하는 컨테이너의 Hyper-V 격리는 향후 릴리스로 계획되어 있다. +kubelet 파라미터 `--kubelet-reserve` 를 사용하여 메모리 사용량을 +합리적인 범위 내로 유지할 수 있으며, `--system-reserve` 를 사용하여 +노드(컨테이너 외부)의 메모리 사용량을 예약할 수 있다. 이들을 사용하면 그만큼 +[노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)은 줄어든다. -##### 기능 제한 +워크로드를 배포할 때, 컨테이너에 리소스 제한을 +걸어라(제한만 설정하거나, 제한이 요청과 같아야 함). 이 또한 NodeAllocatable에서 차감되며, +메모리가 꽉 찬 노드에 스케줄러가 파드를 할당하지 않도록 제한한다. -* TerminationGracePeriod: CRI-containerD 필요 +오버프로비저닝을 방지하는 가장 좋은 방법은 윈도우, 도커, 그리고 +쿠버네티스 프로세스를 위해 최소 2GB 이상의 시스템 예약 메모리로 +kubelet을 설정하는 것이다. + +##### CPU 예약 + +윈도우, 도커, 그리고 다른 쿠버네티스 호스트 프로세스가 이벤트에 +잘 응답할 수 있도록, CPU의 일정 비율을 예약하는 것이 +좋다. 이 값은 윈도우 노드에 있는 CPU 코어 수에 +따라 조정해야 한다. 이 비율을 결정하려면, 각 노드의 +최대 파드 밀도(density)를 관찰하고, 시스템 서비스의 CPU +사용량을 모니터링하여 워크로드 요구사항을 충족하는 값을 선택해야 한다. + +kubelet 파라미터 `--kubelet-reserve` 를 사용하여 CPU 사용량을 +합리적인 범위 내로 유지할 수 있으며, `--system-reserve` 를 사용하여 +노드 (컨테이너 외부) 의 CPU 사용량을 예약할 수 있다. 이들을 사용하면 그만큼 +[노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)은 줄어든다. + +#### 기능 제한 + +* TerminationGracePeriod: 구현되지 않음 * 단일 파일 매핑: CRI-ContainerD로 구현 예정 * 종료 메시지: CRI-ContainerD로 구현 예정 * 특권을 가진(Privileged) 컨테이너: 현재 윈도우 컨테이너에서 지원되지 않음 * HugePages: 현재 윈도우 컨테이너에서 지원되지 않음 -* 기존 노드 문제 감지기는 리눅스 전용이며 특권을 가진 컨테이너가 필요하다. 윈도우에서 특권을 가진 컨테이너를 지원하지 않기 때문에 일반적으로 윈도우에서 이 기능이 사용될 것으로 예상하지 않는다. -* 공유 네임스페이스의 모든 기능이 지원되는 것은 아니다. (자세한 내용은 API 섹션 참조). +* 기존 노드 문제 감지기는 리눅스 전용이며 특권을 가진 + 컨테이너가 필요하다. 윈도우에서 특권을 가진 컨테이너를 지원하지 않기 때문에 + 일반적으로 윈도우에서 이 기능이 사용될 것으로 예상하지 않는다. +* 공유 네임스페이스의 모든 기능이 지원되는 것은 아니다. (자세한 내용은 + API 섹션 참조). -##### 메모리 예약 및 처리 +#### 각 플래그의 리눅스와의 차이점 -윈도우에는 리눅스처럼 out-of-memory 프로세스 킬러가 없다. 윈도우는 항상 모든 사용자 모드 메모리 할당을 가상으로 처리하며 페이지 파일은 필수이다. 결과적으로 윈도우는 리눅스와 같은 방식으로 메모리 부족 상태에 도달하지 않고, 메모리 부족(OOM)으로 인한 종료 대신 페이지를 디스크로 처리한다. 메모리가 과도하게 프로비저닝되고 모든 실제 메모리가 고갈되면, 페이징으로 인해 성능이 저하될 수 있다. +윈도우 노드에서의 kubelet 플래그의 동작은 아래에 설명된 대로 다르게 동작한다. -2단계 프로세스를 통해 적절한 범위 내에서 메모리 사용량을 유지할 수 있다. 먼저, kubelet 파라미터 `--kubelet-reserve` 그리고/또는 `--system-reserve`를 사용하여 노드(컨테이너 외부)의 메모리 사용량을 고려한다. 이렇게 하면 [노드 할당(NodeAllocatable)](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)이 줄어든다. 워크로드를 배포할 때 컨테이너에 리소스 제한을 사용(limits만 설정하거나 limits이 requests과 같아야 함)한다. 또한 NodeAllocatable에서 빼고 노드가 가득차면 스케줄러가 더 많은 파드를 추가하지 못하도록 한다. +* `--kubelet-reserve`, `--system-reserve`, `--eviction-hard` 플래그는 + Node Allocatable 업데이트 -오버 프로비저닝을 방지하는 모범 사례는 윈도우, 도커 및 쿠버네티스 프로세스를 고려하여 최소 2GB의 시스템 예약 메모리로 kubelet을 구성하는 것이다. - -플래그의 동작은 아래에 설명된 대로 다르게 동작한다. - -* `--kubelet-reserve`, `--system-reserve`, `--eviction-hard` 플래그는 Node Allocatable 업데이트 * `--enforce-node-allocable`을 사용한 축출(Eviction)은 구현되지 않았다. + * `--eviction-hard`와 `--eviction-soft`를 사용한 축출은 구현되지 않았다. + * MemoryPressure 조건은 구현되지 않았다. + * kubelet이 취한 OOM 축출 조치가 없다. -* 윈도우 노드에서 실행되는 Kubelet에는 메모리 제한이 없다. `--kubelet-reserve`와 `--system-reserve`는 호스트에서 실행되는 kubelet 또는 프로세스에 제한을 설정하지 않는다. 이는 호스트의 kubelet 또는 프로세스가 node-allocatable 및 스케줄러 외부에서 메모리 리소스 부족을 유발할 수 있음을 의미한다. -* kubelet 프로세스의 우선 순위를 설정하는 추가 플래그는 `--windows-priorityclass`라는 윈도우 노드에서 사용할 수 있다. 이 플래그를 사용하면 kubelet 프로세스가 윈도우 호스트에서 실행중인 다른 프로세스와 비교할 때 더 많은 CPU 시간 슬라이스을 얻을 수 있다. 허용되는 값과 그 의미에 대한 자세한 내용은 [윈도우 우선순위 클래스](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class)에서 확인할 수 있다. kubelet이 항상 충분한 CPU주기를 갖도록 하려면 이 플래그를 `ABOVE_NORMAL_PRIORITY_CLASS` 이상으로 설정하는 것이 좋다. + +* 윈도우 노드에서 실행되는 Kubelet에는 메모리 제한이 없다. + `--kubelet-reserve`와 `--system-reserve`는 호스트에서 실행되는 kubelet 또는 + 프로세스에 제한을 설정하지 않는다. 이는 호스트의 kubelet 또는 프로세스가 + node-allocatable 및 스케줄러 외부에서 메모리 리소스 부족을 유발할 수 있음을 + 의미한다. + +* kubelet 프로세스의 우선 순위를 설정하는 추가 플래그는 + `--windows-priorityclass`라는 윈도우 노드에서 사용할 수 있다. 이 플래그를 사용하면 + kubelet 프로세스가 윈도우 호스트에서 실행중인 다른 프로세스와 비교할 때 더 많은 CPU 시간 + 슬라이스을 얻을 수 있다. 허용되는 값과 그 의미에 대한 자세한 내용은 + [윈도우 우선순위 클래스](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class)에서 + 확인할 수 있다. + kubelet이 항상 충분한 CPU주기를 갖도록 하려면 + 이 플래그를 `ABOVE_NORMAL_PRIORITY_CLASS` 이상으로 설정하는 것이 좋다. #### 스토리지 -윈도우에는 컨테이너 계층을 마운트하고 NTFS를 기반으로 하는 복제 파일시스템을 만드는 레이어드(layered) 파일시스템 드라이버가 있다. 컨테이너의 모든 파일 경로는 해당 컨테이너의 컨텍스트 내에서만 확인된다. +윈도우에는 컨테이너 계층을 마운트하고 NTFS를 기반으로 하는 복제 파일시스템을 +만드는 레이어드(layered) 파일시스템 드라이버가 있다. 컨테이너의 모든 파일 경로는 +해당 컨테이너의 컨텍스트 내에서만 확인된다. -* 도커 볼륨 마운트는 개별 파일이 아닌 컨테이너의 디렉토리 만 대상으로 할 수 있다. 이 제한은 CRI-containerD에는 존재하지 않는다. -* 볼륨 마운트는 파일이나 디렉터리를 호스트 파일시스템으로 다시 투영할 수 없다. -* 읽기 전용 파일시스템은 윈도우 레지스트리 및 SAM 데이터베이스에 항상 쓰기 접근이 필요하기 때문에 지원되지 않는다. 그러나 읽기 전용 볼륨은 지원된다. -* 볼륨 사용자 마스크(user-masks) 및 권한은 사용할 수 없다. SAM은 호스트와 컨테이너 간에 공유되지 않기 때문에 이들 간에 매핑이 없다. 모든 권한은 컨테이너 컨텍스트 내에서 해결된다. +* 도커 볼륨 마운트는 개별 파일이 아닌 컨테이너의 + 디렉터리만 대상으로 할 수 있다. 이 제한은 CRI-containerD에는 존재하지 않는다. + +* 볼륨 마운트는 파일이나 디렉터리를 호스트 파일시스템으로 다시 + 투영할 수 없다. + +* 읽기 전용 파일시스템은 윈도우 레지스트리 및 SAM 데이터베이스에 항상 + 쓰기 접근이 필요하기 때문에 지원되지 않는다. 그러나 읽기 전용 + 볼륨은 지원된다. + +* 볼륨 사용자 마스크(user-masks) 및 권한은 사용할 수 없다. SAM은 + 호스트와 컨테이너 간에 공유되지 않기 때문에 이들 간에 매핑이 없다. 모든 + 권한은 컨테이너 컨텍스트 내에서 해결된다. 결과적으로, 다음 스토리지 기능은 윈도우 노드에서 지원되지 않는다. @@ -296,24 +695,61 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템 #### 네트워킹 {#네트워킹-제한} -윈도우 컨테이너 네트워킹은 리눅스 네트워킹과 몇 가지 중요한 면에서 다르다. [윈도우 컨테이너 네트워킹에 대한 Microsoft 문서](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/container-networking/architecture)에는 추가 세부 정보와 배경이 포함되어 있다. +윈도우 컨테이너 네트워킹은 리눅스 네트워킹과 몇 가지 중요한 면에서 +다르다. [윈도우 컨테이너 네트워킹에 대한 Microsoft 문서](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/container-networking/architecture)에는 +추가 세부 정보와 배경이 포함되어 있다. -윈도우 호스트 네트워킹 서비스와 가상 스위치는 네임스페이스를 구현하고 파드 또는 컨테이너에 필요한 가상 NIC을 만들 수 있다. 그러나 DNS, 라우트, 메트릭과 같은 많은 구성은 리눅스에서와 같이 /etc/... 파일이 아닌 윈도우 레지스트리 데이터베이스에 저장된다. 컨테이너의 윈도우 레지스트리는 호스트 레지스트리와 별개이므로 호스트에서 컨테이너로 /etc/resolv.conf를 매핑하는 것과 같은 개념은 리눅스에서와 동일한 효과를 갖지 않는다. 해당 컨테이너의 컨텍스트에서 실행되는 윈도우 API를 사용하여 구성해야 한다. 따라서 CNI 구현에서는 파일 매핑에 의존하는 대신 HNS를 호출하여 네트워크 세부 정보를 파드 또는 컨테이너로 전달해야 한다. +윈도우 호스트 네트워킹 서비스와 가상 스위치는 네임스페이스를 +구현하고 파드 또는 컨테이너에 필요한 가상 NIC을 만들 수 있다. 그러나 +DNS, 라우트, 메트릭과 같은 많은 구성은 리눅스에서와 같이 /etc/... 파일이 +아닌 윈도우 레지스트리 데이터베이스에 저장된다. 컨테이너의 +윈도우 레지스트리는 호스트 레지스트리와 별개이므로 호스트에서 +컨테이너로 /etc/resolv.conf를 매핑하는 것과 같은 개념은 리눅스에서와 +동일한 효과를 갖지 않는다. 해당 컨테이너의 컨텍스트에서 실행되는 윈도우 API를 +사용하여 구성해야 한다. 따라서 CNI 구현에서는 파일 매핑에 의존하는 +대신 HNS를 호출하여 네트워크 세부 정보를 파드 또는 컨테이너로 +전달해야 한다. 다음 네트워킹 기능은 윈도우 노드에서 지원되지 않는다. * 윈도우 파드에서는 호스트 네트워킹 모드를 사용할 수 없다. -* 노드 자체에서 로컬 NodePort 접근은 실패한다. (다른 노드 또는 외부 클라이언트에서는 가능) -* 노드에서 서비스 VIP에 접근하는 것은 향후 윈도우 서버 릴리스에서 사용할 수 있다. + +* 노드 자체에서 로컬 NodePort 접근은 실패한다. (다른 노드 또는 + 외부 클라이언트에서는 가능) + +* 노드에서 서비스 VIP에 접근하는 것은 향후 윈도우 서버 릴리스에서 + 사용할 수 있다. + * 한 서비스는 최대 64개의 백엔드 파드 또는 고유한 목적지 IP를 지원할 수 있다. -* kube-proxy의 오버레이 네트워킹 지원은 알파 릴리스이다. 또한 윈도우 서버 2019에 [KB4482887](https://support.microsoft.com/ko-kr/help/4482887/windows-10-update-kb4482887)을 설치해야 한다. -* 로컬 트래픽 정책 및 DSR 모드 -* l2bridge, l2tunnel 또는 오버레이 네트워크에 연결된 윈도우 컨테이너는 IPv6 스택을 통한 통신을 지원하지 않는다. 이러한 네트워크 드라이버가 IPv6 주소를 사용하고 kubelet, kube-proxy 및 CNI 플러그인에서 후속 쿠버네티스 작업을 사용할 수 있도록 하는데 필요한 뛰어난 윈도우 플랫폼 작업이 있다. -* win-overlay, win-bridge, Azure-CNI 플러그인을 통해 ICMP 프로토콜을 사용하는 아웃바운드 통신. 특히, 윈도우 데이터 플레인([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/))은 ICMP 패킷 치환을 지원하지 않는다. 이것은 다음을 의미한다. - * 동일한 네트워크(예: ping을 통한 파드 간 통신) 내의 목적지로 전달되는 ICMP 패킷은 예상대로 제한 없이 작동한다. + +* kube-proxy의 오버레이 네트워킹 지원은 베타 기능이다. 또한 + 윈도우 서버 2019에 [KB4482887](https://support.microsoft.com/ko-kr/help/4482887/windows-10-update-kb4482887)을 + 설치해야 한다. + +* 비-DSR 모드의 로컬 트래픽 정책 + +* 오버레이 네트워크에 연결된 윈도우 컨테이너는 + IPv6 스택을 통한 통신을 지원하지 않는다. 이 네트워크 드라이버가 IPv6 주소를 + 사용하고 kubelet, kube-proxy 및 CNI 플러그인에서 후속 쿠버네티스 작업을 + 사용할 수 있도록 하는데 필요한 뛰어난 윈도우 플랫폼 작업이 있다. + +* win-overlay, win-bridge, Azure-CNI 플러그인을 통해 + ICMP 프로토콜을 사용하는 아웃바운드 통신. 특히, 윈도우 데이터 플레인 + ([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/))은 + ICMP 패킷 치환을 지원하지 않는다. 이것은 다음을 의미한다. + + * 동일한 네트워크(예: ping을 통한 파드 간 통신) 내의 목적지로 전달되는 + ICMP 패킷은 예상대로 제한 없이 작동한다. + * TCP/UDP 패킷은 예상대로 제한 없이 작동한다. - * 원격 네트워크를 통과하도록 지정된 ICMP 패킷(예: ping을 통한 파드에서 외부 인터넷으로의 통신)은 치환될 수 없으므로 소스로 다시 라우팅되지 않는다. - * TCP/UDP 패킷은 여전히 ​​치환될 수 있기 때문에 `ping `을 `curl `으로 대체하여 외부와의 연결을 디버깅할 수 있다. + + * 원격 네트워크를 통과하도록 지정된 ICMP 패킷(예: ping을 통한 + 파드에서 외부 인터넷으로의 통신)은 치환될 수 없으므로 + 소스로 다시 라우팅되지 않는다. + + * TCP/UDP 패킷은 여전히 ​​치환될 수 있기 때문에 + `ping `을 `curl `으로 대체하여 + 외부와의 연결을 디버깅할 수 있다. 해당 기능은 쿠버네티스 v1.15에 추가되었다. @@ -321,330 +757,583 @@ CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템 ##### CNI 플러그인 -* 윈도우 참조 네트워크 플러그인 win-bridge와 win-overlay는 현재 "CHECK" 구현 누락으로 인해 [CNI 사양](https://github.com/containernetworking/cni/blob/master/SPEC.md) v0.4.0을 구현하지 않는다. +* 윈도우 참조 네트워크 플러그인 win-bridge와 win-overlay는 + 현재 "CHECK" 구현 누락으로 인해 [CNI 사양](https://github.com/containernetworking/cni/blob/master/SPEC.md) + v0.4.0을 구현하지 않는다. + * Flannel VXLAN CNI는 윈도우에서 다음과 같은 제한이 있다. -1. 노드-파드 연결은 설계상 불가능하다. Flannel v0.12.0(또는 그 이상)이 있는 로컬 파드에서만 가능하다. -2. VNI 4096와 UDP 4789 포트 사용은 제한된다. VNI 제한은 작업 중이며 향후 릴리스(오픈 소스 flannel 변경)에서 구현될 것이다. 이러한 파라미터에 대한 자세한 내용은 공식 [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) 백엔드 문서를 참고한다. + 1. 노드-파드 연결은 설계상 불가능하다. Flannel v0.12.0(또는 그 이상)이 + 있는 로컬 파드에서만 가능하다. + + 1. VNI 4096와 UDP 4789 포트 사용은 제한된다. VNI 제한은 + 작업 중이며 향후 릴리스(오픈 소스 flannel 변경)에서 + 구현될 것이다. 이러한 파라미터에 대한 자세한 내용은 공식 + [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) + 백엔드 문서를 참고한다. ##### DNS {#dns-limitations} -* ClusterFirstWithHostNet은 DNS에서 지원되지 않는다. 윈도우는 '.'이 있는 모든 이름을 FQDN으로 처리하고 PQDN 확인을 건너뛴다. -* 리눅스에서는 PQDN을 확인하려고 할 때 사용되는 DNS 접미사 목록이 있다. 윈도우에서는 해당 파드의 네임스페이스(예: mydns.svc.cluster.local)와 연결된 DNS 접미사인 DNS 접미사 1개만 있다. 윈도우는 FQDN과 서비스 또는 해당 접미사만으로 확인할 수 있는 이름을 확인할 수 있다. 예를 들어, 디폴트 네임스페이스에서 생성된 파드에는 DNS 접미사 **default.svc.cluster.local**이 있다. 윈도우 파드에서는 **kubernetes.default.svc.cluster.local** 및 **kubernetes**를 모두 확인할 수 있지만 **kubernetes.default** 또는 **kubernetes.default.svc**와 같은 중간 항목은 확인할 수 없다. -* 윈도우에서는 사용할 수 있는 여러 가지의 DNS 리졸버(resolver)가 있다. 이들은 약간 다른 동작을 제공하므로, 이름 쿼리 확인을 위해 `Resolve-DNSName` 유틸리티를 사용하는 것이 좋다. +* ClusterFirstWithHostNet은 DNS에서 지원되지 않는다. 윈도우는 + '.'이 있는 모든 이름을 FQDN으로 처리하고 PQDN 확인을 건너뛴다. + +* 리눅스에서는 PQDN을 확인하려고 할 때 사용되는 DNS 접미사 목록이 + 있다. 윈도우에서는 해당 파드의 네임스페이스(예: mydns.svc.cluster.local)와 + 연결된 DNS 접미사인 DNS 접미사 1개만 있다. + 윈도우는 FQDN과 서비스 또는 해당 접미사만으로 확인할 수 있는 이름을 확인할 수 + 있다. 예를 들어, 디폴트 네임스페이스에서 생성된 파드에는 DNS + 접미사 `default.svc.cluster.local`이 있다. 윈도우 파드에서는 + `kubernetes.default.svc.cluster.local` 및 `kubernetes`를 모두 확인할 수 + 있지만 `kubernetes.default` 또는 `kubernetes.default.svc`와 같은 중간 항목은 확인할 수 없다. + +* 윈도우에서는 사용할 수 있는 여러 가지의 DNS 리졸버(resolver)가 있다. 이들은 + 약간 다른 동작을 제공하므로, 이름 쿼리 확인을 위해 `Resolve-DNSName` 유틸리티를 + 사용하는 것이 좋다. ##### IPv6 -윈도우의 쿠버네티스는 단일 스택 "IPv6 전용" 네트워킹을 지원하지 않는다. 그러나 단일 제품군 서비스를 사용하는 파드와 노드에 대한 이중 스택 IPv4/IPv6 네트워킹이 지원된다. 자세한 내용은 [IPv4/IPv6 이중 스택 네트워킹](#ipv4ipv6-이중-스택)을 참고한다. +윈도우의 쿠버네티스는 단일 스택 "IPv6 전용" 네트워킹을 지원하지 않는다. +그러나 단일 제품군 서비스를 사용하는 파드와 노드에 대한 이중 스택 IPv4/IPv6 네트워킹이 +지원된다. +자세한 내용은 [IPv4/IPv6 이중 스택 네트워킹](#ipv4ipv6-이중-스택)을 참고한다. ##### 세션 어피니티(affinity) -`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`를 사용하는 윈도우 서비스의 최대 세션 고정(sticky) 시간 설정은 지원되지 않는다. +`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds`를 사용하는 +윈도우 서비스의 최대 세션 고정(sticky) 시간 설정은 지원되지 않는다. ##### 보안 -시크릿(Secret)은 노드의 볼륨(리눅스의 tmpfs/in-memory와 비교)에 일반 텍스트로 작성된다. 이는 고객이 두 가지 작업을 수행해야 함을 의미한다. +시크릿(Secret)은 노드의 볼륨(리눅스의 tmpfs/in-memory와 +비교)에 일반 텍스트로 작성된다. 이는 고객이 두 가지 작업을 수행해야 함을 의미한다. 1. 파일 ACL을 사용하여 시크릿 파일 위치를 보호한다. -2. [BitLocker](https://docs.microsoft.com/ko-kr/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)를 사용한 볼륨-레벨 암호화를 사용한다. +1. [BitLocker](https://docs.microsoft.com/ko-kr/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)를 + 사용한 볼륨-레벨 암호화를 사용한다. -[RunAsUsername](/ko/docs/tasks/configure-pod-container/configure-runasusername)은 컨테이너 프로세스를 노드 기본 사용자로 실행하기 위해 윈도우 파드 또는 컨테이너에 지정할 수 있다. 이것은 [RunAsUser](/ko/docs/concepts/policy/pod-security-policy/#사용자-및-그룹)와 거의 동일하다. +[RunAsUsername](/ko/docs/tasks/configure-pod-container/configure-runasusername/)은 +컨테이너 프로세스를 노드 기본 사용자로 실행하기 위해 윈도우 파드 또는 +컨테이너에 지정할 수 있다. 이것은 +[RunAsUser](/ko/docs/concepts/policy/pod-security-policy/#사용자-및-그룹)와 거의 동일하다. -SELinux, AppArmor, Seccomp, 기능(POSIX 기능)과 같은 리눅스 특유의 파드 시큐리티 컨텍스트 권한은 지원하지 않는다. +SELinux, AppArmor, Seccomp, 기능(POSIX 기능)과 같은 +리눅스 특유의 파드 시큐리티 컨텍스트 권한은 지원하지 않는다. -또한 이미 언급했듯이 특권을 가진 컨테이너는 윈도우에서 지원되지 않는다. +또한 이미 언급했듯이 특권을 가진 컨테이너는 윈도우에서 지원되지 +않는다. #### API -대부분의 Kubernetes API가 윈도우에서 작동하는 방식은 차이가 없다. 중요한 차이점은 OS와 컨테이너 런타임의 차이로 귀결된다. 특정 상황에서 파드 또는 컨테이너와 같은 워크로드 API의 일부 속성은 리눅스에서 구현되고 윈도우에서 실행되지 않는다는 가정 하에 설계되었다. +대부분의 Kubernetes API가 윈도우에서 작동하는 방식은 차이가 없다. +중요한 차이점은 OS와 컨테이너 런타임의 차이로 +귀결된다. 특정 상황에서 파드 또는 컨테이너와 같은 워크로드 API의 +일부 속성은 리눅스에서 구현되고 윈도우에서 실행되지 않는다는 가정 하에 +설계되었다. 높은 수준에서 이러한 OS 개념은 다르다. -* ID - 리눅스는 정수형으로 표시되는 userID(UID) 및 groupID(GID)를 사용한다. 사용자와 그룹 이름은 정식 이름이 아니다. UID+GID에 대한 `/etc/groups` 또는 `/etc/passwd`의 별칭일 뿐이다. 윈도우는 윈도우 보안 계정 관리자(Security Account Manager, SAM) 데이터베이스에 저장된 더 큰 이진 보안 식별자(SID)를 사용한다. 이 데이터베이스는 호스트와 컨테이너 간에 또는 컨테이너들 간에 공유되지 않는다. -* 파일 퍼미션 - 윈도우는 권한 및 UUID+GID의 비트 마스크(bitmask) 대신 SID를 기반으로 하는 접근 제어 목록을 사용한다. -* 파일 경로 - 윈도우의 규칙은 `/` 대신 `\`를 사용하는 것이다. Go IO 라이브러리는 일반적으로 두 가지를 모두 허용하고 작동하도록 하지만, 컨테이너 내부에서 해석되는 경로 또는 커맨드 라인을 설정할 때 `\`가 필요할 수 있다. -* 신호(Signals) - 윈도우 대화형(interactive) 앱은 종료를 다르게 처리하며, 다음 중 하나 이상을 구현할 수 있다. - * UI 스레드는 WM_CLOSE를 포함하여 잘 정의된(well-defined) 메시지를 처리한다. - * 콘솔 앱은 컨트롤 핸들러(Control Handler)를 사용하여 ctrl-c 또는 ctrl-break를 처리한다. - * 서비스는 SERVICE_CONTROL_STOP 제어 코드를 수용할 수 있는 Service Control Handler 함수를 등록한다. +* ID - 리눅스는 정수형으로 표시되는 userID(UID) 및 groupID(GID)를 + 사용한다. 사용자와 그룹 이름은 정식 이름이 아니다. UID+GID에 대한 + `/etc/groups` 또는 `/etc/passwd`의 별칭일 뿐이다. 윈도우는 윈도우 + 보안 계정 관리자(Security Account Manager, SAM) 데이터베이스에 + 저장된 더 큰 이진 보안 식별자(SID)를 사용한다. 이 데이터베이스는 호스트와 + 컨테이너 간에 또는 컨테이너들 간에 공유되지 않는다. -종료 코드는 0일 때 성공, 0이 아닌 경우 실패인 동일한 규칙을 따른다. 특정 오류 코드는 윈도우와 리눅스에서 다를 수 있다. 그러나 쿠버네티스 컴포넌트(kubelet, kube-proxy)에서 전달된 종료 코드는 변경되지 않는다. +* 파일 퍼미션 - 윈도우는 권한 및 UUID+GID의 비트 마스크(bitmask) 대신 + SID를 기반으로 하는 접근 제어 목록을 사용한다. + +* 파일 경로 - 윈도우의 규칙은 `/` 대신 `\`를 사용하는 것이다. Go IO + 라이브러리는 두 가지 파일 경로 분리자를 모두 허용한다. 하지만, 컨테이너 + 내부에서 해석되는 경로 또는 커맨드 라인을 설정할 때 `\`가 필요할 수 + 있다. + +* 신호(Signals) - 윈도우 대화형(interactive) 앱은 종료를 다르게 처리하며, 다음 중 + 하나 이상을 구현할 수 있다. + + * UI 스레드는 `WM_CLOSE`를 포함하여 잘 정의된(well-defined) 메시지를 처리한다. + + * 콘솔 앱은 컨트롤 핸들러(Control Handler)를 사용하여 ctrl-c 또는 ctrl-break를 처리한다. + + * 서비스는 `SERVICE_CONTROL_STOP` 제어 코드를 수용할 수 있는 + Service Control Handler 함수를 등록한다. + +종료 코드는 0일 때 성공, 0이 아닌 경우 실패인 동일한 규칙을 따른다. +특정 오류 코드는 윈도우와 리눅스에서 다를 수 있다. 그러나 +쿠버네티스 컴포넌트(kubelet, kube-proxy)에서 전달된 종료 코드는 +변경되지 않는다. ##### V1.Container -* V1.Container.ResourceRequirements.limits.cpu 및 V1.Container.ResourceRequirements.limits.memory - 윈도우는 CPU 할당에 하드 리밋(hard limit)을 사용하지 않는다. 대신 공유 시스템이 사용된다. 밀리코어를 기반으로 하는 기존 필드는 윈도우 스케줄러가 뒤따르는 상대적인 공유로 스케일된다. [참고: kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go), [참고: Microsoft 문서 내 리소스 제어](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/resource-controls) - * Huge page는 윈도우 컨테이너 런타임에서 구현되지 않으며, 사용할 수 없다. 컨테이너에 대해 구성할 수 없는 [사용자 권한(privilege) 어설트](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support)가 필요하다. -* V1.Container.ResourceRequirements.requests.cpu 및 V1.Container.ResourceRequirements.requests.memory - 노드의 사용 가능한 리소스에서 요청(requests)을 빼서, 노드에 대한 오버 프로비저닝을 방지하는데 사용할 수 있다. 그러나 오버 프로비저닝된 노드에서 리소스를 보장하는 데는 사용할 수 없다. 운영자가 오버 프로비저닝을 완전히 피하려는 경우 모범 사례로 모든 컨테이너에 적용해야 한다. -* V1.Container.SecurityContext.allowPrivilegeEscalation - 윈도우에서는 불가능하며, 어떤 기능도 연결되지 않는다. -* V1.Container.SecurityContext.Capabilities - POSIX 기능은 윈도우에서 구현되지 않는다. -* V1.Container.SecurityContext.privileged - 윈도우는 특권을 가진 컨테이너를 지원하지 않는다. +* V1.Container.ResourceRequirements.limits.cpu 및 + V1.Container.ResourceRequirements.limits.memory - 윈도우는 CPU 할당에 하드 + 리밋(hard limit)을 사용하지 않는다. 대신 공유 시스템이 사용된다. 밀리코어를 + 기반으로 하는 기존 필드는 윈도우 스케줄러가 뒤따르는 상대적인 공유로 + 스케일된다. + [참고: kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go), + [참고: Microsoft 문서 내 리소스 제어](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/manage-containers/resource-controls) + + * Huge page는 윈도우 컨테이너 런타임에서 구현되지 않으며, + 사용할 수 없다. 컨테이너에 대해 구성할 수 없는 + [사용자 권한(privilege) 어설트](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support)가 + 필요하다. + +* V1.Container.ResourceRequirements.requests.cpu 및 + V1.Container.ResourceRequirements.requests.memory - 노드의 사용 가능한 + 리소스에서 요청(requests)을 빼서, 노드에 대한 오버 프로비저닝을 방지하는데 사용할 수 + 있다. 그러나 오버 프로비저닝된 노드에서 리소스를 보장하는 데는 + 사용할 수 없다. 운영자가 오버 프로비저닝을 완전히 피하려는 경우 + 모범 사례로 모든 컨테이너에 적용해야 한다. + +* V1.Container.SecurityContext.allowPrivilegeEscalation - 윈도우에서는 + 불가능하며, 어떤 기능도 연결되지 않는다. + +* V1.Container.SecurityContext.Capabilities - POSIX 기능은 윈도우에서 + 구현되지 않는다. + +* V1.Container.SecurityContext.privileged - 윈도우는 특권을 가진 컨테이너를 + 지원하지 않는다. + * V1.Container.SecurityContext.procMount - 윈도우에는 /proc 파일시스템이 없다. -* V1.Container.SecurityContext.readOnlyRootFilesystem - 윈도우에서는 불가능하며, 레지스트리 및 시스템 프로세스가 컨테이너 내부에서 실행되려면 쓰기 권한이 필요하다. + +* V1.Container.SecurityContext.readOnlyRootFilesystem - 윈도우에서는 불가능하며, + 레지스트리 및 시스템 프로세스가 컨테이너 내부에서 실행되려면 쓰기 권한이 + 필요하다. + * V1.Container.SecurityContext.runAsGroup - 윈도우에서는 불가능하며, GID 지원이 없다. -* V1.Container.SecurityContext.runAsNonRoot - 윈도우에는 root 사용자가 없다. 가장 가까운 항목은 노드에 존재하지 않는 아이덴티티(identity)인 ContainerAdministrator이다. -* V1.Container.SecurityContext.runAsUser - 윈도우에서는 불가능하며, 정수값으로의 UID 지원이 없다. + +* V1.Container.SecurityContext.runAsNonRoot - 윈도우에는 root 사용자가 + 없다. 가장 가까운 항목은 노드에 존재하지 않는 아이덴티티(identity)인 + ContainerAdministrator이다. + +* V1.Container.SecurityContext.runAsUser - 윈도우에서는 불가능하며, 정수값으로의 UID + 지원이 없다. + * V1.Container.SecurityContext.seLinuxOptions - 윈도우에서는 불가능하며, SELinux가 없다. -* V1.Container.terminationMessagePath - 윈도우가 단일 파일 매핑을 지원하지 않는다는 점에서 몇 가지 제한이 있다. 기본값은 /dev/termination-log이며, 기본적으로 윈도우에 존재하지 않기 때문에 작동한다. + +* V1.Container.terminationMessagePath - 윈도우가 단일 파일 매핑을 지원하지 + 않는다는 점에서 몇 가지 제한이 있다. 기본값은 /dev/termination-log이며, 기본적으로 윈도우에 존재하지 않기 때문에 + 작동한다. ##### V1.Pod * V1.Pod.hostIPC, v1.pod.hostpid - 윈도우에서 호스트 네임스페이스 공유가 불가능하다. + * V1.Pod.hostNetwork - 호스트 네트워크를 공유하기 위한 윈도우 OS 지원이 없다. -* V1.Pod.dnsPolicy - ClusterFirstWithHostNet - 윈도우에서 호스트 네트워킹이 지원되지 않기 때문에 지원되지 않는다. + +* V1.Pod.dnsPolicy - ClusterFirstWithHostNet - 윈도우에서 호스트 네트워킹이 지원되지 않기 때문에 + 지원되지 않는다. + * V1.Pod.podSecurityContext - 아래 V1.PodSecurityContext 내용을 참고한다. -* V1.Pod.shareProcessNamespace - 이것은 베타 기능이며, 윈도우에서 구현되지 않은 리눅스 네임스페이스에 따라 다르다. 윈도우는 프로세스 네임스페이스 또는 컨테이너의 루트 파일시스템을 공유할 수 없다. 네트워크만 공유할 수 있다. -* V1.Pod.terminationGracePeriodSeconds - 이것은 윈도우의 도커에서 완전히 구현되지 않았다. [참조](https://github.com/moby/moby/issues/25982)의 내용을 참고한다. 현재 동작은 ENTRYPOINT 프로세스가 CTRL_SHUTDOWN_EVENT로 전송된 다음, 윈도우가 기본적으로 5초를 기다린 후, 마지막으로 정상적인 윈도우 종료 동작을 사용하여 모든 프로세스를 종료하는 것이다. 5초 기본값은 실제로 [컨테이너 내부](https://github.com/moby/moby/issues/25982#issuecomment-426441183) 윈도우 레지스트리에 있으므로 컨테이너를 빌드할 때 재정의 할 수 있다. -* V1.Pod.volumeDevices - 이것은 베타 기능이며, 윈도우에서 구현되지 않는다. 윈도우는 원시 블록 장치(raw block device)를 파드에 연결할 수 없다. -* V1.Pod.volumes - EmptyDir, 시크릿, 컨피그맵, HostPath - 모두 작동하며 TestGrid에 테스트가 있다. - * V1.emptyDirVolumeSource - 노드 기본 매체는 윈도우의 디스크이다. 윈도우에는 내장 RAM 디스크가 없기 때문에 메모리는 지원되지 않는다. + +* V1.Pod.shareProcessNamespace - 이것은 베타 기능이며, 윈도우에서 구현되지 않은 + 리눅스 네임스페이스에 따라 다르다. 윈도우는 프로세스 네임스페이스 또는 + 컨테이너의 루트 파일시스템을 공유할 수 없다. 네트워크만 공유할 수 + 있다. + +* V1.Pod.terminationGracePeriodSeconds - 이것은 윈도우의 도커에서 + 완전히 구현되지 않았다. + [참조](https://github.com/moby/moby/issues/25982)의 내용을 참고한다. 현재 동작은 + `ENTRYPOINT` 프로세스가 `CTRL_SHUTDOWN_EVENT`로 전송된 다음, 윈도우가 기본적으로 5초를 + 기다린 후, 마지막으로 정상적인 윈도우 종료 동작을 사용하여 모든 프로세스를 + 종료하는 것이다. 5초 기본값은 실제로 + [컨테이너 내부](https://github.com/moby/moby/issues/25982#issuecomment-426441183) + 윈도우 레지스트리에 있으므로 컨테이너를 빌드할 때 재정의 할 수 있다. + +* V1.Pod.volumeDevices - 이것은 베타 기능이며, 윈도우에서 구현되지 + 않는다. 윈도우는 원시 블록 장치(raw block device)를 파드에 연결할 수 없다. + +* V1.Pod.volumes - EmptyDir, 시크릿, 컨피그맵, HostPath - 모두 작동하며 + TestGrid에 테스트가 있다. + + * V1.emptyDirVolumeSource - 노드 기본 매체는 윈도우의 디스크이다. + 윈도우에는 내장 RAM 디스크가 없기 때문에 메모리는 지원되지 않는다. + * V1.VolumeMount.mountPropagation - 마운트 전파(propagation)는 윈도우에서 지원되지 않는다. ##### V1.PodSecurityContext -PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 위해 여기에 나열한다. +PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를 위해 여기에 +나열한다. * V1.PodSecurityContext.SELinuxOptions - SELinux는 윈도우에서 사용할 수 없다. + * V1.PodSecurityContext.RunAsUser - 윈도우에서는 사용할 수 없는 UID를 제공한다. + * V1.PodSecurityContext.RunAsGroup - 윈도우에서는 사용할 수 없는 GID를 제공한다. -* V1.PodSecurityContext.RunAsNonRoot - 윈도우에는 root 사용자가 없다. 가장 가까운 항목은 노드에 존재하지 않는 아이덴티티인 ContainerAdministrator이다. + +* V1.PodSecurityContext.RunAsNonRoot - 윈도우에는 root 사용자가 없다. 가장 + 가까운 항목은 노드에 존재하지 않는 아이덴티티인 + ContainerAdministrator이다. + * V1.PodSecurityContext.SupplementalGroups - 윈도우에서는 사용할 수 없는 GID를 제공한다. -* V1.PodSecurityContext.Sysctls - 이것들은 리눅스 sysctl 인터페이스의 일부이다. 윈도우에는 이에 상응하는 것이 없다. + +* V1.PodSecurityContext.Sysctls - 이것들은 리눅스 sysctl 인터페이스의 + 일부이다. 윈도우에는 이에 상응하는 것이 없다. + +#### 운영 체제 버전 제한 + +윈도우에는 호스트 OS 버전이 컨테이너 베이스 이미지 OS 버전과 일치해야 하는 +엄격한 호환성 규칙이 있다. 윈도우 서버 2019의 컨테이너 +운영 체제가 있는 윈도우 컨테이너만 지원된다. 윈도우 컨테이너 이미지 버전의 일부 +이전 버전과의 호환성을 가능하게 하는 컨테이너의 Hyper-V 격리는 +향후 릴리스로 계획되어 있다. ## 도움 받기 및 트러블슈팅 {#troubleshooting} -쿠버네티스 클러스터 트러블슈팅을 위한 기본 도움말은 이 [섹션](/docs/tasks/debug-application-cluster/troubleshooting/)에서 먼저 찾아야 한다. 이 섹션에는 몇 가지 추가 윈도우 관련 트러블슈팅 도움말이 포함되어 있다. 로그는 쿠버네티스에서 트러블슈팅하는데 중요한 요소이다. 다른 기여자로부터 트러블슈팅 지원을 구할 때마다 이를 포함해야 한다. SIG-Windows [로그 수집에 대한 기여 가이드](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)의 지침을 따른다. +쿠버네티스 클러스터 트러블슈팅을 위한 기본 +도움말은 이 +[섹션](/docs/tasks/debug-application-cluster/troubleshooting/)에서 먼저 찾아야 한다. 이 +섹션에는 몇 가지 추가 윈도우 관련 트러블슈팅 도움말이 포함되어 있다. +로그는 쿠버네티스에서 트러블슈팅하는데 중요한 요소이다. 다른 +기여자로부터 트러블슈팅 지원을 구할 때마다 이를 포함해야 +한다. SIG-Windows +[로그 수집에 대한 기여 가이드](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)의 지침을 따른다. -1. start.ps1이 성공적으로 완료되었는지 어떻게 알 수 있는가? +* start.ps1이 성공적으로 완료되었는지 어떻게 알 수 있는가? - kubelet, kube-proxy 및 (Flannel을 네트워킹 솔루션으로 선택한 경우) 노드에서 실행 중인 flanneld 호스트 에이전트 프로세스를 확인할 수 있어야 하는데, 별도의 PowerShell 윈도우에서 실행 중인 로그가 표시된다. 또한 윈도우 노드는 쿠버네티스 클러스터에서 "Ready"로 조회되어야 한다. + kubelet, kube-proxy 및 (Flannel을 네트워킹 솔루션으로 + 선택한 경우) 노드에서 실행 중인 flanneld 호스트 에이전트 프로세스를 + 확인할 수 있어야 하는데, 별도의 PowerShell 윈도우에서 실행 중인 로그가 표시된다. 또한 + 윈도우 노드는 쿠버네티스 클러스터에서 "Ready"로 조회되어야 + 한다. -1. 백그라운드에서 서비스로 실행되도록 쿠버네티스 노드 프로세스를 구성할 수 있는가? +* 백그라운드에서 서비스로 실행되도록 쿠버네티스 노드 프로세스를 구성할 수 있는가? - Kubelet 및 kube-proxy는 이미 기본 윈도우 서비스로 실행되도록 구성되어 있으며, 실패(예: 프로세스 충돌) 시 서비스를 자동으로 다시 시작하여 복원력(resiliency)을 제공한다. 이러한 노드 컴포넌트를 서비스로 구성하기 위한 두 가지 옵션이 있다. + Kubelet 및 kube-proxy는 이미 기본 윈도우 서비스로 실행되도록 + 구성되어 있으며, 실패(예: 프로세스 충돌) 시 서비스를 + 자동으로 다시 시작하여 복원력(resiliency)을 + 제공한다. 이러한 노드 컴포넌트를 서비스로 구성하기 위한 + 두 가지 옵션이 있다. - 1. 네이티브 윈도우 서비스 + * 네이티브 윈도우 서비스 - Kubelet와 kube-proxy는 `sc.exe`를 사용하여 네이티브 윈도우 서비스로 실행될 수 있다. - - ```powershell - # 두 개의 개별 명령으로 kubelet 및 kube-proxy에 대한 서비스 생성 - sc.exe create <컴포넌트_명> binPath= "<바이너리_경로> --service <다른_인자>" - - # 인자에 공백이 포함된 경우 이스케이프 되어야 한다. - sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' <다른_인자>" - - # 서비스 시작 - Start-Service kubelet - Start-Service kube-proxy - - # 서비스 중지 - Stop-Service kubelet (-Force) - Stop-Service kube-proxy (-Force) - - # 서비스 상태 질의 - Get-Service kubelet - Get-Service kube-proxy - ``` - - 1. nssm.exe 사용 - - 또한 언제든지 [nssm.exe](https://nssm.cc/)와 같은 대체 서비스 관리자를 사용하여 백그라운드에서 이러한 프로세스(flanneld, kubelet, kube-proxy)를 실행할 수 있다. 이 [샘플 스크립트](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1)를 사용하여 백그라운드에서 윈도우 서비스로 실행하기 위해 nssm.exe를 활용하여 kubelet, kube-proxy, flanneld.exe를 등록할 수 있다. - - ```powershell - register-svc.ps1 -NetworkMode <네트워크 모드> -ManagementIP <윈도우 노드 IP> -ClusterCIDR <클러스터 서브넷> -KubeDnsServiceIP -LogDir <로그 위치 디렉터리> - - # NetworkMode = 네트워크 모드 l2bridge(flannel host-gw, 기본값이기도 함) 또는 네트워크 솔루션으로 선택한 오버레이(flannel vxlan) - # ManagementIP = 윈도우 노드에 할당된 IP 주소. ipconfig를 사용하여 찾을 수 있다. - # ClusterCIDR = 클러스터 서브넷 범위. (기본값 10.244.0.0/16) - # KubeDnsServiceIP = 쿠버네티스 DNS 서비스 IP (기본값 10.96.0.10) - # LogDir = kubelet 및 kube-proxy 로그가 각각의 출력 파일로 리다이렉션되는 디렉터리(기본값 C:\k) - ``` - - 위에 언급된 스크립트가 적합하지 않은 경우, 다음 예제를 사용하여 nssm.exe를 수동으로 구성할 수 있다. - ```powershell - # flanneld.exe 등록 - nssm install flanneld C:\flannel\flanneld.exe - nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 - nssm set flanneld AppEnvironmentExtra NODE_NAME= - nssm set flanneld AppDirectory C:\flannel - nssm start flanneld - - # kubelet.exe 등록 - # Microsoft는 mcr.microsoft.com/oss/kubernetes/pause:1.4.1에서 pause 인프라 컨테이너를 릴리스했다. - nssm install kubelet C:\k\kubelet.exe - nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=mcr.microsoft.com/oss/kubernetes/pause:1.4.1 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config - nssm set kubelet AppDirectory C:\k - nssm start kubelet - - # kube-proxy.exe 등록 (l2bridge / host-gw) - nssm install kube-proxy C:\k\kube-proxy.exe - nssm set kube-proxy AppDirectory c:\k - nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=--kubeconfig=c:\k\config --enable-dsr=false --log-dir= --logtostderr=false - nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0 - nssm set kube-proxy DependOnService kubelet - nssm start kube-proxy - - # kube-proxy.exe 등록 (overlay / vxlan) - nssm install kube-proxy C:\k\kube-proxy.exe - nssm set kube-proxy AppDirectory c:\k - nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override= --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip= --enable-dsr=false --log-dir= --logtostderr=false - nssm set kube-proxy DependOnService kubelet - nssm start kube-proxy - ``` - - - 초기 트러블슈팅을 위해 [nssm.exe](https://nssm.cc/)에서 다음 플래그를 사용하여 stdout 및 stderr을 출력 파일로 리다이렉션할 수 있다. - - ```powershell - nssm set AppStdout C:\k\mysvc.log - nssm set AppStderr C:\k\mysvc.log - ``` - - 자세한 내용은 공식 [nssm 사용](https://nssm.cc/usage) 문서를 참고한다. - -1. 내 윈도우 파드에 네트워크 연결이 없다. - - 가상 머신을 사용하는 경우, 모든 VM 네트워크 어댑터에서 MAC 스푸핑이 활성화되어 있는지 확인한다. - -1. 내 윈도우 파드가 외부 리소스를 ping 할 수 없다. - - 윈도우 파드에는 현재 ICMP 프로토콜용으로 프로그래밍된 아웃바운드 규칙이 없다. 그러나 TCP/UDP는 지원된다. 클러스터 외부 리소스에 대한 연결을 시연하려는 경우, `ping `를 해당 `curl `명령으로 대체한다. - - 여전히 문제가 발생하는 경우, [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf)의 네트워크 구성에 특별히 추가 확인이 필요하다. 언제든지 이 정적 파일을 편집할 수 있다. 구성 업데이트는 새로 생성된 모든 쿠버네티스 리소스에 적용된다. - - 쿠버네티스 네트워킹 요구 사항 중 하나([쿠버네티스 모델](/ko/docs/concepts/cluster-administration/networking/))는 클러스터 통신이 내부적으로 NAT 없이 발생하는 것이다. 이 요구 사항을 준수하기 위해 아웃바운드 NAT가 발생하지 않도록 하는 모든 통신에 대한 [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20)가 있다. 그러나 이것은 쿼리하려는 외부 IP를 ExceptionList에서 제외해야 함도 의미한다. 그래야만 윈도우 파드에서 발생하는 트래픽이 제대로 SNAT 되어 외부에서 응답을 받는다. 이와 관련하여 `cni.conf`의 ExceptionList는 다음과 같아야 한다. - - ```conf - "ExceptionList": [ - "10.244.0.0/16", # 클러스터 서브넷 - "10.96.0.0/12", # 서비스 서브넷 - "10.127.130.0/24" # 관리(호스트) 서브넷 - ] - ``` - -1. 내 윈도우 노드가 NodePort 서비스에 접근할 수 없다. - - 노드 자체에서는 로컬 NodePort 접근이 실패한다. 이것은 알려진 제약사항이다. NodePort 접근은 다른 노드 또는 외부 클라이언트에서는 가능하다. - -1. 컨테이너의 vNIC 및 HNS 엔드포인트가 삭제되었다. - - 이 문제는 `hostname-override` 파라미터가 [kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/)에 전달되지 않은 경우 발생할 수 있다. 이를 해결하려면 사용자는 다음과 같이 hostname을 kube-proxy에 전달해야 한다. + Kubelet와 kube-proxy는 `sc.exe`를 사용하여 네이티브 윈도우 서비스로 실행될 수 있다. ```powershell - C:\k\kube-proxy.exe --hostname-override=$(hostname) + # 두 개의 개별 명령으로 kubelet 및 kube-proxy에 대한 서비스 생성 + sc.exe create <컴포넌트_명> binPath= "<바이너리_경로> --service <다른_인자>" + + # 인자에 공백이 포함된 경우 이스케이프 되어야 한다. + sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' <다른_인자>" + + # 서비스 시작 + Start-Service kubelet + Start-Service kube-proxy + + # 서비스 중지 + Stop-Service kubelet (-Force) + Stop-Service kube-proxy (-Force) + + # 서비스 상태 질의 + Get-Service kubelet + Get-Service kube-proxy ``` -1. 플란넬(flannel)을 사용하면 클러스터에 다시 조인(join)한 후 노드에 이슈가 발생한다. + * nssm.exe 사용 - 이전에 삭제된 노드가 클러스터에 다시 조인될 때마다, flannelD는 새 파드 서브넷을 노드에 할당하려고 한다. 사용자는 다음 경로에서 이전 파드 서브넷 구성 파일을 제거해야 한다. + 또한 언제든지 [nssm.exe](https://nssm.cc/)와 같은 + 대체 서비스 관리자를 사용하여 백그라운드에서 이러한 프로세스(flanneld, kubelet, + kube-proxy)를 실행할 수 있다. 이 + [샘플 스크립트](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1)를 사용하여 + 백그라운드에서 윈도우 서비스로 실행하기 위해 `nssm.exe`를 활용하여 kubelet, kube-proxy, + `flanneld.exe`를 등록할 수 있다. ```powershell - Remove-Item C:\k\SourceVip.json - Remove-Item C:\k\SourceVipRequest.json + register-svc.ps1 -NetworkMode <네트워크 모드> -ManagementIP <윈도우 노드 IP> -ClusterCIDR <클러스터 서브넷> -KubeDnsServiceIP -LogDir <로그 위치 디렉터리> ``` + 파라미터 설명은 아래와 같다. -1. `start.ps1`을 시작한 후, flanneld가 "Waiting for the Network to be created"에서 멈춘다. + - `NetworkMode`: 네트워크 모드 l2bridge(flannel host-gw, + 기본값이기도 함) 또는 네트워크 솔루션으로 선택한 오버레이(flannel vxlan) + - `ManagementIP`: 윈도우 노드에 할당된 IP 주소. `ipconfig`를 사용하여 + 찾을 수 있다. + - `ClusterCIDR`: 클러스터 서브넷 범위. (기본값 10.244.0.0/16) + - `KubeDnsServiceIP`: 쿠버네티스 DNS 서비스 IP (기본값 10.96.0.10) + - `LogDir`: kubelet 및 kube-proxy 로그가 각각의 출력 파일로 + 리다이렉션되는 디렉터리(기본값 C:\k) - 이 [이슈](https://github.com/coreos/flannel/issues/1066)에 대한 수많은 보고가 있다. 플란넬 네트워크의 관리 IP가 설정될 때의 타이밍 이슈일 가능성이 높다. 해결 방법은 start.ps1을 다시 시작하거나 다음과 같이 수동으로 다시 시작하는 것이다. + 위에 언급된 스크립트가 적합하지 않은 경우, 다음 예제를 사용하여 + `nssm.exe`를 수동으로 구성할 수 있다. + + flanneld.exe를 등록한다. ```powershell - PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "") - PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 + nssm install flanneld C:\flannel\flanneld.exe + nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 + nssm set flanneld AppEnvironmentExtra NODE_NAME= + nssm set flanneld AppDirectory C:\flannel + nssm start flanneld ``` -1. `/run/flannel/subnet.env` 누락으로 인해 윈도우 파드를 시작할 수 없다. - - 이것은 플란넬이 제대로 실행되지 않았음을 나타낸다. flanneld.exe를 다시 시작하거나 쿠버네티스 마스터의 `/run/flannel/subnet.env`에서 윈도우 워커 노드의 `C:\run\flannel\subnet.env`로 파일을 수동으로 복사할 수 있고, `FLANNEL_SUBNET` 행을 다른 숫자로 수정한다. 예를 들어, 다음은 노드 서브넷 10.244.4.1/24가 필요한 경우이다. - - ```env - FLANNEL_NETWORK=10.244.0.0/16 - FLANNEL_SUBNET=10.244.4.1/24 - FLANNEL_MTU=1500 - FLANNEL_IPMASQ=true - ``` - -1. 내 윈도우 노드가 서비스 IP를 사용하여 내 서비스에 접근할 수 없다. - - 이는 윈도우에서 현재 네트워킹 스택의 알려진 제약 사항이다. 그러나 윈도우 파드는 서비스 IP에 접근할 수 있다. - -1. kubelet을 시작할 때 네트워크 어댑터를 찾을 수 없다. - - 윈도우 네트워킹 스택에는 쿠버네티스 네트워킹이 작동하기 위한 가상 어댑터가 필요하다. 다음 명령이 (어드민 셸에서) 결과를 반환하지 않으면, Kubelet이 작동하는데 필요한 필수 구성 요소인 가상 네트워크 생성이 실패한 것이다. + kubelet.exe를 등록한다. ```powershell - Get-HnsNetwork | ? Name -ieq "cbr0" - Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*" + # Microsoft는 mcr.microsoft.com/oss/kubernetes/pause:1.4.1에서 pause 인프라 컨테이너를 릴리스했다. + nssm install kubelet C:\k\kubelet.exe + nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=mcr.microsoft.com/oss/kubernetes/pause:1.4.1 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config + nssm set kubelet AppDirectory C:\k + nssm start kubelet ``` - 호스트 네트워크 어댑터가 "Ethernet"이 아닌 경우, 종종 start.ps1 스크립트의 [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) 파라미터를 수정하는 것이 좋다. 그렇지 않으면 `start-kubelet.ps1` 스크립트의 출력을 참조하여 가상 네트워크 생성 중에 오류가 있는지 확인한다. + kube-proxy.exe를 등록한다(l2bridge / host-gw). -1. 내 파드가 "Container Creating"에서 멈췄거나 계속해서 다시 시작된다. - - pause 이미지가 OS 버전과 호환되는지 확인한다. [지침](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)에서는 OS와 컨테이너가 모두 버전 1803이라고 가정한다. 이후 버전의 윈도우가 있는 경우, Insider 빌드와 같이 그에 따라 이미지를 조정해야 한다. 이미지는 Microsoft의 [도커 리포지터리](https://hub.docker.com/u/microsoft/)를 참조한다. 그럼에도 불구하고, pause 이미지 Dockerfile과 샘플 서비스는 이미지가 :latest로 태그될 것으로 예상한다. - -1. DNS 확인(resolution)이 제대로 작동하지 않는다. - - 이 [섹션](#dns-limitations)에서 윈도우에 대한 DNS 제한을 확인한다. - -1. `kubectl port-forward`가 "unable to do port forwarding: wincat not found"로 실패한다. - - 이는 쿠버네티스 1.15 및 pause 인프라 컨테이너 `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`에서 구현되었다. 해당 버전 또는 최신 버전을 사용해야 한다. - 자체 pause 인프라 컨테이너를 빌드하려면 [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)을 포함해야 한다. - -1. 내 윈도우 서버 노드가 프록시 뒤에 있기 때문에 내 쿠버네티스 설치가 실패한다. - - 프록시 뒤에 있는 경우 다음 PowerShell 환경 변수를 정의해야 한다. - - ```PowerShell - [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) - [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) + ```powershell + nssm install kube-proxy C:\k\kube-proxy.exe + nssm set kube-proxy AppDirectory c:\k + nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=--kubeconfig=c:\k\config --enable-dsr=false --log-dir= --logtostderr=false + nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0 + nssm set kube-proxy DependOnService kubelet + nssm start kube-proxy ``` -1. `pause` 컨테이너란 무엇인가? + kube-proxy.exe를 등록한다(overlay / vxlan). - 쿠버네티스 파드에서는 컨테이너 엔드포인트를 호스팅하기 위해 먼저 인프라 또는 "pause" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여 동일한 파드에 속하는 컨테이너는 공통 네트워크 네임스페이스 및 엔드포인트(동일한 IP 및 포트 공간)를 공유한다. 네트워크 구성을 잃지 않고 워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 pause 컨테이너가 필요하다. + ```powershell + nssm install kube-proxy C:\k\kube-proxy.exe + nssm set kube-proxy AppDirectory c:\k + nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override= --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip= --enable-dsr=false --log-dir= --logtostderr=false + nssm set kube-proxy DependOnService kubelet + nssm start kube-proxy + ``` - "pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서 호스팅된다. `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`을 사용하여 접근할 수 있다. 자세한 내용은 [DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile)을 참고한다. + + 초기 트러블슈팅을 위해 [nssm.exe](https://nssm.cc/)에서 + 다음 플래그를 사용하여 stdout 및 stderr을 출력 파일로 리다이렉션할 수 있다. + + ```powershell + nssm set AppStdout C:\k\mysvc.log + nssm set AppStderr C:\k\mysvc.log + ``` + + 자세한 내용은 공식 [nssm 사용](https://nssm.cc/usage) 문서를 참고한다. + +* 내 윈도우 파드에 네트워크 연결이 없다. + + 가상 머신을 사용하는 경우, 모든 VM 네트워크 어댑터에서 MAC 스푸핑이 + 활성화되어 있는지 확인한다. + +* 내 윈도우 파드가 외부 리소스를 ping 할 수 없다. + + 윈도우 파드에는 현재 ICMP 프로토콜용으로 프로그래밍된 아웃바운드 + 규칙이 없다. 그러나 TCP/UDP는 지원된다. 클러스터 외부 리소스에 대한 연결을 + 시연하려는 경우, `ping `를 해당 `curl `명령으로 + 대체한다. + + 여전히 문제가 발생하는 경우, + [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf)의 + 네트워크 구성에 특별히 추가 확인이 필요하다. 언제든지 이 정적 파일을 편집할 수 있다. 구성 + 업데이트는 새로 생성된 모든 쿠버네티스 리소스에 적용된다. + + 쿠버네티스 네트워킹 요구 사항 중 + 하나([쿠버네티스 모델](/ko/docs/concepts/cluster-administration/networking/))는 + 클러스터 통신이 내부적으로 NAT 없이 발생하는 것이다. 이 요구 사항을 + 준수하기 위해 아웃바운드 NAT가 발생하지 않도록 하는 모든 통신에 대한 + [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20)가 + 있다. 그러나 + 이것은 쿼리하려는 외부 IP를 ExceptionList에서 + 제외해야 함도 의미한다. 그래야만 윈도우 파드에서 발생하는 트래픽이 제대로 SNAT 되어 + 외부에서 응답을 받는다. 이와 관련하여 `cni.conf`의 ExceptionList는 다음과 + 같아야 한다. + + ```conf + "ExceptionList": [ + "10.244.0.0/16", # 클러스터 서브넷 + "10.96.0.0/12", # 서비스 서브넷 + "10.127.130.0/24" # 관리(호스트) 서브넷 + ] + ``` + +* 내 윈도우 노드가 NodePort 서비스에 접근할 수 없다. + + 노드 자체에서는 로컬 NodePort 접근이 실패한다. 이것은 알려진 + 제약사항이다. NodePort 접근은 다른 노드 또는 외부 클라이언트에서는 가능하다. + +* 컨테이너의 vNIC 및 HNS 엔드포인트가 삭제되었다. + + 이 문제는 `hostname-override` 파라미터가 + [kube-proxy](/ko/docs/reference/command-line-tools-reference/kube-proxy/)에 + 전달되지 않은 경우 발생할 수 있다. + 이를 해결하려면 사용자는 다음과 같이 hostname을 kube-proxy에 전달해야 한다. + + ```powershell + C:\k\kube-proxy.exe --hostname-override=$(hostname) + ``` + +* 플란넬(flannel)을 사용하면 클러스터에 다시 조인(join)한 후 노드에 이슈가 발생한다. + + 이전에 삭제된 노드가 클러스터에 다시 조인될 때마다, + flannelD는 새 파드 서브넷을 노드에 할당하려고 한다. 사용자는 다음 경로에서 + 이전 파드 서브넷 구성 파일을 제거해야 한다. + + ```powershell + Remove-Item C:\k\SourceVip.json + Remove-Item C:\k\SourceVipRequest.json + ``` + +* `start.ps1`을 시작한 후, flanneld가 "Waiting for the Network + to be created"에서 멈춘다. + + 이 [이슈](https://github.com/coreos/flannel/issues/1066)에 + 대한 수많은 보고가 있다. 플란넬 네트워크의 + 관리 IP가 설정될 때의 타이밍 이슈일 가능성이 높다. 해결 + 방법은 start.ps1을 다시 시작하거나 다음과 같이 수동으로 다시 시작하는 것이다. + + ```powershell + PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "") + PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 + ``` + +* `/run/flannel/subnet.env` 누락으로 인해 윈도우 파드를 시작할 수 없다. + + 이것은 플란넬이 제대로 실행되지 않았음을 나타낸다. flanneld.exe를 + 다시 시작하거나 쿠버네티스 마스터의 + `/run/flannel/subnet.env`에서 윈도우 워커 노드의 + `C:\run\flannel\subnet.env`로 파일을 수동으로 복사할 수 있고, + `FLANNEL_SUBNET` 행을 다른 숫자로 수정한다. 예를 들어, 다음은 노드 서브넷 + 10.244.4.1/24가 필요한 경우이다. + + ```none + FLANNEL_NETWORK=10.244.0.0/16 + FLANNEL_SUBNET=10.244.4.1/24 + FLANNEL_MTU=1500 + FLANNEL_IPMASQ=true + ``` + +* 내 윈도우 노드가 서비스 IP를 사용하여 내 서비스에 접근할 수 없다. + + 이는 윈도우에서 현재 네트워킹 스택의 알려진 제약 사항이다. + 그러나 윈도우 파드는 서비스 IP에 접근할 수 있다. + +* kubelet을 시작할 때 네트워크 어댑터를 찾을 수 없다. + + 윈도우 네트워킹 스택에는 쿠버네티스 네트워킹이 작동하기 위한 + 가상 어댑터가 필요하다. 다음 명령이 (어드민 셸에서) 결과를 반환하지 + 않으면, Kubelet이 작동하는데 필요한 필수 구성 요소인 가상 네트워크 생성이 + 실패한 것이다. + + ```powershell + Get-HnsNetwork | ? Name -ieq "cbr0" + Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*" + ``` + + 호스트 네트워크 어댑터가 "Ethernet"이 아닌 경우, + 종종 start.ps1 스크립트의 + [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) + 파라미터를 수정하는 것이 좋다. 그렇지 않으면 `start-kubelet.ps1` + 스크립트의 출력을 참조하여 가상 네트워크 생성 중에 오류가 있는지 확인한다. + +* 내 파드가 "Container Creating"에서 멈췄거나 계속해서 다시 시작된다. + + pause 이미지가 OS 버전과 호환되는지 확인한다. + [지침](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)에서는 + OS와 컨테이너가 모두 버전 1803이라고 가정한다. 이후 버전의 + 윈도우가 있는 경우, Insider 빌드와 같이 그에 따라 이미지를 + 조정해야 한다. 이미지는 Microsoft의 + [도커 리포지터리](https://hub.docker.com/u/microsoft/)를 참조한다. + 그럼에도 불구하고, pause 이미지 Dockerfile과 샘플 서비스는 이미지가 + :latest로 태그될 것으로 예상한다. + +* DNS 확인(resolution)이 제대로 작동하지 않는다. + + [윈도우에 대한 DNS 제한](#dns-limitations)을 확인한다. + +* `kubectl port-forward`가 "unable to do port forwarding: wincat not found"로 실패한다. + + 이는 쿠버네티스 1.15 및 pause 인프라 컨테이너 + `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`에서 구현되었다. + 해당 버전 또는 최신 버전을 사용해야 한다. 자체 pause + 인프라 컨테이너를 빌드하려면 + [wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)을 포함해야 한다. + +* 내 윈도우 서버 노드가 프록시 뒤에 있기 때문에 내 쿠버네티스 + 설치가 실패한다. + + 프록시 뒤에 있는 경우 다음 PowerShell 환경 변수를 + 정의해야 한다. + + ```PowerShell + [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) + [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) + ``` + +* `pause` 컨테이너란 무엇인가? + + 쿠버네티스 파드에서는 컨테이너 엔드포인트를 호스팅하기 위해 + 먼저 인프라 또는 "pause" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여 + 동일한 파드에 속하는 컨테이너는 공통 네트워크 네임스페이스 및 + 엔드포인트(동일한 IP 및 포트 공간)를 공유한다. 네트워크 구성을 잃지 않고 + 워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 pause 컨테이너가 + 필요하다. + + "pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서 + 호스팅된다. `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`을 사용하여 접근할 수 있다. + 자세한 내용은 + [DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile)을 참고한다. ### 추가 조사 -이러한 단계로 문제가 해결되지 않으면, 다음을 통해 쿠버네티스의 윈도우 노드에서 윈도우 컨테이너를 실행하는데 도움을 받을 수 있다. +이러한 단계로 문제가 해결되지 않으면, 다음을 통해 쿠버네티스의 윈도우 노드에서 +윈도우 컨테이너를 실행하는데 도움을 받을 수 있다. * 스택오버플로우 [윈도우 서버 컨테이너](https://stackoverflow.com/questions/tagged/windows-server-container) 주제 + * 쿠버네티스 공식 포럼 [discuss.kubernetes.io](https://discuss.kubernetes.io/) + * 쿠버네티스 슬랙 [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows) ## 이슈 리포팅 및 기능 요청 -버그처럼 보이는 부분이 있거나 기능 요청을 하고 싶다면, [GitHub 이슈 트래킹 시스템](https://github.com/kubernetes/kubernetes/issues)을 활용한다. [GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose)에서 이슈를 열고 SIG-Windows에 할당할 수 있다. 먼저 이전에 보고된 이슈 목록을 검색하고 이슈에 대한 경험을 언급하고 추가 로그를 첨부해야 한다. SIG-Windows 슬랙은 티켓을 만들기 전에 초기 지원 및 트러블슈팅 아이디어를 얻을 수 있는 좋은 방법이기도 하다. +버그처럼 보이는 부분이 있거나 기능 +요청을 하고 싶다면, +[GitHub 이슈 트래킹 시스템](https://github.com/kubernetes/kubernetes/issues)을 +활용한다. +[GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose)에서 이슈를 열고 +SIG-Windows에 할당할 수 있다. 먼저 이전에 보고된 이슈 목록을 검색하고 +이슈에 대한 경험을 언급하고 추가 로그를 +첨부해야 한다. SIG-Windows 슬랙은 티켓을 만들기 전에 초기 지원 및 +트러블슈팅 아이디어를 얻을 수 있는 좋은 방법이기도 하다. -버그를 제출하는 경우, 다음과 같이 문제를 재현하는 방법에 대한 자세한 정보를 포함한다. +버그를 제출하는 경우, 다음과 같이 문제를 재현하는 방법에 대한 자세한 정보를 +포함한다. * 쿠버네티스 버전: kubectl version -* 환경 세부사항: 클라우드 공급자, OS 배포판, 네트워킹 선택 및 구성, 도커 버전 +* 환경 세부사항: 클라우드 공급자, OS 배포판, 네트워킹 선택 및 + 구성, 도커 버전 * 문제를 재현하기 위한 세부 단계 * [관련 로그](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) -* SIG-Windows 회원의 주의를 끌 수 있도록 `/sig windows`로 이슈에 대해 어노테이션을 달아 이슈에 sig/windows 태그를 지정한다. +* SIG-Windows 회원의 주의를 끌 수 있도록 `/sig windows`로 이슈에 대해 어노테이션을 달아 + 이슈에 sig/windows 태그를 지정한다. ## {{% heading "whatsnext" %}} -로드맵에는 많은 기능이 있다. 요약된 높은 수준의 목록이 아래에 포함되어 있지만, [로드맵 프로젝트](https://github.com/orgs/kubernetes/projects/8)를 보고 [기여](https://github.com/kubernetes/community/blob/master/sig-windows/)하여 윈도우 지원을 개선하는데 도움이 주는 것이 좋다. +로드맵에는 많은 기능이 있다. 요약된 높은 수준의 +목록이 아래에 포함되어 있지만, +[로드맵 프로젝트](https://github.com/orgs/kubernetes/projects/8)를 보고 +[기여](https://github.com/kubernetes/community/blob/master/sig-windows/)하여 +윈도우 지원을 개선하는데 도움이 주는 것이 좋다. ### Hyper-V 격리(isolation) -쿠버네티스에서 윈도우 컨테이너에 대해 다음 유스케이스를 사용하려면 Hyper-V 격리가 필요하다. +쿠버네티스에서 윈도우 컨테이너에 대해 다음 유스케이스를 사용하려면 +Hyper-V 격리가 필요하다. * 추가 보안을 위해 파드 간 하이퍼바이저 기반 격리 -* 하위 호환성을 통해 컨테이너를 다시 빌드할 필요 없이 노드에서 최신 윈도우 서버 버전을 실행할 수 있다. + +* 하위 호환성을 통해 컨테이너를 다시 빌드할 필요 없이 노드에서 + 최신 윈도우 서버 버전을 실행할 수 있다. + * 파드에 대한 특정 CPU/NUMA 설정 + * 메모리 격리 및 예약 -Hyper-V 격리 지원은 이후 릴리스에 추가되며 CRI-Containerd가 필요하다. +Hyper-V 격리 지원은 이후 릴리스에 추가되며 +CRI-Containerd가 필요하다. ### kubeadm 및 클러스터 API를 사용한 배포 Kubeadm은 사용자가 쿠버네티스 클러스터를 배포하기 위한 사실상의 표준이 되고 있다. kubeadm의 윈도우 노드 지원은 현재 작업 중이지만 -[여기](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)에서 가이드를 사용할 수 있다. +[여기](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)에서 +가이드를 사용할 수 있다. 또한 윈도우 노드가 적절하게 프로비저닝되도록 클러스터 API에 투자하고 있다. diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md index aabc838ea5..5c3d52e475 100644 --- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md @@ -6,7 +6,8 @@ weight: 75 -많은 조직에서 실행하는 서비스와 애플리케이션의 상당 부분이 윈도우 애플리케이션으로 구성된다. 이 가이드는 쿠버네티스에서 윈도우 컨테이너를 구성하고 배포하는 단계를 안내한다. +많은 조직에서 실행하는 서비스와 애플리케이션의 상당 부분이 윈도우 애플리케이션으로 구성된다. +이 가이드는 쿠버네티스에서 윈도우 컨테이너를 구성하고 배포하는 단계를 안내한다. @@ -19,12 +20,18 @@ weight: 75 ## 시작하기 전에 -* [윈도우 서버에서 운영하는 마스터와 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를 포함한 쿠버네티스 클러스터를 생성한다. -* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너 모두 비슷한 방식이라는 것이 중요하다. [Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다. 아래 단원의 예시는 윈도우 컨테이너를 경험하기 위해 제공한다. +* [윈도우 서버에서 운영하는 마스터와 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를 +포함한 쿠버네티스 클러스터를 생성한다. +* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너 +모두 비슷한 방식이라는 것이 중요하다. +[Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다. +아래 단원의 예시를 통해 윈도우 컨테이너와 좀 더 빨리 친숙해질 수 있다. ## 시작하기: 윈도우 컨테이너 배포하기 -쿠버네티스에서 윈도우 컨테이너를 배포하려면, 먼저 예시 애플리케이션을 생성해야 한다. 아래 예시 YAML 파일은 간단한 웹서버 애플리케이션을 생성한다. 아래 내용으로 채운 서비스 스펙을 `win-webserver.yaml`로 생성하자. +쿠버네티스에서 윈도우 컨테이너를 배포하려면, 먼저 예시 애플리케이션을 생성해야 한다. +아래 예시 YAML 파일은 간단한 웹서버 애플리케이션을 생성한다. +아래 내용으로 채운 서비스 스펙을 `win-webserver.yaml`로 생성하자. ```yaml apiVersion: v1 @@ -71,7 +78,8 @@ spec: ``` {{< note >}} -포트 매핑도 지원하지만, 간략한 예시를 위해 컨테이너 포트 80을 직접 서비스로 노출한다. +포트 매핑도 지원하지만, 간략한 예시를 위해 +컨테이너 포트 80을 직접 서비스로 노출한다. {{< /note >}} 1. 모든 노드가 건강한지 확인한다. @@ -91,53 +99,87 @@ spec: 1. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자. - * 윈도우 노드에 파드당 두 컨테이너, `docker ps`를 사용한다. - * 리눅스 마스터에서 나열된 두 파드, `kubectl get pods`를 사용한다. - * 네트워크를 통한 노드에서 파드 간에 통신, 리눅스 마스터에서 `curl`을 파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다. - * 파드와 파드 간에 통신, `docker exec` 나 `kubectl exec`를 이용해 파드 간에 핑(ping)한다(윈도우 노드를 여럿가지고 있다면 호스트를 달리하며). - * 서비스와 파드 간에 통신, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스 IP 주소(`kubectl get services`로 보여지는)로 실행한다. - * 서비스 검색(discovery), 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다. - * 인바운드 연결, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다. - * 아웃바운드 연결, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다. + * 윈도우 노드에 파드당 두 컨테이너가 존재하는지 확인하려면, `docker ps`를 사용한다. + * 리눅스 마스터에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다. + * 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터에서 `curl`을 + 파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다. + * 파드 간 통신이 되는지 확인하려면, `docker exec` 나 `kubectl exec`를 이용해 파드 간에 + 핑(ping)한다(윈도우 노드가 2대 이상이라면, 서로 다른 노드에 있는 파드 간 통신도 확인할 수 있다). + * 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스 + IP 주소(`kubectl get services`로 볼 수 있는)로 실행한다. + * 서비스 검색(discovery)이 되는지 확인하려면, 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다. + * 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다. + * 아웃바운드 연결이 되는지 확인하려면, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다. {{< note >}} -윈도우 컨테이너 호스트는 현재 윈도우 네트워킹 스택의 플랫폼 제한으로 인해, 그 안에서 스케줄링하는 서비스의 IP 주소로 접근할 수 없다. 윈도우 파드만 서비스 IP 주소로 접근할 수 있다. +윈도우 컨테이너 호스트는 현재 윈도우 네트워킹 스택의 플랫폼 제한으로 인해, 그 안에서 스케줄링하는 서비스의 IP 주소로 접근할 수 없다. +윈도우 파드만 서비스 IP 주소로 접근할 수 있다. {{< /note >}} ## 가시성 ### 워크로드에서 로그 캡쳐하기 -로그는 가시성의 중요한 요소이다. 로그는 사용자가 워크로드의 운영측면을 파악할 수 있도록 하며 문제 해결의 핵심 요소이다. 윈도우 컨테이너와 워크로드 내의 윈도우 컨테이너가 리눅스 컨테이너와는 다르게 동작하기 때문에, 사용자가 로그를 수집하는 데 어려움을 겪었기에 운영 가시성이 제한되었다. 예를 들어 윈도우 워크로드는 일반적으로 ETW(Event Tracing for Windows)에 로그인하거나 애플리케이션 이벤트 로그에 항목을 푸시하도록 구성한다. Microsoft의 오픈 소스 도구인 [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)는 윈도우 컨테이너 안에 구성된 로그 소스를 모니터링하는 권장하는 방법이다. LogMonitor는 이벤트 로그, ETW 공급자 그리고 사용자 정의 애플리케이션 로그 모니터링을 지원하고 `kubectl logs ` 에 의한 사용을 위해 STDOUT으로 파이프한다. +로그는 가시성의 중요한 요소이다. 로그는 사용자가 워크로드의 운영측면을 +파악할 수 있도록 하며 문제 해결의 핵심 요소이다. +윈도우 컨테이너, 그리고 윈도우 컨테이너 내의 워크로드는 리눅스 컨테이너와는 다르게 동작하기 때문에, +사용자가 로그를 수집하기 어려웠고 이로 인해 운영 가시성이 제한되어 왔다. +예를 들어 윈도우 워크로드는 일반적으로 ETW(Event Tracing for Windows)에 로그인하거나 +애플리케이션 이벤트 로그에 항목을 푸시하도록 구성한다. +Microsoft의 오픈 소스 도구인 [LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor)는 +윈도우 컨테이너 안에 구성된 로그 소스를 모니터링하는 권장하는 방법이다. +LogMonitor는 이벤트 로그, ETW 공급자 그리고 사용자 정의 애플리케이션 로그 모니터링을 지원하고 +`kubectl logs ` 에 의한 사용을 위해 STDOUT으로 파이프한다. -LogMonitor Github 페이지의 지침에 따라 모든 컨테이너 바이너리와 설정 파일을 복사하고, LogMonitor에 필요한 입력 지점을 추가해서 로그를 STDOUT으로 푸시한다. +LogMonitor GitHub 페이지의 지침에 따라 모든 컨테이너 바이너리와 설정 파일을 복사하고, +LogMonitor가 로그를 STDOUT으로 푸시할 수 있도록 필요한 엔트리포인트를 추가한다. ## 설정 가능한 컨테이너 username 사용하기 -쿠버네티스 v1.16 부터, 윈도우 컨테이너는 이미지 기본 값과는 다른 username으로 엔트리포인트와 프로세스를 실행하도록 설정할 수 있다. 이 방식은 리눅스 컨테이너에서 지원되는 방식과는 조금 차이가 있다. [여기](/docs/tasks/configure-pod-container/configure-runasusername/)에서 이에 대해 추가적으로 배울 수 있다. +쿠버네티스 v1.16 부터, 윈도우 컨테이너는 이미지 기본 값과는 다른 username으로 엔트리포인트와 프로세스를 +실행하도록 설정할 수 있다. +이 방식은 리눅스 컨테이너에서 지원되는 방식과는 조금 차이가 있다. +[여기](/ko/docs/tasks/configure-pod-container/configure-runasusername/)에서 이에 대해 추가적으로 배울 수 있다. ## 그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기 -쿠버네티스 v1.14부터 윈도우 컨테이너 워크로드는 그룹 매니지드 서비스 어카운트(GMSA, Group Managed Service Account)를 이용하여 구성할 수 있다. 그룹 매니지드 서비스 어카운트는 액티브 디렉터리 어카운트의 특정한 종류로 자동 암호 관리 기능, 단순화된 서비스 주체 이름(SPN, simplified service principal name), 여러 서버의 다른 관리자에게 관리를 위임하는 기능을 제공한다. GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동안 외부 액티브 디렉터리 도메인 리소스를 접근할 수 있다. 윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 [여기](/docs/tasks/configure-pod-container/configure-gmsa/)에서 알아보자. +쿠버네티스 v1.14부터 윈도우 컨테이너 워크로드는 그룹 매니지드 서비스 어카운트(GMSA, Group Managed Service Account)를 이용하여 구성할 수 있다. +그룹 매니지드 서비스 어카운트는 액티브 디렉터리 어카운트의 특정한 종류로 자동 암호 관리 기능, +단순화된 서비스 주체 이름(SPN, simplified service principal name), 여러 서버의 다른 관리자에게 관리를 위임하는 기능을 제공한다. +GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동안 외부 액티브 디렉터리 도메인 리소스를 접근할 수 있다. +윈도우 컨테이너를 위한 GMSA를 이용하고 구성하는 방법은 [여기](/docs/tasks/configure-pod-container/configure-gmsa/)에서 알아보자. ## 테인트(Taint)와 톨러레이션(Toleration) -오늘날 사용자는 리눅스와 윈도우 워크로드를 특정 OS 노드별로 보존하기 위해 테인트와 노드 셀렉터(nodeSelector)의 조합을 이용해야 한다. 이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데, 이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다. +오늘날 사용자는 리눅스와 윈도우 워크로드를 (동일한 OS를 실행하는) 적절한 노드에 할당되도록 하기 위해 테인트와 +노드셀렉터(nodeSelector)의 조합을 이용해야 한다. +이것은 윈도우 사용자에게만 부담을 줄 것으로 보인다. 아래는 권장되는 방식의 개요인데, +이것의 주요 목표 중에 하나는 이 방식이 기존 리눅스 워크로드와 호환되어야 한다는 것이다. ### 특정 OS 워크로드를 적절한 컨테이너 호스트에서 처리하도록 보장하기 -사용자는 윈도우 컨테이너가 테인트와 톨러레이션을 이용해서 적절한 호스트에서 스케줄링되기를 보장할 수 있다. 오늘날 모든 쿠버네티스 노드는 다음 기본 레이블을 가지고 있다. +사용자는 테인트와 톨러레이션을 이용하여 윈도우 컨테이너가 적절한 호스트에서 스케줄링되기를 보장할 수 있다. +오늘날 모든 쿠버네티스 노드는 다음 기본 레이블을 가지고 있다. * kubernetes.io/os = [windows|linux] * kubernetes.io/arch = [amd64|arm64|...] -파드 사양에 노드 셀렉터를 `"kubernetes.io/os": windows`와 같이 지정하지 않았다면, 그 파드는 리눅스나 윈도우, 아무 호스트에나 스케줄링될 수 있다. 윈도우 컨테이너는 윈도우에서만 운영될 수 있고 리눅스 컨테이너는 리눅스에서만 운영될 수 있기 때문에 이는 문제를 일으킬 수 있다. 가장 좋은 방법은 노드 셀렉터를 사용하는 것이다. +파드 사양에 노드 셀렉터를 `"kubernetes.io/os": windows`와 같이 지정하지 않았다면, +그 파드는 리눅스나 윈도우, 아무 호스트에나 스케줄링될 수 있다. +윈도우 컨테이너는 윈도우에서만 운영될 수 있고 리눅스 컨테이너는 리눅스에서만 운영될 수 있기 때문에 이는 문제를 일으킬 수 있다. +가장 좋은 방법은 노드 셀렉터를 사용하는 것이다. -그러나 많은 경우 사용자는 이미 존재하는 대량의 리눅스 컨테이너용 디플로이먼트를 가지고 있을 뿐만 아니라, 헬름(Helm) 차트 커뮤니티 같은 상용 구성의 에코시스템이나, 오퍼레이터(Operator) 같은 프로그래밍 방식의 파드 생성 사례가 있음을 알고 있다. 이런 상황에서는 노드 셀렉터를 추가하는 구성 변경을 망설일 수 있다. 이에 대한 대안은 테인트를 사용하는 것이다. Kubelet은 등록하는 동안 테인트를 설정할 수 있기 때문에, 윈도우에서만 운영할 때에 자동으로 테인트를 추가하기 쉽다. +그러나 많은 경우 사용자는 이미 존재하는 대량의 리눅스 컨테이너용 디플로이먼트를 가지고 있을 뿐만 아니라, +헬름(Helm) 차트 커뮤니티 같은 상용 구성의 에코시스템이나, 오퍼레이터(Operator) 같은 프로그래밍 방식의 파드 생성 사례가 있음을 알고 있다. +이런 상황에서는 노드 셀렉터를 추가하는 구성 변경을 망설일 수 있다. +이에 대한 대안은 테인트를 사용하는 것이다. Kubelet은 등록하는 동안 테인트를 설정할 수 있기 때문에, +윈도우에서만 운영할 때에 자동으로 테인트를 추가하기 쉽다. 예를 들면, `--register-with-taints='os=windows:NoSchedule'` -모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여). 윈도우 파드가 윈도우 노드에 스케줄링되려면, 윈도우를 선택하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다. +모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여). +윈도우 파드가 윈도우 노드에 스케줄링되려면, +윈도우를 선택하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다. ```yaml nodeSelector: @@ -152,14 +194,14 @@ tolerations: ### 동일 클러스터에서 여러 윈도우 버전을 조작하는 방법 -파드에서 사용하는 윈도우 서버 버전은 노드 버전과 일치해야 한다. 만약 동일한 클러스터에서 여러 윈도우 -서버 버전을 사용하려면, 추가로 노드 레이블과 nodeSelectors를 설정해야만 한다. +파드에서 사용하는 윈도우 서버 버전은 노드의 윈도우 서버 버전과 일치해야 한다. 만약 동일한 클러스터에서 여러 윈도우 +서버 버전을 사용하려면, 추가로 노드 레이블과 nodeSelectors를 설정해야 한다. -쿠버네티스 1.17은 이것을 단순화하기 위해 새로운 레이블인 `node.kubernetes.io/windows-build` 를 자동으로 추가 한다. 만약 이전 버전을 -실행 중인 경우 이 레이블을 윈도우 노드에 수동으로 추가하는 것을 권장한다. +쿠버네티스 1.17은 이것을 단순화하기 위해 새로운 레이블인 `node.kubernetes.io/windows-build` 를 자동으로 추가한다. +만약 이전 버전을 실행 중인 경우, 이 레이블을 윈도우 노드에 수동으로 추가하는 것을 권장한다. -이 레이블은 호환성을 일치해야 하는 윈도우 메이저, 마이너 및 빌드 번호를 나타낸다. 여기에 현재 -사용하는 각 윈도우 서버 버전이 있다. +이 레이블은 호환성을 위해 일치시켜야 하는 윈도우 메이저, 마이너 및 빌드 번호를 나타낸다. +각 윈도우 서버 버전에 대해 현재 사용하고 있는 빌드 번호는 다음과 같다. | 제품 이름 | 빌드 번호 | |--------------------------------------|------------------------| @@ -170,11 +212,12 @@ tolerations: ### RuntimeClass로 단순화 -[RuntimeClass] 를 사용해서 테인트(taint)와 톨러레이션(toleration)을 사용하는 프로세스를 간소화 할 수 있다. 클러스터 관리자는 -이 테인트와 톨러레이션을 캡슐화하는데 사용되는 `RuntimeClass` 오브젝트를 생성할 수 있다. +[런타임클래스(RuntimeClass)](/ko/docs/concepts/containers/runtime-class/)를 사용해서 테인트(taint)와 톨러레이션(toleration)을 사용하는 프로세스를 간소화 할 수 있다. +클러스터 관리자는 이 테인트와 톨러레이션을 캡슐화하는 데 사용되는 `RuntimeClass` 오브젝트를 생성할 수 있다. -1. 이 파일을 `runtimeClasses.yml` 로 저장한다. 여기에는 윈도우 OS, 아키텍처 및 버전에 적합한 `nodeSelector` 가 포함되었다. +1. 이 파일을 `runtimeClasses.yml` 로 저장한다. 여기에는 윈도우 OS, +아키텍처 및 버전에 적합한 `nodeSelector` 가 포함되어 있다. ```yaml apiVersion: node.k8s.io/v1 diff --git a/content/ko/docs/setup/release/_index.md b/content/ko/docs/setup/release/_index.md deleted file mode 100755 index fcef7a59ab..0000000000 --- a/content/ko/docs/setup/release/_index.md +++ /dev/null @@ -1,5 +0,0 @@ ---- -title: "릴리스 노트와 버전 차이 지원(skew)" -weight: 10 ---- - diff --git a/content/ko/docs/setup/release/notes.md b/content/ko/docs/setup/release/notes.md deleted file mode 100644 index 8cb17b2ec0..0000000000 --- a/content/ko/docs/setup/release/notes.md +++ /dev/null @@ -1,2141 +0,0 @@ ---- -title: v1.20 릴리스 노트 -weight: 10 -card: - name: release-notes - weight: 20 - anchors: - - anchor: "#" - title: 현재 릴리스 노트 - - anchor: "#긴급-업그레이드-노트" - title: 긴급 업그레이드 노트 ---- - - - -# v1.20.0 - -[문서](https://docs.k8s.io) - -## v1.20.0 다운로드 - -파일명 | sha512 해시 --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes.tar.gz) | `ebfe49552bbda02807034488967b3b62bf9e3e507d56245e298c4c19090387136572c1fca789e772a5e8a19535531d01dcedb61980e42ca7b0461d3864df2c14` -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-src.tar.gz) | `bcbd67ed0bb77840828c08c6118ad0c9bf2bcda16763afaafd8731fd6ce735be654feef61e554bcc34c77c65b02a25dae565adc5e1dc49a2daaa0d115bf1efe6` - -### 클라이언트 바이너리 - -파일명 | sha512 해시 --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-darwin-amd64.tar.gz) | `3609f6483f4244676162232b3294d7a2dc40ae5bdd86a842a05aa768f5223b8f50e1d6420fd8afb2d0ce19de06e1d38e5e5b10154ba0cb71a74233e6dc94d5a0` -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-linux-386.tar.gz) | `e06c08016a08137d39804383fdc33a40bb2567aa77d88a5c3fd5b9d93f5b581c635b2c4faaa718ed3bb2d120cb14fe91649ed4469ba72c3a3dda1e343db545ed` -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-linux-amd64.tar.gz) | `081472833601aa4fa78e79239f67833aa4efcb4efe714426cd01d4ddf6f36fbf304ef7e1f5373bff0fdff44a845f7560165c093c108bd359b5ab4189f36b1f2f` -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-linux-arm.tar.gz) | `037f84a2f29fe62d266cab38ac5600d058cce12cbc4851bcf062fafba796c1fbe23a0c2939cd15784854ca7cd92383e5b96a11474fc71fb614b47dbf98a477d9` -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-linux-arm64.tar.gz) | `275727e1796791ca3cbe52aaa713a2660404eab6209466fdc1cfa8559c9b361fe55c64c6bcecbdeba536b6d56213ddf726e58adc60f959b6f77e4017834c5622` -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-linux-ppc64le.tar.gz) | `7a9965293029e9fcdb2b7387467f022d2026953b8461e6c84182abf35c28b7822d2389a6d8e4d8e532d2ea5d5d67c6fee5fb6c351363cb44c599dc8800649b04` -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-linux-s390x.tar.gz) | `85fc449ce1980f5f030cc32e8c8e2198c1cc91a448e04b15d27debc3ca56aa85d283f44b4f4e5fed26ac96904cc12808fa3e9af3d8bf823fc928befb9950d6f5` -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-windows-386.tar.gz) | `4c0a27dba1077aaee943e0eb7a787239dd697e1d968e78d1933c1e60b02d5d233d58541d5beec59807a4ffe3351d5152359e11da120bf64cacb3ee29fbc242e6` -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-client-windows-amd64.tar.gz) | `29336faf7c596539b8329afbbdceeddc843162501de4afee44a40616278fa1f284d8fc48c241fc7d52c65dab70f76280cc33cec419c8c5dbc2625d9175534af8` - -### 서버 바이너리 - -파일명 | sha512 해시 --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-server-linux-amd64.tar.gz) | `fb56486a55dbf7dbacb53b1aaa690bae18d33d244c72a1e2dc95fb0fcce45108c44ba79f8fa04f12383801c46813dc33d2d0eb2203035cdce1078871595e446e` -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-server-linux-arm.tar.gz) | `735ed9993071fe35b292bf06930ee3c0f889e3c7edb983195b1c8e4d7113047c12c0f8281fe71879fc2fcd871e1ee587f03b695a03c8512c873abad444997a19` -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-server-linux-arm64.tar.gz) | `ffab155531d5a9b82487ee1abf4f6ef49626ea58b2de340656a762e46cf3e0f470bdbe7821210901fe1114224957c44c1d9cc1e32efb5ee24e51fe63990785b2` -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-server-linux-ppc64le.tar.gz) | `9d5730d35c4ddfb4c5483173629fe55df35d1e535d96f02459468220ac2c97dc01b995f577432a6e4d1548b6edbfdc90828dc9c1f7cf7464481af6ae10aaf118` -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-server-linux-s390x.tar.gz) | `6e4c165306940e8b99dd6e590f8542e31aed23d2c7a6808af0357fa425cec1a57016dd66169cf2a95f8eb8ef70e1f29e2d500533aae889e2e3d9290d04ab8721` - -### 노드 바이너리 - -파일명 | sha512 해시 --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-node-linux-amd64.tar.gz) | `3e6c90561dd1c27fa1dff6953c503251c36001f7e0f8eff3ec918c74ae2d9aa25917d8ac87d5b4224b8229f620b1830442e6dce3b2a497043f8497eee3705696` -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-node-linux-arm.tar.gz) | `26db385d9ae9a97a1051a638e7e3de22c4bbff389d5a419fe40d5893f9e4fa85c8b60a2bd1d370fd381b60c3ca33c5d72d4767c90898caa9dbd4df6bd116a247` -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-node-linux-arm64.tar.gz) | `5b8b63f617e248432b7eb913285a8ef8ba028255216332c05db949666c3f9e9cb9f4c393bbd68d00369bda77abf9bfa2da254a5c9fe0d79ffdad855a77a9d8ed` -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-node-linux-ppc64le.tar.gz) | `60da7715996b4865e390640525d6e98593ba3cd45c6caeea763aa5355a7f989926da54f58cc5f657f614c8134f97cd3894b899f8b467d100dca48bc22dd4ff63` -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-node-linux-s390x.tar.gz) | `9407dc55412bd04633f84fcefe3a1074f3eaa772a7cb9302242b8768d6189b75d37677a959f91130e8ad9dc590f9ba8408ba6700a0ceff6827315226dd5ee1e6` -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0/kubernetes-node-windows-amd64.tar.gz) | `9d4261af343cc330e6359582f80dbd6efb57d41f882747a94bbf47b4f93292d43dd19a86214d4944d268941622dfbc96847585e6fec15fddc4dbd93d17015fa8` - -## v1.19.0 이후 변경로그(Changelog) - -## 새로운 소식(주요 테마) - -### Dockershim 사용 중단(deprecation) - -Docker as an underlying runtime is being deprecated. Docker-produced images will continue to work in your cluster with all runtimes, as they always have. -The Kubernetes community [has written a blog post about this in detail](https://blog.k8s.io/2020/12/02/dont-panic-kubernetes-and-docker/) with [a dedicated FAQ page for it](https://blog.k8s.io/2020/12/02/dockershim-faq/). - -### client-go를 위한 외부 자격증명(credential) 제공자 - -The client-go credential plugins can now be passed in the current cluster information via the `KUBERNETES_EXEC_INFO` environment variable. Learn more about this on [client-go credential plugins documentation](https://docs.k8s.io/reference/access-authn-authz/authentication/#client-go-credential-plugins/). - -### 기능 게이트(feature gate)를 통해 크론잡(CronJob) 컨트롤러 v2 활성화 가능 - -An alternative implementation of `CronJob` controller is now available as an alpha feature in this release, which has experimental performance improvement by using informers instead of polling. While this will be the default behavior in the future, you can [try them in this release through a feature gate](https://docs.k8s.io/concepts/workloads/controllers/cron-jobs/). - -### PID 제한(PID Limits)이 안정 기능(General Availability)으로 전환 - -PID Limits features are now generally available on both `SupportNodePidsLimit` (node-to-pod PID isolation) and `SupportPodPidsLimit` (ability to limit PIDs per pod), after being enabled-by-default in beta stage for a year. - -### API 우선순위 및 공정성(API Priority and Fairness)이 베타 단계로 전환 - -Initially introduced in 1.18, Kubernetes 1.20 now enables API Priority and Fairness (APF) by default. This allows `kube-apiserver` to [categorize incoming requests by priority levels](https://docs.k8s.io/concepts/cluster-administration/flow-control/). - -### IPv4/IPv6이 작동 - -IPv4/IPv6 dual-stack has been reimplemented for 1.20 to support dual-stack Services, based on user and community feedback. If your cluster has dual-stack enabled, you can create Services which can use IPv4, IPv6, or both, and you can change this setting for existing Services. Details are available in updated [IPv4/IPv6 dual-stack docs](https://docs.k8s.io/concepts/services-networking/dual-stack/), which cover the nuanced array of options. - -We expect this implementation to progress from alpha to beta and GA in coming releases, so we’re eager to have you comment about your dual-stack experiences in [#k8s-dual-stack](https://kubernetes.slack.com/messages/k8s-dual-stack) or in [enhancements #563](https://features.k8s.io/563). - -### go1.15.5 - -go1.15.5 has been integrated to Kubernetes project as of this release, [including other infrastructure related updates on this effort](https://github.com/kubernetes/kubernetes/pull/95776). - -### CSI 볼륨 스냅샷(CSI Volume Snapshot)이 안정 기능으로 전환 - -CSI Volume Snapshot moves to GA in the 1.20 release. This feature provides a standard way to trigger volume snapshot operations in Kubernetes and allows Kubernetes users to incorporate snapshot operations in a portable manner on any Kubernetes environment regardless of supporting underlying storage providers. -Additionally, these Kubernetes snapshot primitives act as basic building blocks that unlock the ability to develop advanced, enterprise grade, storage administration features for Kubernetes: including application or cluster level backup solutions. -Note that snapshot support will require Kubernetes distributors to bundle the Snapshot controller, Snapshot CRDs, and validation webhook. In addition, a CSI driver supporting the snapshot functionality must also be deployed on the cluster. - -### 비재귀적 볼륨 소유(Non-recursive Volume Ownership (FSGroup))가 베타 단계로 전환 - -By default, the `fsgroup` setting, if specified, recursively updates permissions for every file in a volume on every mount. This can make mount, and pod startup, very slow if the volume has many files. -This setting enables a pod to specify a `PodFSGroupChangePolicy` that indicates that volume ownership and permissions will be changed only when permission and ownership of the root directory does not match with expected permissions on the volume. - -### FSGroup를 위한 CSIDriver 정책이 베타 단계로 전환 - -The FSGroup's CSIDriver Policy is now beta in 1.20. This allows CSIDrivers to explicitly indicate if they want Kubernetes to manage permissions and ownership for their volumes via `fsgroup`. - -### CSI 드라이버의 보안성 향상(알파) - -In 1.20, we introduce a new alpha feature `CSIServiceAccountToken`. This feature allows CSI drivers to impersonate the pods that they mount the volumes for. This improves the security posture in the mounting process where the volumes are ACL’ed on the pods’ service account without handing out unnecessary permissions to the CSI drivers’ service account. This feature is especially important for secret-handling CSI drivers, such as the secrets-store-csi-driver. Since these tokens can be rotated and short-lived, this feature also provides a knob for CSI drivers to receive `NodePublishVolume` RPC calls periodically with the new token. This knob is also useful when volumes are short-lived, e.g. certificates. - -### 그레이스풀 노드 종료(Graceful Node Shutdown) 기능 소개(알파) - -The `GracefulNodeShutdown` feature is now in Alpha. This allows kubelet to be aware of node system shutdowns, enabling graceful termination of pods during a system shutdown. This feature can be [enabled through feature gate](https://docs.k8s.io/concepts/architecture/nodes/#graceful-node-shutdown). - -### 런타임 로그 관리(sanitation) - -Logs can now be configured to use runtime protection from leaking sensitive data. [Details for this experimental feature is available in documentation](https://docs.k8s.io/concepts/cluster-administration/system-logs/#log-sanitization). - -### 파드 리소스 메트릭 - -On-demand metrics calculation is now available through `/metrics/resources`. [When enabled]( -https://docs.k8s.io/concepts/cluster-administration/system-metrics#kube-scheduler-metrics), the endpoint will report the requested resources and the desired limits of all running pods. - -### `RootCAConfigMap` 소개 - -`RootCAConfigMap` graduates to Beta, seperating from `BoundServiceAccountTokenVolume`. The `kube-root-ca.crt` ConfigMap is now available to every namespace, by default. It contains the Certificate Authority bundle for verify kube-apiserver connections. - -### `kubectl debug` 이 베타 단계로 전환 - -`kubectl alpha debug` graduates from alpha to beta in 1.20, becoming `kubectl debug`. -`kubectl debug` provides support for common debugging workflows directly from kubectl. Troubleshooting scenarios supported in this release of `kubectl` include: -Troubleshoot workloads that crash on startup by creating a copy of the pod that uses a different container image or command. -Troubleshoot distroless containers by adding a new container with debugging tools, either in a new copy of the pod or using an ephemeral container. (Ephemeral containers are an alpha feature that are not enabled by default.) -Troubleshoot on a node by creating a container running in the host namespaces and with access to the host’s filesystem. -Note that as a new builtin command, `kubectl debug` takes priority over any `kubectl` plugin named “debug”. You will need to rename the affected plugin. -Invocations using `kubectl alpha debug` are now deprecated and will be removed in a subsequent release. Update your scripts to use `kubectl debug` instead of `kubectl alpha debug`! -For more information about kubectl debug, see Debugging Running Pods on the Kubernetes website, kubectl help debug, or reach out to SIG CLI by visiting #sig-cli or commenting on [enhancement #1441](https://features.k8s.io/1441). - -### kubeadm에서 사용 중단된 플래그 삭제 - -`kubeadm` applies a number of deprecations and removals of deprecated features in this release. More details are available in the Urgent Upgrade Notes and Kind / Deprecation sections. - -### 파드의 호스트네임을 FQDN으로 사용하는 것이 베타 단계로 전환 - -Previously introduced in 1.19 behind a feature gate, `SetHostnameAsFQDN` is now enabled by default. More details on this behavior is available in [documentation for DNS for Services and Pods](https://docs.k8s.io/concepts/services-networking/dns-pod-service/#pod-sethostnameasfqdn-field) - -### `TokenRequest` / `TokenRequestProjection` 이 안정 기능으로 전환 - -Service account tokens bound to pod is now a stable feature. The feature gates will be removed in 1.21 release. For more information, refer to notes below on the changelogs. - -### 런타임클래스(RuntimeClass)가 안정 기능으로 전환 - -The `node.k8s.io` API groups are promoted from `v1beta1` to `v1`. `v1beta1` is now deprecated and will be removed in a future release, please start using `v1`. ([#95718](https://github.com/kubernetes/kubernetes/pull/95718), [@SergeyKanzhelev](https://github.com/SergeyKanzhelev)) [SIG Apps, Auth, Node, Scheduling and Testing] - -### 클라우드 컨트롤러 관리자(Cloud Controller Manager)가 이제 각 클라우드 공급자를 통해서만 제공 - -Kubernetes will no longer ship an instance of the Cloud Controller Manager binary. Each Cloud Provider is expected to ship their own instance of this binary. Details for a Cloud Provider to create an instance of such a binary can be found under [here](https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/cloud-provider/sample). Anyone with questions on building a Cloud Controller Manager should reach out to SIG Cloud Provider. Questions about the Cloud Controller Manager on a Managed Kubernetes solution should go to the relevant Cloud Provider. Questions about the Cloud Controller Manager on a non managed solution can be brought up with SIG Cloud Provider. - -## 알려진 이슈 - -### kubelet의 요약(Summary) API는 가속기(accelerator) 메트릭을 가지고 있지 않음 -Currently, cadvisor_stats_provider provides AcceleratorStats but cri_stats_provider does not. As a result, when using cri_stats_provider, kubelet's Summary API does not have accelerator metrics. [There is an open work in progress to fix this](https://github.com/kubernetes/kubernetes/pull/96873). - -## 긴급 업그레이드 노트 - -### (주의. 업그레이드 전에 반드시 읽어야 함) - -- A bug was fixed in kubelet where exec probe timeouts were not respected. This may result in unexpected behavior since the default timeout (if not specified) is `1s` which may be too small for some exec probes. Ensure that pods relying on this behavior are updated to correctly handle probe timeouts. See [configure probe](https://docs.k8s.io/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes) section of the documentation for more details. - - - This change in behavior may be unexpected for some clusters and can be disabled by turning off the `ExecProbeTimeout` feature gate. This gate will be locked and removed in future releases so that exec probe timeouts are always respected. ([#94115](https://github.com/kubernetes/kubernetes/pull/94115), [@andrewsykim](https://github.com/andrewsykim)) [SIG Node and Testing] -- RuntimeClass feature graduates to General Availability. Promote `node.k8s.io` API groups from `v1beta1` to `v1`. `v1beta1` is now deprecated and will be removed in a future release, please start using `v1`. ([#95718](https://github.com/kubernetes/kubernetes/pull/95718), [@SergeyKanzhelev](https://github.com/SergeyKanzhelev)) [SIG Apps, Auth, Node, Scheduling and Testing] -- API priority and fairness graduated to beta. 1.19 servers with APF turned on should not be run in a multi-server cluster with 1.20+ servers. ([#96527](https://github.com/kubernetes/kubernetes/pull/96527), [@adtac](https://github.com/adtac)) [SIG API Machinery and Testing] -- For CSI drivers, kubelet no longer creates the target_path for NodePublishVolume in accordance with the CSI spec. Kubelet also no longer checks if staging and target paths are mounts or corrupted. CSI drivers need to be idempotent and do any necessary mount verification. ([#88759](https://github.com/kubernetes/kubernetes/pull/88759), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage] -- Kubeadm: http://git.k8s.io/enhancements/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint/README.md ([#95382](https://github.com/kubernetes/kubernetes/pull/95382), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] - - The label applied to control-plane nodes "node-role.kubernetes.io/master" is now deprecated and will be removed in a future release after a GA deprecation period. - - Introduce a new label "node-role.kubernetes.io/control-plane" that will be applied in parallel to "node-role.kubernetes.io/master" until the removal of the "node-role.kubernetes.io/master" label. - - Make "kubeadm upgrade apply" add the "node-role.kubernetes.io/control-plane" label on existing nodes that only have the "node-role.kubernetes.io/master" label during upgrade. - - Please adapt your tooling built on top of kubeadm to use the "node-role.kubernetes.io/control-plane" label. - - The taint applied to control-plane nodes "node-role.kubernetes.io/master:NoSchedule" is now deprecated and will be removed in a future release after a GA deprecation period. - - Apply toleration for a new, future taint "node-role.kubernetes.io/control-plane:NoSchedule" to the kubeadm CoreDNS / kube-dns managed manifests. Note that this taint is not yet applied to kubeadm control-plane nodes. - - Please adapt your workloads to tolerate the same future taint preemptively. - -- Kubeadm: improve the validation of serviceSubnet and podSubnet. - ServiceSubnet has to be limited in size, due to implementation details, and the mask can not allocate more than 20 bits. - PodSubnet validates against the corresponding cluster "--node-cidr-mask-size" of the kube-controller-manager, it fail if the values are not compatible. - kubeadm no longer sets the node-mask automatically on IPv6 deployments, you must check that your IPv6 service subnet mask is compatible with the default node mask /64 or set it accordenly. - Previously, for IPv6, if the podSubnet had a mask lower than /112, kubeadm calculated a node-mask to be multiple of eight and splitting the available bits to maximise the number used for nodes. ([#95723](https://github.com/kubernetes/kubernetes/pull/95723), [@aojea](https://github.com/aojea)) [SIG Cluster Lifecycle] -- The deprecated flag --experimental-kustomize is now removed from kubeadm commands. Use --experimental-patches instead, which was introduced in 1.19. Migration information available in --help description for --experimental-patches. ([#94871](https://github.com/kubernetes/kubernetes/pull/94871), [@neolit123](https://github.com/neolit123)) -- Windows hyper-v container featuregate is deprecated in 1.20 and will be removed in 1.21 ([#95505](https://github.com/kubernetes/kubernetes/pull/95505), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] -- The kube-apiserver ability to serve on an insecure port, deprecated since v1.10, has been removed. The insecure address flags `--address` and `--insecure-bind-address` have no effect in kube-apiserver and will be removed in v1.24. The insecure port flags `--port` and `--insecure-port` may only be set to 0 and will be removed in v1.24. ([#95856](https://github.com/kubernetes/kubernetes/pull/95856), [@knight42](https://github.com/knight42), [SIG API Machinery, Node, Testing]) -- Add dual-stack Services (alpha). This is a BREAKING CHANGE to an alpha API. - It changes the dual-stack API wrt Service from a single ipFamily field to 3 - fields: ipFamilyPolicy (SingleStack, PreferDualStack, RequireDualStack), - ipFamilies (a list of families assigned), and clusterIPs (inclusive of - clusterIP). Most users do not need to set anything at all, defaulting will - handle it for them. Services are single-stack unless the user asks for - dual-stack. This is all gated by the "IPv6DualStack" feature gate. ([#91824](https://github.com/kubernetes/kubernetes/pull/91824), [@khenidak](https://github.com/khenidak)) [SIG API Machinery, Apps, CLI, Network, Node, Scheduling and Testing] -- `TokenRequest` and `TokenRequestProjection` are now GA features. The following flags are required by the API server: - - `--service-account-issuer`, should be set to a URL identifying the API server that will be stable over the cluster lifetime. - - `--service-account-key-file`, set to one or more files containing one or more public keys used to verify tokens. - - `--service-account-signing-key-file`, set to a file containing a private key to use to sign service account tokens. Can be the same file given to `kube-controller-manager` with `--service-account-private-key-file`. ([#95896](https://github.com/kubernetes/kubernetes/pull/95896), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Auth, Cluster Lifecycle] -- kubeadm: make the command "kubeadm alpha kubeconfig user" accept a "--config" flag and remove the following flags: - - apiserver-advertise-address / apiserver-bind-port: use either localAPIEndpoint from InitConfiguration or controlPlaneEndpoint from ClusterConfiguration. - - cluster-name: use clusterName from ClusterConfiguration - - cert-dir: use certificatesDir from ClusterConfiguration ([#94879](https://github.com/kubernetes/kubernetes/pull/94879), [@knight42](https://github.com/knight42)) [SIG Cluster Lifecycle] -- Resolves non-deterministic behavior of the garbage collection controller when ownerReferences with incorrect data are encountered. Events with a reason of `OwnerRefInvalidNamespace` are recorded when namespace mismatches between child and owner objects are detected. The [kubectl-check-ownerreferences](https://github.com/kubernetes-sigs/kubectl-check-ownerreferences) tool can be run prior to upgrading to locate existing objects with invalid ownerReferences. - - A namespaced object with an ownerReference referencing a uid of a namespaced kind which does not exist in the same namespace is now consistently treated as though that owner does not exist, and the child object is deleted. - - A cluster-scoped object with an ownerReference referencing a uid of a namespaced kind is now consistently treated as though that owner is not resolvable, and the child object is ignored by the garbage collector. ([#92743](https://github.com/kubernetes/kubernetes/pull/92743), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Testing] - - -## 종류(Kind)별 변경 사항 - -### 사용 중단 - -- Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. ([#94624](https://github.com/kubernetes/kubernetes/pull/94624), [@dims](https://github.com/dims)) [SIG Node] -- Kubeadm: deprecate self-hosting support. The experimental command "kubeadm alpha self-hosting" is now deprecated and will be removed in a future release. ([#95125](https://github.com/kubernetes/kubernetes/pull/95125), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: graduate the "kubeadm alpha certs" command to a parent command "kubeadm certs". The command "kubeadm alpha certs" is deprecated and will be removed in a future release. Please migrate. ([#94938](https://github.com/kubernetes/kubernetes/pull/94938), [@yagonobre](https://github.com/yagonobre)) [SIG Cluster Lifecycle] -- Kubeadm: remove the deprecated "kubeadm alpha kubelet config enable-dynamic" command. To continue using the feature please defer to the guide for "Dynamic Kubelet Configuration" at k8s.io. This change also removes the parent command "kubeadm alpha kubelet" as there are no more sub-commands under it for the time being. ([#94668](https://github.com/kubernetes/kubernetes/pull/94668), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: remove the deprecated --kubelet-config flag for the command "kubeadm upgrade node" ([#94869](https://github.com/kubernetes/kubernetes/pull/94869), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubectl: deprecate --delete-local-data ([#95076](https://github.com/kubernetes/kubernetes/pull/95076), [@dougsland](https://github.com/dougsland)) [SIG CLI, Cloud Provider and Scalability] -- Kubelet's deprecated endpoint `metrics/resource/v1alpha1` has been removed, please adopt `metrics/resource`. ([#94272](https://github.com/kubernetes/kubernetes/pull/94272), [@RainbowMango](https://github.com/RainbowMango)) [SIG Instrumentation and Node] -- Removes deprecated scheduler metrics DeprecatedSchedulingDuration, DeprecatedSchedulingAlgorithmPredicateEvaluationSecondsDuration, DeprecatedSchedulingAlgorithmPriorityEvaluationSecondsDuration ([#94884](https://github.com/kubernetes/kubernetes/pull/94884), [@arghya88](https://github.com/arghya88)) [SIG Instrumentation and Scheduling] -- Scheduler alpha metrics binding_duration_seconds and scheduling_algorithm_preemption_evaluation_seconds are deprecated, Both of those metrics are now covered as part of framework_extension_point_duration_seconds, the former as a PostFilter the latter and a Bind plugin. The plan is to remove both in 1.21 ([#95001](https://github.com/kubernetes/kubernetes/pull/95001), [@arghya88](https://github.com/arghya88)) [SIG Instrumentation and Scheduling] -- Support 'controlplane' as a valid EgressSelection type in the EgressSelectorConfiguration API. 'Master' is deprecated and will be removed in v1.22. ([#95235](https://github.com/kubernetes/kubernetes/pull/95235), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery] -- The v1alpha1 PodPreset API and admission plugin has been removed with no built-in replacement. Admission webhooks can be used to modify pods on creation. ([#94090](https://github.com/kubernetes/kubernetes/pull/94090), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Apps, CLI, Cloud Provider, Scalability and Testing] - - -### API 변경 - -- `TokenRequest` and `TokenRequestProjection` features have been promoted to GA. This feature allows generating service account tokens that are not visible in Secret objects and are tied to the lifetime of a Pod object. See https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection for details on configuring and using this feature. The `TokenRequest` and `TokenRequestProjection` feature gates will be removed in v1.21. - - kubeadm's kube-apiserver Pod manifest now includes the following flags by default "--service-account-key-file", "--service-account-signing-key-file", "--service-account-issuer". ([#93258](https://github.com/kubernetes/kubernetes/pull/93258), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Auth, Cluster Lifecycle, Storage and Testing] -- A new `nofuzz` go build tag now disables gofuzz support. Release binaries enable this. ([#92491](https://github.com/kubernetes/kubernetes/pull/92491), [@BenTheElder](https://github.com/BenTheElder)) [SIG API Machinery] -- Add WindowsContainerResources and Annotations to CRI-API UpdateContainerResourcesRequest ([#95741](https://github.com/kubernetes/kubernetes/pull/95741), [@katiewasnothere](https://github.com/katiewasnothere)) [SIG Node] -- Add a `serving` and `terminating` condition to the EndpointSlice API. - `serving` tracks the readiness of endpoints regardless of their terminating state. This is distinct from `ready` since `ready` is only true when pods are not terminating. - `terminating` is true when an endpoint is terminating. For pods this is any endpoint with a deletion timestamp. ([#92968](https://github.com/kubernetes/kubernetes/pull/92968), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network] -- Add dual-stack Services (alpha). This is a BREAKING CHANGE to an alpha API. - It changes the dual-stack API wrt Service from a single ipFamily field to 3 - fields: ipFamilyPolicy (SingleStack, PreferDualStack, RequireDualStack), - ipFamilies (a list of families assigned), and clusterIPs (inclusive of - clusterIP). Most users do not need to set anything at all, defaulting will - handle it for them. Services are single-stack unless the user asks for - dual-stack. This is all gated by the "IPv6DualStack" feature gate. ([#91824](https://github.com/kubernetes/kubernetes/pull/91824), [@khenidak](https://github.com/khenidak)) [SIG API Machinery, Apps, CLI, Network, Node, Scheduling and Testing] -- Add support for hugepages to downward API ([#86102](https://github.com/kubernetes/kubernetes/pull/86102), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG API Machinery, Apps, CLI, Network, Node, Scheduling and Testing] -- Adds kubelet alpha feature, `GracefulNodeShutdown` which makes kubelet aware of node system shutdowns and result in graceful termination of pods during a system shutdown. ([#96129](https://github.com/kubernetes/kubernetes/pull/96129), [@bobbypage](https://github.com/bobbypage)) [SIG Node] -- AppProtocol is now GA for Endpoints and Services. The ServiceAppProtocol feature gate will be deprecated in 1.21. ([#96327](https://github.com/kubernetes/kubernetes/pull/96327), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- Automatic allocation of NodePorts for services with type LoadBalancer can now be disabled by setting the (new) parameter - Service.spec.allocateLoadBalancerNodePorts=false. The default is to allocate NodePorts for services with type LoadBalancer which is the existing behavior. ([#92744](https://github.com/kubernetes/kubernetes/pull/92744), [@uablrek](https://github.com/uablrek)) [SIG Apps and Network] -- Certain fields on Service objects will be automatically cleared when changing the service's `type` to a mode that does not need those fields. For example, changing from type=LoadBalancer to type=ClusterIP will clear the NodePort assignments, rather than forcing the user to clear them. ([#95196](https://github.com/kubernetes/kubernetes/pull/95196), [@thockin](https://github.com/thockin)) [SIG API Machinery, Apps, Network and Testing] -- Document that ServiceTopology feature is required to use `service.spec.topologyKeys`. ([#96528](https://github.com/kubernetes/kubernetes/pull/96528), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps] -- EndpointSlice has a new NodeName field guarded by the EndpointSliceNodeName feature gate. - - EndpointSlice topology field will be deprecated in an upcoming release. - - EndpointSlice "IP" address type is formally removed after being deprecated in Kubernetes 1.17. - - The discovery.k8s.io/v1alpha1 API is deprecated and will be removed in Kubernetes 1.21. ([#96440](https://github.com/kubernetes/kubernetes/pull/96440), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps and Network] -- External facing API podresources is now available under k8s.io/kubelet/pkg/apis/ ([#92632](https://github.com/kubernetes/kubernetes/pull/92632), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Node and Testing] -- Fewer candidates are enumerated for preemption to improve performance in large clusters. ([#94814](https://github.com/kubernetes/kubernetes/pull/94814), [@adtac](https://github.com/adtac)) -- Fix conversions for custom metrics. ([#94481](https://github.com/kubernetes/kubernetes/pull/94481), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Instrumentation] -- GPU metrics provided by kubelet are now disabled by default. ([#95184](https://github.com/kubernetes/kubernetes/pull/95184), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) -- If BoundServiceAccountTokenVolume is enabled, cluster admins can use metric `serviceaccount_stale_tokens_total` to monitor workloads that are depending on the extended tokens. If there are no such workloads, turn off extended tokens by starting `kube-apiserver` with flag `--service-account-extend-token-expiration=false` ([#96273](https://github.com/kubernetes/kubernetes/pull/96273), [@zshihang](https://github.com/zshihang)) [SIG API Machinery and Auth] -- Introduce alpha support for exec-based container registry credential provider plugins in the kubelet. ([#94196](https://github.com/kubernetes/kubernetes/pull/94196), [@andrewsykim](https://github.com/andrewsykim)) [SIG Node and Release] -- Introduces a metric source for HPAs which allows scaling based on container resource usage. ([#90691](https://github.com/kubernetes/kubernetes/pull/90691), [@arjunrn](https://github.com/arjunrn)) [SIG API Machinery, Apps, Autoscaling and CLI] -- Kube-apiserver now deletes expired kube-apiserver Lease objects: - - The feature is under feature gate `APIServerIdentity`. - - A flag is added to kube-apiserver: `identity-lease-garbage-collection-check-period-seconds` ([#95895](https://github.com/kubernetes/kubernetes/pull/95895), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery, Apps, Auth and Testing] -- Kube-controller-manager: volume plugins can be restricted from contacting local and loopback addresses by setting `--volume-host-allow-local-loopback=false`, or from contacting specific CIDR ranges by setting `--volume-host-cidr-denylist` (for example, `--volume-host-cidr-denylist=127.0.0.1/28,feed::/16`) ([#91785](https://github.com/kubernetes/kubernetes/pull/91785), [@mattcary](https://github.com/mattcary)) [SIG API Machinery, Apps, Auth, CLI, Network, Node, Storage and Testing] -- Migrate scheduler, controller-manager and cloud-controller-manager to use LeaseLock ([#94603](https://github.com/kubernetes/kubernetes/pull/94603), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, Apps, Cloud Provider and Scheduling] -- Modify DNS-1123 error messages to indicate that RFC 1123 is not followed exactly ([#94182](https://github.com/kubernetes/kubernetes/pull/94182), [@mattfenwick](https://github.com/mattfenwick)) [SIG API Machinery, Apps, Auth, Network and Node] -- Move configurable fsgroup change policy for pods to beta ([#96376](https://github.com/kubernetes/kubernetes/pull/96376), [@gnufied](https://github.com/gnufied)) [SIG Apps and Storage] -- New flag is introduced, i.e. --topology-manager-scope=container|pod. - The default value is the "container" scope. ([#92967](https://github.com/kubernetes/kubernetes/pull/92967), [@cezaryzukowski](https://github.com/cezaryzukowski)) [SIG Instrumentation, Node and Testing] -- New parameter `defaultingType` for `PodTopologySpread` plugin allows to use k8s defined or user provided default constraints ([#95048](https://github.com/kubernetes/kubernetes/pull/95048), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- NodeAffinity plugin can be configured with AddedAffinity. ([#96202](https://github.com/kubernetes/kubernetes/pull/96202), [@alculquicondor](https://github.com/alculquicondor)) [SIG Node, Scheduling and Testing] -- Promote RuntimeClass feature to GA. - Promote node.k8s.io API groups from v1beta1 to v1. ([#95718](https://github.com/kubernetes/kubernetes/pull/95718), [@SergeyKanzhelev](https://github.com/SergeyKanzhelev)) [SIG Apps, Auth, Node, Scheduling and Testing] -- Reminder: The labels "failure-domain.beta.kubernetes.io/zone" and "failure-domain.beta.kubernetes.io/region" are deprecated in favor of "topology.kubernetes.io/zone" and "topology.kubernetes.io/region" respectively. All users of the "failure-domain.beta..." labels should switch to the "topology..." equivalents. ([#96033](https://github.com/kubernetes/kubernetes/pull/96033), [@thockin](https://github.com/thockin)) [SIG API Machinery, Apps, CLI, Cloud Provider, Network, Node, Scheduling, Storage and Testing] -- Server Side Apply now treats LabelSelector fields as atomic (meaning the entire selector is managed by a single writer and updated together), since they contain interrelated and inseparable fields that do not merge in intuitive ways. ([#93901](https://github.com/kubernetes/kubernetes/pull/93901), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Storage and Testing] -- Services will now have a `clusterIPs` field to go with `clusterIP`. `clusterIPs[0]` is a synonym for `clusterIP` and will be syncronized on create and update operations. ([#95894](https://github.com/kubernetes/kubernetes/pull/95894), [@thockin](https://github.com/thockin)) [SIG Network] -- The ServiceAccountIssuerDiscovery feature gate is now Beta and enabled by default. ([#91921](https://github.com/kubernetes/kubernetes/pull/91921), [@mtaufen](https://github.com/mtaufen)) [SIG Auth] -- The status of v1beta1 CRDs without "preserveUnknownFields:false" now shows a violation, "spec.preserveUnknownFields: Invalid value: true: must be false". ([#93078](https://github.com/kubernetes/kubernetes/pull/93078), [@vareti](https://github.com/vareti)) -- The usage of mixed protocol values in the same LoadBalancer Service is possible if the new feature gate MixedProtocolLBService is enabled. The feature gate is disabled by default. The user has to enable it for the API Server. ([#94028](https://github.com/kubernetes/kubernetes/pull/94028), [@janosi](https://github.com/janosi)) [SIG API Machinery and Apps] -- This PR will introduce a feature gate CSIServiceAccountToken with two additional fields in `CSIDriverSpec`. ([#93130](https://github.com/kubernetes/kubernetes/pull/93130), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Apps, Auth, CLI, Network, Node, Storage and Testing] -- Users can try the cronjob controller v2 using the feature gate. This will be the default controller in future releases. ([#93370](https://github.com/kubernetes/kubernetes/pull/93370), [@alaypatel07](https://github.com/alaypatel07)) [SIG API Machinery, Apps, Auth and Testing] -- VolumeSnapshotDataSource moves to GA in 1.20 release ([#95282](https://github.com/kubernetes/kubernetes/pull/95282), [@xing-yang](https://github.com/xing-yang)) [SIG Apps] -- WinOverlay feature graduated to beta ([#94807](https://github.com/kubernetes/kubernetes/pull/94807), [@ksubrmnn](https://github.com/ksubrmnn)) [SIG Windows] - -### 기능(feature) - -- **Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.**: -- A new metric `apiserver_request_filter_duration_seconds` has been introduced that - measures request filter latency in seconds. ([#95207](https://github.com/kubernetes/kubernetes/pull/95207), [@tkashem](https://github.com/tkashem)) [SIG API Machinery and Instrumentation] -- A new set of alpha metrics are reported by the Kubernetes scheduler under the `/metrics/resources` endpoint that allow administrators to easily see the resource consumption (requests and limits for all resources on the pods) and compare it to actual pod usage or node capacity. ([#94866](https://github.com/kubernetes/kubernetes/pull/94866), [@smarterclayton](https://github.com/smarterclayton)) [SIG API Machinery, Instrumentation, Node and Scheduling] -- Add --experimental-logging-sanitization flag enabling runtime protection from leaking sensitive data in logs ([#96370](https://github.com/kubernetes/kubernetes/pull/96370), [@serathius](https://github.com/serathius)) [SIG API Machinery, Cluster Lifecycle and Instrumentation] -- Add a StorageVersionAPI feature gate that makes API server update storageversions before serving certain write requests. - This feature allows the storage migrator to manage storage migration for built-in resources. - Enabling internal.apiserver.k8s.io/v1alpha1 API and APIServerIdentity feature gate are required to use this feature. ([#93873](https://github.com/kubernetes/kubernetes/pull/93873), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery, Auth and Testing] -- Add a metric for time taken to perform recursive permission change ([#95866](https://github.com/kubernetes/kubernetes/pull/95866), [@JornShen](https://github.com/JornShen)) [SIG Instrumentation and Storage] -- Add a new `vSphere` metric: `cloudprovider_vsphere_vcenter_versions`. It's content show `vCenter` hostnames with the associated server version. ([#94526](https://github.com/kubernetes/kubernetes/pull/94526), [@Danil-Grigorev](https://github.com/Danil-Grigorev)) [SIG Cloud Provider and Instrumentation] -- Add a new flag to set priority for the kubelet on Windows nodes so that workloads cannot overwhelm the node there by disrupting kubelet process. ([#96051](https://github.com/kubernetes/kubernetes/pull/96051), [@ravisantoshgudimetla](https://github.com/ravisantoshgudimetla)) [SIG Node and Windows] -- Add feature to size memory backed volumes ([#94444](https://github.com/kubernetes/kubernetes/pull/94444), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG Storage and Testing] -- Add foreground cascading deletion to kubectl with the new `kubectl delete foreground|background|orphan` option. ([#93384](https://github.com/kubernetes/kubernetes/pull/93384), [@zhouya0](https://github.com/zhouya0)) -- Add metrics for azure service operations (route and loadbalancer). ([#94124](https://github.com/kubernetes/kubernetes/pull/94124), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider and Instrumentation] -- Add network rule support in Azure account creation. ([#94239](https://github.com/kubernetes/kubernetes/pull/94239), [@andyzhangx](https://github.com/andyzhangx)) -- Add node_authorizer_actions_duration_seconds metric that can be used to estimate load to node authorizer. ([#92466](https://github.com/kubernetes/kubernetes/pull/92466), [@mborsz](https://github.com/mborsz)) [SIG API Machinery, Auth and Instrumentation] -- Add pod_ based CPU and memory metrics to Kubelet's /metrics/resource endpoint ([#95839](https://github.com/kubernetes/kubernetes/pull/95839), [@egernst](https://github.com/egernst)) [SIG Instrumentation, Node and Testing] -- Added `get-users` and `delete-user` to the `kubectl config` subcommand ([#89840](https://github.com/kubernetes/kubernetes/pull/89840), [@eddiezane](https://github.com/eddiezane)) [SIG CLI] -- Added counter metric "apiserver_request_self" to count API server self-requests with labels for verb, resource, and subresource. ([#94288](https://github.com/kubernetes/kubernetes/pull/94288), [@LogicalShark](https://github.com/LogicalShark)) [SIG API Machinery, Auth, Instrumentation and Scheduling] -- Added new k8s.io/component-helpers repository providing shared helper code for (core) components. ([#92507](https://github.com/kubernetes/kubernetes/pull/92507), [@ingvagabund](https://github.com/ingvagabund)) [SIG Apps, Node, Release and Scheduling] -- Adds `create ingress` command to `kubectl` ([#78153](https://github.com/kubernetes/kubernetes/pull/78153), [@amimof](https://github.com/amimof)) [SIG CLI and Network] -- Adds a headless service on node-local-cache addon. ([#88412](https://github.com/kubernetes/kubernetes/pull/88412), [@stafot](https://github.com/stafot)) [SIG Cloud Provider and Network] -- Allow cross compilation of kubernetes on different platforms. ([#94403](https://github.com/kubernetes/kubernetes/pull/94403), [@bnrjee](https://github.com/bnrjee)) [SIG Release] -- Azure: Support multiple services sharing one IP address ([#94991](https://github.com/kubernetes/kubernetes/pull/94991), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- CRDs: For structural schemas, non-nullable null map fields will now be dropped and defaulted if a default is available. null items in list will continue being preserved, and fail validation if not nullable. ([#95423](https://github.com/kubernetes/kubernetes/pull/95423), [@apelisse](https://github.com/apelisse)) [SIG API Machinery] -- Changed: default "Accept: */*" header added to HTTP probes. See https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#http-probes (https://github.com/kubernetes/website/pull/24756) ([#95641](https://github.com/kubernetes/kubernetes/pull/95641), [@fonsecas72](https://github.com/fonsecas72)) [SIG Network and Node] -- Client-go credential plugins can now be passed in the current cluster information via the KUBERNETES_EXEC_INFO environment variable. ([#95489](https://github.com/kubernetes/kubernetes/pull/95489), [@ankeesler](https://github.com/ankeesler)) [SIG API Machinery and Auth] -- Command to start network proxy changes from 'KUBE_ENABLE_EGRESS_VIA_KONNECTIVITY_SERVICE ./cluster/kube-up.sh' to 'KUBE_ENABLE_KONNECTIVITY_SERVICE=true ./hack/kube-up.sh' ([#92669](https://github.com/kubernetes/kubernetes/pull/92669), [@Jefftree](https://github.com/Jefftree)) [SIG Cloud Provider] -- Configure AWS LoadBalancer health check protocol via service annotations. ([#94546](https://github.com/kubernetes/kubernetes/pull/94546), [@kishorj](https://github.com/kishorj)) -- DefaultPodTopologySpread graduated to Beta. The feature gate is enabled by default. ([#95631](https://github.com/kubernetes/kubernetes/pull/95631), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling and Testing] -- E2e test for PodFsGroupChangePolicy ([#96247](https://github.com/kubernetes/kubernetes/pull/96247), [@saikat-royc](https://github.com/saikat-royc)) [SIG Storage and Testing] -- Ephemeral containers now apply the same API defaults as initContainers and containers ([#94896](https://github.com/kubernetes/kubernetes/pull/94896), [@wawa0210](https://github.com/wawa0210)) [SIG Apps and CLI] -- Gradudate the Pod Resources API to G.A - Introduces the pod_resources_endpoint_requests_total metric which tracks the total number of requests to the pod resources API ([#92165](https://github.com/kubernetes/kubernetes/pull/92165), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Instrumentation, Node and Testing] -- In dual-stack bare-metal clusters, you can now pass dual-stack IPs to `kubelet --node-ip`. - eg: `kubelet --node-ip 10.1.0.5,fd01::0005`. This is not yet supported for non-bare-metal - clusters. - - In dual-stack clusters where nodes have dual-stack addresses, hostNetwork pods - will now get dual-stack PodIPs. ([#95239](https://github.com/kubernetes/kubernetes/pull/95239), [@danwinship](https://github.com/danwinship)) [SIG Network and Node] -- Introduce api-extensions category which will return: mutating admission configs, validating admission configs, CRDs and APIServices when used in kubectl get, for example. ([#95603](https://github.com/kubernetes/kubernetes/pull/95603), [@soltysh](https://github.com/soltysh)) [SIG API Machinery] -- Introduces a new GCE specific cluster creation variable KUBE_PROXY_DISABLE. When set to true, this will skip over the creation of kube-proxy (whether the daemonset or static pod). This can be used to control the lifecycle of kube-proxy separately from the lifecycle of the nodes. ([#91977](https://github.com/kubernetes/kubernetes/pull/91977), [@varunmar](https://github.com/varunmar)) [SIG Cloud Provider] -- Kube-apiserver now maintains a Lease object to identify itself: - - The feature is under feature gate `APIServerIdentity`. - - Two flags are added to kube-apiserver: `identity-lease-duration-seconds`, `identity-lease-renew-interval-seconds` ([#95533](https://github.com/kubernetes/kubernetes/pull/95533), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery] -- Kube-apiserver: The timeout used when making health check calls to etcd can now be configured with `--etcd-healthcheck-timeout`. The default timeout is 2 seconds, matching the previous behavior. ([#93244](https://github.com/kubernetes/kubernetes/pull/93244), [@Sh4d1](https://github.com/Sh4d1)) [SIG API Machinery] -- Kube-apiserver: added support for compressing rotated audit log files with `--audit-log-compress` ([#94066](https://github.com/kubernetes/kubernetes/pull/94066), [@lojies](https://github.com/lojies)) [SIG API Machinery and Auth] -- Kubeadm now prints warnings instead of throwing errors if the current system time is outside of the NotBefore and NotAfter bounds of a loaded certificate. ([#94504](https://github.com/kubernetes/kubernetes/pull/94504), [@neolit123](https://github.com/neolit123)) -- Kubeadm: Add a preflight check that the control-plane node has at least 1700MB of RAM ([#93275](https://github.com/kubernetes/kubernetes/pull/93275), [@xlgao-zju](https://github.com/xlgao-zju)) [SIG Cluster Lifecycle] -- Kubeadm: add the "--cluster-name" flag to the "kubeadm alpha kubeconfig user" to allow configuring the cluster name in the generated kubeconfig file ([#93992](https://github.com/kubernetes/kubernetes/pull/93992), [@prabhu43](https://github.com/prabhu43)) [SIG Cluster Lifecycle] -- Kubeadm: add the "--kubeconfig" flag to the "kubeadm init phase upload-certs" command to allow users to pass a custom location for a kubeconfig file. ([#94765](https://github.com/kubernetes/kubernetes/pull/94765), [@zhanw15](https://github.com/zhanw15)) [SIG Cluster Lifecycle] -- Kubeadm: make etcd pod request 100m CPU, 100Mi memory and 100Mi ephemeral_storage by default ([#94479](https://github.com/kubernetes/kubernetes/pull/94479), [@knight42](https://github.com/knight42)) [SIG Cluster Lifecycle] -- Kubeadm: make the command "kubeadm alpha kubeconfig user" accept a "--config" flag and remove the following flags: - - apiserver-advertise-address / apiserver-bind-port: use either localAPIEndpoint from InitConfiguration or controlPlaneEndpoint from ClusterConfiguration. - - cluster-name: use clusterName from ClusterConfiguration - - cert-dir: use certificatesDir from ClusterConfiguration ([#94879](https://github.com/kubernetes/kubernetes/pull/94879), [@knight42](https://github.com/knight42)) [SIG Cluster Lifecycle] -- Kubectl create now supports creating ingress objects. ([#94327](https://github.com/kubernetes/kubernetes/pull/94327), [@rikatz](https://github.com/rikatz)) [SIG CLI and Network] -- Kubectl rollout history sts/sts-name --revision=some-revision will start showing the detailed view of the sts on that specified revision ([#86506](https://github.com/kubernetes/kubernetes/pull/86506), [@dineshba](https://github.com/dineshba)) [SIG CLI] -- Kubectl: Previously users cannot provide arguments to a external diff tool via KUBECTL_EXTERNAL_DIFF env. This release now allow users to specify args to KUBECTL_EXTERNAL_DIFF env. ([#95292](https://github.com/kubernetes/kubernetes/pull/95292), [@dougsland](https://github.com/dougsland)) [SIG CLI] -- Kubemark now supports both real and hollow nodes in a single cluster. ([#93201](https://github.com/kubernetes/kubernetes/pull/93201), [@ellistarn](https://github.com/ellistarn)) [SIG Scalability] -- Kubernetes E2E test image manifest lists now contain Windows images. ([#77398](https://github.com/kubernetes/kubernetes/pull/77398), [@claudiubelu](https://github.com/claudiubelu)) [SIG Testing and Windows] -- Kubernetes is now built using go1.15.2 - - build: Update to k/repo-infra@v0.1.1 (supports go1.15.2) - - build: Use go-runner:buster-v2.0.1 (built using go1.15.1) - - bazel: Replace --features with Starlark build settings flag - - hack/lib/util.sh: some bash cleanups - - - switched one spot to use kube::logging - - make kube::util::find-binary return an error when it doesn't find - anything so that hack scripts fail fast instead of with '' binary not - found errors. - - this required deleting some genfeddoc stuff. the binary no longer - exists in k/k repo since we removed federation/, and I don't see it - in https://github.com/kubernetes-sigs/kubefed/ either. I'm assuming - that it's gone for good now. - - - bazel: output go_binary rule directly from go_binary_conditional_pure - - From: [@mikedanese](https://github.com/mikedanese): - Instead of aliasing. Aliases are annoying in a number of ways. This is - specifically bugging me now because they make the action graph harder to - analyze programmatically. By using aliases here, we would need to handle - potentially aliased go_binary targets and dereference to the effective - target. - - The comment references an issue with `pure = select(...)` which appears - to be resolved considering this now builds. - - - make kube::util::find-binary not dependent on bazel-out/ structure - - Implement an aspect that outputs go_build_mode metadata for go binaries, - and use that during binary selection. ([#94449](https://github.com/kubernetes/kubernetes/pull/94449), [@justaugustus](https://github.com/justaugustus)) [SIG Architecture, CLI, Cluster Lifecycle, Node, Release and Testing] -- Kubernetes is now built using go1.15.5 - - build: Update to k/repo-infra@v0.1.2 (supports go1.15.5) ([#95776](https://github.com/kubernetes/kubernetes/pull/95776), [@justaugustus](https://github.com/justaugustus)) [SIG Cloud Provider, Instrumentation, Release and Testing] -- New default scheduling plugins order reduces scheduling and preemption latency when taints and node affinity are used ([#95539](https://github.com/kubernetes/kubernetes/pull/95539), [@soulxu](https://github.com/soulxu)) [SIG Scheduling] -- Only update Azure data disks when attach/detach ([#94265](https://github.com/kubernetes/kubernetes/pull/94265), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Promote SupportNodePidsLimit to GA to provide node-to-pod PID isolation. - Promote SupportPodPidsLimit to GA to provide ability to limit PIDs per pod. ([#94140](https://github.com/kubernetes/kubernetes/pull/94140), [@derekwaynecarr](https://github.com/derekwaynecarr)) -- SCTP support in API objects (Pod, Service, NetworkPolicy) is now GA. - Note that this has no effect on whether SCTP is enabled on nodes at the kernel level, - and note that some cloud platforms and network plugins do not support SCTP traffic. ([#95566](https://github.com/kubernetes/kubernetes/pull/95566), [@danwinship](https://github.com/danwinship)) [SIG Apps and Network] -- Scheduler now ignores Pod update events if the resourceVersion of old and new Pods are identical. ([#96071](https://github.com/kubernetes/kubernetes/pull/96071), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling] -- Scheduling Framework: expose Run[Pre]ScorePlugins functions to PreemptionHandle which can be used in PostFilter extention point. ([#93534](https://github.com/kubernetes/kubernetes/pull/93534), [@everpeace](https://github.com/everpeace)) [SIG Scheduling and Testing] -- SelectorSpreadPriority maps to PodTopologySpread plugin when DefaultPodTopologySpread feature is enabled ([#95448](https://github.com/kubernetes/kubernetes/pull/95448), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- Send GCE node startup scripts logs to console and journal. ([#95311](https://github.com/kubernetes/kubernetes/pull/95311), [@karan](https://github.com/karan)) -- SetHostnameAsFQDN has been graduated to Beta and therefore it is enabled by default. ([#95267](https://github.com/kubernetes/kubernetes/pull/95267), [@javidiaz](https://github.com/javidiaz)) [SIG Node] -- Support [service.beta.kubernetes.io/azure-pip-ip-tags] annotations to allow customers to specify ip-tags to influence public-ip creation in Azure [Tag1=Value1, Tag2=Value2, etc.] ([#94114](https://github.com/kubernetes/kubernetes/pull/94114), [@MarcPow](https://github.com/MarcPow)) [SIG Cloud Provider] -- Support custom tags for cloud provider managed resources ([#96450](https://github.com/kubernetes/kubernetes/pull/96450), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Support customize load balancer health probe protocol and request path ([#96338](https://github.com/kubernetes/kubernetes/pull/96338), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Support for Windows container images (OS Versions: 1809, 1903, 1909, 2004) was added the pause:3.4 image. ([#91452](https://github.com/kubernetes/kubernetes/pull/91452), [@claudiubelu](https://github.com/claudiubelu)) [SIG Node, Release and Windows] -- Support multiple standard load balancers in one cluster ([#96111](https://github.com/kubernetes/kubernetes/pull/96111), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- The beta `RootCAConfigMap` feature gate is enabled by default and causes kube-controller-manager to publish a "kube-root-ca.crt" ConfigMap to every namespace. This ConfigMap contains a CA bundle used for verifying connections to the kube-apiserver. ([#96197](https://github.com/kubernetes/kubernetes/pull/96197), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Apps, Auth and Testing] -- The kubelet_runtime_operations_duration_seconds metric buckets were set to 0.005 0.0125 0.03125 0.078125 0.1953125 0.48828125 1.220703125 3.0517578125 7.62939453125 19.073486328125 47.6837158203125 119.20928955078125 298.0232238769531 and 745.0580596923828 seconds ([#96054](https://github.com/kubernetes/kubernetes/pull/96054), [@alvaroaleman](https://github.com/alvaroaleman)) [SIG Instrumentation and Node] -- There is a new pv_collector_total_pv_count metric that counts persistent volumes by the volume plugin name and volume mode. ([#95719](https://github.com/kubernetes/kubernetes/pull/95719), [@tsmetana](https://github.com/tsmetana)) [SIG Apps, Instrumentation, Storage and Testing] -- Volume snapshot e2e test to validate PVC and VolumeSnapshotContent finalizer ([#95863](https://github.com/kubernetes/kubernetes/pull/95863), [@RaunakShah](https://github.com/RaunakShah)) [SIG Cloud Provider, Storage and Testing] -- Warns user when executing kubectl apply/diff to resource currently being deleted. ([#95544](https://github.com/kubernetes/kubernetes/pull/95544), [@SaiHarshaK](https://github.com/SaiHarshaK)) [SIG CLI] -- `kubectl alpha debug` has graduated to beta and is now `kubectl debug`. ([#96138](https://github.com/kubernetes/kubernetes/pull/96138), [@verb](https://github.com/verb)) [SIG CLI and Testing] -- `kubectl debug` gains support for changing container images when copying a pod for debugging, similar to how `kubectl set image` works. See `kubectl help debug` for more information. ([#96058](https://github.com/kubernetes/kubernetes/pull/96058), [@verb](https://github.com/verb)) [SIG CLI] - -### 문서 - -- Fake dynamic client: document that List does not preserve TypeMeta in UnstructuredList ([#95117](https://github.com/kubernetes/kubernetes/pull/95117), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery] -- Kubelet: remove alpha warnings for CNI flags. ([#94508](https://github.com/kubernetes/kubernetes/pull/94508), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network and Node] -- Updates docs and guidance on cloud provider InstancesV2 and Zones interface for external cloud providers: - - removes experimental warning for InstancesV2 - - document that implementation of InstancesV2 will disable calls to Zones - - deprecate Zones in favor of InstancesV2 ([#96397](https://github.com/kubernetes/kubernetes/pull/96397), [@andrewsykim](https://github.com/andrewsykim)) [SIG Cloud Provider] - -### 실패 테스트 - -- Resolves an issue running Ingress conformance tests on clusters which use finalizers on Ingress objects to manage releasing load balancer resources ([#96742](https://github.com/kubernetes/kubernetes/pull/96742), [@spencerhance](https://github.com/spencerhance)) [SIG Network and Testing] -- The Conformance test "validates that there is no conflict between pods with same hostPort but different hostIP and protocol" now validates the connectivity to each hostPort, in addition to the functionality. ([#96627](https://github.com/kubernetes/kubernetes/pull/96627), [@aojea](https://github.com/aojea)) [SIG Scheduling and Testing] - -### 버그 또는 회귀(regression) - -- Add kubectl wait --ignore-not-found flag ([#90969](https://github.com/kubernetes/kubernetes/pull/90969), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] -- Added support to kube-proxy for externalTrafficPolicy=Local setting via Direct Server Return (DSR) load balancers on Windows. ([#93166](https://github.com/kubernetes/kubernetes/pull/93166), [@elweb9858](https://github.com/elweb9858)) [SIG Network] -- Alter wording to describe pods using a pvc ([#95635](https://github.com/kubernetes/kubernetes/pull/95635), [@RaunakShah](https://github.com/RaunakShah)) [SIG CLI] -- An issues preventing volume expand controller to annotate the PVC with `volume.kubernetes.io/storage-resizer` when the PVC StorageClass is already updated to the out-of-tree provisioner is now fixed. ([#94489](https://github.com/kubernetes/kubernetes/pull/94489), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG API Machinery, Apps and Storage] -- Azure ARM client: don't segfault on empty response and http error ([#94078](https://github.com/kubernetes/kubernetes/pull/94078), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider] -- Azure armclient backoff step defaults to 1 (no retry). ([#94180](https://github.com/kubernetes/kubernetes/pull/94180), [@feiskyer](https://github.com/feiskyer)) -- Azure: fix a bug that kube-controller-manager would panic if wrong Azure VMSS name is configured ([#94306](https://github.com/kubernetes/kubernetes/pull/94306), [@knight42](https://github.com/knight42)) [SIG Cloud Provider] -- Both apiserver_request_duration_seconds metrics and RequestReceivedTimestamp fields of an audit event now take into account the time a request spends in the apiserver request filters. ([#94903](https://github.com/kubernetes/kubernetes/pull/94903), [@tkashem](https://github.com/tkashem)) -- Build/lib/release: Explicitly use '--platform' in building server images - - When we switched to go-runner for building the apiserver, - controller-manager, and scheduler server components, we no longer - reference the individual architectures in the image names, specifically - in the 'FROM' directive of the server image Dockerfiles. - - As a result, server images for non-amd64 images copy in the go-runner - amd64 binary instead of the go-runner that matches that architecture. - - This commit explicitly sets the '--platform=linux/${arch}' to ensure - we're pulling the correct go-runner arch from the manifest list. - - Before: - `FROM ${base_image}` - - After: - `FROM --platform=linux/${arch} ${base_image}` ([#94552](https://github.com/kubernetes/kubernetes/pull/94552), [@justaugustus](https://github.com/justaugustus)) [SIG Release] -- Bump node-problem-detector version to v0.8.5 to fix OOM detection in with Linux kernels 5.1+ ([#96716](https://github.com/kubernetes/kubernetes/pull/96716), [@tosi3k](https://github.com/tosi3k)) [SIG Cloud Provider, Scalability and Testing] -- CSIDriver object can be deployed during volume attachment. ([#93710](https://github.com/kubernetes/kubernetes/pull/93710), [@Jiawei0227](https://github.com/Jiawei0227)) [SIG Apps, Node, Storage and Testing] -- Ceph RBD volume expansion now works even when ceph.conf was not provided. ([#92027](https://github.com/kubernetes/kubernetes/pull/92027), [@juliantaylor](https://github.com/juliantaylor)) -- Change plugin name in fsgroupapplymetrics of csi and flexvolume to distinguish different driver ([#95892](https://github.com/kubernetes/kubernetes/pull/95892), [@JornShen](https://github.com/JornShen)) [SIG Instrumentation, Storage and Testing] -- Change the calculation of pod UIDs so that static pods get a unique value - will cause all containers to be killed and recreated after in-place upgrade. ([#87461](https://github.com/kubernetes/kubernetes/pull/87461), [@bboreham](https://github.com/bboreham)) [SIG Node] -- Change the mount way from systemd to normal mount except ceph and glusterfs intree-volume. ([#94916](https://github.com/kubernetes/kubernetes/pull/94916), [@smileusd](https://github.com/smileusd)) [SIG Apps, Cloud Provider, Network, Node, Storage and Testing] -- Changes to timeout parameter handling in 1.20.0-beta.2 have been reverted to avoid breaking backwards compatibility with existing clients. ([#96727](https://github.com/kubernetes/kubernetes/pull/96727), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Testing] -- Clear UDP conntrack entry on endpoint changes when using nodeport ([#71573](https://github.com/kubernetes/kubernetes/pull/71573), [@JacobTanenbaum](https://github.com/JacobTanenbaum)) [SIG Network] -- Cloud node controller: handle empty providerID from getProviderID ([#95342](https://github.com/kubernetes/kubernetes/pull/95342), [@nicolehanjing](https://github.com/nicolehanjing)) [SIG Cloud Provider] -- Disable watchcache for events ([#96052](https://github.com/kubernetes/kubernetes/pull/96052), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery] -- Disabled `LocalStorageCapacityIsolation` feature gate is honored during scheduling. ([#96092](https://github.com/kubernetes/kubernetes/pull/96092), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling] -- Do not fail sorting empty elements. ([#94666](https://github.com/kubernetes/kubernetes/pull/94666), [@soltysh](https://github.com/soltysh)) [SIG CLI] -- Dual-stack: make nodeipam compatible with existing single-stack clusters when dual-stack feature gate become enabled by default ([#90439](https://github.com/kubernetes/kubernetes/pull/90439), [@SataQiu](https://github.com/SataQiu)) [SIG API Machinery] -- Duplicate owner reference entries in create/update/patch requests now get deduplicated by the API server. The client sending the request now receives a warning header in the API response. Clients should stop sending requests with duplicate owner references. The API server may reject such requests as early as 1.24. ([#96185](https://github.com/kubernetes/kubernetes/pull/96185), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery and Testing] -- Endpoint slice controller now mirrors parent's service label to its corresponding endpoint slices. ([#94443](https://github.com/kubernetes/kubernetes/pull/94443), [@aojea](https://github.com/aojea)) -- Ensure getPrimaryInterfaceID not panic when network interfaces for Azure VMSS are null ([#94355](https://github.com/kubernetes/kubernetes/pull/94355), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Exposes and sets a default timeout for the SubjectAccessReview client for DelegatingAuthorizationOptions ([#95725](https://github.com/kubernetes/kubernetes/pull/95725), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery and Cloud Provider] -- Exposes and sets a default timeout for the TokenReview client for DelegatingAuthenticationOptions ([#96217](https://github.com/kubernetes/kubernetes/pull/96217), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery and Cloud Provider] -- Fix CVE-2020-8555 for Quobyte client connections. ([#95206](https://github.com/kubernetes/kubernetes/pull/95206), [@misterikkit](https://github.com/misterikkit)) [SIG Storage] -- Fix IP fragmentation of UDP and TCP packets not supported issues on LoadBalancer rules ([#96464](https://github.com/kubernetes/kubernetes/pull/96464), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Fix a bug that DefaultPreemption plugin is disabled when using (legacy) scheduler policy. ([#96439](https://github.com/kubernetes/kubernetes/pull/96439), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing] -- Fix a bug where loadbalancer deletion gets stuck because of missing resource group. ([#93962](https://github.com/kubernetes/kubernetes/pull/93962), [@phiphi282](https://github.com/phiphi282)) -- Fix a concurrent map writes error in kubelet ([#93773](https://github.com/kubernetes/kubernetes/pull/93773), [@knight42](https://github.com/knight42)) [SIG Node] -- Fix a panic in `kubectl debug` when a pod has multiple init or ephemeral containers. ([#94580](https://github.com/kubernetes/kubernetes/pull/94580), [@kiyoshim55](https://github.com/kiyoshim55)) -- Fix a regression where kubeadm bails out with a fatal error when an optional version command line argument is supplied to the "kubeadm upgrade plan" command ([#94421](https://github.com/kubernetes/kubernetes/pull/94421), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle] -- Fix azure disk attach failure for disk size bigger than 4TB ([#95463](https://github.com/kubernetes/kubernetes/pull/95463), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix azure disk data loss issue on Windows when unmount disk ([#95456](https://github.com/kubernetes/kubernetes/pull/95456), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fix azure file migration panic ([#94853](https://github.com/kubernetes/kubernetes/pull/94853), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix bug in JSON path parser where an error occurs when a range is empty ([#95933](https://github.com/kubernetes/kubernetes/pull/95933), [@brianpursley](https://github.com/brianpursley)) [SIG API Machinery] -- Fix client-go prometheus metrics to correctly present the API path accessed in some environments. ([#74363](https://github.com/kubernetes/kubernetes/pull/74363), [@aanm](https://github.com/aanm)) [SIG API Machinery] -- Fix detach azure disk issue when vm not exist ([#95177](https://github.com/kubernetes/kubernetes/pull/95177), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix etcd_object_counts metric reported by kube-apiserver ([#94773](https://github.com/kubernetes/kubernetes/pull/94773), [@tkashem](https://github.com/tkashem)) [SIG API Machinery] -- Fix incorrectly reported verbs for kube-apiserver metrics for CRD objects ([#93523](https://github.com/kubernetes/kubernetes/pull/93523), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Instrumentation] -- Fix k8s.io/apimachinery/pkg/api/meta.SetStatusCondition to update ObservedGeneration ([#95961](https://github.com/kubernetes/kubernetes/pull/95961), [@KnicKnic](https://github.com/KnicKnic)) [SIG API Machinery] -- Fix kubectl SchemaError on CRDs with schema using x-kubernetes-preserve-unknown-fields on array types. ([#94888](https://github.com/kubernetes/kubernetes/pull/94888), [@sttts](https://github.com/sttts)) [SIG API Machinery] -- Fix memory leak in kube-apiserver when underlying time goes forth and back. ([#96266](https://github.com/kubernetes/kubernetes/pull/96266), [@chenyw1990](https://github.com/chenyw1990)) [SIG API Machinery] -- Fix missing csi annotations on node during parallel csinode update. ([#94389](https://github.com/kubernetes/kubernetes/pull/94389), [@pacoxu](https://github.com/pacoxu)) [SIG Storage] -- Fix network_programming_latency metric reporting for Endpoints/EndpointSlice deletions, where we don't have correct timestamp ([#95363](https://github.com/kubernetes/kubernetes/pull/95363), [@wojtek-t](https://github.com/wojtek-t)) [SIG Network and Scalability] -- Fix paging issues when Azure API returns empty values with non-empty nextLink ([#96211](https://github.com/kubernetes/kubernetes/pull/96211), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Fix pull image error from multiple ACRs using azure managed identity ([#96355](https://github.com/kubernetes/kubernetes/pull/96355), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix race condition on timeCache locks. ([#94751](https://github.com/kubernetes/kubernetes/pull/94751), [@auxten](https://github.com/auxten)) -- Fix regression on `kubectl portforward` when TCP and UCP services were configured on the same port. ([#94728](https://github.com/kubernetes/kubernetes/pull/94728), [@amorenoz](https://github.com/amorenoz)) -- Fix scheduler cache snapshot when a Node is deleted before its Pods ([#95130](https://github.com/kubernetes/kubernetes/pull/95130), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- Fix the `cloudprovider_azure_api_request_duration_seconds` metric buckets to correctly capture the latency metrics. Previously, the majority of the calls would fall in the "+Inf" bucket. ([#94873](https://github.com/kubernetes/kubernetes/pull/94873), [@marwanad](https://github.com/marwanad)) [SIG Cloud Provider and Instrumentation] -- Fix vSphere volumes that could be erroneously attached to wrong node ([#96224](https://github.com/kubernetes/kubernetes/pull/96224), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage] -- Fix verb & scope reporting for kube-apiserver metrics (LIST reported instead of GET) ([#95562](https://github.com/kubernetes/kubernetes/pull/95562), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Testing] -- Fix vsphere detach failure for static PVs ([#95447](https://github.com/kubernetes/kubernetes/pull/95447), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage] -- Fix: azure disk resize error if source does not exist ([#93011](https://github.com/kubernetes/kubernetes/pull/93011), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix: detach azure disk broken on Azure Stack ([#94885](https://github.com/kubernetes/kubernetes/pull/94885), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix: resize Azure disk issue when it's in attached state ([#96705](https://github.com/kubernetes/kubernetes/pull/96705), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix: smb valid path error ([#95583](https://github.com/kubernetes/kubernetes/pull/95583), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage] -- Fix: use sensitiveOptions on Windows mount ([#94126](https://github.com/kubernetes/kubernetes/pull/94126), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fixed a bug causing incorrect formatting of `kubectl describe ingress`. ([#94985](https://github.com/kubernetes/kubernetes/pull/94985), [@howardjohn](https://github.com/howardjohn)) [SIG CLI and Network] -- Fixed a bug in client-go where new clients with customized `Dial`, `Proxy`, `GetCert` config may get stale HTTP transports. ([#95427](https://github.com/kubernetes/kubernetes/pull/95427), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery] -- Fixed a bug that prevents kubectl to validate CRDs with schema using x-kubernetes-preserve-unknown-fields on object fields. ([#96369](https://github.com/kubernetes/kubernetes/pull/96369), [@gautierdelorme](https://github.com/gautierdelorme)) [SIG API Machinery and Testing] -- Fixed a bug that prevents the use of ephemeral containers in the presence of a validating admission webhook. ([#94685](https://github.com/kubernetes/kubernetes/pull/94685), [@verb](https://github.com/verb)) [SIG Node and Testing] -- Fixed a bug where aggregator_unavailable_apiservice metrics were reported for deleted apiservices. ([#96421](https://github.com/kubernetes/kubernetes/pull/96421), [@dgrisonnet](https://github.com/dgrisonnet)) [SIG API Machinery and Instrumentation] -- Fixed a bug where improper storage and comparison of endpoints led to excessive API traffic from the endpoints controller ([#94112](https://github.com/kubernetes/kubernetes/pull/94112), [@damemi](https://github.com/damemi)) [SIG Apps, Network and Testing] -- Fixed a regression which prevented pods with `docker/default` seccomp annotations from being created in 1.19 if a PodSecurityPolicy was in place which did not allow `runtime/default` seccomp profiles. ([#95985](https://github.com/kubernetes/kubernetes/pull/95985), [@saschagrunert](https://github.com/saschagrunert)) [SIG Auth] -- Fixed bug in reflector that couldn't recover from "Too large resource version" errors with API servers 1.17.0-1.18.5 ([#94316](https://github.com/kubernetes/kubernetes/pull/94316), [@janeczku](https://github.com/janeczku)) [SIG API Machinery] -- Fixed bug where kubectl top pod output is not sorted when --sort-by and --containers flags are used together ([#93692](https://github.com/kubernetes/kubernetes/pull/93692), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] -- Fixed kubelet creating extra sandbox for pods with RestartPolicyOnFailure after all containers succeeded ([#92614](https://github.com/kubernetes/kubernetes/pull/92614), [@tnqn](https://github.com/tnqn)) [SIG Node and Testing] -- Fixes an issue proxying to ipv6 pods without specifying a port ([#94834](https://github.com/kubernetes/kubernetes/pull/94834), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Network] -- Fixes code generation for non-namespaced create subresources fake client test. ([#96586](https://github.com/kubernetes/kubernetes/pull/96586), [@Doude](https://github.com/Doude)) [SIG API Machinery] -- Fixes high CPU usage in kubectl drain ([#95260](https://github.com/kubernetes/kubernetes/pull/95260), [@amandahla](https://github.com/amandahla)) [SIG CLI] -- For vSphere Cloud Provider, If VM of worker node is deleted, the node will also be deleted by node controller ([#92608](https://github.com/kubernetes/kubernetes/pull/92608), [@lubronzhan](https://github.com/lubronzhan)) [SIG Cloud Provider] -- Gracefully delete nodes when their parent scale set went missing ([#95289](https://github.com/kubernetes/kubernetes/pull/95289), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider] -- HTTP/2 connection health check is enabled by default in all Kubernetes clients. The feature should work out-of-the-box. If needed, users can tune the feature via the HTTP2_READ_IDLE_TIMEOUT_SECONDS and HTTP2_PING_TIMEOUT_SECONDS environment variables. The feature is disabled if HTTP2_READ_IDLE_TIMEOUT_SECONDS is set to 0. ([#95981](https://github.com/kubernetes/kubernetes/pull/95981), [@caesarxuchao](https://github.com/caesarxuchao)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node] -- If the user specifies an invalid timeout in the request URL, the request will be aborted with an HTTP 400. - - If the user specifies a timeout in the request URL that exceeds the maximum request deadline allowed by the apiserver, the request will be aborted with an HTTP 400. ([#96061](https://github.com/kubernetes/kubernetes/pull/96061), [@tkashem](https://github.com/tkashem)) [SIG API Machinery, Network and Testing] -- If we set SelectPolicy MinPolicySelect on scaleUp behavior or scaleDown behavior,Horizontal Pod Autoscaler doesn`t automatically scale the number of pods correctly ([#95647](https://github.com/kubernetes/kubernetes/pull/95647), [@JoshuaAndrew](https://github.com/JoshuaAndrew)) [SIG Apps and Autoscaling] -- Ignore apparmor for non-linux operating systems ([#93220](https://github.com/kubernetes/kubernetes/pull/93220), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] -- Ignore root user check when windows pod starts ([#92355](https://github.com/kubernetes/kubernetes/pull/92355), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] -- Improve error messages related to nodePort endpoint changes conntrack entries cleanup. ([#96251](https://github.com/kubernetes/kubernetes/pull/96251), [@ravens](https://github.com/ravens)) [SIG Network] -- In dual-stack clusters, kubelet will now set up both IPv4 and IPv6 iptables rules, which may - fix some problems, eg with HostPorts. ([#94474](https://github.com/kubernetes/kubernetes/pull/94474), [@danwinship](https://github.com/danwinship)) [SIG Network and Node] -- Increase maximum IOPS of AWS EBS io1 volume to current maximum (64,000). ([#90014](https://github.com/kubernetes/kubernetes/pull/90014), [@jacobmarble](https://github.com/jacobmarble)) -- Ipvs: ensure selected scheduler kernel modules are loaded ([#93040](https://github.com/kubernetes/kubernetes/pull/93040), [@cmluciano](https://github.com/cmluciano)) [SIG Network] -- K8s.io/apimachinery: runtime.DefaultUnstructuredConverter.FromUnstructured now handles converting integer fields to typed float values ([#93250](https://github.com/kubernetes/kubernetes/pull/93250), [@liggitt](https://github.com/liggitt)) [SIG API Machinery] -- Kube-proxy now trims extra spaces found in loadBalancerSourceRanges to match Service validation. ([#94107](https://github.com/kubernetes/kubernetes/pull/94107), [@robscott](https://github.com/robscott)) [SIG Network] -- Kubeadm ensures "kubeadm reset" does not unmount the root "/var/lib/kubelet" directory if it is mounted by the user. ([#93702](https://github.com/kubernetes/kubernetes/pull/93702), [@thtanaka](https://github.com/thtanaka)) -- Kubeadm now makes sure the etcd manifest is regenerated upon upgrade even when no etcd version change takes place ([#94395](https://github.com/kubernetes/kubernetes/pull/94395), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle] -- Kubeadm now warns (instead of error out) on missing "ca.key" files for root CA, front-proxy CA and etcd CA, during "kubeadm join --control-plane" if the user has provided all certificates, keys and kubeconfig files which require signing with the given CA keys. ([#94988](https://github.com/kubernetes/kubernetes/pull/94988), [@neolit123](https://github.com/neolit123)) -- Kubeadm: add missing "--experimental-patches" flag to "kubeadm init phase control-plane" ([#95786](https://github.com/kubernetes/kubernetes/pull/95786), [@Sh4d1](https://github.com/Sh4d1)) [SIG Cluster Lifecycle] -- Kubeadm: avoid a panic when determining if the running version of CoreDNS is supported during upgrades ([#94299](https://github.com/kubernetes/kubernetes/pull/94299), [@zouyee](https://github.com/zouyee)) [SIG Cluster Lifecycle] -- Kubeadm: ensure the etcd data directory is created with 0700 permissions during control-plane init and join ([#94102](https://github.com/kubernetes/kubernetes/pull/94102), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: fix coredns migration should be triggered when there are newdefault configs during kubeadm upgrade ([#96907](https://github.com/kubernetes/kubernetes/pull/96907), [@pacoxu](https://github.com/pacoxu)) [SIG Cluster Lifecycle] -- Kubeadm: fix the bug that kubeadm tries to call 'docker info' even if the CRI socket was for another CR ([#94555](https://github.com/kubernetes/kubernetes/pull/94555), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] -- Kubeadm: for Docker as the container runtime, make the "kubeadm reset" command stop containers before removing them ([#94586](https://github.com/kubernetes/kubernetes/pull/94586), [@BedivereZero](https://github.com/BedivereZero)) [SIG Cluster Lifecycle] -- Kubeadm: make the kubeconfig files for the kube-controller-manager and kube-scheduler use the LocalAPIEndpoint instead of the ControlPlaneEndpoint. This makes kubeadm clusters more reseliant to version skew problems during immutable upgrades: https://kubernetes.io/docs/setup/release/version-skew-policy/#kube-controller-manager-kube-scheduler-and-cloud-controller-manager ([#94398](https://github.com/kubernetes/kubernetes/pull/94398), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: relax the validation of kubeconfig server URLs. Allow the user to define custom kubeconfig server URLs without erroring out during validation of existing kubeconfig files (e.g. when using external CA mode). ([#94816](https://github.com/kubernetes/kubernetes/pull/94816), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubectl: print error if users place flags before plugin name ([#92343](https://github.com/kubernetes/kubernetes/pull/92343), [@knight42](https://github.com/knight42)) [SIG CLI] -- Kubelet: assume that swap is disabled when `/proc/swaps` does not exist ([#93931](https://github.com/kubernetes/kubernetes/pull/93931), [@SataQiu](https://github.com/SataQiu)) [SIG Node] -- New Azure instance types do now have correct max data disk count information. ([#94340](https://github.com/kubernetes/kubernetes/pull/94340), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Cloud Provider and Storage] -- Port mapping now allows the same `containerPort` of different containers to different `hostPort` without naming the mapping explicitly. ([#94494](https://github.com/kubernetes/kubernetes/pull/94494), [@SergeyKanzhelev](https://github.com/SergeyKanzhelev)) -- Print go stack traces at -v=4 and not -v=2 ([#94663](https://github.com/kubernetes/kubernetes/pull/94663), [@soltysh](https://github.com/soltysh)) [SIG CLI] -- Recreate EndpointSlices on rapid Service creation. ([#94730](https://github.com/kubernetes/kubernetes/pull/94730), [@robscott](https://github.com/robscott)) -- Reduce volume name length for vsphere volumes ([#96533](https://github.com/kubernetes/kubernetes/pull/96533), [@gnufied](https://github.com/gnufied)) [SIG Storage] -- Remove ready file and its directory (which is created during volume SetUp) during emptyDir volume TearDown. ([#95770](https://github.com/kubernetes/kubernetes/pull/95770), [@jingxu97](https://github.com/jingxu97)) [SIG Storage] -- Reorganized iptables rules to fix a performance issue ([#95252](https://github.com/kubernetes/kubernetes/pull/95252), [@tssurya](https://github.com/tssurya)) [SIG Network] -- Require feature flag CustomCPUCFSQuotaPeriod if setting a non-default cpuCFSQuotaPeriod in kubelet config. ([#94687](https://github.com/kubernetes/kubernetes/pull/94687), [@karan](https://github.com/karan)) [SIG Node] -- Resolves a regression in 1.19+ with workloads targeting deprecated beta os/arch labels getting stuck in NodeAffinity status on node startup. ([#96810](https://github.com/kubernetes/kubernetes/pull/96810), [@liggitt](https://github.com/liggitt)) [SIG Node] -- Resolves non-deterministic behavior of the garbage collection controller when ownerReferences with incorrect data are encountered. Events with a reason of `OwnerRefInvalidNamespace` are recorded when namespace mismatches between child and owner objects are detected. The [kubectl-check-ownerreferences](https://github.com/kubernetes-sigs/kubectl-check-ownerreferences) tool can be run prior to upgrading to locate existing objects with invalid ownerReferences. - - A namespaced object with an ownerReference referencing a uid of a namespaced kind which does not exist in the same namespace is now consistently treated as though that owner does not exist, and the child object is deleted. - - A cluster-scoped object with an ownerReference referencing a uid of a namespaced kind is now consistently treated as though that owner is not resolvable, and the child object is ignored by the garbage collector. ([#92743](https://github.com/kubernetes/kubernetes/pull/92743), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Testing] -- Skip [k8s.io/kubernetes@v1.19.0/test/e2e/storage/testsuites/base.go:162]: Driver azure-disk doesn't support snapshot type DynamicSnapshot -- skipping - skip [k8s.io/kubernetes@v1.19.0/test/e2e/storage/testsuites/base.go:185]: Driver azure-disk doesn't support ntfs -- skipping ([#96144](https://github.com/kubernetes/kubernetes/pull/96144), [@qinpingli](https://github.com/qinpingli)) [SIG Storage and Testing] -- StatefulSet Controller now waits for PersistentVolumeClaim deletion before creating pods. ([#93457](https://github.com/kubernetes/kubernetes/pull/93457), [@ymmt2005](https://github.com/ymmt2005)) -- StreamWatcher now calls HandleCrash at appropriate sequence. ([#93108](https://github.com/kubernetes/kubernetes/pull/93108), [@lixiaobing1](https://github.com/lixiaobing1)) -- Support the node label `node.kubernetes.io/exclude-from-external-load-balancers` ([#95542](https://github.com/kubernetes/kubernetes/pull/95542), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- The AWS network load balancer attributes can now be specified during service creation ([#95247](https://github.com/kubernetes/kubernetes/pull/95247), [@kishorj](https://github.com/kishorj)) [SIG Cloud Provider] -- The `/debug/api_priority_and_fairness/dump_requests` path at an apiserver will no longer return a phantom line for each exempt priority level. ([#93406](https://github.com/kubernetes/kubernetes/pull/93406), [@MikeSpreitzer](https://github.com/MikeSpreitzer)) [SIG API Machinery] -- The kube-apiserver will no longer serve APIs that should have been deleted in GA non-alpha levels. Alpha levels will continue to serve the removed APIs so that CI doesn't immediately break. ([#96525](https://github.com/kubernetes/kubernetes/pull/96525), [@deads2k](https://github.com/deads2k)) [SIG API Machinery] -- The kubelet recognizes the --containerd-namespace flag to configure the namespace used by cadvisor. ([#87054](https://github.com/kubernetes/kubernetes/pull/87054), [@changyaowei](https://github.com/changyaowei)) [SIG Node] -- Unhealthy pods covered by PDBs can be successfully evicted if enough healthy pods are available. ([#94381](https://github.com/kubernetes/kubernetes/pull/94381), [@michaelgugino](https://github.com/michaelgugino)) [SIG Apps] -- Update Calico to v3.15.2 ([#94241](https://github.com/kubernetes/kubernetes/pull/94241), [@lmm](https://github.com/lmm)) [SIG Cloud Provider] -- Update default etcd server version to 3.4.13 ([#94287](https://github.com/kubernetes/kubernetes/pull/94287), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cloud Provider, Cluster Lifecycle and Testing] -- Update max azure data disk count map ([#96308](https://github.com/kubernetes/kubernetes/pull/96308), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Update the PIP when it is not in the Succeeded provisioning state during the LB update. ([#95748](https://github.com/kubernetes/kubernetes/pull/95748), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Update the frontend IP config when the service's `pipName` annotation is changed ([#95813](https://github.com/kubernetes/kubernetes/pull/95813), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Update the route table tag in the route reconcile loop ([#96545](https://github.com/kubernetes/kubernetes/pull/96545), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Use NLB Subnet CIDRs instead of VPC CIDRs in Health Check SG Rules ([#93515](https://github.com/kubernetes/kubernetes/pull/93515), [@t0rr3sp3dr0](https://github.com/t0rr3sp3dr0)) [SIG Cloud Provider] -- Users will see increase in time for deletion of pods and also guarantee that removal of pod from api server would mean deletion of all the resources from container runtime. ([#92817](https://github.com/kubernetes/kubernetes/pull/92817), [@kmala](https://github.com/kmala)) [SIG Node] -- Very large patches may now be specified to `kubectl patch` with the `--patch-file` flag instead of including them directly on the command line. The `--patch` and `--patch-file` flags are mutually exclusive. ([#93548](https://github.com/kubernetes/kubernetes/pull/93548), [@smarterclayton](https://github.com/smarterclayton)) [SIG CLI] -- Volume binding: report UnschedulableAndUnresolvable status instead of an error when bound PVs not found ([#95541](https://github.com/kubernetes/kubernetes/pull/95541), [@cofyc](https://github.com/cofyc)) [SIG Apps, Scheduling and Storage] -- Warn instead of fail when creating Roles and ClusterRoles with custom verbs via kubectl ([#92492](https://github.com/kubernetes/kubernetes/pull/92492), [@eddiezane](https://github.com/eddiezane)) [SIG CLI] -- When creating a PVC with the volume.beta.kubernetes.io/storage-provisioner annotation already set, the PV controller might have incorrectly deleted the newly provisioned PV instead of binding it to the PVC, depending on timing and system load. ([#95909](https://github.com/kubernetes/kubernetes/pull/95909), [@pohly](https://github.com/pohly)) [SIG Apps and Storage] -- [kubectl] Fail when local source file doesn't exist ([#90333](https://github.com/kubernetes/kubernetes/pull/90333), [@bamarni](https://github.com/bamarni)) [SIG CLI] - -### 기타 (정리 또는 플레이크(flake)) - -- **Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.**: - - ([#96443](https://github.com/kubernetes/kubernetes/pull/96443), [@alaypatel07](https://github.com/alaypatel07)) [SIG Apps] -- --redirect-container-streaming is no longer functional. The flag will be removed in v1.22 ([#95935](https://github.com/kubernetes/kubernetes/pull/95935), [@tallclair](https://github.com/tallclair)) [SIG Node] -- A new metric `requestAbortsTotal` has been introduced that counts aborted requests for each `group`, `version`, `verb`, `resource`, `subresource` and `scope`. ([#95002](https://github.com/kubernetes/kubernetes/pull/95002), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery, Cloud Provider, Instrumentation and Scheduling] -- API priority and fairness metrics use snake_case in label names ([#96236](https://github.com/kubernetes/kubernetes/pull/96236), [@adtac](https://github.com/adtac)) [SIG API Machinery, Cluster Lifecycle, Instrumentation and Testing] -- Add fine grained debugging to intra-pod conformance test to troubleshoot networking issues for potentially unhealthy nodes when running conformance or sonobuoy tests. ([#93837](https://github.com/kubernetes/kubernetes/pull/93837), [@jayunit100](https://github.com/jayunit100)) -- Add the following metrics: - - network_plugin_operations_total - - network_plugin_operations_errors_total ([#93066](https://github.com/kubernetes/kubernetes/pull/93066), [@AnishShah](https://github.com/AnishShah)) -- Adds a bootstrapping ClusterRole, ClusterRoleBinding and group for /metrics, /livez/*, /readyz/*, & /healthz/- endpoints. ([#93311](https://github.com/kubernetes/kubernetes/pull/93311), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery, Auth, Cloud Provider and Instrumentation] -- AdmissionReview objects sent for the creation of Namespace API objects now populate the `namespace` attribute consistently (previously the `namespace` attribute was empty for Namespace creation via POST requests, and populated for Namespace creation via server-side-apply PATCH requests) ([#95012](https://github.com/kubernetes/kubernetes/pull/95012), [@nodo](https://github.com/nodo)) [SIG API Machinery and Testing] -- Applies translations on all command descriptions ([#95439](https://github.com/kubernetes/kubernetes/pull/95439), [@HerrNaN](https://github.com/HerrNaN)) [SIG CLI] -- Base-images: Update to debian-iptables:buster-v1.3.0 - - Uses iptables 1.8.5 - - base-images: Update to debian-base:buster-v1.2.0 - - cluster/images/etcd: Build etcd:3.4.13-1 image - - Uses debian-base:buster-v1.2.0 ([#94733](https://github.com/kubernetes/kubernetes/pull/94733), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Release and Testing] -- Changed: default "Accept-Encoding" header removed from HTTP probes. See https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#http-probes ([#96127](https://github.com/kubernetes/kubernetes/pull/96127), [@fonsecas72](https://github.com/fonsecas72)) [SIG Network and Node] -- Client-go header logging (at verbosity levels >= 9) now masks `Authorization` header contents ([#95316](https://github.com/kubernetes/kubernetes/pull/95316), [@sfowl](https://github.com/sfowl)) [SIG API Machinery] -- Decrease warning message frequency on setting volume ownership for configmap/secret. ([#92878](https://github.com/kubernetes/kubernetes/pull/92878), [@jvanz](https://github.com/jvanz)) -- Enhance log information of verifyRunAsNonRoot, add pod, container information ([#94911](https://github.com/kubernetes/kubernetes/pull/94911), [@wawa0210](https://github.com/wawa0210)) [SIG Node] -- Fix func name NewCreateCreateDeploymentOptions ([#91931](https://github.com/kubernetes/kubernetes/pull/91931), [@lixiaobing1](https://github.com/lixiaobing1)) [SIG CLI] -- Fix kubelet to properly log when a container is started. Previously, kubelet may log that container is dead and was restarted when it was actually started for the first time. This behavior only happened on pods with initContainers and regular containers. ([#91469](https://github.com/kubernetes/kubernetes/pull/91469), [@rata](https://github.com/rata)) -- Fixes the message about no auth for metrics in scheduler. ([#94035](https://github.com/kubernetes/kubernetes/pull/94035), [@zhouya0](https://github.com/zhouya0)) [SIG Scheduling] -- Generators for services are removed from kubectl ([#95256](https://github.com/kubernetes/kubernetes/pull/95256), [@Git-Jiro](https://github.com/Git-Jiro)) [SIG CLI] -- Introduce kubectl-convert plugin. ([#96190](https://github.com/kubernetes/kubernetes/pull/96190), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing] -- Kube-scheduler now logs processed component config at startup ([#96426](https://github.com/kubernetes/kubernetes/pull/96426), [@damemi](https://github.com/damemi)) [SIG Scheduling] -- Kubeadm: Separate argument key/value in log msg ([#94016](https://github.com/kubernetes/kubernetes/pull/94016), [@mrueg](https://github.com/mrueg)) [SIG Cluster Lifecycle] -- Kubeadm: remove the CoreDNS check for known image digests when applying the addon ([#94506](https://github.com/kubernetes/kubernetes/pull/94506), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: update the default pause image version to 1.4.0 on Windows. With this update the image supports Windows versions 1809 (2019LTS), 1903, 1909, 2004 ([#95419](https://github.com/kubernetes/kubernetes/pull/95419), [@jsturtevant](https://github.com/jsturtevant)) [SIG Cluster Lifecycle and Windows] -- Kubectl: the `generator` flag of `kubectl autoscale` has been deprecated and has no effect, it will be removed in a feature release ([#92998](https://github.com/kubernetes/kubernetes/pull/92998), [@SataQiu](https://github.com/SataQiu)) [SIG CLI] -- Lock ExternalPolicyForExternalIP to default, this feature gate will be removed in 1.22. ([#94581](https://github.com/kubernetes/kubernetes/pull/94581), [@knabben](https://github.com/knabben)) [SIG Network] -- Mask ceph RBD adminSecrets in logs when logLevel >= 4. ([#95245](https://github.com/kubernetes/kubernetes/pull/95245), [@sfowl](https://github.com/sfowl)) -- Remove offensive words from kubectl cluster-info command. ([#95202](https://github.com/kubernetes/kubernetes/pull/95202), [@rikatz](https://github.com/rikatz)) -- Remove support for "ci/k8s-master" version label in kubeadm, use "ci/latest" instead. See [kubernetes/test-infra#18517](https://github.com/kubernetes/test-infra/pull/18517). ([#93626](https://github.com/kubernetes/kubernetes/pull/93626), [@vikkyomkar](https://github.com/vikkyomkar)) -- Remove the dependency of csi-translation-lib module on apiserver/cloud-provider/controller-manager ([#95543](https://github.com/kubernetes/kubernetes/pull/95543), [@wawa0210](https://github.com/wawa0210)) [SIG Release] -- Scheduler framework interface moved from pkg/scheduler/framework/v1alpha to pkg/scheduler/framework ([#95069](https://github.com/kubernetes/kubernetes/pull/95069), [@farah](https://github.com/farah)) [SIG Scheduling, Storage and Testing] -- Service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset is removed. All Standard load balancers will always enable tcp resets. ([#94297](https://github.com/kubernetes/kubernetes/pull/94297), [@MarcPow](https://github.com/MarcPow)) [SIG Cloud Provider] -- Stop propagating SelfLink (deprecated in 1.16) in kube-apiserver ([#94397](https://github.com/kubernetes/kubernetes/pull/94397), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Testing] -- Strip unnecessary security contexts on Windows ([#93475](https://github.com/kubernetes/kubernetes/pull/93475), [@ravisantoshgudimetla](https://github.com/ravisantoshgudimetla)) [SIG Node, Testing and Windows] -- To ensure the code be strong, add unit test for GetAddressAndDialer ([#93180](https://github.com/kubernetes/kubernetes/pull/93180), [@FreeZhang61](https://github.com/FreeZhang61)) [SIG Node] -- UDP and SCTP protocols can left stale connections that need to be cleared to avoid services disruption, but they can cause problems that are hard to debug. - Kubernetes components using a loglevel greater or equal than 4 will log the conntrack operations and its output, to show the entries that were deleted. ([#95694](https://github.com/kubernetes/kubernetes/pull/95694), [@aojea](https://github.com/aojea)) [SIG Network] -- Update CNI plugins to v0.8.7 ([#94367](https://github.com/kubernetes/kubernetes/pull/94367), [@justaugustus](https://github.com/justaugustus)) [SIG Cloud Provider, Network, Node, Release and Testing] -- Update cri-tools to [v1.19.0](https://github.com/kubernetes-sigs/cri-tools/releases/tag/v1.19.0) ([#94307](https://github.com/kubernetes/kubernetes/pull/94307), [@xmudrii](https://github.com/xmudrii)) [SIG Cloud Provider] -- Update etcd client side to v3.4.13 ([#94259](https://github.com/kubernetes/kubernetes/pull/94259), [@jingyih](https://github.com/jingyih)) [SIG API Machinery and Cloud Provider] -- Users will now be able to configure all supported values for AWS NLB health check interval and thresholds for new resources. ([#96312](https://github.com/kubernetes/kubernetes/pull/96312), [@kishorj](https://github.com/kishorj)) [SIG Cloud Provider] -- V1helpers.MatchNodeSelectorTerms now accepts just a Node and a list of Terms ([#95871](https://github.com/kubernetes/kubernetes/pull/95871), [@damemi](https://github.com/damemi)) [SIG Apps, Scheduling and Storage] -- Vsphere: improve logging message on node cache refresh event ([#95236](https://github.com/kubernetes/kubernetes/pull/95236), [@andrewsykim](https://github.com/andrewsykim)) [SIG Cloud Provider] -- `MatchNodeSelectorTerms` function moved to `k8s.io/component-helpers` ([#95531](https://github.com/kubernetes/kubernetes/pull/95531), [@damemi](https://github.com/damemi)) [SIG Apps, Scheduling and Storage] -- `kubectl api-resources` now prints the API version (as 'API group/version', same as output of `kubectl api-versions`). The column APIGROUP is now APIVERSION ([#95253](https://github.com/kubernetes/kubernetes/pull/95253), [@sallyom](https://github.com/sallyom)) [SIG CLI] -- `kubectl get ingress` now prefers the `networking.k8s.io/v1` over `extensions/v1beta1` (deprecated since v1.14). To explicitly request the deprecated version, use `kubectl get ingress.v1beta1.extensions`. ([#94309](https://github.com/kubernetes/kubernetes/pull/94309), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and CLI] - -## 의존성 - -### 추가 -- cloud.google.com/go/firestore: v1.1.0 -- github.com/Azure/go-autorest: [v14.2.0+incompatible](https://github.com/Azure/go-autorest/tree/v14.2.0) -- github.com/armon/go-metrics: [f0300d1](https://github.com/armon/go-metrics/tree/f0300d1) -- github.com/armon/go-radix: [7fddfc3](https://github.com/armon/go-radix/tree/7fddfc3) -- github.com/bketelsen/crypt: [5cbc8cc](https://github.com/bketelsen/crypt/tree/5cbc8cc) -- github.com/form3tech-oss/jwt-go: [v3.2.2+incompatible](https://github.com/form3tech-oss/jwt-go/tree/v3.2.2) -- github.com/fvbommel/sortorder: [v1.0.1](https://github.com/fvbommel/sortorder/tree/v1.0.1) -- github.com/hashicorp/consul/api: [v1.1.0](https://github.com/hashicorp/consul/api/tree/v1.1.0) -- github.com/hashicorp/consul/sdk: [v0.1.1](https://github.com/hashicorp/consul/sdk/tree/v0.1.1) -- github.com/hashicorp/errwrap: [v1.0.0](https://github.com/hashicorp/errwrap/tree/v1.0.0) -- github.com/hashicorp/go-cleanhttp: [v0.5.1](https://github.com/hashicorp/go-cleanhttp/tree/v0.5.1) -- github.com/hashicorp/go-immutable-radix: [v1.0.0](https://github.com/hashicorp/go-immutable-radix/tree/v1.0.0) -- github.com/hashicorp/go-msgpack: [v0.5.3](https://github.com/hashicorp/go-msgpack/tree/v0.5.3) -- github.com/hashicorp/go-multierror: [v1.0.0](https://github.com/hashicorp/go-multierror/tree/v1.0.0) -- github.com/hashicorp/go-rootcerts: [v1.0.0](https://github.com/hashicorp/go-rootcerts/tree/v1.0.0) -- github.com/hashicorp/go-sockaddr: [v1.0.0](https://github.com/hashicorp/go-sockaddr/tree/v1.0.0) -- github.com/hashicorp/go-uuid: [v1.0.1](https://github.com/hashicorp/go-uuid/tree/v1.0.1) -- github.com/hashicorp/go.net: [v0.0.1](https://github.com/hashicorp/go.net/tree/v0.0.1) -- github.com/hashicorp/logutils: [v1.0.0](https://github.com/hashicorp/logutils/tree/v1.0.0) -- github.com/hashicorp/mdns: [v1.0.0](https://github.com/hashicorp/mdns/tree/v1.0.0) -- github.com/hashicorp/memberlist: [v0.1.3](https://github.com/hashicorp/memberlist/tree/v0.1.3) -- github.com/hashicorp/serf: [v0.8.2](https://github.com/hashicorp/serf/tree/v0.8.2) -- github.com/jmespath/go-jmespath/internal/testify: [v1.5.1](https://github.com/jmespath/go-jmespath/internal/testify/tree/v1.5.1) -- github.com/mitchellh/cli: [v1.0.0](https://github.com/mitchellh/cli/tree/v1.0.0) -- github.com/mitchellh/go-testing-interface: [v1.0.0](https://github.com/mitchellh/go-testing-interface/tree/v1.0.0) -- github.com/mitchellh/gox: [v0.4.0](https://github.com/mitchellh/gox/tree/v0.4.0) -- github.com/mitchellh/iochan: [v1.0.0](https://github.com/mitchellh/iochan/tree/v1.0.0) -- github.com/pascaldekloe/goe: [57f6aae](https://github.com/pascaldekloe/goe/tree/57f6aae) -- github.com/posener/complete: [v1.1.1](https://github.com/posener/complete/tree/v1.1.1) -- github.com/ryanuber/columnize: [9b3edd6](https://github.com/ryanuber/columnize/tree/9b3edd6) -- github.com/sean-/seed: [e2103e2](https://github.com/sean-/seed/tree/e2103e2) -- github.com/subosito/gotenv: [v1.2.0](https://github.com/subosito/gotenv/tree/v1.2.0) -- github.com/willf/bitset: [d5bec33](https://github.com/willf/bitset/tree/d5bec33) -- gopkg.in/ini.v1: v1.51.0 -- gopkg.in/yaml.v3: 9f266ea -- rsc.io/quote/v3: v3.1.0 -- rsc.io/sampler: v1.3.0 - -### 변경 -- cloud.google.com/go/bigquery: v1.0.1 → v1.4.0 -- cloud.google.com/go/datastore: v1.0.0 → v1.1.0 -- cloud.google.com/go/pubsub: v1.0.1 → v1.2.0 -- cloud.google.com/go/storage: v1.0.0 → v1.6.0 -- cloud.google.com/go: v0.51.0 → v0.54.0 -- github.com/Azure/go-autorest/autorest/adal: [v0.8.2 → v0.9.5](https://github.com/Azure/go-autorest/autorest/adal/compare/v0.8.2...v0.9.5) -- github.com/Azure/go-autorest/autorest/date: [v0.2.0 → v0.3.0](https://github.com/Azure/go-autorest/autorest/date/compare/v0.2.0...v0.3.0) -- github.com/Azure/go-autorest/autorest/mocks: [v0.3.0 → v0.4.1](https://github.com/Azure/go-autorest/autorest/mocks/compare/v0.3.0...v0.4.1) -- github.com/Azure/go-autorest/autorest: [v0.9.6 → v0.11.1](https://github.com/Azure/go-autorest/autorest/compare/v0.9.6...v0.11.1) -- github.com/Azure/go-autorest/logger: [v0.1.0 → v0.2.0](https://github.com/Azure/go-autorest/logger/compare/v0.1.0...v0.2.0) -- github.com/Azure/go-autorest/tracing: [v0.5.0 → v0.6.0](https://github.com/Azure/go-autorest/tracing/compare/v0.5.0...v0.6.0) -- github.com/Microsoft/go-winio: [fc70bd9 → v0.4.15](https://github.com/Microsoft/go-winio/compare/fc70bd9...v0.4.15) -- github.com/aws/aws-sdk-go: [v1.28.2 → v1.35.24](https://github.com/aws/aws-sdk-go/compare/v1.28.2...v1.35.24) -- github.com/blang/semver: [v3.5.0+incompatible → v3.5.1+incompatible](https://github.com/blang/semver/compare/v3.5.0...v3.5.1) -- github.com/checkpoint-restore/go-criu/v4: [v4.0.2 → v4.1.0](https://github.com/checkpoint-restore/go-criu/v4/compare/v4.0.2...v4.1.0) -- github.com/containerd/containerd: [v1.3.3 → v1.4.1](https://github.com/containerd/containerd/compare/v1.3.3...v1.4.1) -- github.com/containerd/ttrpc: [v1.0.0 → v1.0.2](https://github.com/containerd/ttrpc/compare/v1.0.0...v1.0.2) -- github.com/containerd/typeurl: [v1.0.0 → v1.0.1](https://github.com/containerd/typeurl/compare/v1.0.0...v1.0.1) -- github.com/coreos/etcd: [v3.3.10+incompatible → v3.3.13+incompatible](https://github.com/coreos/etcd/compare/v3.3.10...v3.3.13) -- github.com/docker/docker: [aa6a989 → bd33bbf](https://github.com/docker/docker/compare/aa6a989...bd33bbf) -- github.com/go-gl/glfw/v3.3/glfw: [12ad95a → 6f7a984](https://github.com/go-gl/glfw/v3.3/glfw/compare/12ad95a...6f7a984) -- github.com/golang/groupcache: [215e871 → 8c9f03a](https://github.com/golang/groupcache/compare/215e871...8c9f03a) -- github.com/golang/mock: [v1.3.1 → v1.4.1](https://github.com/golang/mock/compare/v1.3.1...v1.4.1) -- github.com/golang/protobuf: [v1.4.2 → v1.4.3](https://github.com/golang/protobuf/compare/v1.4.2...v1.4.3) -- github.com/google/cadvisor: [v0.37.0 → v0.38.5](https://github.com/google/cadvisor/compare/v0.37.0...v0.38.5) -- github.com/google/go-cmp: [v0.4.0 → v0.5.2](https://github.com/google/go-cmp/compare/v0.4.0...v0.5.2) -- github.com/google/pprof: [d4f498a → 1ebb73c](https://github.com/google/pprof/compare/d4f498a...1ebb73c) -- github.com/google/uuid: [v1.1.1 → v1.1.2](https://github.com/google/uuid/compare/v1.1.1...v1.1.2) -- github.com/gorilla/mux: [v1.7.3 → v1.8.0](https://github.com/gorilla/mux/compare/v1.7.3...v1.8.0) -- github.com/gorilla/websocket: [v1.4.0 → v1.4.2](https://github.com/gorilla/websocket/compare/v1.4.0...v1.4.2) -- github.com/jmespath/go-jmespath: [c2b33e8 → v0.4.0](https://github.com/jmespath/go-jmespath/compare/c2b33e8...v0.4.0) -- github.com/karrick/godirwalk: [v1.7.5 → v1.16.1](https://github.com/karrick/godirwalk/compare/v1.7.5...v1.16.1) -- github.com/opencontainers/go-digest: [v1.0.0-rc1 → v1.0.0](https://github.com/opencontainers/go-digest/compare/v1.0.0-rc1...v1.0.0) -- github.com/opencontainers/runc: [819fcc6 → v1.0.0-rc92](https://github.com/opencontainers/runc/compare/819fcc6...v1.0.0-rc92) -- github.com/opencontainers/runtime-spec: [237cc4f → 4d89ac9](https://github.com/opencontainers/runtime-spec/compare/237cc4f...4d89ac9) -- github.com/opencontainers/selinux: [v1.5.2 → v1.6.0](https://github.com/opencontainers/selinux/compare/v1.5.2...v1.6.0) -- github.com/prometheus/procfs: [v0.1.3 → v0.2.0](https://github.com/prometheus/procfs/compare/v0.1.3...v0.2.0) -- github.com/quobyte/api: [v0.1.2 → v0.1.8](https://github.com/quobyte/api/compare/v0.1.2...v0.1.8) -- github.com/spf13/cobra: [v1.0.0 → v1.1.1](https://github.com/spf13/cobra/compare/v1.0.0...v1.1.1) -- github.com/spf13/viper: [v1.4.0 → v1.7.0](https://github.com/spf13/viper/compare/v1.4.0...v1.7.0) -- github.com/storageos/go-api: [343b3ef → v2.2.0+incompatible](https://github.com/storageos/go-api/compare/343b3ef...v2.2.0) -- github.com/stretchr/testify: [v1.4.0 → v1.6.1](https://github.com/stretchr/testify/compare/v1.4.0...v1.6.1) -- github.com/vishvananda/netns: [52d707b → db3c7e5](https://github.com/vishvananda/netns/compare/52d707b...db3c7e5) -- go.etcd.io/etcd: 17cef6e → dd1b699 -- go.opencensus.io: v0.22.2 → v0.22.3 -- golang.org/x/crypto: 75b2880 → 7f63de1 -- golang.org/x/exp: da58074 → 6cc2880 -- golang.org/x/lint: fdd1cda → 738671d -- golang.org/x/net: ab34263 → 69a7880 -- golang.org/x/oauth2: 858c2ad → bf48bf1 -- golang.org/x/sys: ed371f2 → 5cba982 -- golang.org/x/text: v0.3.3 → v0.3.4 -- golang.org/x/time: 555d28b → 3af7569 -- golang.org/x/xerrors: 9bdfabe → 5ec99f8 -- google.golang.org/api: v0.15.1 → v0.20.0 -- google.golang.org/genproto: cb27e3a → 8816d57 -- google.golang.org/grpc: v1.27.0 → v1.27.1 -- google.golang.org/protobuf: v1.24.0 → v1.25.0 -- honnef.co/go/tools: v0.0.1-2019.2.3 → v0.0.1-2020.1.3 -- k8s.io/gengo: 8167cfd → 83324d8 -- k8s.io/klog/v2: v2.2.0 → v2.4.0 -- k8s.io/kube-openapi: 6aeccd4 → d219536 -- k8s.io/system-validators: v1.1.2 → v1.2.0 -- k8s.io/utils: d5654de → 67b214c -- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.9 → v0.0.14 -- sigs.k8s.io/structured-merge-diff/v4: v4.0.1 → v4.0.2 - -### 제거 -- github.com/armon/consul-api: [eb2c6b5](https://github.com/armon/consul-api/tree/eb2c6b5) -- github.com/go-ini/ini: [v1.9.0](https://github.com/go-ini/ini/tree/v1.9.0) -- github.com/ugorji/go: [v1.1.4](https://github.com/ugorji/go/tree/v1.1.4) -- github.com/xlab/handysort: [fb3537e](https://github.com/xlab/handysort/tree/fb3537e) -- github.com/xordataexchange/crypt: [b2862e3](https://github.com/xordataexchange/crypt/tree/b2862e3) -- vbom.ml/util: db5cfe1 - - -## 의존성 - -### 추가 -- cloud.google.com/go/firestore: v1.1.0 -- github.com/Azure/go-autorest: [v14.2.0+incompatible](https://github.com/Azure/go-autorest/tree/v14.2.0) -- github.com/armon/go-metrics: [f0300d1](https://github.com/armon/go-metrics/tree/f0300d1) -- github.com/armon/go-radix: [7fddfc3](https://github.com/armon/go-radix/tree/7fddfc3) -- github.com/bketelsen/crypt: [5cbc8cc](https://github.com/bketelsen/crypt/tree/5cbc8cc) -- github.com/form3tech-oss/jwt-go: [v3.2.2+incompatible](https://github.com/form3tech-oss/jwt-go/tree/v3.2.2) -- github.com/fvbommel/sortorder: [v1.0.1](https://github.com/fvbommel/sortorder/tree/v1.0.1) -- github.com/hashicorp/consul/api: [v1.1.0](https://github.com/hashicorp/consul/api/tree/v1.1.0) -- github.com/hashicorp/consul/sdk: [v0.1.1](https://github.com/hashicorp/consul/sdk/tree/v0.1.1) -- github.com/hashicorp/errwrap: [v1.0.0](https://github.com/hashicorp/errwrap/tree/v1.0.0) -- github.com/hashicorp/go-cleanhttp: [v0.5.1](https://github.com/hashicorp/go-cleanhttp/tree/v0.5.1) -- github.com/hashicorp/go-immutable-radix: [v1.0.0](https://github.com/hashicorp/go-immutable-radix/tree/v1.0.0) -- github.com/hashicorp/go-msgpack: [v0.5.3](https://github.com/hashicorp/go-msgpack/tree/v0.5.3) -- github.com/hashicorp/go-multierror: [v1.0.0](https://github.com/hashicorp/go-multierror/tree/v1.0.0) -- github.com/hashicorp/go-rootcerts: [v1.0.0](https://github.com/hashicorp/go-rootcerts/tree/v1.0.0) -- github.com/hashicorp/go-sockaddr: [v1.0.0](https://github.com/hashicorp/go-sockaddr/tree/v1.0.0) -- github.com/hashicorp/go-uuid: [v1.0.1](https://github.com/hashicorp/go-uuid/tree/v1.0.1) -- github.com/hashicorp/go.net: [v0.0.1](https://github.com/hashicorp/go.net/tree/v0.0.1) -- github.com/hashicorp/logutils: [v1.0.0](https://github.com/hashicorp/logutils/tree/v1.0.0) -- github.com/hashicorp/mdns: [v1.0.0](https://github.com/hashicorp/mdns/tree/v1.0.0) -- github.com/hashicorp/memberlist: [v0.1.3](https://github.com/hashicorp/memberlist/tree/v0.1.3) -- github.com/hashicorp/serf: [v0.8.2](https://github.com/hashicorp/serf/tree/v0.8.2) -- github.com/jmespath/go-jmespath/internal/testify: [v1.5.1](https://github.com/jmespath/go-jmespath/internal/testify/tree/v1.5.1) -- github.com/mitchellh/cli: [v1.0.0](https://github.com/mitchellh/cli/tree/v1.0.0) -- github.com/mitchellh/go-testing-interface: [v1.0.0](https://github.com/mitchellh/go-testing-interface/tree/v1.0.0) -- github.com/mitchellh/gox: [v0.4.0](https://github.com/mitchellh/gox/tree/v0.4.0) -- github.com/mitchellh/iochan: [v1.0.0](https://github.com/mitchellh/iochan/tree/v1.0.0) -- github.com/pascaldekloe/goe: [57f6aae](https://github.com/pascaldekloe/goe/tree/57f6aae) -- github.com/posener/complete: [v1.1.1](https://github.com/posener/complete/tree/v1.1.1) -- github.com/ryanuber/columnize: [9b3edd6](https://github.com/ryanuber/columnize/tree/9b3edd6) -- github.com/sean-/seed: [e2103e2](https://github.com/sean-/seed/tree/e2103e2) -- github.com/subosito/gotenv: [v1.2.0](https://github.com/subosito/gotenv/tree/v1.2.0) -- github.com/willf/bitset: [d5bec33](https://github.com/willf/bitset/tree/d5bec33) -- gopkg.in/ini.v1: v1.51.0 -- gopkg.in/yaml.v3: 9f266ea -- rsc.io/quote/v3: v3.1.0 -- rsc.io/sampler: v1.3.0 - -### 변경 -- cloud.google.com/go/bigquery: v1.0.1 → v1.4.0 -- cloud.google.com/go/datastore: v1.0.0 → v1.1.0 -- cloud.google.com/go/pubsub: v1.0.1 → v1.2.0 -- cloud.google.com/go/storage: v1.0.0 → v1.6.0 -- cloud.google.com/go: v0.51.0 → v0.54.0 -- github.com/Azure/go-autorest/autorest/adal: [v0.8.2 → v0.9.5](https://github.com/Azure/go-autorest/autorest/adal/compare/v0.8.2...v0.9.5) -- github.com/Azure/go-autorest/autorest/date: [v0.2.0 → v0.3.0](https://github.com/Azure/go-autorest/autorest/date/compare/v0.2.0...v0.3.0) -- github.com/Azure/go-autorest/autorest/mocks: [v0.3.0 → v0.4.1](https://github.com/Azure/go-autorest/autorest/mocks/compare/v0.3.0...v0.4.1) -- github.com/Azure/go-autorest/autorest: [v0.9.6 → v0.11.1](https://github.com/Azure/go-autorest/autorest/compare/v0.9.6...v0.11.1) -- github.com/Azure/go-autorest/logger: [v0.1.0 → v0.2.0](https://github.com/Azure/go-autorest/logger/compare/v0.1.0...v0.2.0) -- github.com/Azure/go-autorest/tracing: [v0.5.0 → v0.6.0](https://github.com/Azure/go-autorest/tracing/compare/v0.5.0...v0.6.0) -- github.com/Microsoft/go-winio: [fc70bd9 → v0.4.15](https://github.com/Microsoft/go-winio/compare/fc70bd9...v0.4.15) -- github.com/aws/aws-sdk-go: [v1.28.2 → v1.35.24](https://github.com/aws/aws-sdk-go/compare/v1.28.2...v1.35.24) -- github.com/blang/semver: [v3.5.0+incompatible → v3.5.1+incompatible](https://github.com/blang/semver/compare/v3.5.0...v3.5.1) -- github.com/checkpoint-restore/go-criu/v4: [v4.0.2 → v4.1.0](https://github.com/checkpoint-restore/go-criu/v4/compare/v4.0.2...v4.1.0) -- github.com/containerd/containerd: [v1.3.3 → v1.4.1](https://github.com/containerd/containerd/compare/v1.3.3...v1.4.1) -- github.com/containerd/ttrpc: [v1.0.0 → v1.0.2](https://github.com/containerd/ttrpc/compare/v1.0.0...v1.0.2) -- github.com/containerd/typeurl: [v1.0.0 → v1.0.1](https://github.com/containerd/typeurl/compare/v1.0.0...v1.0.1) -- github.com/coreos/etcd: [v3.3.10+incompatible → v3.3.13+incompatible](https://github.com/coreos/etcd/compare/v3.3.10...v3.3.13) -- github.com/docker/docker: [aa6a989 → bd33bbf](https://github.com/docker/docker/compare/aa6a989...bd33bbf) -- github.com/go-gl/glfw/v3.3/glfw: [12ad95a → 6f7a984](https://github.com/go-gl/glfw/v3.3/glfw/compare/12ad95a...6f7a984) -- github.com/golang/groupcache: [215e871 → 8c9f03a](https://github.com/golang/groupcache/compare/215e871...8c9f03a) -- github.com/golang/mock: [v1.3.1 → v1.4.1](https://github.com/golang/mock/compare/v1.3.1...v1.4.1) -- github.com/golang/protobuf: [v1.4.2 → v1.4.3](https://github.com/golang/protobuf/compare/v1.4.2...v1.4.3) -- github.com/google/cadvisor: [v0.37.0 → v0.38.5](https://github.com/google/cadvisor/compare/v0.37.0...v0.38.5) -- github.com/google/go-cmp: [v0.4.0 → v0.5.2](https://github.com/google/go-cmp/compare/v0.4.0...v0.5.2) -- github.com/google/pprof: [d4f498a → 1ebb73c](https://github.com/google/pprof/compare/d4f498a...1ebb73c) -- github.com/google/uuid: [v1.1.1 → v1.1.2](https://github.com/google/uuid/compare/v1.1.1...v1.1.2) -- github.com/gorilla/mux: [v1.7.3 → v1.8.0](https://github.com/gorilla/mux/compare/v1.7.3...v1.8.0) -- github.com/gorilla/websocket: [v1.4.0 → v1.4.2](https://github.com/gorilla/websocket/compare/v1.4.0...v1.4.2) -- github.com/jmespath/go-jmespath: [c2b33e8 → v0.4.0](https://github.com/jmespath/go-jmespath/compare/c2b33e8...v0.4.0) -- github.com/karrick/godirwalk: [v1.7.5 → v1.16.1](https://github.com/karrick/godirwalk/compare/v1.7.5...v1.16.1) -- github.com/opencontainers/go-digest: [v1.0.0-rc1 → v1.0.0](https://github.com/opencontainers/go-digest/compare/v1.0.0-rc1...v1.0.0) -- github.com/opencontainers/runc: [819fcc6 → v1.0.0-rc92](https://github.com/opencontainers/runc/compare/819fcc6...v1.0.0-rc92) -- github.com/opencontainers/runtime-spec: [237cc4f → 4d89ac9](https://github.com/opencontainers/runtime-spec/compare/237cc4f...4d89ac9) -- github.com/opencontainers/selinux: [v1.5.2 → v1.6.0](https://github.com/opencontainers/selinux/compare/v1.5.2...v1.6.0) -- github.com/prometheus/procfs: [v0.1.3 → v0.2.0](https://github.com/prometheus/procfs/compare/v0.1.3...v0.2.0) -- github.com/quobyte/api: [v0.1.2 → v0.1.8](https://github.com/quobyte/api/compare/v0.1.2...v0.1.8) -- github.com/spf13/cobra: [v1.0.0 → v1.1.1](https://github.com/spf13/cobra/compare/v1.0.0...v1.1.1) -- github.com/spf13/viper: [v1.4.0 → v1.7.0](https://github.com/spf13/viper/compare/v1.4.0...v1.7.0) -- github.com/storageos/go-api: [343b3ef → v2.2.0+incompatible](https://github.com/storageos/go-api/compare/343b3ef...v2.2.0) -- github.com/stretchr/testify: [v1.4.0 → v1.6.1](https://github.com/stretchr/testify/compare/v1.4.0...v1.6.1) -- github.com/vishvananda/netns: [52d707b → db3c7e5](https://github.com/vishvananda/netns/compare/52d707b...db3c7e5) -- go.etcd.io/etcd: 17cef6e → dd1b699 -- go.opencensus.io: v0.22.2 → v0.22.3 -- golang.org/x/crypto: 75b2880 → 7f63de1 -- golang.org/x/exp: da58074 → 6cc2880 -- golang.org/x/lint: fdd1cda → 738671d -- golang.org/x/net: ab34263 → 69a7880 -- golang.org/x/oauth2: 858c2ad → bf48bf1 -- golang.org/x/sys: ed371f2 → 5cba982 -- golang.org/x/text: v0.3.3 → v0.3.4 -- golang.org/x/time: 555d28b → 3af7569 -- golang.org/x/xerrors: 9bdfabe → 5ec99f8 -- google.golang.org/api: v0.15.1 → v0.20.0 -- google.golang.org/genproto: cb27e3a → 8816d57 -- google.golang.org/grpc: v1.27.0 → v1.27.1 -- google.golang.org/protobuf: v1.24.0 → v1.25.0 -- honnef.co/go/tools: v0.0.1-2019.2.3 → v0.0.1-2020.1.3 -- k8s.io/gengo: 8167cfd → 83324d8 -- k8s.io/klog/v2: v2.2.0 → v2.4.0 -- k8s.io/kube-openapi: 6aeccd4 → d219536 -- k8s.io/system-validators: v1.1.2 → v1.2.0 -- k8s.io/utils: d5654de → 67b214c -- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.9 → v0.0.14 -- sigs.k8s.io/structured-merge-diff/v4: v4.0.1 → v4.0.2 - -### 제거 -- github.com/armon/consul-api: [eb2c6b5](https://github.com/armon/consul-api/tree/eb2c6b5) -- github.com/go-ini/ini: [v1.9.0](https://github.com/go-ini/ini/tree/v1.9.0) -- github.com/ugorji/go: [v1.1.4](https://github.com/ugorji/go/tree/v1.1.4) -- github.com/xlab/handysort: [fb3537e](https://github.com/xlab/handysort/tree/fb3537e) -- github.com/xordataexchange/crypt: [b2862e3](https://github.com/xordataexchange/crypt/tree/b2862e3) -- vbom.ml/util: db5cfe1 - - - -# v1.20.0-rc.0 - - -## Downloads for v1.20.0-rc.0 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes.tar.gz) | acfee8658831f9503fccda0904798405434f17be7064a361a9f34c6ed04f1c0f685e79ca40cef5fcf34e3193bacbf467665e8dc277e0562ebdc929170034b5ae -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-src.tar.gz) | 9d962f8845e1fa221649cf0c0e178f0f03808486c49ea15ab5ec67861ec5aa948cf18bc0ee9b2067643c8332227973dd592e6a4457456a9d9d80e8ef28d5f7c3 - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-darwin-amd64.tar.gz) | 062b57f1a450fe01d6184f104d81d376bdf5720010412821e315fd9b1b622a400ac91f996540daa66cee172006f3efade4eccc19265494f1a1d7cc9450f0b50a -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-linux-386.tar.gz) | 86e96d2c2046c5e62e02bef30a6643f25e01f1b3eba256cab7dd61252908540c26cb058490e9cecc5a9bad97d2b577f5968884e9f1a90237e302419f39e068bc -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-linux-amd64.tar.gz) | 619d3afb9ce902368390e71633396010e88e87c5fd848e3adc71571d1d4a25be002588415e5f83afee82460f8a7c9e0bd968335277cb8f8cb51e58d4bb43e64e -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-linux-arm.tar.gz) | 60965150a60ab3d05a248339786e0c7da4b89a04539c3719737b13d71302bac1dd9bcaa427d8a1f84a7b42d0c67801dce2de0005e9e47d21122868b32ac3d40f -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-linux-arm64.tar.gz) | 688e064f4ef6a17189dbb5af468c279b9de35e215c40500fb97b1d46692d222747023f9e07a7f7ba006400f9532a8912e69d7c5143f956b1dadca144c67ee711 -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-linux-ppc64le.tar.gz) | 47b8abc02b42b3b1de67da184921b5801d7e3cb09befac840c85913193fc5ac4e5e3ecfcb57da6b686ff21af9a3bd42ae6949d4744dbe6ad976794340e328b83 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-linux-s390x.tar.gz) | 971b41d3169f30e6c412e0254c180636abb7ccc8dcee6641b0e9877b69752fc61aa30b76c19c108969df654fe385da3cb3a44dd59d3c28dc45561392d7e08874 -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-windows-386.tar.gz) | 2d34e8387e31531d9aca5655f2f0d18e75b01825dc1c39b7beb73a7b7b610e2ba429e5ca97d5c41a71b67e75e7096c86ab63fda9baab4c0878c1ccb3a1aefac8 -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-client-windows-amd64.tar.gz) | f909640f4140693bb871936f10a40e79b43502105d0adb318b35bb7a64a770ad9d05a3a732368ccd3d15d496d75454789165bd1f5c2571da9a00569b3e6c007c - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-server-linux-amd64.tar.gz) | 0ea4458ae34108c633b4d48f1f128c6274dbc82b613492e78b3e0a2f656ac0df0bb9a75124e15d67c8e81850adcecf19f4ab0234c17247ee7ddf84f2df3e5eaa -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-server-linux-arm.tar.gz) | aef6a4d457faa29936603370f29a8523bb274211c3cb5101bd31aaf469c91ba6bd149ea99a4ccdd83352cf37e4d6508c5ee475ec10292bccd2f77ceea31e1c28 -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-server-linux-arm64.tar.gz) | 4829f473e9d60f9929ad17c70fdc2b6b6509ed75418be0b23a75b28580949736cb5b0bd6382070f93aa0a2a8863f0b1596daf965186ca749996c29d03ef7d8b8 -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-server-linux-ppc64le.tar.gz) | 9ab0790d382a3e28df1c013762c09da0085449cfd09d176d80be932806c24a715ea829be0075c3e221a2ad9cf06e726b4c39ab41987c1fb0fee2563e48206763 -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-server-linux-s390x.tar.gz) | 98670b587e299856dd9821b7517a35f9a65835b915b153de08b66c54d82160438b66f774bf5306c07bc956d70ff709860bc23162225da5e89f995d3fdc1f0122 - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-node-linux-amd64.tar.gz) | 699e9c8d1837198312eade8eb6fec390f6a2fea9e08207d2f58e8bb6e3e799028aca69e4670aac0a4ba7cf0af683aee2c158bf78cc520c80edc876c8d94d521a -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-node-linux-arm.tar.gz) | f3b5eab0669490e3cd7e802693daf3555d08323dfff6e73a881fce00fed4690e8bdaf1610278d9de74036ca37631016075e5695a02158b7d3e7582b20ef7fa35 -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-node-linux-arm64.tar.gz) | e5012f77363561a609aaf791baaa17d09009819c4085a57132e5feb5366275a54640094e6ed1cba527f42b586c6d62999c2a5435edf5665ff0e114db4423c2ae -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-node-linux-ppc64le.tar.gz) | 2a6d6501620b1a9838dff05c66a40260cc22154a28027813346eb16e18c386bc3865298a46a0f08da71cd55149c5e7d07c4c4c431b4fd231486dd9d716548adb -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-node-linux-s390x.tar.gz) | 5eca02777519e31428a1e5842fe540b813fb8c929c341bbc71dcfd60d98deb89060f8f37352e8977020e21e053379eead6478eb2d54ced66fb9d38d5f3142bf0 -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-rc.0/kubernetes-node-windows-amd64.tar.gz) | 8ace02e7623dff894e863a2e0fa7dfb916368431d1723170713fe82e334c0ae0481b370855b71e2561de0fb64fed124281be604761ec08607230b66fb9ed1c03 - -## Changelog since v1.20.0-beta.2 - -## Changes by Kind - -### Feature - -- Kubernetes is now built using go1.15.5 - - build: Update to k/repo-infra@v0.1.2 (supports go1.15.5) ([#95776](https://github.com/kubernetes/kubernetes/pull/95776), [@justaugustus](https://github.com/justaugustus)) [SIG Cloud Provider, Instrumentation, Release and Testing] - -### Failing Test - -- Resolves an issue running Ingress conformance tests on clusters which use finalizers on Ingress objects to manage releasing load balancer resources ([#96742](https://github.com/kubernetes/kubernetes/pull/96742), [@spencerhance](https://github.com/spencerhance)) [SIG Network and Testing] -- The Conformance test "validates that there is no conflict between pods with same hostPort but different hostIP and protocol" now validates the connectivity to each hostPort, in addition to the functionality. ([#96627](https://github.com/kubernetes/kubernetes/pull/96627), [@aojea](https://github.com/aojea)) [SIG Scheduling and Testing] - -### Bug or Regression - -- Bump node-problem-detector version to v0.8.5 to fix OOM detection in with Linux kernels 5.1+ ([#96716](https://github.com/kubernetes/kubernetes/pull/96716), [@tosi3k](https://github.com/tosi3k)) [SIG Cloud Provider, Scalability and Testing] -- Changes to timeout parameter handling in 1.20.0-beta.2 have been reverted to avoid breaking backwards compatibility with existing clients. ([#96727](https://github.com/kubernetes/kubernetes/pull/96727), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Testing] -- Duplicate owner reference entries in create/update/patch requests now get deduplicated by the API server. The client sending the request now receives a warning header in the API response. Clients should stop sending requests with duplicate owner references. The API server may reject such requests as early as 1.24. ([#96185](https://github.com/kubernetes/kubernetes/pull/96185), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery and Testing] -- Fix: resize Azure disk issue when it's in attached state ([#96705](https://github.com/kubernetes/kubernetes/pull/96705), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fixed a bug where aggregator_unavailable_apiservice metrics were reported for deleted apiservices. ([#96421](https://github.com/kubernetes/kubernetes/pull/96421), [@dgrisonnet](https://github.com/dgrisonnet)) [SIG API Machinery and Instrumentation] -- Fixes code generation for non-namespaced create subresources fake client test. ([#96586](https://github.com/kubernetes/kubernetes/pull/96586), [@Doude](https://github.com/Doude)) [SIG API Machinery] -- HTTP/2 connection health check is enabled by default in all Kubernetes clients. The feature should work out-of-the-box. If needed, users can tune the feature via the HTTP2_READ_IDLE_TIMEOUT_SECONDS and HTTP2_PING_TIMEOUT_SECONDS environment variables. The feature is disabled if HTTP2_READ_IDLE_TIMEOUT_SECONDS is set to 0. ([#95981](https://github.com/kubernetes/kubernetes/pull/95981), [@caesarxuchao](https://github.com/caesarxuchao)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node] -- Kubeadm: fix coredns migration should be triggered when there are newdefault configs during kubeadm upgrade ([#96907](https://github.com/kubernetes/kubernetes/pull/96907), [@pacoxu](https://github.com/pacoxu)) [SIG Cluster Lifecycle] -- Reduce volume name length for vsphere volumes ([#96533](https://github.com/kubernetes/kubernetes/pull/96533), [@gnufied](https://github.com/gnufied)) [SIG Storage] -- Resolves a regression in 1.19+ with workloads targeting deprecated beta os/arch labels getting stuck in NodeAffinity status on node startup. ([#96810](https://github.com/kubernetes/kubernetes/pull/96810), [@liggitt](https://github.com/liggitt)) [SIG Node] - -## Dependencies - -### Added -_Nothing has changed._ - -### Changed -- github.com/google/cadvisor: [v0.38.4 → v0.38.5](https://github.com/google/cadvisor/compare/v0.38.4...v0.38.5) - -### Removed -_Nothing has changed._ - - - -# v1.20.0-beta.2 - - -## Downloads for v1.20.0-beta.2 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes.tar.gz) | fe769280aa623802a949b6a35fbddadbba1d6f9933a54132a35625683719595ecf58096a9aa0f7456f8d4931774df21bfa98e148bc3d85913f1da915134f77bd -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-src.tar.gz) | ce1c8d97c52e5189af335d673bd7e99c564816f6adebf249838f7e3f0e920f323b4e398a5d163ea767091497012ec38843c59ff14e6fdd07683b682135eed645 - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-darwin-amd64.tar.gz) | d6c14bd0f6702f4bbdf14a6abdfa4e5936de5b4efee38aa86c2bd7272967ec6d7868b88fc00ad4a7c3a20717a35e6be2b84e56dec04154fd702315f641409f7c -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-linux-386.tar.gz) | b923c44cb0acb91a8f6fd442c2168aa6166c848f5d037ce50a7cb11502be3698db65836b373c916f75b648d6ac8d9158807a050eecc4e1c77cffa25b386c8cdb -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-linux-amd64.tar.gz) | 8cae14146a9034dcd4e9d69d5d700f195a77aac35f629a148960ae028ed8b4fe12213993fe3e6e464b4b3e111adebe6f3dd7ca0accc70c738ed5cfd8993edd7c -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-linux-arm.tar.gz) | 1f54e5262a0432945ead57fcb924e6bfedd9ea76db1dd9ebd946787a2923c247cf16e10505307b47e365905a1b398678dac5af0f433c439c158a33e08362d97b -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-linux-arm64.tar.gz) | 31cf79c01e4878a231b4881fe3ed5ef790bd5fb5419388438d3f8c6a2129e655aba9e00b8e1d77e0bc5d05ecc75cf4ae02cf8266788822d0306c49c85ee584ed -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-linux-ppc64le.tar.gz) | 2527948c40be2e16724d939316ad5363f15aa22ebf42d59359d8b6f757d30cfef6447434cc93bc5caa5a23a6a00a2da8d8191b6441e06bba469d9d4375989a97 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-linux-s390x.tar.gz) | b777ad764b3a46651ecb0846e5b7f860bb2c1c4bd4d0fcc468c6ccffb7d3b8dcb6dcdd73b13c16ded7219f91bba9f1e92f9258527fd3bb162b54d7901ac303ff -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-windows-386.tar.gz) | 8a2f58aaab01be9fe298e4d01456536047cbdd39a37d3e325c1f69ceab3a0504998be41a9f41a894735dfc4ed22bed02591eea5f3c75ce12d9e95ba134e72ec5 -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-client-windows-amd64.tar.gz) | 2f69cda177a178df149f5de66b7dba7f5ce14c1ffeb7c8d7dc4130c701b47d89bb2fbe74e7a262f573e4d21dee2c92414d050d7829e7c6fc3637a9d6b0b9c5c1 - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-server-linux-amd64.tar.gz) | 3ecaac0213d369eab691ac55376821a80df5013cb12e1263f18d1c236a9e49d42b3cea422175556d8f929cdf3109b22c0b6212ac0f2e80cc7a5f4afa3aba5f24 -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-server-linux-arm.tar.gz) | 580030b57ff207e177208fec0801a43389cae10cc2c9306327d354e7be6a055390184531d54b6742e0983550b7a76693cc4a705c2d2f4ac30495cf63cef26b9b -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-server-linux-arm64.tar.gz) | 3e3286bd54671549fbef0dfdaaf1da99bc5c3efb32cc8d1e1985d9926520cea0c43bcf7cbcbbc8b1c1a95eab961255693008af3bb1ba743362998b5f0017d6d7 -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-server-linux-ppc64le.tar.gz) | 9fa051e7e97648e97e26b09ab6d26be247b41b1a5938d2189204c9e6688e455afe76612bbcdd994ed5692935d0d960bd96dc222bce4b83f61d62557752b9d75b -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-server-linux-s390x.tar.gz) | fa85d432eff586f30975c95664ac130b9f5ae02dc52b97613ed7a41324496631ea11d1a267daba564cf2485a9e49707814d86bbd3175486c7efc8b58a9314af5 - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-node-linux-amd64.tar.gz) | 86e631f95fe670b467ead2b88d34e0364eaa275935af433d27cc378d82dcaa22041ccce40f5fa9561b9656dadaa578dc018ad458a59b1690d35f86dca4776b5c -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-node-linux-arm.tar.gz) | a8754ff58a0e902397056b8615ab49af07aca347ba7cc4a812c238e3812234862270f25106b6a94753b157bb153b8eae8b39a01ed67384774d798598c243583b -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-node-linux-arm64.tar.gz) | 28d727d7d08e2c856c9b4a574ef2dbf9e37236a0555f7ec5258b4284fa0582fb94b06783aaf50bf661f7503d101fbd70808aba6de02a2f0af94db7d065d25947 -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-node-linux-ppc64le.tar.gz) | a1283449f1a0b155c11449275e9371add544d0bdd4609d6dc737ed5f7dd228e84e24ff249613a2a153691627368dd894ad64f4e6c0010eecc6efd2c13d4fb133 -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-node-linux-s390x.tar.gz) | 5806028ba15a6a9c54a34f90117bc3181428dbb0e7ced30874c9f4a953ea5a0e9b2c73e6b1e2545e1b4e5253e9c7691588538b44cdfa666ce6865964b92d2fa8 -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.2/kubernetes-node-windows-amd64.tar.gz) | d5327e3b7916c78777b9b69ba0f3758c3a8645c67af80114a0ae52babd7af27bb504febbaf51b1bfe5bd2d74c8c5c573471e1cb449f2429453f4b1be9d5e682a - -## Changelog since v1.20.0-beta.1 - -## Urgent Upgrade Notes - -### (No, really, you MUST read this before you upgrade) - - - A bug was fixed in kubelet where exec probe timeouts were not respected. Ensure that pods relying on this behavior are updated to correctly handle probe timeouts. - - This change in behavior may be unexpected for some clusters and can be disabled by turning off the ExecProbeTimeout feature gate. This gate will be locked and removed in future releases so that exec probe timeouts are always respected. ([#94115](https://github.com/kubernetes/kubernetes/pull/94115), [@andrewsykim](https://github.com/andrewsykim)) [SIG Node and Testing] - - For CSI drivers, kubelet no longer creates the target_path for NodePublishVolume in accordance with the CSI spec. Kubelet also no longer checks if staging and target paths are mounts or corrupted. CSI drivers need to be idempotent and do any necessary mount verification. ([#88759](https://github.com/kubernetes/kubernetes/pull/88759), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage] - - Kubeadm: - - The label applied to control-plane nodes "node-role.kubernetes.io/master" is now deprecated and will be removed in a future release after a GA deprecation period. - - Introduce a new label "node-role.kubernetes.io/control-plane" that will be applied in parallel to "node-role.kubernetes.io/master" until the removal of the "node-role.kubernetes.io/master" label. - - Make "kubeadm upgrade apply" add the "node-role.kubernetes.io/control-plane" label on existing nodes that only have the "node-role.kubernetes.io/master" label during upgrade. - - Please adapt your tooling built on top of kubeadm to use the "node-role.kubernetes.io/control-plane" label. - - - The taint applied to control-plane nodes "node-role.kubernetes.io/master:NoSchedule" is now deprecated and will be removed in a future release after a GA deprecation period. - - Apply toleration for a new, future taint "node-role.kubernetes.io/control-plane:NoSchedule" to the kubeadm CoreDNS / kube-dns managed manifests. Note that this taint is not yet applied to kubeadm control-plane nodes. - - Please adapt your workloads to tolerate the same future taint preemptively. - - For more details see: http://git.k8s.io/enhancements/keps/sig-cluster-lifecycle/kubeadm/2067-rename-master-label-taint/README.md ([#95382](https://github.com/kubernetes/kubernetes/pull/95382), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] - -## Changes by Kind - -### Deprecation - -- Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. ([#94624](https://github.com/kubernetes/kubernetes/pull/94624), [@dims](https://github.com/dims)) [SIG Node] -- Kubectl: deprecate --delete-local-data ([#95076](https://github.com/kubernetes/kubernetes/pull/95076), [@dougsland](https://github.com/dougsland)) [SIG CLI, Cloud Provider and Scalability] - -### API Change - -- API priority and fairness graduated to beta - 1.19 servers with APF turned on should not be run in a multi-server cluster with 1.20+ servers. ([#96527](https://github.com/kubernetes/kubernetes/pull/96527), [@adtac](https://github.com/adtac)) [SIG API Machinery and Testing] -- Add LoadBalancerIPMode feature gate ([#92312](https://github.com/kubernetes/kubernetes/pull/92312), [@Sh4d1](https://github.com/Sh4d1)) [SIG Apps, CLI, Cloud Provider and Network] -- Add WindowsContainerResources and Annotations to CRI-API UpdateContainerResourcesRequest ([#95741](https://github.com/kubernetes/kubernetes/pull/95741), [@katiewasnothere](https://github.com/katiewasnothere)) [SIG Node] -- Add a 'serving' and `terminating` condition to the EndpointSlice API. - - `serving` tracks the readiness of endpoints regardless of their terminating state. This is distinct from `ready` since `ready` is only true when pods are not terminating. - `terminating` is true when an endpoint is terminating. For pods this is any endpoint with a deletion timestamp. ([#92968](https://github.com/kubernetes/kubernetes/pull/92968), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps and Network] -- Add support for hugepages to downward API ([#86102](https://github.com/kubernetes/kubernetes/pull/86102), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG API Machinery, Apps, CLI, Network, Node, Scheduling and Testing] -- Adds kubelet alpha feature, `GracefulNodeShutdown` which makes kubelet aware of node system shutdowns and result in graceful termination of pods during a system shutdown. ([#96129](https://github.com/kubernetes/kubernetes/pull/96129), [@bobbypage](https://github.com/bobbypage)) [SIG Node] -- AppProtocol is now GA for Endpoints and Services. The ServiceAppProtocol feature gate will be deprecated in 1.21. ([#96327](https://github.com/kubernetes/kubernetes/pull/96327), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- Automatic allocation of NodePorts for services with type LoadBalancer can now be disabled by setting the (new) parameter - Service.spec.allocateLoadBalancerNodePorts=false. The default is to allocate NodePorts for services with type LoadBalancer which is the existing behavior. ([#92744](https://github.com/kubernetes/kubernetes/pull/92744), [@uablrek](https://github.com/uablrek)) [SIG Apps and Network] -- Document that ServiceTopology feature is required to use `service.spec.topologyKeys`. ([#96528](https://github.com/kubernetes/kubernetes/pull/96528), [@andrewsykim](https://github.com/andrewsykim)) [SIG Apps] -- EndpointSlice has a new NodeName field guarded by the EndpointSliceNodeName feature gate. - - EndpointSlice topology field will be deprecated in an upcoming release. - - EndpointSlice "IP" address type is formally removed after being deprecated in Kubernetes 1.17. - - The discovery.k8s.io/v1alpha1 API is deprecated and will be removed in Kubernetes 1.21. ([#96440](https://github.com/kubernetes/kubernetes/pull/96440), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps and Network] -- Fewer candidates are enumerated for preemption to improve performance in large clusters ([#94814](https://github.com/kubernetes/kubernetes/pull/94814), [@adtac](https://github.com/adtac)) [SIG Scheduling] -- If BoundServiceAccountTokenVolume is enabled, cluster admins can use metric `serviceaccount_stale_tokens_total` to monitor workloads that are depending on the extended tokens. If there are no such workloads, turn off extended tokens by starting `kube-apiserver` with flag `--service-account-extend-token-expiration=false` ([#96273](https://github.com/kubernetes/kubernetes/pull/96273), [@zshihang](https://github.com/zshihang)) [SIG API Machinery and Auth] -- Introduce alpha support for exec-based container registry credential provider plugins in the kubelet. ([#94196](https://github.com/kubernetes/kubernetes/pull/94196), [@andrewsykim](https://github.com/andrewsykim)) [SIG Node and Release] -- Kube-apiserver now deletes expired kube-apiserver Lease objects: - - The feature is under feature gate `APIServerIdentity`. - - A flag is added to kube-apiserver: `identity-lease-garbage-collection-check-period-seconds` ([#95895](https://github.com/kubernetes/kubernetes/pull/95895), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery, Apps, Auth and Testing] -- Move configurable fsgroup change policy for pods to beta ([#96376](https://github.com/kubernetes/kubernetes/pull/96376), [@gnufied](https://github.com/gnufied)) [SIG Apps and Storage] -- New flag is introduced, i.e. --topology-manager-scope=container|pod. - The default value is the "container" scope. ([#92967](https://github.com/kubernetes/kubernetes/pull/92967), [@cezaryzukowski](https://github.com/cezaryzukowski)) [SIG Instrumentation, Node and Testing] -- NodeAffinity plugin can be configured with AddedAffinity. ([#96202](https://github.com/kubernetes/kubernetes/pull/96202), [@alculquicondor](https://github.com/alculquicondor)) [SIG Node, Scheduling and Testing] -- Promote RuntimeClass feature to GA. - Promote node.k8s.io API groups from v1beta1 to v1. ([#95718](https://github.com/kubernetes/kubernetes/pull/95718), [@SergeyKanzhelev](https://github.com/SergeyKanzhelev)) [SIG Apps, Auth, Node, Scheduling and Testing] -- Reminder: The labels "failure-domain.beta.kubernetes.io/zone" and "failure-domain.beta.kubernetes.io/region" are deprecated in favor of "topology.kubernetes.io/zone" and "topology.kubernetes.io/region" respectively. All users of the "failure-domain.beta..." labels should switch to the "topology..." equivalents. ([#96033](https://github.com/kubernetes/kubernetes/pull/96033), [@thockin](https://github.com/thockin)) [SIG API Machinery, Apps, CLI, Cloud Provider, Network, Node, Scheduling, Storage and Testing] -- The usage of mixed protocol values in the same LoadBalancer Service is possible if the new feature gate MixedProtocolLBSVC is enabled. - "action required" - The feature gate is disabled by default. The user has to enable it for the API Server. ([#94028](https://github.com/kubernetes/kubernetes/pull/94028), [@janosi](https://github.com/janosi)) [SIG API Machinery and Apps] -- This PR will introduce a feature gate CSIServiceAccountToken with two additional fields in `CSIDriverSpec`. ([#93130](https://github.com/kubernetes/kubernetes/pull/93130), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Apps, Auth, CLI, Network, Node, Storage and Testing] -- Users can try the cronjob controller v2 using the feature gate. This will be the default controller in future releases. ([#93370](https://github.com/kubernetes/kubernetes/pull/93370), [@alaypatel07](https://github.com/alaypatel07)) [SIG API Machinery, Apps, Auth and Testing] -- VolumeSnapshotDataSource moves to GA in 1.20 release ([#95282](https://github.com/kubernetes/kubernetes/pull/95282), [@xing-yang](https://github.com/xing-yang)) [SIG Apps] - -### Feature - -- **Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.**: ([#95896](https://github.com/kubernetes/kubernetes/pull/95896), [@zshihang](https://github.com/zshihang)) [SIG API Machinery and Cluster Lifecycle] -- A new set of alpha metrics are reported by the Kubernetes scheduler under the `/metrics/resources` endpoint that allow administrators to easily see the resource consumption (requests and limits for all resources on the pods) and compare it to actual pod usage or node capacity. ([#94866](https://github.com/kubernetes/kubernetes/pull/94866), [@smarterclayton](https://github.com/smarterclayton)) [SIG API Machinery, Instrumentation, Node and Scheduling] -- Add --experimental-logging-sanitization flag enabling runtime protection from leaking sensitive data in logs ([#96370](https://github.com/kubernetes/kubernetes/pull/96370), [@serathius](https://github.com/serathius)) [SIG API Machinery, Cluster Lifecycle and Instrumentation] -- Add a StorageVersionAPI feature gate that makes API server update storageversions before serving certain write requests. - This feature allows the storage migrator to manage storage migration for built-in resources. - Enabling internal.apiserver.k8s.io/v1alpha1 API and APIServerIdentity feature gate are required to use this feature. ([#93873](https://github.com/kubernetes/kubernetes/pull/93873), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery, Auth and Testing] -- Add a new `vSphere` metric: `cloudprovider_vsphere_vcenter_versions`. It's content show `vCenter` hostnames with the associated server version. ([#94526](https://github.com/kubernetes/kubernetes/pull/94526), [@Danil-Grigorev](https://github.com/Danil-Grigorev)) [SIG Cloud Provider and Instrumentation] -- Add feature to size memory backed volumes ([#94444](https://github.com/kubernetes/kubernetes/pull/94444), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG Storage and Testing] -- Add node_authorizer_actions_duration_seconds metric that can be used to estimate load to node authorizer. ([#92466](https://github.com/kubernetes/kubernetes/pull/92466), [@mborsz](https://github.com/mborsz)) [SIG API Machinery, Auth and Instrumentation] -- Add pod_ based CPU and memory metrics to Kubelet's /metrics/resource endpoint ([#95839](https://github.com/kubernetes/kubernetes/pull/95839), [@egernst](https://github.com/egernst)) [SIG Instrumentation, Node and Testing] -- Adds a headless service on node-local-cache addon. ([#88412](https://github.com/kubernetes/kubernetes/pull/88412), [@stafot](https://github.com/stafot)) [SIG Cloud Provider and Network] -- CRDs: For structural schemas, non-nullable null map fields will now be dropped and defaulted if a default is available. null items in list will continue being preserved, and fail validation if not nullable. ([#95423](https://github.com/kubernetes/kubernetes/pull/95423), [@apelisse](https://github.com/apelisse)) [SIG API Machinery] -- E2e test for PodFsGroupChangePolicy ([#96247](https://github.com/kubernetes/kubernetes/pull/96247), [@saikat-royc](https://github.com/saikat-royc)) [SIG Storage and Testing] -- Gradudate the Pod Resources API to G.A - Introduces the pod_resources_endpoint_requests_total metric which tracks the total number of requests to the pod resources API ([#92165](https://github.com/kubernetes/kubernetes/pull/92165), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Instrumentation, Node and Testing] -- Introduce api-extensions category which will return: mutating admission configs, validating admission configs, CRDs and APIServices when used in kubectl get, for example. ([#95603](https://github.com/kubernetes/kubernetes/pull/95603), [@soltysh](https://github.com/soltysh)) [SIG API Machinery] -- Kube-apiserver now maintains a Lease object to identify itself: - - The feature is under feature gate `APIServerIdentity`. - - Two flags are added to kube-apiserver: `identity-lease-duration-seconds`, `identity-lease-renew-interval-seconds` ([#95533](https://github.com/kubernetes/kubernetes/pull/95533), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery] -- Kube-apiserver: The timeout used when making health check calls to etcd can now be configured with `--etcd-healthcheck-timeout`. The default timeout is 2 seconds, matching the previous behavior. ([#93244](https://github.com/kubernetes/kubernetes/pull/93244), [@Sh4d1](https://github.com/Sh4d1)) [SIG API Machinery] -- Kubectl: Previously users cannot provide arguments to a external diff tool via KUBECTL_EXTERNAL_DIFF env. This release now allow users to specify args to KUBECTL_EXTERNAL_DIFF env. ([#95292](https://github.com/kubernetes/kubernetes/pull/95292), [@dougsland](https://github.com/dougsland)) [SIG CLI] -- Scheduler now ignores Pod update events if the resourceVersion of old and new Pods are identical. ([#96071](https://github.com/kubernetes/kubernetes/pull/96071), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling] -- Support custom tags for cloud provider managed resources ([#96450](https://github.com/kubernetes/kubernetes/pull/96450), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Support customize load balancer health probe protocol and request path ([#96338](https://github.com/kubernetes/kubernetes/pull/96338), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Support multiple standard load balancers in one cluster ([#96111](https://github.com/kubernetes/kubernetes/pull/96111), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- The beta `RootCAConfigMap` feature gate is enabled by default and causes kube-controller-manager to publish a "kube-root-ca.crt" ConfigMap to every namespace. This ConfigMap contains a CA bundle used for verifying connections to the kube-apiserver. ([#96197](https://github.com/kubernetes/kubernetes/pull/96197), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Apps, Auth and Testing] -- The kubelet_runtime_operations_duration_seconds metric got additional buckets of 60, 300, 600, 900 and 1200 seconds ([#96054](https://github.com/kubernetes/kubernetes/pull/96054), [@alvaroaleman](https://github.com/alvaroaleman)) [SIG Instrumentation and Node] -- There is a new pv_collector_total_pv_count metric that counts persistent volumes by the volume plugin name and volume mode. ([#95719](https://github.com/kubernetes/kubernetes/pull/95719), [@tsmetana](https://github.com/tsmetana)) [SIG Apps, Instrumentation, Storage and Testing] -- Volume snapshot e2e test to validate PVC and VolumeSnapshotContent finalizer ([#95863](https://github.com/kubernetes/kubernetes/pull/95863), [@RaunakShah](https://github.com/RaunakShah)) [SIG Cloud Provider, Storage and Testing] -- Warns user when executing kubectl apply/diff to resource currently being deleted. ([#95544](https://github.com/kubernetes/kubernetes/pull/95544), [@SaiHarshaK](https://github.com/SaiHarshaK)) [SIG CLI] -- `kubectl alpha debug` has graduated to beta and is now `kubectl debug`. ([#96138](https://github.com/kubernetes/kubernetes/pull/96138), [@verb](https://github.com/verb)) [SIG CLI and Testing] -- `kubectl debug` gains support for changing container images when copying a pod for debugging, similar to how `kubectl set image` works. See `kubectl help debug` for more information. ([#96058](https://github.com/kubernetes/kubernetes/pull/96058), [@verb](https://github.com/verb)) [SIG CLI] - -### Documentation - -- Updates docs and guidance on cloud provider InstancesV2 and Zones interface for external cloud providers: - - removes experimental warning for InstancesV2 - - document that implementation of InstancesV2 will disable calls to Zones - - deprecate Zones in favor of InstancesV2 ([#96397](https://github.com/kubernetes/kubernetes/pull/96397), [@andrewsykim](https://github.com/andrewsykim)) [SIG Cloud Provider] - -### Bug or Regression - -- Change plugin name in fsgroupapplymetrics of csi and flexvolume to distinguish different driver ([#95892](https://github.com/kubernetes/kubernetes/pull/95892), [@JornShen](https://github.com/JornShen)) [SIG Instrumentation, Storage and Testing] -- Clear UDP conntrack entry on endpoint changes when using nodeport ([#71573](https://github.com/kubernetes/kubernetes/pull/71573), [@JacobTanenbaum](https://github.com/JacobTanenbaum)) [SIG Network] -- Exposes and sets a default timeout for the TokenReview client for DelegatingAuthenticationOptions ([#96217](https://github.com/kubernetes/kubernetes/pull/96217), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery and Cloud Provider] -- Fix CVE-2020-8555 for Quobyte client connections. ([#95206](https://github.com/kubernetes/kubernetes/pull/95206), [@misterikkit](https://github.com/misterikkit)) [SIG Storage] -- Fix IP fragmentation of UDP and TCP packets not supported issues on LoadBalancer rules ([#96464](https://github.com/kubernetes/kubernetes/pull/96464), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Fix a bug that DefaultPreemption plugin is disabled when using (legacy) scheduler policy. ([#96439](https://github.com/kubernetes/kubernetes/pull/96439), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling and Testing] -- Fix bug in JSON path parser where an error occurs when a range is empty ([#95933](https://github.com/kubernetes/kubernetes/pull/95933), [@brianpursley](https://github.com/brianpursley)) [SIG API Machinery] -- Fix client-go prometheus metrics to correctly present the API path accessed in some environments. ([#74363](https://github.com/kubernetes/kubernetes/pull/74363), [@aanm](https://github.com/aanm)) [SIG API Machinery] -- Fix memory leak in kube-apiserver when underlying time goes forth and back. ([#96266](https://github.com/kubernetes/kubernetes/pull/96266), [@chenyw1990](https://github.com/chenyw1990)) [SIG API Machinery] -- Fix paging issues when Azure API returns empty values with non-empty nextLink ([#96211](https://github.com/kubernetes/kubernetes/pull/96211), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Fix pull image error from multiple ACRs using azure managed identity ([#96355](https://github.com/kubernetes/kubernetes/pull/96355), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix vSphere volumes that could be erroneously attached to wrong node ([#96224](https://github.com/kubernetes/kubernetes/pull/96224), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage] -- Fixed a bug that prevents kubectl to validate CRDs with schema using x-kubernetes-preserve-unknown-fields on object fields. ([#96369](https://github.com/kubernetes/kubernetes/pull/96369), [@gautierdelorme](https://github.com/gautierdelorme)) [SIG API Machinery and Testing] -- For vSphere Cloud Provider, If VM of worker node is deleted, the node will also be deleted by node controller ([#92608](https://github.com/kubernetes/kubernetes/pull/92608), [@lubronzhan](https://github.com/lubronzhan)) [SIG Cloud Provider] -- HTTP/2 connection health check is enabled by default in all Kubernetes clients. The feature should work out-of-the-box. If needed, users can tune the feature via the HTTP2_READ_IDLE_TIMEOUT_SECONDS and HTTP2_PING_TIMEOUT_SECONDS environment variables. The feature is disabled if HTTP2_READ_IDLE_TIMEOUT_SECONDS is set to 0. ([#95981](https://github.com/kubernetes/kubernetes/pull/95981), [@caesarxuchao](https://github.com/caesarxuchao)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node] -- If the user specifies an invalid timeout in the request URL, the request will be aborted with an HTTP 400. - - If the user specifies a timeout in the request URL that exceeds the maximum request deadline allowed by the apiserver, the request will be aborted with an HTTP 400. ([#96061](https://github.com/kubernetes/kubernetes/pull/96061), [@tkashem](https://github.com/tkashem)) [SIG API Machinery, Network and Testing] -- Improve error messages related to nodePort endpoint changes conntrack entries cleanup. ([#96251](https://github.com/kubernetes/kubernetes/pull/96251), [@ravens](https://github.com/ravens)) [SIG Network] -- Print go stack traces at -v=4 and not -v=2 ([#94663](https://github.com/kubernetes/kubernetes/pull/94663), [@soltysh](https://github.com/soltysh)) [SIG CLI] -- Remove ready file and its directory (which is created during volume SetUp) during emptyDir volume TearDown. ([#95770](https://github.com/kubernetes/kubernetes/pull/95770), [@jingxu97](https://github.com/jingxu97)) [SIG Storage] -- Resolves non-deterministic behavior of the garbage collection controller when ownerReferences with incorrect data are encountered. Events with a reason of `OwnerRefInvalidNamespace` are recorded when namespace mismatches between child and owner objects are detected. - - A namespaced object with an ownerReference referencing a uid of a namespaced kind which does not exist in the same namespace is now consistently treated as though that owner does not exist, and the child object is deleted. - - A cluster-scoped object with an ownerReference referencing a uid of a namespaced kind is now consistently treated as though that owner is not resolvable, and the child object is ignored by the garbage collector. ([#92743](https://github.com/kubernetes/kubernetes/pull/92743), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Testing] -- Skip [k8s.io/kubernetes@v1.19.0/test/e2e/storage/testsuites/base.go:162]: Driver azure-disk doesn't support snapshot type DynamicSnapshot -- skipping - skip [k8s.io/kubernetes@v1.19.0/test/e2e/storage/testsuites/base.go:185]: Driver azure-disk doesn't support ntfs -- skipping ([#96144](https://github.com/kubernetes/kubernetes/pull/96144), [@qinpingli](https://github.com/qinpingli)) [SIG Storage and Testing] -- The AWS network load balancer attributes can now be specified during service creation ([#95247](https://github.com/kubernetes/kubernetes/pull/95247), [@kishorj](https://github.com/kishorj)) [SIG Cloud Provider] -- The kube-apiserver will no longer serve APIs that should have been deleted in GA non-alpha levels. Alpha levels will continue to serve the removed APIs so that CI doesn't immediately break. ([#96525](https://github.com/kubernetes/kubernetes/pull/96525), [@deads2k](https://github.com/deads2k)) [SIG API Machinery] -- Update max azure data disk count map ([#96308](https://github.com/kubernetes/kubernetes/pull/96308), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Update the route table tag in the route reconcile loop ([#96545](https://github.com/kubernetes/kubernetes/pull/96545), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Volume binding: report UnschedulableAndUnresolvable status instead of an error when bound PVs not found ([#95541](https://github.com/kubernetes/kubernetes/pull/95541), [@cofyc](https://github.com/cofyc)) [SIG Apps, Scheduling and Storage] -- [kubectl] Fail when local source file doesn't exist ([#90333](https://github.com/kubernetes/kubernetes/pull/90333), [@bamarni](https://github.com/bamarni)) [SIG CLI] - -### Other (Cleanup or Flake) - -- Handle slow cronjob lister in cronjob controller v2 and improve memory footprint. ([#96443](https://github.com/kubernetes/kubernetes/pull/96443), [@alaypatel07](https://github.com/alaypatel07)) [SIG Apps] -- --redirect-container-streaming is no longer functional. The flag will be removed in v1.22 ([#95935](https://github.com/kubernetes/kubernetes/pull/95935), [@tallclair](https://github.com/tallclair)) [SIG Node] -- A new metric `requestAbortsTotal` has been introduced that counts aborted requests for each `group`, `version`, `verb`, `resource`, `subresource` and `scope`. ([#95002](https://github.com/kubernetes/kubernetes/pull/95002), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery, Cloud Provider, Instrumentation and Scheduling] -- API priority and fairness metrics use snake_case in label names ([#96236](https://github.com/kubernetes/kubernetes/pull/96236), [@adtac](https://github.com/adtac)) [SIG API Machinery, Cluster Lifecycle, Instrumentation and Testing] -- Applies translations on all command descriptions ([#95439](https://github.com/kubernetes/kubernetes/pull/95439), [@HerrNaN](https://github.com/HerrNaN)) [SIG CLI] -- Changed: default "Accept-Encoding" header removed from HTTP probes. See https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#http-probes ([#96127](https://github.com/kubernetes/kubernetes/pull/96127), [@fonsecas72](https://github.com/fonsecas72)) [SIG Network and Node] -- Generators for services are removed from kubectl ([#95256](https://github.com/kubernetes/kubernetes/pull/95256), [@Git-Jiro](https://github.com/Git-Jiro)) [SIG CLI] -- Introduce kubectl-convert plugin. ([#96190](https://github.com/kubernetes/kubernetes/pull/96190), [@soltysh](https://github.com/soltysh)) [SIG CLI and Testing] -- Kube-scheduler now logs processed component config at startup ([#96426](https://github.com/kubernetes/kubernetes/pull/96426), [@damemi](https://github.com/damemi)) [SIG Scheduling] -- NONE ([#96179](https://github.com/kubernetes/kubernetes/pull/96179), [@bbyrne5](https://github.com/bbyrne5)) [SIG Network] -- Users will now be able to configure all supported values for AWS NLB health check interval and thresholds for new resources. ([#96312](https://github.com/kubernetes/kubernetes/pull/96312), [@kishorj](https://github.com/kishorj)) [SIG Cloud Provider] - -## Dependencies - -### Added -- cloud.google.com/go/firestore: v1.1.0 -- github.com/armon/go-metrics: [f0300d1](https://github.com/armon/go-metrics/tree/f0300d1) -- github.com/armon/go-radix: [7fddfc3](https://github.com/armon/go-radix/tree/7fddfc3) -- github.com/bketelsen/crypt: [5cbc8cc](https://github.com/bketelsen/crypt/tree/5cbc8cc) -- github.com/hashicorp/consul/api: [v1.1.0](https://github.com/hashicorp/consul/api/tree/v1.1.0) -- github.com/hashicorp/consul/sdk: [v0.1.1](https://github.com/hashicorp/consul/sdk/tree/v0.1.1) -- github.com/hashicorp/errwrap: [v1.0.0](https://github.com/hashicorp/errwrap/tree/v1.0.0) -- github.com/hashicorp/go-cleanhttp: [v0.5.1](https://github.com/hashicorp/go-cleanhttp/tree/v0.5.1) -- github.com/hashicorp/go-immutable-radix: [v1.0.0](https://github.com/hashicorp/go-immutable-radix/tree/v1.0.0) -- github.com/hashicorp/go-msgpack: [v0.5.3](https://github.com/hashicorp/go-msgpack/tree/v0.5.3) -- github.com/hashicorp/go-multierror: [v1.0.0](https://github.com/hashicorp/go-multierror/tree/v1.0.0) -- github.com/hashicorp/go-rootcerts: [v1.0.0](https://github.com/hashicorp/go-rootcerts/tree/v1.0.0) -- github.com/hashicorp/go-sockaddr: [v1.0.0](https://github.com/hashicorp/go-sockaddr/tree/v1.0.0) -- github.com/hashicorp/go-uuid: [v1.0.1](https://github.com/hashicorp/go-uuid/tree/v1.0.1) -- github.com/hashicorp/go.net: [v0.0.1](https://github.com/hashicorp/go.net/tree/v0.0.1) -- github.com/hashicorp/logutils: [v1.0.0](https://github.com/hashicorp/logutils/tree/v1.0.0) -- github.com/hashicorp/mdns: [v1.0.0](https://github.com/hashicorp/mdns/tree/v1.0.0) -- github.com/hashicorp/memberlist: [v0.1.3](https://github.com/hashicorp/memberlist/tree/v0.1.3) -- github.com/hashicorp/serf: [v0.8.2](https://github.com/hashicorp/serf/tree/v0.8.2) -- github.com/mitchellh/cli: [v1.0.0](https://github.com/mitchellh/cli/tree/v1.0.0) -- github.com/mitchellh/go-testing-interface: [v1.0.0](https://github.com/mitchellh/go-testing-interface/tree/v1.0.0) -- github.com/mitchellh/gox: [v0.4.0](https://github.com/mitchellh/gox/tree/v0.4.0) -- github.com/mitchellh/iochan: [v1.0.0](https://github.com/mitchellh/iochan/tree/v1.0.0) -- github.com/pascaldekloe/goe: [57f6aae](https://github.com/pascaldekloe/goe/tree/57f6aae) -- github.com/posener/complete: [v1.1.1](https://github.com/posener/complete/tree/v1.1.1) -- github.com/ryanuber/columnize: [9b3edd6](https://github.com/ryanuber/columnize/tree/9b3edd6) -- github.com/sean-/seed: [e2103e2](https://github.com/sean-/seed/tree/e2103e2) -- github.com/subosito/gotenv: [v1.2.0](https://github.com/subosito/gotenv/tree/v1.2.0) -- github.com/willf/bitset: [d5bec33](https://github.com/willf/bitset/tree/d5bec33) -- gopkg.in/ini.v1: v1.51.0 -- gopkg.in/yaml.v3: 9f266ea -- rsc.io/quote/v3: v3.1.0 -- rsc.io/sampler: v1.3.0 - -### Changed -- cloud.google.com/go/bigquery: v1.0.1 → v1.4.0 -- cloud.google.com/go/datastore: v1.0.0 → v1.1.0 -- cloud.google.com/go/pubsub: v1.0.1 → v1.2.0 -- cloud.google.com/go/storage: v1.0.0 → v1.6.0 -- cloud.google.com/go: v0.51.0 → v0.54.0 -- github.com/Microsoft/go-winio: [fc70bd9 → v0.4.15](https://github.com/Microsoft/go-winio/compare/fc70bd9...v0.4.15) -- github.com/aws/aws-sdk-go: [v1.35.5 → v1.35.24](https://github.com/aws/aws-sdk-go/compare/v1.35.5...v1.35.24) -- github.com/blang/semver: [v3.5.0+incompatible → v3.5.1+incompatible](https://github.com/blang/semver/compare/v3.5.0...v3.5.1) -- github.com/checkpoint-restore/go-criu/v4: [v4.0.2 → v4.1.0](https://github.com/checkpoint-restore/go-criu/v4/compare/v4.0.2...v4.1.0) -- github.com/containerd/containerd: [v1.3.3 → v1.4.1](https://github.com/containerd/containerd/compare/v1.3.3...v1.4.1) -- github.com/containerd/ttrpc: [v1.0.0 → v1.0.2](https://github.com/containerd/ttrpc/compare/v1.0.0...v1.0.2) -- github.com/containerd/typeurl: [v1.0.0 → v1.0.1](https://github.com/containerd/typeurl/compare/v1.0.0...v1.0.1) -- github.com/coreos/etcd: [v3.3.10+incompatible → v3.3.13+incompatible](https://github.com/coreos/etcd/compare/v3.3.10...v3.3.13) -- github.com/docker/docker: [aa6a989 → bd33bbf](https://github.com/docker/docker/compare/aa6a989...bd33bbf) -- github.com/go-gl/glfw/v3.3/glfw: [12ad95a → 6f7a984](https://github.com/go-gl/glfw/v3.3/glfw/compare/12ad95a...6f7a984) -- github.com/golang/groupcache: [215e871 → 8c9f03a](https://github.com/golang/groupcache/compare/215e871...8c9f03a) -- github.com/golang/mock: [v1.3.1 → v1.4.1](https://github.com/golang/mock/compare/v1.3.1...v1.4.1) -- github.com/golang/protobuf: [v1.4.2 → v1.4.3](https://github.com/golang/protobuf/compare/v1.4.2...v1.4.3) -- github.com/google/cadvisor: [v0.37.0 → v0.38.4](https://github.com/google/cadvisor/compare/v0.37.0...v0.38.4) -- github.com/google/go-cmp: [v0.4.0 → v0.5.2](https://github.com/google/go-cmp/compare/v0.4.0...v0.5.2) -- github.com/google/pprof: [d4f498a → 1ebb73c](https://github.com/google/pprof/compare/d4f498a...1ebb73c) -- github.com/google/uuid: [v1.1.1 → v1.1.2](https://github.com/google/uuid/compare/v1.1.1...v1.1.2) -- github.com/gorilla/mux: [v1.7.3 → v1.8.0](https://github.com/gorilla/mux/compare/v1.7.3...v1.8.0) -- github.com/gorilla/websocket: [v1.4.0 → v1.4.2](https://github.com/gorilla/websocket/compare/v1.4.0...v1.4.2) -- github.com/karrick/godirwalk: [v1.7.5 → v1.16.1](https://github.com/karrick/godirwalk/compare/v1.7.5...v1.16.1) -- github.com/opencontainers/runc: [819fcc6 → v1.0.0-rc92](https://github.com/opencontainers/runc/compare/819fcc6...v1.0.0-rc92) -- github.com/opencontainers/runtime-spec: [237cc4f → 4d89ac9](https://github.com/opencontainers/runtime-spec/compare/237cc4f...4d89ac9) -- github.com/opencontainers/selinux: [v1.5.2 → v1.6.0](https://github.com/opencontainers/selinux/compare/v1.5.2...v1.6.0) -- github.com/prometheus/procfs: [v0.1.3 → v0.2.0](https://github.com/prometheus/procfs/compare/v0.1.3...v0.2.0) -- github.com/quobyte/api: [v0.1.2 → v0.1.8](https://github.com/quobyte/api/compare/v0.1.2...v0.1.8) -- github.com/spf13/cobra: [v1.0.0 → v1.1.1](https://github.com/spf13/cobra/compare/v1.0.0...v1.1.1) -- github.com/spf13/viper: [v1.4.0 → v1.7.0](https://github.com/spf13/viper/compare/v1.4.0...v1.7.0) -- github.com/stretchr/testify: [v1.4.0 → v1.6.1](https://github.com/stretchr/testify/compare/v1.4.0...v1.6.1) -- github.com/vishvananda/netns: [52d707b → db3c7e5](https://github.com/vishvananda/netns/compare/52d707b...db3c7e5) -- go.opencensus.io: v0.22.2 → v0.22.3 -- golang.org/x/exp: da58074 → 6cc2880 -- golang.org/x/lint: fdd1cda → 738671d -- golang.org/x/net: ab34263 → 69a7880 -- golang.org/x/oauth2: 858c2ad → bf48bf1 -- golang.org/x/sys: ed371f2 → 5cba982 -- golang.org/x/text: v0.3.3 → v0.3.4 -- golang.org/x/time: 555d28b → 3af7569 -- golang.org/x/xerrors: 9bdfabe → 5ec99f8 -- google.golang.org/api: v0.15.1 → v0.20.0 -- google.golang.org/genproto: cb27e3a → 8816d57 -- google.golang.org/grpc: v1.27.0 → v1.27.1 -- google.golang.org/protobuf: v1.24.0 → v1.25.0 -- honnef.co/go/tools: v0.0.1-2019.2.3 → v0.0.1-2020.1.3 -- k8s.io/gengo: 8167cfd → 83324d8 -- k8s.io/klog/v2: v2.2.0 → v2.4.0 -- k8s.io/kube-openapi: 8b50664 → d219536 -- k8s.io/utils: d5654de → 67b214c -- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.12 → v0.0.14 -- sigs.k8s.io/structured-merge-diff/v4: b3cf1e8 → v4.0.2 - -### Removed -- github.com/armon/consul-api: [eb2c6b5](https://github.com/armon/consul-api/tree/eb2c6b5) -- github.com/go-ini/ini: [v1.9.0](https://github.com/go-ini/ini/tree/v1.9.0) -- github.com/ugorji/go: [v1.1.4](https://github.com/ugorji/go/tree/v1.1.4) -- github.com/xordataexchange/crypt: [b2862e3](https://github.com/xordataexchange/crypt/tree/b2862e3) - - - -# v1.20.0-beta.1 - - -## Downloads for v1.20.0-beta.1 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes.tar.gz) | 4eddf4850c2d57751696f352d0667309339090aeb30ff93e8db8a22c6cdebf74cb2d5dc78d4ae384c4e25491efc39413e2e420a804b76b421a9ad934e56b0667 -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-src.tar.gz) | 59de5221162e9b6d88f5abbdb99765cb2b2e501498ea853fb65f2abe390211e28d9f21e0d87be3ade550a5ea6395d04552cf093d2ce2f99fd45ad46545dd13cb - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-darwin-amd64.tar.gz) | d69ffed19b034a4221fc084e43ac293cf392e98febf5bf580f8d92307a8421d8b3aab18f9ca70608937e836b42c7a34e829f88eba6e040218a4486986e2fca21 -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-linux-386.tar.gz) | 1b542e165860c4adcd4550adc19b86c3db8cd75d2a1b8db17becc752da78b730ee48f1b0aaf8068d7bfbb1d8e023741ec293543bc3dd0f4037172a6917db8169 -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-linux-amd64.tar.gz) | 90ad52785eecb43a6f9035b92b6ba39fc84e67f8bc91cf098e70f8cfdd405c4b9d5c02dccb21022f21bb5b6ce92fdef304def1da0a7255c308e2c5fb3a9cdaab -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-linux-arm.tar.gz) | d0cb3322b056e1821679afa70728ffc0d3375e8f3326dabbe8185be2e60f665ab8985b13a1a432e10281b84a929e0f036960253ac0dd6e0b44677d539e98e61b -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-linux-arm64.tar.gz) | 3aecc8197e0aa368408624add28a2dd5e73f0d8a48e5e33c19edf91d5323071d16a27353a6f3e22df4f66ed7bfbae8e56e0a9050f7bbdf927ce6aeb29bba6374 -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-linux-ppc64le.tar.gz) | 6ff145058f62d478b98f1e418e272555bfb5c7861834fbbf10a8fb334cc7ff09b32f2666a54b230932ba71d2fc7d3b1c1f5e99e6fe6d6ec83926a9b931cd2474 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-linux-s390x.tar.gz) | ff7b8bb894076e05a3524f6327a4a6353b990466f3292e84c92826cb64b5c82b3855f48b8e297ccadc8bcc15552bc056419ff6ff8725fc4e640828af9cc1331b -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-windows-386.tar.gz) | 6c6dcac9c725605763a130b5a975f2b560aa976a5c809d4e0887900701b707baccb9ca1aebc10a03cfa7338a6f42922bbf838ccf6800fc2a3e231686a72568b6 -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-client-windows-amd64.tar.gz) | d12e3a29c960f0ddd1b9aabf5426ac1259863ac6c8f2be1736ebeb57ddca6b1c747ee2c363be19e059e38cf71488c5ea3509ad4d0e67fd5087282a5ad0ae9a48 - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-server-linux-amd64.tar.gz) | 904e8c049179e071c6caa65f525f465260bb4d4318a6dd9cc05be2172f39f7cfc69d1672736e01d926045764fe8872e806444e3af77ffef823ede769537b7d20 -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-server-linux-arm.tar.gz) | 5934959374868aed8d4294de84411972660bca7b2e952201a9403f37e40c60a5c53eaea8001344d0bf4a00c8cd27de6324d88161388de27f263a5761357cb82b -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-server-linux-arm64.tar.gz) | 4c884585970f80dc5462d9a734d7d5be9558b36c6e326a8a3139423efbd7284fa9f53fb077983647e17e19f03f5cb9bf26201450c78daecf10afa5a1ab5f9efc -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-server-linux-ppc64le.tar.gz) | 235b78b08440350dcb9f13b63f7722bd090c672d8e724ca5d409256e5a5d4f46d431652a1aa908c3affc5b1e162318471de443d38b93286113e79e7f90501a9b -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-server-linux-s390x.tar.gz) | 220fc9351702b3ecdcf79089892ceb26753a8a1deaf46922ffb3d3b62b999c93fef89440e779ca6043372b963081891b3a966d1a5df0cf261bdd44395fd28dce - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-node-linux-amd64.tar.gz) | fe59d3a1f21c47bab126f689687657f77fbcb46a2caeef48eecd073b2b22879f997a466911b5c5c829e9cf27e68a36ecdf18686d42714839d4b97d6c7281578d -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-node-linux-arm.tar.gz) | 93e545aa963cfd11e0b2c6d47669b5ef70c5a86ef80c3353c1a074396bff1e8e7371dda25c39d78c7a9e761f2607b8b5ab843fa0c10b8ff9663098fae8d25725 -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-node-linux-arm64.tar.gz) | 5e0f177f9bec406a668d4b37e69b191208551fdf289c82b5ec898959da4f8a00a2b0695cbf1d2de5acb809321c6e5604f5483d33556543d92b96dcf80e814dd3 -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-node-linux-ppc64le.tar.gz) | 574412059e4d257eb904cd4892a075b6a2cde27adfa4976ee64c46d6768facece338475f1b652ad94c8df7cfcbb70ebdf0113be109c7099ab76ffdb6f023eefd -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-node-linux-s390x.tar.gz) | b1ffaa6d7f77d89885c642663cb14a86f3e2ec2afd223e3bb2000962758cf0f15320969ffc4be93b5826ff22d54fdbae0dbea09f9d8228eda6da50b6fdc88758 -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.1/kubernetes-node-windows-amd64.tar.gz) | 388983765213cf3bdc1f8b27103ed79e39028767e5f1571e35ed1f91ed100e49f3027f7b7ff19b53fab7fbb6d723c0439f21fc6ed62be64532c25f5bfa7ee265 - -## Changelog since v1.20.0-beta.0 - -## Changes by Kind - -### Deprecation - -- ACTION REQUIRED: The kube-apiserver ability to serve on an insecure port, deprecated since v1.10, has been removed. The insecure address flags `--address` and `--insecure-bind-address` have no effect in kube-apiserver and will be removed in v1.24. The insecure port flags `--port` and `--insecure-port` may only be set to 0 and will be removed in v1.24. ([#95856](https://github.com/kubernetes/kubernetes/pull/95856), [@knight42](https://github.com/knight42)) [SIG API Machinery, Node and Testing] - -### API Change - -- + `TokenRequest` and `TokenRequestProjection` features have been promoted to GA. This feature allows generating service account tokens that are not visible in Secret objects and are tied to the lifetime of a Pod object. See https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection for details on configuring and using this feature. The `TokenRequest` and `TokenRequestProjection` feature gates will be removed in v1.21. - + kubeadm's kube-apiserver Pod manifest now includes the following flags by default "--service-account-key-file", "--service-account-signing-key-file", "--service-account-issuer". ([#93258](https://github.com/kubernetes/kubernetes/pull/93258), [@zshihang](https://github.com/zshihang)) [SIG API Machinery, Auth, Cluster Lifecycle, Storage and Testing] -- Certain fields on Service objects will be automatically cleared when changing the service's `type` to a mode that does not need those fields. For example, changing from type=LoadBalancer to type=ClusterIP will clear the NodePort assignments, rather than forcing the user to clear them. ([#95196](https://github.com/kubernetes/kubernetes/pull/95196), [@thockin](https://github.com/thockin)) [SIG API Machinery, Apps, Network and Testing] -- Services will now have a `clusterIPs` field to go with `clusterIP`. `clusterIPs[0]` is a synonym for `clusterIP` and will be syncronized on create and update operations. ([#95894](https://github.com/kubernetes/kubernetes/pull/95894), [@thockin](https://github.com/thockin)) [SIG Network] - -### Feature - -- A new metric `apiserver_request_filter_duration_seconds` has been introduced that - measures request filter latency in seconds. ([#95207](https://github.com/kubernetes/kubernetes/pull/95207), [@tkashem](https://github.com/tkashem)) [SIG API Machinery and Instrumentation] -- Add a new flag to set priority for the kubelet on Windows nodes so that workloads cannot overwhelm the node there by disrupting kubelet process. ([#96051](https://github.com/kubernetes/kubernetes/pull/96051), [@ravisantoshgudimetla](https://github.com/ravisantoshgudimetla)) [SIG Node and Windows] -- Changed: default "Accept: */*" header added to HTTP probes. See https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#http-probes (https://github.com/kubernetes/website/pull/24756) ([#95641](https://github.com/kubernetes/kubernetes/pull/95641), [@fonsecas72](https://github.com/fonsecas72)) [SIG Network and Node] -- Client-go credential plugins can now be passed in the current cluster information via the KUBERNETES_EXEC_INFO environment variable. ([#95489](https://github.com/kubernetes/kubernetes/pull/95489), [@ankeesler](https://github.com/ankeesler)) [SIG API Machinery and Auth] -- Kube-apiserver: added support for compressing rotated audit log files with `--audit-log-compress` ([#94066](https://github.com/kubernetes/kubernetes/pull/94066), [@lojies](https://github.com/lojies)) [SIG API Machinery and Auth] - -### Documentation - -- Fake dynamic client: document that List does not preserve TypeMeta in UnstructuredList ([#95117](https://github.com/kubernetes/kubernetes/pull/95117), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery] - -### Bug or Regression - -- Added support to kube-proxy for externalTrafficPolicy=Local setting via Direct Server Return (DSR) load balancers on Windows. ([#93166](https://github.com/kubernetes/kubernetes/pull/93166), [@elweb9858](https://github.com/elweb9858)) [SIG Network] -- Disable watchcache for events ([#96052](https://github.com/kubernetes/kubernetes/pull/96052), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery] -- Disabled `LocalStorageCapacityIsolation` feature gate is honored during scheduling. ([#96092](https://github.com/kubernetes/kubernetes/pull/96092), [@Huang-Wei](https://github.com/Huang-Wei)) [SIG Scheduling] -- Fix bug in JSON path parser where an error occurs when a range is empty ([#95933](https://github.com/kubernetes/kubernetes/pull/95933), [@brianpursley](https://github.com/brianpursley)) [SIG API Machinery] -- Fix k8s.io/apimachinery/pkg/api/meta.SetStatusCondition to update ObservedGeneration ([#95961](https://github.com/kubernetes/kubernetes/pull/95961), [@KnicKnic](https://github.com/KnicKnic)) [SIG API Machinery] -- Fixed a regression which prevented pods with `docker/default` seccomp annotations from being created in 1.19 if a PodSecurityPolicy was in place which did not allow `runtime/default` seccomp profiles. ([#95985](https://github.com/kubernetes/kubernetes/pull/95985), [@saschagrunert](https://github.com/saschagrunert)) [SIG Auth] -- Kubectl: print error if users place flags before plugin name ([#92343](https://github.com/kubernetes/kubernetes/pull/92343), [@knight42](https://github.com/knight42)) [SIG CLI] -- When creating a PVC with the volume.beta.kubernetes.io/storage-provisioner annotation already set, the PV controller might have incorrectly deleted the newly provisioned PV instead of binding it to the PVC, depending on timing and system load. ([#95909](https://github.com/kubernetes/kubernetes/pull/95909), [@pohly](https://github.com/pohly)) [SIG Apps and Storage] - -### Other (Cleanup or Flake) - -- Kubectl: the `generator` flag of `kubectl autoscale` has been deprecated and has no effect, it will be removed in a feature release ([#92998](https://github.com/kubernetes/kubernetes/pull/92998), [@SataQiu](https://github.com/SataQiu)) [SIG CLI] -- V1helpers.MatchNodeSelectorTerms now accepts just a Node and a list of Terms ([#95871](https://github.com/kubernetes/kubernetes/pull/95871), [@damemi](https://github.com/damemi)) [SIG Apps, Scheduling and Storage] -- `MatchNodeSelectorTerms` function moved to `k8s.io/component-helpers` ([#95531](https://github.com/kubernetes/kubernetes/pull/95531), [@damemi](https://github.com/damemi)) [SIG Apps, Scheduling and Storage] - -## Dependencies - -### Added -_Nothing has changed._ - -### Changed -_Nothing has changed._ - -### Removed -_Nothing has changed._ - - - -# v1.20.0-beta.0 - - -## Downloads for v1.20.0-beta.0 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes.tar.gz) | 385e49e32bbd6996f07bcadbf42285755b8a8ef9826ee1ba42bd82c65827cf13f63e5634b834451b263a93b708299cbb4b4b0b8ddbc688433deaf6bec240aa67 -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-src.tar.gz) | 842e80f6dcad461426fb699de8a55fde8621d76a94e54288fe9939cc1a3bbd0f4799abadac2c59bcf3f91d743726dbd17e1755312ae7fec482ef560f336dbcbb - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-darwin-amd64.tar.gz) | bde5e7d9ee3e79d1e69465a3ddb4bb36819a4f281b5c01a7976816d7c784410812dde133cdf941c47e5434e9520701b9c5e8b94d61dca77c172f87488dfaeb26 -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-linux-386.tar.gz) | 721bb8444c9e0d7a9f8461e3f5428882d76fcb3def6eb11b8e8e08fae7f7383630699248660d69d4f6a774124d6437888666e1fa81298d5b5518bc4a6a6b2c92 -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-linux-amd64.tar.gz) | 71e4edc41afbd65f813e7ecbc22b27c95f248446f005e288d758138dc4cc708735be7218af51bcf15e8b9893a3598c45d6a685f605b46f50af3762b02c32ed76 -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-linux-arm.tar.gz) | bbefc749156f63898973f2f7c7a6f1467481329fb430d641fe659b497e64d679886482d557ebdddb95932b93de8d1e3e365c91d4bf9f110b68bd94b0ba702ded -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-linux-arm64.tar.gz) | 9803190685058b4b64d002c2fbfb313308bcea4734ed53a8c340cfdae4894d8cb13b3e819ae64051bafe0fbf8b6ecab53a6c1dcf661c57640c75b0eb60041113 -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-linux-ppc64le.tar.gz) | bcdceea64cba1ae38ea2bab50d8fd77c53f6d673de12566050b0e3c204334610e6c19e4ace763e68b5e48ab9e811521208b852b1741627be30a2b17324fc1daf -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-linux-s390x.tar.gz) | 41e36d00867e90012d5d5adfabfaae8d9f5a9fd32f290811e3c368e11822916b973afaaf43961081197f2cbab234090d97d89774e674aeadc1da61f7a64708a9 -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-windows-386.tar.gz) | c50fec5aec2d0e742f851f25c236cb73e76f8fc73b0908049a10ae736c0205b8fff83eb3d29b1748412edd942da00dd738195d9003f25b577d6af8359d84fb2f -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-client-windows-amd64.tar.gz) | 0fd6777c349908b6d627e849ea2d34c048b8de41f7df8a19898623f597e6debd35b7bcbf8e1d43a1be3a9abb45e4810bc498a0963cf780b109e93211659e9c7e - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-server-linux-amd64.tar.gz) | 30d982424ca64bf0923503ae8195b2e2a59497096b2d9e58dfd491cd6639633027acfa9750bc7bccf34e1dc116d29d2f87cbd7ae713db4210ce9ac16182f0576 -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-server-linux-arm.tar.gz) | f08b62be9bc6f0745f820b0083c7a31eedb2ce370a037c768459a59192107b944c8f4345d0bb88fc975f2e7a803ac692c9ac3e16d4a659249d4600e84ff75d9e -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-server-linux-arm64.tar.gz) | e3472b5b3dfae0a56e5363d52062b1e4a9fc227a05e0cf5ece38233b2c442f427970aab94a52377fb87e583663c120760d154bc1c4ac22dca1f4d0d1ebb96088 -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-server-linux-ppc64le.tar.gz) | 06c254e0a62f755d31bc40093d86c44974f0a60308716cc3214a6b3c249a4d74534d909b82f8a3dd3a3c9720e61465b45d2bb3a327ef85d3caba865750020dfb -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-server-linux-s390x.tar.gz) | 2edeb4411c26a0de057a66787091ab1044f71774a464aed898ffee26634a40127181c2edddb38e786b6757cca878fd0c3a885880eec6c3448b93c645770abb12 - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-node-linux-amd64.tar.gz) | cc1d5b94b86070b5e7746d7aaeaeac3b3a5e5ebbff1ec33885f7eeab270a6177d593cb1975b2e56f4430b7859ad42da76f266629f9313e0f688571691ac448ed -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-node-linux-arm.tar.gz) | 75e82c7c9122add3b24695b94dcb0723c52420c3956abf47511e37785aa48a1fa8257db090c6601010c4475a325ccfff13eb3352b65e3aa1774f104b09b766b0 -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-node-linux-arm64.tar.gz) | 16ef27c40bf4d678a55fcd3d3f7d09f1597eec2cc58f9950946f0901e52b82287be397ad7f65e8d162d8a9cdb4a34a610b6db8b5d0462be8e27c4b6eb5d6e5e7 -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-node-linux-ppc64le.tar.gz) | 939865f2c4cb6a8934f22a06223e416dec5f768ffc1010314586149470420a1d62aef97527c34d8a636621c9669d6489908ce1caf96f109e8d073cee1c030b50 -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-node-linux-s390x.tar.gz) | bbfdd844075fb816079af7b73d99bc1a78f41717cdbadb043f6f5872b4dc47bc619f7f95e2680d4b516146db492c630c17424e36879edb45e40c91bc2ae4493c -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-beta.0/kubernetes-node-windows-amd64.tar.gz) | a2b3ea40086fd71aed71a4858fd3fc79fd1907bc9ea8048ff3c82ec56477b0a791b724e5a52d79b3b36338c7fbd93dfd3d03b00ccea9042bda0d270fc891e4ec - -## Changelog since v1.20.0-alpha.3 - -## Urgent Upgrade Notes - -### (No, really, you MUST read this before you upgrade) - - - Kubeadm: improve the validation of serviceSubnet and podSubnet. - ServiceSubnet has to be limited in size, due to implementation details, and the mask can not allocate more than 20 bits. - PodSubnet validates against the corresponding cluster "--node-cidr-mask-size" of the kube-controller-manager, it fail if the values are not compatible. - kubeadm no longer sets the node-mask automatically on IPv6 deployments, you must check that your IPv6 service subnet mask is compatible with the default node mask /64 or set it accordenly. - Previously, for IPv6, if the podSubnet had a mask lower than /112, kubeadm calculated a node-mask to be multiple of eight and splitting the available bits to maximise the number used for nodes. ([#95723](https://github.com/kubernetes/kubernetes/pull/95723), [@aojea](https://github.com/aojea)) [SIG Cluster Lifecycle] - - Windows hyper-v container featuregate is deprecated in 1.20 and will be removed in 1.21 ([#95505](https://github.com/kubernetes/kubernetes/pull/95505), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] - -## Changes by Kind - -### Deprecation - -- Support 'controlplane' as a valid EgressSelection type in the EgressSelectorConfiguration API. 'Master' is deprecated and will be removed in v1.22. ([#95235](https://github.com/kubernetes/kubernetes/pull/95235), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery] - -### API Change - -- Add dual-stack Services (alpha). This is a BREAKING CHANGE to an alpha API. - It changes the dual-stack API wrt Service from a single ipFamily field to 3 - fields: ipFamilyPolicy (SingleStack, PreferDualStack, RequireDualStack), - ipFamilies (a list of families assigned), and clusterIPs (inclusive of - clusterIP). Most users do not need to set anything at all, defaulting will - handle it for them. Services are single-stack unless the user asks for - dual-stack. This is all gated by the "IPv6DualStack" feature gate. ([#91824](https://github.com/kubernetes/kubernetes/pull/91824), [@khenidak](https://github.com/khenidak)) [SIG API Machinery, Apps, CLI, Network, Node, Scheduling and Testing] -- Introduces a metric source for HPAs which allows scaling based on container resource usage. ([#90691](https://github.com/kubernetes/kubernetes/pull/90691), [@arjunrn](https://github.com/arjunrn)) [SIG API Machinery, Apps, Autoscaling and CLI] - -### Feature - -- Add a metric for time taken to perform recursive permission change ([#95866](https://github.com/kubernetes/kubernetes/pull/95866), [@JornShen](https://github.com/JornShen)) [SIG Instrumentation and Storage] -- Allow cross compilation of kubernetes on different platforms. ([#94403](https://github.com/kubernetes/kubernetes/pull/94403), [@bnrjee](https://github.com/bnrjee)) [SIG Release] -- Command to start network proxy changes from 'KUBE_ENABLE_EGRESS_VIA_KONNECTIVITY_SERVICE ./cluster/kube-up.sh' to 'KUBE_ENABLE_KONNECTIVITY_SERVICE=true ./hack/kube-up.sh' ([#92669](https://github.com/kubernetes/kubernetes/pull/92669), [@Jefftree](https://github.com/Jefftree)) [SIG Cloud Provider] -- DefaultPodTopologySpread graduated to Beta. The feature gate is enabled by default. ([#95631](https://github.com/kubernetes/kubernetes/pull/95631), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling and Testing] -- Kubernetes E2E test image manifest lists now contain Windows images. ([#77398](https://github.com/kubernetes/kubernetes/pull/77398), [@claudiubelu](https://github.com/claudiubelu)) [SIG Testing and Windows] -- Support for Windows container images (OS Versions: 1809, 1903, 1909, 2004) was added the pause:3.4 image. ([#91452](https://github.com/kubernetes/kubernetes/pull/91452), [@claudiubelu](https://github.com/claudiubelu)) [SIG Node, Release and Windows] - -### Documentation - -- Fake dynamic client: document that List does not preserve TypeMeta in UnstructuredList ([#95117](https://github.com/kubernetes/kubernetes/pull/95117), [@andrewsykim](https://github.com/andrewsykim)) [SIG API Machinery] - -### Bug or Regression - -- Exposes and sets a default timeout for the SubjectAccessReview client for DelegatingAuthorizationOptions. ([#95725](https://github.com/kubernetes/kubernetes/pull/95725), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery and Cloud Provider] -- Alter wording to describe pods using a pvc ([#95635](https://github.com/kubernetes/kubernetes/pull/95635), [@RaunakShah](https://github.com/RaunakShah)) [SIG CLI] -- If we set SelectPolicy MinPolicySelect on scaleUp behavior or scaleDown behavior,Horizontal Pod Autoscaler doesn`t automatically scale the number of pods correctly ([#95647](https://github.com/kubernetes/kubernetes/pull/95647), [@JoshuaAndrew](https://github.com/JoshuaAndrew)) [SIG Apps and Autoscaling] -- Ignore apparmor for non-linux operating systems ([#93220](https://github.com/kubernetes/kubernetes/pull/93220), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] -- Ipvs: ensure selected scheduler kernel modules are loaded ([#93040](https://github.com/kubernetes/kubernetes/pull/93040), [@cmluciano](https://github.com/cmluciano)) [SIG Network] -- Kubeadm: add missing "--experimental-patches" flag to "kubeadm init phase control-plane" ([#95786](https://github.com/kubernetes/kubernetes/pull/95786), [@Sh4d1](https://github.com/Sh4d1)) [SIG Cluster Lifecycle] -- Reorganized iptables rules to fix a performance issue ([#95252](https://github.com/kubernetes/kubernetes/pull/95252), [@tssurya](https://github.com/tssurya)) [SIG Network] -- Unhealthy pods covered by PDBs can be successfully evicted if enough healthy pods are available. ([#94381](https://github.com/kubernetes/kubernetes/pull/94381), [@michaelgugino](https://github.com/michaelgugino)) [SIG Apps] -- Update the PIP when it is not in the Succeeded provisioning state during the LB update. ([#95748](https://github.com/kubernetes/kubernetes/pull/95748), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Update the frontend IP config when the service's `pipName` annotation is changed ([#95813](https://github.com/kubernetes/kubernetes/pull/95813), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] - -### Other (Cleanup or Flake) - -- NO ([#95690](https://github.com/kubernetes/kubernetes/pull/95690), [@nikhita](https://github.com/nikhita)) [SIG Release] - -## Dependencies - -### Added -- github.com/form3tech-oss/jwt-go: [v3.2.2+incompatible](https://github.com/form3tech-oss/jwt-go/tree/v3.2.2) - -### Changed -- github.com/Azure/go-autorest/autorest/adal: [v0.9.0 → v0.9.5](https://github.com/Azure/go-autorest/autorest/adal/compare/v0.9.0...v0.9.5) -- github.com/Azure/go-autorest/autorest/mocks: [v0.4.0 → v0.4.1](https://github.com/Azure/go-autorest/autorest/mocks/compare/v0.4.0...v0.4.1) -- golang.org/x/crypto: 75b2880 → 7f63de1 - -### Removed -_Nothing has changed._ - - - -# v1.20.0-alpha.3 - - -## Downloads for v1.20.0-alpha.3 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes.tar.gz) | 542cc9e0cd97732020491456402b6e2b4f54f2714007ee1374a7d363663a1b41e82b50886176a5313aaccfbfd4df2bc611d6b32d19961cdc98b5821b75d6b17c -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-src.tar.gz) | 5e5d725294e552fd1d14fd6716d013222827ac2d4e2d11a7a1fdefb77b3459bbeb69931f38e1597de205dd32a1c9763ab524c2af1551faef4f502ef0890f7fbf - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-darwin-amd64.tar.gz) | 60004939727c75d0f06adc4449e16b43303941937c0e9ea9aca7d947e93a5aed5d11e53d1fc94caeb988be66d39acab118d406dc2d6cead61181e1ced6d2be1a -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-linux-386.tar.gz) | 7edba9c4f1bf38fdf1fa5bff2856c05c0e127333ce19b17edf3119dc9b80462c027404a1f58a5eabf1de73a8f2f20aced043dda1fafd893619db1a188cda550c -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-linux-amd64.tar.gz) | db1818aa82d072cb3e32a2a988e66d76ecf7cebc6b8a29845fa2d6ec27f14a36e4b9839b1b7ed8c43d2da9cde00215eb672a7e8ee235d2e3107bc93c22e58d38 -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-linux-arm.tar.gz) | d2922e70d22364b1f5a1e94a0c115f849fe2575b231b1ba268f73a9d86fc0a9fbb78dc713446839a2593acf1341cb5a115992f350870f13c1a472bb107b75af7 -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-linux-arm64.tar.gz) | 2e3ae20e554c7d4fc3a8afdfcafe6bbc81d4c5e9aea036357baac7a3fdc2e8098aa8a8c3dded3951667d57f667ce3fbf37ec5ae5ceb2009a569dc9002d3a92f9 -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-linux-ppc64le.tar.gz) | b54a34e572e6a86221577de376e6f7f9fcd82327f7fe94f2fc8d21f35d302db8a0f3d51e60dc89693999f5df37c96d0c3649a29f07f095efcdd59923ae285c95 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-linux-s390x.tar.gz) | 5be1b70dc437d3ba88cb0b89cd1bc555f79896c3f5b5f4fa0fb046a0d09d758b994d622ebe5cef8e65bba938c5ae945b81dc297f9dfa0d98f82ea75f344a3a0d -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-windows-386.tar.gz) | 88cf3f66168ef3bf9a5d3d2275b7f33799406e8205f2c202997ebec23d449aa4bb48b010356ab1cf52ff7b527b8df7c8b9947a43a82ebe060df83c3d21b7223a -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-client-windows-amd64.tar.gz) | 87d2d4ea1829da8cfa1a705a03ea26c759a03bd1c4d8b96f2c93264c4d172bb63a91d9ddda65cdc5478b627c30ae8993db5baf8be262c157d83bffcebe85474e - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-server-linux-amd64.tar.gz) | 7af691fc0b13a937797912374e3b3eeb88d5262e4eb7d4ebe92a3b64b3c226cb049aedfd7e39f639f6990444f7bcf2fe58699cf0c29039daebe100d7eebf60de -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-server-linux-arm.tar.gz) | 557c47870ecf5c2090b2694c8f0c8e3b4ca23df5455a37945bd037bc6fb5b8f417bf737bb66e6336b285112cb52de0345240fdb2f3ce1c4fb335ca7ef1197f99 -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-server-linux-arm64.tar.gz) | 981de6cf7679d743cdeef1e894314357b68090133814801870504ef30564e32b5675e270db20961e9a731e35241ad9b037bdaf749da87b6c4ce8889eeb1c5855 -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-server-linux-ppc64le.tar.gz) | 506578a21601ccff609ae757a55e68634c15cbfecbf13de972c96b32a155ded29bd71aee069c77f5f721416672c7a7ac0b8274de22bfd28e1ecae306313d96c5 -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-server-linux-s390x.tar.gz) | af0cdcd4a77a7cc8060a076641615730a802f1f02dab084e41926023489efec6102d37681c70ab0dbe7440cd3e72ea0443719a365467985360152b9aae657375 - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-node-linux-amd64.tar.gz) | 2d92c61596296279de1efae23b2b707415565d9d50cd61a7231b8d10325732b059bcb90f3afb36bef2575d203938c265572721e38df408e8792d3949523bd5d9 -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-node-linux-arm.tar.gz) | c298de9b5ac1b8778729a2d8e2793ff86743033254fbc27014333880b03c519de81691caf03aa418c729297ee8942ce9ec89d11b0e34a80576b9936015dc1519 -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-node-linux-arm64.tar.gz) | daa3c65afda6d7aff206c1494390bbcc205c2c6f8db04c10ca967a690578a01c49d49c6902b85e7158f79fd4d2a87c5d397d56524a75991c9d7db85ac53059a7 -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-node-linux-ppc64le.tar.gz) | 05661908bb73bfcaf9c2eae96e9a6a793db5a7a100bce6df9e057985dd53a7a5248d72e81b6d13496bd38b9326c17cdb2edaf0e982b6437507245fb846e1efc6 -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-node-linux-s390x.tar.gz) | 845e518e2c4ef0cef2c3b58f0b9ea5b5fe9b8a249717f789607752484c424c26ae854b263b7c0a004a8426feb9aa3683c177a9ed2567e6c3521f4835ea08c24a -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.3/kubernetes-node-windows-amd64.tar.gz) | 530e536574ed2c3e5973d3c0f0fdd2b4d48ef681a7a7c02db13e605001669eeb4f4b8a856fc08fc21436658c27b377f5d04dbcb3aae438098abc953b6eaf5712 - -## Changelog since v1.20.0-alpha.2 - -## Changes by Kind - -### API Change - -- New parameter `defaultingType` for `PodTopologySpread` plugin allows to use k8s defined or user provided default constraints ([#95048](https://github.com/kubernetes/kubernetes/pull/95048), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] - -### Feature - -- Added new k8s.io/component-helpers repository providing shared helper code for (core) components. ([#92507](https://github.com/kubernetes/kubernetes/pull/92507), [@ingvagabund](https://github.com/ingvagabund)) [SIG Apps, Node, Release and Scheduling] -- Adds `create ingress` command to `kubectl` ([#78153](https://github.com/kubernetes/kubernetes/pull/78153), [@amimof](https://github.com/amimof)) [SIG CLI and Network] -- Kubectl create now supports creating ingress objects. ([#94327](https://github.com/kubernetes/kubernetes/pull/94327), [@rikatz](https://github.com/rikatz)) [SIG CLI and Network] -- New default scheduling plugins order reduces scheduling and preemption latency when taints and node affinity are used ([#95539](https://github.com/kubernetes/kubernetes/pull/95539), [@soulxu](https://github.com/soulxu)) [SIG Scheduling] -- SCTP support in API objects (Pod, Service, NetworkPolicy) is now GA. - Note that this has no effect on whether SCTP is enabled on nodes at the kernel level, - and note that some cloud platforms and network plugins do not support SCTP traffic. ([#95566](https://github.com/kubernetes/kubernetes/pull/95566), [@danwinship](https://github.com/danwinship)) [SIG Apps and Network] -- Scheduling Framework: expose Run[Pre]ScorePlugins functions to PreemptionHandle which can be used in PostFilter extention point. ([#93534](https://github.com/kubernetes/kubernetes/pull/93534), [@everpeace](https://github.com/everpeace)) [SIG Scheduling and Testing] -- SelectorSpreadPriority maps to PodTopologySpread plugin when DefaultPodTopologySpread feature is enabled ([#95448](https://github.com/kubernetes/kubernetes/pull/95448), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- SetHostnameAsFQDN has been graduated to Beta and therefore it is enabled by default. ([#95267](https://github.com/kubernetes/kubernetes/pull/95267), [@javidiaz](https://github.com/javidiaz)) [SIG Node] - -### Bug or Regression - -- An issues preventing volume expand controller to annotate the PVC with `volume.kubernetes.io/storage-resizer` when the PVC StorageClass is already updated to the out-of-tree provisioner is now fixed. ([#94489](https://github.com/kubernetes/kubernetes/pull/94489), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG API Machinery, Apps and Storage] -- Change the mount way from systemd to normal mount except ceph and glusterfs intree-volume. ([#94916](https://github.com/kubernetes/kubernetes/pull/94916), [@smileusd](https://github.com/smileusd)) [SIG Apps, Cloud Provider, Network, Node, Storage and Testing] -- Fix azure disk attach failure for disk size bigger than 4TB ([#95463](https://github.com/kubernetes/kubernetes/pull/95463), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix azure disk data loss issue on Windows when unmount disk ([#95456](https://github.com/kubernetes/kubernetes/pull/95456), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fix verb & scope reporting for kube-apiserver metrics (LIST reported instead of GET) ([#95562](https://github.com/kubernetes/kubernetes/pull/95562), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Testing] -- Fix vsphere detach failure for static PVs ([#95447](https://github.com/kubernetes/kubernetes/pull/95447), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage] -- Fix: smb valid path error ([#95583](https://github.com/kubernetes/kubernetes/pull/95583), [@andyzhangx](https://github.com/andyzhangx)) [SIG Storage] -- Fixed a bug causing incorrect formatting of `kubectl describe ingress`. ([#94985](https://github.com/kubernetes/kubernetes/pull/94985), [@howardjohn](https://github.com/howardjohn)) [SIG CLI and Network] -- Fixed a bug in client-go where new clients with customized `Dial`, `Proxy`, `GetCert` config may get stale HTTP transports. ([#95427](https://github.com/kubernetes/kubernetes/pull/95427), [@roycaihw](https://github.com/roycaihw)) [SIG API Machinery] -- Fixes high CPU usage in kubectl drain ([#95260](https://github.com/kubernetes/kubernetes/pull/95260), [@amandahla](https://github.com/amandahla)) [SIG CLI] -- Support the node label `node.kubernetes.io/exclude-from-external-load-balancers` ([#95542](https://github.com/kubernetes/kubernetes/pull/95542), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] - -### Other (Cleanup or Flake) - -- Fix func name NewCreateCreateDeploymentOptions ([#91931](https://github.com/kubernetes/kubernetes/pull/91931), [@lixiaobing1](https://github.com/lixiaobing1)) [SIG CLI] -- Kubeadm: update the default pause image version to 1.4.0 on Windows. With this update the image supports Windows versions 1809 (2019LTS), 1903, 1909, 2004 ([#95419](https://github.com/kubernetes/kubernetes/pull/95419), [@jsturtevant](https://github.com/jsturtevant)) [SIG Cluster Lifecycle and Windows] -- Upgrade snapshot controller to 3.0.0 ([#95412](https://github.com/kubernetes/kubernetes/pull/95412), [@saikat-royc](https://github.com/saikat-royc)) [SIG Cloud Provider] -- Remove the dependency of csi-translation-lib module on apiserver/cloud-provider/controller-manager ([#95543](https://github.com/kubernetes/kubernetes/pull/95543), [@wawa0210](https://github.com/wawa0210)) [SIG Release] -- Scheduler framework interface moved from pkg/scheduler/framework/v1alpha to pkg/scheduler/framework ([#95069](https://github.com/kubernetes/kubernetes/pull/95069), [@farah](https://github.com/farah)) [SIG Scheduling, Storage and Testing] -- UDP and SCTP protocols can left stale connections that need to be cleared to avoid services disruption, but they can cause problems that are hard to debug. - Kubernetes components using a loglevel greater or equal than 4 will log the conntrack operations and its output, to show the entries that were deleted. ([#95694](https://github.com/kubernetes/kubernetes/pull/95694), [@aojea](https://github.com/aojea)) [SIG Network] - -## Dependencies - -### Added -_Nothing has changed._ - -### Changed -_Nothing has changed._ - -### Removed -_Nothing has changed._ - - - -# v1.20.0-alpha.2 - - -## Downloads for v1.20.0-alpha.2 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes.tar.gz) | 45089a4d26d56a5d613ecbea64e356869ac738eca3cc71d16b74ea8ae1b4527bcc32f1dc35ff7aa8927e138083c7936603faf063121d965a2f0f8ba28fa128d8 -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-src.tar.gz) | 646edd890d6df5858b90aaf68cc6e1b4589b8db09396ae921b5c400f2188234999e6c9633906692add08c6e8b4b09f12b2099132b0a7533443fb2a01cfc2bf81 - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-darwin-amd64.tar.gz) | c136273883e24a2a50b5093b9654f01cdfe57b97461d34885af4a68c2c4d108c07583c02b1cdf7f57f82e91306e542ce8f3bddb12fcce72b744458bc4796f8eb -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-linux-386.tar.gz) | 6ec59f1ed30569fa64ddb2d0de32b1ae04cda4ffe13f339050a7c9d7c63d425ee6f6d963dcf82c17281c4474da3eaf32c08117669052872a8c81bdce2c8a5415 -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-linux-amd64.tar.gz) | 7b40a4c087e2ea7f8d055f297fcd39a3f1cb6c866e7a3981a9408c3c3eb5363c648613491aad11bc7d44d5530b20832f8f96f6ceff43deede911fb74aafad35f -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-linux-arm.tar.gz) | cda9955feebea5acb8f2b5b87895d24894bbbbde47041453b1f926ebdf47a258ce0496aa27d06bcbf365b5615ce68a20d659b64410c54227216726e2ee432fca -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-linux-arm64.tar.gz) | f65bd9241c7eb88a4886a285330f732448570aea4ededaebeabcf70d17ea185f51bf8a7218f146ee09fb1adceca7ee71fb3c3683834f2c415163add820fba96e -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-linux-ppc64le.tar.gz) | 1e377599af100a81d027d9199365fb8208d443a8e0a97affff1a79dc18796e14b78cb53d6e245c1c1e8defd0e050e37bf5f2a23c8a3ff45a6d18d03619709bf5 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-linux-s390x.tar.gz) | 1cdee81478246aa7e7b80ae4efc7f070a5b058083ae278f59fad088b75a8052761b0e15ab261a6e667ddafd6a69fb424fc307072ed47941cad89a85af7aee93d -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-windows-386.tar.gz) | d8774167c87b6844c348aa15e92d5033c528d6ab9e95d08a7cb22da68bafd8e46d442cf57a5f6affad62f674c10ae6947d524b94108b5e450ca78f92656d63c0 -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-client-windows-amd64.tar.gz) | f664b47d8daa6036f8154c1dc1f881bfe683bf57c39d9b491de3848c03d051c50c6644d681baf7f9685eae45f9ce62e4c6dfea2853763cfe8256a61bdd59d894 - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-server-linux-amd64.tar.gz) | d6fcb4600be0beb9de222a8da64c35fe22798a0da82d41401d34d0f0fc7e2817512169524c281423d8f4a007cd77452d966317d5a1b67d2717a05ff346e8aa7d -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-server-linux-arm.tar.gz) | 022a76cf10801f8afbabb509572479b68fdb4e683526fa0799cdbd9bab4d3f6ecb76d1d63d0eafee93e3edf6c12892d84b9c771ef2325663b95347728fa3d6c0 -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-server-linux-arm64.tar.gz) | 0679aadd60bbf6f607e5befad74b5267eb2d4c1b55985cc25a97e0f4c5efb7acbb3ede91bfa6a5a5713dae4d7a302f6faaf678fd6b359284c33d9a6aca2a08bb -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-server-linux-ppc64le.tar.gz) | 9f2cfeed543b515eafb60d9765a3afff4f3d323c0a5c8a0d75e3de25985b2627817bfcbe59a9a61d969e026e2b861adb974a09eae75b58372ed736ceaaed2a82 -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-server-linux-s390x.tar.gz) | 937258704d7b9dcd91f35f2d34ee9dd38c18d9d4e867408c05281bfbbb919ad012c95880bee84d2674761aa44cc617fb2fae1124cf63b689289286d6eac1c407 - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-node-linux-amd64.tar.gz) | 076165d745d47879de68f4404eaf432920884be48277eb409e84bf2c61759633bf3575f46b0995f1fc693023d76c0921ed22a01432e756d7f8d9e246a243b126 -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-node-linux-arm.tar.gz) | 1ff2e2e3e43af41118cdfb70c778e15035bbb1aca833ffd2db83c4bcd44f55693e956deb9e65017ebf3c553f2820ad5cd05f5baa33f3d63f3e00ed980ea4dfed -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-node-linux-arm64.tar.gz) | b232c7359b8c635126899beee76998078eec7a1ef6758d92bcdebe8013b0b1e4d7b33ecbf35e3f82824fe29493400845257e70ed63c1635bfa36c8b3b4969f6f -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-node-linux-ppc64le.tar.gz) | 51d415a068f554840f4c78d11a4fedebd7cb03c686b0ec864509b24f7a8667ebf54bb0a25debcf2b70f38be1e345e743f520695b11806539a55a3620ce21946f -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-node-linux-s390x.tar.gz) | b51c082d8af358233a088b632cf2f6c8cfe5421471c27f5dc9ba4839ae6ea75df25d84298f2042770097554c01742bb7686694b331ad9bafc93c86317b867728 -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.2/kubernetes-node-windows-amd64.tar.gz) | 91b9d26620a2dde67a0edead0039814efccbdfd54594dda3597aaced6d89140dc92612ed0727bc21d63468efeef77c845e640153b09e39d8b736062e6eee0c76 - -## Changelog since v1.20.0-alpha.1 - -## Changes by Kind - -### Deprecation - -- Action-required: kubeadm: graduate the "kubeadm alpha certs" command to a parent command "kubeadm certs". The command "kubeadm alpha certs" is deprecated and will be removed in a future release. Please migrate. ([#94938](https://github.com/kubernetes/kubernetes/pull/94938), [@yagonobre](https://github.com/yagonobre)) [SIG Cluster Lifecycle] -- Action-required: kubeadm: remove the deprecated feature --experimental-kustomize from kubeadm commands. The feature was replaced with --experimental-patches in 1.19. To migrate see the --help description for the --experimental-patches flag. ([#94871](https://github.com/kubernetes/kubernetes/pull/94871), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: deprecate self-hosting support. The experimental command "kubeadm alpha self-hosting" is now deprecated and will be removed in a future release. ([#95125](https://github.com/kubernetes/kubernetes/pull/95125), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Removes deprecated scheduler metrics DeprecatedSchedulingDuration, DeprecatedSchedulingAlgorithmPredicateEvaluationSecondsDuration, DeprecatedSchedulingAlgorithmPriorityEvaluationSecondsDuration ([#94884](https://github.com/kubernetes/kubernetes/pull/94884), [@arghya88](https://github.com/arghya88)) [SIG Instrumentation and Scheduling] -- Scheduler alpha metrics binding_duration_seconds and scheduling_algorithm_preemption_evaluation_seconds are deprecated, Both of those metrics are now covered as part of framework_extension_point_duration_seconds, the former as a PostFilter the latter and a Bind plugin. The plan is to remove both in 1.21 ([#95001](https://github.com/kubernetes/kubernetes/pull/95001), [@arghya88](https://github.com/arghya88)) [SIG Instrumentation and Scheduling] - -### API Change - -- GPU metrics provided by kubelet are now disabled by default ([#95184](https://github.com/kubernetes/kubernetes/pull/95184), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Node] -- New parameter `defaultingType` for `PodTopologySpread` plugin allows to use k8s defined or user provided default constraints ([#95048](https://github.com/kubernetes/kubernetes/pull/95048), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- Server Side Apply now treats LabelSelector fields as atomic (meaning the entire selector is managed by a single writer and updated together), since they contain interrelated and inseparable fields that do not merge in intuitive ways. ([#93901](https://github.com/kubernetes/kubernetes/pull/93901), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Storage and Testing] -- Status of v1beta1 CRDs without "preserveUnknownFields:false" will show violation "spec.preserveUnknownFields: Invalid value: true: must be false" ([#93078](https://github.com/kubernetes/kubernetes/pull/93078), [@vareti](https://github.com/vareti)) [SIG API Machinery] - -### Feature - -- Added `get-users` and `delete-user` to the `kubectl config` subcommand ([#89840](https://github.com/kubernetes/kubernetes/pull/89840), [@eddiezane](https://github.com/eddiezane)) [SIG CLI] -- Added counter metric "apiserver_request_self" to count API server self-requests with labels for verb, resource, and subresource. ([#94288](https://github.com/kubernetes/kubernetes/pull/94288), [@LogicalShark](https://github.com/LogicalShark)) [SIG API Machinery, Auth, Instrumentation and Scheduling] -- Added new k8s.io/component-helpers repository providing shared helper code for (core) components. ([#92507](https://github.com/kubernetes/kubernetes/pull/92507), [@ingvagabund](https://github.com/ingvagabund)) [SIG Apps, Node, Release and Scheduling] -- Adds `create ingress` command to `kubectl` ([#78153](https://github.com/kubernetes/kubernetes/pull/78153), [@amimof](https://github.com/amimof)) [SIG CLI and Network] -- Allow configuring AWS LoadBalancer health check protocol via service annotations ([#94546](https://github.com/kubernetes/kubernetes/pull/94546), [@kishorj](https://github.com/kishorj)) [SIG Cloud Provider] -- Azure: Support multiple services sharing one IP address ([#94991](https://github.com/kubernetes/kubernetes/pull/94991), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider] -- Ephemeral containers now apply the same API defaults as initContainers and containers ([#94896](https://github.com/kubernetes/kubernetes/pull/94896), [@wawa0210](https://github.com/wawa0210)) [SIG Apps and CLI] -- In dual-stack bare-metal clusters, you can now pass dual-stack IPs to `kubelet --node-ip`. - eg: `kubelet --node-ip 10.1.0.5,fd01::0005`. This is not yet supported for non-bare-metal - clusters. - - In dual-stack clusters where nodes have dual-stack addresses, hostNetwork pods - will now get dual-stack PodIPs. ([#95239](https://github.com/kubernetes/kubernetes/pull/95239), [@danwinship](https://github.com/danwinship)) [SIG Network and Node] -- Introduces a new GCE specific cluster creation variable KUBE_PROXY_DISABLE. When set to true, this will skip over the creation of kube-proxy (whether the daemonset or static pod). This can be used to control the lifecycle of kube-proxy separately from the lifecycle of the nodes. ([#91977](https://github.com/kubernetes/kubernetes/pull/91977), [@varunmar](https://github.com/varunmar)) [SIG Cloud Provider] -- Kubeadm: do not throw errors if the current system time is outside of the NotBefore and NotAfter bounds of a loaded certificate. Print warnings instead. ([#94504](https://github.com/kubernetes/kubernetes/pull/94504), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: make the command "kubeadm alpha kubeconfig user" accept a "--config" flag and remove the following flags: - - apiserver-advertise-address / apiserver-bind-port: use either localAPIEndpoint from InitConfiguration or controlPlaneEndpoint from ClusterConfiguration. - - cluster-name: use clusterName from ClusterConfiguration - - cert-dir: use certificatesDir from ClusterConfiguration ([#94879](https://github.com/kubernetes/kubernetes/pull/94879), [@knight42](https://github.com/knight42)) [SIG Cluster Lifecycle] -- Kubectl rollout history sts/sts-name --revision=some-revision will start showing the detailed view of the sts on that specified revision ([#86506](https://github.com/kubernetes/kubernetes/pull/86506), [@dineshba](https://github.com/dineshba)) [SIG CLI] -- Scheduling Framework: expose Run[Pre]ScorePlugins functions to PreemptionHandle which can be used in PostFilter extention point. ([#93534](https://github.com/kubernetes/kubernetes/pull/93534), [@everpeace](https://github.com/everpeace)) [SIG Scheduling and Testing] -- Send gce node startup scripts logs to console and journal ([#95311](https://github.com/kubernetes/kubernetes/pull/95311), [@karan](https://github.com/karan)) [SIG Cloud Provider and Node] -- Support kubectl delete orphan/foreground/background options ([#93384](https://github.com/kubernetes/kubernetes/pull/93384), [@zhouya0](https://github.com/zhouya0)) [SIG CLI and Testing] - -### Bug or Regression - -- Change the mount way from systemd to normal mount except ceph and glusterfs intree-volume. ([#94916](https://github.com/kubernetes/kubernetes/pull/94916), [@smileusd](https://github.com/smileusd)) [SIG Apps, Cloud Provider, Network, Node, Storage and Testing] -- Cloud node controller: handle empty providerID from getProviderID ([#95342](https://github.com/kubernetes/kubernetes/pull/95342), [@nicolehanjing](https://github.com/nicolehanjing)) [SIG Cloud Provider] -- Fix a bug where the endpoint slice controller was not mirroring the parent service labels to its corresponding endpoint slices ([#94443](https://github.com/kubernetes/kubernetes/pull/94443), [@aojea](https://github.com/aojea)) [SIG Apps and Network] -- Fix azure disk attach failure for disk size bigger than 4TB ([#95463](https://github.com/kubernetes/kubernetes/pull/95463), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix azure disk data loss issue on Windows when unmount disk ([#95456](https://github.com/kubernetes/kubernetes/pull/95456), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fix detach azure disk issue when vm not exist ([#95177](https://github.com/kubernetes/kubernetes/pull/95177), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix network_programming_latency metric reporting for Endpoints/EndpointSlice deletions, where we don't have correct timestamp ([#95363](https://github.com/kubernetes/kubernetes/pull/95363), [@wojtek-t](https://github.com/wojtek-t)) [SIG Network and Scalability] -- Fix scheduler cache snapshot when a Node is deleted before its Pods ([#95130](https://github.com/kubernetes/kubernetes/pull/95130), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scheduling] -- Fix vsphere detach failure for static PVs ([#95447](https://github.com/kubernetes/kubernetes/pull/95447), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider and Storage] -- Fixed a bug that prevents the use of ephemeral containers in the presence of a validating admission webhook. ([#94685](https://github.com/kubernetes/kubernetes/pull/94685), [@verb](https://github.com/verb)) [SIG Node and Testing] -- Gracefully delete nodes when their parent scale set went missing ([#95289](https://github.com/kubernetes/kubernetes/pull/95289), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider] -- In dual-stack clusters, kubelet will now set up both IPv4 and IPv6 iptables rules, which may - fix some problems, eg with HostPorts. ([#94474](https://github.com/kubernetes/kubernetes/pull/94474), [@danwinship](https://github.com/danwinship)) [SIG Network and Node] -- Kubeadm: for Docker as the container runtime, make the "kubeadm reset" command stop containers before removing them ([#94586](https://github.com/kubernetes/kubernetes/pull/94586), [@BedivereZero](https://github.com/BedivereZero)) [SIG Cluster Lifecycle] -- Kubeadm: warn but do not error out on missing "ca.key" files for root CA, front-proxy CA and etcd CA, during "kubeadm join --control-plane" if the user has provided all certificates, keys and kubeconfig files which require signing with the given CA keys. ([#94988](https://github.com/kubernetes/kubernetes/pull/94988), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Port mapping allows to map the same `containerPort` to multiple `hostPort` without naming the mapping explicitly. ([#94494](https://github.com/kubernetes/kubernetes/pull/94494), [@SergeyKanzhelev](https://github.com/SergeyKanzhelev)) [SIG Network and Node] -- Warn instead of fail when creating Roles and ClusterRoles with custom verbs via kubectl ([#92492](https://github.com/kubernetes/kubernetes/pull/92492), [@eddiezane](https://github.com/eddiezane)) [SIG CLI] - -### Other (Cleanup or Flake) - -- Added fine grained debugging to the intra-pod conformance test for helping easily resolve networking issues for nodes that might be unhealthy when running conformance or sonobuoy tests. ([#93837](https://github.com/kubernetes/kubernetes/pull/93837), [@jayunit100](https://github.com/jayunit100)) [SIG Network and Testing] -- AdmissionReview objects sent for the creation of Namespace API objects now populate the `namespace` attribute consistently (previously the `namespace` attribute was empty for Namespace creation via POST requests, and populated for Namespace creation via server-side-apply PATCH requests) ([#95012](https://github.com/kubernetes/kubernetes/pull/95012), [@nodo](https://github.com/nodo)) [SIG API Machinery and Testing] -- Client-go header logging (at verbosity levels >= 9) now masks `Authorization` header contents ([#95316](https://github.com/kubernetes/kubernetes/pull/95316), [@sfowl](https://github.com/sfowl)) [SIG API Machinery] -- Enhance log information of verifyRunAsNonRoot, add pod, container information ([#94911](https://github.com/kubernetes/kubernetes/pull/94911), [@wawa0210](https://github.com/wawa0210)) [SIG Node] -- Errors from staticcheck: - vendor/k8s.io/client-go/discovery/cached/memory/memcache_test.go:94:2: this value of g is never used (SA4006) ([#95098](https://github.com/kubernetes/kubernetes/pull/95098), [@phunziker](https://github.com/phunziker)) [SIG API Machinery] -- Kubeadm: update the default pause image version to 1.4.0 on Windows. With this update the image supports Windows versions 1809 (2019LTS), 1903, 1909, 2004 ([#95419](https://github.com/kubernetes/kubernetes/pull/95419), [@jsturtevant](https://github.com/jsturtevant)) [SIG Cluster Lifecycle and Windows] -- Masks ceph RBD adminSecrets in logs when logLevel >= 4 ([#95245](https://github.com/kubernetes/kubernetes/pull/95245), [@sfowl](https://github.com/sfowl)) [SIG Storage] -- Upgrade snapshot controller to 3.0.0 ([#95412](https://github.com/kubernetes/kubernetes/pull/95412), [@saikat-royc](https://github.com/saikat-royc)) [SIG Cloud Provider] -- Remove offensive words from kubectl cluster-info command ([#95202](https://github.com/kubernetes/kubernetes/pull/95202), [@rikatz](https://github.com/rikatz)) [SIG Architecture, CLI and Testing] -- The following new metrics are available. - - network_plugin_operations_total - - network_plugin_operations_errors_total ([#93066](https://github.com/kubernetes/kubernetes/pull/93066), [@AnishShah](https://github.com/AnishShah)) [SIG Instrumentation, Network and Node] -- Vsphere: improve logging message on node cache refresh event ([#95236](https://github.com/kubernetes/kubernetes/pull/95236), [@andrewsykim](https://github.com/andrewsykim)) [SIG Cloud Provider] -- `kubectl api-resources` now prints the API version (as 'API group/version', same as output of `kubectl api-versions`). The column APIGROUP is now APIVERSION ([#95253](https://github.com/kubernetes/kubernetes/pull/95253), [@sallyom](https://github.com/sallyom)) [SIG CLI] - -## Dependencies - -### Added -- github.com/jmespath/go-jmespath/internal/testify: [v1.5.1](https://github.com/jmespath/go-jmespath/internal/testify/tree/v1.5.1) - -### Changed -- github.com/aws/aws-sdk-go: [v1.28.2 → v1.35.5](https://github.com/aws/aws-sdk-go/compare/v1.28.2...v1.35.5) -- github.com/jmespath/go-jmespath: [c2b33e8 → v0.4.0](https://github.com/jmespath/go-jmespath/compare/c2b33e8...v0.4.0) -- k8s.io/kube-openapi: 6aeccd4 → 8b50664 -- sigs.k8s.io/apiserver-network-proxy/konnectivity-client: v0.0.9 → v0.0.12 -- sigs.k8s.io/structured-merge-diff/v4: v4.0.1 → b3cf1e8 - -### Removed -_Nothing has changed._ - - - -# v1.20.0-alpha.1 - - -## Downloads for v1.20.0-alpha.1 - -### Source Code - -filename | sha512 hash --------- | ----------- -[kubernetes.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes.tar.gz) | e7daed6502ea07816274f2371f96fe1a446d0d7917df4454b722d9eb3b5ff6163bfbbd5b92dfe7a0c1d07328b8c09c4ae966e482310d6b36de8813aaf87380b5 -[kubernetes-src.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-src.tar.gz) | e91213a0919647a1215d4691a63b12d89a3e74055463a8ebd71dc1a4cabf4006b3660881067af0189960c8dab74f4a7faf86f594df69021901213ee5b56550ea - -### Client binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-client-darwin-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-darwin-amd64.tar.gz) | 1f3add5f826fa989820d715ca38e8864b66f30b59c1abeacbb4bfb96b4e9c694eac6b3f4c1c81e0ee3451082d44828cb7515315d91ad68116959a5efbdaef1e1 -[kubernetes-client-linux-386.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-linux-386.tar.gz) | c62acdc8993b0a950d4b0ce0b45473bf96373d501ce61c88adf4007afb15c1d53da8d53b778a7eccac6c1624f7fdda322be9f3a8bc2d80aaad7b4237c39f5eaf -[kubernetes-client-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-linux-amd64.tar.gz) | 1203ababfe00f9bc5be5c059324c17160a96530c1379a152db33564bbe644ccdb94b30eea15a0655bd652efb17895a46c31bbba19d4f5f473c2a0ff62f6e551f -[kubernetes-client-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-linux-arm.tar.gz) | 31860088596e12d739c7aed94556c2d1e217971699b950c8417a3cea1bed4e78c9ff1717b9f3943354b75b4641d4b906cd910890dbf4278287c0d224837d9a7d -[kubernetes-client-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-linux-arm64.tar.gz) | 8d469f37fe20d6e15b5debc13cce4c22e8b7a4f6a4ac787006b96507a85ce761f63b28140d692c54b5f7deb08697f8d5ddb9bbfa8f5ac0d9241fc7de3a3fe3cd -[kubernetes-client-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-linux-ppc64le.tar.gz) | 0d62ee1729cd5884946b6c73701ad3a570fa4d642190ca0fe5c1db0fb0cba9da3ac86a948788d915b9432d28ab8cc499e28aadc64530b7d549ee752a6ed93ec1 -[kubernetes-client-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-linux-s390x.tar.gz) | 0fc0420e134ec0b8e0ab2654e1e102cebec47b48179703f1e1b79d51ee0d6da55a4e7304d8773d3cf830341ac2fe3cede1e6b0460fd88f7595534e0730422d5a -[kubernetes-client-windows-386.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-windows-386.tar.gz) | 3fb53b5260f4888c77c0e4ff602bbcf6bf38c364d2769850afe2b8d8e8b95f7024807c15e2b0d5603e787c46af8ac53492be9e88c530f578b8a389e3bd50c099 -[kubernetes-client-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-client-windows-amd64.tar.gz) | 2f44c93463d6b5244ce0c82f147e7f32ec2233d0e29c64c3c5759e23533aebd12671bf63e986c0861e9736f9b5259bb8d138574a7c8c8efc822e35cd637416c0 - -### Server binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-server-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-server-linux-amd64.tar.gz) | ae82d14b1214e4100f0cc2c988308b3e1edd040a65267d0eddb9082409f79644e55387889e3c0904a12c710f91206e9383edf510990bee8c9ea2e297b6472551 -[kubernetes-server-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-server-linux-arm.tar.gz) | 9a2a5828b7d1ddb16cc19d573e99a4af642f84129408e6203eeeb0558e7b8db77f3269593b5770b6a976fe9df4a64240ed27ad05a4bd43719e55fce1db0abf58 -[kubernetes-server-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-server-linux-arm64.tar.gz) | ed700dd226c999354ce05b73927388d36d08474c15333ae689427de15de27c84feb6b23c463afd9dd81993315f31eb8265938cfc7ecf6f750247aa42b9b33fa9 -[kubernetes-server-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-server-linux-ppc64le.tar.gz) | abb7a9d726538be3ccf5057a0c63ff9732b616e213c6ebb81363f0c49f1e168ce8068b870061ad7cba7ba1d49252f94cf00a5f68cec0f38dc8fce4e24edc5ca6 -[kubernetes-server-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-server-linux-s390x.tar.gz) | 3a51888af1bfdd2d5b0101d173ee589c1f39240e4428165f5f85c610344db219625faa42f00a49a83ce943fb079be873b1a114a62003fae2f328f9bf9d1227a4 - -### Node binaries - -filename | sha512 hash --------- | ----------- -[kubernetes-node-linux-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-node-linux-amd64.tar.gz) | d0f28e3c38ca59a7ff1bfecb48a1ce97116520355d9286afdca1200d346c10018f5bbdf890f130a388654635a2e83e908b263ed45f8a88defca52a7c1d0a7984 -[kubernetes-node-linux-arm.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-node-linux-arm.tar.gz) | ed9d3f13028beb3be39bce980c966f82c4b39dc73beaae38cc075fea5be30b0309e555cb2af8196014f2cc9f0df823354213c314b4d6545ff6e30dd2d00ec90e -[kubernetes-node-linux-arm64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-node-linux-arm64.tar.gz) | ad5b3268db365dcdded9a9a4bffc90c7df0f844000349accdf2b8fb5f1081e553de9b9e9fb25d5e8a4ef7252d51fa94ef94d36d2ab31d157854e164136f662c2 -[kubernetes-node-linux-ppc64le.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-node-linux-ppc64le.tar.gz) | c4de2524e513996def5eeba7b83f7b406f17eaf89d4d557833a93bd035348c81fa9375dcd5c27cfcc55d73995449fc8ee504be1b3bd7b9f108b0b2f153cb05ae -[kubernetes-node-linux-s390x.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-node-linux-s390x.tar.gz) | 9157b44e3e7bd5478af9f72014e54d1afa5cd19b984b4cd8b348b312c385016bb77f29db47f44aea08b58abf47d8a396b92a2d0e03f2fe8acdd30f4f9466cbdb -[kubernetes-node-windows-amd64.tar.gz](https://dl.k8s.io/v1.20.0-alpha.1/kubernetes-node-windows-amd64.tar.gz) | 8b40a43c5e6447379ad2ee8aac06e8028555e1b370a995f6001018a62411abe5fbbca6060b3d1682c5cadc07a27d49edd3204e797af46368800d55f4ca8aa1de - -## Changelog since v1.20.0-alpha.0 - -## Urgent Upgrade Notes - -### (No, really, you MUST read this before you upgrade) - - - Azure blob disk feature(`kind`: `Shared`, `Dedicated`) has been deprecated, you should use `kind`: `Managed` in `kubernetes.io/azure-disk` storage class. ([#92905](https://github.com/kubernetes/kubernetes/pull/92905), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] - - CVE-2020-8559 (Medium): Privilege escalation from compromised node to cluster. See https://github.com/kubernetes/kubernetes/issues/92914 for more details. - The API Server will no longer proxy non-101 responses for upgrade requests. This could break proxied backends (such as an extension API server) that respond to upgrade requests with a non-101 response code. ([#92941](https://github.com/kubernetes/kubernetes/pull/92941), [@tallclair](https://github.com/tallclair)) [SIG API Machinery] - -## Changes by Kind - -### Deprecation - -- Kube-apiserver: the componentstatus API is deprecated. This API provided status of etcd, kube-scheduler, and kube-controller-manager components, but only worked when those components were local to the API server, and when kube-scheduler and kube-controller-manager exposed unsecured health endpoints. Instead of this API, etcd health is included in the kube-apiserver health check and kube-scheduler/kube-controller-manager health checks can be made directly against those components' health endpoints. ([#93570](https://github.com/kubernetes/kubernetes/pull/93570), [@liggitt](https://github.com/liggitt)) [SIG API Machinery, Apps and Cluster Lifecycle] -- Kubeadm: deprecate the "kubeadm alpha kubelet config enable-dynamic" command. To continue using the feature please defer to the guide for "Dynamic Kubelet Configuration" at k8s.io. ([#92881](https://github.com/kubernetes/kubernetes/pull/92881), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: remove the deprecated "kubeadm alpha kubelet config enable-dynamic" command. To continue using the feature please defer to the guide for "Dynamic Kubelet Configuration" at k8s.io. This change also removes the parent command "kubeadm alpha kubelet" as there are no more sub-commands under it for the time being. ([#94668](https://github.com/kubernetes/kubernetes/pull/94668), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: remove the deprecated --kubelet-config flag for the command "kubeadm upgrade node" ([#94869](https://github.com/kubernetes/kubernetes/pull/94869), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubelet's deprecated endpoint `metrics/resource/v1alpha1` has been removed, please adopt to `metrics/resource`. ([#94272](https://github.com/kubernetes/kubernetes/pull/94272), [@RainbowMango](https://github.com/RainbowMango)) [SIG Instrumentation and Node] -- The v1alpha1 PodPreset API and admission plugin has been removed with no built-in replacement. Admission webhooks can be used to modify pods on creation. ([#94090](https://github.com/kubernetes/kubernetes/pull/94090), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Apps, CLI, Cloud Provider, Scalability and Testing] - -### API Change - -- A new `nofuzz` go build tag now disables gofuzz support. Release binaries enable this. ([#92491](https://github.com/kubernetes/kubernetes/pull/92491), [@BenTheElder](https://github.com/BenTheElder)) [SIG API Machinery] -- A new alpha-level field, `SupportsFsGroup`, has been introduced for CSIDrivers to allow them to specify whether they support volume ownership and permission modifications. The `CSIVolumeSupportFSGroup` feature gate must be enabled to allow this field to be used. ([#92001](https://github.com/kubernetes/kubernetes/pull/92001), [@huffmanca](https://github.com/huffmanca)) [SIG API Machinery, CLI and Storage] -- Added pod version skew strategy for seccomp profile to synchronize the deprecated annotations with the new API Server fields. Please see the corresponding section [in the KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190717-seccomp-ga.md#version-skew-strategy) for more detailed explanations. ([#91408](https://github.com/kubernetes/kubernetes/pull/91408), [@saschagrunert](https://github.com/saschagrunert)) [SIG Apps, Auth, CLI and Node] -- Adds the ability to disable Accelerator/GPU metrics collected by Kubelet ([#91930](https://github.com/kubernetes/kubernetes/pull/91930), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Node] -- Custom Endpoints are now mirrored to EndpointSlices by a new EndpointSliceMirroring controller. ([#91637](https://github.com/kubernetes/kubernetes/pull/91637), [@robscott](https://github.com/robscott)) [SIG API Machinery, Apps, Auth, Cloud Provider, Instrumentation, Network and Testing] -- External facing API podresources is now available under k8s.io/kubelet/pkg/apis/ ([#92632](https://github.com/kubernetes/kubernetes/pull/92632), [@RenaudWasTaken](https://github.com/RenaudWasTaken)) [SIG Node and Testing] -- Fix conversions for custom metrics. ([#94481](https://github.com/kubernetes/kubernetes/pull/94481), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Instrumentation] -- Generic ephemeral volumes, a new alpha feature under the `GenericEphemeralVolume` feature gate, provide a more flexible alternative to `EmptyDir` volumes: as with `EmptyDir`, volumes are created and deleted for each pod automatically by Kubernetes. But because the normal provisioning process is used (`PersistentVolumeClaim`), storage can be provided by third-party storage vendors and all of the usual volume features work. Volumes don't need to be empt; for example, restoring from snapshot is supported. ([#92784](https://github.com/kubernetes/kubernetes/pull/92784), [@pohly](https://github.com/pohly)) [SIG API Machinery, Apps, Auth, CLI, Instrumentation, Node, Scheduling, Storage and Testing] -- Kube-controller-manager: volume plugins can be restricted from contacting local and loopback addresses by setting `--volume-host-allow-local-loopback=false`, or from contacting specific CIDR ranges by setting `--volume-host-cidr-denylist` (for example, `--volume-host-cidr-denylist=127.0.0.1/28,feed::/16`) ([#91785](https://github.com/kubernetes/kubernetes/pull/91785), [@mattcary](https://github.com/mattcary)) [SIG API Machinery, Apps, Auth, CLI, Network, Node, Storage and Testing] -- Kubernetes is now built with golang 1.15.0-rc.1. - - The deprecated, legacy behavior of treating the CommonName field on X.509 serving certificates as a host name when no Subject Alternative Names are present is now disabled by default. It can be temporarily re-enabled by adding the value x509ignoreCN=0 to the GODEBUG environment variable. ([#93264](https://github.com/kubernetes/kubernetes/pull/93264), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Auth, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Node, Release, Scalability, Storage and Testing] -- Migrate scheduler, controller-manager and cloud-controller-manager to use LeaseLock ([#94603](https://github.com/kubernetes/kubernetes/pull/94603), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery, Apps, Cloud Provider and Scheduling] -- Modify DNS-1123 error messages to indicate that RFC 1123 is not followed exactly ([#94182](https://github.com/kubernetes/kubernetes/pull/94182), [@mattfenwick](https://github.com/mattfenwick)) [SIG API Machinery, Apps, Auth, Network and Node] -- The ServiceAccountIssuerDiscovery feature gate is now Beta and enabled by default. ([#91921](https://github.com/kubernetes/kubernetes/pull/91921), [@mtaufen](https://github.com/mtaufen)) [SIG Auth] -- The kube-controller-manager managed signers can now have distinct signing certificates and keys. See the help about `--cluster-signing-[signer-name]-{cert,key}-file`. `--cluster-signing-{cert,key}-file` is still the default. ([#90822](https://github.com/kubernetes/kubernetes/pull/90822), [@deads2k](https://github.com/deads2k)) [SIG API Machinery, Apps and Auth] -- When creating a networking.k8s.io/v1 Ingress API object, `spec.tls[*].secretName` values are required to pass validation rules for Secret API object names. ([#93929](https://github.com/kubernetes/kubernetes/pull/93929), [@liggitt](https://github.com/liggitt)) [SIG Network] -- WinOverlay feature graduated to beta ([#94807](https://github.com/kubernetes/kubernetes/pull/94807), [@ksubrmnn](https://github.com/ksubrmnn)) [SIG Windows] - -### Feature - -- ACTION REQUIRED : In CoreDNS v1.7.0, [metrics names have been changed](https://github.com/coredns/coredns/blob/master/notes/coredns-1.7.0.md#metric-changes) which will be backward incompatible with existing reporting formulas that use the old metrics' names. Adjust your formulas to the new names before upgrading. - - Kubeadm now includes CoreDNS version v1.7.0. Some of the major changes include: - - Fixed a bug that could cause CoreDNS to stop updating service records. - - Fixed a bug in the forward plugin where only the first upstream server is always selected no matter which policy is set. - - Remove already deprecated options `resyncperiod` and `upstream` in the Kubernetes plugin. - - Includes Prometheus metrics name changes (to bring them in line with standard Prometheus metrics naming convention). They will be backward incompatible with existing reporting formulas that use the old metrics' names. - - The federation plugin (allows for v1 Kubernetes federation) has been removed. - More details are available in https://coredns.io/2020/06/15/coredns-1.7.0-release/ ([#92651](https://github.com/kubernetes/kubernetes/pull/92651), [@rajansandeep](https://github.com/rajansandeep)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle and Instrumentation] -- Add metrics for azure service operations (route and loadbalancer). ([#94124](https://github.com/kubernetes/kubernetes/pull/94124), [@nilo19](https://github.com/nilo19)) [SIG Cloud Provider and Instrumentation] -- Add network rule support in Azure account creation ([#94239](https://github.com/kubernetes/kubernetes/pull/94239), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Add tags support for Azure File Driver ([#92825](https://github.com/kubernetes/kubernetes/pull/92825), [@ZeroMagic](https://github.com/ZeroMagic)) [SIG Cloud Provider and Storage] -- Added kube-apiserver metrics: apiserver_current_inflight_request_measures and, when API Priority and Fairness is enable, windowed_request_stats. ([#91177](https://github.com/kubernetes/kubernetes/pull/91177), [@MikeSpreitzer](https://github.com/MikeSpreitzer)) [SIG API Machinery, Instrumentation and Testing] -- Audit events for API requests to deprecated API versions now include a `"k8s.io/deprecated": "true"` audit annotation. If a target removal release is identified, the audit event includes a `"k8s.io/removal-release": "."` audit annotation as well. ([#92842](https://github.com/kubernetes/kubernetes/pull/92842), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Instrumentation] -- Cloud node-controller use InstancesV2 ([#91319](https://github.com/kubernetes/kubernetes/pull/91319), [@gongguan](https://github.com/gongguan)) [SIG Apps, Cloud Provider, Scalability and Storage] -- Kubeadm: Add a preflight check that the control-plane node has at least 1700MB of RAM ([#93275](https://github.com/kubernetes/kubernetes/pull/93275), [@xlgao-zju](https://github.com/xlgao-zju)) [SIG Cluster Lifecycle] -- Kubeadm: add the "--cluster-name" flag to the "kubeadm alpha kubeconfig user" to allow configuring the cluster name in the generated kubeconfig file ([#93992](https://github.com/kubernetes/kubernetes/pull/93992), [@prabhu43](https://github.com/prabhu43)) [SIG Cluster Lifecycle] -- Kubeadm: add the "--kubeconfig" flag to the "kubeadm init phase upload-certs" command to allow users to pass a custom location for a kubeconfig file. ([#94765](https://github.com/kubernetes/kubernetes/pull/94765), [@zhanw15](https://github.com/zhanw15)) [SIG Cluster Lifecycle] -- Kubeadm: deprecate the "--csr-only" and "--csr-dir" flags of the "kubeadm init phase certs" subcommands. Please use "kubeadm alpha certs generate-csr" instead. This new command allows you to generate new private keys and certificate signing requests for all the control-plane components, so that the certificates can be signed by an external CA. ([#92183](https://github.com/kubernetes/kubernetes/pull/92183), [@wallrj](https://github.com/wallrj)) [SIG Cluster Lifecycle] -- Kubeadm: make etcd pod request 100m CPU, 100Mi memory and 100Mi ephemeral_storage by default ([#94479](https://github.com/kubernetes/kubernetes/pull/94479), [@knight42](https://github.com/knight42)) [SIG Cluster Lifecycle] -- Kubemark now supports both real and hollow nodes in a single cluster. ([#93201](https://github.com/kubernetes/kubernetes/pull/93201), [@ellistarn](https://github.com/ellistarn)) [SIG Scalability] -- Kubernetes is now built using go1.15.2 - - build: Update to k/repo-infra@v0.1.1 (supports go1.15.2) - - build: Use go-runner:buster-v2.0.1 (built using go1.15.1) - - bazel: Replace --features with Starlark build settings flag - - hack/lib/util.sh: some bash cleanups - - - switched one spot to use kube::logging - - make kube::util::find-binary return an error when it doesn't find - anything so that hack scripts fail fast instead of with '' binary not - found errors. - - this required deleting some genfeddoc stuff. the binary no longer - exists in k/k repo since we removed federation/, and I don't see it - in https://github.com/kubernetes-sigs/kubefed/ either. I'm assuming - that it's gone for good now. - - - bazel: output go_binary rule directly from go_binary_conditional_pure - - From: @mikedanese: - Instead of aliasing. Aliases are annoying in a number of ways. This is - specifically bugging me now because they make the action graph harder to - analyze programmatically. By using aliases here, we would need to handle - potentially aliased go_binary targets and dereference to the effective - target. - - The comment references an issue with `pure = select(...)` which appears - to be resolved considering this now builds. - - - make kube::util::find-binary not dependent on bazel-out/ structure - - Implement an aspect that outputs go_build_mode metadata for go binaries, - and use that during binary selection. ([#94449](https://github.com/kubernetes/kubernetes/pull/94449), [@justaugustus](https://github.com/justaugustus)) [SIG Architecture, CLI, Cluster Lifecycle, Node, Release and Testing] -- Only update Azure data disks when attach/detach ([#94265](https://github.com/kubernetes/kubernetes/pull/94265), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Promote SupportNodePidsLimit to GA to provide node to pod pid isolation - Promote SupportPodPidsLimit to GA to provide ability to limit pids per pod ([#94140](https://github.com/kubernetes/kubernetes/pull/94140), [@derekwaynecarr](https://github.com/derekwaynecarr)) [SIG Node and Testing] -- Rename pod_preemption_metrics to preemption_metrics. ([#93256](https://github.com/kubernetes/kubernetes/pull/93256), [@ahg-g](https://github.com/ahg-g)) [SIG Instrumentation and Scheduling] -- Server-side apply behavior has been regularized in the case where a field is removed from the applied configuration. Removed fields which have no other owners are deleted from the live object, or reset to their default value if they have one. Safe ownership transfers, such as the transfer of a `replicas` field from a user to an HPA without resetting to the default value are documented in [Transferring Ownership](/docs/reference/using-api/server-side-apply/#transferring-ownership) ([#92661](https://github.com/kubernetes/kubernetes/pull/92661), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Testing] -- Set CSIMigrationvSphere feature gates to beta. - Users should enable CSIMigration + CSIMigrationvSphere features and install the vSphere CSI Driver (https://github.com/kubernetes-sigs/vsphere-csi-driver) to move workload from the in-tree vSphere plugin "kubernetes.io/vsphere-volume" to vSphere CSI Driver. - - Requires: vSphere vCenter/ESXi Version: 7.0u1, HW Version: VM version 15 ([#92816](https://github.com/kubernetes/kubernetes/pull/92816), [@divyenpatel](https://github.com/divyenpatel)) [SIG Cloud Provider and Storage] -- Support [service.beta.kubernetes.io/azure-pip-ip-tags] annotations to allow customers to specify ip-tags to influence public-ip creation in Azure [Tag1=Value1, Tag2=Value2, etc.] ([#94114](https://github.com/kubernetes/kubernetes/pull/94114), [@MarcPow](https://github.com/MarcPow)) [SIG Cloud Provider] -- Support a smooth upgrade from client-side apply to server-side apply without conflicts, as well as support the corresponding downgrade. ([#90187](https://github.com/kubernetes/kubernetes/pull/90187), [@julianvmodesto](https://github.com/julianvmodesto)) [SIG API Machinery and Testing] -- Trace output in apiserver logs is more organized and comprehensive. Traces are nested, and for all non-long running request endpoints, the entire filter chain is instrumented (e.g. authentication check is included). ([#88936](https://github.com/kubernetes/kubernetes/pull/88936), [@jpbetz](https://github.com/jpbetz)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Scheduling] -- `kubectl alpha debug` now supports debugging nodes by creating a debugging container running in the node's host namespaces. ([#92310](https://github.com/kubernetes/kubernetes/pull/92310), [@verb](https://github.com/verb)) [SIG CLI] - -### Documentation - -- Kubelet: remove alpha warnings for CNI flags. ([#94508](https://github.com/kubernetes/kubernetes/pull/94508), [@andrewsykim](https://github.com/andrewsykim)) [SIG Network and Node] - -### Failing Test - -- Kube-proxy iptables min-sync-period defaults to 1 sec. Previously, it was 0. ([#92836](https://github.com/kubernetes/kubernetes/pull/92836), [@aojea](https://github.com/aojea)) [SIG Network] - -### Bug or Regression - -- A panic in the apiserver caused by the `informer-sync` health checker is now fixed. ([#93600](https://github.com/kubernetes/kubernetes/pull/93600), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG API Machinery] -- Add kubectl wait --ignore-not-found flag ([#90969](https://github.com/kubernetes/kubernetes/pull/90969), [@zhouya0](https://github.com/zhouya0)) [SIG CLI] -- Adding fix to the statefulset controller to wait for pvc deletion before creating pods. ([#93457](https://github.com/kubernetes/kubernetes/pull/93457), [@ymmt2005](https://github.com/ymmt2005)) [SIG Apps] -- Azure ARM client: don't segfault on empty response and http error ([#94078](https://github.com/kubernetes/kubernetes/pull/94078), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider] -- Azure: fix a bug that kube-controller-manager would panic if wrong Azure VMSS name is configured ([#94306](https://github.com/kubernetes/kubernetes/pull/94306), [@knight42](https://github.com/knight42)) [SIG Cloud Provider] -- Azure: per VMSS VMSS VMs cache to prevent throttling on clusters having many attached VMSS ([#93107](https://github.com/kubernetes/kubernetes/pull/93107), [@bpineau](https://github.com/bpineau)) [SIG Cloud Provider] -- Both apiserver_request_duration_seconds metrics and RequestReceivedTimestamp field of an audit event take - into account the time a request spends in the apiserver request filters. ([#94903](https://github.com/kubernetes/kubernetes/pull/94903), [@tkashem](https://github.com/tkashem)) [SIG API Machinery, Auth and Instrumentation] -- Build/lib/release: Explicitly use '--platform' in building server images - - When we switched to go-runner for building the apiserver, - controller-manager, and scheduler server components, we no longer - reference the individual architectures in the image names, specifically - in the 'FROM' directive of the server image Dockerfiles. - - As a result, server images for non-amd64 images copy in the go-runner - amd64 binary instead of the go-runner that matches that architecture. - - This commit explicitly sets the '--platform=linux/${arch}' to ensure - we're pulling the correct go-runner arch from the manifest list. - - Before: - `FROM ${base_image}` - - After: - `FROM --platform=linux/${arch} ${base_image}` ([#94552](https://github.com/kubernetes/kubernetes/pull/94552), [@justaugustus](https://github.com/justaugustus)) [SIG Release] -- CSIDriver object can be deployed during volume attachment. ([#93710](https://github.com/kubernetes/kubernetes/pull/93710), [@Jiawei0227](https://github.com/Jiawei0227)) [SIG Apps, Node, Storage and Testing] -- CVE-2020-8557 (Medium): Node-local denial of service via container /etc/hosts file. See https://github.com/kubernetes/kubernetes/issues/93032 for more details. ([#92916](https://github.com/kubernetes/kubernetes/pull/92916), [@joelsmith](https://github.com/joelsmith)) [SIG Node] -- Do not add nodes labeled with kubernetes.azure.com/managed=false to backend pool of load balancer. ([#93034](https://github.com/kubernetes/kubernetes/pull/93034), [@matthias50](https://github.com/matthias50)) [SIG Cloud Provider] -- Do not fail sorting empty elements. ([#94666](https://github.com/kubernetes/kubernetes/pull/94666), [@soltysh](https://github.com/soltysh)) [SIG CLI] -- Do not retry volume expansion if CSI driver returns FailedPrecondition error ([#92986](https://github.com/kubernetes/kubernetes/pull/92986), [@gnufied](https://github.com/gnufied)) [SIG Node and Storage] -- Dockershim security: pod sandbox now always run with `no-new-privileges` and `runtime/default` seccomp profile - dockershim seccomp: custom profiles can now have smaller seccomp profiles when set at pod level ([#90948](https://github.com/kubernetes/kubernetes/pull/90948), [@pjbgf](https://github.com/pjbgf)) [SIG Node] -- Dual-stack: make nodeipam compatible with existing single-stack clusters when dual-stack feature gate become enabled by default ([#90439](https://github.com/kubernetes/kubernetes/pull/90439), [@SataQiu](https://github.com/SataQiu)) [SIG API Machinery] -- Endpoint controller requeues service after an endpoint deletion event occurs to confirm that deleted endpoints are undesired to mitigate the effects of an out of sync endpoint cache. ([#93030](https://github.com/kubernetes/kubernetes/pull/93030), [@swetharepakula](https://github.com/swetharepakula)) [SIG Apps and Network] -- EndpointSlice controllers now return immediately if they encounter an error creating, updating, or deleting resources. ([#93908](https://github.com/kubernetes/kubernetes/pull/93908), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- EndpointSliceMirroring controller now copies labels from Endpoints to EndpointSlices. ([#93442](https://github.com/kubernetes/kubernetes/pull/93442), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- EndpointSliceMirroring controller now mirrors Endpoints that do not have a Service associated with them. ([#94171](https://github.com/kubernetes/kubernetes/pull/94171), [@robscott](https://github.com/robscott)) [SIG Apps, Network and Testing] -- Ensure backoff step is set to 1 for Azure armclient. ([#94180](https://github.com/kubernetes/kubernetes/pull/94180), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Ensure getPrimaryInterfaceID not panic when network interfaces for Azure VMSS are null ([#94355](https://github.com/kubernetes/kubernetes/pull/94355), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Eviction requests for pods that have a non-zero DeletionTimestamp will always succeed ([#91342](https://github.com/kubernetes/kubernetes/pull/91342), [@michaelgugino](https://github.com/michaelgugino)) [SIG Apps] -- Extended DSR loadbalancer feature in winkernel kube-proxy to HNS versions 9.3-9.max, 10.2+ ([#93080](https://github.com/kubernetes/kubernetes/pull/93080), [@elweb9858](https://github.com/elweb9858)) [SIG Network] -- Fix HandleCrash order ([#93108](https://github.com/kubernetes/kubernetes/pull/93108), [@lixiaobing1](https://github.com/lixiaobing1)) [SIG API Machinery] -- Fix a concurrent map writes error in kubelet ([#93773](https://github.com/kubernetes/kubernetes/pull/93773), [@knight42](https://github.com/knight42)) [SIG Node] -- Fix a regression where kubeadm bails out with a fatal error when an optional version command line argument is supplied to the "kubeadm upgrade plan" command ([#94421](https://github.com/kubernetes/kubernetes/pull/94421), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle] -- Fix azure file migration panic ([#94853](https://github.com/kubernetes/kubernetes/pull/94853), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix bug where loadbalancer deletion gets stuck because of missing resource group #75198 ([#93962](https://github.com/kubernetes/kubernetes/pull/93962), [@phiphi282](https://github.com/phiphi282)) [SIG Cloud Provider] -- Fix calling AttachDisk on a previously attached EBS volume ([#93567](https://github.com/kubernetes/kubernetes/pull/93567), [@gnufied](https://github.com/gnufied)) [SIG Cloud Provider, Storage and Testing] -- Fix detection of image filesystem, disk metrics for devicemapper, detection of OOM Kills on 5.0+ linux kernels. ([#92919](https://github.com/kubernetes/kubernetes/pull/92919), [@dashpole](https://github.com/dashpole)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation and Node] -- Fix etcd_object_counts metric reported by kube-apiserver ([#94773](https://github.com/kubernetes/kubernetes/pull/94773), [@tkashem](https://github.com/tkashem)) [SIG API Machinery] -- Fix incorrectly reported verbs for kube-apiserver metrics for CRD objects ([#93523](https://github.com/kubernetes/kubernetes/pull/93523), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Instrumentation] -- Fix instance not found issues when an Azure Node is recreated in a short time ([#93316](https://github.com/kubernetes/kubernetes/pull/93316), [@feiskyer](https://github.com/feiskyer)) [SIG Cloud Provider] -- Fix kube-apiserver /readyz to contain "informer-sync" check ensuring that internal informers are synced. ([#93670](https://github.com/kubernetes/kubernetes/pull/93670), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Testing] -- Fix kubectl SchemaError on CRDs with schema using x-kubernetes-preserve-unknown-fields on array types. ([#94888](https://github.com/kubernetes/kubernetes/pull/94888), [@sttts](https://github.com/sttts)) [SIG API Machinery] -- Fix memory leak in EndpointSliceTracker for EndpointSliceMirroring controller. ([#93441](https://github.com/kubernetes/kubernetes/pull/93441), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- Fix missing csi annotations on node during parallel csinode update. ([#94389](https://github.com/kubernetes/kubernetes/pull/94389), [@pacoxu](https://github.com/pacoxu)) [SIG Storage] -- Fix the `cloudprovider_azure_api_request_duration_seconds` metric buckets to correctly capture the latency metrics. Previously, the majority of the calls would fall in the "+Inf" bucket. ([#94873](https://github.com/kubernetes/kubernetes/pull/94873), [@marwanad](https://github.com/marwanad)) [SIG Cloud Provider and Instrumentation] -- Fix: azure disk resize error if source does not exist ([#93011](https://github.com/kubernetes/kubernetes/pull/93011), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix: detach azure disk broken on Azure Stack ([#94885](https://github.com/kubernetes/kubernetes/pull/94885), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fix: determine the correct ip config based on ip family ([#93043](https://github.com/kubernetes/kubernetes/pull/93043), [@aramase](https://github.com/aramase)) [SIG Cloud Provider] -- Fix: initial delay in mounting azure disk & file ([#93052](https://github.com/kubernetes/kubernetes/pull/93052), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fix: use sensitiveOptions on Windows mount ([#94126](https://github.com/kubernetes/kubernetes/pull/94126), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider and Storage] -- Fixed Ceph RBD volume expansion when no ceph.conf exists ([#92027](https://github.com/kubernetes/kubernetes/pull/92027), [@juliantaylor](https://github.com/juliantaylor)) [SIG Storage] -- Fixed a bug where improper storage and comparison of endpoints led to excessive API traffic from the endpoints controller ([#94112](https://github.com/kubernetes/kubernetes/pull/94112), [@damemi](https://github.com/damemi)) [SIG Apps, Network and Testing] -- Fixed a bug whereby the allocation of reusable CPUs and devices was not being honored when the TopologyManager was enabled ([#93189](https://github.com/kubernetes/kubernetes/pull/93189), [@klueska](https://github.com/klueska)) [SIG Node] -- Fixed a panic in kubectl debug when pod has multiple init containers or ephemeral containers ([#94580](https://github.com/kubernetes/kubernetes/pull/94580), [@kiyoshim55](https://github.com/kiyoshim55)) [SIG CLI] -- Fixed a regression that sometimes prevented `kubectl portforward` to work when TCP and UDP services were configured on the same port ([#94728](https://github.com/kubernetes/kubernetes/pull/94728), [@amorenoz](https://github.com/amorenoz)) [SIG CLI] -- Fixed bug in reflector that couldn't recover from "Too large resource version" errors with API servers 1.17.0-1.18.5 ([#94316](https://github.com/kubernetes/kubernetes/pull/94316), [@janeczku](https://github.com/janeczku)) [SIG API Machinery] -- Fixed bug where kubectl top pod output is not sorted when --sort-by and --containers flags are used together ([#93692](https://github.com/kubernetes/kubernetes/pull/93692), [@brianpursley](https://github.com/brianpursley)) [SIG CLI] -- Fixed kubelet creating extra sandbox for pods with RestartPolicyOnFailure after all containers succeeded ([#92614](https://github.com/kubernetes/kubernetes/pull/92614), [@tnqn](https://github.com/tnqn)) [SIG Node and Testing] -- Fixed memory leak in endpointSliceTracker ([#92838](https://github.com/kubernetes/kubernetes/pull/92838), [@tnqn](https://github.com/tnqn)) [SIG Apps and Network] -- Fixed node data lost in kube-scheduler for clusters with imbalance on number of nodes across zones ([#93355](https://github.com/kubernetes/kubernetes/pull/93355), [@maelk](https://github.com/maelk)) [SIG Scheduling] -- Fixed the EndpointSliceController to correctly create endpoints for IPv6-only pods. - - Fixed the EndpointController to allow IPv6 headless services, if the IPv6DualStack - feature gate is enabled, by specifying `ipFamily: IPv6` on the service. (This already - worked with the EndpointSliceController.) ([#91399](https://github.com/kubernetes/kubernetes/pull/91399), [@danwinship](https://github.com/danwinship)) [SIG Apps and Network] -- Fixes a bug evicting pods after a taint with a limited tolerationSeconds toleration is removed from a node ([#93722](https://github.com/kubernetes/kubernetes/pull/93722), [@liggitt](https://github.com/liggitt)) [SIG Apps and Node] -- Fixes a bug where EndpointSlices would not be recreated after rapid Service recreation. ([#94730](https://github.com/kubernetes/kubernetes/pull/94730), [@robscott](https://github.com/robscott)) [SIG Apps, Network and Testing] -- Fixes a race condition in kubelet pod handling ([#94751](https://github.com/kubernetes/kubernetes/pull/94751), [@auxten](https://github.com/auxten)) [SIG Node] -- Fixes an issue proxying to ipv6 pods without specifying a port ([#94834](https://github.com/kubernetes/kubernetes/pull/94834), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Network] -- Fixes an issue that can result in namespaced custom resources being orphaned when their namespace is deleted, if the CRD defining the custom resource is removed concurrently with namespaces being deleted, then recreated. ([#93790](https://github.com/kubernetes/kubernetes/pull/93790), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and Apps] -- Ignore root user check when windows pod starts ([#92355](https://github.com/kubernetes/kubernetes/pull/92355), [@wawa0210](https://github.com/wawa0210)) [SIG Node and Windows] -- Increased maximum IOPS of AWS EBS io1 volumes to 64,000 (current AWS maximum). ([#90014](https://github.com/kubernetes/kubernetes/pull/90014), [@jacobmarble](https://github.com/jacobmarble)) [SIG Cloud Provider and Storage] -- K8s.io/apimachinery: runtime.DefaultUnstructuredConverter.FromUnstructured now handles converting integer fields to typed float values ([#93250](https://github.com/kubernetes/kubernetes/pull/93250), [@liggitt](https://github.com/liggitt)) [SIG API Machinery] -- Kube-aggregator certificates are dynamically loaded on change from disk ([#92791](https://github.com/kubernetes/kubernetes/pull/92791), [@p0lyn0mial](https://github.com/p0lyn0mial)) [SIG API Machinery] -- Kube-apiserver: fixed a bug returning inconsistent results from list requests which set a field or label selector and set a paging limit ([#94002](https://github.com/kubernetes/kubernetes/pull/94002), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery] -- Kube-apiserver: jsonpath expressions with consecutive recursive descent operators are no longer evaluated for custom resource printer columns ([#93408](https://github.com/kubernetes/kubernetes/pull/93408), [@joelsmith](https://github.com/joelsmith)) [SIG API Machinery] -- Kube-proxy now trims extra spaces found in loadBalancerSourceRanges to match Service validation. ([#94107](https://github.com/kubernetes/kubernetes/pull/94107), [@robscott](https://github.com/robscott)) [SIG Network] -- Kube-up now includes CoreDNS version v1.7.0. Some of the major changes include: - - Fixed a bug that could cause CoreDNS to stop updating service records. - - Fixed a bug in the forward plugin where only the first upstream server is always selected no matter which policy is set. - - Remove already deprecated options `resyncperiod` and `upstream` in the Kubernetes plugin. - - Includes Prometheus metrics name changes (to bring them in line with standard Prometheus metrics naming convention). They will be backward incompatible with existing reporting formulas that use the old metrics' names. - - The federation plugin (allows for v1 Kubernetes federation) has been removed. - More details are available in https://coredns.io/2020/06/15/coredns-1.7.0-release/ ([#92718](https://github.com/kubernetes/kubernetes/pull/92718), [@rajansandeep](https://github.com/rajansandeep)) [SIG Cloud Provider] -- Kubeadm now makes sure the etcd manifest is regenerated upon upgrade even when no etcd version change takes place ([#94395](https://github.com/kubernetes/kubernetes/pull/94395), [@rosti](https://github.com/rosti)) [SIG Cluster Lifecycle] -- Kubeadm: avoid a panic when determining if the running version of CoreDNS is supported during upgrades ([#94299](https://github.com/kubernetes/kubernetes/pull/94299), [@zouyee](https://github.com/zouyee)) [SIG Cluster Lifecycle] -- Kubeadm: ensure "kubeadm reset" does not unmount the root "/var/lib/kubelet" directory if it is mounted by the user ([#93702](https://github.com/kubernetes/kubernetes/pull/93702), [@thtanaka](https://github.com/thtanaka)) [SIG Cluster Lifecycle] -- Kubeadm: ensure the etcd data directory is created with 0700 permissions during control-plane init and join ([#94102](https://github.com/kubernetes/kubernetes/pull/94102), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: fix the bug that kubeadm tries to call 'docker info' even if the CRI socket was for another CR ([#94555](https://github.com/kubernetes/kubernetes/pull/94555), [@SataQiu](https://github.com/SataQiu)) [SIG Cluster Lifecycle] -- Kubeadm: make the kubeconfig files for the kube-controller-manager and kube-scheduler use the LocalAPIEndpoint instead of the ControlPlaneEndpoint. This makes kubeadm clusters more reseliant to version skew problems during immutable upgrades: https://kubernetes.io/docs/setup/release/version-skew-policy/#kube-controller-manager-kube-scheduler-and-cloud-controller-manager ([#94398](https://github.com/kubernetes/kubernetes/pull/94398), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: relax the validation of kubeconfig server URLs. Allow the user to define custom kubeconfig server URLs without erroring out during validation of existing kubeconfig files (e.g. when using external CA mode). ([#94816](https://github.com/kubernetes/kubernetes/pull/94816), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubeadm: remove duplicate DNS names and IP addresses from generated certificates ([#92753](https://github.com/kubernetes/kubernetes/pull/92753), [@QianChenglong](https://github.com/QianChenglong)) [SIG Cluster Lifecycle] -- Kubelet: assume that swap is disabled when `/proc/swaps` does not exist ([#93931](https://github.com/kubernetes/kubernetes/pull/93931), [@SataQiu](https://github.com/SataQiu)) [SIG Node] -- Kubelet: fix race condition in pluginWatcher ([#93622](https://github.com/kubernetes/kubernetes/pull/93622), [@knight42](https://github.com/knight42)) [SIG Node] -- Kuberuntime security: pod sandbox now always runs with `runtime/default` seccomp profile - kuberuntime seccomp: custom profiles can now have smaller seccomp profiles when set at pod level ([#90949](https://github.com/kubernetes/kubernetes/pull/90949), [@pjbgf](https://github.com/pjbgf)) [SIG Node] -- NONE ([#71269](https://github.com/kubernetes/kubernetes/pull/71269), [@DeliangFan](https://github.com/DeliangFan)) [SIG Node] -- New Azure instance types do now have correct max data disk count information. ([#94340](https://github.com/kubernetes/kubernetes/pull/94340), [@ialidzhikov](https://github.com/ialidzhikov)) [SIG Cloud Provider and Storage] -- Pods with invalid Affinity/AntiAffinity LabelSelectors will now fail scheduling when these plugins are enabled ([#93660](https://github.com/kubernetes/kubernetes/pull/93660), [@damemi](https://github.com/damemi)) [SIG Scheduling] -- Require feature flag CustomCPUCFSQuotaPeriod if setting a non-default cpuCFSQuotaPeriod in kubelet config. ([#94687](https://github.com/kubernetes/kubernetes/pull/94687), [@karan](https://github.com/karan)) [SIG Node] -- Reverted devicemanager for Windows node added in 1.19rc1. ([#93263](https://github.com/kubernetes/kubernetes/pull/93263), [@liggitt](https://github.com/liggitt)) [SIG Node and Windows] -- Scheduler bugfix: Scheduler doesn't lose pod information when nodes are quickly recreated. This could happen when nodes are restarted or quickly recreated reusing a nodename. ([#93938](https://github.com/kubernetes/kubernetes/pull/93938), [@alculquicondor](https://github.com/alculquicondor)) [SIG Scalability, Scheduling and Testing] -- The EndpointSlice controller now waits for EndpointSlice and Node caches to be synced before starting. ([#94086](https://github.com/kubernetes/kubernetes/pull/94086), [@robscott](https://github.com/robscott)) [SIG Apps and Network] -- The `/debug/api_priority_and_fairness/dump_requests` path at an apiserver will no longer return a phantom line for each exempt priority level. ([#93406](https://github.com/kubernetes/kubernetes/pull/93406), [@MikeSpreitzer](https://github.com/MikeSpreitzer)) [SIG API Machinery] -- The kubelet recognizes the --containerd-namespace flag to configure the namespace used by cadvisor. ([#87054](https://github.com/kubernetes/kubernetes/pull/87054), [@changyaowei](https://github.com/changyaowei)) [SIG Node] -- The terminationGracePeriodSeconds from pod spec is respected for the mirror pod. ([#92442](https://github.com/kubernetes/kubernetes/pull/92442), [@tedyu](https://github.com/tedyu)) [SIG Node and Testing] -- Update Calico to v3.15.2 ([#94241](https://github.com/kubernetes/kubernetes/pull/94241), [@lmm](https://github.com/lmm)) [SIG Cloud Provider] -- Update default etcd server version to 3.4.13 ([#94287](https://github.com/kubernetes/kubernetes/pull/94287), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cloud Provider, Cluster Lifecycle and Testing] -- Updated Cluster Autoscaler to 1.19.0; ([#93577](https://github.com/kubernetes/kubernetes/pull/93577), [@vivekbagade](https://github.com/vivekbagade)) [SIG Autoscaling and Cloud Provider] -- Use NLB Subnet CIDRs instead of VPC CIDRs in Health Check SG Rules ([#93515](https://github.com/kubernetes/kubernetes/pull/93515), [@t0rr3sp3dr0](https://github.com/t0rr3sp3dr0)) [SIG Cloud Provider] -- Users will see increase in time for deletion of pods and also guarantee that removal of pod from api server would mean deletion of all the resources from container runtime. ([#92817](https://github.com/kubernetes/kubernetes/pull/92817), [@kmala](https://github.com/kmala)) [SIG Node] -- Very large patches may now be specified to `kubectl patch` with the `--patch-file` flag instead of including them directly on the command line. The `--patch` and `--patch-file` flags are mutually exclusive. ([#93548](https://github.com/kubernetes/kubernetes/pull/93548), [@smarterclayton](https://github.com/smarterclayton)) [SIG CLI] -- When creating a networking.k8s.io/v1 Ingress API object, `spec.rules[*].http` values are now validated consistently when the `host` field contains a wildcard. ([#93954](https://github.com/kubernetes/kubernetes/pull/93954), [@Miciah](https://github.com/Miciah)) [SIG CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Network, Storage and Testing] - -### Other (Cleanup or Flake) - -- --cache-dir sets cache directory for both http and discovery, defaults to $HOME/.kube/cache ([#92910](https://github.com/kubernetes/kubernetes/pull/92910), [@soltysh](https://github.com/soltysh)) [SIG API Machinery and CLI] -- Adds a bootstrapping ClusterRole, ClusterRoleBinding and group for /metrics, /livez/*, /readyz/*, & /healthz/- endpoints. ([#93311](https://github.com/kubernetes/kubernetes/pull/93311), [@logicalhan](https://github.com/logicalhan)) [SIG API Machinery, Auth, Cloud Provider and Instrumentation] -- Base-images: Update to debian-iptables:buster-v1.3.0 - - Uses iptables 1.8.5 - - base-images: Update to debian-base:buster-v1.2.0 - - cluster/images/etcd: Build etcd:3.4.13-1 image - - Uses debian-base:buster-v1.2.0 ([#94733](https://github.com/kubernetes/kubernetes/pull/94733), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Release and Testing] -- Build: Update to debian-base@v2.1.2 and debian-iptables@v12.1.1 ([#93667](https://github.com/kubernetes/kubernetes/pull/93667), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Release and Testing] -- Build: Update to debian-base@v2.1.3 and debian-iptables@v12.1.2 ([#93916](https://github.com/kubernetes/kubernetes/pull/93916), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, Release and Testing] -- Build: Update to go-runner:buster-v2.0.0 ([#94167](https://github.com/kubernetes/kubernetes/pull/94167), [@justaugustus](https://github.com/justaugustus)) [SIG Release] -- Fix kubelet to properly log when a container is started. Before, sometimes the log said that a container is dead and was restarted when it was started for the first time. This only happened when using pods with initContainers and regular containers. ([#91469](https://github.com/kubernetes/kubernetes/pull/91469), [@rata](https://github.com/rata)) [SIG Node] -- Fix: license issue in blob disk feature ([#92824](https://github.com/kubernetes/kubernetes/pull/92824), [@andyzhangx](https://github.com/andyzhangx)) [SIG Cloud Provider] -- Fixes the flooding warning messages about setting volume ownership for configmap/secret volumes ([#92878](https://github.com/kubernetes/kubernetes/pull/92878), [@jvanz](https://github.com/jvanz)) [SIG Instrumentation, Node and Storage] -- Fixes the message about no auth for metrics in scheduler. ([#94035](https://github.com/kubernetes/kubernetes/pull/94035), [@zhouya0](https://github.com/zhouya0)) [SIG Scheduling] -- Kube-up: defaults to limiting critical pods to the kube-system namespace to match behavior prior to 1.17 ([#93121](https://github.com/kubernetes/kubernetes/pull/93121), [@liggitt](https://github.com/liggitt)) [SIG Cloud Provider and Scheduling] -- Kubeadm: Separate argument key/value in log msg ([#94016](https://github.com/kubernetes/kubernetes/pull/94016), [@mrueg](https://github.com/mrueg)) [SIG Cluster Lifecycle] -- Kubeadm: remove support for the "ci/k8s-master" version label. This label has been removed in the Kubernetes CI release process and would no longer work in kubeadm. You can use the "ci/latest" version label instead. See kubernetes/test-infra#18517 ([#93626](https://github.com/kubernetes/kubernetes/pull/93626), [@vikkyomkar](https://github.com/vikkyomkar)) [SIG Cluster Lifecycle] -- Kubeadm: remove the CoreDNS check for known image digests when applying the addon ([#94506](https://github.com/kubernetes/kubernetes/pull/94506), [@neolit123](https://github.com/neolit123)) [SIG Cluster Lifecycle] -- Kubernetes is now built with go1.15.0 ([#93939](https://github.com/kubernetes/kubernetes/pull/93939), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing] -- Kubernetes is now built with go1.15.0-rc.2 ([#93827](https://github.com/kubernetes/kubernetes/pull/93827), [@justaugustus](https://github.com/justaugustus)) [SIG API Machinery, CLI, Cloud Provider, Cluster Lifecycle, Instrumentation, Node, Release and Testing] -- Lock ExternalPolicyForExternalIP to default, this feature gate will be removed in 1.22. ([#94581](https://github.com/kubernetes/kubernetes/pull/94581), [@knabben](https://github.com/knabben)) [SIG Network] -- Service.beta.kubernetes.io/azure-load-balancer-disable-tcp-reset is removed. All Standard load balancers will always enable tcp resets. ([#94297](https://github.com/kubernetes/kubernetes/pull/94297), [@MarcPow](https://github.com/MarcPow)) [SIG Cloud Provider] -- Stop propagating SelfLink (deprecated in 1.16) in kube-apiserver ([#94397](https://github.com/kubernetes/kubernetes/pull/94397), [@wojtek-t](https://github.com/wojtek-t)) [SIG API Machinery and Testing] -- Strip unnecessary security contexts on Windows ([#93475](https://github.com/kubernetes/kubernetes/pull/93475), [@ravisantoshgudimetla](https://github.com/ravisantoshgudimetla)) [SIG Node, Testing and Windows] -- To ensure the code be strong, add unit test for GetAddressAndDialer ([#93180](https://github.com/kubernetes/kubernetes/pull/93180), [@FreeZhang61](https://github.com/FreeZhang61)) [SIG Node] -- Update CNI plugins to v0.8.7 ([#94367](https://github.com/kubernetes/kubernetes/pull/94367), [@justaugustus](https://github.com/justaugustus)) [SIG Cloud Provider, Network, Node, Release and Testing] -- Update Golang to v1.14.5 - - Update repo-infra to 0.0.7 (to support go1.14.5 and go1.13.13) - - Includes: - - bazelbuild/bazel-toolchains@3.3.2 - - bazelbuild/rules_go@v0.22.7 ([#93088](https://github.com/kubernetes/kubernetes/pull/93088), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing] -- Update Golang to v1.14.6 - - Update repo-infra to 0.0.8 (to support go1.14.6 and go1.13.14) - - Includes: - - bazelbuild/bazel-toolchains@3.4.0 - - bazelbuild/rules_go@v0.22.8 ([#93198](https://github.com/kubernetes/kubernetes/pull/93198), [@justaugustus](https://github.com/justaugustus)) [SIG Release and Testing] -- Update cri-tools to [v1.19.0](https://github.com/kubernetes-sigs/cri-tools/releases/tag/v1.19.0) ([#94307](https://github.com/kubernetes/kubernetes/pull/94307), [@xmudrii](https://github.com/xmudrii)) [SIG Cloud Provider] -- Update default etcd server version to 3.4.9 ([#92349](https://github.com/kubernetes/kubernetes/pull/92349), [@jingyih](https://github.com/jingyih)) [SIG API Machinery, Cloud Provider, Cluster Lifecycle and Testing] -- Update etcd client side to v3.4.13 ([#94259](https://github.com/kubernetes/kubernetes/pull/94259), [@jingyih](https://github.com/jingyih)) [SIG API Machinery and Cloud Provider] -- `kubectl get ingress` now prefers the `networking.k8s.io/v1` over `extensions/v1beta1` (deprecated since v1.14). To explicitly request the deprecated version, use `kubectl get ingress.v1beta1.extensions`. ([#94309](https://github.com/kubernetes/kubernetes/pull/94309), [@liggitt](https://github.com/liggitt)) [SIG API Machinery and CLI] - -## Dependencies - -### Added -- github.com/Azure/go-autorest: [v14.2.0+incompatible](https://github.com/Azure/go-autorest/tree/v14.2.0) -- github.com/fvbommel/sortorder: [v1.0.1](https://github.com/fvbommel/sortorder/tree/v1.0.1) -- github.com/yuin/goldmark: [v1.1.27](https://github.com/yuin/goldmark/tree/v1.1.27) -- sigs.k8s.io/structured-merge-diff/v4: v4.0.1 - -### Changed -- github.com/Azure/go-autorest/autorest/adal: [v0.8.2 → v0.9.0](https://github.com/Azure/go-autorest/autorest/adal/compare/v0.8.2...v0.9.0) -- github.com/Azure/go-autorest/autorest/date: [v0.2.0 → v0.3.0](https://github.com/Azure/go-autorest/autorest/date/compare/v0.2.0...v0.3.0) -- github.com/Azure/go-autorest/autorest/mocks: [v0.3.0 → v0.4.0](https://github.com/Azure/go-autorest/autorest/mocks/compare/v0.3.0...v0.4.0) -- github.com/Azure/go-autorest/autorest: [v0.9.6 → v0.11.1](https://github.com/Azure/go-autorest/autorest/compare/v0.9.6...v0.11.1) -- github.com/Azure/go-autorest/logger: [v0.1.0 → v0.2.0](https://github.com/Azure/go-autorest/logger/compare/v0.1.0...v0.2.0) -- github.com/Azure/go-autorest/tracing: [v0.5.0 → v0.6.0](https://github.com/Azure/go-autorest/tracing/compare/v0.5.0...v0.6.0) -- github.com/Microsoft/hcsshim: [v0.8.9 → 5eafd15](https://github.com/Microsoft/hcsshim/compare/v0.8.9...5eafd15) -- github.com/cilium/ebpf: [9f1617e → 1c8d4c9](https://github.com/cilium/ebpf/compare/9f1617e...1c8d4c9) -- github.com/containerd/cgroups: [bf292b2 → 0dbf7f0](https://github.com/containerd/cgroups/compare/bf292b2...0dbf7f0) -- github.com/coredns/corefile-migration: [v1.0.8 → v1.0.10](https://github.com/coredns/corefile-migration/compare/v1.0.8...v1.0.10) -- github.com/evanphx/json-patch: [e83c0a1 → v4.9.0+incompatible](https://github.com/evanphx/json-patch/compare/e83c0a1...v4.9.0) -- github.com/google/cadvisor: [8450c56 → v0.37.0](https://github.com/google/cadvisor/compare/8450c56...v0.37.0) -- github.com/json-iterator/go: [v1.1.9 → v1.1.10](https://github.com/json-iterator/go/compare/v1.1.9...v1.1.10) -- github.com/opencontainers/go-digest: [v1.0.0-rc1 → v1.0.0](https://github.com/opencontainers/go-digest/compare/v1.0.0-rc1...v1.0.0) -- github.com/opencontainers/runc: [1b94395 → 819fcc6](https://github.com/opencontainers/runc/compare/1b94395...819fcc6) -- github.com/prometheus/client_golang: [v1.6.0 → v1.7.1](https://github.com/prometheus/client_golang/compare/v1.6.0...v1.7.1) -- github.com/prometheus/common: [v0.9.1 → v0.10.0](https://github.com/prometheus/common/compare/v0.9.1...v0.10.0) -- github.com/prometheus/procfs: [v0.0.11 → v0.1.3](https://github.com/prometheus/procfs/compare/v0.0.11...v0.1.3) -- github.com/rubiojr/go-vhd: [0bfd3b3 → 02e2102](https://github.com/rubiojr/go-vhd/compare/0bfd3b3...02e2102) -- github.com/storageos/go-api: [343b3ef → v2.2.0+incompatible](https://github.com/storageos/go-api/compare/343b3ef...v2.2.0) -- github.com/urfave/cli: [v1.22.1 → v1.22.2](https://github.com/urfave/cli/compare/v1.22.1...v1.22.2) -- go.etcd.io/etcd: 54ba958 → dd1b699 -- golang.org/x/crypto: bac4c82 → 75b2880 -- golang.org/x/mod: v0.1.0 → v0.3.0 -- golang.org/x/net: d3edc99 → ab34263 -- golang.org/x/tools: c00d67e → c1934b7 -- k8s.io/kube-openapi: 656914f → 6aeccd4 -- k8s.io/system-validators: v1.1.2 → v1.2.0 -- k8s.io/utils: 6e3d28b → d5654de - -### Removed -- github.com/godbus/dbus: [ade71ed](https://github.com/godbus/dbus/tree/ade71ed) -- github.com/xlab/handysort: [fb3537e](https://github.com/xlab/handysort/tree/fb3537e) -- sigs.k8s.io/structured-merge-diff/v3: v3.0.0 -- vbom.ml/util: db5cfe1 diff --git a/content/ko/docs/tasks/access-application-cluster/_index.md b/content/ko/docs/tasks/access-application-cluster/_index.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/tasks/access-application-cluster/access-cluster.md b/content/ko/docs/tasks/access-application-cluster/access-cluster.md index 43a6a82343..9e7c9b4fc7 100644 --- a/content/ko/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/access-cluster.md @@ -26,9 +26,9 @@ kubectl이 인지하는 위치정보와 인증정보는 다음 커맨드로 확 kubectl config view ``` -많은 [예제들](/ko/docs/reference/kubectl/cheatsheet/)에서 -kubectl을 사용하는 것을 소개하고 있으며 완전한 문서는 -[kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에서 찾아볼 수 있다. +[여기](/ko/docs/reference/kubectl/cheatsheet/)에서 +kubectl 사용 예시를 볼 수 있으며, 완전한 문서는 +[kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에서 확인할 수 있다. ## REST API에 직접 접근 @@ -44,12 +44,12 @@ REST API에 직접 접근하려고 한다면 위치 파악과 인증을 하는 - 앞으로는 클라이언트 측의 지능형 load balancing과 failover가 될 것이다. - 직접적으로 http 클라이언트에 위치정보와 인증정보를 제공. - 대안적인 접근 방식. - - proxy 사용과 혼동되는 몇 가지 타입의 클라이언트 code들과 같이 동작한다. - - MITM로부터 보호를 위해 root 인증서를 당신의 브라우저로 import해야 한다. + - proxy 사용과 혼동되는 몇 가지 타입의 클라이언트 코드와 같이 동작한다. + - MITM로부터 보호를 위해 root 인증서를 당신의 브라우저로 임포트해야 한다. ### kubectl proxy 사용 -다음 커맨드는 kubectl을 reverse proxy처럼 동작하는 모드를 실행한다. 이는 +다음 커맨드는 kubectl을 리버스 프록시(reverse proxy)처럼 동작하는 모드를 실행한다. 이는 apiserver의 위치지정과 인증을 처리한다. 다음과 같이 실행한다. @@ -205,7 +205,7 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. - 파드의 sidecar 컨테이너 내에서 `kubectl proxy`를 실행하거나, 컨테이너 내부에서 백그라운드 프로세스로 실행한다. - 이는 쿠버네티스 API를 파드의 localhost 인터페이스로 proxy하여 + 이는 쿠버네티스 API를 파드의 localhost 인터페이스로 프록시하여 해당 파드의 컨테이너 내에 다른 프로세스가 API에 접속할 수 있게 해준다. - Go 클라이언트 라이브러리를 이용하여 `rest.InClusterConfig()`와 `kubernetes.NewForConfig()` 함수들을 사용하도록 클라이언트를 만든다. 이는 apiserver의 위치지정과 인증을 처리한다. [예제](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go) @@ -215,47 +215,47 @@ apiserver의 인증서 제공을 검증하는데 사용되어야 한다. ## 클러스터에서 실행되는 서비스로 접근 이전 장은 쿠버네티스 API server 접속에 대한 내용을 다루었다. 이번 장은 -쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. 쿠버네티스에서 -[노드들](/ko/docs/concepts/architecture/nodes/), -[파드들](/ko/docs/concepts/workloads/pods/), -[서비스들](/ko/docs/concepts/services-networking/service/)은 -모두 자신의 IP들을 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 -클러스터 상의 노드 IP들, 파드 IP들, 서비스 IP들로 라우팅되지 않아서 접근을 +쿠버네티스 클러스터 상에서 실행되는 다른 서비스로의 연결을 다룰 것이다. + +쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/), +[파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두 +고유한 IP를 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 +클러스터 상의 노드 IP, 파드 IP, 서비스 IP로 라우팅되지 않아서 접근을 할 수 없을 것이다. ### 통신을 위한 방식들 -클러스터 외부에서 노드들, 파드들, 서비스들에 접속하는 데는 몇 가지 선택지들이 있다. +클러스터 외부에서 노드, 파드 및 서비스에 접속하기 위한 몇 가지 옵션이 있다. - 공인 IP를 통해 서비스에 접근. - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참조한다. - - 당신의 클러스터 환경에 따라 회사 네트워크에만 서비스를 노출하거나 - 인터넷으로 노출할 수 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. + - 클러스터 환경에 따라, 서비스는 회사 네트워크에만 노출되기도 하며, + 인터넷에 노출되는 경우도 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. 해당 서비스는 자체적으로 인증을 수행하는가? - - 파드들은 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면 - 해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택한 신규 서비스를 생성한다. + - 파드는 서비스 뒤에 위치시킨다. 레플리카들의 집합에서 특정 파드 하나에 debugging 같은 목적으로 접근하려면 + 해당 파드에 고유의 레이블을 붙이고 셀렉터에 해당 레이블을 선택하는 신규 서비스를 생성한다. - 대부분의 경우에는 애플리케이션 개발자가 노드 IP를 통해 직접 노드에 접근할 필요는 없다. - Proxy Verb를 사용하여 서비스, 노드, 파드에 접근. - 원격 서비스에 접근하기에 앞서 apiserver의 인증과 인가를 받아야 한다. - 서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 port에 + 서비스가 인터넷에 노출하기에 보안이 충분하지 않거나 노드 IP 상의 포트에 접근을 하려고 하거나 debugging을 하려면 이를 사용한다. - - 어떤 web 애플리케이션에서는 proxy가 문제를 일으킬 수 있다. + - 어떤 web 애플리케이션에서는 프록시가 문제를 일으킬 수 있다. - HTTP/HTTPS에서만 동작한다. - [여기](#수작업으로-apiserver-proxy-url들을-구축)에서 설명하고 있다. - 클러스터 내 노드 또는 파드에서 접근. - - 파드를 Running시킨 다음 [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다. - 해당 셸에서 다른 노드들, 파드들, 서비스들에 연결한다. + - 파드를 실행한 다음, [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)를 사용하여 해당 파드의 셸로 접속한다. + 해당 셸에서 다른 노드, 파드, 서비스에 연결한다. - 어떤 클러스터는 클러스터 내의 노드에 ssh 접속을 허용하기도 한다. 이런 클러스터에서는 클러스터 서비스에 접근도 가능하다. 이는 비표준 방식으로 특정 클러스터에서는 동작하지만 다른 클러스터에서는 동작하지 않을 수 있다. 브라우저와 다른 도구들이 설치되지 않았거나 설치되었을 수 있다. 클러스터 DNS가 동작하지 않을 수도 있다. -### 빌트인 서비스들의 발견 +### 빌트인 서비스 검색 -일반적으로 kube-system에 의해 클러스터 상에서 start되는 몇 가지 서비스들이 존재한다. -`kubectl cluster-info` 커맨드로 이 서비스들의 리스트를 볼 수 있다. +일반적으로 kube-system에 의해 클러스터에 실행되는 몇 가지 서비스가 있다. +`kubectl cluster-info` 커맨드로 이 서비스의 리스트를 볼 수 있다. ```shell kubectl cluster-info @@ -280,20 +280,20 @@ heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/servi #### 수작업으로 apiserver proxy URL을 구축 -위에서 언급한 것처럼 서비스의 proxy URL을 검색하는데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 해당 서비스에 +위에서 언급한 것처럼 서비스의 proxy URL을 검색하는 데 `kubectl cluster-info` 커맨드를 사용할 수 있다. 서비스 endpoint, 접미사, 매개변수를 포함하는 proxy URL을 생성하려면 해당 서비스에 `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`service_name[:port_name]`*`/proxy` 형식의 proxy URL을 덧붙인다. -당신이 port에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. +당신이 포트에 이름을 지정하지 않았다면 URL에 *port_name* 을 지정할 필요는 없다. 이름이 있는 포트와 이름이 없는 포트 모두에 대하여, *port_name* 이 들어갈 자리에 포트 번호를 기재할 수도 있다. -기본적으로 API server는 http를 사용하여 서비스를 proxy한다. https를 사용하려면 다음과 같이 서비스 네임의 접두사에 `https:`를 붙인다. +기본적으로 API server는 http를 사용하여 서비스를 프록시한다. https를 사용하려면 다음과 같이 서비스 네임의 접두사에 `https:`를 붙인다. `http://`*`kubernetes_master_address`*`/api/v1/namespaces/`*`namespace_name`*`/services/`*`https:service_name:[port_name]`*`/proxy` URL의 네임 부분에 지원되는 양식은 다음과 같다. -* `` - http를 사용하여 기본값 또는 이름이 없는 port로 proxy한다 -* `:` - http를 사용하여 지정된 port로 proxy한다 -* `https::` - https를 사용하여 기본값 또는 이름이 없는 port로 proxy한다(마지막 콜론:에 주의) -* `https::` - https를 사용하여 지정된 port로 proxy한다 +* `` - http를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. +* `:` - http를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다. +* `https::` - https를 사용하여 기본값 또는 이름이 없는 포트로 프록시한다. (마지막 콜론:에 주의) +* `https::` - https를 사용하여 지정된 포트 이름 또는 포트 번호로 프록시한다. ##### 예제들 @@ -326,38 +326,38 @@ URL의 네임 부분에 지원되는 양식은 다음과 같다. ## 요청 redirect -redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) proxy를 사용하기를 바란다. +redirect 기능은 deprecated되고 제거 되었다. 대신 (아래의) 프록시를 사용하기를 바란다. -## 다양한 Proxy들 +## 다양한 프록시들 -쿠버네티스를 사용하면서 당신이 접할 수 있는 몇 가지 다른 proxy들이 존재한다. +쿠버네티스를 사용하면서 당신이 접할 수 있는 몇 가지 다른 프록시들이 존재한다. 1. [kubectl proxy](#rest-api에-직접-접근): - 사용자의 데스크탑이나 파드 내에서 실행한다 - - localhost 주소에서 쿠버네티스 apiserver로 proxy한다 - - proxy하는 클라이언트는 HTTP를 사용한다 - - apiserver의 proxy는 HTTPS를 사용한다 + - localhost 주소에서 쿠버네티스 apiserver로 프록시한다 + - 프록시하는 클라이언트는 HTTP를 사용한다 + - apiserver의 프록시는 HTTPS를 사용한다 - apiserver를 위치지정한다 - 인증 header들을 추가한다 -1. [apiserver proxy](#빌트인-서비스들의-발견): +1. [apiserver proxy](#빌트인-서비스-검색): - apiserver 내의 빌트인 bastion이다 - - 다른 방식으로는 연결할 수 없는 클러스터 외부의 사용자를 클러스터 IP들로 연결한다 + - 다른 방식으로는 연결할 수 없는 클러스터 외부의 사용자를 클러스터 IP로 연결한다 - apiserver process들 내에서 실행된다 - - proxy하는 클라이언트는 HTTPS를 사용한다(또는 apiserver가 http로 구성되었다면 http) - - 타겟으로의 proxy는 가용정보를 사용하는 proxy에 의해서 HTTP 또는 HTTPS를 사용할 수도 있다 + - 프록시하는 클라이언트는 HTTPS를 사용한다(또는 apiserver가 http로 구성되었다면 http) + - 타겟으로의 프록시는 가용정보를 사용하는 프록시에 의해서 HTTP 또는 HTTPS를 사용할 수도 있다 - 노드, 파드, 서비스에 접근하는 데 사용될 수 있다 - 서비스에 접근하는 데 사용되면 load balacing한다 1. [kube proxy](/ko/docs/concepts/services-networking/service/#ips-and-vips): - 각 노드 상에서 실행된다 - - UDP와 TCP를 proxy한다 + - UDP와 TCP를 프록시한다 - HTTP를 인지하지 않는다 - load balancing을 제공한다 - - 서비스에 접근하는 데만 사용된다 + - 서비스에 접근하는 데에만 사용된다 1. apiserver(s) 전면의 Proxy/Load-balancer: diff --git a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 477e310943..b3997580f2 100644 --- a/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/ko/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -7,7 +7,6 @@ card: weight: 40 --- - 이 페이지에서는 구성 파일을 사용하여 다수의 클러스터에 접근할 수 있도록 @@ -22,19 +21,21 @@ card: {{< /note >}} +{{< warning >}} +신뢰할 수 있는 소스의 kubeconfig 파일만 사용해야 한다. 특수 제작된 kubeconfig 파일은 악성코드를 실행하거나 파일을 노출시킬 수 있다. +신뢰할 수 없는 kubeconfig 파일을 꼭 사용해야 한다면, 셸 스크립트를 사용하는 경우처럼 신중한 검사가 선행되어야 한다. +{{< /warning>}} + ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}이 설치되었는지 확인하려면, `kubectl version --client`을 실행한다. kubectl 버전은 클러스터의 API 서버 버전과 -[마이너 버전 하나 차이 이내](/ko/docs/setup/release/version-skew-policy/#kubectl)여야 +[마이너 버전 하나 차이 이내](/ko/releases/version-skew-policy/#kubectl)여야 한다. - - ## 클러스터, 사용자, 컨텍스트 정의 @@ -49,7 +50,7 @@ scratch 클러스터에 접근하려면 사용자네임과 패스워드로 인 `config-exercise`라는 디렉터리를 생성한다. `config-exercise` 디렉터리에 다음 내용을 가진 `config-demo`라는 파일을 생성한다. -```shell +```yaml apiVersion: v1 kind: Config preferences: {} @@ -114,7 +115,7 @@ kubectl config --kubeconfig=config-demo view 두 클러스터, 두 사용자, 세 컨텍스트들이 출력 결과로 나온다. -```shell +```yaml apiVersion: v1 clusters: - cluster: @@ -186,7 +187,7 @@ kubectl config --kubeconfig=config-demo view --minify `dev-frontend` 컨텍스트에 관련된 구성 정보가 출력 결과로 표시될 것이다. -```shell +```yaml apiVersion: v1 clusters: - cluster: @@ -238,7 +239,6 @@ kubectl config --kubeconfig=config-demo use-context dev-storage 현재 컨텍스트인 `dev-storage`에 관련된 설정을 보자. - ```shell kubectl config --kubeconfig=config-demo view --minify ``` @@ -247,7 +247,7 @@ kubectl config --kubeconfig=config-demo view --minify `config-exercise` 디렉터리에서 다음 내용으로 `config-demo-2`라는 파일을 생성한다. -```shell +```yaml apiVersion: v1 kind: Config preferences: {} @@ -269,13 +269,17 @@ contexts: 예: ### 리눅스 + ```shell -export KUBECONFIG_SAVED=$KUBECONFIG +export KUBECONFIG_SAVED=$KUBECONFIG ``` + ### 윈도우 PowerShell -```shell + +```powershell $Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG ``` + `KUBECONFIG` 환경 변수는 구성 파일들의 경로의 리스트이다. 이 리스트는 리눅스와 Mac에서는 콜론으로 구분되며 윈도우에서는 세미콜론으로 구분된다. `KUBECONFIG` 환경 변수를 가지고 있다면, 리스트에 포함된 구성 파일들에 @@ -284,11 +288,14 @@ $Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG 다음 예와 같이 임시로 `KUBECONFIG` 환경 변수에 두 개의 경로들을 덧붙여보자. ### 리눅스 + ```shell -export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2 +export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2 ``` + ### 윈도우 PowerShell -```shell + +```powershell $Env:KUBECONFIG=("config-demo;config-demo-2") ``` @@ -303,7 +310,7 @@ kubectl config view 컨텍스트와 `config-demo` 파일의 세 개의 컨텍스트들을 가지고 있다는 것에 주목하길 바란다. -```shell +```yaml contexts: - context: cluster: development @@ -347,12 +354,15 @@ kubeconfig 파일들을 어떻게 병합하는지에 대한 상세정보는 예: ### 리눅스 + ```shell export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config ``` + ### 윈도우 Powershell -```shell - $Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config" + +```powershell +$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config" ``` 이제 `KUBECONFIG` 환경 변수에 리스트에 포함된 모든 파일들이 합쳐진 구성 정보를 보자. @@ -367,19 +377,18 @@ kubectl config view `KUBECONFIG` 환경 변수를 원래 값으로 되돌려 놓자. 예를 들면:
    ### 리눅스 + ```shell export KUBECONFIG=$KUBECONFIG_SAVED ``` ### 윈도우 PowerShell -```shell - $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED + +```powershell +$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED ``` - - ## {{% heading "whatsnext" %}} - * [kubeconfig 파일을 사용하여 클러스터 접근 구성하기](/ko/docs/concepts/configuration/organize-cluster-access-kubeconfig/) * [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) diff --git a/content/ko/docs/tasks/access-application-cluster/connecting-frontend-backend.md b/content/ko/docs/tasks/access-application-cluster/connecting-frontend-backend.md index 488ea59ff6..11afa655e8 100644 --- a/content/ko/docs/tasks/access-application-cluster/connecting-frontend-backend.md +++ b/content/ko/docs/tasks/access-application-cluster/connecting-frontend-backend.md @@ -220,4 +220,4 @@ kubectl delete deployment frontend backend * [서비스](/ko/docs/concepts/services-networking/service/)에 대해 더 알아본다. * [컨피그맵](/docs/tasks/configure-pod-container/configure-pod-configmap/)에 대해 더 알아본다. -* [서비스와 파드용 DNS](/docs/concepts/services-networking/dns-pod-service/)에 대해 더 알아본다. +* [서비스와 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/)에 대해 더 알아본다. diff --git a/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md b/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md new file mode 100644 index 0000000000..f777d192cd --- /dev/null +++ b/content/ko/docs/tasks/access-application-cluster/list-all-running-container-images.md @@ -0,0 +1,109 @@ +--- +title: 클러스터 내 모든 컨테이너 이미지 목록 보기 +content_type: task +weight: 100 +--- + + + +이 문서는 kubectl을 이용하여 클러스터 내 모든 컨테이너 이미지 목록을 +조회하는 방법에 관해 설명한다. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + +이 작업에서는 kubectl을 사용하여 클러스터 내 모든 파드의 정보를 +조회하고, 결과값의 서식을 변경하여 각 파드에 대한 컨테이너 이미지 목록으로 +재구성할 것이다. + +## 모든 네임스페이스의 모든 컨테이너 이미지 가져오기 + +- `kubectl get pods --all-namespaces` 를 사용하여 모든 네임스페이스의 모든 파드 정보를 가져온다. +- 컨테이너 이미지 이름만 출력하기 위해 `-o jsonpath={.items[*].spec.containers[*].image}` 를 사용한다. + 이 명령어는 결과값으로 받은 json을 반복적으로 파싱하여, + `image` 필드만을 출력한다. + - jsonpath를 사용하는 방법에 대해 더 많은 정보를 얻고 싶다면 + [Jsonpath 지원](/ko/docs/reference/kubectl/jsonpath/)을 확인한다. +- 다음의 표준 툴을 이용해서 결과값을 처리한다. `tr`, `sort`, `uniq` + - `tr` 을 사용하여 공백을 줄 바꾸기로 대체한다. + - `sort` 를 사용하여 결과값을 정렬한다. + - `uniq` 를 사용하여 이미지 개수를 합산한다. + +```shell +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" |\ +tr -s '[[:space:]]' '\n' |\ +sort |\ +uniq -c +``` + +이 커맨드는 결과값으로 나온 모든 아이템 중에 `image` 라고 명명된 필드를 +모두 출력한다. + +이와 다른 방법으로 파드 이미지 필드 값의 절대 경로를 사용할 수 있다. +이것은 필드명이 반복될 때에도 +정확한 값을 출력하도록 보장한다. +예) 결과값 중에 많은 필드들이 `name`으로 명명되었을 경우, + +```shell +kubectl get pods --all-namespaces -o jsonpath="{.items[*].spec.containers[*].image}" +``` + +이 jsonpath는 다음과 같이 해석할 수 있다. + +- `.items[*]`: 각 결과값에 대하여 +- `.spec`: spec 값을 가져온다. +- `.containers[*]`: 각 컨테이너에 대하여 +- `.image`: image 값을 가져온다. + +{{< note >}} +명령어로 하나의 파드를 가져올 때, 예를 들어 `kubectl get pod nginx` 라면, +jsonpath에서 `.items[*]` 부분은 생략해야 하는데, 이는 명령어가 아이템 목록이 아닌 +단 한 개의 아이템(여기선 파드)으로 결과값을 주기 때문이다. +{{< /note >}} + +## 각 파드의 컨테이너 이미지 보기 + +`range` 연산을 사용하여 명령어의 결과값에서 각각의 요소들을 +반복하여 출력할 수 있다. + +```shell +kubectl get pods --all-namespaces -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{end}' |\ +sort +``` + +## 파드 레이블로 필터링된 컨테이너 이미지 목록 보기 + +특정 레이블에 맞는 파드를 지정하기 위해서 -l 플래그를 사용한다. 아래의 +명령어 결과값은 `app=nginx` 레이블에 일치하는 파드만 출력한다. + +```shell +kubectl get pods --all-namespaces -o=jsonpath="{.items[*].spec.containers[*].image}" -l app=nginx +``` + +## 파드 네임스페이스로 필터링된 컨테이너 이미지 목록 보기 + +특정 네임스페이스의 파드를 지정하려면, 네임스페이스 플래그를 사용한다. +아래의 명령어 결과값은 `kube-system` 네임스페이스에 있는 파드만 출력한다. + +```shell +kubectl get pods --namespace kube-system -o jsonpath="{.items[*].spec.containers[*].image}" +``` + +## jsonpath 대신 Go 템플릿을 사용하여 컨테이너 이미지 목록 보기 + +jsonpath의 대안으로 Kubectl은 [Go 템플릿](https://golang.org/pkg/text/template/)을 지원한다. +다음과 같이 결과값의 서식을 지정할 수 있다. + +```shell +kubectl get pods --all-namespaces -o go-template --template="{{range .items}}{{range .spec.containers}}{{.image}} {{end}}{{end}}" +``` + +## {{% heading "whatsnext" %}} + +### 참조 + +* [Jsonpath](/ko/docs/reference/kubectl/jsonpath/) 참조 +* [Go 템플릿](https://golang.org/pkg/text/template/) 참조 diff --git a/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md index a6739cc2ea..333001af81 100644 --- a/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md +++ b/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md @@ -8,7 +8,7 @@ min-kubernetes-server-version: v1.10 이 페이지는 `kubectl port-forward` 를 사용해서 쿠버네티스 클러스터 내에서 -실행중인 Redis 서버에 연결하는 방법을 보여준다. 이 유형의 연결은 데이터베이스 +실행중인 MongoDB 서버에 연결하는 방법을 보여준다. 이 유형의 연결은 데이터베이스 디버깅에 유용할 수 있다. @@ -19,25 +19,25 @@ min-kubernetes-server-version: v1.10 * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -* [redis-cli](http://redis.io/topics/rediscli)를 설치한다. +* [MongoDB Shell](https://www.mongodb.com/try/download/shell)을 설치한다. -## Redis 디플로이먼트와 서비스 생성하기 +## MongoDB 디플로이먼트와 서비스 생성하기 -1. Redis를 실행하기 위해 디플로이먼트를 생성한다. +1. MongoDB를 실행하기 위해 디플로이먼트를 생성한다. ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-deployment.yaml + kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml ``` 성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다. ``` - deployment.apps/redis-master created + deployment.apps/mongo created ``` 파드 상태를 조회하여 파드가 준비되었는지 확인한다. @@ -49,8 +49,8 @@ min-kubernetes-server-version: v1.10 출력은 파드가 생성되었다는 것을 보여준다. ``` - NAME READY STATUS RESTARTS AGE - redis-master-765d459796-258hz 1/1 Running 0 50s + NAME READY STATUS RESTARTS AGE + mongo-75f59d57f4-4nd6q 1/1 Running 0 2m4s ``` 디플로이먼트 상태를 조회한다. @@ -62,104 +62,104 @@ min-kubernetes-server-version: v1.10 출력은 디플로이먼트가 생성되었다는 것을 보여준다. ``` - NAME READY UP-TO-DATE AVAILABLE AGE - redis-master 1/1 1 1 55s + NAME READY UP-TO-DATE AVAILABLE AGE + mongo 1/1 1 1 2m21s ``` + 디플로이먼트는 자동으로 레플리카셋을 관리한다. 아래의 명령어를 사용하여 레플리카셋 상태를 조회한다. ```shell - kubectl get rs + kubectl get replicaset ``` 출력은 레플리카셋이 생성되었다는 것을 보여준다. ``` - NAME DESIRED CURRENT READY AGE - redis-master-765d459796 1 1 1 1m + NAME DESIRED CURRENT READY AGE + mongo-75f59d57f4 1 1 1 3m12s ``` -2. Redis를 네트워크에 노출시키기 위해 서비스를 생성한다. +2. MongoDB를 네트워크에 노출시키기 위해 서비스를 생성한다. ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml + kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml ``` 성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다. ``` - service/redis-master created + service/mongo created ``` 서비스가 생성되었는지 확인한다. ```shell - kubectl get svc | grep redis + kubectl get service mongo ``` 출력은 서비스가 생성되었다는 것을 보여준다. ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - redis-master ClusterIP 10.0.0.213 6379/TCP 27s + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + mongo ClusterIP 10.96.41.183 27017/TCP 11s ``` -3. Redis 서버가 파드 안에서 실행되고 있고, 6379번 포트에서 수신하고 있는지 확인한다. +3. MongoDB 서버가 파드 안에서 실행되고 있고, 27017번 포트에서 수신하고 있는지 확인한다. ```shell - # redis-master-765d459796-258hz 를 파드 이름으로 변경한다. - kubectl get pod redis-master-765d459796-258hz --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}' - + # mongo-75f59d57f4-4nd6q 를 당신의 파드 이름으로 대체한다. + kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}' ``` - 출력은 파드 내 Redis 포트 번호를 보여준다. + 출력은 파드 내 MongoDB 포트 번호를 보여준다. ``` - 6379 + 27017 ``` - (이 TCP 포트는 Redis가 인터넷에 할당된 것이다). + (이는 인터넷 상의 MongoDB에 할당된 TCP 포트이다.) ## 파드의 포트를 로컬 포트로 포워딩하기 -1. `kubectl port-forward` 명령어는 파드 이름과 같이 리소스 이름을 사용하여 일치하는 파드를 선택해 포트 포워딩하는 것을 허용한다. +1. `kubectl port-forward` 명령어는 파드 이름과 같이 리소스 이름을 사용하여 일치하는 파드를 선택해 포트 포워딩하는 것을 허용한다. ```shell - # redis-master-765d459796-258hz 를 파드 이름으로 변경한다. - kubectl port-forward redis-master-765d459796-258hz 7000:6379 + # mongo-75f59d57f4-4nd6q 를 당신의 파드 이름으로 대체한다. + kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017 ``` 이것은 ```shell - kubectl port-forward pods/redis-master-765d459796-258hz 7000:6379 + kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017 ``` 또는 ```shell - kubectl port-forward deployment/redis-master 7000:6379 + kubectl port-forward deployment/mongo 28015:27017 ``` 또는 ```shell - kubectl port-forward rs/redis-master 7000:6379 + kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017 ``` 또는 다음과 같다. ```shell - kubectl port-forward service/redis-master 7000:redis + kubectl port-forward service/mongo 28015:27017 ``` 위의 명령어들은 모두 동일하게 동작한다. 이와 유사하게 출력된다. ``` - Forwarding from 127.0.0.1:7000 -> 6379 - Forwarding from [::1]:7000 -> 6379 + Forwarding from 127.0.0.1:28015 -> 27017 + Forwarding from [::1]:28015 -> 27017 ``` {{< note >}} @@ -168,22 +168,22 @@ min-kubernetes-server-version: v1.10 {{< /note >}} -2. Redis 커맨드라인 인터페이스를 실행한다. +2. MongoDB 커맨드라인 인터페이스를 실행한다. ```shell - redis-cli -p 7000 + mongosh --port 28015 ``` -3. Redis 커맨드라인 프롬프트에 `ping` 명령을 입력한다. +3. MongoDB 커맨드라인 프롬프트에 `ping` 명령을 입력한다. - ```shell - ping + ``` + db.runCommand( { ping: 1 } ) ``` 성공적인 핑 요청을 반환한다. ``` - PONG + { ok: 1 } ``` ### 선택적으로 _kubectl_ 이 로컬 포트를 선택하게 하기 {#let-kubectl-choose-local-port} @@ -193,15 +193,15 @@ min-kubernetes-server-version: v1.10 부담을 줄일 수 있다. ```shell -kubectl port-forward deployment/redis-master :6379 +kubectl port-forward deployment/mongo :27017 ``` -`kubectl` 도구는 사용 중이 아닌 로컬 포트 번호를 찾는다. (낮은 포트 번호는 -다른 애플리케이션에서 사용될 것이므로, 낮은 포트 번호를 피해서) 출력은 다음과 같을 것이다. +`kubectl` 도구는 사용 중이 아닌 로컬 포트 번호를 찾는다 (낮은 포트 번호는 +다른 애플리케이션에서 사용될 것이므로, 낮은 포트 번호를 피해서). 출력은 다음과 같을 것이다. ``` -Forwarding from 127.0.0.1:62162 -> 6379 -Forwarding from [::1]:62162 -> 6379 +Forwarding from 127.0.0.1:63753 -> 27017 +Forwarding from [::1]:63753 -> 27017 ``` @@ -209,7 +209,7 @@ Forwarding from [::1]:62162 -> 6379 ## 토의 -로컬 7000 포트에 대한 연결은 Redis 서버가 실행중인 파드의 6379 포트로 포워딩된다. +로컬 28015 포트에 대한 연결은 MongoDB 서버가 실행중인 파드의 27017 포트로 포워딩된다. 이 연결로 로컬 워크스테이션에서 파드 안에서 실행 중인 데이터베이스를 디버깅하는데 사용할 수 있다. diff --git a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md index d0cfee3009..7cb694386d 100644 --- a/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md +++ b/content/ko/docs/tasks/access-application-cluster/web-ui-dashboard.md @@ -1,4 +1,8 @@ --- + + + + title: 웹 UI (대시보드) content_type: concept weight: 10 @@ -30,12 +34,11 @@ card: 대시보드 UI는 기본으로 배포되지 않는다. 배포하려면 다음 커맨드를 동작한다. ``` -kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0/aio/deploy/recommended.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml ``` ## 대시보드 UI 접근 - 클러스터 데이터를 보호하기 위해, 대시보드는 기본적으로 최소한의 RBAC 설정을 제공한다. 현재, 대시보드는 Bearer 토큰으로 로그인 하는 방법을 제공한다. 본 시연을 위한 토큰을 생성하기 위해서는, diff --git a/content/ko/docs/tasks/administer-cluster/_index.md b/content/ko/docs/tasks/administer-cluster/_index.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md index 5dd7a627d0..8019e46c25 100644 --- a/content/ko/docs/tasks/administer-cluster/access-cluster-services.md +++ b/content/ko/docs/tasks/administer-cluster/access-cluster-services.md @@ -19,22 +19,22 @@ content_type: task 쿠버네티스에서, [노드](/ko/docs/concepts/architecture/nodes/), [파드](/ko/docs/concepts/workloads/pods/) 및 [서비스](/ko/docs/concepts/services-networking/service/)는 모두 -고유한 IP를 가진다. 대부분의 경우, 클러스터의 노드 IP, 파드 IP 및 일부 서비스 IP는 라우팅할 수 -없으므로, 데스크톱 시스템과 같은 클러스터 외부 시스템에서 -도달할 수 없다. +고유한 IP를 가진다. 당신의 데스크탑 PC와 같은 클러스터 외부 장비에서는 +클러스터 상의 노드 IP, 파드 IP, 서비스 IP로 라우팅되지 않아서 +접근할 수 없을 것이다. ### 연결하는 방법 -클러스터 외부에서 노드, 파드 및 서비스에 연결하기 위한 몇 가지 옵션이 있다. +클러스터 외부에서 노드, 파드 및 서비스에 접속하기 위한 몇 가지 옵션이 있다. - 퍼블릭 IP를 통해 서비스에 접근한다. - - `NodePort` 또는 `LoadBalancer` 타입의 서비스를 사용하여 해당 서비스를 클러스터 외부에서 - 접근할 수 있게 한다. [서비스](/ko/docs/concepts/services-networking/service/)와 + - 클러스터 외부에서 접근할 수 있도록 `NodePort` 또는 `LoadBalancer` 타입의 + 서비스를 사용한다. [서비스](/ko/docs/concepts/services-networking/service/)와 [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands/#expose) 문서를 참고한다. - - 클러스터 환경에 따라, 서비스는 단지 회사 네트워크에 노출되기도 하며, - 인터넷에 노출되는 경우도 있다. 노출되는 서비스가 안전한지 생각한다. - 자체 인증을 수행하는가? - - 서비스 뒤에 파드를 배치한다. 디버깅과 같은 목적으로 레플리카 집합에서 특정 파드에 접근하려면, + - 클러스터 환경에 따라, 서비스는 회사 네트워크에만 노출되기도 하며, + 인터넷에 노출되는 경우도 있다. 이 경우 노출되는 서비스의 보안 여부를 고려해야 한다. + 해당 서비스는 자체적으로 인증을 수행하는가? + - 파드는 서비스 뒤에 위치시킨다. 디버깅과 같은 목적으로 레플리카 집합에서 특정 파드에 접근하려면, 파드에 고유한 레이블을 배치하고 이 레이블을 선택하는 새 서비스를 생성한다. - 대부분의 경우, 애플리케이션 개발자가 nodeIP를 통해 노드에 직접 접근할 필요는 없다. @@ -54,8 +54,8 @@ content_type: task ### 빌트인 서비스 검색 -일반적으로, kube-system에 의해 클러스터에서 시작되는 몇 가지 서비스가 있다. `kubectl cluster-info` 명령을 -사용하여 이들의 목록을 얻는다. +일반적으로 kube-system에 의해 클러스터에 실행되는 몇 가지 서비스가 있다. +`kubectl cluster-info` 커맨드로 이 서비스의 리스트를 볼 수 있다. ```shell kubectl cluster-info diff --git a/content/ko/docs/tasks/administer-cluster/certificates.md b/content/ko/docs/tasks/administer-cluster/certificates.md index 8c8f6a148b..076f09faf4 100644 --- a/content/ko/docs/tasks/administer-cluster/certificates.md +++ b/content/ko/docs/tasks/administer-cluster/certificates.md @@ -116,7 +116,10 @@ weight: 20 openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ -CAcreateserial -out server.crt -days 10000 \ -extensions v3_ext -extfile csr.conf -1. 인증서를 본다. +1. 인증서 서명 요청을 확인한다. + + openssl req -noout -text -in ./server.csr +1. 인증서를 확인한다. openssl x509 -noout -text -in ./server.crt @@ -246,5 +249,5 @@ done. ## 인증서 API `certificates.k8s.io` API를 사용해서 -[여기](/docs/tasks/tls/managing-tls-in-a-cluster)에 +[여기](/ko/docs/tasks/tls/managing-tls-in-a-cluster/)에 설명된 대로 인증에 사용할 x509 인증서를 프로비전 할 수 있다. diff --git a/content/ko/docs/tasks/administer-cluster/coredns.md b/content/ko/docs/tasks/administer-cluster/coredns.md index 6f0caad9e4..414f681901 100644 --- a/content/ko/docs/tasks/administer-cluster/coredns.md +++ b/content/ko/docs/tasks/administer-cluster/coredns.md @@ -33,8 +33,8 @@ Kube-dns의 배포나 교체에 관한 매뉴얼은 [CoreDNS GitHub 프로젝트 ### Kubeadm을 사용해 기존 클러스터 업그레이드하기 쿠버네티스 버전 1.10 이상에서, `kube-dns` 를 사용하는 클러스터를 업그레이드하기 위하여 -`kubeadm` 을 사용할 때 CoreDNS로 이동할 수도 있다. 이 경우, `kubeadm` 은 -`kube-dns` 컨피그맵(ConfigMap)을 기반으로 패더레이션, 스텁 도메인(stub domain), 업스트림 네임 서버의 +`kubeadm` 을 사용할 때 CoreDNS로 전환할 수도 있다. 이 경우, `kubeadm` 은 +`kube-dns` 컨피그맵(ConfigMap)을 기반으로 스텁 도메인(stub domain), 업스트림 네임 서버의 설정을 유지하며 CoreDNS 설정("Corefile")을 생성한다. 만약 kube-dns에서 CoreDNS로 이동하는 경우, 업그레이드 과정에서 기능 게이트의 `CoreDNS` 값을 `true` 로 설정해야 한다. @@ -44,8 +44,6 @@ kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true ``` 쿠버네티스 1.13 이상에서 기능 게이트의 `CoreDNS` 항목은 제거되었으며, CoreDNS가 기본적으로 사용된다. -업그레이드된 클러스터에서 kube-dns를 사용하려는 경우, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에 -설명된 지침 가이드를 참고하자. 1.11 미만 버전일 경우 업그레이드 과정에서 만들어진 파일이 Corefile을 **덮어쓴다**. **만약 컨피그맵을 사용자 정의한 경우, 기존의 컨피그맵을 저장해야 한다.** 새 컨피그맵이 @@ -54,26 +52,7 @@ kubeadm upgrade apply v1.11.0 --feature-gates=CoreDNS=true 만약 쿠버네티스 1.11 이상 버전에서 CoreDNS를 사용하는 경우, 업그레이드 과정에서, 기존의 Corefile이 유지된다. - -### Kubeadm을 사용해 CoreDNS가 아닌 kube-dns 설치하기 - -{{< note >}} -쿠버네티스 1.11 버전에서, CoreDNS는 GA(General Availability) 되었으며, -기본적으로 설치된다. -{{< /note >}} - -{{< warning >}} -쿠버네티스 1.18 버전에서, kubeadm을 통한 kube-dns는 사용 중단되었으며, 향후 버전에서 제거될 예정이다. -{{< /warning >}} - -1.13 보다 이전 버전에서 kube-dns를 설치하는경우, 기능 게이트의 `CoreDNS` -값을 `false` 로 변경해야 한다. - -``` -kubeadm init --feature-gates=CoreDNS=false -``` - -1.13 이후 버전에서는, [여기](/docs/reference/setup-tools/kubeadm/kubeadm-init-phase#cmd-phase-addon)에 설명된 지침 가이드를 참고하자. +쿠버네티스 버전 1.21에서, kubeadm 의 `kube-dns` 지원 기능이 삭제되었다. ## CoreDNS 업그레이드하기 diff --git a/content/ko/docs/tasks/administer-cluster/declare-network-policy.md b/content/ko/docs/tasks/administer-cluster/declare-network-policy.md index 7a7a97576d..6d4193e63c 100644 --- a/content/ko/docs/tasks/administer-cluster/declare-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/declare-network-policy.md @@ -1,4 +1,7 @@ --- + + + title: 네트워크 폴리시(Network Policy) 선언하기 min-kubernetes-server-version: v1.8 content_type: task @@ -13,8 +16,9 @@ content_type: task {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -네트워크 폴리시를 지원하는 네트워크 제공자를 구성하였는지 확인해야 한다. 다음과 같이 네트워크폴리시를 제공하는 많은 네트워크 제공자들이 있다. +네트워크 폴리시를 지원하는 네트워크 제공자를 구성하였는지 확인해야 한다. 다음과 같이 네트워크폴리시를 지원하는 많은 네트워크 제공자들이 있다. +* [Antrea](/docs/tasks/administer-cluster/network-policy-provider/antrea-network-policy/) * [캘리코(Calico)](/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy/) * [실리움(Cilium)](/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy/) * [Kube-router](/ko/docs/tasks/administer-cluster/network-policy-provider/kube-router-network-policy/) @@ -85,7 +89,7 @@ remote file exists {{< codenew file="service/networking/nginx-policy.yaml" >}} 네트워크폴리시 오브젝트의 이름은 유효한 -[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)이어야 한다. +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. {{< note >}} 네트워크폴리시는 정책이 적용되는 파드의 그룹을 선택하는 `podSelector` 를 포함한다. 사용자는 이 정책이 `app=nginx` 레이블을 갖는 파드를 선택하는 것을 볼 수 있다. 레이블은 `nginx` 디플로이먼트에 있는 파드에 자동으로 추가된다. 빈 `podSelector` 는 네임스페이스의 모든 파드를 선택한다. diff --git a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md index ad76009844..f681bc8778 100644 --- a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md +++ b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md @@ -23,7 +23,7 @@ DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한 ## 소개 -DNS는 _애드온 관리자_ 인 [클러스터 애드온](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을 +DNS는 _애드온 관리자_ 인 [클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을 사용하여 자동으로 시작되는 쿠버네티스 내장 서비스이다. @@ -31,7 +31,7 @@ DNS는 _애드온 관리자_ 인 [클러스터 애드온](http://releases.k8s.io CoreDNS 대신 `kube-dns` 를 계속 사용할 수도 있다. {{< note >}} -CoreDNS와 kube-dns 서비스 모두 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다. +CoreDNS 서비스는 `metadata.name` 필드에 `kube-dns` 로 이름이 지정된다. 이를 통해, 기존의 `kube-dns` 서비스 이름을 사용하여 클러스터 내부의 주소를 확인하는 워크로드에 대한 상호 운용성이 증가된다. `kube-dns` 로 서비스 이름을 사용하면, 해당 DNS 공급자가 어떤 공통 이름으로 실행되고 있는지에 대한 구현 세부 정보를 추상화한다. {{< /note >}} @@ -176,17 +176,14 @@ kube-dns는 스텁 도메인 및 네임서버(예: ns.foo.com)에 대한 FQDN을 CoreDNS는 kube-dns 이상의 기능을 지원한다. `StubDomains` 과 `upstreamNameservers` 를 지원하도록 생성된 kube-dns의 컨피그맵은 CoreDNS의 `forward` 플러그인으로 변환된다. -마찬가지로, kube-dns의 `Federations` 플러그인은 CoreDNS의 `federation` 플러그인으로 변환된다. ### 예시 -kube-dns에 대한 이 컨피그맵 예제는 federations, stubDomains 및 upstreamNameservers를 지정한다. +kube-dns에 대한 이 컨피그맵 예제는 stubDomains 및 upstreamNameservers를 지정한다. ```yaml apiVersion: v1 data: - federations: | - {"foo" : "foo.feddomain.com"} stubDomains: | {"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]} upstreamNameservers: | @@ -196,13 +193,6 @@ kind: ConfigMap CoreDNS에서는 동등한 설정으로 Corefile을 생성한다. -* federations 에 대응하는 설정: -``` -federation cluster.local { - foo foo.feddomain.com -} -``` - * stubDomains 에 대응하는 설정: ```yaml abc.com:53 { diff --git a/content/ko/docs/tasks/administer-cluster/enable-disable-api.md b/content/ko/docs/tasks/administer-cluster/enable-disable-api.md new file mode 100644 index 0000000000..202035c291 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/enable-disable-api.md @@ -0,0 +1,29 @@ +--- +title: 쿠버네티스 API 활성화 혹은 비활성화하기 +content_type: task +--- + + +이 페이지는 클러스터 {{< glossary_tooltip text="컨트롤 플레인" term_id="control-plane" >}}의 +특정한 API 버전을 활성화하거나 비활성화하는 방법에 대해 설명한다. + + + + +API 서버에 `--runtime-config=api/` 커맨드 라인 인자를 사용함으로서 특정한 API 버전을 +활성화하거나 비활성화할 수 있다. 이 인자에 대한 값으로는 콤마로 구분된 API 버전의 목록을 사용한다. +뒤쪽에 위치한 값은 앞쪽의 값보다 우선적으로 사용된다. + +이 `runtime-config` 커맨드 라인 인자에는 다음의 두 개의 특수 키를 사용할 수도 있다. + +- `api/all`: 사용할 수 있는 모든 API를 선택한다. +- `api/legacy`: 레거시 API만을 선택한다. 여기서 레거시 API란 명시적으로 + [사용이 중단된](/docs/reference/using-api/deprecation-policy/) 모든 API를 가리킨다. + +예를 들어서, v1을 제외한 모든 API 버전을 비활성화하기 위해서는 `kube-apiserver`에 +`--runtime-config=api/all=false,api/v1=true` 인자를 사용한다. + +## {{% heading "whatsnext" %}} + +`kube-apiserver` 컴포넌트에 대한 더 자세한 내용은 다음의 [문서](/docs/reference/command-line-tools-reference/kube-apiserver/) +를 참고한다. diff --git a/content/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints.md b/content/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints.md new file mode 100644 index 0000000000..c0342fb377 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/enabling-topology-aware-hints.md @@ -0,0 +1,38 @@ +--- +title: 토폴로지 인지 힌트 활성화하기 +content_type: task +min-kubernetes-server-version: 1.21 +--- + + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +_토폴로지 인지 힌트_ 는 {{< glossary_tooltip text="엔드포인트슬라이스(EndpointSlices)" term_id="endpoint-slice" >}}에 포함되어 있는 +토폴로지 정보를 이용해 토폴로지 인지 라우팅을 가능하게 한다. +이 방법은 트래픽을 해당 트래픽이 시작된 곳과 최대한 근접하도록 라우팅하는데, +이를 통해 비용을 줄이거나 네트워크 성능을 향상시킬 수 있다. + +## {{% heading "prerequisites" %}} + + {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + +토폴로지 인지 힌트를 활성화하기 위해서는 다음의 필수 구성 요소가 필요하다. + +* {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}가 + iptables 모드 혹은 IPVS 모드로 동작하도록 설정 +* 엔드포인트슬라이스가 비활성화되지 않았는지 확인 + +## 토폴로지 인지 힌트 활성화하기 + +서비스 토폴로지 힌트를 활성화하기 위해서는 kube-apiserver, kube-controller-manager, kube-proxy에 대해 +`TopologyAwareHints` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 +활성화한다. + +``` +--feature-gates="TopologyAwareHints=true" +``` + +## {{% heading "whatsnext" %}} + +* 서비스 항목 아래의 [토폴로지 인지 힌트](/docs/concepts/services-networking/topology-aware-hints)를 참고 +* [서비스와 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 참고 diff --git a/content/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md b/content/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md new file mode 100644 index 0000000000..bbc44c94a1 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods.md @@ -0,0 +1,25 @@ +--- + + + + +title: 중요한 애드온 파드 스케줄링 보장하기 +content_type: concept +--- + + + +API 서버, 스케줄러 및 컨트롤러 매니저와 같은 쿠버네티스 주요 컴포넌트들은 컨트롤 플레인 노드에서 동작한다. 반면, 애드온들은 일반 클러스터 노드에서 동작한다. +이러한 애드온들 중 일부(예: 메트릭 서버, DNS, UI)는 클러스터 전부가 정상적으로 동작하는 데 필수적일 수 있다. +만약, 필수 애드온이 축출되고(수동 축출, 혹은 업그레이드와 같은 동작으로 인한 의도하지 않은 축출) +pending 상태가 된다면, 클러스터가 더 이상 제대로 동작하지 않을 수 있다. (사용률이 매우 높은 클러스터에서 해당 애드온이 +축출되자마자 다른 대기중인 파드가 스케줄링되거나 다른 이유로 노드에서 사용할 수 있는 자원량이 줄어들어 pending 상태가 발생할 수 있다) + +유의할 점은, 파드를 중요(critical)로 표시하는 것은 축출을 완전히 방지하기 위함이 아니다. 이것은 단지 파드가 영구적으로 사용할 수 없게 되는 것만을 방지하기 위함이다. +중요로 표시한 스태틱(static) 파드는 축출될 수 없다. 반면, 중요로 표시한 일반적인(non-static) 파드의 경우 항상 다시 스케줄링된다. + + + +### 파드를 중요(critical)로 표시하기 + +파드를 중요로 표시하기 위해서는, 해당 파드에 대해 priorityClassName을 `system-cluster-critical`이나 `system-node-critical`로 설정한다. `system-node-critical`은 가장 높은 우선 순위를 가지며, 심지어 `system-cluster-critical`보다도 우선 순위가 높다. diff --git a/content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md b/content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md new file mode 100644 index 0000000000..2ee11427f3 --- /dev/null +++ b/content/ko/docs/tasks/administer-cluster/highly-available-control-plane.md @@ -0,0 +1,216 @@ +--- + + +title: 고가용성 쿠버네티스 클러스터 컨트롤 플레인 설정하기 +content_type: task + +--- + + + +{{< feature-state for_k8s_version="v1.5" state="alpha" >}} + +구글 컴퓨트 엔진(Google Compute Engine, 이하 GCE)의 `kube-up`이나 `kube-down` 스크립트에 쿠버네티스 컨트롤 플레인 노드를 복제할 수 있다. 하지만 이러한 스크립트들은 프로덕션 용도로 사용하기에 적합하지 않으며, 프로젝트의 CI에서만 주로 사용된다. +이 문서는 kube-up/down 스크립트를 사용하여 고가용(HA) 컨트롤 플레인을 관리하는 방법과 GCE와 함께 사용하기 위해 HA 컨트롤 플레인을 구현하는 방법에 관해 설명한다. + + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} + + + + + +## HA 호환 클러스터 시작 + +새 HA 호환 클러스터를 생성하려면, `kube-up` 스크립트에 다음 플래그를 설정해야 한다. + +* `MULTIZONE=true` - 서버의 기본 영역(zone)과 다른 영역에서 컨트롤 플레인 kubelet이 제거되지 않도록 한다. +여러 영역에서 컨트롤 플레인 노드를 실행(권장됨)하려는 경우에 필요하다. + +* `ENABLE_ETCD_QUORUM_READ=true` - 모든 API 서버에서 읽은 내용이 최신 데이터를 반환하도록 하기 위한 것이다. +true인 경우, Etcd의 리더 복제본에서 읽는다. +이 값을 true로 설정하는 것은 선택 사항이다. 읽기는 더 안정적이지만 느리게 된다. + +선택적으로, 첫 번째 컨트롤 플레인 노드가 생성될 GCE 영역을 지정할 수 있다. +다음 플래그를 설정한다. + +* `KUBE_GCE_ZONE=zone` - 첫 번째 컨트롤 플레인 노드가 실행될 영역. + +다음 샘플 커맨드는 europe-west1-b GCE 영역에 HA 호환 클러스터를 구성한다. + +```shell +MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh +``` + +위의 커맨드는 하나의 컨트롤 플레인 노드를 포함하는 클러스터를 생성한다. +그러나 후속 커맨드로 새 컨트롤 플레인 노드를 추가할 수 있다. + +## 새 컨트롤 플레인 노드 추가 + +HA 호환 클러스터를 생성했다면, 여기에 컨트롤 플레인 노드를 추가할 수 있다. +`kube-up` 스크립트에 다음 플래그를 사용하여 컨트롤 플레인 노드를 추가한다. + +* `KUBE_REPLICATE_EXISTING_MASTER=true` - 기존 컨트롤 플레인 노드의 복제본을 +만든다. + +* `KUBE_GCE_ZONE=zone` - 컨트롤 플레인 노드가 실행될 영역. +반드시 다른 컨트롤 플레인 노드가 존재하는 영역과 동일한 지역(region)에 있어야 한다. + +HA 호환 클러스터를 시작할 때, 상속되는 `MULTIZONE`이나 `ENABLE_ETCD_QUORUM_READS` 플래그를 따로 +설정할 필요는 없다. + +다음 샘플 커맨드는 기존 HA 호환 클러스터에서 +컨트롤 플레인 노드를 복제한다. + +```shell +KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh +``` + +## 컨트롤 플레인 노드 제거 + +다음 플래그가 있는 `kube-down` 스크립트를 사용하여 HA 클러스터에서 컨트롤 플레인 노드를 제거할 수 있다. + +* `KUBE_DELETE_NODES=false` - kubelet을 삭제하지 않기 위한 것이다. + +* `KUBE_GCE_ZONE=zone` - 컨트롤 플레인 노드가 제거될 영역. + +* `KUBE_REPLICA_NAME=replica_name` - (선택) 제거할 컨트롤 플레인 노드의 이름. +명시하지 않으면, 해당 영역의 모든 복제본이 제거된다. + +다음 샘플 커맨드는 기존 HA 클러스터에서 컨트롤 플레인 노드를 제거한다. + +```shell +KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh +``` + +## 동작에 실패한 컨트롤 플레인 노드 처리 + +HA 클러스터의 컨트롤 플레인 노드 중 하나가 동작에 실패하면, +클러스터에서 해당 노드를 제거하고 동일한 영역에 새 컨트롤 플레인 +노드를 추가하는 것이 가장 좋다. +다음 샘플 커맨드로 이 과정을 시연한다. + +1. 손상된 복제본을 제거한다. + +```shell +KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh +``` + +
    1. 기존 복제본을 대신할 새 노드를 추가한다.
    + +```shell +KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh +``` + +## HA 클러스터에서 컨트롤 플레인 노드 복제에 관한 모범 사례 + +* 다른 영역에 컨트롤 플레인 노드를 배치하도록 한다. 한 영역이 동작에 실패하는 동안, +해당 영역에 있는 컨트롤 플레인 노드도 모두 동작에 실패할 것이다. +영역 장애를 극복하기 위해 노드를 여러 영역에 배치한다 +(더 자세한 내용은 [멀티 영역](/ko/docs/setup/best-practices/multiple-zones/)를 참조한다). + +* 두 개의 노드로 구성된 컨트롤 플레인은 사용하지 않는다. 두 개의 노드로 구성된 +컨트롤 플레인에서의 합의를 위해서는 지속적 상태(persistent state) 변경 시 두 컨트롤 플레인 노드가 모두 정상적으로 동작 중이어야 한다. +결과적으로 두 컨트롤 플레인 노드 모두 필요하고, 둘 중 한 컨트롤 플레인 노드에만 장애가 발생해도 +클러스터의 심각한 장애 상태를 초래한다. +따라서 HA 관점에서는 두 개의 노드로 구성된 컨트롤 플레인은 +단일 노드로 구성된 컨트롤 플레인보다도 못하다. + +* 컨트롤 플레인 노드를 추가하면, 클러스터의 상태(Etcd)도 새 인스턴스로 복사된다. +클러스터가 크면, 이 상태를 복제하는 시간이 오래 걸릴 수 있다. +이 작업은 [etcd 관리 가이드](https://etcd.io/docs/v2.3/admin_guide/#member-migration)에 기술한 대로 +Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있다. +(향후에 Etcd 데이터 디렉터리 마이그레이션 지원 추가를 고려 중이다) + + + + + +## 구현 지침 + +![ha-master-gce](/images/docs/ha-master-gce.png) + +### 개요 + +각 컨트롤 플레인 노드는 다음 모드에서 다음 구성 요소를 실행한다. + +* Etcd 인스턴스: 모든 인스턴스는 합의를 사용하여 함께 클러스터화 한다. + +* API 서버: 각 서버는 내부 Etcd와 통신한다. 클러스터의 모든 API 서버가 가용하게 된다. + +* 컨트롤러, 스케줄러, 클러스터 오토스케일러: 임대 방식을 이용한다. 각 인스턴스 중 하나만이 클러스터에서 활성화된다. + +* 애드온 매니저: 각 매니저는 애드온의 동기화를 유지하려고 독립적으로 작업한다. + +또한 API 서버 앞단에 외부/내부 트래픽을 라우팅하는 로드 밸런서가 있을 것이다. + +### 로드 밸런싱 + +두 번째 컨트롤 플레인 노드를 배치할 때, 두 개의 복제본에 대한 로드 밸런서가 생성될 것이고, 첫 번째 복제본의 IP 주소가 로드 밸런서의 IP 주소로 승격된다. +비슷하게 끝에서 두 번째의 컨트롤 플레인 노드를 제거한 후에는 로드 밸런서가 제거되고 +해당 IP 주소는 마지막으로 남은 복제본에 할당된다. +로드 밸런서 생성 및 제거는 복잡한 작업이며, 이를 전파하는 데 시간(~20분)이 걸릴 수 있다. + +### 컨트롤 플레인 서비스와 Kubelet + +쿠버네티스 서비스에서 최신의 쿠버네티스 API 서버 목록을 유지하는 대신, +시스템은 모든 트래픽을 외부 IP 주소로 보낸다. + +* 단일 노드 컨트롤 플레인의 경우, IP 주소는 단일 컨트롤 플레인 노드를 가리킨다. + +* 고가용성 컨트롤 플레인의 경우, IP 주소는 컨트롤 플레인 노드 앞의 로드밸런서를 가리킨다. + +마찬가지로 Kubelet은 외부 IP 주소를 사용하여 컨트롤 플레인과 통신한다. + +### 컨트롤 플레인 노드 인증서 + +쿠버네티스는 각 컨트롤 플레인 노드의 외부 퍼블릭 IP 주소와 내부 IP 주소를 대상으로 TLS 인증서를 발급한다. +컨트롤 플레인 노드의 임시 퍼블릭 IP 주소에 대한 인증서는 없다. +임시 퍼블릭 IP 주소를 통해 컨트롤 플레인 노드에 접근하려면, TLS 검증을 건너뛰어야 한다. + +### etcd 클러스터화 + +etcd를 클러스터로 구축하려면, etcd 인스턴스간 통신에 필요한 포트를 열어야 한다(클러스터 내부 통신용). +이러한 배포를 안전하게 하기 위해, etcd 인스턴스간의 통신은 SSL을 이용하여 승인한다. + +### API 서버 신원 + +{{< feature-state state="alpha" for_k8s_version="v1.20" >}} + +API 서버 식별 기능은 +[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에 +의해 제어되며 기본적으로 활성화되지 않는다. +{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} +시작 시 `APIServerIdentity` 라는 기능 게이트를 활성화하여 API 서버 신원을 활성화할 수 있다. + +```shell +kube-apiserver \ +--feature-gates=APIServerIdentity=true \ + # …다른 플래그는 평소와 같다. +``` + +부트스트랩 중에 각 kube-apiserver는 고유한 ID를 자신에게 할당한다. ID는 +`kube-apiserver-{UUID}` 형식이다. 각 kube-apiserver는 +_kube-system_ {{< glossary_tooltip text="네임스페이스" term_id="namespace">}}에 +[임대](/docs/reference/generated/kubernetes-api/{{< param "version" >}}//#lease-v1-coordination-k8s-io)를 생성한다. +임대 이름은 kube-apiserver의 고유 ID이다. 임대에는 +`k8s.io/component=kube-apiserver` 라는 레이블이 있다. 각 kube-apiserver는 +`IdentityLeaseRenewIntervalSeconds` (기본값은 10초)마다 임대를 새로 갱신한다. 각 +kube-apiserver는 `IdentityLeaseDurationSeconds` (기본값은 3600초)마다 +모든 kube-apiserver 식별 ID 임대를 확인하고, +`IdentityLeaseDurationSeconds` 이상 갱신되지 않은 임대를 삭제한다. +`IdentityLeaseRenewIntervalSeconds` 및 `IdentityLeaseDurationSeconds`는 +kube-apiserver 플래그 `identity-lease-renew-interval-seconds` +및 `identity-lease-duration-seconds`로 구성된다. + +이 기능을 활성화하는 것은 HA API 서버 조정과 관련된 기능을 +사용하기 위한 전제조건이다(예: `StorageVersionAPI` 기능 게이트). + +## 추가 자료 + +[자동화된 HA 마스터 배포 - 제안 문서](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md) diff --git a/content/ko/docs/tasks/administer-cluster/highly-available-master.md b/content/ko/docs/tasks/administer-cluster/highly-available-master.md deleted file mode 100644 index 76a734bd65..0000000000 --- a/content/ko/docs/tasks/administer-cluster/highly-available-master.md +++ /dev/null @@ -1,207 +0,0 @@ ---- -reviewers: -title: 고가용성 쿠버네티스 클러스터 마스터 설정하기 -content_type: task ---- - - - -{{< feature-state for_k8s_version="v1.5" state="alpha" >}} - -구글 컴퓨트 엔진(Google Compute Engine, 이하 GCE)의 `kube-up`이나 `kube-down` 스크립트에 쿠버네티스 마스터를 복제할 수 있다. -이 문서는 kube-up/down 스크립트를 사용하여 고가용(HA) 마스터를 관리하는 방법과 GCE와 함께 사용하기 위해 HA 마스터를 구현하는 방법에 관해 설명한다. - - - - -## {{% heading "prerequisites" %}} - - -{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - - - - -## HA 호환 클러스터 시작 - -새 HA 호환 클러스터를 생성하려면, `kube-up` 스크립트에 다음 플래그를 설정해야 한다. - -* `MULTIZONE=true` - 서버의 기본 존(zone)과 다른 존에서 마스터 복제본의 kubelet이 제거되지 않도록 한다. -다른 존에서 마스터 복제본을 실행하려는 경우에 권장하고 필요하다. - -* `ENABLE_ETCD_QUORUM_READ=true` - 모든 API 서버에서 읽은 내용이 최신 데이터를 반환하도록 하기 위한 것이다. -true인 경우, Etcd의 리더 복제본에서 읽는다. -이 값을 true로 설정하는 것은 선택 사항이다. 읽기는 더 안정적이지만 느리게 된다. - -선택적으로 첫 번째 마스터 복제본이 생성될 GCE 존을 지정할 수 있다. -다음 플래그를 설정한다. - -* `KUBE_GCE_ZONE=zone` - 첫 마스터 복제본이 실행될 존. - -다음 샘플 커맨드는 europe-west1-b GCE 존에 HA 호환 클러스터를 구성한다. - -```shell -MULTIZONE=true KUBE_GCE_ZONE=europe-west1-b ENABLE_ETCD_QUORUM_READS=true ./cluster/kube-up.sh -``` - -위에 커맨드는 하나의 마스터로 클러스터를 생성한다. -그러나 후속 커맨드로 새 마스터 복제본을 추가할 수 있다. - -## 새 마스터 복제본 추가 - -HA 호환 클러스터를 생성한 다음 그것의 마스터 복제본을 추가할 수 있다. -`kube-up` 스크립트에 다음 플래그를 사용하여 마스터 복제본을 추가한다. - -* `KUBE_REPLICATE_EXISTING_MASTER=true` - 기존 마스터의 복제본을 -만든다. - -* `KUBE_GCE_ZONE=zone` - 마스터 복제본이 실행될 존. -반드시 다른 복제본 존과 동일한 존에 있어야 한다. - -HA 호환 클러스터를 시작할 때, 상속되는 `MULTIZONE`이나 `ENABLE_ETCD_QUORUM_READS` 플래그를 따로 -설정할 필요는 없다. - -다음 샘플 커맨드는 기존 HA 호환 클러스터에서 마스터를 복제한다. - -```shell -KUBE_GCE_ZONE=europe-west1-c KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh -``` - -## 마스터 복제본 제거 - -다음 플래그가 있는 `kube-down` 스크립트를 사용하여 HA 클러스터에서 마스터 복제본을 제거할 수 있다. - -* `KUBE_DELETE_NODES=false` - kubelet을 삭제하지 않기 위한 것이다. - -* `KUBE_GCE_ZONE=zone` - 마스터 복제본이 제거될 존. - -* `KUBE_REPLICA_NAME=replica_name` - (선택) 제거할 마스터 복제본의 이름. -비어있는 경우, 해당 존의 모든 복제본이 제거된다. - -다음 샘플 커맨드는 기존 HA 클러스터에서 마스터 복제본을 제거한다. - -```shell -KUBE_DELETE_NODES=false KUBE_GCE_ZONE=europe-west1-c ./cluster/kube-down.sh -``` - -## 마스터 복제 실패 처리 - -HA 클러스터의 마스터 복제본 중 하나가 실패하면, -클러스터에서 복제본을 제거하고 동일한 존에서 새 복제본을 추가하는 것이 가장 좋다. -다음 샘플 커맨드로 이 과정을 시연한다. - -1. 손상된 복제본을 제거한다. - - ```shell - KUBE_DELETE_NODES=false KUBE_GCE_ZONE=replica_zone KUBE_REPLICA_NAME=replica_name ./cluster/kube-down.sh - ``` - -1. 기존 복제본 대신 새 복제본을 추가한다. - - ```shell - KUBE_GCE_ZONE=replica-zone KUBE_REPLICATE_EXISTING_MASTER=true ./cluster/kube-up.sh - ``` - -## HA 클러스터에서 마스터 복제에 관한 모범 사례 - -* 다른 존에 마스터 복제본을 배치하도록 한다. 한 존이 실패하는 동안, 해당 존에 있는 마스터도 모두 실패할 것이다. -존 장애를 극복하기 위해 노드를 여러 존에 배치한다 -(더 자세한 내용은 [멀티 존](/ko/docs/setup/best-practices/multiple-zones/)를 참조한다). - -* 두 개의 마스터 복제본은 사용하지 않는다. 두 개의 복제 클러스터에 대한 합의는 지속적 상태를 변경해야 할 때 두 복제본 모두 실행해야 한다. -결과적으로 두 복제본 모두 필요하고, 어떤 복제본의 장애에도 클러스터가 대부분 장애 상태로 변한다. -따라서 두 개의 복제본 클러스터는 HA 관점에서 단일 복제 클러스터보다 열등하다. - -* 마스터 복제본을 추가하면, 클러스터의 상태(Etcd)도 새 인스턴스로 복사된다. -클러스터가 크면, 이 상태를 복제하는 시간이 오래 걸릴 수 있다. -이 작업은 [여기](https://coreos.com/etcd/docs/latest/admin_guide.html#member-migration) 기술한 대로 -Etcd 데이터 디렉터리를 마이그레이션하여 속도를 높일 수 있다(향후에 Etcd 데이터 디렉터리 마이그레이션 지원 추가를 고려 중이다). - - - - - -## 구현 지침 - -![ha-master-gce](/images/docs/ha-master-gce.png) - -### 개요 - -각 마스터 복제본은 다음 모드에서 다음 구성 요소를 실행한다. - -* Etcd 인스턴스: 모든 인스턴스는 합의를 사용하여 함께 클러스터화 한다. - -* API 서버: 각 서버는 내부 Etcd와 통신한다. 클러스터의 모든 API 서버가 가용하게 된다. - -* 컨트롤러, 스케줄러, 클러스터 오토스케일러: 임대 방식을 이용한다. 각 인스턴스 중 하나만이 클러스터에서 활성화된다. - -* 애드온 매니저: 각 매니저는 애드온의 동기화를 유지하려고 독립적으로 작업한다. - -또한 API 서버 앞단에 외부/내부 트래픽을 라우팅하는 로드 밸런서가 있을 것이다. - -### 로드 밸런싱 - -두 번째 마스터 복제본을 시작할 때, 두 개의 복제본을 포함된 로드 밸런서가 생성될 것이고, 첫 번째 복제본의 IP 주소가 로드 밸런서의 IP 주소로 승격된다. -비슷하게 끝에서 두 번째의 마스터 복제본을 제거한 후에는 로드 밸런서가 제거되고 -해당 IP 주소는 마지막으로 남은 복제본에 할당된다. -로드 밸런서 생성 및 제거는 복잡한 작업이며, 이를 전파하는 데 시간(~20분)이 걸릴 수 있다. - -### 마스터 서비스와 Kubelet - -쿠버네티스 서비스에서 최신의 쿠버네티스 API 서버 목록을 유지하는 대신, -시스템은 모든 트래픽을 외부 IP 주소로 보낸다. - -* 단일 마스터 클러스터에서 IP 주소는 단일 마스터를 가리킨다. - -* 다중 마스터 클러스터에서 IP 주소는 마스터 앞에 로드밸런서를 가리킨다. - -마찬가지로 Kubelet은 외부 IP 주소를 사용하여 마스터와 통신한다. - -### 마스터 인증서 - -쿠버네티스는 각 복제본의 외부 퍼블릭 IP 주소와 내부 IP 주소를 대상으로 마스터 TLS 인증서를 발급한다. -복제본의 임시 공개 IP 주소에 대한 인증서는 없다. -임시 퍼블릭 IP 주소를 통해 복제본에 접근하려면, TLS 검증을 건너뛰어야 한다. - -### etcd 클러스터화 - -etcd를 클러스터로 구축하려면, etcd 인스턴스간 통신에 필요한 포트를 열어야 한다(클러스터 내부 통신용). -이러한 배포를 안전하게 하기 위해, etcd 인스턴스간의 통신은 SSL을 이용하여 승인한다. - -### API 서버 신원 - -{{< feature-state state="alpha" for_k8s_version="v1.20" >}} - -API 서버 식별 기능은 -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)에 -의해 제어되며 기본적으로 활성화되지 않는다. -{{< glossary_tooltip text="API 서버" term_id="kube-apiserver" >}} -시작 시 `APIServerIdentity` 라는 기능 게이트를 활성화하여 API 서버 신원을 활성화할 수 있다. - -```shell -kube-apiserver \ ---feature-gates=APIServerIdentity=true \ - # …다른 플래그는 평소와 같다. -``` - -부트스트랩 중에 각 kube-apiserver는 고유한 ID를 자신에게 할당한다. ID는 -`kube-apiserver-{UUID}` 형식이다. 각 kube-apiserver는 -_kube-system_ {{< glossary_tooltip text="네임스페이스" term_id="namespace">}}에 -[임대](/docs/reference/generated/kubernetes-api/{{< param "version" >}}//#lease-v1-coordination-k8s-io)를 생성한다. -임대 이름은 kube-apiserver의 고유 ID이다. 임대에는 -`k8s.io/component=kube-apiserver` 라는 레이블이 있다. 각 kube-apiserver는 -`IdentityLeaseRenewIntervalSeconds` (기본값은 10초)마다 임대를 새로 갱신한다. 각 -kube-apiserver는 `IdentityLeaseDurationSeconds` (기본값은 3600초)마다 -모든 kube-apiserver 식별 ID 임대를 확인하고, -`IdentityLeaseDurationSeconds` 이상 갱신되지 않은 임대를 삭제한다. -`IdentityLeaseRenewIntervalSeconds` 및 `IdentityLeaseDurationSeconds`는 -kube-apiserver 플래그 `identity-lease-renew-interval-seconds` -및 `identity-lease-duration-seconds`로 구성된다. - -이 기능을 활성화하는 것은 HA API 서버 조정과 관련된 기능을 -사용하기 위한 전제조건이다(예: `StorageVersionAPI` 기능 게이트). - -## 추가 자료 - -[자동화된 HA 마스터 배포 - 제안 문서](https://git.k8s.io/community/contributors/design-proposals/cluster-lifecycle/ha_master.md) diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/_index.md b/content/ko/docs/tasks/administer-cluster/kubeadm/_index.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md index 16c84d451c..e67a08a74e 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md @@ -183,7 +183,7 @@ curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/lates ```powershell # 예 -.\Install-Containerd.ps1 -ContainerDVersion v1.4.1 +.\Install-Containerd.ps1 -ContainerDVersion 1.4.1 ``` {{< /note >}} diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 487d89379e..de6feb480d 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -1,4 +1,6 @@ --- + + title: kubeadm을 사용한 인증서 관리 content_type: task weight: 10 @@ -83,7 +85,11 @@ front-proxy-ca Dec 28, 2029 23:36 UTC 9y no {{< /warning >}} {{< note >}} -kubeadm은 자동 인증서 갱신을 위해 kubelet을 구성하기 때문에 `kubelet.conf` 는 위 목록에 포함되어 있지 않다. +`kubelet.conf` 는 위 목록에 포함되어 있지 않은데, 이는 +kubeadm이 [자동 인증서 갱신](/ko/docs/tasks/tls/certificate-rotation/)을 위해 +`/var/lib/kubelet/pki`에 있는 갱신 가능한 인증서를 이용하여 kubelet을 구성하기 때문이다. +만료된 kubelet 클라이언트 인증서를 갱신하려면 +[kubelet 클라이언트 갱신 실패](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#kubelet-client-cert) 섹션을 확인한다. {{< /note >}} {{< warning >}} @@ -155,7 +161,7 @@ HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서 빌트인 서명자를 활성화하려면, `--cluster-signing-cert-file` 와 `--cluster-signing-key-file` 플래그를 전달해야 한다. -새 클러스터를 생성하는 경우, kubeadm [구성 파일](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2)을 사용할 수 있다. +새 클러스터를 생성하는 경우, kubeadm [구성 파일](/docs/reference/config-api/kubeadm-config.v1beta2/)을 사용할 수 있다. ```yaml apiVersion: kubeadm.k8s.io/v1beta2 @@ -168,7 +174,7 @@ controllerManager: ### 인증서 서명 요청(CSR) 생성 -쿠버네티스 API로 CSR을 작성하려면 [CertificateSigningRequest 생성](https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)을 본다. +쿠버네티스 API로 CSR을 작성하려면 [CertificateSigningRequest 생성](/docs/reference/access-authn-authz/certificate-signing-requests/#create-certificatesigningrequest)을 본다. ## 외부 CA로 인증서 갱신 @@ -190,11 +196,13 @@ CSR과 함께 제공되는 개인 키가 모두 출력된다. `kubeadm init` 과 마찬가지로 출력 디렉터리를 `--csr-dir` 플래그로 지정할 수 있다. CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지정하지는 않는다. -인증서를 발행할 때 [올바른 인증서 용도](/ko/docs/setup/best-practices/certificates/#모든-인증서)를 지정하는 것은 CA의 책임이다. +인증서를 발행할 때 [올바른 인증서 용도](/ko/docs/setup/best-practices/certificates/#모든-인증서)를 +지정하는 것은 CA의 책임이다. * `openssl` 의 경우 [`openssl ca` 명령](https://superuser.com/questions/738612/openssl-ca-keyusage-extension)으로 수행한다. -* `cfssl` 의 경우 [설정 파일에 용도](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170)를 지정한다. +* `cfssl` 의 경우 + [설정 파일에 용도](https://github.com/cloudflare/cfssl/blob/master/doc/cmd/cfssl.txt#L170)를 지정한다. 선호하는 방법으로 인증서에 서명한 후, 인증서와 개인 키를 PKI 디렉터리(기본적으로 `/etc/kubernetes/pki`)에 복사해야 한다. @@ -203,3 +211,71 @@ CSR에는 인증서 이름, 도메인 및 IP가 포함되지만, 용도를 지 Kubeadm은 CA 인증서의 순환이나 교체 기능을 기본적으로 지원하지 않는다. CA의 수동 순환이나 교체에 대한 보다 상세한 정보는 [CA 인증서 수동 순환](/docs/tasks/tls/manual-rotation-of-ca-certificates/) 문서를 참조한다. + +## 서명된 kubelet 인증서 활성화하기 {#kubelet-serving-certs} + +기본적으로 kubeadm에 의해서 배포된 kubelet 인증서는 자가 서명된(self-signed) 것이다. +이것은 [metrics-server](https://github.com/kubernetes-sigs/metrics-server)와 +같은 외부 서비스의 kubelet에 대한 연결은 +TLS로 보안되지 않음을 의미한다. + +제대로 서명된 인증서를 얻기 위해서 신규 kubeadm 클러스터의 kubelet을 구성하려면 +다음의 최소 구성을 `kubeadm init` 에 전달해야 한다. + +```yaml +apiVersion: kubeadm.k8s.io/v1beta2 +kind: ClusterConfiguration +--- +apiVersion: kubelet.config.k8s.io/v1beta1 +kind: KubeletConfiguration +serverTLSBootstrap: true +``` + +만약 이미 클러스터를 생성했다면 다음을 따라 이를 조정해야 한다. + - `kube-system` 네임스페이스에서 `kubelet-config-{{< skew latestVersion >}}` 컨피그맵을 찾아서 수정한다. +해당 컨피그맵에는 `kubelet` 키가 +[KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) +문서를 값으로 가진다. `serverTLSBootstrap: true` 가 되도록 KubeletConfiguration 문서를 수정한다. +- 각 노드에서, `serverTLSBootstrap: true` 필드를 `/var/lib/kubelet/config.yaml` 에 추가한다. +그리고 `systemctl restart kubelet` 로 kubelet을 재시작한다. + +`serverTLSBootstrap: true` 필드는 kubelet 인증서를 이용한 부트스트랩을 +`certificates.k8s.io` API에 요청함으로써 활성화할 것이다. 한 가지 알려진 제약은 +이 인증서들에 대한 CSR(인증서 서명 요청)들이 kube-controller-manager - +[`kubernetes.io/kubelet-serving`](/docs/reference/access-authn-authz/certificate-signing-requests/#kubernetes-signers)의 +기본 서명자(default signer)에 의해서 자동으로 승인될 수 없다는 점이다. +이것은 사용자나 제 3의 컨트롤러의 액션을 필요로 할 것이다. + +이 CSR들은 다음을 통해 볼 수 있다. + +```shell +kubectl get csr +NAME AGE SIGNERNAME REQUESTOR CONDITION +csr-9wvgt 112s kubernetes.io/kubelet-serving system:node:worker-1 Pending +csr-lz97v 1m58s kubernetes.io/kubelet-serving system:node:control-plane-1 Pending +``` + +이를 승인하기 위해서는 다음을 수행한다. +```shell +kubectl certificate approve +``` + +기본적으로, 이 인증서는 1년 후에 만기될 것이다. Kubeadm은 +`KubeletConfiguration` 필드의 `rotateCertificates` 를 `true` 로 설정한다. 이것은 만기가 +다가오면 인증서를 위한 신규 CSR 세트가 생성되는 것을 의미하며, +해당 순환(rotation)을 완료하기 위해서는 승인이 되어야 한다는 것을 의미한다. 더 상세한 이해를 위해서는 +[인증서 순환](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#certificate-rotation)를 확인한다. + +만약 이 CSR들의 자동 승인을 위한 솔루션을 찾고 있다면 클라우드 제공자와 +연락하여 대역 외 메커니즘(out of band mechanism)을 통해 노드의 신분을 검증할 수 있는 +CSR 서명자를 가지고 있는지 문의하는 것을 추천한다. + +{{% thirdparty-content %}} + +제 3 자 커스텀 컨트롤러도 사용될 수 있다. +- [kubelet-rubber-stamp](https://github.com/kontena/kubelet-rubber-stamp) + +이러한 컨트롤러는 CSR의 CommonName과 요청된 IPs 및 도메인 네임을 +모두 검증하지 않는 한, 보안이 되는 메커니즘이 아니다. 이것을 통해 악의적 행위자가 +kubelet 인증서(클라이언트 인증)를 사용하여 아무 IP나 도메인 네임에 대해 인증서를 +요청하는 CSR의 생성을 방지할 수 있을 것이다. diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index bf70b98e93..c009339acc 100644 --- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -37,8 +37,8 @@ weight: 20 ### 추가 정보 -- kubelet 마이너 버전을 업그레이드하기 전에 [노드 드레이닝(draining)](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/)이 - 필요하다. 컨트롤 플레인 노드의 경우 CoreNDS 파드 또는 기타 중요한 워크로드를 실행할 수 있다. +- kubelet 마이너 버전을 업그레이드하기 전에 [노드 드레이닝(draining)](/docs/tasks/administer-cluster/safely-drain-node/)이 + 필요하다. 컨트롤 플레인 노드의 경우 CoreDNS 파드 또는 기타 중요한 워크로드를 실행할 수 있다. - 컨테이너 사양 해시 값이 변경되므로, 업그레이드 후 모든 컨테이너가 다시 시작된다. @@ -328,7 +328,7 @@ etcd 업그레이드가 실패하고 자동 롤백이 작동하지 않으면, - 컨트롤 플레인 이미지가 사용 가능한지 또는 머신으로 가져올 수 있는지 확인한다. - 컴포넌트 구성에 버전 업그레이드가 필요한 경우 대체 구성을 생성하거나 사용자가 제공한 것으로 덮어 쓰기한다. - 컨트롤 플레인 컴포넌트 또는 롤백 중 하나라도 나타나지 않으면 업그레이드한다. -- 새로운 `kube-dns` 와 `kube-proxy` 매니페스트를 적용하고 필요한 모든 RBAC 규칙이 생성되도록 한다. +- 새로운 `CoreDNS` 와 `kube-proxy` 매니페스트를 적용하고 필요한 모든 RBAC 규칙이 생성되도록 한다. - API 서버의 새 인증서와 키 파일을 작성하고 180일 후에 만료될 경우 이전 파일을 백업한다. `kubeadm upgrade node` 는 추가 컨트롤 플레인 노드에서 다음을 수행한다. diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md index bee3c94069..25abb14314 100644 --- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md +++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/calico-network-policy.md @@ -18,7 +18,7 @@ weight: 10 **사전요구사항**: [gcloud](https://cloud.google.com/sdk/docs/quickstarts). -1. 캘리코로 GKE 클러스터를 시작하려면, `--enable-network-policy` 플래그를 추가하면 된다. +1. 캘리코로 GKE 클러스터를 시작하려면, `--enable-network-policy` 플래그를 추가한다. **문법** ```shell diff --git a/content/ko/docs/tasks/configmap-secret/_index.md b/content/ko/docs/tasks/configmap-secret/_index.md new file mode 100644 index 0000000000..e63c605924 --- /dev/null +++ b/content/ko/docs/tasks/configmap-secret/_index.md @@ -0,0 +1,6 @@ +--- +title: "시크릿(Secret) 관리" +weight: 28 +description: 시크릿을 사용하여 기밀 설정 데이터 관리. +--- + diff --git a/content/ko/docs/tasks/configmap-secret/managing-secret-using-config-file.md b/content/ko/docs/tasks/configmap-secret/managing-secret-using-config-file.md new file mode 100644 index 0000000000..3248328907 --- /dev/null +++ b/content/ko/docs/tasks/configmap-secret/managing-secret-using-config-file.md @@ -0,0 +1,198 @@ +--- +title: 환경 설정 파일을 사용하여 시크릿을 관리 +content_type: task +weight: 20 +description: 환경 설정 파일을 사용하여 시크릿 오브젝트를 생성. +--- + + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + + + +## 환경 설정 파일 생성 + +먼저 새 파일에 JSON 이나 YAML 형식으로 시크릿(Secret)에 대한 상세 사항을 기록하고, +이 파일을 이용하여 해당 시크릿 오브젝트를 생성할 수 있다. 이 +[시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) +리소스에는 `data` 와 `stringData` 의 두 가지 맵이 포함되어 있다. +`data` 필드는 base64로 인코딩된 임의의 데이터를 기입하는 데 사용된다. +`stringData` 필드는 편의를 위해 제공되며, 이를 사용해 시크릿 데이터를 인코딩되지 않은 문자열로 +기입할 수 있다. +`data` 및 `stringData`은 영숫자, +`-`, `_` 그리고 `.`로 구성되어야 한다. + +예를 들어 시크릿에 `data` 필드를 사용하여 두 개의 문자열을 저장하려면 다음과 같이 +문자열을 base64로 변환한다. + +```shell +echo -n 'admin' | base64 +``` + +출력은 다음과 유사하다. + +``` +YWRtaW4= +``` + +```shell +echo -n '1f2d1e2e67df' | base64 +``` + +출력은 다음과 유사하다. + +``` +MWYyZDFlMmU2N2Rm +``` + +다음과 같이 시크릿 구성 파일을 작성한다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +``` + +시크릿 오브젝트의 이름은 유효한 +[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다. + +{{< note >}} +시크릿 데이터의 직렬화된(serialized) JSON 및 YAML 값은 base64 문자열로 인코딩된다. +이러한 문자열에는 개행(newline)을 사용할 수 없으므로 생략해야 한다. +Darwin/macOS에서 `base64` 도구를 사용할 경우, 사용자는 긴 줄을 분할하는 `-b` 옵션을 사용해서는 안 된다. +반대로, 리눅스 사용자는 `-w` 옵션을 사용할 수 없는 경우 +`base64` 명령어 또는 `base64 | tr -d '\n'` 파이프라인에 +`-w 0` 옵션을 *추가해야 한다*. +{{< /note >}} + +특정 시나리오의 경우 `stringData` 필드를 대신 사용할 수 있다. 이 +필드를 사용하면 base64로 인코딩되지 않은 문자열을 시크릿에 직접 넣을 수 있으며, +시크릿이 생성되거나 업데이트될 때 문자열이 인코딩된다. + +이에 대한 실제적인 예로, +시크릿을 사용하여 구성 파일을 저장하는 애플리케이션을 배포하면서, +배포 프로세스 중에 해당 구성 파일의 일부를 채우려는 경우를 들 수 있다. + +예를 들어 애플리케이션에서 다음 구성 파일을 사용하는 경우: + +```yaml +apiUrl: "https://my.api.com/api/v1" +username: "" +password: "" +``` + +다음 정의를 사용하여 이를 시크릿에 저장할 수 있다. + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +stringData: + config.yaml: | + apiUrl: "https://my.api.com/api/v1" + username: + password: +``` + +## 시크릿 오브젝트 생성 + +[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)를 이용하여 시크릿 오브젝트를 생성한다. + +```shell +kubectl apply -f ./secret.yaml +``` + +출력은 다음과 유사하다. + +``` +secret/mysecret created +``` + +## 시크릿 확인 + +`stringData` 필드는 쓰기 전용 편의 필드이다. 시크릿을 조회할 때 절대 출력되지 않는다. +예를 들어 다음 명령을 실행하는 경우: + +```shell +kubectl get secret mysecret -o yaml +``` + +출력은 다음과 유사하다. + +```yaml +apiVersion: v1 +data: + config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19 +kind: Secret +metadata: + creationTimestamp: 2018-11-15T20:40:59Z + name: mysecret + namespace: default + resourceVersion: "7225" + uid: c280ad2e-e916-11e8-98f2-025000000001 +type: Opaque +``` + +`kubectl get` 및 `kubectl describe` 명령은 기본적으로 `시크릿`의 내용을 표시하지 않는다. +이는 `시크릿`이 실수로 구경꾼에게 노출되거나 +터미널 로그에 저장되는 것을 방지하기 위한 것이다. +인코딩된 데이터의 실제 내용을 확인하려면 다음을 참조한다. +[시크릿 디코딩](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret). + +하나의 필드(예: `username`)가 `data`와 `stringData`에 모두 명시되면, `stringData`에 명시된 값이 사용된다. +예를 들어 다음과 같은 시크릿인 경우: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + username: YWRtaW4= +stringData: + username: administrator +``` + +결과는 다음과 같은 시크릿이다. + +```yaml +apiVersion: v1 +data: + username: YWRtaW5pc3RyYXRvcg== +kind: Secret +metadata: + creationTimestamp: 2018-11-15T20:46:46Z + name: mysecret + namespace: default + resourceVersion: "7579" + uid: 91460ecb-e917-11e8-98f2-025000000001 +type: Opaque +``` + +여기서 `YWRtaW5pc3RyYXRvcg==`는 `administrator`으로 디코딩된다. + +## 삭제 + +생성한 시크릿을 삭제하려면 다음 명령을 실행한다. + +```shell +kubectl delete secret mysecret +``` + +## {{% heading "whatsnext" %}} + +- [시크릿 개념](/ko/docs/concepts/configuration/secret/)에 대해 자세히 알아보기 +- [`kubectl` 커맨드를 사용하여 시크릿을 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 알아보기 +- [kustomize를 사용하여 시크릿을 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 알아보기 + diff --git a/content/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl.md b/content/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl.md new file mode 100644 index 0000000000..8b3f62217e --- /dev/null +++ b/content/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl.md @@ -0,0 +1,156 @@ +--- +title: kubectl을 사용한 시크릿 관리 +content_type: task +weight: 10 +description: kubectl 커맨드를 사용하여 시크릿 오브젝트를 생성. +--- + + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + + + +## 시크릿 생성 + +`시크릿`에는 파드가 데이터베이스에 접근하는 데 필요한 사용자 자격 증명이 포함될 수 있다. +예를 들어 데이터베이스 연결 문자열은 사용자 이름과 암호로 구성된다. +사용자 이름은 로컬 컴퓨터의 `./username.txt` 파일에, 비밀번호는 +`./password.txt` 파일에 저장할 수 있다. + +```shell +echo -n 'admin' > ./username.txt +echo -n '1f2d1e2e67df' > ./password.txt +``` +이 명령에서 `-n` 플래그는 생성된 파일의 +텍스트 끝에 추가 개행 문자가 포함되지 않도록 해 준다. 이는 `kubectl`이 파일을 읽고 +내용을 base64 문자열로 인코딩할 때 개행 문자도 함께 인코딩될 수 있기 때문에 +중요하다. + +`kubectl create secret` 명령은 이러한 파일들을 시크릿으로 패키징하고 +API 서버에 오브젝트를 생성한다. + +```shell +kubectl create secret generic db-user-pass \ + --from-file=./username.txt \ + --from-file=./password.txt +``` + +출력은 다음과 유사하다. + +``` +secret/db-user-pass created +``` + +기본 키 이름은 파일 이름이다. 선택적으로 `--from-file=[key=]source`를 사용하여 키 이름을 설정할 수 있다. +예제: + +```shell +kubectl create secret generic db-user-pass \ + --from-file=username=./username.txt \ + --from-file=password=./password.txt +``` + +파일에 포함하는 암호 문자열에서 +특수 문자를 이스케이프하지 않아도 된다. + +`--from-literal==` 태그를 사용하여 시크릿 데이터를 제공할 수도 있다. +이 태그는 여러 키-값 쌍을 제공하기 위해 두 번 이상 지정할 수 있다. +`$`, `\`, `*`, `=` 및 `!`와 같은 특수 문자는 +[shell](https://en.wikipedia.org/wiki/Shell_(computing))에 해석하고 처리하기 때문에 +이스케이프할 필요가 있다. + +대부분의 셸에서 암호를 이스케이프하는 가장 쉬운 방법은 암호를 작은따옴표(`'`)로 둘러싸는 것이다. +예를 들어, 비밀번호가 `S!B\*d$zDsb=`인 경우, +다음 커맨드를 실행한다. + +```shell +kubectl create secret generic dev-db-secret \ + --from-literal=username=devuser \ + --from-literal=password='S!B\*d$zDsb=' +``` + +## 시크릿 확인 + +시크릿이 생성되었는지 확인한다. + +```shell +kubectl get secrets +``` + +출력은 다음과 유사하다. + +``` +NAME TYPE DATA AGE +db-user-pass Opaque 2 51s +``` + +다음 명령을 실행하여 `시크릿`에 대한 상세 사항을 볼 수 있다. + +```shell +kubectl describe secrets/db-user-pass +``` + +출력은 다음과 유사하다. + +``` +Name: db-user-pass +Namespace: default +Labels: +Annotations: + +Type: Opaque + +Data +==== +password: 12 bytes +username: 5 bytes +``` + +`kubectl get` 및 `kubectl describe` 명령은 +기본적으로 `시크릿`의 내용을 표시하지 않는다. 이는 `시크릿`이 실수로 노출되거나 +터미널 로그에 저장되는 것을 방지하기 위한 것이다. + +## 시크릿 디코딩 {#decoding-secret} + +생성한 시크릿을 보려면 다음 명령을 실행한다. + +```shell +kubectl get secret db-user-pass -o jsonpath='{.data}' +``` + +출력은 다음과 유사하다. + +```json +{"password":"MWYyZDFlMmU2N2Rm","username":"YWRtaW4="} +``` + +이제 `password` 데이터를 디코딩할 수 있다. + +```shell +echo 'MWYyZDFlMmU2N2Rm' | base64 --decode +``` + +출력은 다음과 유사하다. + +``` +1f2d1e2e67df +``` + +## 삭제 + +생성한 시크릿을 삭제하려면 다음 명령을 실행한다. + +```shell +kubectl delete secret db-user-pass +``` + + + +## {{% heading "whatsnext" %}} + +- [시크릿 개념](/ko/docs/concepts/configuration/secret/)에 대해 자세히 알아보기 +- [환경 설정 파일을 사용하여 시크릿을 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 알아보기 +- [kustomize를 사용하여 시크릿을 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize/)하는 방법 알아보기 diff --git a/content/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize.md b/content/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize.md new file mode 100644 index 0000000000..2198903885 --- /dev/null +++ b/content/ko/docs/tasks/configmap-secret/managing-secret-using-kustomize.md @@ -0,0 +1,139 @@ +--- +title: kustomize를 사용하여 시크릿 관리 +content_type: task +weight: 30 +description: kustomization.yaml 파일을 사용하여 시크릿 오브젝트 생성. +--- + + + +쿠버네티스 v1.14부터 `kubectl`은 +[Kustomize를 이용한 쿠버네티스 오브젝트의 선언형 관리](/ko/docs/tasks/manage-kubernetes-objects/kustomization/)를 지원한다. +Kustomize는 시크릿 및 컨피그맵을 생성하기 위한 리소스 생성기를 제공한다. +Kustomize 생성기는 디렉토리 내의 `kustomization.yaml` 파일에 지정되어야 한다. +시크릿 생성 후 `kubectl apply`를 통해 API +서버에 시크릿을 생성할 수 있다. + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + + + +## Kustomization 파일 생성 + +`kustomization.yaml` 파일에 다른 기존 파일을 참조하는 +`secretGenerator`를 정의하여 시크릿을 생성할 수 있다. +예를 들어 다음 kustomization 파일은 +`./username.txt` 및 `./password.txt` 파일을 참조한다. + +```yaml +secretGenerator: +- name: db-user-pass + files: + - username.txt + - password.txt +``` + +`kustomization.yaml` 파일에 리터럴을 명시하여 `secretGenerator`를 +정의할 수도 있다. +예를 들어 다음 `kustomization.yaml` 파일에는 +각각 `username`과 `password`에 대한 두 개의 리터럴이 포함되어 있다. + +```yaml +secretGenerator: +- name: db-user-pass + literals: + - username=admin + - password=1f2d1e2e67df +``` + +`kustomization.yaml` 파일에 `.env` 파일을 명시하여 +`secretGenerator`를 정의할 수도 있다. +예를 들어 다음 `kustomization.yaml` 파일은 +`.env.secret` 파일에서 데이터를 가져온다. + +```yaml +secretGenerator: +- name: db-user-pass + envs: + - .env.secret +``` + +모든 경우에 대해, 값을 base64로 인코딩하지 않아도 된다. + +## 시크릿 생성 + +다음 명령을 실행하여 시크릿을 생성한다. + +```shell +kubectl apply -k . +``` + +출력은 다음과 유사하다. + +``` +secret/db-user-pass-96mffmfh4k created +``` + +시크릿이 생성되면 시크릿 데이터를 해싱하고 +이름에 해시 값을 추가하여 시크릿 이름이 생성된다. 이렇게 함으로써 +데이터가 수정될 때마다 시크릿이 새롭게 생성된다. + +## 생성된 시크릿 확인 + +시크릿이 생성된 것을 확인할 수 있다. + +```shell +kubectl get secrets +``` + +출력은 다음과 유사하다. + +``` +NAME TYPE DATA AGE +db-user-pass-96mffmfh4k Opaque 2 51s +``` + +다음 명령을 실행하여 시크릿에 대한 상세 사항을 볼 수 있다. + +```shell +kubectl describe secrets/db-user-pass-96mffmfh4k +``` + +출력은 다음과 유사하다. + +``` +Name: db-user-pass-96mffmfh4k +Namespace: default +Labels: +Annotations: + +Type: Opaque + +Data +==== +password.txt: 12 bytes +username.txt: 5 bytes +``` + +`kubectl get` 및 `kubectl describe` 명령은 기본적으로 `시크릿`의 내용을 표시하지 않는다. +이는 `시크릿`이 실수로 구경꾼에게 노출되는 것을 방지하기 위한 것으로, +또는 터미널 로그에 저장되지 않는다. +인코딩된 데이터의 실제 내용을 확인하려면 다음을 참조한다. +[시크릿 디코딩](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret). + +## 삭제 + +생성한 시크릿을 삭제하려면 다음 명령을 실행한다. + +```shell +kubectl delete secret db-user-pass-96mffmfh4k +``` + + +## {{% heading "whatsnext" %}} + +- [시크릿 개념](/ko/docs/concepts/configuration/secret/)에 대해 자세히 알아보기 +- [`kubectl` 커맨드을 사용하여 시크릿 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl/) 방법 알아보기 +- [환경 설정 파일을 사용하여 시크릿을 관리](/ko/docs/tasks/configmap-secret/managing-secret-using-config-file/)하는 방법 알아보기 diff --git a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index dc4acf8411..3461c57061 100644 --- a/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -28,7 +28,7 @@ weight: 60 * 사용자는 노드가 단 하나만 있는 쿠버네티스 클러스터가 필요하고, {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} 커맨드라인 툴이 사용자의 클러스터와 통신할 수 있도록 설정되어 있어야 한다. 만약 사용자가 -아직 단일 노드 클러스터를 가지고 있지 않다면, [Minikube](/ko/docs/setup/learning-environment/minikube/)를 +아직 단일 노드 클러스터를 가지고 있지 않다면, [Minikube](/ko/docs/tasks/tools/#minikube)를 사용하여 클러스터 하나를 생성할 수 있다. * [퍼시스턴트 볼륨](https://minikube.sigs.k8s.io/docs/)의 diff --git a/content/ko/docs/tasks/configure-pod-container/configure-runasusername.md b/content/ko/docs/tasks/configure-pod-container/configure-runasusername.md new file mode 100644 index 0000000000..8bae2f4286 --- /dev/null +++ b/content/ko/docs/tasks/configure-pod-container/configure-runasusername.md @@ -0,0 +1,126 @@ +--- +title: 윈도우 파드 및 컨테이너에서 RunAsUserName 구성 +content_type: task +weight: 20 +--- + + + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +이 페이지에서는 윈도우 노드에서 실행될 파드 및 컨테이너에 `runAsUserName` 설정을 사용하는 방법을 소개한다. 이는 리눅스 관련 `runAsUser` 설정과 거의 동일하여, 컨테이너의 기본값과 다른 username으로 애플리케이션을 실행할 수 있다. + + + +## {{% heading "prerequisites" %}} + + +쿠버네티스 클러스터가 있어야 하며 클러스터와 통신하도록 kubectl 명령줄 도구를 구성해야 한다. 클러스터에는 윈도우 워커 노드가 있어야 하고, 해당 노드에서 윈도우 워크로드를 실행하는 컨테이너의 파드가 스케쥴 된다. + + + + + +## 파드의 username 설정 + +파드의 컨테이너 프로세스를 실행할 username을 지정하려면 파드 명세에 `securityContext` 필드 ([PodSecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritycontext-v1-core)) 를 포함시키고, 그 안에 `runAsUserName` 필드를 포함하는 `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)) 필드를 추가한다. + +파드에 지정하는 윈도우 보안 컨텍스트 옵션은 파드의 모든 컨테이너 및 초기화 컨테이너에 적용된다. + +다음은 `runAsUserName` 필드가 설정된 윈도우 파드의 구성 파일이다. + +{{< codenew file="windows/run-as-username-pod.yaml" >}} + +파드를 생성한다. + +```shell +kubectl apply -f https://k8s.io/examples/windows/run-as-username-pod.yaml +``` + +파드의 컨테이너가 실행 중인지 확인한다. + +```shell +kubectl get pod run-as-username-pod-demo +``` + +실행 중인 컨테이너의 셸에 접근한다. + +```shell +kubectl exec -it run-as-username-pod-demo -- powershell +``` + +셸이 올바른 username인 사용자로 실행 중인지 확인한다. + +```powershell +echo $env:USERNAME +``` + +결과는 다음과 같다. + +```shell +ContainerUser +``` + +## 컨테이너의 username 설정 + +컨테이너의 프로세스를 실행할 username을 지정하려면, 컨테이너 매니페스트에 `securityContext` 필드 ([SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)) 를 포함시키고 그 안에 `runAsUserName` 필드를 포함하는 `windowsOptions` ([WindowsSecurityContextOptions](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#windowssecuritycontextoptions-v1-core)) 필드를 추가한다. + +컨테이너에 지정하는 윈도우 보안 컨텍스트 옵션은 해당 개별 컨테이너에만 적용되며 파드 수준에서 지정한 설정을 재정의한다. + +다음은 한 개의 컨테이너에 `runAsUserName` 필드가 파드 수준 및 컨테이너 수준에서 설정되는 파드의 구성 파일이다. + +{{< codenew file="windows/run-as-username-container.yaml" >}} + +파드를 생성한다. + +```shell +kubectl apply -f https://k8s.io/examples/windows/run-as-username-container.yaml +``` + +파드의 컨테이너가 실행 중인지 확인한다. + +```shell +kubectl get pod run-as-username-container-demo +``` + +실행 중인 컨테이너의 셸에 접근한다. + +```shell +kubectl exec -it run-as-username-container-demo -- powershell +``` + +셸이 사용자에게 올바른 username(컨테이너 수준에서 설정된 사용자)을 실행 중인지 확인한다. + +```powershell +echo $env:USERNAME +``` + +결과는 다음과 같다. + +```shell +ContainerAdministrator +``` + +## 윈도우 username 제약사항 + +이 기능을 사용하려면 `runAsUserName` 필드에 설정된 값이 유효한 username이어야 한다. 형식은 `DOMAIN\USER` 여야하고, 여기서 `DOMAIN\`은 선택 사항이다. 윈도우 username은 대소문자를 구분하지 않는다. 또한 `DOMAIN` 및 `USER` 와 관련된 몇 가지 제약사항이 있다. + +- `runAsUserName` 필드는 비워 둘 수 없으며 제어 문자를 포함할 수 없다. (ASCII 값: `0x00-0x1F`, `0x7F`) +- `DOMAIN`은 NetBios 이름 또는 DNS 이름이어야 하며 각각 고유한 제한이 있다. + - NetBios 이름: 최대 15 자, `.`(마침표)으로 시작할 수 없으며 다음 문자를 포함할 수 없다. `\ / : * ? " < > |` + - DNS 이름: 최대 255 자로 영숫자, 마침표(`.`), 대시(`-`)로만 구성되며, 마침표 또는 대시로 시작하거나 끝날 수 없다. +- `USER`는 최대 20자이며, *오직* 마침표나 공백들로는 구성할 수 없고, 다음 문자는 포함할 수 없다. `" / \ [ ] : ; | = , + * ? < > @`. + +`runAsUserName` 필드에 허용되는 값의 예 : `ContainerAdministrator`,`ContainerUser`, `NT AUTHORITY\NETWORK SERVICE`, `NT AUTHORITY\LOCAL SERVICE`. + +이러한 제약사항에 대한 자세한 내용은 [여기](https://support.microsoft.com/en-us/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and) 와 [여기](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.localaccounts/new-localuser?view=powershell-5.1)를 확인한다. + + + +## {{% heading "whatsnext" %}} + + +* [쿠버네티스에서 윈도우 컨테이너 스케줄링을 위한 가이드](/ko/docs/setup/production-environment/windows/user-guide-windows-containers/) +* [그룹 매니지드 서비스 어카운트를 이용하여 워크로드 신원 관리하기](/ko/docs/setup/production-environment/windows/user-guide-windows-containers/#그룹-매니지드-서비스-어카운트를-이용하여-워크로드-신원-관리하기) +* [윈도우 파드와 컨테이너의 GMSA 구성](/docs/tasks/configure-pod-container/configure-gmsa/) + diff --git a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md index 5a8295aff2..2188ced539 100644 --- a/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md +++ b/content/ko/docs/tasks/configure-pod-container/pull-image-private-registry.md @@ -55,7 +55,7 @@ cat ~/.docker/config.json ## 기존의 도커 자격 증명을 기반으로 시크릿 생성하기 {#registry-secret-existing-credentials} 쿠버네티스 클러스터는 프라이빗 이미지를 받아올 때, 컨테이너 레지스트리에 인증하기 위하여 -`docker-registry` 타입의 시크릿을 사용한다. +`kubernetes.io/dockerconfigjson` 타입의 시크릿을 사용한다. 만약 이미 `docker login` 을 수행하였다면, 이 때 생성된 자격 증명을 쿠버네티스 클러스터로 복사할 수 있다. diff --git a/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md b/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md index 57e0a94b40..c644a8aff1 100644 --- a/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md +++ b/content/ko/docs/tasks/configure-pod-container/quality-service-pod.md @@ -45,10 +45,14 @@ kubectl create namespace qos-example 파드에 Guaranteed QoS 클래스 할당을 위한 전제 조건은 다음과 같다. -* 파드의 초기화 컨테이너를 포함한 모든 컨테이너는 메모리 상한과 메모리 요청량을 가지고 있어야 하며, 이는 동일해야 한다. -* 파드의 초기화 컨테이너를 포함한 모든 컨테이너는 CPU 상한과 CPU 요청량을 가지고 있어야 하며, 이는 동일해야 한다. +* 파드 내 모든 컨테이너는 메모리 상한과 메모리 요청량을 가지고 있어야 한다. +* 파드 내 모든 컨테이너의 메모리 상한이 메모리 요청량과 일치해야 한다. +* 파드 내 모든 컨테이너는 CPU 상한과 CPU 요청량을 가지고 있어야 한다. +* 파드 내 모든 컨테이너의 CPU 상한이 CPU 요청량과 일치해야 한다. -이것은 하나의 컨테이너를 갖는 파드의 구성 파일이다. 해당 컨테이너는 메모리 상한과 +이러한 제약은 초기화 컨테이너와 앱 컨테이너 모두에 동일하게 적용된다. + +다음은 하나의 컨테이너를 갖는 파드의 구성 파일이다. 해당 컨테이너는 메모리 상한과 메모리 요청량을 갖고 있고, 200MiB로 동일하다. 해당 컨테이너는 CPU 상한과 CPU 요청량을 가지며, 700 milliCPU로 동일하다. {{< codenew file="pods/qos/qos-pod.yaml" >}} diff --git a/content/ko/docs/tasks/configure-pod-container/static-pod.md b/content/ko/docs/tasks/configure-pod-container/static-pod.md index 4daf739c2f..aea2fcffa1 100644 --- a/content/ko/docs/tasks/configure-pod-container/static-pod.md +++ b/content/ko/docs/tasks/configure-pod-container/static-pod.md @@ -31,21 +31,14 @@ API 서버에서 제어될 수는 없다. 을 사용하는 것이 바람직하다. {{< /note >}} - - ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} 이 페이지는 파드를 실행하기 위해 {{< glossary_tooltip term_id="docker" >}}를 사용하며, 노드에서 Fedora 운영 체제를 구동하고 있다고 가정한다. 다른 배포판이나 쿠버네티스 설치 지침과는 다소 상이할 수 있다. - - - - ## 스태틱 파드 생성하기 {#static-pod-creation} @@ -54,7 +47,9 @@ API 서버에서 제어될 수는 없다. ### 파일시스템이 호스팅 하는 스태틱 파드 매니페스트 {#configuration-files} -매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)의 `staticPodPath: ` 필드를 사용하자. 이 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다. +매니페스트는 특정 디렉터리에 있는 JSON 이나 YAML 형식의 표준 파드 정의이다. +[kubelet 구성 파일](/docs/reference/config-api/kubelet-config.v1beta1/)의 `staticPodPath: ` 필드를 사용하자. +명시한 디렉터리를 정기적으로 스캔하여, 디렉터리 안의 YAML/JSON 파일이 생성되거나 삭제되었을 때 스태틱 파드를 생성하거나 삭제한다. Kubelet 이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단어를 무시한다는 점을 유의하자. 예를 들어, 다음은 스태틱 파드로 간단한 웹 서버를 구동하는 방법을 보여준다. @@ -90,17 +85,18 @@ Kubelet 이 특정 디렉터리를 스캔할 때 점(.)으로 시작하는 단 3. 노드에서 kubelet 실행 시에 `--pod-manifest-path=/etc/kubelet.d/` 와 같이 인자를 제공하여 해당 디렉터리를 사용하도록 구성한다. Fedora 의 경우 이 줄을 포함하기 위하여 `/etc/kubernetes/kubelet` 파일을 다음과 같이 수정한다. - ``` - KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" - ``` - 혹은 [kubelet 구성 파일](/docs/tasks/administer-cluster/kubelet-config-file)에 `staticPodPath: ` 필드를 추가한다. + ``` + KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" + ``` + 혹은 [kubelet 구성 파일](/docs/reference/config-api/kubelet-config.v1beta1/)에 + `staticPodPath: ` 필드를 추가한다. 4. kubelet을 재시작한다. Fedora의 경우 아래와 같이 수행한다. - ```shell - # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. - systemctl restart kubelet - ``` + ```shell + # kubelet 이 동작하고 있는 노드에서 이 명령을 수행한다. + systemctl restart kubelet + ``` ### 웹이 호스팅 하는 스태틱 파드 매니페스트 {#pods-created-via-http} diff --git a/content/ko/docs/tasks/debug-application-cluster/_index.md b/content/ko/docs/tasks/debug-application-cluster/_index.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md b/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md index 2c7a95a136..f8696993ff 100644 --- a/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md +++ b/content/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller.md @@ -57,7 +57,7 @@ kubectl describe pods ${POD_NAME} 절대 스케줄 될 수 없다. 사용자는 `kubectl get nodes -o ` 명령으로 노드의 - 용량을 점검할 수 있다. 다음은 필요한 정보만을 추출하는 몇 가지 + 용량을 점검할 수 있다. 다음은 필요한 정보를 추출하는 몇 가지 명령의 예이다. ```shell diff --git a/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md b/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md index 3c8df08ede..4dde485c13 100644 --- a/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md +++ b/content/ko/docs/tasks/debug-application-cluster/determine-reason-pod-failure.md @@ -41,7 +41,7 @@ content_type: task kubectl apply -f https://k8s.io/examples/debug/termination.yaml - YAML 파일에 있는 `cmd` 와 `args` 필드에서 컨테이너가 10초 간 잠든 뒤에 + YAML 파일에 있는 `command` 와 `args` 필드에서 컨테이너가 10초 간 잠든 뒤에 "Sleep expired" 문자열을 `/dev/termination-log` 파일에 기록하는 것을 확인할 수 있다. 컨테이너는 "Sleep expired" 메시지를 기록한 후에 종료된다. diff --git a/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md index e2b1435464..26353959ef 100644 --- a/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/ko/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -1,12 +1,18 @@ --- title: 크론잡(CronJob)으로 자동화된 작업 실행 -min-kubernetes-server-version: v1.8 +min-kubernetes-server-version: v1.21 + + content_type: task weight: 10 --- +쿠버네티스 버전 1.21에서 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}이 GA (General Availability)로 승격되었다. +이전 버전의 쿠버네티스를 사용하고 있다면, 해당 쿠버네티스 버전의 문서를 참고하여 정확한 정보를 확인할 수 있다. +이전 버전의 쿠버네티스는 `batch/v1` 크론잡 API를 지원하지 않는다. + 시간 기반의 스케줄에 따라 {{< glossary_tooltip text="크론잡" term_id="cronjob" >}}을 이용해서 {{< glossary_tooltip text="잡(Job)" term_id="job" >}}을 실행할 수 있다. 이러한 자동화된 잡은 리눅스 또는 유닉스 시스템에서 [크론](https://ko.wikipedia.org/wiki/Cron) 작업처럼 실행된다. @@ -140,7 +146,7 @@ kubectl delete cronjob hello `.spec.schedule` 은 `.spec` 의 필수 필드이다. 이는 해당 잡이 생성되고 실행되는 스케줄 시간으로 `0 * * * *` 또는 `@hourly` 와 같이 [크론](https://ko.wikipedia.org/wiki/Cron) 형식의 문자열을 받아들인다. -이 형식은 확장된 `vixie cron` 스텝(step) 값도 포함한다. 이 내용은 +이 형식은 확장된 "Vixie cron" 스텝(step) 값도 포함한다. 이 내용은 [FreeBSD 매뉴얼](https://www.freebsd.org/cgi/man.cgi?crontab%285%29)에 설명되어 있다. > 스텝 값은 범위(range)와 함께 사용할 수 있다. 범위 뒤에 `/` 를 @@ -168,13 +174,11 @@ kubectl delete cronjob hello 이러한 방식으로 기한을 맞추지 못한 잡은 실패한 작업으로 간주된다. 이 필드를 지정하지 않으면, 잡에 기한이 없다. -크론잡 컨트롤러는 크론 잡에 대해 얼마나 많은 스케줄이 누락되었는지를 계산한다. 누락된 스케줄이 100개를 초과 한다면, 크론 잡은 더이상 스케줄되지 않는다. `.spec.startingDeadlineSeconds` 이 설정되지 않았다면, 크론잡 컨트롤러는 `status.lastScheduleTime` 부터 지금까지 누락된 스케줄을 계산한다. +`.spec.startingDeadlineSeconds` 필드가 (null이 아닌 값으로) 설정되어 있다면, +크론잡 컨트롤러는 잡 생성 완료 예상 시각과 현재 시각의 차이를 측정하고, +시각 차이가 설정한 값보다 커지면 잡 생성 동작을 스킵한다. -예를 들어, 하나의 크론 잡이 1분마다 실행되도록 설정되어 있고, 크론잡의 `status.lastScheduleTime` 은 새벽 5:00시이지만, 지금은 오전 7:00시라고 가정하자. 즉 120개의 스케줄이 누락되었다는 것이고, 그래서 크론 잡은 더이상 스케줄되지 않는다. - -`.spec.startingDeadlineSeconds` 필드가 (null이 아닌) 값으로 설정되어 있다면, 크론잡 컨트롤러는 `.spec.startingDeadlineSeconds` 의 값으로부터 지금까지 얼마나 많은 잡이 누락되었는지를 계산한다. - -예를 들어, `200` 으로 설정되었다면, 지난 200초 동안 누락된 스케줄이 몇 번 발생했는지 계산한다. 이 경우, 지난 200초 동안 누락된 스케줄이 100개가 넘으면, 크론 잡이 더이상 스케줄되지 않는다. +예를 들어, `200` 으로 설정되었다면, 잡 생성 완료 예상 시각으로부터 200초까지는 잡이 생성될 수 있다. ### 동시성 정책 diff --git a/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md b/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md index fa765a7005..bd8bf38808 100644 --- a/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md +++ b/content/ko/docs/tasks/job/coarse-parallel-processing-work-queue.md @@ -2,7 +2,7 @@ title: 작업 대기열을 사용한 거친 병렬 처리 min-kubernetes-server-version: v1.8 content_type: task -weight: 30 +weight: 20 --- @@ -19,7 +19,7 @@ weight: 30 1. **메시지 대기열 서비스를 시작한다.** 이 예에서는, RabbitMQ를 사용하지만, 다른 메시지 대기열을 이용해도 된다. 실제로 사용할 때는, 한 번 메시지 대기열 서비스를 구축하고서 이를 여러 잡을 위해 재사용하기도 한다. 1. **대기열을 만들고, 메시지로 채운다.** 각 메시지는 수행할 하나의 작업을 나타낸다. - 이 예제에서, 메시지는 긴 계산을 수행할 정수일 뿐이다. + 이 예제에서, 메시지는 긴 계산을 수행할 정수다. 1. **대기열에서 작업을 수행하는 잡을 시작한다.** 잡은 여러 파드를 시작한다. 각 파드는 메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다. @@ -141,13 +141,12 @@ root@temp-loe07:/# ``` 마지막 커맨드에서, `amqp-consume` 도구는 대기열로부터 하나의 메시지를 -받고(`-c 1`), 그 메시지를 임의의 명령 표준입력으로 전달한다. 이 경우에는, `cat` 프로그램이 표준입력으로부터 -받은 값을 바로 출력하고 있고, echo가 캐리지 리턴을 더해주어 +받고(`-c 1`), 그 메시지를 임의의 명령 표준입력으로 전달한다. 이 경우에는, `cat` 프로그램이 표준입력으로부터 받은 값을 출력하고, echo가 캐리지 리턴을 더해주어 출력 결과가 보여진다. ## 작업으로 대기열 채우기 -이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제에서의 작업은 간단히 문자열을 +이제 몇 가지 "작업"으로 대기열을 채운다. 이 예제에서의 작업은 문자열을 출력하는 것이다. 실제로 사용할 때는, 메시지의 내용이 다음과 같을 수 있다. diff --git a/content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md b/content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md index 8788477c17..b85f687df7 100644 --- a/content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md +++ b/content/ko/docs/tasks/job/fine-parallel-processing-work-queue.md @@ -2,7 +2,7 @@ title: 작업 대기열을 사용한 정밀 병렬 처리 content_type: task min-kubernetes-server-version: v1.8 -weight: 40 +weight: 30 --- @@ -21,7 +21,7 @@ weight: 40 않기 때문에 Redis 및 사용자 지정의 작업 대기열 클라이언트 라이브러리를 사용한다. 실제로는 Redis와 같은 저장소를 한 번 설정하고 여러 작업과 다른 것들의 작업 대기열로 재사용한다. 1. **대기열을 만들고, 메시지로 채운다.** 각 메시지는 수행할 하나의 작업을 나타낸다. 이 - 예에서, 메시지는 긴 계산을 수행할 정수일 뿐이다. + 예에서, 메시지는 긴 계산을 수행할 정수다. 1. **대기열에서 작업을 수행하는 잡을 시작한다.** 잡은 여러 파드를 시작한다. 각 파드는 메시지 대기열에서 하나의 작업을 가져와서, 처리한 다음, 대기열이 비워질 때까지 반복한다. diff --git a/content/ko/docs/tasks/job/parallel-processing-expansion.md b/content/ko/docs/tasks/job/parallel-processing-expansion.md index ef02dac61b..fbf105024d 100644 --- a/content/ko/docs/tasks/job/parallel-processing-expansion.md +++ b/content/ko/docs/tasks/job/parallel-processing-expansion.md @@ -2,7 +2,7 @@ title: 확장을 사용한 병렬 처리 content_type: task min-kubernetes-server-version: v1.8 -weight: 20 +weight: 50 --- diff --git a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md index 659836833a..50a3a6ad2b 100644 --- a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md @@ -1,41 +1,42 @@ --- + + title: 데몬셋(DaemonSet)에서 롤링 업데이트 수행 content_type: task weight: 10 --- - - - 이 페이지는 데몬셋에서 롤링 업데이트를 수행하는 방법을 보여준다. ## {{% heading "prerequisites" %}} -* 데몬셋 롤링 업데이트 기능은 쿠버네티스 버전 1.6 이상에서만 지원된다. - ## 데몬셋 업데이트 전략 데몬셋에는 두 가지 업데이트 전략 유형이 있다. -* OnDelete: `OnDelete` 업데이트 전략을 사용하여, 데몬셋 템플릿을 업데이트한 후, +* `OnDelete`: `OnDelete` 업데이트 전략을 사용하여, 데몬셋 템플릿을 업데이트한 후, 이전 데몬셋 파드를 수동으로 삭제할 때 *만* 새 데몬셋 파드가 생성된다. 이것은 쿠버네티스 버전 1.5 이하에서의 데몬셋의 동작과 동일하다. -* RollingUpdate: 기본 업데이트 전략이다. +* `RollingUpdate`: 기본 업데이트 전략이다. `RollingUpdate` 업데이트 전략을 사용하여, 데몬셋 템플릿을 업데이트한 후, 오래된 데몬셋 파드가 종료되고, 새로운 데몬셋 파드는 - 제어 방식으로 자동 생성된다. 전체 업데이트 프로세스 동안 데몬셋의 최대 하나의 파드가 각 노드에서 실행된다. + 제어 방식으로 자동 생성된다. 전체 업데이트 프로세스 동안 + 데몬셋의 최대 하나의 파드가 각 노드에서 실행된다. ## 롤링 업데이트 수행 데몬셋의 롤링 업데이트 기능을 사용하려면, `.spec.updateStrategy.type` 에 `RollingUpdate` 를 설정해야 한다. -[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/ko/docs/concepts/workloads/controllers/deployment/#최대-불가max-unavailable)(기본값은 1)과 -[`.spec.minReadySeconds`](/ko/docs/concepts/workloads/controllers/deployment/#최소-대기-시간초)(기본값은 0)으로 설정할 수도 있다. +[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/ko/docs/concepts/workloads/controllers/deployment/#최대-불가max-unavailable) +(기본값은 1)과 +[`.spec.minReadySeconds`](/ko/docs/concepts/workloads/controllers/deployment/#최소-대기-시간초) +(기본값은 0)으로 +설정할 수도 있다. ### `RollingUpdate` 업데이트 전략으로 데몬셋 생성 @@ -111,8 +112,8 @@ kubectl edit ds/fluentd-elasticsearch -n kube-system ##### 컨테이너 이미지만 업데이트 -데몬셋 템플릿에서 컨테이너 이미지를 업데이트해야 하는 -경우(예: `.spec.template.spec.containers[*].image`), `kubectl set image` 를 사용한다. +데몬셋 템플릿(예: `.spec.template.spec.containers[*].image`)에 의해 정의된 컨테이너 이미지만 업데이트하려면, +`kubectl set image` 를 사용한다. ```shell kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=quay.io/fluentd_elasticsearch/fluentd:v2.6.0 -n kube-system @@ -142,7 +143,7 @@ daemonset "fluentd-elasticsearch" successfully rolled out #### 일부 노드에 리소스가 부족하다 적어도 하나의 노드에서 새 데몬셋 파드를 스케줄링할 수 없어서 롤아웃이 -중단되었다. 노드에 [리소스가 부족](/docs/tasks/administer-cluster/out-of-resource/)할 때 +중단되었다. 노드에 [리소스가 부족](/docs/concepts/scheduling-eviction/node-pressure-eviction/)할 때 발생할 수 있다. 이 경우, `kubectl get nodes` 의 출력 결과와 다음의 출력 결과를 비교하여 @@ -168,7 +169,7 @@ kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system 데몬셋 롤아웃이 진행되지 않는다. 이 문제를 해결하려면, 데몬셋 템플릿을 다시 업데이트한다. 이전의 비정상 롤아웃으로 인해 -새로운 롤아웃이 차단되지 않는다. +새로운 롤아웃이 차단되지는 않는다. #### 클럭 차이(skew) @@ -184,12 +185,7 @@ kubectl get pods -l name=fluentd-elasticsearch -o wide -n kube-system kubectl delete ds fluentd-elasticsearch -n kube-system ``` - - - ## {{% heading "whatsnext" %}} - -* [태스크: 데몬셋에서 롤백 - 수행](/ko/docs/tasks/manage-daemon/rollback-daemon-set/)을 참고한다. -* [개념: 기존 데몬셋 파드를 채택하기 위한 데몬셋 생성](/ko/docs/concepts/workloads/controllers/daemonset/)을 참고한다. +* [데몬셋에서 롤백 수행](/ko/docs/tasks/manage-daemon/rollback-daemon-set/)을 참고한다. +* [기존 데몬셋 파드를 채택하기 위한 데몬셋 생성](/ko/docs/concepts/workloads/controllers/daemonset/)을 참고한다. diff --git a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md index 78c5dc2cbd..087399df01 100644 --- a/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md +++ b/content/ko/docs/tasks/manage-gpus/scheduling-gpus.md @@ -13,7 +13,7 @@ description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성 쿠버네티스는 AMD 및 NVIDIA GPU(그래픽 프로세싱 유닛)를 노드들에 걸쳐 관리하기 위한 **실험적인** 지원을 포함한다. -이 페이지는 다른 쿠버네티스 버전 간에 걸쳐 사용자가 GPU들을 소비할 수 있는 방법과 +이 페이지는 여러 쿠버네티스 버전에서 사용자가 GPU를 활용할 수 있는 방법과 현재의 제약 사항을 설명한다. @@ -37,7 +37,7 @@ description: 클러스터의 노드별로 리소스로 사용할 GPU를 구성 `nvidia.com/gpu` 를 스케줄 가능한 리소스로써 노출시킨다. 사용자는 이 GPU들을 `cpu` 나 `memory` 를 요청하는 방식과 동일하게 -`.com/gpu` 를 요청함으로써 컨테이너를 통해 소비할 수 있다. +`.com/gpu` 를 요청함으로써 컨테이너에서 활용할 수 있다. 그러나 GPU를 사용할 때는 리소스 요구 사항을 명시하는 방식에 약간의 제약이 있다. diff --git a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md index e420acbed9..9484882f30 100644 --- a/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md +++ b/content/ko/docs/tasks/manage-kubernetes-objects/kustomization.md @@ -47,12 +47,12 @@ Kustomize는 쿠버네티스 구성을 사용자 정의화하는 도구이다. ### 리소스 생성 -컨피그 맵과 시크릿은 파드와 같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다. 컨피그 맵이나 시크릿의 실질적인 소스는 일반적으로 `.properties` 파일이나 ssh key 파일과 같은 것들은 클러스터 외부에 있다. -Kustomize는 시크릿과 컨피그 맵을 파일이나 문자열에서 생성하는 `secretGenerator`와 `configMapGenerator`를 가지고 있다. +컨피그맵과 시크릿은 파드와 같은 다른 쿠버네티스 오브젝트에서 사용되는 설정이나 민감한 데이터를 가지고 있다. 컨피그맵이나 시크릿의 실질적인 소스는 일반적으로 `.properties` 파일이나 ssh key 파일과 같은 것들은 클러스터 외부에 있다. +Kustomize는 시크릿과 컨피그맵을 파일이나 문자열에서 생성하는 `secretGenerator`와 `configMapGenerator`를 가지고 있다. #### configMapGenerator -파일에서 컨피그 맵을 생성하려면 `configMapGenerator` 내의 `files` 리스트에 항목을 추가한다. 다음은 하나의 `.properties` 파일에서 데이터 항목으로 컨피그 맵을 생성하는 예제이다. +파일에서 컨피그맵을 생성하려면 `configMapGenerator` 내의 `files` 리스트에 항목을 추가한다. 다음은 하나의 `.properties` 파일에서 데이터 항목으로 컨피그맵을 생성하는 예제이다. ```shell # application.properties 파일을 생성 @@ -68,13 +68,13 @@ configMapGenerator: EOF ``` -생성된 컨피그 맵은 다음 명령어로 검사할 수 있다. +생성된 컨피그맵은 다음 명령어로 검사할 수 있다. ```shell kubectl kustomize ./ ``` -생성된 컨피그 맵은 다음과 같다. +생성된 컨피그맵은 다음과 같다. ```yaml apiVersion: v1 @@ -86,7 +86,44 @@ metadata: name: example-configmap-1-8mbdf7882g ``` -컨피그 맵은 문자로된 키-값 쌍들로도 생성할 수 있다. 문자로된 키-값 쌍에서 컨피그 맵을 생성하려면, configMapGenerator 내의 `literals` 리스트에 항목을 추가한다. 다음은 키-값 쌍을 데이터 항목으로 받는 컨피그 맵을 생성하는 예제이다. +env 파일에서 컨피그맵을 생성하려면, `configMapGenerator`의 `envs` 리스트에 항목을 추가한다. 다음은 `.env` 파일의 데이터 항목으로 컨피그맵을 생성하는 예시를 보여준다. + +```shell +# .env 파일 생성 +cat <.env +FOO=Bar +EOF + +cat <./kustomization.yaml +configMapGenerator: +- name: example-configmap-1 + envs: + - .env +EOF +``` + +생성된 컨피그맵은 다음 명령어로 검사할 수 있다. + +```shell +kubectl kustomize ./ +``` + +생성된 컨피그맵은 다음과 같다. + +```yaml +apiVersion: v1 +data: + FOO=Bar +kind: ConfigMap +metadata: + name: example-configmap-1-8mbdf7882g +``` + +{{< note >}} +`.env` 파일의 각 변수는 생성한 컨피그맵에서 분리된 키가 된다. `.properties` 라는 이름의 파일을 내장하는 이전 예시(그리고 모든 항목들)는 단일 키를 위한 값이므로 이 예시와는 다르다. +{{< /note >}} + +컨피그맵은 문자로된 키-값 쌍들로도 생성할 수 있다. 문자로된 키-값 쌍에서 컨피그맵을 생성하려면, configMapGenerator 내의 `literals` 리스트에 항목을 추가한다. 다음은 키-값 쌍을 데이터 항목으로 받는 컨피그맵을 생성하는 예제이다. ```shell cat <./kustomization.yaml @@ -97,13 +134,13 @@ configMapGenerator: EOF ``` -생성된 컨피그 맵은 다음 명령어로 확인할 수 있다. +생성된 컨피그맵은 다음 명령어로 확인할 수 있다. ```shell kubectl kustomize ./ ``` -생성된 컨피그 맵은 다음과 같다. +생성된 컨피그맵은 다음과 같다. ```yaml apiVersion: v1 @@ -114,6 +151,98 @@ metadata: name: example-configmap-2-g2hdhfc6tk ``` +디플로이먼트에서 생성된 컨피그맵을 사용하기 위해서는, configMapGenerator의 이름을 참조한다. Kustomize는 자동으로 해당 이름을 생성된 이름으로 교체할 것이다. + +다음은 생성된 컨피그맵을 사용하는 디플로이먼트의 예시다. + +```yaml +# application.properties 파일을 생성한다. +cat <application.properties +FOO=Bar +EOF + +cat <deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-app + labels: + app: my-app +spec: + selector: + matchLabels: + app: my-app + template: + metadata: + labels: + app: my-app + spec: + containers: + - name: app + image: my-app + volumeMounts: + - name: config + mountPath: /config + volumes: + - name: config + configMap: + name: example-configmap-1 +EOF + +cat <./kustomization.yaml +resources: +- deployment.yaml +configMapGenerator: +- name: example-configmap-1 + files: + - application.properties +EOF +``` + +컨피그맵과 디플로이먼트를 생성한다. + +```shell +kubectl kustomize ./ +``` + +생성된 디플로이먼트는 이름을 통해서 생성된 컨피그맵을 참조한다. + +```yaml +apiVersion: v1 +data: + application.properties: | + FOO=Bar +kind: ConfigMap +metadata: + name: example-configmap-1-g4hk9g2ff8 +--- +apiVersion: apps/v1 +kind: Deployment +metadata: + labels: + app: my-app + name: my-app +spec: + selector: + matchLabels: + app: my-app + template: + metadata: + labels: + app: my-app + spec: + containers: + - image: my-app + name: app + volumeMounts: + - mountPath: /config + name: config + volumes: + - configMap: + name: example-configmap-1-g4hk9g2ff8 + name: config +``` + #### secretGenerator 파일 또는 문자로된 키-값 쌍들로 시크릿을 생성할 수 있다. 파일에서 시크릿을 생성하려면 `secretGenerator` 내의 `files` 리스트에 항목을 추가한다. 다음은 파일을 데이터 항목으로 받는 시크릿을 생성하는 예제이다. @@ -170,9 +299,56 @@ metadata: type: Opaque ``` +컨피그맵과 유사하게, 생성된 시크릿도 secretGenerator의 이름을 참조함으로써 디플로이먼트에서 사용될 수 있다. + +```shell +# password.txt 파일을 생성한다. +cat <./password.txt +username=admin +password=secret +EOF + +cat <deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: my-app + labels: + app: my-app +spec: + selector: + matchLabels: + app: my-app + template: + metadata: + labels: + app: my-app + spec: + containers: + - name: app + image: my-app + volumeMounts: + - name: password + mountPath: /secrets + volumes: + - name: password + secret: + secretName: example-secret-1 +EOF + +cat <./kustomization.yaml +resources: +- deployment.yaml +secretGenerator: +- name: example-secret-1 + files: + - password.txt +EOF +``` + #### generatorOptions -생성된 컨피그 맵과 시크릿은 콘텐츠 해시 접미사가 추가된다. 이는 콘텐츠가 변경될 때 새로운 컨피그 맵 이나 시크릿이 생성되는 것을 보장한다. 접미사를 추가하는 동작을 비활성화하는 방법으로 `generatorOptions`를 사용할 수 있다. 그밖에, 생성된 컨피그 맵과 시크릿에 교차 편집 옵션들을 지정해주는 것도 가능하다. +생성된 컨피그맵과 시크릿은 콘텐츠 해시 접미사가 추가된다. 이는 콘텐츠가 변경될 때 새로운 컨피그맵 이나 시크릿이 생성되는 것을 보장한다. 접미사를 추가하는 동작을 비활성화하는 방법으로 `generatorOptions`를 사용할 수 있다. 그밖에, 생성된 컨피그맵과 시크릿에 교차 편집 옵션들을 지정해주는 것도 가능하다. ```shell cat <./kustomization.yaml @@ -189,7 +365,7 @@ generatorOptions: EOF ``` -생성된 컨피그 맵을 보려면 `kubectl kustomize ./`를 실행한다. +생성된 컨피그맵을 보려면 `kubectl kustomize ./`를 실행한다. ```yaml apiVersion: v1 @@ -814,17 +990,17 @@ deployment.apps "dev-my-nginx" deleted | nameSuffix | string | 모든 리소스 네임에 이 필드의 값이 접미사로 추가된다 | | commonLabels | map[string]string | 모든 리소스와 셀렉터에 추가될 레이블 | | commonAnnotations | map[string]string | 모든 리소스에 추가될 어노테이션 | -| resources | []string | 이 리스트 내 각각의 항목은 반드시 존재하는 리소스 구성 파일로 해석되어져야 한다 | -| configmapGenerator | [][ConfigMapArgs](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L99) | 이 리스트 내 각각의 항목은 컨피그 맵을 생성한다 | -| secretGenerator | [][SecretArgs](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L106) | 이 리스트 내 각각의 항목은 시크릿을 생성한다 | -| generatorOptions | [GeneratorOptions](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/kustomization.go#L109) | 모든 configMapGenerator와 secretGenerator의 동작을 변경 | -| bases | []string | 이 리스트 내 각각의 항목은 kustomization.yaml 파일을 가지는 디렉터리로 해석되어져야 한다 | -| patchesStrategicMerge | []string | 이 리스트 내 각각의 항목은 쿠버네티스 오브젝트의 전략적 병합 패치로 해석되어져야 한다 | -| patchesJson6902 | [][Json6902](https://github.com/kubernetes-sigs/kustomize/blob/release-kustomize-v4.0/api/types/patchjson6902.go#L8) | 이 리스트 내 각각의 항목은 쿠버네티스 오브젝트와 Json 패치로 해석되어져야 한다 | -| vars | [][Var](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/var.go#L31) | 각각의 항목은 한 리소스의 필드에서 텍스트를 캡쳐한다 | -| images | [][Image](https://github.com/kubernetes-sigs/kustomize/tree/master/api/types/image.go#L23) | 각각의 항목은 패치를 생성하지 않고 한 이미지의 name, tags 그리고/또는 digest를 수정한다 | -| configurations | []string | 이 리스트 내 각각의 항목은 [Kustomize 변환 설정](https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs)을 포함하는 파일로 해석되어져야 한다 | -| crds | []string | 이 리스트 내 각각의 항목은 쿠버네티스 타입에 대한 OpenAPI 정의 파일로 해석되어져야 한다 | +| resources | []string | 이 리스트 내 각각의 항목은 반드시 존재하는 리소스 구성 파일로 해석되어야 한다. | +| configMapGenerator | [][ConfigMapArgs](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/configmapargs.go#L7) | 이 리스트의 각 항목은 컨피그맵을 생성한다. | +| secretGenerator | [][SecretArgs](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/secretargs.go#L7) | 이 리스트의 각 항목은 시크릿을 생성한다. | +| generatorOptions | [GeneratorOptions](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/generatoroptions.go#L7) | 모든 컨피그맵 및 시크릿 생성자(generator)의 동작을 수정한다. | +| bases | []string | 이 리스트 내 각각의 항목은 kustomization.yaml 파일을 가지는 디렉터리로 해석되어야 한다. | +| patchesStrategicMerge | []string | 이 리스트 내 각각의 항목은 쿠버네티스 오브젝트의 전략적 병합 패치로 해석되어야 한다. | +| patchesJson6902 | [][Patch](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/patch.go#L10) | 이 리스트 내 각각의 항목은 쿠버네티스 오브젝트와 Json 패치로 해석되어야 한다. | +| vars | [][Var](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/var.go#L19) | 각각의 항목은 한 리소스의 필드에서 텍스트를 캡쳐한다. | +| images | [][Image](https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/image.go#L8) | 각각의 항목은 패치를 생성하지 않고 하나의 이미지에 대한 name, tags 그리고/또는 digest를 수정한다. | +| configurations | []string | 이 리스트 내 각각의 항목은 [Kustomize 변환 설정](https://github.com/kubernetes-sigs/kustomize/tree/master/examples/transformerconfigs)을 포함하는 파일로 해석되어야 한다. | +| crds | []string | 이 리스트 내 각각의 항목은 쿠버네티스 타입에 대한 OpenAPI 정의 파일로 해석되어야 한다. | @@ -832,6 +1008,6 @@ deployment.apps "dev-my-nginx" deleted * [Kustomize](https://github.com/kubernetes-sigs/kustomize) -* [Kubectl 북](https://kubectl.docs.kubernetes.io) +* [Kubectl 문서](https://kubectl.docs.kubernetes.io) * [Kubectl 커맨드 참조](/docs/reference/generated/kubectl/kubectl-commands/) * [쿠버네티스 API 참조](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md b/content/ko/docs/tasks/network/customize-hosts-file-for-pods.md similarity index 98% rename from content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md rename to content/ko/docs/tasks/network/customize-hosts-file-for-pods.md index be39f13f21..1901f16726 100644 --- a/content/ko/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases.md +++ b/content/ko/docs/tasks/network/customize-hosts-file-for-pods.md @@ -1,6 +1,6 @@ --- title: HostAliases로 파드의 /etc/hosts 항목 추가하기 -content_type: concept +content_type: task weight: 60 min-kubernetes-server-version: 1.7 --- @@ -13,7 +13,7 @@ min-kubernetes-server-version: 1.7 HostAliases를 사용하지 않은 수정은 권장하지 않는데, 이는 호스트 파일이 kubelet에 의해 관리되고, 파드 생성/재시작 중에 덮어쓰여질 수 있기 때문이다. - + ## 기본 호스트 파일 내용 diff --git a/content/ko/docs/tasks/network/validate-dual-stack.md b/content/ko/docs/tasks/network/validate-dual-stack.md index a9f15956a0..5a3fdc477e 100644 --- a/content/ko/docs/tasks/network/validate-dual-stack.md +++ b/content/ko/docs/tasks/network/validate-dual-stack.md @@ -1,4 +1,8 @@ --- + + + + min-kubernetes-server-version: v1.20 title: IPv4/IPv6 이중 스택 검증 content_type: task @@ -36,9 +40,10 @@ a00:100::/24 ``` 단일 IPv4 블록과 단일 IPv6 블록이 할당되어야 한다. -노드가 IPv4 및 IPv6 인터페이스를 가지고 있는지 검증한다. (노드 이름을 클러스터의 검증된 노드로 대체한다. 본 예제에서 노드 이름은 k8s-linuxpool1-34450317-0) 이다. +노드가 IPv4 및 IPv6 인터페이스를 가지고 있는지 검증한다. 노드 이름을 클러스터의 검증된 노드로 대체한다. 본 예제에서 노드 이름은 `k8s-linuxpool1-34450317-0` 이다. + ```shell -kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .status.addresses}}{{printf "%s: %s \n" .type .address}}{{end}}' +kubectl get nodes k8s-linuxpool1-34450317-0 -o go-template --template='{{range .status.addresses}}{{printf "%s: %s\n" .type .address}}{{end}}' ``` ``` Hostname: k8s-linuxpool1-34450317-0 @@ -48,9 +53,10 @@ InternalIP: 2001:1234:5678:9abc::5 ### 파드 어드레싱 검증 -파드가 IPv4 및 IPv6 주소를 할당받았는지 검증한다. (파드 이름을 클러스터에서 검증된 파드로 대체한다. 본 예제에서 파드 이름은 pod01 이다.) +파드가 IPv4 및 IPv6 주소를 할당받았는지 검증한다. 파드 이름을 클러스터에서 검증된 파드로 대체한다. 본 예제에서 파드 이름은 `pod01` 이다. + ```shell -kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{printf "%s \n" .ip}}{{end}}' +kubectl get pods pod01 -o go-template --template='{{range .status.podIPs}}{{printf "%s\n" .ip}}{{end}}' ``` ``` 10.244.1.4 @@ -68,6 +74,7 @@ a00:100::4 ``` 다음 커맨드는 컨테이너 내 `MY_POD_IPS` 환경 변수의 값을 출력한다. 해당 값은 파드의 IPv4 및 IPv6 주소를 나타내는 쉼표로 구분된 목록이다. + ```shell kubectl exec -it pod01 -- set | grep MY_POD_IPS ``` @@ -225,3 +232,4 @@ kubectl get svc -l app=MyApp ```shell NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE my-service LoadBalancer fd00::7ebc 2603:1030:805::5 80:30790/TCP 35s +``` diff --git a/content/ko/docs/tasks/run-application/delete-stateful-set.md b/content/ko/docs/tasks/run-application/delete-stateful-set.md index 1ef9220d65..7c2b1ed783 100644 --- a/content/ko/docs/tasks/run-application/delete-stateful-set.md +++ b/content/ko/docs/tasks/run-application/delete-stateful-set.md @@ -1,4 +1,10 @@ --- + + + + + + title: 스테이트풀셋(StatefulSet) 삭제하기 content_type: task weight: 60 @@ -37,14 +43,14 @@ kubectl delete statefulsets kubectl delete service ``` -kubectl을 통해 스테이트풀셋을 삭제하면 0으로 스케일이 낮아지고, 스테이트풀셋에 포함된 모든 파드가 삭제된다. -파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=false` 를 사용한다. +kubectl을 통해 스테이트풀셋을 삭제하면, 스테이트풀셋의 크기가 0으로 설정되고 이로 인해 스테이트풀셋에 포함된 모든 파드가 삭제된다. 파드가 아닌 스테이트풀셋만 삭제하려면, `--cascade=orphan` 옵션을 사용한다. +예시는 다음과 같다. ```shell -kubectl delete -f --cascade=false +kubectl delete -f --cascade=orphan ``` -`kubectl delete` 에 `--cascade=false` 를 사용하면 스테이트풀셋 오브젝트가 삭제된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다. +`kubectl delete` 에 `--cascade=orphan` 를 사용하면 스테이트풀셋 오브젝트가 삭제된 후에도 스테이트풀셋에 의해 관리된 파드는 남게 된다. 만약 파드가 `app=myapp` 레이블을 갖고 있다면, 다음과 같이 파드를 삭제할 수 있다. ```shell kubectl delete pods -l app=myapp diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index b4ca1826d6..61f1dbc758 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -381,7 +381,7 @@ object: 외부 메트릭 사용시, 먼저 모니터링 시스템에 대한 이해가 있어야 한다. 이 설치는 사용자 정의 메트릭과 유사하다. 외부 메트릭을 사용하면 모니터링 시스템의 사용 가능한 메트릭에 기반하여 클러스터를 오토스케일링 할 수 있다. -위의 예제처럼 `name`과 `selector`를 갖는 `metric` 블록을 제공하고, +위의 예제처럼 `name`과 `selector`를 갖는 `metric` 블록을 명시하고, `Object` 대신에 `External` 메트릭 타입을 사용한다. 만일 여러 개의 시계열이 `metricSelector`와 일치하면, HorizontalPodAutoscaler가 값의 합을 사용한다. 외부 메트릭들은 `Value`와 `AverageValue` 대상 타입을 모두 지원하고, diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md index f762357603..90d151e768 100644 --- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -23,9 +23,7 @@ Pod Autoscaler는 크기를 조정할 수 없는 오브젝트(예: 데몬셋(Dae Horizontal Pod Autoscaler는 쿠버네티스 API 리소스 및 컨트롤러로 구현된다. 리소스는 컨트롤러의 동작을 결정한다. -컨트롤러는 관찰된 평균 CPU 사용률이 사용자가 지정한 대상과 일치하도록 레플리케이션 -컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다. - +컨트롤러는 평균 CPU 사용률, 평균 메모리 사용률 또는 다른 커스텀 메트릭과 같은 관찰 대상 메트릭이 사용자가 지정한 목표값과 일치하도록 레플리케이션 컨트롤러 또는 디플로이먼트에서 레플리카 개수를 주기적으로 조정한다. @@ -79,7 +77,7 @@ HorizontalPodAutoscaler는 보통 일련의 API 집합(`metrics.k8s.io`, 힙스터에서 메트릭 가져오기는 Kubernetes 1.11에서 사용 중단(deprecated)됨. {{< /note >}} -자세한 사항은 [메트릭 API를 위한 지원](#메트릭-API를-위한-지원)을 참조한다. +자세한 사항은 [메트릭 API를 위한 지원](#메트릭-api를-위한-지원)을 참조한다. 오토스케일러는 스케일 하위 리소스를 사용하여 상응하는 확장 가능 컨트롤러(예: 레플리케이션 컨트롤러, 디플로이먼트, 레플리케이션 셋)에 접근한다. 스케일은 레플리카의 개수를 동적으로 설정하고 각 현재 상태를 검사 할 수 있게 해주는 인터페이스이다. @@ -355,7 +353,7 @@ API에 접속하려면 클러스터 관리자는 다음을 확인해야 한다. ## 구성가능한 스케일링 동작 지원 -[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md) +[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md) 부터 `v2beta2` API는 HPA `behavior` 필드를 통해 스케일링 동작을 구성할 수 있다. 동작은 `behavior` 필드 아래의 `scaleUp` 또는 `scaleDown` diff --git a/content/ko/docs/tasks/tls/certificate-rotation.md b/content/ko/docs/tasks/tls/certificate-rotation.md index 037f99d87a..eadec87b4f 100644 --- a/content/ko/docs/tasks/tls/certificate-rotation.md +++ b/content/ko/docs/tasks/tls/certificate-rotation.md @@ -27,10 +27,10 @@ kubelet은 쿠버네티스 API 인증을 위해 인증서를 사용한다. 기본적으로 이러한 인증서는 1년 만기로 발급되므로 너무 자주 갱신할 필요는 없다. -쿠버네티스 1.8은 [kubelet 인증서 +쿠버네티스는 [kubelet 인증서 갱신](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)을 포함하며, 이 기능은 현재 인증서의 만료 시한이 임박한 경우, -새로운 키를 자동으로 생성하고 쿠버네티스 API에서 새로운 인증서를 요청하는 베타 기능이다. +새로운 키를 자동으로 생성하고 쿠버네티스 API에서 새로운 인증서를 요청하는 기능이다. 새로운 인증서를 사용할 수 있게 되면 쿠버네티스 API에 대한 연결을 인증하는데 사용된다. diff --git a/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md b/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md index f814db9919..d6f29e780d 100644 --- a/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md +++ b/content/ko/docs/tasks/tls/managing-tls-in-a-cluster.md @@ -88,7 +88,7 @@ EOF 여기서 `192.0.2.24`는 서비스의 클러스터 IP, `my-svc.my-namespace.svc.cluster.local`은 서비스의 DNS 이름, -`10.0.34.2`는 파드의 IP,`my-pod.my- namespace.pod.cluster.local`은 +`10.0.34.2`는 파드의 IP,`my-pod.my-namespace.pod.cluster.local`은 파드의 DNS 이름이다. 다음 출력이 표시되어야 한다. ``` diff --git a/content/ko/docs/tasks/tools/_index.md b/content/ko/docs/tasks/tools/_index.md old mode 100755 new mode 100644 index 8c2b3e1aed..990a9fd99b --- a/content/ko/docs/tasks/tools/_index.md +++ b/content/ko/docs/tasks/tools/_index.md @@ -17,9 +17,9 @@ no_list: true `kubectl` 은 다양한 리눅스 플랫폼, macOS, 그리고 윈도우에 설치할 수 있다. 각각에 대한 설치 가이드는 다음과 같다. -- [리눅스에 `kubectl` 설치하기](install-kubectl-linux) -- [macOS에 `kubectl` 설치하기](install-kubectl-macos) -- [윈도우에 `kubectl` 설치하기](install-kubectl-windows) +- [리눅스에 `kubectl` 설치하기](/ko/docs/tasks/tools/install-kubectl-linux/) +- [macOS에 `kubectl` 설치하기](/ko/docs/tasks/tools/install-kubectl-macos/) +- [윈도우에 `kubectl` 설치하기](/ko/docs/tasks/tools/install-kubectl-windows/) ## kind diff --git a/content/ko/docs/tasks/tools/included/install-kubectl-gcloud.md b/content/ko/docs/tasks/tools/included/install-kubectl-gcloud.md deleted file mode 100644 index f3deae981c..0000000000 --- a/content/ko/docs/tasks/tools/included/install-kubectl-gcloud.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "gcloud kubectl install" -description: "gcloud를 이용하여 kubectl을 설치하는 방법을 각 OS별 탭에 포함하기 위한 스니펫." -headless: true ---- - -Google Cloud SDK를 사용하여 kubectl을 설치할 수 있다. - -1. [Google Cloud SDK](https://cloud.google.com/sdk/)를 설치한다. - -1. `kubectl` 설치 명령을 실행한다. - - ```shell - gcloud components install kubectl - ``` - -1. 설치한 버전이 최신 버전인지 확인한다. - - ```shell - kubectl version --client - ``` \ No newline at end of file diff --git a/content/ko/docs/tasks/tools/included/kubectl-convert-overview.md b/content/ko/docs/tasks/tools/included/kubectl-convert-overview.md new file mode 100644 index 0000000000..cec8b3f55b --- /dev/null +++ b/content/ko/docs/tasks/tools/included/kubectl-convert-overview.md @@ -0,0 +1,11 @@ +--- +title: "kubectl-convert 개요" +description: >- + 특정 버전의 쿠버네티스 API로 작성된 매니페스트를 다른 버전으로 변환하는 + kubectl 플러그인. +headless: true +--- + +이것은 쿠버네티스 커맨드 라인 도구인 `kubectl`의 플러그인으로서, 특정 버전의 쿠버네티스 API로 작성된 매니페스트를 다른 버전으로 +변환할 수 있도록 한다. 이것은 매니페스트를 최신 쿠버네티스 릴리스의 사용 중단되지 않은 API로 마이그레이션하는 데 특히 유용하다. +더 많은 정보는 다음의 [사용 중단되지 않은 API로 마이그레이션](/docs/reference/using-api/deprecation-guide/#migrate-to-non-deprecated-apis)을 참고한다. diff --git a/content/ko/docs/tasks/tools/install-kubectl-linux.md b/content/ko/docs/tasks/tools/install-kubectl-linux.md index 96ab0a4024..77717372d1 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-linux.md +++ b/content/ko/docs/tasks/tools/install-kubectl-linux.md @@ -12,24 +12,16 @@ card: ## {{% heading "prerequisites" %}} -클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. -예를 들어, v1.2 클라이언트는 v1.1, v1.2 및 v1.3의 마스터와 함께 작동해야 한다. +클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew latestVersion >}} 클라이언트는 v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, v{{< skew nextMinorVersion >}}의 컨트롤 플레인과 연동될 수 있다. 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다. ## 리눅스에 kubectl 설치 다음과 같은 방법으로 리눅스에 kubectl을 설치할 수 있다. -- [{{% heading "prerequisites" %}}](#시작하기-전에) -- [리눅스에 kubectl 설치](#리눅스에-kubectl-설치) - - [리눅스에서 curl을 사용하여 kubectl 바이너리 설치]{#install-kubectl-binary-with-curl-on-linux} - - [기본 패키지 관리 도구를 사용하여 설치]{#install-using-native-package-management} - - [다른 패키지 관리 도구를 사용하여 설치]{#install-using-other-package-management} - - [Google Cloud SDK를 사용하여 설치]{#install-on-linux-as-part-of-the-google-cloud-sdk} -- [kubectl 구성 확인](#kubectl-구성-확인) -- [선택적 kubectl 구성](#선택적-kubectl-구성) - - [셸 자동 완성 활성화](#셸-자동-완성-활성화) -- [{{% heading "whatsnext" %}}](#다음-내용) +- [리눅스에 curl을 사용하여 kubectl 바이너리 설치](#install-kubectl-binary-with-curl-on-linux) +- [기본 패키지 관리 도구를 사용하여 설치](#install-using-native-package-management) +- [다른 패키지 관리 도구를 사용하여 설치](#install-using-other-package-management) ### 리눅스에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-linux} @@ -90,6 +82,7 @@ card: 대상 시스템에 root 접근 권한을 가지고 있지 않더라도, `~/.local/bin` 디렉터리에 kubectl을 설치할 수 있다. ```bash + chmod +x kubectl mkdir -p ~/.local/bin/kubectl mv ./kubectl ~/.local/bin/kubectl # 그리고 ~/.local/bin/kubectl을 $PATH에 추가 @@ -158,7 +151,6 @@ yum install -y kubectl ```shell snap install kubectl --classic - kubectl version --client ``` @@ -169,7 +161,6 @@ kubectl version --client ```shell brew install kubectl - kubectl version --client ``` @@ -177,15 +168,11 @@ kubectl version --client {{< /tabs >}} -### Google Cloud SDK를 사용하여 설치 {#install-on-linux-as-part-of-the-google-cloud-sdk} - -{{< include "included/install-kubectl-gcloud.md" >}} - ## kubectl 구성 확인 {{< include "included/verify-kubectl.md" >}} -## 선택적 kubectl 구성 +## 선택적 kubectl 구성 및 플러그인 ### 셸 자동 완성 활성화 @@ -198,6 +185,61 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력 {{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}} {{< /tabs >}} +### `kubectl convert` 플러그인 설치 + +{{< include "included/kubectl-convert-overview.md" >}} + +1. 다음 명령으로 최신 릴리스를 다운로드한다. + + ```bash + curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert + ``` + +1. 바이너리를 검증한다. (선택 사항) + + kubectl-convert 체크섬(checksum) 파일을 다운로드한다. + + ```bash + curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256" + ``` + + kubectl-convert 바이너리를 체크섬 파일을 통해 검증한다. + + ```bash + echo "$(}} + 동일한 버전의 바이너리와 체크섬을 다운로드한다. + {{< /note >}} + +1. kubectl-convert 설치 + + ```bash + sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert + ``` + +1. 플러그인이 정상적으로 설치되었는지 확인한다. + + ```shell + kubectl convert --help + ``` + + 에러가 출력되지 않는다면, 플러그인이 정상적으로 설치된 것이다. + ## {{% heading "whatsnext" %}} {{< include "included/kubectl-whats-next.md" >}} diff --git a/content/ko/docs/tasks/tools/install-kubectl-macos.md b/content/ko/docs/tasks/tools/install-kubectl-macos.md index 1fd37151a6..90fefb0c3a 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-macos.md +++ b/content/ko/docs/tasks/tools/install-kubectl-macos.md @@ -12,8 +12,7 @@ card: ## {{% heading "prerequisites" %}} -클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. -예를 들어, v1.2 클라이언트는 v1.1, v1.2 및 v1.3의 마스터와 함께 작동해야 한다. +클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew latestVersion >}} 클라이언트는 v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, v{{< skew nextMinorVersion >}}의 컨트롤 플레인과 연동될 수 있다. 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다. ## macOS에 kubectl 설치 @@ -23,23 +22,33 @@ card: - [macOS에서 curl을 사용하여 kubectl 바이너리 설치](#install-kubectl-binary-with-curl-on-macos) - [macOS에서 Homebrew를 사용하여 설치](#install-with-homebrew-on-macos) - [macOS에서 Macports를 사용하여 설치](#install-with-macports-on-macos) -- [macOS에서 Google Cloud SDK를 사용하여 설치](#install-on-macos-as-part-of-the-google-cloud-sdk) ### macOS에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-macos} 1. 최신 릴리스를 다운로드한다. - ```bash + {{< tabs name="download_binary_macos" >}} + {{< tab name="Intel" codelang="bash" >}} curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl" - ``` + {{< /tab >}} + {{< tab name="Apple Silicon" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl" + {{< /tab >}} + {{< /tabs >}} {{< note >}} 특정 버전을 다운로드하려면, `$(curl -L -s https://dl.k8s.io/release/stable.txt)` 명령 부분을 특정 버전으로 바꾼다. - 예를 들어, macOS에서 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다. + 예를 들어, Intel macOS에 버전 {{< param "fullversion" >}}을 다운로드하려면, 다음을 입력한다. ```bash - curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl + curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl" + ``` + + Apple Silicon의 macOS라면, 다음을 입력한다. + + ```bash + curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/darwin/arm64/kubectl" ``` {{< /note >}} @@ -48,9 +57,14 @@ card: kubectl 체크섬 파일을 다운로드한다. - ```bash - curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256" - ``` + {{< tabs name="download_checksum_macos" >}} + {{< tab name="Intel" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl.sha256" + {{< /tab >}} + {{< tab name="Apple Silicon" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl.sha256" + {{< /tab >}} + {{< /tabs >}} kubectl 바이너리를 체크섬 파일을 통해 검증한다. @@ -84,10 +98,14 @@ card: 1. kubectl 바이너리를 시스템 `PATH` 의 파일 위치로 옮긴다. ```bash - sudo mv ./kubectl /usr/local/bin/kubectl && \ + sudo mv ./kubectl /usr/local/bin/kubectl sudo chown root: /usr/local/bin/kubectl ``` + {{< note >}} + `PATH` 환경 변수 안에 `/usr/local/bin` 이 있는지 확인한다. + {{< /note >}} + 1. 설치한 버전이 최신 버전인지 확인한다. ```bash @@ -133,16 +151,11 @@ macOS에서 [Macports](https://macports.org/) 패키지 관리자를 사용하 kubectl version --client ``` - -### Google Cloud SDK를 사용하여 설치 {#install-on-macos-as-part-of-the-google-cloud-sdk} - -{{< include "included/install-kubectl-gcloud.md" >}} - ## kubectl 구성 확인 {{< include "included/verify-kubectl.md" >}} -## 선택적 kubectl 구성 +## 선택적 kubectl 구성 및 플러그인 ### 셸 자동 완성 활성화 @@ -155,6 +168,82 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력 {{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}} {{< /tabs >}} +### `kubectl convert` 플러그인 설치 + +{{< include "included/kubectl-convert-overview.md" >}} + +1. 다음 명령으로 최신 릴리스를 다운로드한다. + + {{< tabs name="download_convert_binary_macos" >}} + {{< tab name="Intel" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert" + {{< /tab >}} + {{< tab name="Apple Silicon" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert" + {{< /tab >}} + {{< /tabs >}} + +1. 바이너리를 검증한다. (선택 사항) + + kubectl-convert 체크섬(checksum) 파일을 다운로드한다. + + {{< tabs name="download_convert_checksum_macos" >}} + {{< tab name="Intel" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert.sha256" + {{< /tab >}} + {{< tab name="Apple Silicon" codelang="bash" >}} + curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert.sha256" + {{< /tab >}} + {{< /tabs >}} + + kubectl-convert 바이너리를 체크섬 파일을 통해 검증한다. + + ```bash + echo "$(}} + 동일한 버전의 바이너리와 체크섬을 다운로드한다. + {{< /note >}} + +1. kubectl-convert 바이너리를 실행 가능하게 한다. + + ```bash + chmod +x ./kubectl-convert + ``` + +1. kubectl-convert 바이너리를 시스템 `PATH` 의 파일 위치로 옮긴다. + + ```bash + sudo mv ./kubectl /usr/local/bin/kubectl-convert + sudo chown root: /usr/local/bin/kubectl-convert + ``` + + {{< note >}} + `PATH` 환경 변수 안에 `/usr/local/bin` 이 있는지 확인한다. + {{< /note >}} + +1. 플러그인이 정상적으로 설치되었는지 확인한다. + + ```shell + kubectl convert --help + ``` + + 에러가 출력되지 않는다면, 플러그인이 정상적으로 설치된 것이다. + ## {{% heading "whatsnext" %}} {{< include "included/kubectl-whats-next.md" >}} diff --git a/content/ko/docs/tasks/tools/install-kubectl-windows.md b/content/ko/docs/tasks/tools/install-kubectl-windows.md index e1c67af9ce..ab5e7ca05d 100644 --- a/content/ko/docs/tasks/tools/install-kubectl-windows.md +++ b/content/ko/docs/tasks/tools/install-kubectl-windows.md @@ -12,8 +12,7 @@ card: ## {{% heading "prerequisites" %}} -클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. -예를 들어, v1.2 클라이언트는 v1.1, v1.2 및 v1.3의 마스터와 함께 작동해야 한다. +클러스터의 마이너(minor) 버전 차이 내에 있는 kubectl 버전을 사용해야 한다. 예를 들어, v{{< skew latestVersion >}} 클라이언트는 v{{< skew prevMinorVersion >}}, v{{< skew latestVersion >}}, v{{< skew nextMinorVersion >}}의 컨트롤 플레인과 연동될 수 있다. 최신 버전의 kubectl을 사용하면 예기치 않은 문제를 피할 수 있다. ## 윈도우에 kubectl 설치 @@ -21,9 +20,7 @@ card: 다음과 같은 방법으로 윈도우에 kubectl을 설치할 수 있다. - [윈도우에서 curl을 사용하여 kubectl 바이너리 설치](#install-kubectl-binary-with-curl-on-windows) -- [PSGallery에서 PowerShell로 설치](#install-with-powershell-from-psgallery) - [Chocolatey 또는 Scoop을 사용하여 윈도우에 설치](#install-on-windows-using-chocolatey-or-scoop) -- [Google Cloud SDK를 사용하여 설치](#install-on-windows-as-part-of-the-google-cloud-sdk) ### 윈도우에서 curl을 사용하여 kubectl 바이너리 설치 {#install-kubectl-binary-with-curl-on-windows} @@ -33,7 +30,7 @@ card: 또는 `curl` 을 설치한 경우, 다음 명령을 사용한다. ```powershell - curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe + curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe" ``` {{< note >}} @@ -45,7 +42,7 @@ card: kubectl 체크섬 파일을 다운로드한다. ```powershell - curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256 + curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256" ``` kubectl 바이너리를 체크섬 파일을 통해 검증한다. @@ -76,33 +73,6 @@ card: 도커 데스크톱을 이전에 설치한 경우, 도커 데스크톱 설치 프로그램에서 추가한 `PATH` 항목 앞에 `PATH` 항목을 배치하거나 도커 데스크톱의 `kubectl` 을 제거해야 할 수도 있다. {{< /note >}} -### PSGallery에서 PowerShell로 설치 {#install-with-powershell-from-psgallery} - -윈도우에서 [Powershell Gallery](https://www.powershellgallery.com/) 패키지 관리자를 사용하는 경우, Powershell로 kubectl을 설치하고 업데이트할 수 있다. - -1. 설치 명령을 실행한다(`DownloadLocation` 을 지정해야 한다). - - ```powershell - Install-Script -Name install-kubectl -Scope CurrentUser -Force - install-kubectl.ps1 [-DownloadLocation ] - ``` - - {{< note >}} - `DownloadLocation` 을 지정하지 않으면, `kubectl` 은 사용자의 `temp` 디렉터리에 설치된다. - {{< /note >}} - - 설치 프로그램은 `$HOME/.kube` 를 생성하고 구성 파일을 작성하도록 지시한다. - -1. 설치한 버전이 최신 버전인지 확인한다. - - ```powershell - kubectl version --client - ``` - -{{< note >}} -설치 업데이트는 1 단계에서 나열한 두 명령을 다시 실행하여 수행한다. -{{< /note >}} - ### Chocolatey 또는 Scoop을 사용하여 윈도우에 설치 {#install-on-windows-using-chocolatey-or-scoop} 1. 윈도우에 kubectl을 설치하기 위해서 [Chocolatey](https://chocolatey.org) 패키지 관리자나 [Scoop](https://scoop.sh) 커맨드 라인 설치 프로그램을 사용할 수 있다. @@ -156,15 +126,11 @@ card: 메모장과 같은 텍스트 편집기를 선택하여 구성 파일을 편집한다. {{< /note >}} -### Google Cloud SDK를 사용하여 설치 {#install-on-windows-as-part-of-the-google-cloud-sdk} - -{{< include "included/install-kubectl-gcloud.md" >}} - ## kubectl 구성 확인 {{< include "included/verify-kubectl.md" >}} -## 선택적 kubectl 구성 +## 선택적 kubectl 구성 및 플러그인 ### 셸 자동 완성 활성화 @@ -174,6 +140,49 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력 {{< include "included/optional-kubectl-configs-zsh.md" >}} +### `kubectl convert` 플러그인 설치 + +{{< include "included/kubectl-convert-overview.md" >}} + +1. 다음 명령으로 최신 릴리스를 다운로드한다. + + ```powershell + curl -LO "https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe" + ``` + +1. 바이너리를 검증한다. (선택 사항) + + kubectl-convert 체크섬(checksum) 파일을 다운로드한다. + + ```powershell + curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe.sha256" + ``` + + kubectl-convert 바이너리를 체크섬 파일을 통해 검증한다. + + - 수동으로 `CertUtil` 의 출력과 다운로드한 체크섬 파일을 비교하기 위해서 커맨드 프롬프트를 사용한다. + + ```cmd + CertUtil -hashfile kubectl-convert.exe SHA256 + type kubectl-convert.exe.sha256 + ``` + + - `-eq` 연산자를 통해 `True` 또는 `False` 결과를 얻는 자동 검증을 위해서 PowerShell을 사용한다. + + ```powershell + $($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256) + ``` + +1. 바이너리를 `PATH` 가 설정된 디렉터리에 추가한다. + +1. 플러그인이 정상적으로 설치되었는지 확인한다. + + ```shell + kubectl convert --help + ``` + + 에러가 출력되지 않는다면, 플러그인이 정상적으로 설치된 것이다. + ## {{% heading "whatsnext" %}} -{{< include "included/kubectl-whats-next.md" >}} \ No newline at end of file +{{< include "included/kubectl-whats-next.md" >}} diff --git a/content/ko/docs/tutorials/_index.md b/content/ko/docs/tutorials/_index.md index 7c1216c5fd..093208f22d 100644 --- a/content/ko/docs/tutorials/_index.md +++ b/content/ko/docs/tutorials/_index.md @@ -27,13 +27,15 @@ content_type: concept ## 구성 +* [예제: Java 마이크로서비스 구성하기](/ko/docs/tutorials/configuration/configure-java-microservice/) + * [컨피그 맵을 사용해서 Redis 설정하기](/ko/docs/tutorials/configuration/configure-redis-using-configmap/) ## 상태 유지를 하지 않는(stateless) 애플리케이션 * [외부 IP 주소를 노출하여 클러스터의 애플리케이션에 접속하기](/ko/docs/tutorials/stateless-application/expose-external-ip-address/) -* [예시: MongoDB를 사용한 PHP 방명록 애플리케이션 배포하기](/ko/docs/tutorials/stateless-application/guestbook/) +* [예시: Redis를 사용한 PHP 방명록 애플리케이션 배포하기](/ko/docs/tutorials/stateless-application/guestbook/) ## 상태 유지가 필요한(stateful) 애플리케이션 diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md index ae3fce6cb8..43b07e293b 100644 --- a/content/ko/docs/tutorials/clusters/apparmor.md +++ b/content/ko/docs/tutorials/clusters/apparmor.md @@ -322,7 +322,7 @@ Events: 23s 23s 1 {kubelet e2e-test-stclair-node-pool-t1f5} Warning AppArmor Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded ``` -파드 상태는 Failed이며 오류메시지는 `Pod Cannot enforce AppArmor: profile +파드 상태는 Pending이며, 오류 메시지는 `Pod Cannot enforce AppArmor: profile "k8s-apparmor-example-allow-write" is not loaded`이다. 이벤트도 동일한 메시지로 기록되었다. ## 관리 {#administration} diff --git a/content/ko/docs/tutorials/configuration/_index.md b/content/ko/docs/tutorials/configuration/_index.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md index c1b21d1404..fb1ac922fc 100644 --- a/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/ko/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -55,7 +55,7 @@ EOF ```shell kubectl apply -f example-redis-config.yaml -kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml ``` Redis 파드 매니페스트의 내용을 검토하고 다음의 사항을 염두에 둔다. @@ -206,7 +206,7 @@ kubectl exec -it redis -- redis-cli ```shell kubectl delete pod redis -kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/master/content/en/examples/pods/config/redis-pod.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/config/redis-pod.yaml ``` 이제 마지막으로 설정값을 다시 확인해 본다. diff --git a/content/ko/docs/tutorials/hello-minikube.md b/content/ko/docs/tutorials/hello-minikube.md index 39e57ff501..091a1c684f 100644 --- a/content/ko/docs/tutorials/hello-minikube.md +++ b/content/ko/docs/tutorials/hello-minikube.md @@ -41,14 +41,14 @@ Katacode는 무료로 브라우저에서 쿠버네티스 환경을 제공한다. -## minikubue 클러스터 만들기 +## minikube 클러스터 만들기 1. **Launch Terminal** 을 클릭 {{< kat-button >}} {{< note >}} - minikube를 로컬에 설치했다면 `minikube start`를 실행한다. + minikube를 로컬에 설치했다면 `minikube start`를 실행한다. `minikube dashboard` 명령을 실행하기 전에, 새 터미널을 열고, 그 터미널에서 `minikube dashboard` 명령을 실행한 후, 원래의 터미널로 돌아온다. {{< /note >}} 2. 브라우저에서 쿠버네티스 대시보드를 열어보자. @@ -154,7 +154,7 @@ minikube dashboard --url `k8s.gcr.io/echoserver` 이미지 내의 애플리케이션 코드는 TCP 포트 8080에서만 수신한다. `kubectl expose`를 사용하여 다른 포트를 노출한 경우, 클라이언트는 다른 포트에 연결할 수 없다. -2. 방금 생성한 서비스 살펴보기 +2. 생성한 서비스 살펴보기 ```shell kubectl get services @@ -217,7 +217,7 @@ minikube 툴은 활성화하거나 비활성화할 수 있고 로컬 쿠버네 storage-provisioner-gluster: disabled ``` -2. 한 애드온을 활성화 한다. 예를 들어 `metrics-server` +2. 애드온을 활성화 한다. 여기서는 `metrics-server`를 예시로 사용한다. ```shell minikube addons enable metrics-server @@ -226,10 +226,10 @@ minikube 툴은 활성화하거나 비활성화할 수 있고 로컬 쿠버네 다음과 유사하게 출력된다. ``` - metrics-server was successfully enabled + The 'metrics-server' addon is enabled ``` -3. 방금 생성한 파드와 서비스를 확인한다. +3. 생성한 파드와 서비스를 확인한다. ```shell kubectl get pod,svc -n kube-system diff --git a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index d9d621d867..fcad9b42b3 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -25,8 +25,8 @@ weight: 20
    - - 모듈 2로 진행하기› + 홈으로 이동 + 모듈 2로 진행하기 >
    diff --git a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 2cf9daa6e1..ce5be2cfc0 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -37,8 +37,9 @@ weight: 20
    - - 모듈 3으로 진행하기› + < 모듈 1로 돌아가기 + 홈으로 이동 + 모듈 3으로 진행하기 >
    diff --git a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html index f82846a390..e3b67a1dae 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-interactive.html @@ -29,8 +29,9 @@ weight: 20
    - 모듈 4로 - 진행하기› + < 모듈 2로 돌아가기 + 홈으로 이동 + 모듈 4로 진행하기 >
    diff --git a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html index 2e34002571..e218222010 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/ko/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -74,11 +74,11 @@ weight: 10

    노드

    -

    파드는 언제나 노드 상에서 동작한다. 노드는 쿠버네티스에서 워커 머신을 말하며 클러스터에 따라 가상 또는 물리 머신일 수 있다. 각 노드는 마스터에 의해 관리된다. 하나의 노드는 여러 개의 파드를 가질 수 있고, 쿠버네티스 마스터는 클러스터 내 노드를 통해서 파드에 대한 스케쥴링을 자동으로 처리한다.

    +

    파드는 언제나 노드 상에서 동작한다. 노드는 쿠버네티스에서 워커 머신을 말하며 클러스터에 따라 가상 또는 물리 머신일 수 있다. 각 노드는 컨트롤 플레인에 의해 관리된다. 하나의 노드는 여러 개의 파드를 가질 수 있고, 쿠버네티스 컨트롤 플레인은 클러스터 내 노드를 통해서 파드에 대한 스케쥴링을 자동으로 처리한다. 컨트롤 플레인의 자동 스케줄링은 각 노드의 사용 가능한 리소스를 모두 고려합니다.

    모든 쿠버네티스 노드는 최소한 다음과 같이 동작한다.

      -
    • Kubelet은, 쿠버네티스 마스터와 노드 간 통신을 책임지는 프로세스이며, 하나의 머신 상에서 동작하는 파드와 컨테이너를 관리한다.
      • +
    • Kubelet은, 쿠버네티스 컨트롤 플레인과 노드 간 통신을 책임지는 프로세스이며, 하나의 머신 상에서 동작하는 파드와 컨테이너를 관리한다.
    • 컨테이너 런타임(도커와 같은)은 레지스트리에서 컨테이너 이미지를 가져와 묶여 있는 것을 풀고 애플리케이션을 동작시키는 책임을 맡는다.
    diff --git a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html index bfbb0eb1c8..09dde78cb8 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/expose/expose-interactive.html @@ -26,7 +26,9 @@ weight: 20
    - 모듈 5로 진행하기› + < 모듈 3으로 돌아가기 + 홈으로 이동 + 모듈 5로 진행하기 >
    diff --git a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html index 31c1d859a2..22b5d41342 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/scale/scale-interactive.html @@ -26,8 +26,9 @@ weight: 20
    - - 모듈 6으로 진행하기› + < 모듈 4로 돌아가기 + 홈으로 이동 + 모듈 6으로 진행하기 >
    diff --git a/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html index 24da082b89..4038e3b358 100644 --- a/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html +++ b/content/ko/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -26,7 +26,8 @@ weight: 20
    - 쿠버네티스 기초로 돌아가기› + < 모듈 5로 돌아가기 + 쿠버네티스 기초로 돌아가기
    diff --git a/content/ko/docs/tutorials/services/source-ip.md b/content/ko/docs/tutorials/services/source-ip.md index 6874d6669b..7300b06615 100644 --- a/content/ko/docs/tutorials/services/source-ip.md +++ b/content/ko/docs/tutorials/services/source-ip.md @@ -6,10 +6,10 @@ min-kubernetes-server-version: v1.5 -쿠버네티스 클러스터에서 실행 중인 애플리케이션은 서로 간에 외부 세계와 -서비스 추상화를 통해 찾고 통신한다. 이 문서는 -다른 종류의 서비스로 보내진 패킷의 소스 IP 주소에 어떤 일이 벌어지는지와 -이 동작을 요구에 따라 토글할 수 있는지 설명한다. +쿠버네티스 클러스터에서 실행 중인 애플리케이션은 서비스 추상화를 통해서 +서로를, 그리고 외부 세계를 찾고 통신한다. 이 문서는 +다른 종류의 서비스로 전송된 패킷의 소스 IP에 어떤 일이 벌어지는지와 +이 동작을 필요에 따라 어떻게 전환할 수 있는지 설명한다. @@ -29,16 +29,16 @@ min-kubernetes-server-version: v1.5 : 네트워크 주소 변환 [소스 NAT](https://en.wikipedia.org/wiki/Network_address_translation#SNAT) -: 패킷 상의 소스 IP 주소를 변경함, 보통 노드의 IP 주소 +: 패킷 상의 소스 IP 주소를 변경하는 것. 이 페이지에서는 일반적으로 노드 IP 주소로의 변경을 의미함. [대상 NAT](https://en.wikipedia.org/wiki/Network_address_translation#DNAT) -: 패킷 상의 대상 IP 주소를 변경함, 보통 파드의 IP 주소 +: 패킷 상의 대상 IP 주소를 변경하는 것. 이 페이지에서는 일반적으로 {{< glossary_tooltip term_id="pod" text="파드" >}} IP 주소로의 변경을 의미함. [VIP](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시) -: 가상 IP 주소, 모든 쿠버네티스 서비스에 할당된 것 같은 +: 쿠버네티스의 모든 {{< glossary_tooltip text="서비스" term_id="service" >}}에 할당되어 있는 것과 같은, 가상 IP 주소. [Kube-proxy](/ko/docs/concepts/services-networking/service/#가상-ip와-서비스-프록시) -: 네트워크 데몬으로 모든 노드에서 서비스 VIP 관리를 관리한다. +: 모든 노드에서 서비스 VIP 관리를 조율하는 네트워크 데몬. ### 전제 조건 @@ -80,7 +80,7 @@ deployment.apps/source-ip-app created ```console kubectl get nodes ``` -출력은 다음과 유사하다 +출력은 다음과 유사하다. ``` NAME STATUS ROLES AGE VERSION kubernetes-node-6jst Ready 2h v1.13.0 @@ -220,7 +220,6 @@ graph LR; class client plain; {{}} - 이를 피하기 위해 쿠버네티스는 [클라이언트 소스 IP 주소를 보존](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)하는 기능이 있다. `service.spec.externalTrafficPolicy` 의 값을 `Local` 로 하면 @@ -439,5 +438,5 @@ kubectl delete deployment source-ip-app ## {{% heading "whatsnext" %}} -* [서비스를 통한 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)에 더 자세히 본다. -* 어떻게 [외부 로드밸런서 생성](/docs/tasks/access-application-cluster/create-external-load-balancer/)하는지 본다. +* [서비스를 통한 애플리케이션 연결하기](/ko/docs/concepts/services-networking/connect-applications-service/)를 더 자세히 본다. +* [외부 로드밸런서 생성](/docs/tasks/access-application-cluster/create-external-load-balancer/) 방법을 본다. diff --git a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md index a17ae9f320..ee7cccb70d 100644 --- a/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md +++ b/content/ko/docs/tutorials/stateful-application/basic-stateful-set.md @@ -16,7 +16,7 @@ weight: 10 튜토리얼을 시작하기 전에 다음의 쿠버네티스 컨셉에 대해 익숙해야 한다. -* [파드](/docs/user-guide/pods/single-container/) +* [파드](/ko/docs/concepts/workloads/pods/) * [클러스터 DNS(Cluster DNS)](/ko/docs/concepts/services-networking/dns-pod-service/) * [헤드리스 서비스(Headless Services)](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스) * [퍼시스턴트볼륨(PersistentVolumes)](/ko/docs/concepts/storage/persistent-volumes/) @@ -434,7 +434,7 @@ web-4 0/1 ContainerCreating 0 0s web-4 1/1 Running 0 19s ``` -스테이트풀셋 컨트롤러는 레플리카개수를 스케일링한다. +스테이트풀셋 컨트롤러는 레플리카 개수를 스케일링한다. [스테이트풀셋 생성](#차례대로-파드-생성하기)으로 스테이트풀셋 컨트롤러는 각 파드을 순차적으로 각 순번에 따라 생성하고 후속 파드 시작 전에 이전 파드가 Running과 Ready 상태가 될 때까지 @@ -833,11 +833,11 @@ kubectl get pods -w -l app=nginx 다른 터미널에서는 스테이트풀셋을 지우기 위해 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands/#delete) 명령어를 이용하자. -이 명령어에 `--cascade=false` 파라미터가 추가되었다. +이 명령어에 `--cascade=orphan` 파라미터가 추가되었다. 이 파라미터는 쿠버네티스에 스테이트풀셋만 삭제하고 그에 속한 파드는 지우지 않도록 요청한다. ```shell -kubectl delete statefulset web --cascade=false +kubectl delete statefulset web --cascade=orphan ``` ``` statefulset.apps "web" deleted @@ -953,7 +953,7 @@ kubectl get pods -w -l app=nginx ``` 다른 터미널창에서 스테이트풀셋을 다시 지우자. 이번에는 -`--cascade=false` 파라미터를 생략하자. +`--cascade=orphan` 파라미터를 생략하자. ```shell kubectl delete statefulset web @@ -1067,9 +1067,10 @@ statefulset "web" deleted ### Parallel 파드 관리 `Parallel` 파드 관리는 스테이트풀셋 컨트롤러가 모든 파드를 -병렬로 시작하고 종료하는 것으로 다른 파드를 시작/종료하기 전에 +병렬로 시작하고 종료하는 것으로, 다른 파드를 시작/종료하기 전에 파드가 Running과 Ready 상태로 전환되거나 완전히 종료되기까지 기다리지 않음을 뜻한다. +이 옵션은 스케일링 동작에만 영향을 미치며, 업데이트 동작에는 영향을 미치지 않는다. {{< codenew file="application/web/web-parallel.yaml" >}} @@ -1114,7 +1115,7 @@ web-1 1/1 Running 0 10s 스테이트풀셋 컨트롤러는 `web-0`와 `web-1`를 둘 다 동시에 시작했다. 두 번째 터미널을 열어 놓고 다른 터미널창에서 스테이트풀셋을 -스케일링 하자. +스케일링하자. ```shell kubectl scale statefulset/web --replicas=4 diff --git a/content/ko/docs/tutorials/stateful-application/cassandra.md b/content/ko/docs/tutorials/stateful-application/cassandra.md index 7b1888a15e..3ebb7ec387 100644 --- a/content/ko/docs/tutorials/stateful-application/cassandra.md +++ b/content/ko/docs/tutorials/stateful-application/cassandra.md @@ -7,7 +7,7 @@ weight: 30 -이 튜토리얼은 쿠버네티스에서 [아파치 카산드라](http://cassandra.apache.org/)를 실행하는 방법을 소개한다. +이 튜토리얼은 쿠버네티스에서 [아파치 카산드라](https://cassandra.apache.org/)를 실행하는 방법을 소개한다. 데이터베이스인 카산드라는 데이터 내구성을 제공하기 위해 퍼시스턴트 스토리지가 필요하다(애플리케이션 _상태_). 이 예제에서 사용자 지정 카산드라 시드 공급자는 카산드라가 클러스터에 가입할 때 카산드라가 인스턴스를 검색할 수 있도록 한다. @@ -266,7 +266,7 @@ kubectl apply -f cassandra-statefulset.yaml 이 튜토리얼의 *파드* 는 구글의 [컨테이너 레지스트리](https://cloud.google.com/container-registry/docs/)에 [`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile) 이미지를 이용한다. -이 도커 이미지는 [debian-base](https://github.com/kubernetes/kubernetes/tree/master/build/debian-base)에 +이 도커 이미지는 [debian-base](https://github.com/kubernetes/release/tree/master/images/build/debian-base)에 기반하였고 OpenJDK 8을 포함한다. 이 이미지는 아파치 데비안 리포의 표준 카산드라 설치본을 포함한다. diff --git a/content/ko/docs/tutorials/stateless-application/_index.md b/content/ko/docs/tutorials/stateless-application/_index.md old mode 100755 new mode 100644 diff --git a/content/ko/docs/tutorials/stateless-application/guestbook.md b/content/ko/docs/tutorials/stateless-application/guestbook.md index 04230b4f3e..1a5e4a6079 100644 --- a/content/ko/docs/tutorials/stateless-application/guestbook.md +++ b/content/ko/docs/tutorials/stateless-application/guestbook.md @@ -1,5 +1,6 @@ --- -title: "예시: MongoDB를 사용한 PHP 방명록 애플리케이션 배포하기" +title: "예시: Redis를 사용한 PHP 방명록 애플리케이션 배포하기" + content_type: tutorial @@ -7,305 +8,411 @@ weight: 20 card: name: tutorials weight: 30 - title: "상태를 유지하지 않는 예제: MongoDB를 사용한 PHP 방명록" + title: "상태를 유지하지 않는 예제: Redis를 사용한 PHP 방명록" min-kubernetes-server-version: v1.14 +source: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook --- -이 튜토리얼에서는 쿠버네티스와 [Docker](https://www.docker.com/)를 사용하여 간단한 _(운영 준비가 아닌)_ 멀티 티어 웹 애플리케이션을 빌드하고 배포하는 방법을 보여준다. 이 예제는 다음과 같은 구성으로 이루어져 있다. +이 튜토리얼에서는 쿠버네티스와 [Docker](https://www.docker.com/)를 사용하여 간단한 +_(운영 수준이 아닌)_ 멀티 티어 웹 애플리케이션을 빌드하고 배포하는 방법을 보여준다. +이 예제는 다음과 같은 구성으로 +이루어져 있다. -* 방명록을 저장하는 단일 인스턴스 [MongoDB](https://www.mongodb.com/) +* 방명록 항목을 저장하기 위한 단일 인스턴스 [Redis](https://www.redis.com/) * 여러 개의 웹 프론트엔드 인스턴스 ## {{% heading "objectives" %}} -* Mongo 데이터베이스를 시작 -* 방명록 프론트엔드를 시작 +* Redis 리더를 실행 +* 2개의 Redis 팔로워를 실행 +* 방명록 프론트엔드를 실행 * 프론트엔드 서비스를 노출하고 확인 -* 정리 하기 - +* 정리하기 ## {{% heading "prerequisites" %}} - {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - - -## Mongo 데이터베이스를 실행 +## Redis 데이터베이스를 실행 -방명록 애플리케이션은 MongoDB를 사용해서 데이터를 저장한다. +방명록 애플리케이션은 Redis를 사용하여 데이터를 저장한다. -### Mongo 디플로이먼트를 생성하기 +### Redis 디플로이먼트를 생성하기 -아래의 매니페스트 파일은 단일 복제본 Mongo 파드를 실행하는 디플로이먼트 컨트롤러를 지정한다. +아래의 매니페스트 파일은 단일 복제본 Redis 파드를 실행하는 디플로이먼트 컨트롤러에 대한 명세를 담고 있다. -{{< codenew file="application/guestbook/mongo-deployment.yaml" >}} +{{< codenew file="application/guestbook/redis-leader-deployment.yaml" >}} 1. 매니페스트 파일을 다운로드한 디렉터리에서 터미널 창을 시작한다. -1. `mongo-deployment.yaml` 파일을 통해 MongoDB 디플로이먼트에 적용한다. +1. `redis-leader-deployment.yaml` 파일을 이용하여 Redis 디플로이먼트를 생성한다. - ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml - ``` - + -1. 파드의 목록을 질의하여 MongoDB 파드가 실행 중인지 확인한다. + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-leader-deployment.yaml + ``` - ```shell - kubectl get pods - ``` +1. 파드의 목록을 질의하여 Redis 파드가 실행 중인지 확인한다. - 결과는 아래와 같은 형태로 나타난다. + ```shell + kubectl get pods + ``` - ```shell - NAME READY STATUS RESTARTS AGE - mongo-5cfd459dd4-lrcjb 1/1 Running 0 28s - ``` + 결과는 아래와 같은 형태로 나타난다. -2. MongoDB 파드에서 로그를 보려면 다음 명령어를 실행한다. + ``` + NAME READY STATUS RESTARTS AGE + redis-leader-fb76b4755-xjr2n 1/1 Running 0 13s + ``` - ```shell - kubectl logs -f deployment/mongo - ``` +2. Redis 리더 파드의 로그를 보려면 다음 명령어를 실행한다. -### MongoDB 서비스 생성하기 + ```shell + kubectl logs -f deployment/redis-leader + ``` -방명록 애플리케이션에서 데이터를 쓰려면 MongoDB와 통신해야 한다. MongoDB 파드로 트래픽을 프록시하려면 [서비스](/ko/docs/concepts/services-networking/service/)를 적용해야 한다. 서비스는 파드에 접근하기 위한 정책을 정의한다. +### Redis 리더 서비스 생성하기 -{{< codenew file="application/guestbook/mongo-service.yaml" >}} +방명록 애플리케이션에서 데이터를 쓰려면 Redis와 통신해야 한다. +Redis 파드로 트래픽을 프록시하려면 [서비스](/ko/docs/concepts/services-networking/service/)를 생성해야 한다. +서비스는 파드에 접근하기 위한 정책을 +정의한다. -1. `mongo-service.yaml` 파일을 통해 MongoDB 서비스에 적용한다. +{{< codenew file="application/guestbook/redis-leader-service.yaml" >}} - ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml - ``` +1. `redis-leader-service.yaml` 파일을 이용하여 Redis 서비스를 실행한다. - + -1. 서비스의 목록을 질의하여 MongoDB 서비스가 실행 중인지 확인한다. + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-leader-service.yaml + ``` - ```shell - kubectl get service - ``` +1. 서비스의 목록을 질의하여 Redis 서비스가 실행 중인지 확인한다. - 결과는 아래와 같은 형태로 나타난다. + ```shell + kubectl get service + ``` - ```shell - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - kubernetes ClusterIP 10.0.0.1 443/TCP 1m - mongo ClusterIP 10.0.0.151 27017/TCP 8s - ``` + 결과는 아래와 같은 형태로 나타난다. + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + kubernetes ClusterIP 10.0.0.1 443/TCP 1m + redis-leader ClusterIP 10.103.78.24 6379/TCP 16s + ``` {{< note >}} -이 매니페스트 파일은 이전에 정의된 레이블과 일치하는 레이블 집합을 가진 `mongo`라는 서비스를 생성하므로, 서비스는 네트워크 트래픽을 MongoDB 파드로 라우팅한다. +이 매니페스트 파일은 이전에 정의된 레이블과 일치하는 레이블 집합을 가진 +`redis-leader`라는 서비스를 생성하므로, 서비스는 네트워크 트래픽을 +Redis 파드로 라우팅한다. {{< /note >}} +### Redis 팔로워 구성하기 + +Redis 리더는 단일 파드이지만, 몇 개의 Redis 팔로워 또는 복제본을 추가하여 +가용성을 높이고 트래픽 요구를 충족할 수 있다. + +{{< codenew file="application/guestbook/redis-follower-deployment.yaml" >}} + +1. `redis-follower-deployment.yaml` 파일을 이용하여 Redis 서비스를 실행한다. + + + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-follower-deployment.yaml + ``` + +1. 파드의 목록을 질의하여 2개의 Redis 팔로워 레플리카가 실행 중인지 확인한다. + + ```shell + kubectl get pods + ``` + + 결과는 아래와 같은 형태로 나타난다. + + ``` + NAME READY STATUS RESTARTS AGE + redis-follower-dddfbdcc9-82sfr 1/1 Running 0 37s + redis-follower-dddfbdcc9-qrt5k 1/1 Running 0 38s + redis-leader-fb76b4755-xjr2n 1/1 Running 0 11m + ``` + +### Redis 팔로워 서비스 생성하기 + +방명록 애플리케이션이 데이터를 읽으려면 Redis 팔로워와 통신해야 한다. +Redis 팔로워를 발견 가능(discoverable)하게 만드려면, 새로운 +[서비스](/ko/docs/concepts/services-networking/service/)를 구성해야 한다. + +{{< codenew file="application/guestbook/redis-follower-service.yaml" >}} + +1. `redis-follower-service.yaml` 파일을 이용하여 Redis 서비스를 실행한다. + + + + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/redis-follower-service.yaml + ``` + +1. 서비스의 목록을 질의하여 Redis 서비스가 실행 중인지 확인한다. + + ```shell + kubectl get service + ``` + + 결과는 아래와 같은 형태로 나타난다. + + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + kubernetes ClusterIP 10.96.0.1 443/TCP 3d19h + redis-follower ClusterIP 10.110.162.42 6379/TCP 9s + redis-leader ClusterIP 10.103.78.24 6379/TCP 6m10s + ``` + +{{< note >}} +이 매니페스트 파일은 이전에 정의된 레이블과 일치하는 레이블 집합을 가진 +`redis-follower`라는 서비스를 생성하므로, 서비스는 네트워크 트래픽을 +Redis 파드로 라우팅한다. +{{< /note >}} ## 방명록 프론트엔드를 설정하고 노출하기 -방명록 애플리케이션에는 PHP로 작성된 HTTP 요청을 처리하는 웹 프론트엔드가 있다. 방명록 항목들을 저장하기 위해 `mongo` 서비스에 연결하도록 구성 한다. +방명록을 위한 Redis 저장소를 구성하고 실행했으므로, 이제 방명록 웹 서버를 실행한다. +Redis 팔로워와 마찬가지로, 프론트엔드는 쿠버네티스 디플로이먼트(Deployment)를 +사용하여 배포된다. + +방명록 앱은 PHP 프론트엔드를 사용한다. DB에 대한 요청이 읽기인지 쓰기인지에 따라, +Redis 팔로워 또는 리더 서비스와 통신하도록 구성된다. 프론트엔드는 JSON 인터페이스를 +노출하고, +jQuery-Ajax 기반 UX를 제공한다. ### 방명록 프론트엔드의 디플로이먼트 생성하기 {{< codenew file="application/guestbook/frontend-deployment.yaml" >}} -1. `frontend-deployment.yaml` 파일을 통해 프론트엔드의 디플로이먼트에 적용한다. +1. `frontend-deployment.yaml` 파일을 이용하여 프론트엔드 디플로이먼트를 생성한다. - ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml - ``` + - + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-deployment.yaml + ``` 1. 파드의 목록을 질의하여 세 개의 프론트엔드 복제본이 실행되고 있는지 확인한다. - ```shell - kubectl get pods -l app.kubernetes.io/name=guestbook -l app.kubernetes.io/component=frontend - ``` + ```shell + kubectl get pods -l app=guestbook -l tier=frontend + ``` - 결과는 아래와 같은 형태로 나타난다. + 결과는 아래와 같은 형태로 나타난다. - ``` - NAME READY STATUS RESTARTS AGE - frontend-3823415956-dsvc5 1/1 Running 0 54s - frontend-3823415956-k22zn 1/1 Running 0 54s - frontend-3823415956-w9gbt 1/1 Running 0 54s - ``` + ``` + NAME READY STATUS RESTARTS AGE + frontend-85595f5bf9-5tqhb 1/1 Running 0 47s + frontend-85595f5bf9-qbzwm 1/1 Running 0 47s + frontend-85595f5bf9-zchwc 1/1 Running 0 47s + ``` ### 프론트엔드 서비스 생성하기 -서비스의 기본 유형은 [ClusterIP](/ko/docs/concepts/services-networking/service/#publishing-services-service-types)이기 때문에 적용한 `mongo` 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. `ClusterIP`는 서비스가 가리키는 파드 집합에 대한 단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다. +서비스의 기본 유형은 +[ClusterIP](/ko/docs/concepts/services-networking/service/#publishing-services-service-types) +이기 때문에 생성한 `Redis` 서비스는 컨테이너 클러스터 내에서만 접근할 수 있다. +`ClusterIP`는 서비스가 가리키는 파드 집합에 대한 +단일 IP 주소를 제공한다. 이 IP 주소는 클러스터 내에서만 접근할 수 있다. -게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 서비스를 구성해야 한다. 그렇게 하면 클라이언트가 쿠버네티스 클러스터 외부에서 서비스를 요청할 수 있다. 그러나 쿠버네티스 사용자는 `ClusterIP`를 사용하더라도 `kubectl port-forward`를 사용해서 서비스에 접근할 수 있다. +게스트가 방명록에 접근할 수 있도록 하려면, 외부에서 볼 수 있도록 프론트엔드 +서비스를 구성해야 한다. 그렇게 하면 클라이언트가 쿠버네티스 클러스터 외부에서 +서비스를 요청할 수 있다. 그러나 쿠버네티스 사용자는 `ClusterIP`를 +사용하더라도 `kubectl port-forward`를 사용해서 서비스에 +접근할 수 있다. {{< note >}} -Google Compute Engine 또는 Google Kubernetes Engine과 같은 일부 클라우드 공급자는 외부 로드 밸런서를 지원한다. 클라우드 공급자가 로드 밸런서를 지원하고 이를 사용하려면 `type : LoadBalancer`의 주석을 제거해야 한다. +Google Compute Engine 또는 Google Kubernetes Engine +과 같은 일부 클라우드 공급자는 외부 로드 밸런서를 지원한다. 클라우드 공급자가 로드 +밸런서를 지원하고 이를 사용하려면 `type : LoadBalancer`의 주석을 제거해야 한다. {{< /note >}} {{< codenew file="application/guestbook/frontend-service.yaml" >}} -1. `frontend-service.yaml` 파일을 통해 프론트엔드 서비스에 적용시킨다. +1. `frontend-service.yaml` 파일을 이용하여 프론트엔드 서비스를 실행한다. - ```shell - kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml - ``` + - + ```shell + kubectl apply -f https://k8s.io/examples/application/guestbook/frontend-service.yaml + ``` 1. 서비스의 목록을 질의하여 프론트엔드 서비스가 실행 중인지 확인한다. - ```shell - kubectl get services - ``` + ```shell + kubectl get services + ``` - 결과는 아래와 같은 형태로 나타난다. + 결과는 아래와 같은 형태로 나타난다. - ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - frontend ClusterIP 10.0.0.112 80/TCP 6s - kubernetes ClusterIP 10.0.0.1 443/TCP 4m - mongo ClusterIP 10.0.0.151 6379/TCP 2m - ``` + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + frontend ClusterIP 10.97.28.230 80/TCP 19s + kubernetes ClusterIP 10.96.0.1 443/TCP 3d19h + redis-follower ClusterIP 10.110.162.42 6379/TCP 5m48s + redis-leader ClusterIP 10.103.78.24 6379/TCP 11m + ``` ### `kubectl port-forward`를 통해 프론트엔드 서비스 확인하기 1. 다음 명령어를 실행해서 로컬 머신의 `8080` 포트를 서비스의 `80` 포트로 전달한다. - ```shell - kubectl port-forward svc/frontend 8080:80 - ``` + ```shell + kubectl port-forward svc/frontend 8080:80 + ``` - 결과는 아래와 같은 형태로 나타난다. + 결과는 아래와 같은 형태로 나타난다. - ``` - Forwarding from 127.0.0.1:8080 -> 80 - Forwarding from [::1]:8080 -> 80 - ``` + ``` + Forwarding from 127.0.0.1:8080 -> 80 + Forwarding from [::1]:8080 -> 80 + ``` -1. 방명록을 보기위해 브라우저에서 [http://localhost:8080](http://localhost:8080) 페이지를 로드한다. +1. 방명록을 보기 위해 브라우저에서 [http://localhost:8080](http://localhost:8080) 페이지를 로드한다. ### `LoadBalancer`를 통해 프론트엔드 서비스 확인하기 -`frontend-service.yaml` 매니페스트를 `LoadBalancer`와 함께 배포한 경우, 방명록을 보기 위해 IP 주소를 찾아야 한다. +`frontend-service.yaml` 매니페스트를 `LoadBalancer`와 함께 배포한 경우, +방명록을 보기 위해 IP 주소를 찾아야 한다. 1. 프론트엔드 서비스의 IP 주소를 얻기 위해 아래 명령어를 실행한다. - ```shell - kubectl get service frontend - ``` + ```shell + kubectl get service frontend + ``` - 결과는 아래와 같은 형태로 나타난다. + 결과는 아래와 같은 형태로 나타난다. - ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - frontend ClusterIP 10.51.242.136 109.197.92.229 80:32372/TCP 1m - ``` + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + frontend LoadBalancer 10.51.242.136 109.197.92.229 80:32372/TCP 1m + ``` 1. IP 주소를 복사하고, 방명록을 보기 위해 브라우저에서 페이지를 로드한다. +{{< note >}} +메시지를 입력하고 'Submit'을 클릭하여 방명록에 글을 작성해 본다. +입력한 메시지가 프론트엔드에 나타난다. 이 메시지는 앞서 생성한 서비스를 +통해 데이터가 Redis에 성공적으로 입력되었음을 나타낸다. +{{< /note >}} + ## 웹 프론트엔드 확장하기 -서버가 디플로이먼트 컨르롤러를 사용하는 서비스로 정의되어 있기에 필요에 따라 확장 또는 축소할 수 있다. +서버가 디플로이먼트 컨트롤러를 사용하는 서비스로 정의되어 있으므로 +필요에 따라 확장 또는 축소할 수 있다. 1. 프론트엔드 파드의 수를 확장하기 위해 아래 명령어를 실행한다. - ```shell - kubectl scale deployment frontend --replicas=5 - ``` + ```shell + kubectl scale deployment frontend --replicas=5 + ``` 1. 파드의 목록을 질의하여 실행 중인 프론트엔드 파드의 수를 확인한다. - ```shell - kubectl get pods - ``` + ```shell + kubectl get pods + ``` - 결과는 아래와 같은 형태로 나타난다. + 결과는 아래와 같은 형태로 나타난다. - ``` - NAME READY STATUS RESTARTS AGE - frontend-3823415956-70qj5 1/1 Running 0 5s - frontend-3823415956-dsvc5 1/1 Running 0 54m - frontend-3823415956-k22zn 1/1 Running 0 54m - frontend-3823415956-w9gbt 1/1 Running 0 54m - frontend-3823415956-x2pld 1/1 Running 0 5s - mongo-1068406935-3lswp 1/1 Running 0 56m - ``` + ``` + NAME READY STATUS RESTARTS AGE + frontend-85595f5bf9-5df5m 1/1 Running 0 83s + frontend-85595f5bf9-7zmg5 1/1 Running 0 83s + frontend-85595f5bf9-cpskg 1/1 Running 0 15m + frontend-85595f5bf9-l2l54 1/1 Running 0 14m + frontend-85595f5bf9-l9c8z 1/1 Running 0 14m + redis-follower-dddfbdcc9-82sfr 1/1 Running 0 97m + redis-follower-dddfbdcc9-qrt5k 1/1 Running 0 97m + redis-leader-fb76b4755-xjr2n 1/1 Running 0 108m + ``` 1. 프론트엔드 파드의 수를 축소하기 위해 아래 명령어를 실행한다. - ```shell - kubectl scale deployment frontend --replicas=2 - ``` + ```shell + kubectl scale deployment frontend --replicas=2 + ``` 1. 파드의 목록을 질의하여 실행 중인 프론트엔드 파드의 수를 확인한다. - ```shell - kubectl get pods - ``` - - 결과는 아래와 같은 형태로 나타난다. - - ``` - NAME READY STATUS RESTARTS AGE - frontend-3823415956-k22zn 1/1 Running 0 1h - frontend-3823415956-w9gbt 1/1 Running 0 1h - mongo-1068406935-3lswp 1/1 Running 0 1h - ``` + ```shell + kubectl get pods + ``` + 결과는 아래와 같은 형태로 나타난다. + ``` + NAME READY STATUS RESTARTS AGE + frontend-85595f5bf9-cpskg 1/1 Running 0 16m + frontend-85595f5bf9-l9c8z 1/1 Running 0 15m + redis-follower-dddfbdcc9-82sfr 1/1 Running 0 98m + redis-follower-dddfbdcc9-qrt5k 1/1 Running 0 98m + redis-leader-fb76b4755-xjr2n 1/1 Running 0 109m + ``` ## {{% heading "cleanup" %}} -디플로이먼트 및 서비스를 삭제하면 실행 중인 모든 파드도 삭제된다. 레이블을 사용하여 하나의 명령어로 여러 자원을 삭제해보자. +디플로이먼트 및 서비스를 삭제하면 실행 중인 모든 파드도 삭제된다. +레이블을 사용하여 하나의 명령어로 여러 자원을 삭제해보자. 1. 모든 파드, 디플로이먼트, 서비스를 삭제하기 위해 아래 명령어를 실행한다. - ```shell - kubectl delete deployment -l app.kubernetes.io/name=mongo - kubectl delete service -l app.kubernetes.io/name=mongo - kubectl delete deployment -l app.kubernetes.io/name=guestbook - kubectl delete service -l app.kubernetes.io/name=guestbook - ``` + ```shell + kubectl delete deployment -l app=redis + kubectl delete service -l app=redis + kubectl delete deployment frontend + kubectl delete service frontend + ``` - 결과는 아래와 같은 형태로 나타난다. + 결과는 아래와 같은 형태로 나타난다. - ``` - deployment.apps "mongo" deleted - service "mongo" deleted - deployment.apps "frontend" deleted - service "frontend" deleted - ``` + ``` + deployment.apps "redis-follower" deleted + deployment.apps "redis-leader" deleted + deployment.apps "frontend" deleted + service "frontend" deleted + ``` 1. 파드의 목록을 질의하여 실행 중인 파드가 없는지 확인한다. - ```shell - kubectl get pods - ``` - - 결과는 아래와 같은 형태로 나타난다. - - ``` - No resources found. - ``` + ```shell + kubectl get pods + ``` + 결과는 아래와 같은 형태로 나타난다. + ``` + No resources found in default namespace. + ``` ## {{% heading "whatsnext" %}} diff --git a/content/ko/examples/application/guestbook/frontend-deployment.yaml b/content/ko/examples/application/guestbook/frontend-deployment.yaml index 613c654aa9..f97f20dab6 100644 --- a/content/ko/examples/application/guestbook/frontend-deployment.yaml +++ b/content/ko/examples/application/guestbook/frontend-deployment.yaml @@ -1,32 +1,29 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook apiVersion: apps/v1 kind: Deployment metadata: name: frontend - labels: - app.kubernetes.io/name: guestbook - app.kubernetes.io/component: frontend spec: + replicas: 3 selector: matchLabels: - app.kubernetes.io/name: guestbook - app.kubernetes.io/component: frontend - replicas: 3 + app: guestbook + tier: frontend template: metadata: labels: - app.kubernetes.io/name: guestbook - app.kubernetes.io/component: frontend + app: guestbook + tier: frontend spec: containers: - - name: guestbook - image: paulczar/gb-frontend:v5 - # image: gcr.io/google-samples/gb-frontend:v4 + - name: php-redis + image: gcr.io/google_samples/gb-frontend:v5 + env: + - name: GET_HOSTS_FROM + value: "dns" resources: requests: cpu: 100m memory: 100Mi - env: - - name: GET_HOSTS_FROM - value: dns ports: - - containerPort: 80 + - containerPort: 80 \ No newline at end of file diff --git a/content/ko/examples/application/guestbook/frontend-service.yaml b/content/ko/examples/application/guestbook/frontend-service.yaml index 34ad3771d7..410c6bbaf2 100644 --- a/content/ko/examples/application/guestbook/frontend-service.yaml +++ b/content/ko/examples/application/guestbook/frontend-service.yaml @@ -1,16 +1,19 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook apiVersion: v1 kind: Service metadata: name: frontend labels: - app.kubernetes.io/name: guestbook - app.kubernetes.io/component: frontend + app: guestbook + tier: frontend spec: # if your cluster supports it, uncomment the following to automatically create # an external load-balanced IP for the frontend service. # type: LoadBalancer + #type: LoadBalancer ports: + # the port that this service should serve on - port: 80 selector: - app.kubernetes.io/name: guestbook - app.kubernetes.io/component: frontend + app: guestbook + tier: frontend \ No newline at end of file diff --git a/content/ko/examples/application/guestbook/mongo-deployment.yaml b/content/ko/examples/application/guestbook/mongo-deployment.yaml deleted file mode 100644 index 04908ce25b..0000000000 --- a/content/ko/examples/application/guestbook/mongo-deployment.yaml +++ /dev/null @@ -1,31 +0,0 @@ -apiVersion: apps/v1 -kind: Deployment -metadata: - name: mongo - labels: - app.kubernetes.io/name: mongo - app.kubernetes.io/component: backend -spec: - selector: - matchLabels: - app.kubernetes.io/name: mongo - app.kubernetes.io/component: backend - replicas: 1 - template: - metadata: - labels: - app.kubernetes.io/name: mongo - app.kubernetes.io/component: backend - spec: - containers: - - name: mongo - image: mongo:4.2 - args: - - --bind_ip - - 0.0.0.0 - resources: - requests: - cpu: 100m - memory: 100Mi - ports: - - containerPort: 27017 diff --git a/content/ko/examples/application/guestbook/mongo-service.yaml b/content/ko/examples/application/guestbook/mongo-service.yaml deleted file mode 100644 index b9cef607bc..0000000000 --- a/content/ko/examples/application/guestbook/mongo-service.yaml +++ /dev/null @@ -1,14 +0,0 @@ -apiVersion: v1 -kind: Service -metadata: - name: mongo - labels: - app.kubernetes.io/name: mongo - app.kubernetes.io/component: backend -spec: - ports: - - port: 27017 - targetPort: 27017 - selector: - app.kubernetes.io/name: mongo - app.kubernetes.io/component: backend diff --git a/content/ko/examples/application/guestbook/redis-follower-deployment.yaml b/content/ko/examples/application/guestbook/redis-follower-deployment.yaml new file mode 100644 index 0000000000..c418cf7364 --- /dev/null +++ b/content/ko/examples/application/guestbook/redis-follower-deployment.yaml @@ -0,0 +1,30 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: apps/v1 +kind: Deployment +metadata: + name: redis-follower + labels: + app: redis + role: follower + tier: backend +spec: + replicas: 2 + selector: + matchLabels: + app: redis + template: + metadata: + labels: + app: redis + role: follower + tier: backend + spec: + containers: + - name: follower + image: gcr.io/google_samples/gb-redis-follower:v2 + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 6379 \ No newline at end of file diff --git a/content/ko/examples/application/guestbook/redis-follower-service.yaml b/content/ko/examples/application/guestbook/redis-follower-service.yaml new file mode 100644 index 0000000000..53283d35c4 --- /dev/null +++ b/content/ko/examples/application/guestbook/redis-follower-service.yaml @@ -0,0 +1,17 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: v1 +kind: Service +metadata: + name: redis-follower + labels: + app: redis + role: follower + tier: backend +spec: + ports: + # the port that this service should serve on + - port: 6379 + selector: + app: redis + role: follower + tier: backend \ No newline at end of file diff --git a/content/ko/examples/application/guestbook/redis-leader-deployment.yaml b/content/ko/examples/application/guestbook/redis-leader-deployment.yaml new file mode 100644 index 0000000000..9c7547291c --- /dev/null +++ b/content/ko/examples/application/guestbook/redis-leader-deployment.yaml @@ -0,0 +1,30 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: apps/v1 +kind: Deployment +metadata: + name: redis-leader + labels: + app: redis + role: leader + tier: backend +spec: + replicas: 1 + selector: + matchLabels: + app: redis + template: + metadata: + labels: + app: redis + role: leader + tier: backend + spec: + containers: + - name: leader + image: "docker.io/redis:6.0.5" + resources: + requests: + cpu: 100m + memory: 100Mi + ports: + - containerPort: 6379 \ No newline at end of file diff --git a/content/ko/examples/application/guestbook/redis-leader-service.yaml b/content/ko/examples/application/guestbook/redis-leader-service.yaml new file mode 100644 index 0000000000..e04cc183d0 --- /dev/null +++ b/content/ko/examples/application/guestbook/redis-leader-service.yaml @@ -0,0 +1,17 @@ +# SOURCE: https://cloud.google.com/kubernetes-engine/docs/tutorials/guestbook +apiVersion: v1 +kind: Service +metadata: + name: redis-leader + labels: + app: redis + role: leader + tier: backend +spec: + ports: + - port: 6379 + targetPort: 6379 + selector: + app: redis + role: leader + tier: backend \ No newline at end of file diff --git a/content/ko/examples/application/job/cronjob.yaml b/content/ko/examples/application/job/cronjob.yaml index 816d682f28..da905a9048 100644 --- a/content/ko/examples/application/job/cronjob.yaml +++ b/content/ko/examples/application/job/cronjob.yaml @@ -1,4 +1,4 @@ -apiVersion: batch/v1beta1 +apiVersion: batch/v1 kind: CronJob metadata: name: hello diff --git a/content/ko/examples/application/job/redis/worker.py b/content/ko/examples/application/job/redis/worker.py index b8abbee917..0e24f71f95 100644 --- a/content/ko/examples/application/job/redis/worker.py +++ b/content/ko/examples/application/job/redis/worker.py @@ -8,11 +8,11 @@ host="redis" # import os # host = os.getenv("REDIS_SERVICE_HOST") -q = rediswq.RedisWQ(name="job2", host="redis") +q = rediswq.RedisWQ(name="job2", host=host) print("Worker with sessionID: " + q.sessionID()) print("Initial queue state: empty=" + str(q.empty())) while not q.empty(): - item = q.lease(lease_secs=10, block=True, timeout=2) + item = q.lease(lease_secs=10, block=True, timeout=2) if item is not None: itemstr = item.decode("utf-8") print("Working on " + itemstr) diff --git a/content/ko/examples/application/zookeeper/zookeeper.yaml b/content/ko/examples/application/zookeeper/zookeeper.yaml index a858a72613..4d893b369b 100644 --- a/content/ko/examples/application/zookeeper/zookeeper.yaml +++ b/content/ko/examples/application/zookeeper/zookeeper.yaml @@ -27,7 +27,7 @@ spec: selector: app: zk --- -apiVersion: policy/v1beta1 +apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: zk-pdb diff --git a/content/ko/examples/controllers/daemonset.yaml b/content/ko/examples/controllers/daemonset.yaml index f291b750c1..685a137244 100644 --- a/content/ko/examples/controllers/daemonset.yaml +++ b/content/ko/examples/controllers/daemonset.yaml @@ -18,6 +18,7 @@ spec: # this toleration is to have the daemonset runnable on master nodes # remove it if your masters can't run pods - key: node-role.kubernetes.io/master + operator: Exists effect: NoSchedule containers: - name: fluentd-elasticsearch diff --git a/content/ko/examples/policy/baseline-psp.yaml b/content/ko/examples/policy/baseline-psp.yaml new file mode 100644 index 0000000000..679b780096 --- /dev/null +++ b/content/ko/examples/policy/baseline-psp.yaml @@ -0,0 +1,74 @@ +apiVersion: policy/v1beta1 +kind: PodSecurityPolicy +metadata: + name: baseline + annotations: + # 선택 사항: 기본 AppArmor 프로파일을 활성화한다. 이 경우 기본값을 설정해야 한다. + apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' + apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' + seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*' +spec: + privileged: false + # Moby의 기본 캐퍼빌리티 집합(NET_RAW는 제외되었음) + allowedCapabilities: + - 'CHOWN' + - 'DAC_OVERRIDE' + - 'FSETID' + - 'FOWNER' + - 'MKNOD' + - 'SETGID' + - 'SETUID' + - 'SETFCAP' + - 'SETPCAP' + - 'NET_BIND_SERVICE' + - 'SYS_CHROOT' + - 'KILL' + - 'AUDIT_WRITE' + # hostpath를 제외한 모든 볼륨 타입을 허용 + volumes: + # '코어' 볼륨 타입 + - 'configMap' + - 'emptyDir' + - 'projected' + - 'secret' + - 'downwardAPI' + # 클러스터 관리자에 의해 구성된 휘발성 CSI 드라이버와 퍼시스턴트볼륨(PersistentVolume)은 사용하기에 안전하다고 가정한다. + - 'csi' + - 'persistentVolumeClaim' + - 'ephemeral' + # hostpath 타입이 아닌 다른 모든 볼륨 타입을 허용 + - 'awsElasticBlockStore' + - 'azureDisk' + - 'azureFile' + - 'cephFS' + - 'cinder' + - 'fc' + - 'flexVolume' + - 'flocker' + - 'gcePersistentDisk' + - 'gitRepo' + - 'glusterfs' + - 'iscsi' + - 'nfs' + - 'photonPersistentDisk' + - 'portworxVolume' + - 'quobyte' + - 'rbd' + - 'scaleIO' + - 'storageos' + - 'vsphereVolume' + hostNetwork: false + hostIPC: false + hostPID: false + readOnlyRootFilesystem: false + runAsUser: + rule: 'RunAsAny' + seLinux: + # 이 파드시큐리티폴리시는 노드가 SELinux가 아닌 AppArmor를 사용하고 있다고 가정한다. + # 파드시큐리티폴리시 SELinux API는 SELinux 파드 보안 표준을 표현할 수 없으므로, + # SELinux를 사용하는 경우 더 제한적인 기본값을 선택해야 한다. + rule: 'RunAsAny' + supplementalGroups: + rule: 'RunAsAny' + fsGroup: + rule: 'RunAsAny' diff --git a/content/ko/examples/policy/restricted-psp.yaml b/content/ko/examples/policy/restricted-psp.yaml index cbaf2758c0..4cdc12639a 100644 --- a/content/ko/examples/policy/restricted-psp.yaml +++ b/content/ko/examples/policy/restricted-psp.yaml @@ -5,14 +5,11 @@ metadata: annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default' apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' - seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default' apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' spec: privileged: false - # 루트로의 에스컬레이션을 방지하는데 필요하다. + # 루트로의 에스컬레이션을 방지하는 데 필요하다. allowPrivilegeEscalation: false - # 이것은 루트가 아닌 사용자 + 권한 에스컬레이션을 허용하지 않는 것으로 중복이지만, - # 심층 방어를 위해 이를 제공한다. requiredDropCapabilities: - ALL # 기본 볼륨 유형을 허용한다. @@ -22,8 +19,10 @@ spec: - 'projected' - 'secret' - 'downwardAPI' - # 클러스터 관리자가 설정한 퍼시스턴트볼륨을 사용하는 것이 안전하다고 가정한다. + # 클러스터 관리자에 의해 구성된 휘발성 CSI 드라이버와 퍼시스턴트볼륨(PersistentVolume)의 사용은 안전하다고 가정한다. + - 'csi' - 'persistentVolumeClaim' + - 'ephemeral' hostNetwork: false hostIPC: false hostPID: false diff --git a/content/ko/examples/service/networking/namespaced-params.yaml b/content/ko/examples/service/networking/namespaced-params.yaml new file mode 100644 index 0000000000..dd56724787 --- /dev/null +++ b/content/ko/examples/service/networking/namespaced-params.yaml @@ -0,0 +1,12 @@ +apiVersion: networking.k8s.io/v1 +kind: IngressClass +metadata: + name: external-lb +spec: + controller: example.com/ingress-controller + parameters: + apiGroup: k8s.example.com + kind: IngressParameters + name: external-lb + namespace: external-configuration + scope: Namespace diff --git a/content/ko/examples/windows/configmap-pod.yaml b/content/ko/examples/windows/configmap-pod.yaml new file mode 100644 index 0000000000..661cb73dee --- /dev/null +++ b/content/ko/examples/windows/configmap-pod.yaml @@ -0,0 +1,31 @@ +kind: ConfigMap +apiVersion: v1 +metadata: + name: example-config +data: + example.property.1: hello + example.property.2: world + +--- + +apiVersion: v1 +kind: Pod +metadata: + name: configmap-pod +spec: + containers: + - name: configmap-redis + image: redis:3.0-nanoserver + env: + - name: EXAMPLE_PROPERTY_1 + valueFrom: + configMapKeyRef: + name: example-config + key: example.property.1 + - name: EXAMPLE_PROPERTY_2 + valueFrom: + configMapKeyRef: + name: example-config + key: example.property.2 + nodeSelector: + kubernetes.io/os: windows \ No newline at end of file diff --git a/content/ko/examples/windows/daemonset.yaml b/content/ko/examples/windows/daemonset.yaml new file mode 100644 index 0000000000..7483708fc7 --- /dev/null +++ b/content/ko/examples/windows/daemonset.yaml @@ -0,0 +1,21 @@ +apiVersion: apps/v1 +kind: DaemonSet +metadata: + name: my-daemonset + labels: + app: foo +spec: + selector: + matchLabels: + app: foo + template: + metadata: + labels: + app: foo + spec: + containers: + - name: foo + image: microsoft/windowsservercore:1709 + nodeSelector: + kubernetes.io/os: windows + diff --git a/content/ko/examples/windows/deploy-hyperv.yaml b/content/ko/examples/windows/deploy-hyperv.yaml new file mode 100644 index 0000000000..c8b71ce8cb --- /dev/null +++ b/content/ko/examples/windows/deploy-hyperv.yaml @@ -0,0 +1,22 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: iis +spec: + selector: + matchLabels: + app: iis + replicas: 3 + template: + metadata: + labels: + app: iis + annotations: + experimental.windows.kubernetes.io/isolation-type: hyperv + spec: + containers: + - name: iis + image: microsoft/iis + ports: + - containerPort: 80 + diff --git a/content/ko/examples/windows/deploy-resource.yaml b/content/ko/examples/windows/deploy-resource.yaml new file mode 100644 index 0000000000..81207a3804 --- /dev/null +++ b/content/ko/examples/windows/deploy-resource.yaml @@ -0,0 +1,24 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: iis +spec: + replicas: 3 + selector: + matchLabels: + app: iis + template: + metadata: + labels: + app: iis + spec: + containers: + - name: iis + image: microsoft/iis + resources: + limits: + memory: "128Mi" + cpu: 2 + ports: + - containerPort: 80 + diff --git a/content/ko/examples/windows/emptydir-pod.yaml b/content/ko/examples/windows/emptydir-pod.yaml new file mode 100644 index 0000000000..08d8091391 --- /dev/null +++ b/content/ko/examples/windows/emptydir-pod.yaml @@ -0,0 +1,20 @@ +apiVersion: v1 +kind: Pod +metadata: + name: my-empty-dir-pod +spec: + containers: + - image: microsoft/windowsservercore:1709 + name: my-empty-dir-pod + volumeMounts: + - mountPath: /cache + name: cache-volume + - mountPath: C:/scratch + name: scratch-volume + volumes: + - name: cache-volume + emptyDir: {} + - name: scratch-volume + emptyDir: {} + nodeSelector: + kubernetes.io/os: windows diff --git a/content/ko/examples/windows/hostpath-volume-pod.yaml b/content/ko/examples/windows/hostpath-volume-pod.yaml new file mode 100644 index 0000000000..d95e345b6c --- /dev/null +++ b/content/ko/examples/windows/hostpath-volume-pod.yaml @@ -0,0 +1,18 @@ +apiVersion: v1 +kind: Pod +metadata: + name: hostpath-volume-pod +spec: + containers: + - name: my-hostpath-volume-pod + image: microsoft/windowsservercore:1709 + volumeMounts: + - name: foo + mountPath: "C:\\etc\\foo" + readOnly: true + nodeSelector: + kubernetes.io/os: windows + volumes: + - name: foo + hostPath: + path: "C:\\etc\\foo" diff --git a/content/ko/examples/windows/run-as-username-container.yaml b/content/ko/examples/windows/run-as-username-container.yaml new file mode 100644 index 0000000000..77b7b2d188 --- /dev/null +++ b/content/ko/examples/windows/run-as-username-container.yaml @@ -0,0 +1,17 @@ +apiVersion: v1 +kind: Pod +metadata: + name: run-as-username-container-demo +spec: + securityContext: + windowsOptions: + runAsUserName: "ContainerUser" + containers: + - name: run-as-username-demo + image: mcr.microsoft.com/windows/servercore:ltsc2019 + command: ["ping", "-t", "localhost"] + securityContext: + windowsOptions: + runAsUserName: "ContainerAdministrator" + nodeSelector: + kubernetes.io/os: windows diff --git a/content/ko/examples/windows/run-as-username-pod.yaml b/content/ko/examples/windows/run-as-username-pod.yaml new file mode 100644 index 0000000000..281bbda597 --- /dev/null +++ b/content/ko/examples/windows/run-as-username-pod.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: run-as-username-pod-demo +spec: + securityContext: + windowsOptions: + runAsUserName: "ContainerUser" + containers: + - name: run-as-username-demo + image: mcr.microsoft.com/windows/servercore:ltsc2019 + command: ["ping", "-t", "localhost"] + nodeSelector: + kubernetes.io/os: windows diff --git a/content/ko/examples/windows/secret-pod.yaml b/content/ko/examples/windows/secret-pod.yaml new file mode 100644 index 0000000000..69ee9b1f1e --- /dev/null +++ b/content/ko/examples/windows/secret-pod.yaml @@ -0,0 +1,32 @@ +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm + +--- + +apiVersion: v1 +kind: Pod +metadata: + name: my-secret-pod +spec: + containers: + - name: my-secret-pod + image: microsoft/windowsservercore:1709 + env: + - name: USERNAME + valueFrom: + secretKeyRef: + name: mysecret + key: username + - name: PASSWORD + valueFrom: + secretKeyRef: + name: mysecret + key: password + nodeSelector: + kubernetes.io/os: windows diff --git a/content/ko/examples/windows/simple-pod.yaml b/content/ko/examples/windows/simple-pod.yaml new file mode 100644 index 0000000000..0b1f0ed5c5 --- /dev/null +++ b/content/ko/examples/windows/simple-pod.yaml @@ -0,0 +1,14 @@ +apiVersion: v1 +kind: Pod +metadata: + name: iis + labels: + name: iis +spec: + containers: + - name: iis + image: microsoft/iis:windowsservercore-1709 + ports: + - containerPort: 80 + nodeSelector: + "kubernetes.io/os": windows diff --git a/content/ko/includes/task-tutorial-prereqs.md b/content/ko/includes/task-tutorial-prereqs.md index 90aa725d6c..e27f4b99e4 100644 --- a/content/ko/includes/task-tutorial-prereqs.md +++ b/content/ko/includes/task-tutorial-prereqs.md @@ -1,8 +1,8 @@ 쿠버네티스 클러스터가 필요하고, kubectl 커맨드-라인 툴이 클러스터와 -통신할 수 있도록 설정되어 있어야 한다. -만약, 아직 클러스터를 가지고 있지 않다면, +통신할 수 있도록 설정되어 있어야 한다. 이 튜토리얼은 컨트롤 플레인 호스트가 아닌 노드가 적어도 2개 포함된 클러스터에서 실행하는 것을 추천한다. 만약, 아직 클러스터를 가지고 +있지 않다면, [minikube](/ko/docs/tasks/tools/#minikube)를 사용해서 생성하거나 다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다. * [Katacoda](https://www.katacoda.com/courses/kubernetes/playground) -* [Play with Kubernetes](http://labs.play-with-k8s.com/) +* [Play with Kubernetes](https://labs.play-with-k8s.com/) diff --git a/content/ko/releases/_index.md b/content/ko/releases/_index.md new file mode 100644 index 0000000000..aa6a306f8a --- /dev/null +++ b/content/ko/releases/_index.md @@ -0,0 +1,27 @@ +--- +linktitle: 릴리스 히스토리 +title: 릴리스 +type: docs +--- + + + + +쿠버네티스 프로젝트는 가장 최신의 3개 마이너(minor) 릴리스({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}})에 대해서 릴리스 브랜치를 관리한다. 쿠버네티스 1.19 및 이후 신규 버전은 약 1년간 패치 지원을 받을 수 있다. 쿠버네티스 1.18 및 이전 버전은 약 9개월간의 패치 지원을 받을 수 있다. + +쿠버네티스 버전은 **x.y.z** 의 형태로 표현되는데, +**x** 는 메이저(major) 버전, **y** 는 마이너(minor), **z** 는 패치(patch) 버전을 의미하며, 이는 [시맨틱 버전](https://semver.org/)의 용어를 따른 것이다. + +저 자세한 정보는 [버전 차이(skew) 정책](/releases/version-skew-policy/) 문서에서 확인하길 바란다. + + + +## 릴리스 히스토리 + +{{< release-data >}} + +## 차기 릴리스 + +차기 쿠버네티스 릴리스 **{{< skew nextMinorVersion >}}** 일정은 [스케줄](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}})에서 확인할 수 있다. + +## 유용한 자원 diff --git a/content/ko/releases/notes.md b/content/ko/releases/notes.md new file mode 100644 index 0000000000..b509ae0d65 --- /dev/null +++ b/content/ko/releases/notes.md @@ -0,0 +1,13 @@ +--- +linktitle: 릴리스 노트 +title: 노트 +type: docs +description: > + 쿠버네티스 릴리스 노트. +sitemap: + priority: 0.5 +--- + +릴리스 노트는 사용자의 쿠버네티스 버전에 해당하는 [변경로그(Changelog)](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG)를 통해서 확인할 수 있다. {{< skew latestVersion >}} 의 변경로그는 [깃허브](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew latestVersion >}}.md)에 있다. + +대안으로, 릴리스 노트는 [relnotes.k8s.io](https://relnotes.k8s.io)에서 온라인으로 검색 및 필터링이 가능하다. {{< skew latestVersion >}}로 필터링된 릴리스 노트는 [relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew latestVersion >}}.0)에서 확인한다. diff --git a/content/ko/docs/setup/release/version-skew-policy.md b/content/ko/releases/version-skew-policy.md similarity index 96% rename from content/ko/docs/setup/release/version-skew-policy.md rename to content/ko/releases/version-skew-policy.md index 76ff7504fd..dba98dcdf8 100644 --- a/content/ko/docs/setup/release/version-skew-policy.md +++ b/content/ko/releases/version-skew-policy.md @@ -6,22 +6,21 @@ -title: 쿠버네티스 버전 및 버전 차이(skew) 지원 정책 -content_type: concept -weight: 30 +title: 버전 차이(skew) 정책 +type: docs +description: > + 다양한 쿠버네티스 구성 요소 간에 지원되는 최대 버전 차이 --- 이 문서는 다양한 쿠버네티스 구성 요소 간에 지원되는 최대 버전 차이를 설명한다. 특정 클러스터 배포 도구는 버전 차이에 대한 추가적인 제한을 설정할 수 있다. - ## 지원되는 버전 -쿠버네티스 버전은 **x.y.z**로 표현되는데, -여기서 **x**는 메이저 버전, **y**는 마이너 버전, **z**는 [시맨틱 버전](https://semver.org/) 용어에 따른 패치 버전이다. +쿠버네티스 버전은 **x.y.z** 로 표현되는데, 여기서 **x** 는 메이저 버전, **y** 는 마이너 버전, **z** 는 패치 버전을 의미하며, 이는 [시맨틱 버전](https://semver.org/) 용어에 따른 것이다. 자세한 내용은 [쿠버네티스 릴리스 버전](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning)을 참조한다. 쿠버네티스 프로젝트는 최근 세 개의 마이너 릴리스 ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}) 에 대한 릴리스 분기를 유지한다. 쿠버네티스 1.19 이상은 약 1년간의 패치 지원을 받는다. 쿠버네티스 1.18 이상은 약 9개월의 패치 지원을 받는다. diff --git a/content/pl/_index.html b/content/pl/_index.html index 1096114700..03ec4a4c44 100644 --- a/content/pl/_index.html +++ b/content/pl/_index.html @@ -44,12 +44,12 @@ Kubernetes jako projekt open-source daje Ci wolność wyboru ⏤ skorzystaj z pr

    - Weź udział w wirtualnym KubeCon NA, 17-20.11.2020 + Weź udział w KubeCon North America 11-15.10.2021



    - Weź udział w wirtualnym KubeCon EU 4–7.05.2021 + Weź udział w wirtualnym KubeCon Europe 17-20.5.2022
    diff --git a/content/pl/docs/concepts/overview/_index.md b/content/pl/docs/concepts/overview/_index.md old mode 100755 new mode 100644 diff --git a/content/pl/docs/concepts/overview/components.md b/content/pl/docs/concepts/overview/components.md index dba2d1e782..b6843e04db 100644 --- a/content/pl/docs/concepts/overview/components.md +++ b/content/pl/docs/concepts/overview/components.md @@ -27,7 +27,7 @@ Poniższy rysunek przedstawia klaster Kubernetes i powiązania pomiędzy jego r Komponenty warstwy sterowania podejmują ogólne decyzje dotyczące klastra (np. zlecanie zadań), a także wykrywają i reagują na zdarzenia w klastrze (przykładowo, start nowego {{< glossary_tooltip text="poda" term_id="pod">}}, kiedy wartość `replicas` dla deploymentu nie zgadza się z faktyczną liczbą replik). -Komponenty warstwy sterowania mogą być uruchomione na dowolnej maszynie w klastrze. Dla uproszczenia jednak skrypty instalacyjne zazwyczaj startują wszystkie składniki na tej samej maszynie i jednocześnie nie pozwalają na uruchamianie na niej kontenerów użytkowników. Na stronie [Tworzenie Wysoko Dostępnych Klastrów](/docs/admin/high-availability/) jest więcej informacji o konfiguracji typu *multi-master-VM*. +Komponenty warstwy sterowania mogą być uruchomione na dowolnej maszynie w klastrze. Dla uproszczenia jednak skrypty instalacyjne zazwyczaj startują wszystkie składniki na tej samej maszynie i jednocześnie nie pozwalają na uruchamianie na niej kontenerów użytkowników. Na stronie [Creating Highly Available clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/high-availability/) znajdziesz opis konfiguracji warstwy sterowania działającej na wielu maszynach wirtualnych. ### kube-apiserver @@ -45,10 +45,11 @@ Komponenty warstwy sterowania mogą być uruchomione na dowolnej maszynie w klas {{< glossary_definition term_id="kube-controller-manager" length="all" >}} -Kontrolerami są: +Przykładowe kontrolery: * Node controller: Odpowiada za rozpoznawanie i reagowanie na sytuacje, kiedy węzeł staje się z jakiegoś powodu niedostępny. -* Replication controller: Odpowiada za utrzymanie prawidłowej liczby podów dla każdego obiektu typu *ReplicationController* w systemie. +* Job controller: Czeka na obiekty typu *Job*, które definiują zadania uruchamiane jednorazowo + i startuje Pody, odpowiadające za ich wykonanie tych zadań. * Endpoints controller: Dostarcza informacji do obiektów typu *Endpoints* (tzn. łączy ze sobą Serwisy i Pody). * Service Account & Token controllers: Tworzy domyślne konta i tokeny dostępu API dla nowych przestrzeni nazw (*namespaces*). diff --git a/content/pl/docs/concepts/overview/what-is-kubernetes.md b/content/pl/docs/concepts/overview/what-is-kubernetes.md index d28c841553..7391ed6602 100644 --- a/content/pl/docs/concepts/overview/what-is-kubernetes.md +++ b/content/pl/docs/concepts/overview/what-is-kubernetes.md @@ -14,11 +14,10 @@ sitemap: Na tej stronie znajdziesz ogólne informacje o Kubernetesie. - Kubernetes to przenośna, rozszerzalna platforma oprogramowania *open-source* służąca do zarządzania zadaniami i serwisami uruchamianymi w kontenerach, która umożliwia deklaratywną konfigurację i automatyzację. Ekosystem Kubernetesa jest duży i dynamicznie się rozwija. Serwisy Kubernetesa, wsparcie i narzędzia są szeroko dostępne. -Nazwa Kubernetes pochodzi z greki i oznacza sternika albo pilota. Google otworzyło projekt Kubernetes publicznie w 2014. Kubernetes korzysta z [piętnastoletniego doświadczenia Google w uruchamianiu wielkoskalowych serwisów](/blog/2015/04/borg-predecessor-to-kubernetes/) i łączy je z najlepszymi pomysłami i praktykami wypracowanymi przez społeczność. +Nazwa Kubernetes pochodzi z greki i oznacza sternika albo pilota. Skrót K8s powstał poprzez zastąpienie ośmiu liter pomiędzy "K" i "s" .Google otworzyło projekt Kubernetes publicznie w 2014. Kubernetes korzysta z [piętnastoletniego doświadczenia Google w uruchamianiu wielkoskalowych serwisów](/blog/2015/04/borg-predecessor-to-kubernetes/) i łączy je z najlepszymi pomysłami i praktykami wypracowanymi przez społeczność. ## Trochę historii diff --git a/content/pl/docs/reference/glossary/cloud-controller-manager.md b/content/pl/docs/reference/glossary/cloud-controller-manager.md old mode 100755 new mode 100644 diff --git a/content/pl/docs/reference/glossary/cluster.md b/content/pl/docs/reference/glossary/cluster.md old mode 100755 new mode 100644 diff --git a/content/pl/docs/reference/glossary/etcd.md b/content/pl/docs/reference/glossary/etcd.md old mode 100755 new mode 100644 diff --git a/content/pl/docs/reference/glossary/index.md b/content/pl/docs/reference/glossary/index.md old mode 100755 new mode 100644 diff --git a/content/pl/docs/reference/glossary/kube-apiserver.md b/content/pl/docs/reference/glossary/kube-apiserver.md old mode 100755 new mode 100644 index 14b58a9ba6..12620387d0 --- a/content/pl/docs/reference/glossary/kube-apiserver.md +++ b/content/pl/docs/reference/glossary/kube-apiserver.md @@ -4,7 +4,7 @@ id: kube-apiserver date: 2018-04-12 full_link: /docs/concepts/overview/components/#kube-apiserver short_description: > - Składnik warstwy sterowania udostępniający API Kubernetes. + Składnik warstwy sterowania udostępniający API Kubernetesa. aka: - kube-apiserver @@ -12,13 +12,12 @@ tags: - architecture - fundamental --- - Składnik *master* udostępniający API Kubernetes. Służy jako *front-end* dla warstwy sterowania Kubernetes. - Serwer API jest składnikiem -{{< glossary_tooltip text="warstwy sterowania" term_id="control-plane" >}} Kubernetes, który udostępnia API. +Serwer API jest składnikiem +{{< glossary_tooltip text="warstwy sterowania" term_id="control-plane" >}} Kubernetesa, który udostępnia API. Server API służy jako front-end warstwy sterowania Kubernetes. -Podstawowa implementacją serwera API Kubernetes jest [kube-apiserver](/docs/reference/generated/kube-apiserver/). +Podstawową implementacją serwera API Kubernetesa jest [kube-apiserver](/docs/reference/generated/kube-apiserver/). kube-apiserver został zaprojektowany w taki sposób, aby móc skalować się horyzontalnie — to oznacza, że zwiększa swoją wydajność poprzez dodawanie kolejnych instancji. Można uruchomić kilka instancji kube-apiserver i rozkładać między nimi ruch od klientów. diff --git a/content/pl/docs/reference/glossary/kube-controller-manager.md b/content/pl/docs/reference/glossary/kube-controller-manager.md old mode 100755 new mode 100644 diff --git a/content/pl/docs/reference/glossary/kube-proxy.md b/content/pl/docs/reference/glossary/kube-proxy.md old mode 100755 new mode 100644 diff --git a/content/pl/docs/reference/glossary/kube-scheduler.md b/content/pl/docs/reference/glossary/kube-scheduler.md old mode 100755 new mode 100644 diff --git a/content/pl/docs/reference/glossary/kubelet.md b/content/pl/docs/reference/glossary/kubelet.md old mode 100755 new mode 100644 diff --git a/content/pl/docs/reference/tools.md b/content/pl/docs/reference/tools.md deleted file mode 100644 index 2ec66964ed..0000000000 --- a/content/pl/docs/reference/tools.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Narzędzia -content_type: concept ---- - - -Kubernetes zawiera różne wbudowane narzędzia służące do pracy z systemem: - - - -## Kubectl - -[`kubectl`](/docs/tasks/tools/install-kubectl/) to narzędzie tekstowe (linii poleceń) do Kubernetes. Służy do zarządzania klastrem Kubernetes. - -## Kubeadm - -[`kubeadm`](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/) to narzędzie tekstowe do łatwej instalacji klastra Kubernetes w bezpiecznej konfiguracji, uruchamianego na infrastrukturze serwerów fizycznych, serwerów w chmurze bądź na maszynach wirtualnych (aktualnie w fazie rozwojowej alfa). - -## Minikube - -[`minikube`](https://minikube.sigs.k8s.io/docs/) to narzędzie do uruchamiania jednowęzłowego klastra Kubernetes na twojej stacji roboczej na potrzeby rozwoju oprogramowania lub prowadzenia testów. - -## Pulpit *(Dashboard)* - -[`Dashboard`](/docs/tasks/access-application-cluster/web-ui-dashboard/) - graficzny interfejs użytkownika w przeglądarce web, który umożliwia instalację aplikacji w kontenerach na klastrze Kubernetes, rozwiązywanie problemów z nimi związanych oraz zarządzanie samym klastrem i jego zasobami. - -## Helm - -[`Kubernetes Helm`](https://github.com/kubernetes/helm) — narzędzie do zarządzania pakietami wstępnie skonfigurowanych zasobów Kubernetes (nazywanych *Kubernetes charts*). - -Helm-a można używać do: - -* Wyszukiwania i instalowania popularnego oprogramowania dystrybuowanego jako Kubernetes *charts* -* Udostępniania własnych aplikacji w postaci pakietów Kubernetes *charts* -* Definiowania powtarzalnych instalacji aplikacji na Kubernetes -* Inteligentnego zarządzania plikami list (*manifests*) Kubernetes -* Zarządzaniem kolejnymi wydaniami pakietów Helm - -## Kompose - -[`Kompose`](https://github.com/kubernetes/kompose) to narzędzie, które ma pomóc użytkownikom Docker Compose przenieść się na Kubernetes. - -Kompose można używać do: - -* Tłumaczenia plików Docker Compose na obiekty Kubernetes -* Zmiany sposóbu zarządzania twoimi aplikacjami z lokalnego środowiska Docker na system Kubernetes -* Zamiany plików `yaml` Docker Compose v1 lub v2 oraz [Distributed Application Bundles](https://docs.docker.com/compose/bundles/) - diff --git a/content/pl/docs/setup/_index.md b/content/pl/docs/setup/_index.md index 6107fe0f03..a2908369f7 100644 --- a/content/pl/docs/setup/_index.md +++ b/content/pl/docs/setup/_index.md @@ -1,9 +1,9 @@ --- -no_issue: true title: Od czego zacząć main_menu: true weight: 20 content_type: concept +no_list: true card: name: setup weight: 20 @@ -19,16 +19,44 @@ card: Ten rozdział poświęcony jest różnym metodom konfiguracji i uruchomienia Kubernetesa. Instalując Kubernetesa, przy wyborze platformy kieruj się: łatwością w utrzymaniu, spełnianymi wymogami bezpieczeństwa, poziomem sterowania, dostępnością zasobów oraz doświadczeniem wymaganym do zarządzania klastrem. -Klaster Kubernetes możesz zainstalować na lokalnym komputerze, w chmurze czy w prywatnym centrum obliczeniowym albo skorzystać z klastra Kubernetes udostępnianego jako usługa. Inną możliwością jest budowa własnego systemu opartego o różnych dostawców usług chmurowych, bądź bazującego bezpośrednio na sprzęcie fizycznym. +Możesz [pobrać Kubernetesa](/releases/download/), aby zainstalować klaster +na lokalnym komputerze, w chmurze czy w prywatnym centrum obliczeniowym. + +Jeśli nie chcesz zarządzać klastrem Kubernetesa samodzielnie, możesz wybrać serwis zarządzany przez zewnętrznego dostawcę, +wybierając na przykład spośród [certyfikowanych platform](/docs/setup/production-environment/turnkey-solutions/). +Dostępne są także inne standardowe i specjalizowane rozwiązania dla różnych środowisk chmurowych +bądź bazujące bezpośrednio na sprzęcie fizycznym. ## Środowisko do nauki {#srodowisko-do-nauki} -Do nauki Kubernetesa wykorzystaj narzędzia wspierane przez społeczność Kubernetesa lub inne narzędzia dostępne w ekosystemie, aby uruchomić klaster Kubernetesa na swoim komputerze lokalnym. +Do nauki Kubernetesa wykorzystaj narzędzia wspierane przez społeczność Kubernetesa +lub inne narzędzia dostępne w ekosystemie, aby uruchomić klaster Kubernetesa na swoim komputerze lokalnym. +Zapoznaj się z [narzędziami instalacyjnymi](/docs/tasks/tools/). ## Środowisko produkcyjne {#srodowisko-produkcyjne} -Wybierając rozwiązanie dla środowiska produkcyjnego musisz zdecydować, którymi poziomami zarządzania klastrem (_abstrakcjami_) chcesz zajmować się sam, a które będą realizowane po stronie zewnętrznego operatora. +Wybierając rozwiązanie dla +[środowiska produkcyjnego](/docs/setup/production-environment/) musisz zdecydować, +którymi poziomami zarządzania klastrem (_abstrakcjami_) chcesz zajmować się sam, +a które będą realizowane po stronie zewnętrznego operatora. -Na stronie [Partnerzy Kubernetes](https://kubernetes.io/partners/#conformance) znajdziesz listę dostawców posiadających [certyfikację Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes). +Do instalacji klastra Kubernetesa zarządzanego samodzielnie oficjalnym narzędziem +jest [kubeadm](/docs/setup/production-environment/tools/kubeadm/). + +## {{% heading "whatsnext" %}} + +- [Pobierz Kubernetesa](/releases/download/) +- Pobierz i [zainstaluj narzędzia](/docs/tasks/tools/), w tym `kubectl` +- Wybierz [środowisko uruchomieniowe dla kontenerów](/docs/setup/production-environment/container-runtimes/) w nowym klastrze +- Naucz się [najlepszych praktyk](/docs/setup/best-practices/) przy konfigurowaniu klastra + +Na stronie [Partnerów Kubernetesa](https://kubernetes.io/partners/#conformance) znajdziesz listę dostawców posiadających +[certyfikację Kubernetes](https://github.com/cncf/k8s-conformance/#certified-kubernetes). + +Kubernetes zaprojektowano w ten sposób, że {{< glossary_tooltip term_id="control-plane" text="warstwa sterowania" >}} +wymaga do działania systemu Linux. W ramach klastra aplikacje mogą być uruchamiane na systemie Linux i innych, +w tym Windows. + +- Naucz się, [jak zbudować klaster z węzłami Windows](/docs/setup/production-environment/windows/) diff --git a/content/pl/docs/setup/release/_index.md b/content/pl/docs/setup/release/_index.md deleted file mode 100755 index 2783105198..0000000000 --- a/content/pl/docs/setup/release/_index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: "Informacje o wydaniach i dozwolonych różnicach wersji" -weight: 10 ---- diff --git a/content/pl/docs/tutorials/kubernetes-basics/_index.html b/content/pl/docs/tutorials/kubernetes-basics/_index.html index e27a3ad6bf..0996edc64b 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/_index.html +++ b/content/pl/docs/tutorials/kubernetes-basics/_index.html @@ -11,7 +11,7 @@ card: - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index 12211e42b6..72409e9238 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html index 3955e557c4..c5eddaf5f9 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 64c1a0a9a1..954bad22b3 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index c879aa82b9..f4b893d60b 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/explore/explore-interactive.html index 1ae1e88382..14afae5a3d 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/explore/explore-interactive.html +++ b/content/pl/docs/tutorials/kubernetes-basics/explore/explore-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/pl/docs/tutorials/kubernetes-basics/explore/explore-intro.html index edfff527e6..f62563e1cd 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-interactive.html index a1aca99ce3..1aefa3e793 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-interactive.html +++ b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html index f9f9134e4a..199ab9dfe7 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/scale/scale-interactive.html index e8017f5ad6..7990fbd1a6 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/scale/scale-interactive.html +++ b/content/pl/docs/tutorials/kubernetes-basics/scale/scale-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/pl/docs/tutorials/kubernetes-basics/scale/scale-intro.html index 91eb10eb6d..bb2c40ffee 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/scale/scale-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/scale/scale-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/pl/docs/tutorials/kubernetes-basics/update/update-interactive.html index 07731b5849..5664abc0e6 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/update/update-interactive.html +++ b/content/pl/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -5,7 +5,7 @@ weight: 20 - + diff --git a/content/pl/docs/tutorials/kubernetes-basics/update/update-intro.html b/content/pl/docs/tutorials/kubernetes-basics/update/update-intro.html index b51779237d..2c42eee6d6 100644 --- a/content/pl/docs/tutorials/kubernetes-basics/update/update-intro.html +++ b/content/pl/docs/tutorials/kubernetes-basics/update/update-intro.html @@ -5,7 +5,7 @@ weight: 10 - + diff --git a/content/pl/releases/_index.md b/content/pl/releases/_index.md new file mode 100644 index 0000000000..46c2a7659f --- /dev/null +++ b/content/pl/releases/_index.md @@ -0,0 +1,27 @@ +--- +linktitle: Historia wydań +title: Wydania +type: docs +--- + + + + +Projekt Kubernetes zapewnia wsparcie dla trzech ostatnich wydań _minor_ ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Poprawki do wydania 1.19 i nowszych będą publikowane przez około rok. Kuberetes w wersji 1.18 i wcześniejszych będzie otrzymywał poprawki przez 9 miesięcy. + +Wersje Kubernetesa oznaczane są jako **x.y.z**, +gdzie **x** jest oznaczeniem wersji głównej (_major_), **y** — podwersji (_minor_), a **z** — numer poprawki (_patch_), zgodnie z terminologią [Semantic Versioning](https://semver.org/). + +Więcej informacji można z znaleźć w dokumencie [version skew policy](/releases/version-skew-policy/). + + + +## Historia wydań + +{{< release-data >}} + +## Nadchodzące wydania + +Zajrzyj na [harmonogram](https://github.com/kubernetes/sig-release/tree/master/releases/release-{{< skew nextMinorVersion >}}) nadchodzącego wydania Kubernetesa numer **{{< skew nextMinorVersion >}}**! + +## Przydatne zasoby diff --git a/content/pl/training/_index.html b/content/pl/training/_index.html index 2dd7ed433e..0fd093af3d 100644 --- a/content/pl/training/_index.html +++ b/content/pl/training/_index.html @@ -70,7 +70,7 @@ class: training

    Nauka z Linux Foundation

    -

    Linux Foundation oferuje szkolenia prowadzone przez instruktora oraz szkolenia samodzielne obejmujące wszystkie aspekty rozwijania i zarządzania aplikacjami na Kubrnetesie.

    +

    Linux Foundation oferuje szkolenia prowadzone przez instruktora oraz szkolenia samodzielne obejmujące wszystkie aspekty rozwijania i zarządzania aplikacjami na Kubernetesie.



    Sprawdź ofertę szkoleń
    diff --git a/content/pt/OWNERS b/content/pt-br/OWNERS similarity index 100% rename from content/pt/OWNERS rename to content/pt-br/OWNERS diff --git a/content/pt/_common-resources/index.md b/content/pt-br/_common-resources/index.md similarity index 100% rename from content/pt/_common-resources/index.md rename to content/pt-br/_common-resources/index.md diff --git a/content/pt/_index.html b/content/pt-br/_index.html similarity index 100% rename from content/pt/_index.html rename to content/pt-br/_index.html diff --git a/content/pt/blog/_index.md b/content/pt-br/blog/_index.md similarity index 100% rename from content/pt/blog/_index.md rename to content/pt-br/blog/_index.md diff --git a/content/pt/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md b/content/pt-br/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md similarity index 100% rename from content/pt/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md rename to content/pt-br/blog/_posts/2020-09-02-scaling-kubernetes-networking-endpointslices.md diff --git a/content/pt/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md b/content/pt-br/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md similarity index 100% rename from content/pt/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md rename to content/pt-br/blog/_posts/2020-12-02-dont-panic-kubernetes-and-docker.md diff --git a/content/pt/case-studies/_index.md b/content/pt-br/case-studies/_index.md similarity index 100% rename from content/pt/case-studies/_index.md rename to content/pt-br/case-studies/_index.md diff --git a/content/pt/case-studies/chinaunicom/chinaunicom_featured_logo.png b/content/pt-br/case-studies/chinaunicom/chinaunicom_featured_logo.png similarity index 100% rename from content/pt/case-studies/chinaunicom/chinaunicom_featured_logo.png rename to content/pt-br/case-studies/chinaunicom/chinaunicom_featured_logo.png diff --git a/content/pt/case-studies/chinaunicom/index.html b/content/pt-br/case-studies/chinaunicom/index.html similarity index 100% rename from content/pt/case-studies/chinaunicom/index.html rename to content/pt-br/case-studies/chinaunicom/index.html diff --git a/content/pt/community/_index.html b/content/pt-br/community/_index.html similarity index 100% rename from content/pt/community/_index.html rename to content/pt-br/community/_index.html diff --git a/content/pt/community/code-of-conduct.md b/content/pt-br/community/code-of-conduct.md similarity index 100% rename from content/pt/community/code-of-conduct.md rename to content/pt-br/community/code-of-conduct.md diff --git a/content/pt/community/static/README.md b/content/pt-br/community/static/README.md similarity index 100% rename from content/pt/community/static/README.md rename to content/pt-br/community/static/README.md diff --git a/content/pt/community/static/cncf-code-of-conduct.md b/content/pt-br/community/static/cncf-code-of-conduct.md similarity index 100% rename from content/pt/community/static/cncf-code-of-conduct.md rename to content/pt-br/community/static/cncf-code-of-conduct.md diff --git a/content/pt/docs/_index.md b/content/pt-br/docs/_index.md similarity index 88% rename from content/pt/docs/_index.md rename to content/pt-br/docs/_index.md index 1d1529975c..6e34880dd2 100644 --- a/content/pt/docs/_index.md +++ b/content/pt-br/docs/_index.md @@ -16,7 +16,7 @@ Como você pode ver, a maior parte da documentação ainda está disponível ape -Se você quiser participar, você pode entrar no canal Slack [#kubernets-docs-pt](http://slack.kubernetes.io/) e fazer parte da equipe por trás da tradução. +Se você quiser participar, você pode entrar no canal Slack [#kubernetes-docs-pt](http://slack.kubernetes.io/) e fazer parte da equipe por trás da tradução. Você também pode acessar o canal para solicitar a tradução de uma página específica ou relatar qualquer erro que possa ter sido encontrado. Qualquer contribuição será bem recebida! diff --git a/content/pt/docs/_search.md b/content/pt-br/docs/_search.md similarity index 100% rename from content/pt/docs/_search.md rename to content/pt-br/docs/_search.md diff --git a/content/pt/docs/concepts/_index.md b/content/pt-br/docs/concepts/_index.md similarity index 100% rename from content/pt/docs/concepts/_index.md rename to content/pt-br/docs/concepts/_index.md diff --git a/content/pt/docs/concepts/architecture/_index.md b/content/pt-br/docs/concepts/architecture/_index.md old mode 100755 new mode 100644 similarity index 100% rename from content/pt/docs/concepts/architecture/_index.md rename to content/pt-br/docs/concepts/architecture/_index.md diff --git a/content/pt/docs/concepts/architecture/cloud-controller.md b/content/pt-br/docs/concepts/architecture/cloud-controller.md similarity index 100% rename from content/pt/docs/concepts/architecture/cloud-controller.md rename to content/pt-br/docs/concepts/architecture/cloud-controller.md diff --git a/content/pt/docs/concepts/architecture/master-node-communication.md b/content/pt-br/docs/concepts/architecture/control-plane-node-communication.md similarity index 66% rename from content/pt/docs/concepts/architecture/master-node-communication.md rename to content/pt-br/docs/concepts/architecture/control-plane-node-communication.md index 8cf2ad86c6..de69ad8ea8 100644 --- a/content/pt/docs/concepts/architecture/master-node-communication.md +++ b/content/pt-br/docs/concepts/architecture/control-plane-node-communication.md @@ -1,15 +1,12 @@ --- -reviewers: -- dchen1107 -- liggitt -title: Comunicação entre Node e Master +title: Comunicação entre Nó e Control Plane content_type: concept weight: 20 --- -Este documento cataloga os caminhos de comunicação entre o Master (o +Este documento cataloga os caminhos de comunicação entre o control plane (o apiserver) e o cluster Kubernetes. A intenção é permitir que os usuários personalizem sua instalação para proteger a configuração de rede então o cluster pode ser executado em uma rede não confiável (ou em IPs totalmente públicos em um @@ -20,10 +17,10 @@ provedor de nuvem). -## Cluster para o Master +## Nó para o Control Plane -Todos os caminhos de comunicação do cluster para o Master terminam no -apiserver (nenhum dos outros componentes do Master são projetados para expor +Todos os caminhos de comunicação do cluster para o control plane terminam no +apiserver (nenhum dos outros componentes do control plane são projetados para expor Serviços remotos). Em uma implantação típica, o apiserver é configurado para escutar conexões remotas em uma porta HTTPS segura (443) com uma ou mais clientes [autenticação](/docs/reference/access-authn-authz/authentication/) habilitado. Uma ou mais formas de [autorização](/docs/reference/access-authn-authz/authorization/) @@ -41,21 +38,21 @@ para provisionamento automatizado de certificados de cliente kubelet. Os pods que desejam se conectar ao apiserver podem fazê-lo com segurança, aproveitando conta de serviço para que o Kubernetes injetará automaticamente o certificado raiz público certificado e um token de portador válido no pod quando ele é instanciado. -O serviço `kubernetes` (em todos os namespaces) é configurado com um IP virtual +O serviço `kubernetes` (no namespace `default`) é configurado com um IP virtual endereço que é redirecionado (via kube-proxy) para o endpoint com HTTPS no apiserver. -Os componentes principais também se comunicam com o apiserver do cluster através da porta segura. +Os componentes do control plane também se comunicam com o apiserver do cluster através da porta segura. Como resultado, o modo de operação padrão para conexões do cluster -(nodes e pods em execução nos Nodes) para o Master é protegido por padrão -e pode passar por redes não confiáveis ​​e / ou públicas. +(nodes e pods em execução nos Nodes) para o control plane é protegido por padrão +e pode passar por redes não confiáveis ​​e/ou públicas. -## Master para o Cluster +## Control Plane para o nó -Existem dois caminhos de comunicação primários do mestre (apiserver) para o -cluster. O primeiro é do apiserver para o processo do kubelet que é executado em -cada Node no cluster. O segundo é do apiserver para qualquer Node, pod, +Existem dois caminhos de comunicação primários do control plane (apiserver) para os nós. +O primeiro é do apiserver para o processo do kubelet que é executado em +cada nó no cluster. O segundo é do apiserver para qualquer nó, pod, ou serviço através da funcionalidade de proxy do apiserver. ### apiserver para o kubelet @@ -63,8 +60,8 @@ ou serviço através da funcionalidade de proxy do apiserver. As conexões do apiserver ao kubelet são usadas para: * Buscar logs para pods. -  * Anexar (através de kubectl) pods em execução. -  * Fornecer a funcionalidade de encaminhamento de porta do kubelet. + * Anexar (através de kubectl) pods em execução. + * Fornecer a funcionalidade de encaminhamento de porta do kubelet. Essas conexões terminam no endpoint HTTPS do kubelet. Por padrão, o apiserver não verifica o certificado de serviço do kubelet, @@ -94,12 +91,18 @@ Estas conexões **não são atualmente seguras** para serem usados por redes nã ### SSH Túnel -O Kubernetes suporta túneis SSH para proteger o Servidor Master -> caminhos de comunicação no cluster. Nesta configuração, o apiserver inicia um túnel SSH para cada nó +O Kubernetes suporta túneis SSH para proteger os caminhos de comunicação do control plane para os nós. Nesta configuração, o apiserver inicia um túnel SSH para cada nó no cluster (conectando ao servidor ssh escutando na porta 22) e passa todo o tráfego destinado a um kubelet, nó, pod ou serviço através do túnel. Este túnel garante que o tráfego não seja exposto fora da rede aos quais os nós estão sendo executados. -Atualmente, os túneis SSH estão obsoletos, portanto, você não deve optar por usá-los, a menos que saiba o que está fazendo. Um substituto para este canal de comunicação está sendo projetado. +Atualmente, os túneis SSH estão obsoletos, portanto, você não deve optar por usá-los, a menos que saiba o que está fazendo. O serviço Konnectivity é um substituto para este canal de comunicação. +### Konnectivity service +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + +Como uma substituição aos túneis SSH, o serviço Konnectivity fornece proxy de nível TCP para a comunicação do control plane para o cluster. O serviço Konnectivity consiste em duas partes: o servidor Konnectivity na rede control plane e os agentes Konnectivity na rede dos nós. Os agentes Konnectivity iniciam conexões com o servidor Konnectivity e mantêm as conexões de rede. Depois de habilitar o serviço Konnectivity, todo o tráfego do control plane para os nós passa por essas conexões. + +Veja a [tarefa do Konnectivity](docs/tasks/extend-kubernetes/setup-konnectivity/) para configurar o serviço Konnectivity no seu cluster. diff --git a/content/pt/docs/concepts/architecture/controller.md b/content/pt-br/docs/concepts/architecture/controller.md similarity index 100% rename from content/pt/docs/concepts/architecture/controller.md rename to content/pt-br/docs/concepts/architecture/controller.md diff --git a/content/pt/docs/concepts/cluster-administration/_index.md b/content/pt-br/docs/concepts/cluster-administration/_index.md old mode 100755 new mode 100644 similarity index 100% rename from content/pt/docs/concepts/cluster-administration/_index.md rename to content/pt-br/docs/concepts/cluster-administration/_index.md diff --git a/content/pt-br/docs/concepts/cluster-administration/addons.md b/content/pt-br/docs/concepts/cluster-administration/addons.md new file mode 100644 index 0000000000..79b62bf832 --- /dev/null +++ b/content/pt-br/docs/concepts/cluster-administration/addons.md @@ -0,0 +1,54 @@ +--- +title: Instalando Complementos +content_type: concept +--- + + + +{{% thirdparty-content %}} + +Complementos estendem as funcionalidades do Kubernetes. + +Esta página lista alguns dos complementos disponíveis e links com suas respectivas instruções de instalação. + + + +## Rede e Política de Rede + +* [ACI](https://www.github.com/noironetworks/aci-containers) fornece rede integrada de contêineres e segurança de rede com a Cisco ACI. +* [Antrea](https://antrea.io/) opera nas camadas 3 e 4 do modelo de rede OSI para fornecer serviços de rede e de segurança para o Kubernetes, aproveitando o Open vSwitch como camada de dados de rede. +* [Calico](https://docs.projectcalico.org/latest/introduction/) é um provedor de serviços de rede e de políticas de rede. Este complemento suporta um conjunto flexível de opções de rede, de modo a permitir a escolha da opção mais eficiente para um dado caso de uso, incluindo redes _overlay_ (sobrepostas) e não-_overlay_, com ou sem o uso do protocolo BGP. Calico usa o mesmo mecanismo para aplicar políticas de rede a hosts, pods, e aplicações na camada de _service mesh_ (quando Istio e Envoy estão instalados). +* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) une Flannel e Calico, fornecendo rede e política de rede. +* [Cilium](https://github.com/cilium/cilium) é um plug-in de rede de camada 3 e de políticas de rede que pode aplicar políticas HTTP/API/camada 7 de forma transparente. Tanto o modo de roteamento quanto o de sobreposição/encapsulamento são suportados. Este plug-in também consegue operar no topo de outros plug-ins CNI. +* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) permite que o Kubernetes se conecte facilmente a uma variedade de plug-ins CNI, como Calico, Canal, Flannel, Romana ou Weave. +* [Contiv](http://contiv.github.io) oferece serviços de rede configuráveis para diferentes casos de uso (camada 3 nativa usando BGP, _overlay_ (sobreposição) usando vxlan, camada 2 clássica e Cisco-SDN/ACI) e também um _framework_ rico de políticas de rede. O projeto Contiv é totalmente [open source](http://github.com/contiv). O [instalador](http://github.com/contiv/install) fornece opções de instalação com ou sem kubeadm. +* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) é uma plataforma open source baseada no [Tungsten Fabric](https://tungsten.io) que oferece virtualização de rede multi-nuvem e gerenciamento de políticas de rede. O Contrail e o Tungsten Fabric são integrados a sistemas de orquestração de contêineres, como Kubernetes, OpenShift, OpenStack e Mesos, e fornecem modos de isolamento para cargas de trabalho executando em máquinas virtuais, contêineres/pods e servidores físicos. +* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) é um provedor de redes _overlay_ (sobrepostas) que pode ser usado com o Kubernetes. +* [Knitter](https://github.com/ZTE/Knitter/) é um plug-in para suporte de múltiplas interfaces de rede em Pods do Kubernetes. +* [Multus](https://github.com/Intel-Corp/multus-cni) é um plugin para suporte a várias interfaces de rede em Pods no Kubernetes. Este plug-in pode agir como um "meta-plug-in", ou um plug-in CNI que se comunica com múltiplos outros plug-ins CNI (por exemplo, Calico, Cilium, Contiv, Flannel), além das cargas de trabalho baseadas em SRIOV, DPDK, OVS-DPDK e VPP no Kubernetes. +* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) fornece integração entre o VMware NSX-T e sistemas de orquestração de contêineres como o Kubernetes. Além disso, oferece também integração entre o NSX-T e as plataformas CaaS/PaaS baseadas em contêiner, como o Pivotal Container Service (PKS) e o OpenShift. +* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) é uma plataforma de rede definida por software que fornece serviços de rede baseados em políticas entre os Pods do Kubernetes e os ambientes não-Kubernetes, com visibilidade e monitoramento de segurança. +* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) é um provedor de rede para o Kubernetes baseado no [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), uma implementação de redes virtuais que surgiu através do projeto Open vSwitch (OVS). O OVN-Kubernetes fornece uma implementação de rede baseada em _overlay_ (sobreposição) para o Kubernetes, incluindo uma implementação baseada em OVS para serviços de balanceamento de carga e políticas de rede. +* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) é um plug-in controlador CNI baseado no OVN (Open Virtual Network) que fornece serviços de rede _cloud native_, como _Service Function Chaining_ (SFC), redes _overlay_ (sobrepostas) OVN múltiplas, criação dinâmica de subredes, criação dinâmica de redes virtuais, provedor de rede VLAN e provedor de rede direto, e é plugável a outros plug-ins multi-rede. Ideal para cargas de trabalho que utilizam computação de borda _cloud native_ em redes multi-cluster. +* [Romana](http://romana.io) é uma solução de rede de camada 3 para redes de pods que também suporta a [API NetworkPolicy](/docs/concepts/services-networking/network-policies/). Detalhes da instalação do complemento Kubeadm disponíveis [aqui](https://github.com/romana/romana/tree/master/containerize). +* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) fornece rede e política de rede, funciona em ambos os lados de uma partição de rede e não requer um banco de dados externo. + +## Descoberta de Serviço + +* [CoreDNS](https://coredns.io) é um servidor DNS flexível e extensível que pode ser [instalado](https://github.com/coredns/deployment/tree/master/kubernetes) como o serviço de DNS dentro do cluster para ser utilizado por pods. + +## Visualização & Controle + +* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) é uma interface web para gestão do Kubernetes. +* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) é uma ferramenta gráfica para visualizar contêineres, pods, serviços, entre outros objetos do cluster. Pode ser utilizado com uma [conta Weave Cloud](https://cloud.weave.works/). Como alternativa, é possível hospedar a interface do usuário por conta própria. + +## Infraestrutura + +* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) é um complemento para executar máquinas virtuais no Kubernetes. É geralmente executado em clusters em máquina física. + + +## Complementos Legados + +Existem vários outros complementos documentados no diretório [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) que não são mais utilizados. + +Projetos bem mantidos devem ser listados aqui. PRs são bem-vindos! diff --git a/content/pt/docs/concepts/cluster-administration/certificates.md b/content/pt-br/docs/concepts/cluster-administration/certificates.md similarity index 100% rename from content/pt/docs/concepts/cluster-administration/certificates.md rename to content/pt-br/docs/concepts/cluster-administration/certificates.md diff --git a/content/pt/docs/concepts/cluster-administration/cluster-administration-overview.md b/content/pt-br/docs/concepts/cluster-administration/cluster-administration-overview.md similarity index 100% rename from content/pt/docs/concepts/cluster-administration/cluster-administration-overview.md rename to content/pt-br/docs/concepts/cluster-administration/cluster-administration-overview.md diff --git a/content/pt/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/pt-br/docs/concepts/cluster-administration/kubelet-garbage-collection.md similarity index 100% rename from content/pt/docs/concepts/cluster-administration/kubelet-garbage-collection.md rename to content/pt-br/docs/concepts/cluster-administration/kubelet-garbage-collection.md diff --git a/content/pt/docs/concepts/cluster-administration/logging.md b/content/pt-br/docs/concepts/cluster-administration/logging.md similarity index 100% rename from content/pt/docs/concepts/cluster-administration/logging.md rename to content/pt-br/docs/concepts/cluster-administration/logging.md diff --git a/content/pt/docs/concepts/cluster-administration/networking.md b/content/pt-br/docs/concepts/cluster-administration/networking.md similarity index 100% rename from content/pt/docs/concepts/cluster-administration/networking.md rename to content/pt-br/docs/concepts/cluster-administration/networking.md diff --git a/content/pt-br/docs/concepts/cluster-administration/system-logs.md b/content/pt-br/docs/concepts/cluster-administration/system-logs.md new file mode 100644 index 0000000000..fb79360821 --- /dev/null +++ b/content/pt-br/docs/concepts/cluster-administration/system-logs.md @@ -0,0 +1,132 @@ +--- +title: Logs de Sistema +content_type: concept +weight: 60 +--- + + + +Logs de componentes do sistema armazenam eventos que acontecem no cluster, sendo muito úteis para depuração. Seus níveis de detalhe podem ser ajustados para mais ou para menos. Podendo se ater, por exemplo, a mostrar apenas os erros que ocorrem no componente, ou chegando a mostrar cada passo de um evento. (Como acessos HTTP, mudanças no estado dos pods, ações dos controllers, ou decisões do scheduler). + + + +## Klog + +[Klog](https://github.com/kubernetes/klog) é a biblioteca de logs do Kubernetes. Responsável por gerar as mensagens de log para os componentes do sistema. + +Para mais informações acerca da sua configuração, veja a documentação da [ferramenta de linha de comando](https://kubernetes.io/docs/reference/command-line-tools-reference/). + +Um exemplo do formato padrão dos logs da biblioteca: +``` +I1025 00:15:15.525108 1 httplog.go:79] GET /api/v1/namespaces/kube-system/pods/metrics-server-v0.3.1-57c75779f-9p8wg: (1.512ms) 200 [pod_nanny/v0.0.0 (linux/amd64) kubernetes/$Format 10.56.1.19:51756] +``` + +### Logs Estruturados + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +{{< warning >}} +A migração pro formato de logs estruturados é um processo em andamento. Nem todos os logs estão dessa forma na versão atual. Sendo assim, para realizar o processamento de arquivos de log, você também precisa lidar com logs não estruturados. + +A formatação e serialização dos logs ainda estão sujeitas a alterações. +{{< /warning>}} + +A estruturação dos logs trás uma estrutura uniforme para as mensagens de log, permitindo a extração programática de informações. Logs estruturados podem ser armazenados e processados com menos esforço e custo. Esse formato é totalmente retrocompatível e é habilitado por padrão. + +Formato dos logs estruturados: + +```ini + "" ="" ="" ... +``` + +Exemplo: + +```ini +I1025 00:15:15.525108 1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready" +``` + + +### Logs em formato JSON + +{{< feature-state for_k8s_version="v1.19" state="alpha" >}} + +{{}} +Algumas opções da biblioteca klog ainda não funcionam com os logs em formato JSON. Para ver uma lista completa de quais são estas, veja a documentação da [ferramenta de linha de comando](/docs/reference/command-line-tools-reference/). + +Nem todos os logs estarão garantidamente em formato JSON (como por exemplo durante o início de processos). Sendo assim, se você pretende realizar o processamento dos logs, seu código deverá saber tratar também linhas que não são JSON. + +O nome dos campos e a serialização JSON ainda estão sujeitos a mudanças. +{{< /warning >}} + +A opção `--logging-format=json` muda o formato dos logs, do formato padrão da klog para JSON. Abaixo segue um exemplo de um log em formato JSON (identado): +```json +{ + "ts": 1580306777.04728, + "v": 4, + "msg": "Pod status updated", + "pod":{ + "name": "nginx-1", + "namespace": "default" + }, + "status": "ready" +} +``` + +Chaves com significados especiais: +* `ts` - Data e hora no formato Unix (obrigatório, float) +* `v` - Nível de detalhe (obrigatório, int, padrão 0) +* `err` - Mensagem de erro (opcional, string) +* `msg` - Mensagem (obrigatório, string) + +Lista dos componentes que suportam o formato JSON atualmente: +* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} +* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} +* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} + +### Limpeza dos Logs + +{{< feature-state for_k8s_version="v1.20" state="alpha" >}} + +{{}} +A funcionalidade de limpeza dos logs pode causar impactos significativos na performance, sendo portanto contraindicada em produção. +{{< /warning >}} + +A opção `--experimental-logging-sanitization` habilita o filtro de limpeza dos logs. +Quando habilitado, esse filtro inspeciona todos os argumentos dos logs, procurando por campos contendo dados sensíveis (como senhas, chaves e tokens). Tais campos não serão expostos nas mensagens de log. + +Lista dos componentes que suportam a limpeza de logs atualmente: +* {{< glossary_tooltip term_id="kube-controller-manager" text="kube-controller-manager" >}} +* {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} +* {{< glossary_tooltip term_id="kube-scheduler" text="kube-scheduler" >}} +* {{< glossary_tooltip term_id="kubelet" text="kubelet" >}} + +{{< note >}} +O filtro de limpeza dos logs não impede a exposição de dados sensíveis nos logs das aplicações em execução. +{{< /note >}} + +### Nível de detalhe dos logs + +A opção `-v` controla o nível de detalhe dos logs. Um valor maior aumenta o número de eventos registrados, começando a registrar também os eventos menos importantes. Similarmente, um valor menor restringe os logs apenas aos eventos mais importantes. O valor padrão 0 registra apenas eventos críticos. + +### Localização dos Logs + +Existem dois tipos de componentes do sistema: aqueles que são executados em um contêiner e aqueles que não são. Por exemplo: + +* O [Kubernetes scheduler](https://kubernetes.io/pt-br/docs/concepts/overview/components/#kube-scheduler) e o [kube-proxy](https://kubernetes.io/pt-br/docs/concepts/overview/components/#kube-proxy) são executados em um contêiner. +* O [kubelet](https://kubernetes.io/pt-br/docs/concepts/overview/components/#kubelet) e os [agentes de execução](https://kubernetes.io/pt-br/docs/concepts/overview/components/#container-runtime), como o Docker por exemplo, não são executados em contêineres. + +Em máquinas com systemd, o kubelet e os agentes de execução gravam os logs no journald. +Em outros casos, eles escrevem os logs em arquivos `.log` no diretório `/var/log`. +Já os componentes executados dentro de contêineres, sempre irão escrever os logs em arquivos `.log` +no diretório `/var/log`, ignorando o mecanismo padrão de log. + +De forma similar aos logs de contêiner, os logs de componentes do sistema no diretório `/var/log` devem ser rotacionados. +Nos clusters Kubernetes criados com o script `kube-up.sh`, a rotação dos logs é configurada pela ferramenta `logrotate`. Essa ferramenta rotaciona os logs diariamente +ou quando o tamanho do arquivo excede 100MB. + +## {{% heading "whatsnext" %}} + +* Leia sobre [Arquitetura de Logs do Kubernetes](/pt-br/docs/concepts/cluster-administration/logging/) +* Leia sobre [Logs Estruturados](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) +* Leia sobre [Convenções sobre os níveis de logs](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) diff --git a/content/pt/docs/concepts/configuration/_index.md b/content/pt-br/docs/concepts/configuration/_index.md similarity index 100% rename from content/pt/docs/concepts/configuration/_index.md rename to content/pt-br/docs/concepts/configuration/_index.md diff --git a/content/pt/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/pt-br/docs/concepts/configuration/organize-cluster-access-kubeconfig.md similarity index 100% rename from content/pt/docs/concepts/configuration/organize-cluster-access-kubeconfig.md rename to content/pt-br/docs/concepts/configuration/organize-cluster-access-kubeconfig.md diff --git a/content/pt-br/docs/concepts/configuration/overview.md b/content/pt-br/docs/concepts/configuration/overview.md new file mode 100644 index 0000000000..66f369c03b --- /dev/null +++ b/content/pt-br/docs/concepts/configuration/overview.md @@ -0,0 +1,126 @@ +--- +title: Melhores Práticas de Configuração +content_type: concept +weight: 10 +--- + + +Esse documento destaca e consolida as melhores práticas de configuração apresentadas em todo o guia de usuário, +na documentação de introdução e nos exemplos. + +Este é um documento vivo. Se você pensar em algo que não está nesta lista, mas pode ser útil para outras pessoas, +não hesite em criar uma *issue* ou submeter um PR. + + + +## Dicas Gerais de Configuração + +- Ao definir configurações, especifique a versão mais recente estável da API. + +- Os arquivos de configuração devem ser armazenados em um sistema de controle antes de serem enviados ao cluster. +Isso permite que você reverta rapidamente uma alteração de configuração, caso necessário. Isso também auxilia na recriação e restauração do cluster. + +- Escreva seus arquivos de configuração usando YAML ao invés de JSON. Embora esses formatos possam ser usados alternadamente em quase todos os cenários, YAML tende a ser mais amigável. + +- Agrupe objetos relacionados em um único arquivo sempre que fizer sentido. Geralmente, um arquivo é mais fácil de +gerenciar do que vários. Veja o [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) como exemplo dessa sintaxe. + +- Observe também que vários comandos `kubectl` podem ser chamados em um diretório. Por exemplo, você pode chamar +`kubectl apply` em um diretório de arquivos de configuração. + +- Não especifique valores padrões desnecessariamente: configurações simples e mínimas diminuem a possibilidade de erros. + +- Coloque descrições de objetos nas anotações para permitir uma melhor análise. + + +## "Naked" Pods comparados a ReplicaSets, Deployments, e Jobs {#naked-pods-vs-replicasets-deployments-and-jobs} + +- Se você puder evitar, não use "naked" Pods (ou seja, se você puder evitar, pods não vinculados a um [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) ou [Deployment](/docs/concepts/workloads/controllers/deployment/)). +Os "naked" pods não serão reconfigurados em caso de falha de um nó. + + Criar um Deployment, que cria um ReplicaSet para garantir que o número desejado de Pods esteja disponível e especifica uma estratégia para substituir os Pods (como [RollingUpdate](/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)), é quase sempre preferível do que criar Pods diretamente, exceto para alguns cenários explícitos de restartPolicy:Never. Um Job também pode ser apropriado. + + +## Services + +- Crie o [Service](/docs/concepts/services-networking/service/) antes de suas cargas de trabalho de backend correspondentes (Deployments ou ReplicaSets) e antes de quaisquer cargas de trabalho que precisem acessá-lo. Quando o +Kubernetes inicia um contêiner, ele fornece variáveis de ambiente apontando para todos os Services que estavam em execução quando o contêiner foi iniciado. Por exemplo, se um Service chamado `foo` existe, todos os contêineres vão +receber as seguintes variáveis em seu ambiente inicial: + + ```shell + FOO_SERVICE_HOST= + FOO_SERVICE_PORT= + ``` + +*Isso implica em um requisito de pedido* - qualquer `Service` que um `Pod` quer acessar precisa ser criado antes do `Pod` em si, ou então as variáveis de ambiente não serão populadas. O DNS não possui essa restrição. + +- Um [cluster add-on](/docs/concepts/cluster-administration/addons/) opcional (embora fortemente recomendado) é um servidor DNS. O +servidor DNS monitora a API do Kubernetes buscando novos `Services` e cria um conjunto de DNS para cada um. Se o DNS foi habilitado em todo o cluster, então todos os `Pods` devem ser capazes de fazer a resolução de `Services` automaticamente. + +- Não especifique um `hostPort` para um Pod a menos que isso seja absolutamente necessário. Quando você vincula um Pod a um `hostPort`, isso limita o número de lugares em que o Pod pode ser agendado, porque cada +combinação de <`hostIP`, `hostPort`, `protocol`> deve ser única. Se você não especificar o `hostIP` e `protocol` explicitamente, o Kubernetes vai usar `0.0.0.0` como o `hostIP` padrão e `TCP` como `protocol` padrão. + + Se você precisa de acesso a porta apenas para fins de depuração, pode usar o [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) ou o [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/). + + Se você precisa expor explicitamente a porta de um Pod no nó, considere usar um Service do tipo [NodePort](/docs/concepts/services-networking/service/#nodeport) antes de recorrer a `hostPort`. + +- Evite usar `hostNetwork` pelos mesmos motivos do `hostPort`. + +- Use [headless Services](/docs/concepts/services-networking/service/#headless-services) (que tem um `ClusterIP` ou `None`) para descoberta de serviço quando você não precisar de um balanceador de carga `kube-proxy`. +## Usando Labels + +- Defina e use [labels](/docs/concepts/overview/working-with-objects/labels/) que identifiquem _atributos semânticos_ da sua aplicação ou Deployment, como `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`. Você pode usar essas labels para selecionar os Pods apropriados para outros recursos; por exemplo, um Service que seleciona todos os Pods `tier: frontend`, ou todos +os componentes de `app: myapp`. Veja o app [guestbook](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) para exemplos dessa abordagem. + +Um Service pode ser feito para abranger vários Deployments, omitindo labels específicas de lançamento de seu seletor. Quando você +precisar atualizar um serviço em execução sem _downtime_, use um [Deployment](/docs/concepts/workloads/controllers/deployment/). + +Um estado desejado de um objeto é descrito por um Deployment, e se as alterações nesse _spec_ forem _aplicadas_ o controlador +do Deployment altera o estado real para o estado desejado em uma taxa controlada. + +- Use as [labels comuns do Kubernetes](/docs/concepts/overview/working-with-objects/common-labels/) para casos de uso comuns. +Essas labels padronizadas enriquecem os metadados de uma forma que permite que ferramentas, incluindo `kubectl` e a [dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard), funcionem de uma forma interoperável. + +- Você pode manipular labels para depuração. Como os controladores do Kubernetes (como ReplicaSet) e Services se relacionam com os Pods usando seletor de labels, remover as labels relevantes de um Pod impedirá que ele seja considerado por um controlador ou que +seja atendido pelo tráfego de um Service. Se você remover as labels de um Pod existente, seu controlador criará um novo Pod para +substituí-lo. Essa é uma maneira útil de depurar um Pod anteriormente "ativo" em um ambiente de "quarentena". Para remover ou +alterar labels interativamente, use [`kubectl label`](/docs/reference/generated/kubectl/kubectl-commands#label). + + +## Imagens de Contêiner + +A [imagePullPolicy](/docs/concepts/containers/images/#updating-images) e tag da imagem afetam quando o [kubelet](/docs/reference/command-line-tools-reference/kubelet/) tenta puxar a imagem especificada. + +- `imagePullPolicy: IfNotPresent`: a imagem é puxada apenas se ainda não estiver presente localmente. + +- `imagePullPolicy: Always`: sempre que o kubelet inicia um contêiner, ele consulta o *registry* da imagem do contêiner para verificar o resumo de assinatura da imagem. Se o kubelet tiver uma imagem do contêiner com o mesmo resumo de assinatura +armazenado em cache localmente, o kubelet usará a imagem em cache, caso contrário, o kubelet baixa(*pulls*) a imagem com o resumo de assinatura resolvido, e usa essa imagem para iniciar o contêiner. + +- `imagePullPolicy` é omitido se a tag da imagem é `:latest` ou se `imagePullPolicy` é omitido é automaticamente definido como `Always`. Observe que _não_ será utilizado para `ifNotPresent`se o valor da tag mudar. + +- `imagePullPolicy` é omitido se uma tag da imagem existe mas não `:latest`: `imagePullPolicy` é automaticamente definido como `ifNotPresent`. Observe que isto _não_ será atualizado para `Always` se a tag for removida ou alterada para `:latest`. + +- `imagePullPolicy: Never`: presume-se que a imagem exista localmente. Não é feita nenhuma tentativa de puxar a imagem. + +{{< note >}} +Para garantir que seu contêiner sempre use a mesma versão de uma imagem, você pode especificar seu [resumo de assinatura](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier); +substitua `:` por `@` (por exemplo, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`). Esse resumo de assinatura identifica exclusivamente uma versão +específica de uma imagem, então isso nunca vai ser atualizado pelo Kubernetes a menos que você mude o valor do resumo de assinatura da imagem. +{{< /note >}} + +{{< note >}} +Você deve evitar o uso da tag `:latest` em produção, pois é mais difícil rastrear qual versão da imagem está sendo executada e mais difícil reverter adequadamente. +{{< /note >}} + +{{< note >}} +A semântica de cache do provedor de imagem subjacente torna até mesmo `imagePullPolicy: Always` eficiente, contanto que o registro esteja acessível de forma confiável. Com o Docker, por exemplo, se a imagem já existe, a tentativa de baixar(pull) é rápida porque todas as camadas da imagem são armazenadas em cache e nenhum download de imagem é necessário. +{{< /note >}} + +## Usando kubectl + +- Use `kubectl apply -f `. Isso procura por configurações do Kubernetes em todos os arquivos `.yaml`, `.yml` em `` e passa isso para `apply`. + +- Use *labels selectors* para operações `get` e `delete` em vez de nomes de objetos específicos. Consulte as seções sobre [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors) +e [usando Labels efetivamente](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively). + +- Use `kubectl create deployment` e `kubectl expose` para criar rapidamente Deployments e Services de um único contêiner. Consulte [Use um Service para acessar uma aplicação em um cluster](/docs/tasks/access-application-cluster/service-access-application-cluster/) para obter um exemplo. diff --git a/content/pt/docs/concepts/containers/_index.md b/content/pt-br/docs/concepts/containers/_index.md similarity index 100% rename from content/pt/docs/concepts/containers/_index.md rename to content/pt-br/docs/concepts/containers/_index.md diff --git a/content/pt/docs/concepts/containers/container-environment.md b/content/pt-br/docs/concepts/containers/container-environment.md similarity index 100% rename from content/pt/docs/concepts/containers/container-environment.md rename to content/pt-br/docs/concepts/containers/container-environment.md diff --git a/content/pt/docs/concepts/containers/container-lifecycle-hooks.md b/content/pt-br/docs/concepts/containers/container-lifecycle-hooks.md similarity index 100% rename from content/pt/docs/concepts/containers/container-lifecycle-hooks.md rename to content/pt-br/docs/concepts/containers/container-lifecycle-hooks.md diff --git a/content/pt/docs/concepts/containers/images.md b/content/pt-br/docs/concepts/containers/images.md similarity index 100% rename from content/pt/docs/concepts/containers/images.md rename to content/pt-br/docs/concepts/containers/images.md diff --git a/content/pt/docs/concepts/containers/runtime-class.md b/content/pt-br/docs/concepts/containers/runtime-class.md similarity index 99% rename from content/pt/docs/concepts/containers/runtime-class.md rename to content/pt-br/docs/concepts/containers/runtime-class.md index 70e42a78f0..8f6e33aeee 100644 --- a/content/pt/docs/concepts/containers/runtime-class.md +++ b/content/pt-br/docs/concepts/containers/runtime-class.md @@ -112,7 +112,7 @@ Agentes de execução são configurados através da configuração do containerd `/etc/containerd/config.toml`. Agentes válidos são configurados sob a seção de `runtimes`: ``` -[plugins.cri.containerd.runtimes.${HANDLER_NAME}] +[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}] ``` Veja a documentação de configuração do containerd para maiores detalhes: diff --git a/content/pt/docs/concepts/extend-kubernetes/_index.md b/content/pt-br/docs/concepts/extend-kubernetes/_index.md similarity index 100% rename from content/pt/docs/concepts/extend-kubernetes/_index.md rename to content/pt-br/docs/concepts/extend-kubernetes/_index.md diff --git a/content/pt/docs/concepts/extend-kubernetes/api-extension/_index.md b/content/pt-br/docs/concepts/extend-kubernetes/api-extension/_index.md similarity index 100% rename from content/pt/docs/concepts/extend-kubernetes/api-extension/_index.md rename to content/pt-br/docs/concepts/extend-kubernetes/api-extension/_index.md diff --git a/content/pt/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/pt-br/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md similarity index 100% rename from content/pt/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md rename to content/pt-br/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md diff --git a/content/pt/docs/concepts/extend-kubernetes/compute-storage-net/_index.md b/content/pt-br/docs/concepts/extend-kubernetes/compute-storage-net/_index.md similarity index 100% rename from content/pt/docs/concepts/extend-kubernetes/compute-storage-net/_index.md rename to content/pt-br/docs/concepts/extend-kubernetes/compute-storage-net/_index.md diff --git a/content/pt/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/pt-br/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md similarity index 100% rename from content/pt/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md rename to content/pt-br/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md diff --git a/content/pt/docs/concepts/extend-kubernetes/operator.md b/content/pt-br/docs/concepts/extend-kubernetes/operator.md similarity index 97% rename from content/pt/docs/concepts/extend-kubernetes/operator.md rename to content/pt-br/docs/concepts/extend-kubernetes/operator.md index ba20161490..627bcbfbb8 100644 --- a/content/pt/docs/concepts/extend-kubernetes/operator.md +++ b/content/pt-br/docs/concepts/extend-kubernetes/operator.md @@ -52,7 +52,7 @@ Algumas das coisas que um operador pode ser usado para automatizar incluem: como esquemas de base de dados ou definições de configuração extra * publicar um *Service* para aplicações que não suportam a APIs do Kubernetes para as descobrir -* simular una falha em todo ou parte do cluster de forma a testar a resiliência +* simular uma falha em todo ou parte do cluster de forma a testar a resiliência * escolher um lider para uma aplicação distribuída sem um processo de eleição de membro interno @@ -128,7 +128,7 @@ que pode atuar como um [cliente da API do Kubernetes](/docs/reference/using-api/ * Use ferramentes existentes para escrever os seus Operadores: * usando [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) * usando [kubebuilder](https://book.kubebuilder.io/) - * usando [Metacontroller](https://metacontroller.app/) juntamente com WebHooks que + * usando [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html) juntamente com WebHooks que implementa você mesmo * usando o [Operator Framework](https://github.com/operator-framework/getting-started) * [Publique](https://operatorhub.io/) o seu operador para que outras pessoas o possam usar diff --git a/content/pt/docs/concepts/overview/_index.md b/content/pt-br/docs/concepts/overview/_index.md similarity index 100% rename from content/pt/docs/concepts/overview/_index.md rename to content/pt-br/docs/concepts/overview/_index.md diff --git a/content/pt/docs/concepts/overview/components.md b/content/pt-br/docs/concepts/overview/components.md similarity index 100% rename from content/pt/docs/concepts/overview/components.md rename to content/pt-br/docs/concepts/overview/components.md diff --git a/content/pt/docs/concepts/overview/what-is-kubernetes.md b/content/pt-br/docs/concepts/overview/what-is-kubernetes.md similarity index 99% rename from content/pt/docs/concepts/overview/what-is-kubernetes.md rename to content/pt-br/docs/concepts/overview/what-is-kubernetes.md index 29473a7f75..4a072c01d2 100644 --- a/content/pt/docs/concepts/overview/what-is-kubernetes.md +++ b/content/pt-br/docs/concepts/overview/what-is-kubernetes.md @@ -90,5 +90,5 @@ Kubernetes: ## {{% heading "whatsnext" %}} -* Dê uma olhada em [Componentes do Kubernetes](/docs/concepts/overview/components/). +* Dê uma olhada em [Componentes do Kubernetes](/pt-br/docs/concepts/overview/components/). * Pronto para [Iniciar](/docs/setup/)? diff --git a/content/pt/docs/concepts/overview/working-with-objects/_index.md b/content/pt-br/docs/concepts/overview/working-with-objects/_index.md old mode 100755 new mode 100644 similarity index 100% rename from content/pt/docs/concepts/overview/working-with-objects/_index.md rename to content/pt-br/docs/concepts/overview/working-with-objects/_index.md diff --git a/content/pt/docs/concepts/overview/working-with-objects/names.md b/content/pt-br/docs/concepts/overview/working-with-objects/names.md similarity index 100% rename from content/pt/docs/concepts/overview/working-with-objects/names.md rename to content/pt-br/docs/concepts/overview/working-with-objects/names.md diff --git a/content/pt/docs/concepts/scheduling-eviction/_index.md b/content/pt-br/docs/concepts/scheduling-eviction/_index.md similarity index 100% rename from content/pt/docs/concepts/scheduling-eviction/_index.md rename to content/pt-br/docs/concepts/scheduling-eviction/_index.md diff --git a/content/pt/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/pt-br/docs/concepts/scheduling-eviction/kube-scheduler.md similarity index 100% rename from content/pt/docs/concepts/scheduling-eviction/kube-scheduler.md rename to content/pt-br/docs/concepts/scheduling-eviction/kube-scheduler.md diff --git a/content/pt/docs/concepts/scheduling-eviction/pod-overhead.md b/content/pt-br/docs/concepts/scheduling-eviction/pod-overhead.md similarity index 100% rename from content/pt/docs/concepts/scheduling-eviction/pod-overhead.md rename to content/pt-br/docs/concepts/scheduling-eviction/pod-overhead.md diff --git a/content/pt/docs/concepts/security/_index.md b/content/pt-br/docs/concepts/security/_index.md similarity index 100% rename from content/pt/docs/concepts/security/_index.md rename to content/pt-br/docs/concepts/security/_index.md diff --git a/content/pt/docs/concepts/security/overview.md b/content/pt-br/docs/concepts/security/overview.md similarity index 100% rename from content/pt/docs/concepts/security/overview.md rename to content/pt-br/docs/concepts/security/overview.md diff --git a/content/pt-br/docs/concepts/services-networking/_index.md b/content/pt-br/docs/concepts/services-networking/_index.md new file mode 100755 index 0000000000..cbe38ae33a --- /dev/null +++ b/content/pt-br/docs/concepts/services-networking/_index.md @@ -0,0 +1,14 @@ +--- +title: "Serviços, balanceamento de carga e conectividade" +weight: 60 +description: > + Conceitos e recursos por trás da conectividade no Kubernetes. +--- + +A conectividade do Kubernetes trata quatro preocupações: +- Contêineres em um Pod se comunicam via interface _loopback_. +- A conectividade do cluster provê a comunicação entre diferentes Pods. +- O recurso de _Service_ permite a você expor uma aplicação executando em um Pod, +de forma a ser alcançável de fora de seu cluster. +- Você também pode usar os _Services_ para publicar serviços de consumo interno do +seu cluster. diff --git a/content/pt-br/docs/concepts/services-networking/network-policies.md b/content/pt-br/docs/concepts/services-networking/network-policies.md new file mode 100644 index 0000000000..2c45902e40 --- /dev/null +++ b/content/pt-br/docs/concepts/services-networking/network-policies.md @@ -0,0 +1,345 @@ +--- +title: Políticas de rede +content_type: concept +weight: 50 +--- + + + +Se você deseja controlar o fluxo do tráfego de rede no nível do endereço IP ou de portas TCP e UDP +(camadas OSI 3 e 4) então você deve considerar usar Políticas de rede (`NetworkPolicies`) do Kubernetes para aplicações +no seu cluster. `NetworkPolicy` é um objeto focado em aplicações/experiência do desenvolvedor +que permite especificar como é permitido a um {{< glossary_tooltip text="pod" term_id="pod">}} +comunicar-se com várias "entidades" de rede. + +As entidades que um Pod pode se comunicar são identificadas através de uma combinação dos 3 +identificadores à seguir: + +1. Outros pods que são permitidos (exceção: um pod não pode bloquear a si próprio) +2. Namespaces que são permitidos +3. Blocos de IP (exceção: o tráfego de e para o nó que um Pod está executando sempre é permitido, +independentemente do endereço IP do Pod ou do Nó) + +Quando definimos uma política de rede baseada em pod ou namespace, utiliza-se um {{< glossary_tooltip text="selector" term_id="selector">}} +para especificar qual tráfego é permitido de e para o(s) Pod(s) que correspondem ao seletor. + +Quando uma política de redes baseada em IP é criada, nós definimos a política baseada em blocos de IP (faixas CIDR). + + +## Pré requisitos + +As políticas de rede são implementadas pelo [plugin de redes](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Para usar +uma política de redes, você deve usar uma solução de redes que suporte o objeto `NetworkPolicy`. +A criação de um objeto `NetworkPolicy` sem um controlador que implemente essas regras não tem efeito. + +## Pods isolados e não isolados + +Por padrão, pods não são isolados; eles aceitam tráfego de qualquer origem. + +Os pods tornam-se isolados ao existir uma `NetworkPolicy` que selecione eles. Uma vez que +exista qualquer `NetworkPolicy` no namespace selecionando um pod em específico, aquele pod +irá rejeitar qualquer conexão não permitida por qualquer `NetworkPolicy`. (Outros pod no mesmo +namespace que não são selecionados por nenhuma outra `NetworkPolicy` irão continuar aceitando +todo tráfego de rede.) + +As políticas de rede não conflitam; elas são aditivas. Se qualquer política selecionar um pod, +o pod torna-se restrito ao que é permitido pela união das regras de entrada/saída de tráfego definidas +nas políticas. Assim, a ordem de avaliação não afeta o resultado da política. + +Para o fluxo de rede entre dois pods ser permitido, tanto a política de saída no pod de origem +e a política de entrada no pod de destino devem permitir o tráfego. Se a política de saída na +origem, ou a política de entrada no destino negar o tráfego, o tráfego será bloqueado. + +## O recurso NetworkPolicy {#networkpolicy-resource} + +Veja a referência [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) para uma definição completa do recurso. + +Uma `NetworkPolicy` de exemplo é similar ao abaixo: + +```yaml +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: test-network-policy + namespace: default +spec: + podSelector: + matchLabels: + role: db + policyTypes: + - Ingress + - Egress + ingress: + - from: + - ipBlock: + cidr: 172.17.0.0/16 + except: + - 172.17.1.0/24 + - namespaceSelector: + matchLabels: + project: myproject + - podSelector: + matchLabels: + role: frontend + ports: + - protocol: TCP + port: 6379 + egress: + - to: + - ipBlock: + cidr: 10.0.0.0/24 + ports: + - protocol: TCP + port: 5978 +``` + +{{< note >}} +Criar esse objeto no seu cluster não terá efeito a não ser que você escolha uma +solução de redes que suporte políticas de rede. +{{< /note >}} + +__Campos obrigatórios__: Assim como todas as outras configurações do Kubernetes, uma `NetworkPolicy` +necessita dos campos `apiVersion`, `kind` e `metadata`. Para maiores informações sobre +trabalhar com arquivos de configuração, veja +[Configurando containeres usando ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), +e [Gerenciamento de objetos](/docs/concepts/overview/working-with-objects/object-management). + +__spec__: A [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) contém todas as informações necessárias +para definir uma política de redes em um namespace. + +__podSelector__: Cada `NetworkPolicy` inclui um `podSelector` que seleciona o grupo de pods +que a política se aplica. A política acima seleciona os pods com a _label_ "role=db". Um `podSelector` +vazio seleciona todos os pods no namespace. + +__policyTypes__: Cada `NetworkPolicy` inclui uma lista de `policyTypes` que pode incluir `Ingress`, +`Egress` ou ambos. O campo `policyTypes` indica se a política se aplica ao tráfego de entrada +com destino aos pods selecionados, o tráfego de saída com origem dos pods selecionados ou ambos. +Se nenhum `policyType` for definido então por padrão o tipo `Ingress` será sempre utilizado, e o +tipo `Egress` será configurado apenas se o objeto contiver alguma regra de saída. (campo `egress` a seguir). + +__ingress__: Cada `NetworkPolicy` pode incluir uma lista de regras de entrada permitidas através do campo `ingress`. +Cada regra permite o tráfego que corresponde simultaneamente às sessões `from` (de) e `ports` (portas). +A política de exemplo acima contém uma regra simples, que corresponde ao tráfego em uma única porta, +de uma das três origens definidas, sendo a primeira definida via `ipBlock`, a segunda via `namespaceSelector` e +a terceira via `podSelector`. + +__egress__: Cada política pode incluir uma lista de regras de regras de saída permitidas através do campo `egress`. +Cada regra permite o tráfego que corresponde simultaneamente às sessões `to` (para) e `ports` (portas). +A política de exemplo acima contém uma regra simples, que corresponde ao tráfego destinado a uma +porta em qualquer destino pertencente à faixa de IPs em `10.0.0.0/24`. + +Então a `NetworkPolicy` acima: + +1. Isola os pods no namespace "default" com a _label_ "role=db" para ambos os tráfegos de entrada +e saída (se eles ainda não estavam isolados) +2. (Regras de entrada/ingress) permite conexões para todos os pods no namespace "default" com a _label_ "role=db" na porta TCP 6379 de: + + * qualquer pod no namespace "default" com a _label_ "role=frontend" + * qualquer pod em um namespace que tenha a _label_ "project=myproject" (aqui cabe ressaltar que o namespace que deve ter a _label_ e não os pods dentro desse namespace) + * IPs dentro das faixas 172.17.0.0–172.17.0.255 e 172.17.2.0–172.17.255.255 (ex.:, toda 172.17.0.0/16 exceto 172.17.1.0/24) + +3. (Regras de saída/egress) permite conexões de qualquer pod no namespace "default" com a _label_ +"role=db" para a faixa de destino 10.0.0.0/24 na porta TCP 5978. + +Veja o tutorial [Declarando uma política de redes](/docs/tasks/administer-cluster/declare-network-policy/) para mais exemplos. + +## Comportamento dos seletores `to` e `from` + +Existem quatro tipos de seletores que podem ser especificados nas sessões `ingress.from` ou +`egress.to`: + +__podSelector__: Seleciona Pods no mesmo namespace que a política de rede foi criada, e que deve +ser permitido origens no tráfego de entrada ou destinos no tráfego de saída. + +__namespaceSelector__: Seleciona namespaces para o qual todos os Pods devem ser permitidos como +origens no caso de tráfego de entrada ou destino no tráfego de saída. + +__namespaceSelector__ *e* __podSelector__: Uma entrada `to`/`from` única que permite especificar +ambos `namespaceSelector` e `podSelector` e seleciona um conjunto de Pods dentro de um namespace. +Seja cuidadoso em utilizar a sintaxe YAML correta; essa política: + +```yaml + ... + ingress: + - from: + - namespaceSelector: + matchLabels: + user: alice + podSelector: + matchLabels: + role: client + ... +``` +contém um único elemento `from` permitindo conexões de Pods com a label `role=client` em +namespaces com a _label_ `user=alice`. Mas *essa* política: + +```yaml + ... + ingress: + - from: + - namespaceSelector: + matchLabels: + user: alice + - podSelector: + matchLabels: + role: client + ... +``` + +contém dois elementos no conjunto `from` e permite conexões de Pods no namespace local com +a _label_ `role=client`, *OU* de qualquer outro Pod em qualquer outro namespace que tenha +a label `user=alice`. + +Quando estiver em dúvida, utilize o comando `kubectl describe` para verificar como o +Kubernetes interpretou a política. + +__ipBlock__: Isso seleciona um conjunto particular de faixas de IP a serem permitidos como +origens no caso de entrada ou destinos no caso de saída. Devem ser considerados IPs externos +ao cluster, uma vez que os IPs dos Pods são efêmeros e imprevisíveis. + +Os mecanismos de entrada e saída do cluster geralmente requerem que os IPs de origem ou destino +sejam reescritos. Em casos em que isso aconteça, não é definido se deve acontecer antes ou +depois do processamento da `NetworkPolicy` que corresponde a esse tráfego, e o comportamento +pode ser diferente para cada plugin de rede, provedor de nuvem, implementação de `Service`, etc. + +No caso de tráfego de entrada, isso significa que em alguns casos você pode filtrar os pacotes +de entrada baseado no IP de origem atual, enquanto que em outros casos o IP de origem que +a `NetworkPolicy` atua pode ser o IP de um `LoadBalancer` ou do Nó em que o Pod está executando. + +No caso de tráfego de saída, isso significa que conexões de Pods para `Services` que são reescritos +para IPs externos ao cluster podem ou não estar sujeitos a políticas baseadas no campo `ipBlock`. + +## Políticas padrão + +Por padrão, se nenhuma política existir no namespace, então todo o tráfego de entrada e saída é +permitido de e para os pods nesse namespace. Os exemplos a seguir permitem a você mudar o +comportamento padrão nesse namespace. + +### Bloqueio padrão de todo tráfego de entrada + +Você pode criar uma política padrão de isolamento para um namespace criando um objeto `NetworkPolicy` +que seleciona todos os pods mas não permite o tráfego de entrada para esses pods. + +{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} + +Isso garante que mesmo pods que não são selecionados por nenhuma outra política de rede ainda +serão isolados. Essa política não muda o comportamento padrão de isolamento de tráfego de saída +nesse namespace. + +### Permitir por padrão todo tráfego de entrada + +Se você deseja permitir todo o tráfego de todos os pods em um namespace (mesmo que políticas que +sejam adicionadas faça com que alguns pods sejam tratados como "isolados"), você pode criar +uma política que permite explicitamente todo o tráfego naquele namespace. + +{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} + +### Bloqueio padrão de todo tráfego de saída + +Você pode criar uma política de isolamento de saída padrão para um namespace criando uma +política de redes que selecione todos os pods, mas não permita o tráfego de saída a partir +de nenhum desses pods. + +{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} + +Isso garante que mesmo pods que não são selecionados por outra política de rede não seja permitido +tráfego de saída. Essa política não muda o comportamento padrão de tráfego de entrada. + +### Permitir por padrão todo tráfego de saída + +Caso você queira permitir todo o tráfego de todos os pods em um namespace (mesmo que políticas sejam +adicionadas e cause com que alguns pods sejam tratados como "isolados"), você pode criar uma +política explicita que permite todo o tráfego de saída no namespace. + +{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} + +### Bloqueio padrão de todo tráfego de entrada e saída + +Você pode criar uma política padrão em um namespace que previne todo o tráfego de entrada +E saída criando a política a seguir no namespace. + +{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} + +Isso garante que mesmo pods que não são selecionados por nenhuma outra política de redes não +possuam permissão de tráfego de entrada ou saída. + +## Selecionando uma faixa de portas + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +Ao escrever uma política de redes, você pode selecionar uma faixa de portas ao invés de uma +porta única, utilizando-se do campo `endPort` conforme a seguir: + +```yaml +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: multi-port-egress + namespace: default +spec: + podSelector: + matchLabels: + role: db + policyTypes: + - Egress + egress: + - to: + - ipBlock: + cidr: 10.0.0.0/24 + ports: + - protocol: TCP + port: 32000 + endPort: 32768 +``` + +A regra acima permite a qualquer Pod com a _label_ "role=db" no namespace `default` de se comunicar +com qualquer IP na faixa `10.0.0.0/24` através de protocolo TCP, desde que a porta de destino +esteja na faixa entre 32000 e 32768. + +As seguintes restrições aplicam-se ao se utilizar esse campo: + +* Por ser uma funcionalidade "alpha", ela é desativada por padrão. Para habilitar o campo `endPort` +no cluster, você (ou o seu administrador do cluster) deve habilitar o [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `NetworkPolicyEndPort` no `kube-apiserver` com a flag `--feature-gates=NetworkPolicyEndPort=true,...`. +* O valor de `endPort` deve ser igual ou maior ao valor do campo `port`. +* O campo `endPort` só pode ser definido se o campo `port` também for definido. +* Ambos os campos `port` e `endPort` devem ser números. + +{{< note >}} +Seu cluster deve utilizar um plugin {{< glossary_tooltip text="CNI" term_id="cni" >}} +que suporte o campo `endPort` na especificação da política de redes. +{{< /note >}} + +## Selecionando um Namespace pelo seu nome + +{{< feature-state state="beta" for_k8s_version="1.21" >}} + +A camada de gerenciamento do Kubernetes configura uma _label_ imutável `kubernetes.io/metadata.name` em +todos os namespaces, uma vez que o [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) esteja habilitado por padrão. +O valor dessa _label_ é o nome do namespace. + +Enquanto que um objeto `NetworkPolicy` não pode selecionar um namespace pelo seu nome através de +um campo específico, você pode utilizar essa _label_ padrão para selecionar um namespace pelo seu nome. + +## O que você não pode fazer com `NetworkPolicies` (ao menos por enquanto!) +Por enquanto no Kubernetes {{< skew latestVersion >}} as funcionalidades a seguir não existem +mas você pode conseguir implementar de forma alternativa utilizando componentes do Sistema Operacional +(como SELinux, OpenVSwitch, IPtables, etc) ou tecnologias da camada 7 OSI (Ingress controllers, implementações de service mesh) ou ainda _admission controllers_. +No caso do assunto "segurança de redes no Kubernetes" ser novo para você, vale notar que as +histórias de usuário a seguir ainda não podem ser implementadas: + +- Forçar o tráfego interno do cluster passar por um gateway comum (pode ser implementado via service mesh ou outros proxies) +- Qualquer coisa relacionada a TLS/mTLS (use um service mesh ou ingress controller para isso) +- Políticas específicas a nível do nó kubernetes (você pode utilizar as notações de IP CIDR para isso, mas não pode selecionar nós Kubernetes por suas identidades) +- Selecionar `Services` pelo seu nome (você pode, contudo, selecionar pods e namespaces por seus {{< glossary_tooltip text="labels" term_id="label" >}} o que torna-se uma solução de contorno viável). +- Criação ou gerenciamento +- Políticas padrão que são aplicadas a todos os namespaces e pods (existem alguns plugins externos do Kubernetes e projetos que podem fazer isso, e a comunidade está trabalhando nessa especificação). +- Ferramental de testes para validação de políticas de redes. +- Possibilidade de logar eventos de segurança de redes (conexões bloqueadas, aceitas). Existem plugins CNI que conseguem fazer isso à parte. +- Possibilidade de explicitamente negar políticas de rede (o modelo das `NetworkPolicies` são "negar por padrão e conforme a necessidade, deve-se adicionar regras que permitam o tráfego). +- Bloquear o tráfego que venha da interface de loopback/localhost ou que venham do nó em que o Pod se encontre. + +## {{% heading "whatsnext" %}} + + +- Veja o tutorial [Declarando políticas de redes](/docs/tasks/administer-cluster/declare-network-policy/) para mais exemplos. +- Veja mais [cenários comuns e exemplos](https://github.com/ahmetb/kubernetes-network-policy-recipes) de políticas de redes. diff --git a/content/pt-br/docs/concepts/storage/persistent-volumes.md b/content/pt-br/docs/concepts/storage/persistent-volumes.md new file mode 100644 index 0000000000..65396a3c37 --- /dev/null +++ b/content/pt-br/docs/concepts/storage/persistent-volumes.md @@ -0,0 +1,738 @@ +--- +reviewers: +- jsafrane +- saad-ali +- thockin +- msau42 +- xing-yang +title: Volumes Persistentes +feature: + title: Orquestração de Armazenamento + description: > + Montar automaticamente o armazenamento de sua escolha, seja de um armazenamento local, de um provedor de cloud pública, como GCP ou AWS, ou um armazenameto de rede, como NFS, iSCSI, Gluster, Ceph, Cinder ou Flocker. + +content_type: conceito +weight: 20 +--- + + + +Esse documento descreve o estado atual dos _volumes persistentes_ no Kubernetes. Sugerimos que esteja familiarizado com [volumes](/docs/concepts/storage/volumes/). + + + +## Introdução + + +O gerenciamento de armazenamento é uma questão bem diferente do gerenciamento de instâncias computacionais. O subsistema PersistentVolume provê uma API para usuários e administradores que mostra de forma detalhada de como o armazenamento é provido e como ele é consumido. Para isso, nós introduzimos duas novas APIs: PersistentVolume e PersistentVolumeClaim. + +Um _PersistentVolume_ (PV) é uma parte do armazenamento dentro do cluster que tenha sido provisionada por um administrador, ou dinamicamente utilizando [Classes de Armazenamento](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó também é. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do armazenamento, seja ele NFS, iSCSI, ou um armazenamento específico de um provedor de cloud pública. + +Uma_PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem solicitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [Modos de Acesso](#modos-de-acesso)). + +Enquanto as PersistentVolumeClaims permitem que um usuário utilize recursos de armazenamento de forma limitada, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como desempenho, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que difiram em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essas, temos o recurso de _StorageClass_. + +Veja os [exemplos de passo a passo de forma detalhada](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/). + +## Requisição e ciclo de vida de um volume + +PVs são recursos dentro um cluster. PVCs são requisições para esses recursos e também atuam como uma validação da solicitação desses recursos. O ciclo de vida da interação entre PVs e PVCs funcionam da seguinte forma: + +### Provisionamento + +Existem duas formas de provisionar um PV: estaticamente ou dinamicamente. + +#### Estático + +O administrador do cluster cria uma determinada quantidade de PVs. Eles possuem todos os detalhes do armazenamento os quais estão atrelados, que neste caso fica disponível para utilização por um usuário dentro do cluster. Eles estão presentes na API do Kubernetes e disponíveis para utilização. + +#### Dinâmico + +Quando nenhum dos PVs estáticos, que foram criados anteriormente pelo administrador, satisfazem os critérios de uma PersistentVolumeClaim enviado por um usuário, o cluster pode tentar realizar um provisionamento dinâmico para atender a essa PVC. Esse provisionamento é baseado em StorageClasses: a PVC deve solicitar uma [classe de armazenamento](/docs/concepts/storage/storage-classes/) e o administrador deve ter previamente criado e configurado essa classe para que o provisionamento dinâmico possa ocorrer. Requisições que solicitam a classe `""` efetivamente desabilitam o provisionamento dinâmico para elas mesmas. + +Para habilitar o provisionamento de armazenamento dinâmico baseado em classe de armazenamento, o administrador do cluster precisa habilitar o [controle de admissão](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` no servidor da API. Isso pode ser feito, por exemplo, garantindo que `DefaultStorageClass` esteja entre aspas simples, ordenado por uma lista de valores para a flag `--enable-admission-plugins`, componente do servidor da API. Para mais informações sobre os comandos das flags do servidor da API, consulte a documentação [kube-apiserver](/docs/admin/kube-apiserver/). + +### Binding + +Um usuário cria, ou em caso de um provisionamento dinâmico já ter criado, uma PersistentVolumeClaim solicitando uma quantidade específica de armazenamento e um determinado modo de acesso. Um controle de loop no master monitora por novas PVCs, encontra um PV (se possível) que satisfaça os requisitos e realiza o bind. Se o PV foi provisionado dinamicamente por uma PVC, o loop sempre vai fazer o bind desse PV com essa PVC em específico. Caso contrário, o usuário vai receber no mínimo o que ele havia solicitado, porém, o volume possa exceder em relação à solicitação inicial. Uma vez realizado esse processo, PersistentVolumeClaim sempre vai ter um bind exclusivo, sem levar em conta como o isso aconteceu. Um bind entre uma PVC e um PV é um mapeamento de um para um, utilizando o ClaimRef que é um bind bidirecional entre o PersistentVolume e o PersistentVolumeClaim. + +As requisições permanecerão sem bind se o volume solicitado não existir. O bind ocorrerá somente se os requisitos forem atendidos exatamente da mesma forma como solicitado. Por exemplo, um bind de uma PVC de 100 GB não ocorrerá num cluster que foi provisionado com vários PVs de 50 GB. O bind ocorrerá somente no momento em que um PV de 100 GB for adicionado. + +### Utilização + +Pods utilizam requisições como volumes. O cluster inspeciona a requisição para encontrar o volume atrelado a ela e monta esse volume para um Pod. Para volumes que suportam múltiplos modos de acesso, o usuário especifica qual o modo desejado quando utiliza essas requisições. + +Uma vez que o usuário tem a requisição atrelada a um PV, ele pertence ao usuário pelo tempo que ele precisar. Usuários agendam Pods e acessam seus PVs requisitados através da seção `persistentVolumeClaim` no bloco `volumes` do Pod. Para mais detalhes sobre isso, veja [Requisições como Volumes](#requisições-como-volumes). + +### Proteção de Uso de um Objeto de Armazenamento + +O propósito da funcionalidade do Objeto de Armazenamento em Proteção de Uso é garantir que as PersistentVolumeClaims (PVCs) que estejam sendo utilizadas por um Pod e PersistentVolume (PVs) que pertençam aos PVCs não sejam removidos do sistema, pois isso pode resultar numa perda de dados. + +{{< note >}} +Uma PVC está sendo utilizada por um Pod quando existe um Pod que está usando essa PVC. +{{< /note >}} + +Se um usuário deleta uma PVC que está sendo utilizada por um Pod, esta PVC não é removida imediatamente. A remoção da PVC é adiada até que a PVC não esteja mais sendo utilizado por nenhum Pod. Se um administrador deleta um PV que está atrelado a uma PVC, o PV não é removido imediatamente também. A remoção do PV é adiada até que o PV não esteja mais atrelado à PVC. + +Note que uma PVC é protegida quando o status da PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pvc-protection`: + +```shell +kubectl describe pvc hostpath +Name: hostpath +Namespace: default +StorageClass: example-hostpath +Status: Terminating +Volume: +Labels: +Annotations: volume.beta.kubernetes.io/storage-class=example-hostpath + volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath +Finalizers: [kubernetes.io/pvc-protection] +... +``` + +Note que um PV é protegido quando o status da PVC é `Terminating` e a lista `Finalizers` contém `kubernetes.io/pv-protection` também: + +```shell +kubectl describe pv task-pv-volume +Name: task-pv-volume +Labels: type=local +Annotations: +Finalizers: [kubernetes.io/pv-protection] +StorageClass: standard +Status: Terminating +Claim: +Reclaim Policy: Delete +Access Modes: RWO +Capacity: 1Gi +Message: +Source: + Type: HostPath (bare host directory volume) + Path: /tmp/data + HostPathType: +Events: +``` + +### Recuperação + +Quando um usuário não precisar mais utilizar um volume, ele pode deletar a PVC pela API, que, permite a recuperação do recurso. A política de recuperação para um PersistentVolume diz ao cluster o que fazer com o volume após ele ter sido liberado da sua requisição. Atualmente, volumes podem ser Retidos, Reciclados ou Deletados. + +#### Retenção + +A política `Retain` permite a recuperação de forma manual do recurso. Quando a PersistentVolumeClaim é deletada, ela continua existindo e o volume é considerado "livre". Mas ele ainda não está disponível para outra requisição porque os dados da requisição anterior ainda permanecem no volume. Um administrador pode manualmente recuperar o volume executando os seguintes passos: + + +1. Deletar o PersistentVolume. O armazenamento associado à infraestrutura externa (AWS EBS, GCE PD, Azure Disk ou Cinder volume) ainda continuará existindo após o PV ser deletado. +1. Limpar os dados de forma manual no armazenamento associado. +1. Deletar manualmente o armazenamento associado. Caso você queira utilizar o mesmo armazenamento, crie um novo PersistentVolume com esse armazenamento. + +#### Deletar + +Para plugins de volume que suportam a política de recuperação `Delete`, a deleção vai remover o tanto o PersistentVolume do Kubernetes, quanto o armazenamento associado à infraestrutura externa, como AWS EBS, GCE PD, Azure Disk, ou Cinder volume. Volumes que foram provisionados dinamicamente herdam a [política de retenção da sua StorageClass](#política-de-retenção), que por padrão é `Delete`. O administrador precisa configurar a StorageClass de acordo com as necessidades dos usuários. Caso contrário, o PV deve ser editado ou reparado após sua criação. Veja [Alterar a política de retenção de um PersistentVolume](/docs/tasks/administer-cluster/change-pv-reclaim-policy/). + +#### Reciclar + +{{< warning >}} +A política de retenção `Recycle` está depreciada. Ao invés disso, recomendamos a utilização de provisionamento dinâmico. +{{< /warning >}} + +Em caso do volume plugin ter suporte a essa operação, a política de retenção `Recycle` faz uma limpeza básica (`rm -rf /thevolume/*`) no volume e torna ele disponível novamente para outra requisição. + +Contudo, um administrador pode configurar um template personalizado de um Pod reciclador utilizando a linha de comando do gerenciamento de controle do Kubernetes como descrito em [referência](/docs/reference/command-line-tools-reference/kube-controller-manager/). +O Pod reciclador personalizado deve conter a spec `volume` como é mostrado no exemplo abaixo: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pv-recycler + namespace: default +spec: + restartPolicy: Never + volumes: + - name: vol + hostPath: + path: /any/path/it/will/be/replaced + containers: + - name: pv-recycler + image: "k8s.gcr.io/busybox" + command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/* && test -z \"$(ls -A /scrub)\" || exit 1"] + volumeMounts: + - name: vol + mountPath: /scrub +``` + +Contudo, o caminho especificado no Pod reciclador personalizado em `volumes` é substituído pelo caminho do volume que está sendo reciclado. + +### Reservando um PersistentVolume + +A camada de gerenciamento pode [fazer o bind de um PersistentVolumeClaims com PersistentVolumes equivalentes](#binding) no cluster. Contudo, se você quer que uma PVC faça um bind com um PV específico, é preciso fazer o pré-bind deles. + +Especificando um PersistentVolume na PersistentVolumeClaim, você declara um bind entre uma PVC e um PV específico. O bind ocorrerá se o PersistentVolume existir e não estiver reservado por uma PersistentVolumeClaims através do seu campo `claimRef`. + +O bind ocorre independentemente se algum volume atender ao critério, incluindo afinidade de nó. A camada de gerenciamento verifica se a [classe de armazenamento](/docs/concepts/storage/storage-classes/), modo de acesso e tamanho do armazenamento solicitado ainda são válidos. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: foo-pvc + namespace: foo +spec: + storageClassName: "" # Empty string must be explicitly set otherwise default StorageClass will be set + volumeName: foo-pv + ... +``` + +Esse método não garante nenhum privilégio de bind no PersistentVolume. Para evitar que alguma outra PersistentVolumeClaims possa usar o PV que você especificar, você precisa primeiro reservar esse volume de armazenamento. Especifique sua PersistentVolumeClaim no campo `claimRef` do PV para que outras PVCs não façam bind nele. + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: foo-pv +spec: + storageClassName: "" + claimRef: + name: foo-pvc + namespace: foo + ... +``` + +Isso é útil se você deseja utilizar PersistentVolumes que possuem suas `claimPolicy` configuradas para `Retain`, incluindo situações onde você estiver reutilizando um PV existente. + +### Expandindo Requisições de Volumes Persistentes + +{{< feature-state for_k8s_version="v1.11" state="beta" >}} + +Agora, o suporte à expansão de PersistentVolumeClaims (PVCs) já é habilitado por padrão. Você pode expandir os tipos de volumes abaixo: + +* gcePersistentDisk +* awsElasticBlockStore +* Cinder +* glusterfs +* rbd +* Azure File +* Azure Disk +* Portworx +* FlexVolumes +* {{< glossary_tooltip text="CSI" term_id="csi" >}} + +Você só pode expandir uma PVC se o campo da classe de armazenamento `allowVolumeExpansion` é `true`. + +``` yaml +apiVersion: storage.k8s.io/v1 +kind: StorageClass +metadata: + name: gluster-vol-default +provisioner: kubernetes.io/glusterfs +parameters: + resturl: "http://192.168.10.100:8080" + restusuário: "" + secretNamespace: "" + secretName: "" +allowVolumeExpansion: true +``` + +Para solicitar um volume maior para uma PVC, edite a PVC e especifique um tamanho maior. Isso irá fazer com o que volume atrelado ao respectivo PersistentVolume seja expandido. Nunca um PersistentVolume é criado para satisfazer a requisição. Ao invés disso, um volume existente é redimensionado. + +#### Expansão de volume CSI + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +O suporte à expansão de volumes CSI é habilitada por padrão, porém é necessário um driver CSI específico para suportar a expansão do volume. Verifique a documentação do driver CSI específico para mais informações. + +#### Redimensionando um volume que contém um sistema de arquivo + +Só podem ser redimensionados os volumes que contém os seguintes sistemas de arquivo: XFS, Ext3 ou Ext4. + +Quando um volume contém um sistema de arquivo, o sistema de arquivo somente é redimensionado quando um novo Pod está utilizando a PersistentVolumeClaim no modo `ReadWrite`. A expansão de sistema de arquivo é feita quando um Pod estiver inicializando ou quando um Pod estiver em execução e o respectivo sistema de arquivo tenha suporte para expansão a quente. + +FlexVolumes permitem redimensionamento se o `RequiresFSResize` do drive é configurado como `true`. O FlexVolume pode ser redimensionado na reinicialização do Pod. + +#### Redimensionamento de uma PersistentVolumeClaim em uso + +{{< feature-state for_k8s_version="v1.15" state="beta" >}} + +{{< note >}} +A Expansão de PVCs em uso está disponível como beta desde o Kubernetes 1.15, e como alpha desde a versão 1.11. A funcionalidade `ExpandInUsePersistentVolumes` precisa ser habilitada, o que já está automático para vários clusters que possuem funcionalidades beta. Verifique a documentação [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) para mais informações. +{{< /note >}} + +Neste caso, você não precisa deletar e recriar um Pod ou um deployment que está sendo utilizado por uma PVC existente. +Automaticamente, qualquer PVC em uso fica disponível para o Pod assim que o sistema de arquivo for expandido. +Essa funcionalidade não tem efeito em PVCs que não estão em uso por um Pod ou deployment. Você deve criar um Pod que utilize a PVC antes que a expansão seja completada. + +Da mesma forma que outros tipos de volumes - volumes FlexVolume também podem ser expandidos quando estiverem em uso por um Pod. + +{{< note >}} +Redimensionamento de FlexVolume somente é possível quando o respectivo driver suportar essa operação. +{{< /note >}} + +{{< note >}} +Expandir volumes do tipo EBS é uma operação que toma muito tempo. Além disso, só é possível fazer uma modificação por volume a cada 6 horas. +{{< /note >}} + +#### Recuperação em caso de falha na expansão de volumes + +Se a expansão do respectivo armazenamento falhar, o administrador do cluster pode recuperar manualmente o estado da Persistent Volume Claim (PVC) e cancelar as solicitações de redimensionamento. Caso contrário, as tentativas de solicitação de redimensionamento ocorrerão de forma contínua pelo controlador sem nenhuma intervenção do administrador. + +1. Marque o PersistentVolume(PV) que estiver atrelado à PersistentVolumeClaim(PVC) com a política de recuperação `Retain`. +2. Delete a PVC. Desde que o PV tenha a política de recuperação `Retain` - nenhum dado será perdido quando a PVC for recriada. +3. Delete a entrada `claimRef` da especificação do PV para que uma PVC possa fazer bind com ele. Isso deve tornar o PV `Available`. +4. Recrie a PVC com um tamanho menor que o PV e configure o campo `volumeName` da PCV com o nome do PV. Isso deve fazer o bind de uma nova PVC a um PV existente. +5. Não esqueça de restaurar a política de recuperação do PV. + +## Tipos de volumes persistentes + +Tipos de PersistentVolume são implementados como plugins. Atualmente o Kubernetes suporta os plugins abaixo: + +* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) - AWS Elastic Block Store (EBS) +* [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk) - Azure Disk +* [`azureFile`](/docs/concepts/storage/volumes/#azurefile) - Azure File +* [`cephfs`](/docs/concepts/storage/volumes/#cephfs) - CephFS volume +* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder (OpenStack block storage) + (**depreciado**) +* [`csi`](/docs/concepts/storage/volumes/#csi) - Container Storage Interface (CSI) +* [`fc`](/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) storage +* [`flexVolume`](/docs/concepts/storage/volumes/#flexVolume) - FlexVolume +* [`flocker`](/docs/concepts/storage/volumes/#flocker) - Flocker storage +* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk +* [`glusterfs`](/docs/concepts/storage/volumes/#glusterfs) - Glusterfs volume +* [`hostPath`](/docs/concepts/storage/volumes/#hostpath) - HostPath volume + (somente para teste de nó único; ISSO NÃO FUNCIONARÁ num cluster multi-nós; ao invés disso, considere a utilização de volume `local`.) +* [`iscsi`](/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) storage +* [`local`](/docs/concepts/storage/volumes/#local) - storage local montados nos nós. +* [`nfs`](/docs/concepts/storage/volumes/#nfs) - Network File System (NFS) storage +* `photonPersistentDisk` - Controlador Photon para disco persistente. + (Esse tipo de volume não funciona mais desde a removação do provedor de cloud correspondente.) +* [`portworxVolume`](/docs/concepts/storage/volumes/#portworxvolume) - Volume Portworx +* [`quobyte`](/docs/concepts/storage/volumes/#quobyte) - Volume Quobyte +* [`rbd`](/docs/concepts/storage/volumes/#rbd) - Volume Rados Block Device (RBD) +* [`scaleIO`](/docs/concepts/storage/volumes/#scaleio) - Volume ScaleIO + (**depreciado**) +* [`storageos`](/docs/concepts/storage/volumes/#storageos) - Volume StorageOS +* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - Volume vSphere VMDK + +## Volumes Persistentes + +Cada PV contém uma `spec` e um status, que é a especificação e o status do volume. O nome do PersistentVolume deve ser um [DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: pv0003 +spec: + capacity: + storage: 5Gi + volumeMode: Filesystem + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Retain + storageClassName: slow + mountOptions: + - hard + - nfsvers=4.1 + nfs: + path: /tmp + server: 172.17.0.2 +``` + +{{< note >}} +Talvez sejam necessários programas auxiliares para um determinado tipo de volume utilizar um PersistentVolume no cluster. Neste exemplo, o PersistentVolume é do tipo NFS e o programa auxiliar _/sbin/mount.nfs_ é necessário para suportar a montagem dos sistemas de arquivos NFS. +{{< /note >}} + +### Capacidade + +Geralmente, um PV terá uma capacidade de armazenamento específica. Isso é configurado usando o atributo `capacity` do PV. Veja o [Modelo de Recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) do Kubernetes para entender as unidades aceitas pelo atributo `capacity`. + +Atualmente, o tamanho do armazenamento é o único recurso que pode ser configurado ou solicitado. Os futuros atributos podem incluir IOPS, throughput, etc. + +### Modo do Volume + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +O Kubernetes suporta dois `volumeModes` de PersistentVolumes: `Filesystem` e `Block`. + +`volumeMode` é um parâmetro opcional da API. +`Filesystem` é o modo padrão utilizado quando o parâmetro `volumeMode` é omitido. + +Um volume com `volumeMode: Filesystem` é *montado* em um diretório nos Pods. Se o volume for de um dispositivo de bloco e ele estiver vazio, o Kubernetes cria o sistema de arquivo no dispositivo antes de fazer a montagem pela primeira vez. + +Você pode configurar o valor do `volumeMode` para `Block` para utilizar um disco bruto como volume. Esse volume é apresentado num Pod como um dispositivo de bloco, sem nenhum sistema de arquivo. Esse modo é útil para prover ao Pod a forma mais rápida para acessar um volume, sem nenhuma camada de sistema de arquivo entre o Pod e o volume. Por outro lado, a aplicação que estiver rodando no Pod deverá saber como tratar um dispositivo de bloco. Veja [Suporte a Volume de Bloco Bruto](#raw-block-volume-support) para um exemplo de como utilizar o volume como `volumeMode: Block` num Pod. + +### Modos de Acesso + +Um PersistentVolume pode ser montado num host das mais variadas formas suportadas pelo provedor. Como mostrado na tabela abaixo, os provedores terão diferentes capacidades e cada modo de acesso do PV são configurados nos modos específicos suportados para cada volume em particular. Por exemplo, o NFS pode suportar múltiplos clientes read/write, mas um PV NFS específico pode ser exportado no server como read-only. Cada PV recebe seu próprio modo de acesso que descreve suas capacidades específicas. + +Os modos de acesso são: + +* ReadWriteOnce -- o volume pode ser montado como leitura-escrita por um nó único +* ReadOnlyMany -- o volume pode ser montado como somente-leitura por vários nós +* ReadWriteMany -- o volume pode ser montado como leitura-escrita por vários nós + +Na linha de comando, os modos de acesso ficam abreviados: + +* RWO - ReadWriteOnce +* ROX - ReadOnlyMany +* RWX - ReadWriteMany + +> __Importante!__ Um volume somente pode ser montado utilizando um único modo de acesso por vez, independente se ele suportar mais de um. Por exemplo, um GCEPersistentDisk pode ser montado como ReadWriteOnce por um único nó ou ReadOnlyMany por vários nós, porém não simultaneamente. + + +| Plugin de Volume | ReadWriteOnce | ReadOnlyMany | ReadWriteMany| +| :--- | :---: | :---: | :---: | +| AWSElasticBlockStore | ✓ | - | - | +| AzureFile | ✓ | ✓ | ✓ | +| AzureDisk | ✓ | - | - | +| CephFS | ✓ | ✓ | ✓ | +| Cinder | ✓ | - | - | +| CSI | depende do driver | depende do driver | depende do driver | +| FC | ✓ | ✓ | - | +| FlexVolume | ✓ | ✓ | depende do driver | +| Flocker | ✓ | - | - | +| GCEPersistentDisk | ✓ | ✓ | - | +| Glusterfs | ✓ | ✓ | ✓ | +| HostPath | ✓ | - | - | +| iSCSI | ✓ | ✓ | - | +| Quobyte | ✓ | ✓ | ✓ | +| NFS | ✓ | ✓ | ✓ | +| RBD | ✓ | ✓ | - | +| VsphereVolume | ✓ | - | (funcionam quando os Pods são do tipo collocated) | +| PortworxVolume | ✓ | - | ✓ | +| ScaleIO | ✓ | ✓ | - | +| StorageOS | ✓ | - | - | + +### Classe + +Um PV pode ter uma classe, que é especificada na configuração do atributo `storageClassName` com o nome da [StorageClass](/docs/concepts/storage/storage-classes/). Um PV de uma classe específica só pode ser atrelado a requisições PVCs dessa mesma classe. Um PV sem `storageClassName` não possui nenhuma classe e pode ser montado somente a PVCs que não solicitem nenhuma classe em específico. + +No passado, a notação `volume.beta.kubernetes.io/storage-class` era utilizada no lugar do atributo `storageClassName`. Essa notação ainda funciona. Contudo, ela será totalmente depreciada numa futura versão do Kubernetes. + +### Política de Retenção + +Atualmente as políticas de retenção são: + +* Retain -- recuperação manual +* Recycle -- limpeza básica (`rm -rf /thevolume/*`) +* Delete -- o volume de armazenamento associado, como AWS EBS, GCE PD, Azure Disk ou OpenStack Cinder é deletado + +Atualmente, somente NFS e HostPath suportam reciclagem. Volumes AWS EBS, GCE PD, Azure Disk e Cinder suportam delete. + +### Opções de Montagem + +Um administrador do Kubernetes pode especificar opções de montagem adicionais quando um Volume Persistente é montado num nó. + +{{< note >}} +Nem todos os tipos de Volume Persistente suportam opções de montagem. +{{< /note >}} + +Seguem os tipos de volumes que suportam opções de montagem. + +* AWSElasticBlockStore +* AzureDisk +* AzureFile +* CephFS +* Cinder (OpenStack block storage) +* GCEPersistentDisk +* Glusterfs +* NFS +* Quobyte Volumes +* RBD (Ceph Block Device) +* StorageOS +* VsphereVolume +* iSCSI + +Não há validação em relação às opções de montagem. A montagem irá falhar se houver alguma opção inválida. + +No passado, a notação `volume.beta.kubernetes.io/mount-options` era usada no lugar do atributo `mountOptions`. Essa notação ainda funciona. Contudo, ela será totalmente depreciada numa futura versão do Kubernetes. + +### Afinidade de Nó + +{{< note >}} +Para a maioria dos tipos de volume, a configuração desse campo não se faz necessária. Isso é automaticamente populado pelos seguintes volumes de bloco do tipo: [AWS EBS](/docs/concepts/storage/volumes/#awselasticblockstore), [GCE PD](/docs/concepts/storage/volumes/#gcepersistentdisk) e [Azure Disk](/docs/concepts/storage/volumes/#azuredisk). Você precisa deixar isso configurado para volumes do tipo [local](/docs/concepts/storage/volumes/#local). +{{< /note >}} + +Um PV pode especificar uma [afinidade de nó](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volumenodeaffinity-v1-core) para definir restrições em relação ao limite de nós que podem acessar esse volume. Pods que utilizam um PV serão somente reservados para nós selecionados pela afinidade de nó. + +### Estado + +Um volume sempre estará em um dos seguintes estados: + +* Available -- um recurso que está livre e ainda não foi atrelado a nenhuma requisição +* Bound -- um volume atrelado a uma requisição +* Released -- a requisição foi deletada, mas o curso ainda não foi recuperado pelo cluster +* Failed -- o volume fracassou na sua recuperação automática + + +A CLI mostrará o nome do PV que foi atrelado à PVC + +## PersistentVolumeClaims + +Cada PVC contém uma `spec` e um status, que é a especificação e estado de uma requisição. O nome de um objeto PersistentVolumeClaim precisa ser um [DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: myclaim +spec: + accessModes: + - ReadWriteOnce + volumeMode: Filesystem + resources: + requests: + storage: 8Gi + storageClassName: slow + selector: + matchLabels: + release: "stable" + matchExpressions: + - {key: environment, operator: In, values: [dev]} +``` + +### Modos de Acesso + +As requisições usam as mesmas convenções que os volumes quando eles solicitam um armazenamento com um modo de acesso específico. + +### Modos de Volume + +As requisições usam as mesmas convenções que os volumes quando eles indicam o tipo de volume, seja ele um sistema de arquivo ou dispositivo de bloco. + +### Recursos + + +Assim como Pods, as requisições podem solicitar quantidades específicas de recurso. Neste caso, a solicitação é por armazenamento. O mesmo [modelo de recurso](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) vale para volumes e requisições. + +### Seletor + +Requisições podem especifiar um [seletor de rótulo](/docs/concepts/overview/working-with-objects/labels/#label-selectors) para posteriormente filtrar um grupo de volumes. Somente os volumes que possuam rótulos que satisfaçam os critérios do seletor podem ser atrelados à requisição. O seletor pode conter dois campos: + +* `matchLabels` - o volume deve ter um rótulo com esse valor +* `matchExpressions` - uma lista de requisitos, como chave, lista de valores e operador relacionado aos valores e chaves. São operadores válidos: In, NotIn, Exists e DoesNotExist. + +Todos os requisitos de `matchLabels` e `matchExpressions`, são do tipo AND - todos eles juntos devem ser atendidos. + +### Classe + +Uma requisição pode solicitar uma classe específica através da [StorageClass](/docs/concepts/storage/storage-classes/) utilizando o atributo `storageClassName`. Neste caso o bind ocorrerá somente com os PVs que possuírem a mesma classe do `storageClassName` dos PVCs. + +As PVCs não precisam necessariamente solicitar uma classe. Uma PVC com sua `storageClassName` configurada como `""` sempre solicitará um PV sem classe, dessa forma ela sempre será atrelada a um PV sem classe (que não tenha nenhuma notação, ou seja, igual a `""`). Uma PVC sem `storageClassName` não é a mesma coisa e será tratada pelo cluster de forma diferente, porém isso dependerá se o [puglin de admissão](/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) `DefaultStorageClass` estiver habilitado. + +* Se o plugin de admissão estiver habilitado, o administrador poderá especificar a StorageClass padrão. Todas as PVCs que não tiverem `storageClassName` podem ser atreladas somente a PVs que atendam a esse padrão. A especificação de uma StorageClass padrão é feita através da notação `storageclass.kubernetes.io/is-default-class` recebendo o valor `true` no objeto da StorageClass. Se o administrador não especificar nenhum padrão, o cluster vai tratar a criação de uma PVC como se o plugin de admissão estivesse desabilitado. Se mais de um valor padrão for especificado, o plugin de admissão proíbe a criação de todas as PVCs. +* Se o plugin de admissão estiver desabilitado, não haverá nenhuma notação para a StorageClass padrão. Todas as PVCs que não tiverem `storageClassName` poderão ser atreladas somente aos PVs que não possuem classe. Neste caso, as PVCs que não tiverem `storageClassName` são tratadas da mesma forma como as PVCs que possuem suas `storageClassName` configuradas como `""`. + +Dependendo do modo de instalação, uma StorageClass padrão pode ser implantada num cluster Kubernetes durante a instalação pelo addon manager. + +Quando uma PVC especifica um `selector` para solicitar uma StorageClass, os requisitos são do tipo AND: somente um PV com a classe solicitada e com o rótulo requisitado pode ser atrelado à PVC. + +{{< note >}} +Atualmente, uma PVC que tenha `selector` não pode ter um PV dinamicamente provisionado. +{{< /note >}} + +No passado, a notação `volume.beta.kubernetes.io/storage-class` era usada no lugar do atributo `storageClassName` Essa notação ainda funciona. Contudo, ela será totalmente depreciada numa futura versão do Kubernetes. + +## Requisições como Volumes + +Os Pods podem ter acesso ao armazenamento utilizando a requisição como um volume. Para isso, a requisição tem que estar no mesmo namespace que o Pod. Ao localizar a requisição no namespace do Pod, o cluster passa o PersistentVolume para a requisição. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: mypod +spec: + containers: + - name: myfrontend + image: nginx + volumeMounts: + - mountPath: "/var/www/html" + name: mypd + volumes: + - name: mypd + persistentVolumeClaim: + claimName: myclaim +``` + +### Sobre Namespaces + +Os binds dos PersistentVolumes são exclusivos e, desde que as PersistentVolumeClaims são objetos do namespace, fazer a montagem das requisições com "Muitos" nós (`ROX`, `RWX`) é possível somente para um namespace. + +### PersistentVolumes do tipo `hostPath` + +Um PersistentVolume do tipo `hostPath` utiliza um arquivo ou diretório no nó para emular um network-attached storage (NAS). Veja [um exemplo de volume do tipo `hostPath`](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). + +## Suporte a Volume de Bloco Bruto + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +Os plugins de volume abaixo suportam volumes de bloco bruto, incluindo provisionamento dinâmico onde for aplicável: + +* AWSElasticBlockStore +* AzureDisk +* CSI +* FC (Fibre Channel) +* GCEPersistentDisk +* iSCSI +* Local volume +* OpenStack Cinder +* RBD (Ceph Block Device) +* VsphereVolume + +### Utilização de PersistentVolume com Volume de Bloco Bruto {#persistent-volume-using-a-raw-block-volume} + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: block-pv +spec: + capacity: + storage: 10Gi + accessModes: + - ReadWriteOnce + volumeMode: Block + persistentVolumeReclaimPolicy: Retain + fc: + targetWWNs: ["50060e801049cfd1"] + lun: 0 + readOnly: false +``` + +### Requisição de PersistentVolumeClaim com Volume de Bloco Bruto {#persistent-volume-claim-requesting-a-raw-block-volume} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: block-pvc +spec: + accessModes: + - ReadWriteOnce + volumeMode: Block + resources: + requests: + storage: 10Gi +``` + +### Especificação de Pod com Dispositivo de Bloco Bruto no contêiner + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod-with-block-volume +spec: + containers: + - name: fc-container + image: fedora:26 + command: ["/bin/sh", "-c"] + args: [ "tail -f /dev/null" ] + volumeDevices: + - name: data + devicePath: /dev/xvda + volumes: + - name: data + persistentVolumeClaim: + claimName: block-pvc +``` + +{{< note >}} +Quando adicionar um dispositivo de bloco bruto num Pod, você especifica o caminho do dispositivo no contêiner ao invés de um ponto de montagem. +{{< /note >}} + +### Bind de Volumes de Bloco + +Se um usuário solicita um volume de bloco bruto através do campo `volumeMode` na `spec` da PersistentVolumeClaim, as regras de bind agora têm uma pequena diferença em relação às versões anteriores que não consideravam esse modo como parte da `spec`. +A tabela abaixo mostra as possíveis combinações que um usuário e um administrador pode especificar para requisitar um dispositivo de bloco bruto. A tabela indica se o volume será ou não atrelado com base nas combinações: +Matriz de bind de volume para provisionamento estático de volumes: + +| PV volumeMode | PVC volumeMode | Result | +| --------------|:---------------:| ----------------:| +| unspecified | unspecified | BIND | +| unspecified | Block | NO BIND | +| unspecified | Filesystem | BIND | +| Block | unspecified | NO BIND | +| Block | Block | BIND | +| Block | Filesystem | NO BIND | +| Filesystem | Filesystem | BIND | +| Filesystem | Block | NO BIND | +| Filesystem | unspecified | BIND | + +{{< note >}} +O provisionamento estático de volumes é suportado somente na versão alpha. Os administradores devem tomar cuidado ao considerar esses valores quando estiverem trabalhando com dispositivos de bloco bruto. +{{< /note >}} + +## Snapshot de Volume e Restauração de Volume a partir de um Snapshot + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +O snapshot de volume é suportado somente pelo plugin de volume CSI. Veja [Snapshot de Volume](/docs/concepts/storage/volume-snapshots/) para mais detalhes. +Plugins de volume in-tree estão depreciados. Você pode consultar sobre os plugins de volume depreciados em [Perguntas Frequentes sobre Plugins de Volume](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). + +### Criar uma PersistentVolumeClaim a partir de um Snapshot de Volume {#create-persistent-volume-claim-from-volume-snapshot} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: restore-pvc +spec: + storageClassName: csi-hostpath-sc + dataSource: + name: new-snapshot-test + kind: VolumeSnapshot + apiGroup: snapshot.storage.k8s.io + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +## Clonagem de Volume + +A [Clonagem de Volume](/docs/concepts/storage/volume-pvc-datasource/) é possível somente com plugins de volume CSI. + +### Criação de PersistentVolumeClaim a partir de uma PVC já existente {#create-persistent-volume-claim-from-an-existing-pvc} + +```yaml +apiVersion: v1 +kind: PersistentVolumeClaim +metadata: + name: cloned-pvc +spec: + storageClassName: my-csi-plugin + dataSource: + name: existing-src-pvc-name + kind: PersistentVolumeClaim + accessModes: + - ReadWriteOnce + resources: + requests: + storage: 10Gi +``` + +## Boas Práticas de Configuração + + +Se você está criando templates ou exemplos que rodam numa grande quantidade de clusters e que precisam de armazenamento persistente, recomendamos que utilize o padrão abaixo: + +- Inclua objetos PersistentVolumeClaim em seu pacote de configuração (com Deployments, ConfigMaps, etc.). +- Não inclua objetos PersistentVolume na configuração, pois o usuário que irá instanciar a configuração talvez não tenha permissão para criar PersistentVolume. +- Dê ao usuário a opção dele informar o nome de uma classe de armazenamento quando instanciar o template. + - Se o usuário informar o nome de uma classe de armazenamento, coloque esse valor no campo `persistentVolumeClaim.storageClassName`. Isso fará com que a PVC encontre a classe de armazenamento correta se o cluster tiver a StorageClasses habilitado pelo administrador. + - Se o usuário não informar o nome da classe de armazenamento, deixe o campo `persistentVolumeClaim.storageClassName` sem nenhum valor (vazio). Isso fará com que o PV seja provisionado automaticamente no cluster para o usuário com o StorageClass padrão. Muitos ambientes de cluster já possuem uma StorageClass padrão, ou então os administradores podem criar suas StorageClass de acordo com seus critérios. +- Durante suas tarefas de administração, busque por PVCs que após um tempo não estão sendo atreladas, pois, isso talvez indique que o cluster não tem provisionamento dinâmico (onde o usuário deveria criar um PV que satisfaça os critérios da PVC) ou cluster não tem um sistema de armazenamento (onde usuário não pode realizar um deploy solicitando PVCs). + + ## {{% heading "whatsnext" %}} + + +* Saiba mais sobre [Criando um PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). +* Saiba mais sobre [Criando um PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim). +* Leia a [documentação sobre planejamento de Armazenamento Persistente](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). + +### Referência + +* [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core) +* [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumespec-v1-core) +* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core) diff --git a/content/pt/docs/concepts/workloads/controllers/_index.md b/content/pt-br/docs/concepts/workloads/controllers/_index.md old mode 100755 new mode 100644 similarity index 100% rename from content/pt/docs/concepts/workloads/controllers/_index.md rename to content/pt-br/docs/concepts/workloads/controllers/_index.md diff --git a/content/pt-br/docs/concepts/workloads/controllers/cron-jobs.md b/content/pt-br/docs/concepts/workloads/controllers/cron-jobs.md new file mode 100644 index 0000000000..19c7cd8604 --- /dev/null +++ b/content/pt-br/docs/concepts/workloads/controllers/cron-jobs.md @@ -0,0 +1,109 @@ +--- +title: CronJob +content_type: concept +weight: 80 +--- + + + +{{< feature-state for_k8s_version="v1.21" state="stable" >}} + +Um _CronJob_ cria {{< glossary_tooltip term_id="job" text="Jobs" >}} em um cronograma recorrente. + +Um objeto CronJob é como uma linha em um arquivo _crontab_ (tabela cron). Executa uma tarefa periodicamente em um determinado cronograma, escrito no formato [Cron](https://en.wikipedia.org/wiki/Cron). + +{{< caution >}} + +Todos os horários da propriedade `schedule:` do *CronJob* são baseadas no fuso horário do {{< glossary_tooltip term_id="kube-controller-manager" >}}. + +Se a camada de gerenciamento do cluster executa o kube-controller-manager em Pods ou contêineres avulsos, o fuso horário configurado para o contêiner executando o kube-controller-manager determina o fuso horário que o controlador dos objetos CronJob utiliza. + +{{< /caution >}} + +Ao criar o manifesto para um objeto CronJob, verifique se o nome que você forneceu é um [nome de subdomínio DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. +O nome não pode ter mais que 52 caracteres. Esta limitação existe porque o controlador do CronJob adicionará automaticamente 11 caracteres ao final do nome escolhido para a tarefa, e o tamanho máximo de um nome de tarefa não pode ultrapassar 63 caracteres. + + + +## CronJob + +CronJobs são úteis para criar tarefas periódicas e recorrentes, como a execução de _backups_ ou o envio de mensagens de e-mail. CronJobs também permitem o agendamento de tarefas individuais para um horário específico, como por exemplo uma tarefa que é executada em um período maior de ociosidade do cluster. + +### Exemplo + +Este manifesto de CronJob de exemplo imprime a data e horário atuais, seguidos da mensagem "Hello from the Kubernetes cluster", uma vez por minuto: + +{{< codenew file="application/job/cronjob.yaml" >}} + +(O artigo [Running Automated Tasks with a CronJob](/docs/tasks/job/automated-tasks-with-cron-jobs/) demonstra este exemplo com maiores detalhes). + +### Sintaxe do cronograma cron + +``` +# ┌───────────── minuto (0 - 59) +# │ ┌───────────── hora (0 - 23) +# │ │ ┌───────────── dia do mês (1 - 31) +# │ │ │ ┌───────────── mês (1 - 12) +# │ │ │ │ ┌───────────── dia da semana (0 - 6) (domingo a sábado; +# │ │ │ │ │ 7 também representa domingo em alguns sistemas operacionais) +# │ │ │ │ │ +# │ │ │ │ │ +# * * * * * +``` + +| Expressão | Descrição | Equivalente a | +| ------------- | ------------- |------------- | +| @yearly (ou @annually) | Executa uma vez por ano, à meia-noite de 1º de janeiro | 0 0 1 1 * | +| @monthly | Executa uma vez por mês, à meia-noite do primeiro dia do mês| 0 0 1 * * | +| @weekly | Executa uma vez por semana, à meia-noite de domingo | 0 0 * * 0 | +| @daily (ou @midnight) | Executa uma vez por dia, à meia-noite | 0 0 * * * | +| @hourly | Executa uma vez por hora, no minuto zero | 0 * * * * | + +Por exemplo, a linha abaixo determina que a tarefa deve iniciar toda sexta-feira à meia-noite, bem como em todo dia 13 do mês à meia-noite: + +`0 0 13 * 5` + +É também possível gerar expressões de cronograma para CronJobs utilizando ferramentas da _web_ como o [crontab.guru](https://crontab.guru/). + +## Limitações do CronJob + +Um CronJob cria uma tarefa _aproximadamente_ uma vez por tempo de execução de seu cronograma. Dizemos "aproximadamente" porque existem circunstâncias em que duas tarefas podem ser criadas, e outras circunstâncias em que nenhuma tarefa será criada. Tentamos tornar estas situações raras, mas não é possível preveni-las completamente. Portanto, as tarefas devem ser _idempotentes_. + +Se o valor da propriedade `startingDeadlineSeconds` (limite de tempo de inicialização, em segundos) estiver definido como um valor grande, ou não definido (o padrão), e se a propriedade `concurrencyPolicy` (política de concorrência) estiver definido como `Allow` (permitir), as tarefas sempre serão executadas pelo menos uma vez. + +{{< caution >}} + +Se a propriedade `startingDeadlineSeconds` estiver definida com um valor menor que 10 segundos, a tarefa cron poderá não ser agendada. Isso ocorre porque o cronograma de execução do {{< glossary_tooltip term_id="controller" text="controlador" >}} do CronJob verifica tarefas a cada 10 segundos. + +{{< /caution >}} + +Para cada CronJob, o {{< glossary_tooltip term_id="controller" text="controlador" >}} do CronJob verifica quantos agendamentos foram perdidos no tempo entre o último horário agendado e o horário atual. Se houver mais de 100 agendamentos perdidos no período, o controlador não iniciará o trabalho e gerará a seguinte mensagem de erro: + +``` +Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew. +``` + +É importante observar que, se o campo `startingDeadlineSeconds` estiver definido (não `nil`), o controlador contará quantas tarefas perdidas ocorreram a partir do valor de `startingDeadlineSeconds` até agora, e não do último horário agendado até agora. Por exemplo, se `startingDeadlineSeconds` for `200`, o controlador contará quantas tarefas perdidas ocorreram nos últimos 200 segundos. + +Um CronJob é considerado perdido se não for criado no horário agendado. Por exemplo, se `concurrencyPolicy` estiver definido como `Forbid` (proibir) e uma tentativa de agendamento de um novo CronJob ocorreu quando havia um agendamento anterior ainda em execução, o novo agendamento será contabilizado como perdido. + +Por exemplo, suponha que um CronJob esteja definido para agendar uma nova tarefa a cada minuto, começando às `08:30:00`, e seu campo `startingDeadlineSeconds` não esteja definido. Se o controlador do CronJob estiver inativo das `08:29:00` até as `10:21:00`, a tarefa não será iniciada, pois o número de tarefas que perderam seus horários agendados é maior que 100. + +Para ilustrar melhor este conceito, suponha que um CronJob esteja definido para agendar uma nova tarefa a cada minuto, começando às `08:30:00`, e seu `startingDeadlineSeconds` esteja definido em 200 segundos. Se o controlador do CronJob estiver inativo no mesmo período do exemplo anterior (das `08:29:00` às `10:21:00`), a tarefa ainda será iniciada às 10:22:00. Isso acontece pois o controlador agora verifica quantos agendamentos perdidos ocorreram nos últimos 200 segundos (ou seja, 3 agendamentos perdidos), ao invés de verificar o período entre o último horário agendado e o horário atual. + +O CronJob é responsável apenas pela criação das tarefas que correspondem à sua programação, e a tarefa, por sua vez, é responsável pelo gerenciamento dos Pods que ele representa. + +## Versão do controlador + +A partir da versão 1.21 do Kubernetes, a segunda versão do controlador do CronJob é a implementação ativada por padrão. Para desativar o controlador do CronJob padrão e utilizar a versão original do controlador do CronJob, é necessário adicionar o _flag_ de [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `CronJobControllerV2` à chamada do {{< glossary_tooltip term_id="kube-controller-manager" >}} com o valor `false` (falso). Por exemplo: +``` +--feature-gates="CronJobControllerV2=false" +``` + + +## {{% heading "whatsnext" %}} + +A página [Cron expression format](https://en.wikipedia.org/wiki/Cron) documenta o formato dos campos de agendamento do CronJob. + +Para instruções sobre criação e utilização de tarefas cron, e para um exemplo de manifesto de CronJob, veja +[Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs). diff --git a/content/pt-br/docs/contribute/_index.md b/content/pt-br/docs/contribute/_index.md new file mode 100644 index 0000000000..e5a227c2f1 --- /dev/null +++ b/content/pt-br/docs/contribute/_index.md @@ -0,0 +1,84 @@ +--- +content_type: concept +title: Contribua com a documentação do Kubernetes +linktitle: Contribuir +main_menu: true +weight: 80 +no_list: true +card: + name: contribuir + weight: 10 + title: Comece a contribuir para o K8s +--- +--- + + + +*O Kubernetes agradece as melhorias de todos os contribuidores, novos e experientes!* + +{{< note >}} +Para saber mais sobre como contribuir o Kubernetes em geral, veja a +[documentação para contribuidor](https://www.kubernetes.dev/docs/). +{{< /note >}} + +Este site é mantido pelo [Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs). + +Contribuidores da documentação do Kubernetes podem: + - Melhorar o conteúdo existente + - Criar novo conteúdo + - Traduzir a documentação + - Gerenciar e publicar a documentação como parte do ciclo de lançamento do Kubernetes + + + +## Começando + +Qualquer pessoa pode abrir uma issue sobre a documentação, ou contribuir com uma mudança por meio de um pull request (PR) para o [repositório do Github `kubernetes/website`](https://github.com/kubernetes/website). +É recomendável que você se sinta confortável com [git](https://git-scm.com/) e +[Github](https://lab.github.com/) para trabalhar efetivamente na comunidade Kubernetes. + +Para se envolver com a documentação: + +1. Assine o [Contrato de Licença de Colaborador](https://github.com/kubernetes/community/blob/master/CLA.md) do CNCF. +2. Familiarize-se com o [repositório de documentação](https://github.com/kubernetes/website) e o [gerador de site estático](https://gohugo.io) hugo. +3. Certifique-se de entender os processos básicos para [melhorar o conteúdo](https://kubernetes.io/docs/contribute/start/#improve-existing-content) e [revisar alterações](https://kubernetes.io/docs/contribute/start/#review-docs-pull-requests). + +Algumas tarefas requerem mais confiança e mais acessos na organização do Kubernetes. +Veja [Participando no SIG Docs](/docs/contribute/participate/) para mais detalhes +sobre funções e permissões. + +## Sua primeira contribuição +- Leia sobre [visão geral para contribuição](/docs/contribute/new-content/overview/) para saber mais sobre diferentes formas para você contribuir. +- Veja a [lista de issues em `kubernetes/website`](https://github.com/kubernetes/website/issues/) para identificar issues que sejam um bom ponto de partida. +- [Abra um pull request usando o Github](/docs/contribute/new-content/open-a-pr/#changes-using-github) para documentações existentes e aprenda mais sobre resolver issues no Github. +- Leia sobre o [guia de conteúdo](/docs/contribute/style/content-guide/) e [guias de estilo](/docs/contribute/style/style-guide/). +- Leia sobre [tipos de conteúdo de páginas](/docs/contribute/style/page-content-types/) e [shortcodes do Hugo](/docs/contribute/style/hugo-shortcodes/). + +## Próximos passos + + - Aprenda a [trabalhar com um clone local](/docs/contribute/new-content/open-a-pr/#fork-the-repo) de um repositório. + - Documente [funcionalidades em uma release](/docs/contribute/new-content/new-features/). + - Participe do [SIG Docs](/docs/contribute/participate/), e se torne um + [membro ou revisor](/docs/contribute/participate/roles-and-responsibilities/). + - Comece ou ajude com uma [localização](/docs/contribute/localization/). + +## Se envolva com o SIG Docs + +O [SIG Docs](/docs/contribute/participate/) é um grupo de contribuidores que publica e mantém +a documentação e o site do Kubernetes. Se envolver com o SIG Docs é uma ótima forma de contribuidores Kubernetes (pessoas desenvolvedoras de features ou outros) terem um grande impacto dentro do projeto Kubernetes. + +A comunicação do SIG Docs é feita de diferentes formas: + - [Entre em `#sig-docs` no slack do Kubernetes](https://slack.k8s.io/). + - [Se inscreva na lista de email `kubernetes-dig-docs`](https://groups.google.com/forum/#!forum/kubernetes-sig-docs), onde acontecem discussões e + decisões oficiais são registradas. + - [Participe do encontro semanal do SIG Docs](https://github.com/kubernetes/community/tree/master/sig-docs). Os encontros são sempre anunciados no `#sig-docs` e adicionados ao [calendário de eventos de comunidade do Kubernetes](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). Você precisa baixar o [cliente do Zoom](https://zoom.us/download) ou usar um telefone. + +## Outras formas de contribuir + +- Para contribuir com a comunidade Kubernetes por meio de fóruns on-line, como Twitter ou Stack Overflow, ou aprender sobre encontros locais e eventos do Kubernetes, visite a area de [comunidade Kubernetes](/community/). +- Para contribuir com o desenvolvimento de novas funcionalidades, leia o [cheatsheet do colaborador](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) para começar. +- Leia o [cheatsheet de contribuidor](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) para saber mais sobre as funcionalidades de desenvolvimento do Kubernetes. +- Submeta [um post de blog ou um caso de estudo](/docs/contribute/new-content/blogs-case-studies/). + + + diff --git a/content/pt-br/docs/contribute/analytics.md b/content/pt-br/docs/contribute/analytics.md new file mode 100644 index 0000000000..305e0804cc --- /dev/null +++ b/content/pt-br/docs/contribute/analytics.md @@ -0,0 +1,28 @@ +--- +title: Visualizando Analytics do Site +content_type: concept +weight: 100 +card: + name: contribuir + weight: 100 +--- + + + +Essa página contém informações sobre a dashboard de analystics do kubernetes.io. + + + +Essa [dashboard](https://datastudio.google.com/reporting/fede2672-b2fd-402a-91d2-7473bdb10f04) foi feita usando +o Google Data Studio e possui informações coletadas do +kubernetes.io usando o Google Analytics. + +### Usando a dashboard + +Por padrão, a dashboard mostra todos os analytics coletados nos últimos 30 dias. Use o seletor de data +para ver dados de outros intervalos de data. Outras +opções de filtros permitem que você veja dados baseados +em localização do usuário para acessar o site, a tradução +da documentação usada e outros. + +Se você identificar um problema com essa dashboard ou quer solicitar qualquer melhoria, [abra uma issue](https://github.com/kubernetes/website/issues/new/choose) no repositório. diff --git a/content/pt/docs/home/_index.md b/content/pt-br/docs/home/_index.md similarity index 100% rename from content/pt/docs/home/_index.md rename to content/pt-br/docs/home/_index.md diff --git a/content/pt/docs/home/supported-doc-versions.md b/content/pt-br/docs/home/supported-doc-versions.md similarity index 100% rename from content/pt/docs/home/supported-doc-versions.md rename to content/pt-br/docs/home/supported-doc-versions.md diff --git a/content/pt/docs/reference/_index.md b/content/pt-br/docs/reference/_index.md similarity index 100% rename from content/pt/docs/reference/_index.md rename to content/pt-br/docs/reference/_index.md diff --git a/content/pt/docs/reference/access-authn-authz/authentication.md b/content/pt-br/docs/reference/access-authn-authz/authentication.md similarity index 100% rename from content/pt/docs/reference/access-authn-authz/authentication.md rename to content/pt-br/docs/reference/access-authn-authz/authentication.md diff --git a/content/pt/docs/reference/access-authn-authz/bootstrap-tokens.md b/content/pt-br/docs/reference/access-authn-authz/bootstrap-tokens.md similarity index 100% rename from content/pt/docs/reference/access-authn-authz/bootstrap-tokens.md rename to content/pt-br/docs/reference/access-authn-authz/bootstrap-tokens.md diff --git a/content/pt/docs/reference/glossary/alternate-x509-schemes.md b/content/pt-br/docs/reference/glossary/alternate-x509-schemes.md similarity index 100% rename from content/pt/docs/reference/glossary/alternate-x509-schemes.md rename to content/pt-br/docs/reference/glossary/alternate-x509-schemes.md diff --git a/content/pt/docs/reference/glossary/cloud-controller-manager.md b/content/pt-br/docs/reference/glossary/cloud-controller-manager.md similarity index 100% rename from content/pt/docs/reference/glossary/cloud-controller-manager.md rename to content/pt-br/docs/reference/glossary/cloud-controller-manager.md diff --git a/content/pt/docs/reference/glossary/cluster.md b/content/pt-br/docs/reference/glossary/cluster.md similarity index 100% rename from content/pt/docs/reference/glossary/cluster.md rename to content/pt-br/docs/reference/glossary/cluster.md diff --git a/content/pt/docs/reference/glossary/cncf.md b/content/pt-br/docs/reference/glossary/cncf.md similarity index 100% rename from content/pt/docs/reference/glossary/cncf.md rename to content/pt-br/docs/reference/glossary/cncf.md diff --git a/content/pt/docs/reference/glossary/cni.md b/content/pt-br/docs/reference/glossary/cni.md similarity index 100% rename from content/pt/docs/reference/glossary/cni.md rename to content/pt-br/docs/reference/glossary/cni.md diff --git a/content/pt/docs/reference/glossary/container-runtime.md b/content/pt-br/docs/reference/glossary/container-runtime.md similarity index 100% rename from content/pt/docs/reference/glossary/container-runtime.md rename to content/pt-br/docs/reference/glossary/container-runtime.md diff --git a/content/pt/docs/reference/glossary/containerd.md b/content/pt-br/docs/reference/glossary/containerd.md similarity index 100% rename from content/pt/docs/reference/glossary/containerd.md rename to content/pt-br/docs/reference/glossary/containerd.md diff --git a/content/pt/docs/reference/glossary/control-plane.md b/content/pt-br/docs/reference/glossary/control-plane.md similarity index 100% rename from content/pt/docs/reference/glossary/control-plane.md rename to content/pt-br/docs/reference/glossary/control-plane.md diff --git a/content/pt/docs/reference/glossary/controller.md b/content/pt-br/docs/reference/glossary/controller.md old mode 100755 new mode 100644 similarity index 100% rename from content/pt/docs/reference/glossary/controller.md rename to content/pt-br/docs/reference/glossary/controller.md diff --git a/content/pt/docs/reference/glossary/cri-o.md b/content/pt-br/docs/reference/glossary/cri-o.md similarity index 100% rename from content/pt/docs/reference/glossary/cri-o.md rename to content/pt-br/docs/reference/glossary/cri-o.md diff --git a/content/pt/docs/reference/glossary/cri.md b/content/pt-br/docs/reference/glossary/cri.md similarity index 100% rename from content/pt/docs/reference/glossary/cri.md rename to content/pt-br/docs/reference/glossary/cri.md diff --git a/content/pt/docs/reference/glossary/customresourcedefinition.md b/content/pt-br/docs/reference/glossary/customresourcedefinition.md old mode 100755 new mode 100644 similarity index 100% rename from content/pt/docs/reference/glossary/customresourcedefinition.md rename to content/pt-br/docs/reference/glossary/customresourcedefinition.md diff --git a/content/pt/docs/reference/glossary/etcd.md b/content/pt-br/docs/reference/glossary/etcd.md similarity index 100% rename from content/pt/docs/reference/glossary/etcd.md rename to content/pt-br/docs/reference/glossary/etcd.md diff --git a/content/pt-br/docs/reference/glossary/job.md b/content/pt-br/docs/reference/glossary/job.md new file mode 100644 index 0000000000..47a5b451c2 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/job.md @@ -0,0 +1,19 @@ +--- +title: Job +id: job +date: 2021-07-14 +full_link: /docs/concepts/workloads/controllers/job +short_description: > + Uma tarefa finita ou em lotes que executa até finalizar. + +aka: +tags: +- fundamental +- core-object +- workload +--- +Uma tarefa finita ou em lotes que executa até finalizar. + + + +Cria um ou mais objetos do tipo {{< glossary_tooltip term_id="pod" >}} e garante que um número determinado destes finaliza sua execução com sucesso. Conforme os Pods finalizam com sucesso, o Job observa as execuções bem-sucedidas. diff --git a/content/pt/docs/reference/glossary/kerberos.md b/content/pt-br/docs/reference/glossary/kerberos.md similarity index 100% rename from content/pt/docs/reference/glossary/kerberos.md rename to content/pt-br/docs/reference/glossary/kerberos.md diff --git a/content/pt/docs/reference/glossary/keystone.md b/content/pt-br/docs/reference/glossary/keystone.md similarity index 100% rename from content/pt/docs/reference/glossary/keystone.md rename to content/pt-br/docs/reference/glossary/keystone.md diff --git a/content/pt/docs/reference/glossary/kube-apiserver.md b/content/pt-br/docs/reference/glossary/kube-apiserver.md similarity index 100% rename from content/pt/docs/reference/glossary/kube-apiserver.md rename to content/pt-br/docs/reference/glossary/kube-apiserver.md diff --git a/content/pt/docs/reference/glossary/kube-controller-manager.md b/content/pt-br/docs/reference/glossary/kube-controller-manager.md similarity index 100% rename from content/pt/docs/reference/glossary/kube-controller-manager.md rename to content/pt-br/docs/reference/glossary/kube-controller-manager.md diff --git a/content/pt/docs/reference/glossary/kube-proxy.md b/content/pt-br/docs/reference/glossary/kube-proxy.md similarity index 100% rename from content/pt/docs/reference/glossary/kube-proxy.md rename to content/pt-br/docs/reference/glossary/kube-proxy.md diff --git a/content/pt/docs/reference/glossary/kube-scheduler.md b/content/pt-br/docs/reference/glossary/kube-scheduler.md similarity index 100% rename from content/pt/docs/reference/glossary/kube-scheduler.md rename to content/pt-br/docs/reference/glossary/kube-scheduler.md diff --git a/content/pt/docs/reference/glossary/kubelet.md b/content/pt-br/docs/reference/glossary/kubelet.md old mode 100755 new mode 100644 similarity index 100% rename from content/pt/docs/reference/glossary/kubelet.md rename to content/pt-br/docs/reference/glossary/kubelet.md diff --git a/content/pt/docs/reference/glossary/ldap.md b/content/pt-br/docs/reference/glossary/ldap.md similarity index 100% rename from content/pt/docs/reference/glossary/ldap.md rename to content/pt-br/docs/reference/glossary/ldap.md diff --git a/content/pt/docs/reference/glossary/node.md b/content/pt-br/docs/reference/glossary/node.md old mode 100755 new mode 100644 similarity index 100% rename from content/pt/docs/reference/glossary/node.md rename to content/pt-br/docs/reference/glossary/node.md diff --git a/content/pt/docs/reference/glossary/pod.md b/content/pt-br/docs/reference/glossary/pod.md old mode 100755 new mode 100644 similarity index 100% rename from content/pt/docs/reference/glossary/pod.md rename to content/pt-br/docs/reference/glossary/pod.md diff --git a/content/pt/docs/reference/glossary/saml.md b/content/pt-br/docs/reference/glossary/saml.md similarity index 100% rename from content/pt/docs/reference/glossary/saml.md rename to content/pt-br/docs/reference/glossary/saml.md diff --git a/content/pt/docs/reference/glossary/tls-common-name.md b/content/pt-br/docs/reference/glossary/tls-common-name.md similarity index 100% rename from content/pt/docs/reference/glossary/tls-common-name.md rename to content/pt-br/docs/reference/glossary/tls-common-name.md diff --git a/content/pt/docs/reference/glossary/uid.md b/content/pt-br/docs/reference/glossary/uid.md similarity index 100% rename from content/pt/docs/reference/glossary/uid.md rename to content/pt-br/docs/reference/glossary/uid.md diff --git a/content/pt/docs/reference/glossary/username.md b/content/pt-br/docs/reference/glossary/username.md similarity index 100% rename from content/pt/docs/reference/glossary/username.md rename to content/pt-br/docs/reference/glossary/username.md diff --git a/content/pt/docs/reference/kubectl/_index.md b/content/pt-br/docs/reference/kubectl/_index.md similarity index 100% rename from content/pt/docs/reference/kubectl/_index.md rename to content/pt-br/docs/reference/kubectl/_index.md diff --git a/content/pt/docs/reference/kubectl/cheatsheet.md b/content/pt-br/docs/reference/kubectl/cheatsheet.md similarity index 100% rename from content/pt/docs/reference/kubectl/cheatsheet.md rename to content/pt-br/docs/reference/kubectl/cheatsheet.md diff --git a/content/pt/docs/reference/tools.md b/content/pt-br/docs/reference/tools.md similarity index 100% rename from content/pt/docs/reference/tools.md rename to content/pt-br/docs/reference/tools.md diff --git a/content/pt/docs/setup/_index.md b/content/pt-br/docs/setup/_index.md similarity index 100% rename from content/pt/docs/setup/_index.md rename to content/pt-br/docs/setup/_index.md diff --git a/content/pt/docs/sitemap.md b/content/pt-br/docs/sitemap.md similarity index 100% rename from content/pt/docs/sitemap.md rename to content/pt-br/docs/sitemap.md diff --git a/content/pt/docs/tasks/_index.md b/content/pt-br/docs/tasks/_index.md similarity index 100% rename from content/pt/docs/tasks/_index.md rename to content/pt-br/docs/tasks/_index.md diff --git a/content/pt-br/docs/tasks/configmap-secret/_index.md b/content/pt-br/docs/tasks/configmap-secret/_index.md new file mode 100755 index 0000000000..b12622f4fd --- /dev/null +++ b/content/pt-br/docs/tasks/configmap-secret/_index.md @@ -0,0 +1,6 @@ +--- +title: "Gerenciando Secrets" +weight: 28 +description: Gerenciando dados de configurações usando Secrets. +--- + diff --git a/content/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file.md b/content/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file.md new file mode 100644 index 0000000000..0bac8410fa --- /dev/null +++ b/content/pt-br/docs/tasks/configmap-secret/managing-secret-using-config-file.md @@ -0,0 +1,193 @@ +--- +title: Gerenciando Secret usando Arquivo de Configuração +content_type: task +weight: 20 +description: Criando objetos Secret usando arquivos de configuração de recursos. +--- + + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + + + +## Crie o arquivo de configuração + +Você pode criar um Secret primeiramente em um arquivo, no formato JSON ou YAML, e depois +criar o objeto. O recurso [Secret](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core) +contém dois mapas: `data` e `stringData`. +O campo `data` é usado para armazenar dados arbitrários, codificados usando base64. O +campo `stringData` é usado por conveniência, e permite que você use dados para um Secret +como *strings* não codificadas. +As chaves para `data` e `stringData` precisam ser compostas por caracteres alfanuméricos, +`_`, `-` ou `.`. + +Por exemplo, para armazenar duas strings em um Secret usando o campo `data`, converta +as strings para base64 da seguinte forma: + +```shell +echo -n 'admin' | base64 +``` +A saída deve ser similar a: + +``` +YWRtaW4= +``` + +```shell +echo -n '1f2d1e2e67df' | base64 +``` + +A saída deve ser similar a: + +``` +MWYyZDFlMmU2N2Rm +``` + +Escreva o arquivo de configuração do Secret, que será parecido com: +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + username: YWRtaW4= + password: MWYyZDFlMmU2N2Rm +``` + +Perceba que o nome do objeto Secret precisa ser um +[nome de subdomínio DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-name) válido. + +{{< note >}} +Os valores serializados dos dados JSON e YAML de um Secret são codificados em strings +base64. Novas linhas não são válidas com essas strings e devem ser omitidas. Quando +usar o utilitário `base64` em Darwin/MacOS, os usuários devem evitar usar a opção `-b` +para separar linhas grandes. Por outro lado, usuários de Linux *devem* adicionar a opção +`-w 0` ao comando `base64` ou o *pipe* `base64 | tr -d '\n'` se a opção `w` não estiver disponível +{{< /note >}} + +Para cenários específicos, você pode querer usar o campo `stringData` ao invés de `data`. +Esse campo permite que você use strings não-base64 diretamente dentro do Secret, +e a string vai ser codificada para você quando o Secret for criado ou atualizado. + +Um exemplo prático para isso pode ser quando você esteja fazendo *deploy* de uma aplicação +que usa um Secret para armazenar um arquivo de configuração, e você quer popular partes desse +arquivo de configuração durante o processo de implantação. + +Por exemplo, se sua aplicação usa o seguinte arquivo de configuração: + +```yaml +apiUrl: "https://my.api.com/api/v1" +username: "" +password: "" +``` + +Você pode armazenar isso em um Secret usando a seguinte definição: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +stringData: + config.yaml: | + apiUrl: "https://my.api.com/api/v1" + username: + password: +``` + +## Crie o objeto Secret + +Agora, crie o Secret usando [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply): + +```shell +kubectl apply -f ./secret.yaml +``` + +A saída deve ser similar a: + +``` +secret/mysecret created +``` + +## Verifique o Secret + +O campo `stringData` é um campo de conveniência apenas de leitura. Ele nunca vai ser exibido +ao buscar um Secret. Por exemplo, se você executar o seguinte comando: + +```shell +kubectl get secret mysecret -o yaml +``` + +A saída deve ser similar a: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + creationTimestamp: 2018-11-15T20:40:59Z + name: mysecret + namespace: default + resourceVersion: "7225" + uid: c280ad2e-e916-11e8-98f2-025000000001 +type: Opaque +data: + config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19 +``` + +Os comandos `kubectl get` e `kubectl describe` omitem o conteúdo de um `Secret` por padrão. +Isso para proteger o `Secret` de ser exposto acidentalmente para uma pessoa não autorizada, +ou ser armazenado em um log de terminal. +Para verificar o conteúdo atual de um dado codificado, veja [decodificando secret](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret). + +Se um campo, como `username`, é especificado em `data` e `stringData`, +o valor de `stringData` é o usado. Por exemplo, dada a seguinte definição do Secret: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: mysecret +type: Opaque +data: + username: YWRtaW4= +stringData: + username: administrator +``` + +Resulta no seguinte Secret: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + creationTimestamp: 2018-11-15T20:46:46Z + name: mysecret + namespace: default + resourceVersion: "7579" + uid: 91460ecb-e917-11e8-98f2-025000000001 +type: Opaque +data: + username: YWRtaW5pc3RyYXRvcg== +``` + +Onde `YWRtaW5pc3RyYXRvcg==` é decodificado em `administrator`. + +## Limpeza + +Para apagar o Secret que você criou: + +```shell +kubectl delete secret mysecret +``` + +## {{% heading "whatsnext" %}} + +- Leia mais sobre o [conceito do Secret](/docs/concepts/configuration/secret/) +- Leia sobre como [gerenciar Secret com o comando `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- Leia sobre como [gerenciar Secret usando kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) + diff --git a/content/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl.md b/content/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl.md new file mode 100644 index 0000000000..575bc13253 --- /dev/null +++ b/content/pt-br/docs/tasks/configmap-secret/managing-secret-using-kubectl.md @@ -0,0 +1,152 @@ +--- +title: Gerenciando Secret usando kubectl +content_type: task +weight: 10 +description: Criando objetos Secret usando a linha de comando kubectl. +--- + + + +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + + + +## Criando um Secret + +Um `Secret` pode conter credenciais de usuário requeridas por Pods para acesso a um banco de dados. +Por exemplo, uma string de conexão de banco de dados é composta por um usuário e senha. +Você pode armazenar o usuário em um arquivo `./username.txt` e a senha em um +arquivo `./password.txt` na sua máquina local. + +```shell +echo -n 'admin' > ./username.txt +echo -n '1f2d1e2e67df' > ./password.txt +``` + +A opção `-n` nos comandos acima garante que os arquivos criados não vão conter +uma nova linha extra no final do arquivo de texto. Isso é importante porque +quando o `kubectl` lê um arquivo e codifica o conteúdo em uma string base64, +o caractere da nova linha extra também é codificado. + +O comando `kubectl create secret` empacota os arquivos em um Secret e cria um +objeto no API server. + + +```shell +kubectl create secret generic db-user-pass \ + --from-file=./username.txt \ + --from-file=./password.txt +``` + +A saída deve ser similar a: + +``` +secret/db-user-pass created +``` + +O nome da chave padrão é o nome do arquivo. Opcionalmente, você pode definir +o nome da chave usando `--from-file=[key=]source`. Por exemplo: + +```shell +kubectl create secret generic db-user-pass \ + --from-file=username=./username.txt \ + --from-file=password=./password.txt +``` +Você não precisa escapar o caractere especial em senhas a partir de arquivos (`--from-file`). + +Você também pode prover dados para Secret usando a tag `--from-literal==`. +Essa tag pode ser especificada mais de uma vez para prover múltiplos pares de chave-valor. +Observe que caracteres especiais como `$`, `\`, `*`, `=`, e `!` vão ser interpretados +pelo seu [shell](https://en.wikipedia.org/wiki/Shell_(computing)) e precisam ser escapados. +Na maioria dos shells, a forma mais fácil de escapar as senhas é usar aspas simples (`'`). +Por exemplo, se sua senha atual é `S!B\*d$zDsb=`, você precisa executar o comando dessa forma: + +```shell +kubectl create secret generic db-user-pass \ + --from-literal=username=devuser \ + --from-literal=password='S!B\*d$zDsb=' +``` + +## Verificando o Secret + +Você pode verificar se o secret foi criado: + +```shell +kubectl get secrets +``` + +A saída deve ser similar a: + +``` +NAME TYPE DATA AGE +db-user-pass Opaque 2 51s +``` + +Você pode ver a descrição do `Secret`: + +```shell +kubectl describe secrets/db-user-pass +``` +A saída deve ser similar a: + +``` +Name: db-user-pass +Namespace: default +Labels: +Annotations: + +Type: Opaque + +Data +==== +password: 12 bytes +username: 5 bytes +``` + +Os comandos `kubectl get` e `kubectl describe` omitem o conteúdo de um `Secret` por padrão. +Isso para proteger o `Secret` de ser exposto acidentalmente para uma pessoa não autorizada, +ou ser armazenado em um log de terminal. + +## Decodificando o Secret {#decoding-secret} + +Para ver o conteúdo de um Secret que você criou, execute o seguinte comando: + +```shell +kubectl get secret db-user-pass -o jsonpath='{.data}' +``` + +A saída deve ser similar a: + +```json +{"password":"MWYyZDFlMmU2N2Rm","username":"YWRtaW4="} +``` + +Agora, você pode decodificar os dados de `password`: + +```shell +echo 'MWYyZDFlMmU2N2Rm' | base64 --decode +``` + +A saída deve ser similar a: + +``` +1f2d1e2e67df +``` + +## Limpeza + +Para apagar o Secret que você criou: + +```shell +kubectl delete secret db-user-pass +``` + + + +## {{% heading "whatsnext" %}} + +- Leia mais sobre o [conceito do Secret](/docs/concepts/configuration/secret/) +- Leia sobre como [gerenciar Secret com o comando `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- Leia sobre como [gerenciar Secret usando kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) diff --git a/content/pt-br/docs/tasks/configmap-secret/managing-secret-using-kustomize.md b/content/pt-br/docs/tasks/configmap-secret/managing-secret-using-kustomize.md new file mode 100644 index 0000000000..1658afc3de --- /dev/null +++ b/content/pt-br/docs/tasks/configmap-secret/managing-secret-using-kustomize.md @@ -0,0 +1,122 @@ +--- +title: Gerenciando Secret usando Kustomize +content_type: task +weight: 30 +description: Criando objetos Secret usando o arquivo kustomization.yaml +--- + + + +Desde o Kubernetes v1.14, o `kubectl` provê suporte para [gerenciamento de objetos usando Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/). +O Kustomize provê geradores de recursos para criar Secrets e ConfigMaps. +Os geradores Kustomize devem ser especificados em um arquivo `kustomization.yaml` dentro +de um diretório. Depois de gerar o Secret, você pode criar o Secret com `kubectl apply`. +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + + + +## Criando um arquivo de Kustomization +Você pode criar um Secret definindo um `secretGenerator` em um +arquivo `kustomization.yaml` que referencia outros arquivos existentes. +Por exemplo, o seguinte arquivo kustomization referencia os +arquivos `./username.txt` e `./password.txt`: + +```yaml +secretGenerator: +- name: db-user-pass + files: + - username.txt + - password.txt +``` + +Você também pode definir o `secretGenerator` no arquivo `kustomization.yaml` +por meio de alguns *literais*. +Por exemplo, o seguinte arquivo `kustomization.yaml` contém dois literais +para `username` e `password` respectivamente: + +```yaml +secretGenerator: +- name: db-user-pass + literals: + - username=admin + - password=1f2d1e2e67df +``` + +Observe que nos dois casos, você não precisa codificar os valores em base64. + +## Criando o Secret + +Aplique o diretório que contém o arquivo `kustomization.yaml` para criar o Secret. + +```shell +kubectl apply -k . +``` + +A saída deve ser similar a: + +``` +secret/db-user-pass-96mffmfh4k created +``` + +Observe que quando um Secret é gerado, o nome do segredo é criado usando o hash +dos dados do Secret mais o valor do hash. Isso garante que +um novo Secret é gerado cada vez que os dados são modificados. + +## Verifique o Secret criado + +Você pode verificar que o secret foi criado: + +```shell +kubectl get secrets +``` + +A saída deve ser similar a: + +``` +NAME TYPE DATA AGE +db-user-pass-96mffmfh4k Opaque 2 51s +``` + +Você pode ver a descrição de um secret: + +```shell +kubectl describe secrets/db-user-pass-96mffmfh4k +``` +A saída deve ser similar a: + +``` +Name: db-user-pass-96mffmfh4k +Namespace: default +Labels: +Annotations: + +Type: Opaque + +Data +==== +password.txt: 12 bytes +username.txt: 5 bytes +``` + +Os comandos `kubectl get` e `kubectl describe` omitem o conteúdo de um `Secret` por padrão. +Isso para proteger o `Secret` de ser exposto acidentalmente para uma pessoa não autorizada, +ou ser armazenado em um log de terminal. +Para verificar o conteúdo atual de um dado codificado, veja [decodificando secret](/docs/tasks/configmap-secret/managing-secret-using-kubectl/#decoding-secret). + +## Limpeza + +Para apagar o Secret que você criou: + +```shell +kubectl delete secret db-user-pass-96mffmfh4k +``` + + +## {{% heading "whatsnext" %}} + +- Leia mais sobre o [conceito do Secret](/docs/concepts/configuration/secret/) +- Leia sobre como [gerenciar Secret com o comando `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- Leia sobre como [gerenciar Secret usando kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/) + diff --git a/content/pt/docs/templates/feature-state-alpha.txt b/content/pt-br/docs/templates/feature-state-alpha.txt similarity index 100% rename from content/pt/docs/templates/feature-state-alpha.txt rename to content/pt-br/docs/templates/feature-state-alpha.txt diff --git a/content/pt/docs/templates/feature-state-beta.txt b/content/pt-br/docs/templates/feature-state-beta.txt similarity index 100% rename from content/pt/docs/templates/feature-state-beta.txt rename to content/pt-br/docs/templates/feature-state-beta.txt diff --git a/content/pt/docs/templates/feature-state-deprecated.txt b/content/pt-br/docs/templates/feature-state-deprecated.txt similarity index 100% rename from content/pt/docs/templates/feature-state-deprecated.txt rename to content/pt-br/docs/templates/feature-state-deprecated.txt diff --git a/content/pt/docs/templates/feature-state-stable.txt b/content/pt-br/docs/templates/feature-state-stable.txt similarity index 100% rename from content/pt/docs/templates/feature-state-stable.txt rename to content/pt-br/docs/templates/feature-state-stable.txt diff --git a/content/pt/docs/templates/index.md b/content/pt-br/docs/templates/index.md similarity index 100% rename from content/pt/docs/templates/index.md rename to content/pt-br/docs/templates/index.md diff --git a/content/pt/docs/tutorials/_index.md b/content/pt-br/docs/tutorials/_index.md similarity index 100% rename from content/pt/docs/tutorials/_index.md rename to content/pt-br/docs/tutorials/_index.md diff --git a/content/pt/docs/tutorials/hello-minikube.md b/content/pt-br/docs/tutorials/hello-minikube.md similarity index 100% rename from content/pt/docs/tutorials/hello-minikube.md rename to content/pt-br/docs/tutorials/hello-minikube.md diff --git a/content/pt/docs/tutorials/kubernetes-basics/_index.html b/content/pt-br/docs/tutorials/kubernetes-basics/_index.html similarity index 95% rename from content/pt/docs/tutorials/kubernetes-basics/_index.html rename to content/pt-br/docs/tutorials/kubernetes-basics/_index.html index b397afba37..10b721c3c7 100644 --- a/content/pt/docs/tutorials/kubernetes-basics/_index.html +++ b/content/pt-br/docs/tutorials/kubernetes-basics/_index.html @@ -27,10 +27,10 @@ card:

    Este tutorial fornece instruções básicas sobre o sistema de orquestração de cluster do Kubernetes. Cada módulo contém algumas informações básicas sobre os principais recursos e conceitos do Kubernetes e inclui um tutorial online interativo. Esses tutoriais interativos permitem que você mesmo gerencie um cluster simples e seus aplicativos em contêineres.

    Usando os tutoriais interativos, você pode aprender a:

      -
    • Implante um aplicativo em contêiner em um cluster.
      • -
    • Dimensione a implantação.
      • -
    • Atualize o aplicativo em contêiner com uma nova versão do software.
      • -
    • Depure o aplicativo em contêiner.
      • +
    • Implantar um aplicativo em contêiner em um cluster.
      • +
    • Dimensionar a implantação.
      • +
    • Atualizar o aplicativo em contêiner com uma nova versão do software.
      • +
    • Depurar o aplicativo em contêiner.

    Os tutoriais usam Katacoda para executar um terminal virtual em seu navegador da Web, executado em Minikube, uma implantação local em pequena escala do Kubernetes que pode ser executada em qualquer lugar. Não há necessidade de instalar nenhum software ou configurar nada; cada tutorial interativo é executado diretamente no navegador da web.

    diff --git a/content/pt/docs/tutorials/kubernetes-basics/create-cluster/_index.md b/content/pt-br/docs/tutorials/kubernetes-basics/create-cluster/_index.md similarity index 100% rename from content/pt/docs/tutorials/kubernetes-basics/create-cluster/_index.md rename to content/pt-br/docs/tutorials/kubernetes-basics/create-cluster/_index.md diff --git a/content/pt/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/pt-br/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html similarity index 100% rename from content/pt/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html rename to content/pt-br/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html diff --git a/content/pt/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html b/content/pt-br/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html similarity index 100% rename from content/pt/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html rename to content/pt-br/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro.html diff --git a/content/pt/docs/tutorials/kubernetes-basics/deploy-app/_index.md b/content/pt-br/docs/tutorials/kubernetes-basics/deploy-app/_index.md similarity index 100% rename from content/pt/docs/tutorials/kubernetes-basics/deploy-app/_index.md rename to content/pt-br/docs/tutorials/kubernetes-basics/deploy-app/_index.md diff --git a/content/pt/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/pt-br/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html similarity index 100% rename from content/pt/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html rename to content/pt-br/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html diff --git a/content/pt/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/pt-br/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html similarity index 100% rename from content/pt/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html rename to content/pt-br/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html diff --git a/content/pt/docs/tutorials/kubernetes-basics/explore/_index.md b/content/pt-br/docs/tutorials/kubernetes-basics/explore/_index.md similarity index 100% rename from content/pt/docs/tutorials/kubernetes-basics/explore/_index.md rename to content/pt-br/docs/tutorials/kubernetes-basics/explore/_index.md diff --git a/content/pt/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/pt-br/docs/tutorials/kubernetes-basics/explore/explore-interactive.html similarity index 100% rename from content/pt/docs/tutorials/kubernetes-basics/explore/explore-interactive.html rename to content/pt-br/docs/tutorials/kubernetes-basics/explore/explore-interactive.html diff --git a/content/pt/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/pt-br/docs/tutorials/kubernetes-basics/explore/explore-intro.html similarity index 100% rename from content/pt/docs/tutorials/kubernetes-basics/explore/explore-intro.html rename to content/pt-br/docs/tutorials/kubernetes-basics/explore/explore-intro.html diff --git a/content/pt/docs/tutorials/kubernetes-basics/expose/_index.md b/content/pt-br/docs/tutorials/kubernetes-basics/expose/_index.md similarity index 100% rename from content/pt/docs/tutorials/kubernetes-basics/expose/_index.md rename to content/pt-br/docs/tutorials/kubernetes-basics/expose/_index.md diff --git a/content/pt/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/pt-br/docs/tutorials/kubernetes-basics/expose/expose-interactive.html similarity index 100% rename from content/pt/docs/tutorials/kubernetes-basics/expose/expose-interactive.html rename to content/pt-br/docs/tutorials/kubernetes-basics/expose/expose-interactive.html diff --git a/content/pt/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/pt-br/docs/tutorials/kubernetes-basics/expose/expose-intro.html similarity index 100% rename from content/pt/docs/tutorials/kubernetes-basics/expose/expose-intro.html rename to content/pt-br/docs/tutorials/kubernetes-basics/expose/expose-intro.html diff --git a/content/pt/docs/tutorials/kubernetes-basics/scale/_index.md b/content/pt-br/docs/tutorials/kubernetes-basics/scale/_index.md similarity index 100% rename from content/pt/docs/tutorials/kubernetes-basics/scale/_index.md rename to content/pt-br/docs/tutorials/kubernetes-basics/scale/_index.md diff --git a/content/pt/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/pt-br/docs/tutorials/kubernetes-basics/scale/scale-interactive.html similarity index 100% rename from content/pt/docs/tutorials/kubernetes-basics/scale/scale-interactive.html rename to content/pt-br/docs/tutorials/kubernetes-basics/scale/scale-interactive.html diff --git a/content/pt/docs/tutorials/kubernetes-basics/scale/scale-intro.html b/content/pt-br/docs/tutorials/kubernetes-basics/scale/scale-intro.html similarity index 100% rename from content/pt/docs/tutorials/kubernetes-basics/scale/scale-intro.html rename to content/pt-br/docs/tutorials/kubernetes-basics/scale/scale-intro.html diff --git a/content/pt/examples/admin/logging/fluentd-sidecar-config.yaml b/content/pt-br/examples/admin/logging/fluentd-sidecar-config.yaml similarity index 100% rename from content/pt/examples/admin/logging/fluentd-sidecar-config.yaml rename to content/pt-br/examples/admin/logging/fluentd-sidecar-config.yaml diff --git a/content/pt/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml b/content/pt-br/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml similarity index 100% rename from content/pt/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml rename to content/pt-br/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml diff --git a/content/pt/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml b/content/pt-br/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml similarity index 100% rename from content/pt/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml rename to content/pt-br/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml diff --git a/content/pt/examples/admin/logging/two-files-counter-pod.yaml b/content/pt-br/examples/admin/logging/two-files-counter-pod.yaml similarity index 100% rename from content/pt/examples/admin/logging/two-files-counter-pod.yaml rename to content/pt-br/examples/admin/logging/two-files-counter-pod.yaml diff --git a/content/pt-br/examples/application/job/cronjob.yaml b/content/pt-br/examples/application/job/cronjob.yaml new file mode 100644 index 0000000000..da905a9048 --- /dev/null +++ b/content/pt-br/examples/application/job/cronjob.yaml @@ -0,0 +1,19 @@ +apiVersion: batch/v1 +kind: CronJob +metadata: + name: hello +spec: + schedule: "*/1 * * * *" + jobTemplate: + spec: + template: + spec: + containers: + - name: hello + image: busybox + imagePullPolicy: IfNotPresent + command: + - /bin/sh + - -c + - date; echo Hello from the Kubernetes cluster + restartPolicy: OnFailure diff --git a/content/pt/examples/debug/counter-pod.yaml b/content/pt-br/examples/debug/counter-pod.yaml similarity index 100% rename from content/pt/examples/debug/counter-pod.yaml rename to content/pt-br/examples/debug/counter-pod.yaml diff --git a/content/pt-br/examples/service/networking/network-policy-allow-all-egress.yaml b/content/pt-br/examples/service/networking/network-policy-allow-all-egress.yaml new file mode 100644 index 0000000000..42b2a2a296 --- /dev/null +++ b/content/pt-br/examples/service/networking/network-policy-allow-all-egress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-egress +spec: + podSelector: {} + egress: + - {} + policyTypes: + - Egress diff --git a/content/pt-br/examples/service/networking/network-policy-allow-all-ingress.yaml b/content/pt-br/examples/service/networking/network-policy-allow-all-ingress.yaml new file mode 100644 index 0000000000..462912dae4 --- /dev/null +++ b/content/pt-br/examples/service/networking/network-policy-allow-all-ingress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-ingress +spec: + podSelector: {} + ingress: + - {} + policyTypes: + - Ingress diff --git a/content/pt-br/examples/service/networking/network-policy-default-deny-all.yaml b/content/pt-br/examples/service/networking/network-policy-default-deny-all.yaml new file mode 100644 index 0000000000..5c0086bd71 --- /dev/null +++ b/content/pt-br/examples/service/networking/network-policy-default-deny-all.yaml @@ -0,0 +1,10 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-all +spec: + podSelector: {} + policyTypes: + - Ingress + - Egress diff --git a/content/pt-br/examples/service/networking/network-policy-default-deny-egress.yaml b/content/pt-br/examples/service/networking/network-policy-default-deny-egress.yaml new file mode 100644 index 0000000000..a4659e1417 --- /dev/null +++ b/content/pt-br/examples/service/networking/network-policy-default-deny-egress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-egress +spec: + podSelector: {} + policyTypes: + - Egress diff --git a/content/pt-br/examples/service/networking/network-policy-default-deny-ingress.yaml b/content/pt-br/examples/service/networking/network-policy-default-deny-ingress.yaml new file mode 100644 index 0000000000..e823802487 --- /dev/null +++ b/content/pt-br/examples/service/networking/network-policy-default-deny-ingress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-ingress +spec: + podSelector: {} + policyTypes: + - Ingress diff --git a/content/pt/includes/index.md b/content/pt-br/includes/index.md similarity index 100% rename from content/pt/includes/index.md rename to content/pt-br/includes/index.md diff --git a/content/pt-br/includes/task-tutorial-prereqs.md b/content/pt-br/includes/task-tutorial-prereqs.md new file mode 100644 index 0000000000..eb4177b4fd --- /dev/null +++ b/content/pt-br/includes/task-tutorial-prereqs.md @@ -0,0 +1,6 @@ +Você precisa de um cluster Kubernetes e a ferramenta de linha de comando kubectl +precisa estar configurada para acessar o seu cluster. Se você ainda não tem um +cluster, pode criar um usando o [minikube](/docs/tasks/tools/#minikube) +ou você pode usar um dos seguintes ambientes: +* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground) +* [Play with Kubernetes](http://labs.play-with-k8s.com/) diff --git a/content/pt/partners/_index.html b/content/pt-br/partners/_index.html similarity index 100% rename from content/pt/partners/_index.html rename to content/pt-br/partners/_index.html diff --git a/content/pt/docs/concepts/cluster-administration/addons.md b/content/pt/docs/concepts/cluster-administration/addons.md deleted file mode 100644 index 0a50c96190..0000000000 --- a/content/pt/docs/concepts/cluster-administration/addons.md +++ /dev/null @@ -1,58 +0,0 @@ ---- -title: Instalando Addons -content_type: concept ---- - - - - -Addons estendem a funcionalidade do Kubernetes. - -Esta página lista alguns dos add-ons e links com suas respectivas instruções de instalação. - -Os Add-ons de cada sessão são classificados em ordem alfabética - a ordem não implica qualquer status preferencial. - - - - - - -## Rede e Política de Rede - - -* [ACI](https://www.github.com/noironetworks/aci-containers) fornece rede integrada de contêineres e segurança de rede com a Cisco ACI. -* [Calico](https://docs.projectcalico.org/latest/getting-started/kubernetes/) é um provedor de políticas de rede e rede L3 seguro. -* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) une Flannel e Calico, fornecendo rede e política de rede. -* [Cilium](https://github.com/cilium/cilium) é um plug-in de políticas de rede e rede L3 que pode impor políticas de HTTP / API / L7 de forma transparente. Tanto o modo de roteamento quanto o de sobreposição / encapsulamento são suportados. -* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) permite que o Kubernetes se conecte facilmente a uma variedade de plugins CNI, como Calico, Canal, Flannel, Romana ou Weave. -* [Contiv](http://contiv.github.io) fornece um rede configurável (L3 nativa usando BGP, sobreposição usando vxlan, L2 clássico e Cisco-SDN / ACI) para vários casos de uso e uma estrutura rica de políticas de rede. O projeto Contiv é totalmente [open source](http://github.com/contiv). O script de [instalação](http://github.com/contiv/install) fornece opções de instalação com ou sem kubeadm. -* [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), baseado no [Tungsten Fabric](https://tungsten.io), é um projeto open source, multi-cloud com uma rede virtualizada e com uma plataforma de gerenciamento de políticas de rede. O Contrail e o Tungsten Fabric estão integrados a sistemas de orquestração, como Kubernetes, OpenShift, OpenStack e Mesos, e fornecem modos de isolamento para máquinas virtuais, containers / pods e cargas em servidores físicos. -* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) é um provedor de rede de sobreposição que pode ser usado com o Kubernetes. -* [Knitter](https://github.com/ZTE/Knitter/) é uma solução de rede que suporta múltiplas redes no Kubernetes. -* [Multus](https://github.com/Intel-Corp/multus-cni) é um plugin Multi para suporte a várias redes no Kubernetes para suportar todos os plugins CNI (por exemplo, Calico, Cilium, Contiv, Flannel), além das cargas de trabalho baseadas em SRIOV, DPDK, OVS-DPDK e VPP no Kubernetes. -* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) O Plugin de contêiner (NCP) fornece integração entre o VMware NSX-T e orquestradores de contêineres como o Kubernetes, além da integração entre o NSX-T e as plataformas CaaS / PaaS baseadas em contêiner, como Pivotal Container Service (PKS) e OpenShift. -* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) é uma plataforma SDN que fornece uma rede baseada em políticas entre os Pods Kubernetes e os ambientes não-Kubernetes, com visibilidade e monitoramento de segurança. -* [Romana](http://romana.io) é uma solução de rede Camada 3 para redes de pods que também suporta [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Detalhes da instalação do add-on Kubeadm disponíveis [aqui](https://github.com/romana/romana/tree/master/containerize). -* [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) fornece rede e política de rede, continuará trabalhando em ambos os lados de uma partição de rede e não requer um banco de dados externo. - -## Descoberta de Serviço - -* [CoreDNS](https://coredns.io) é um servidor DNS flexível e extensível que pode ser [instalado](https://github.com/coredns/deployment/tree/master/kubernetes) como DNS dentro do cluster para ser utilizado por pods. - -## Visualização & Controle - -* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) é uma interface web para gestão do Kubernetes. -* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) é uma ferramenta gráfica para visualizar contêineres, pods, serviços etc. Use-o em conjunto com o [Weave Cloud account](https://cloud.weave.works/) ou hospede você mesmo a interface do usuário. - -## A infraestrutura - -* [KubeVirt](https://kubevirt.io/user-guide/docs/latest/administration/intro.html#cluster-side-add-on-deployment) é um add-on para executar máquinas virtuais no Kubernetes. É geralmente executado em clusters em maquina fisica. - - -## Add-ons Legado - -Existem vários outros complementos documentados no diretório não mais ultilizados [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons). - -Projetos bem mantidos deveriam ser linkados aqui. PRs são bem vindas! - - diff --git a/content/pt/docs/concepts/workloads/controllers/cron-jobs.md b/content/pt/docs/concepts/workloads/controllers/cron-jobs.md deleted file mode 100644 index 669d3276d4..0000000000 --- a/content/pt/docs/concepts/workloads/controllers/cron-jobs.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -reviewers: - - erictune - - soltysh - - janetkuo -title: CronJob -content_type: concept -weight: 80 ---- - - - -{{< feature-state for_k8s_version="v1.8" state="beta" >}} - -Um _Cron Job_ cria [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) em um cronograma baseado em tempo. - -Um objeto CronJob é como um arquivo _crontab_ (tabela cron). Executa um job periodicamente em um determinado horário, escrito no formato [Cron](https://en.wikipedia.org/wiki/Cron). - -{{< note >}} -Todos os **CronJob** `schedule (horários):` são indicados em UTC. -{{< /note >}} - -Ao criar o manifesto para um recurso CronJob, verifique se o nome que você fornece é um [nome de subdomínio DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido. -O nome não deve ter mais que 52 caracteres. Isso ocorre porque o controlador do CronJob anexará automaticamente 11 caracteres ao nome da tarefa fornecido e há uma restrição de que o comprimento máximo de um nome da tarefa não pode ultrapassar 63 caracteres. - -Para obter instruções sobre como criar e trabalhar com tarefas cron, e para obter um exemplo de arquivo de especificação para uma tarefa cron, consulte [Executando tarefas automatizadas com tarefas cron](/docs/tasks/job/automated-tasks-with-cron-jobs). - - - - - -## Limitações do Cron Job - -Um trabalho cron cria um objeto de trabalho _about_ uma vez por tempo de execução de seu planejamento, Dizemos "about" porque há certas circunstâncias em que duas tarefas podem ser criadas ou nenhum trabalho pode ser criado. Tentamos torná-los únicos, mas não os impedimos completamente. Portanto, os trabalhos devem ser _idempotente_. - -Se `startingDeadlineSeconds` estiver definido como um valor grande ou não definido (o padrão) e se `concurrencyPolicy` estiver definido como `Allow(Permitir)` os trabalhos sempre serão executados pelo menos uma vez. - -Para cada CronJob, o CronJob {{< glossary_tooltip term_id="controller" >}} verifica quantas agendas faltou na duração, desde o último horário agendado até agora. Se houver mais de 100 agendamentos perdidos, ele não iniciará o trabalho e registrará o erro - -``` -Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew. -``` - -É importante observar que, se o campo `startingDeadlineSeconds` estiver definido (não `nil`), o controlador contará quantas tarefas perdidas ocorreram a partir do valor de `startingDeadlineSeconds` até agora, e não do último horário programado até agora. Por exemplo, se `startingDeadlineSeconds` for `200`, o controlador contará quantas tarefas perdidas ocorreram nos últimos 200 segundos. - -Um CronJob é contado como perdido se não tiver sido criado no horário agendado. Por exemplo, se `concurrencyPolicy` estiver definido como `Forbid` e um CronJob tiver sido tentado ser agendado quando havia um agendamento anterior ainda em execução, será contabilizado como perdido. - -Por exemplo, suponha que um CronJob esteja definido para agendar um novo trabalho a cada minuto, começando em `08:30:00`, e seu campo `startingDeadlineSeconds` não esteja defindo. Se o controlador CronJob estiver baixo de `08:29:00` para `10:21:00`, o trabalho não será iniciado, pois o número de trabalhos perdidos que perderam o cronograma é maior que 100. - -Para ilustrar ainda mais esse conceito, suponha que um CronJob esteja definido para agendar um novo trabalho a cada minuto, começando em `08:30:00`, e seu `startingDeadlineSeconds` está definido em 200 segundos. Se o controlador CronJob estiver inativo no mesmo período do exemplo anterior (`08:29:00` a `10:21:00`), o trabalho ainda será iniciado às 10:22:00. Isso acontece pois o controlador agora verifica quantos agendamentos perdidos ocorreram nos últimos 200 segundos (ou seja, 3 agendamentos perdidos), em vez do último horário agendado até agora. - -O CronJob é responsável apenas pela criação de trabalhos que correspondem à sua programação, e o trabalho, por sua vez, é responsável pelo gerenciamento dos Pods que ele representa. - - diff --git a/content/pt/docs/contribute/_index.md b/content/pt/docs/contribute/_index.md deleted file mode 100644 index 86c4d92967..0000000000 --- a/content/pt/docs/contribute/_index.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -content_type: concept -title: Contribua com o Kubernetes docs -linktitle: Contribute -main_menu: true -weight: 80 ---- - - - -Caso você gostaria de contribuir com a documentação ou o site do Kubernetes, -ficamos felizes em ter sua ajuda! Qualquer pessoa pode contribuir, seja você novo no -projeto ou se você já esta no mercado há muito tempo. Além disso, Se você se identifica como -desenvolvedor, usuário final ou alguém que simplesmente não suporta ver erros de digitação. - - - - -## Começando - -Qualquer pessoa pode abrir uma issue descrevendo o problema ou melhorias desejadas com a documentação ou contribuir com uma alteração e uma solicitação de mudança (Pull Request - PR). -Algumas tarefas exigem mais confiança e precisam de mais acesso na organização Kubernetes. -Veja [Participando do SIG Docs](/docs/contribute/participating/) para mais detalhes sobre -as funções e permissões. - -A documentação do Kubernetes reside em um repositório do GitHub. Nós damos as boas-vindas -a todas as contribuições, mas você vai precisa estar familiarizado com o uso básico de git e GitHub para -operar efetivamente na comunidade Kubernetes. - -Para se envolver com a documentação: - -1. Assine o [Contrato de Licença de Colaborador](https://github.com/kubernetes/community/blob/master/CLA.md) do CNCF. -2. Familiarize-se com o [repositório de documentação](https://github.com/kubernetes/website) e o [gerador de site estático](https://gohugo.io) hugo. -3. Certifique-se de entender os processos básicos para [melhorar o conteúdo](https://kubernetes.io/docs/contribute/start/#improve-existing-content) e [revisar alterações](https://kubernetes.io/docs/contribute/start/#review-docs-pull-requests). - -## Melhores Práticas recomendadas para contribuições - -- Escreva mensagens GIT claras e significativas. -- Certifique-se de incluir _Github Special Keywords_ que faz referência a issue e o fecha automaticamente quando o PR é mergeado. -- Quando você faz uma pequena alteração em um PR, como corrigir um erro de digitação, qualquer alteração de estilo ou gramática, certifique-se de esmagar seus commits (squash) para não obter um grande número de commits por uma alteração relativamente pequena. -- Certifique-se de incluir uma boa descrição de PR explicando as alterações no código, o motivo de alterar um trecho de código e garantir que haja informações suficientes para o revisor entender seu PR. -- Leituras adicionais: - - [chris.beams.io/posts/git-commit/](https://chris.beams.io/posts/git-commit/) - - [github.com/blog/1506-closing-issues-via-pull-requests ](https://github.com/blog/1506-closing-issues-via-pull-requests ) - - [davidwalsh.name/squash-commits-git ](https://davidwalsh.name/squash-commits-git ) - -## Outras maneiras de contribuir - -- Para contribuir com a comunidade Kubernetes por meio de fóruns on-line, como Twitter ou Stack Overflow, ou aprender sobre encontros locais e eventos do Kubernetes, visite o a area de [comunidade Kubernetes](/community/). -- Para contribuir com o desenvolvimento de novas funções, leia o [cheatsheet do colaborador](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) para começar. - - - -## {{% heading "whatsnext" %}} - - -- Para obter mais informações sobre os conceitos básicos de contribuição para a documentação, leia [Comece a contribuir](/docs/contribute/start/). -- Siga o [Guia de estilo de documentação do Kubernetes](/docs/contribute/style/style-guide/) ao propor mudanças. -- Para mais informações sobre o SIG Docs, leia [Participando do SIG Docs](/docs/contribute/participating/). -- Para mais informações sobre a localização de documentos do Kubernetes, leia [Localização da documentação do Kubernetes](/docs/contribute/localization/). - - diff --git a/content/ru/_index.html b/content/ru/_index.html index aaf9f136f5..a460376f12 100644 --- a/content/ru/_index.html +++ b/content/ru/_index.html @@ -41,12 +41,12 @@ Kubernetes — это проект с открытым исходным кодо

    - Посетите KubeCon NA онлайн, 17-20 ноября 2020 + Посетите KubeCon в Северной Америке, 11-15 октября 2021 года



    - Посетите KubeCon EU онлайн, 4 – 7 мая 2021 + Посетите KubeCon в Европе, 17-20 мая 2022 года
    @@ -56,4 +56,4 @@ Kubernetes — это проект с открытым исходным кодо {{< blocks/kubernetes-features >}} -{{< blocks/case-studies >}} \ No newline at end of file +{{< blocks/case-studies >}} diff --git a/content/ru/community/_index.html b/content/ru/community/_index.html index 20d7ac5e79..0d7b49b5a5 100644 --- a/content/ru/community/_index.html +++ b/content/ru/community/_index.html @@ -12,8 +12,8 @@ cid: community

    -

    Сообщество Kubernetes — пользователи, участники проекта, и культура, которую мы создаём вместе — одна из главных причин космической скорости роста этого проекта с открытым исходным кодом. Наши культура и ценности продолжают расти и изменяться вместе с проектом. Мы все стремимся к постоянному улучшению проекта и того, как мы над ним работаем. -

    Мы — люди которые докладывают о проблемах и вносят изменения, участвуют во встречах, митапах Kubernetes, и KubeCon, продвигают его внедрение и развитие, запускают kubectl get pods, и поддерживают проект ещё множеством способов. Узнайте как стать частью этого прекрасного сообщества.

    +

    Сообщество Kubernetes — пользователи, участники проекта и культура, которую мы создаём вместе — одна из главных причин космической скорости роста этого проекта с открытым исходным кодом. Наши культура и ценности продолжают расти и изменяются вместе с проектом. Мы все стремимся к постоянному улучшению проекта и того, как мы над ним работаем. +

    Мы — люди которые докладывают о проблемах и вносят изменения, участвуют во встречах, митапах Kubernetes, и KubeCon, продвигают его внедрение и развитие, запускают kubectl get pods, поддерживают проект ещё множеством способов. Узнайте как стать частью этого прекрасного сообщества.


    diff --git a/content/ru/community/static/README.md b/content/ru/community/static/README.md index 4a448d9754..d26a4e4598 100644 --- a/content/ru/community/static/README.md +++ b/content/ru/community/static/README.md @@ -1,2 +1,2 @@ -Файлы в этой диркетории было импортированы из других источников. +Файлы в этой диркетории были импортированы из других источников. Не редактируйте их напрямую, вместо этого заменяйте их более новыми версиями. diff --git a/content/ru/community/static/community-values.md b/content/ru/community/static/community-values.md new file mode 100644 index 0000000000..c9c0f00ac5 --- /dev/null +++ b/content/ru/community/static/community-values.md @@ -0,0 +1,28 @@ + + +# Ценности сообщества Kubernetes + +Культура сообщества Kubernetes часто упоминается как существенный вклад в стремительный рост этого проекта с открытым исходным кодом. Ниже приведены дистиллированные ценности, которые развивались в течение последних многих лет в нашем сообществе, подталкивая наш проект и коллег к постоянному совершенствованию. + +## Распределение лучше, чем централизация + +Масштаб проекта Kubernetes жизнеспособен только благодаря высокому доверию и четкому распределению работ, которое включает делегирование полномочий, принятие решений, техническое проектирование, владение кодом и документацию. Распределенное асинхронное владение, сотрудничество, коммуникация и принятие решений являются краеугольным камнем нашего мирового сообщества. + +## Сообщество над товаром или компанией + +Мы здесь в первую очередь как сообщество, наша преданность заключается в преднамеренном управлении проектом Kubernetes на благо всех его членов и пользователей во всем мире. Мы поддерживаем совместную публичную работу для достижения общей цели создания динамичной взаимодействующей экосистемы, обеспечивающей отличный опыт для наших пользователей. Отдельные лица получают статус благодаря работе, компании получают статус благодаря своим обязательствам поддерживать это сообщество и финансировать ресурсы, необходимые для функционирования проекта. + +## Автоматизация процесса + +У крупных проектов есть много менее захватывающей, но все же тяжелой работы. Мы ценим время, потраченное на автоматизацию повторяющейся работы, больше, чем тяжелый труд. Там, где эта работа не может быть автоматизирована, наша культура заключается в признании и вознаграждении всех видов вклада. Однако героизм не является устойчивым. + +## Inclusive is better than exclusive + +В целом успешная и полезная технология требует различных перспектив и навыков, которые могут быть услышаны только в гостеприимной и уважительной обстановке. Членство в сообществе-это привилегия, а не право. Лидерство в сообществе достигается за счет усилий, объема, качества, количества и продолжительности взносов. Наше сообщество проявляет уважение к времени и усилиям, затраченным на обсуждение, независимо от того, где участник находится на пути своего роста. + +## Эволюция лучше, чем застой + +Открытость новым идеям и изученная технологическая эволюция делают Kubernetes более сильным проектом. Постоянное совершенствование, лидерство слуг, наставничество и уважение-вот основы культуры проекта Kubernetes. Лидеры сообщества Kubernetes обязаны находить, спонсировать и продвигать новых членов сообщества. Лидеры должны ожидать, что они отойдут в сторону. Члены сообщества должны ожидать, что они сделают шаг вперед. + +**"Culture eats strategy for breakfast." --Peter Drucker** diff --git a/content/ru/community/values.md b/content/ru/community/values.md new file mode 100644 index 0000000000..4ae1fe30b6 --- /dev/null +++ b/content/ru/community/values.md @@ -0,0 +1,13 @@ +--- +title: Community +layout: basic +cid: community +css: /css/community.css +--- + +
    + +
    +{{< include "/static/community-values.md" >}} +
    +
    diff --git a/content/ru/docs/_index.md b/content/ru/docs/_index.md index 09f6d57a37..3ccdee88bb 100644 --- a/content/ru/docs/_index.md +++ b/content/ru/docs/_index.md @@ -1,3 +1,6 @@ --- +linktitle: Документация по Kubernetes title: Документация +sitemap: + priority: 1.0 --- diff --git a/content/ru/docs/concepts/architecture/_index.md b/content/ru/docs/concepts/architecture/_index.md index eb68a67e53..05b3535491 100755 --- a/content/ru/docs/concepts/architecture/_index.md +++ b/content/ru/docs/concepts/architecture/_index.md @@ -1,5 +1,7 @@ --- title: "Кластерная Архитектура" weight: 30 +description: > + The architectural concepts behind Kubernetes. --- diff --git a/content/ru/docs/concepts/architecture/cloud-controller.md b/content/ru/docs/concepts/architecture/cloud-controller.md new file mode 100644 index 0000000000..5bb9c3d4fa --- /dev/null +++ b/content/ru/docs/concepts/architecture/cloud-controller.md @@ -0,0 +1,190 @@ +--- +title: Диспетчер облачных контроллеров +content_type: concept +weight: 40 +--- + + + +{{< feature-state state="beta" for_k8s_version="v1.11" >}} + +Технологии облачной инфраструктуры позволяет запускать Kubernetes в общедоступных, частных и гибридных облаках. Kubernetes верит в автоматизированную, управляемую API инфраструктуру без жесткой связи между компонентами. + +{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="Диспетчер облачных контроллеров">}} + +Диспетчер облачных контроллеров спроектирован с использованием механизма плагинов, которые позволяют различным облачным провайдерам интегрировать свои платформы с Kubernetes. + + + + + +## Дизайн + +![Kubernetes components](/images/docs/components-of-kubernetes.svg) + +Диспетчер облачных контроллеров работает в панели управления как реплицированный набор процессов (обычно это контейнер в Pod-ах). Каждый диспетчер облачных контроллеров реализует множество {{< glossary_tooltip text="контроллеров" term_id="controller" >}} в единственном процессе. + + +{{< note >}} +Вы также можете запустить диспетчер облачных контроллеров как {{< glossary_tooltip text="дополнение" term_id="addons" >}} Kubernetes, а не как часть панели управления. +{{< /note >}} + +## Функции диспетчера облачных контроллеров {#functions-of-the-ccm} + +Контроллеры внутри диспетчера облачных контроллеров включают в себя: + +### Контролер узла + +Контроллер узла отвечает за создание объектов {{< glossary_tooltip text="узла" term_id="node" >}} при создании новых серверов в вашей облачной инфраструктуре. Контроллер узла получает информацию о работающих хостах внутри вашей арендуемой инфраструктуры облачного провайдера. +Контроллер узла выполняет следующие функции: + +1. Инициализация объектов узла для каждого сервера, которые контроллер получает через API облачного провайдера. +2. Аннотирование и маркировка объектов узла специфичной для облака информацией, такой как регион узла и доступные ему ресурсы (процессор, память и т.д.). +3. Получение имени хоста и сетевых адресов. +4. Проверка работоспособности узла. В случае, если узел перестает отвечать на запросы, этот контроллер проверяет с помощью API вашего облачного провайдера, был ли сервер деактивирован / удален / прекращен. Если узел был удален из облака, контроллер удлаяет объект узла из вашего Kubernetes кластера. + +Некоторые облачные провайдеры реализуют его разделение на контроллер узла и отдельный контроллер жизненного цикла узла. + +### Контролер маршрута + +Контролер маршрута отвечает за соответствующую настройку маршрутов в облаке, чтобы контейнеры на разных узлах кластера Kubernetes могли взаимодействовать друг с другом. + +В зависимости от облачного провайдера, контроллер маршрута способен также выделять блоки IP-адресов для сети Pod-ов. + +### Контроллер сервисов + +{{< glossary_tooltip text="Сервисы" term_id="service" >}} интегрируются с компонентами облачной инфраструктуры, такими как управляемые балансировщики нагрузки, IP-адреса, фильтрация сетевых пакетов и проверка работоспособности целевых объектов. Контроллер сервисов взаимодействует с API вашего облачного провайдера для настройки требуемых балансировщиков нагрузки и других компонентов инфраструктуры, когда вы объявляете ресурсы сервисов. + +## Авторизация + +В этом разделе разбирается доступ к различным объектам API, который нужен облачным контроллерам для выполнения своих операций. + +### Контроллер узла {#authorization-node-controller} + +Контроллер узла работает только с объектом узла. Он требует полного доступа для и изменения объектов узла. + +`v1/Node`: + +- Get +- List +- Create +- Update +- Patch +- Watch +- Delete + +### Контролер маршрута {#authorization-route-controller} + +Контролер маршрута прослушивает создание объектов узла и соответствующим образом настраивает маршруты. Для этого требуется получить доступ к объектам узла. + +`v1/Node`: + +- Get + +### Контроллер сервисов {#authorization-service-controller} + +Контроллер сервисов прослушивает события Create, Update и Delete объектов служб, а затем соответствующим образом настраивает конечные точки для соответствующих сервисов. + +Для доступа к сервисам требуется доступ к событиям List и Watch. Для обновления сервисов требуется доступ к событиям Patch и Update. + +Чтобы настроить ресурсы конечных точек для сервисов, требуется доступ к событиям Create, List, Get, Watch и Update. + +`v1/Service`: + +- List +- Get +- Watch +- Patch +- Update + +### Другие {#authorization-miscellaneous} + +Реализация ядра диспетчера облачных контроллеров требует доступ для создания создания объектов событий, а для обеспечения безопасной работы требуется доступ к созданию сервисных учетных записей (ServiceAccounts). + +`v1/Event`: + +- Create +- Patch +- Update + +`v1/ServiceAccount`: + +- Create + +The {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole для диспетчера облачных контроллеров выглядит так: + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: cloud-controller-manager +rules: +- apiGroups: + - "" + resources: + - events + verbs: + - create + - patch + - update +- apiGroups: + - "" + resources: + - nodes + verbs: + - '*' +- apiGroups: + - "" + resources: + - nodes/status + verbs: + - patch +- apiGroups: + - "" + resources: + - services + verbs: + - list + - patch + - update + - watch +- apiGroups: + - "" + resources: + - serviceaccounts + verbs: + - create +- apiGroups: + - "" + resources: + - persistentvolumes + verbs: + - get + - list + - update + - watch +- apiGroups: + - "" + resources: + - endpoints + verbs: + - create + - get + - list + - watch + - update +``` + + +## {{% heading "whatsnext" %}} + +[Администрирование диспетчера облачных контроллеров](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) +содержит инструкции по запуску и управлению диспетером облачных контроллеров. + +Хотите знать, как реализовать свой собственный диспетчер облачных контроллеров или расширить проект? + +Диспетчер облачных контроллеров использует интерфейсы Go, которые позволяют реализовать подключение из любого облака. В частности, он использует интерфейс `CloudProvider`, который определен в [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69) из [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider). + +Реализация общих контроллеров, описанных в этом документе (Node, Route, и Service), а также некоторые другие вспомогательные конструкции, вместе с общим интерфейсом облачного провайдера являются частью ядра Kubernetes. Особые реализации для облачных провайдеров находятся вне ядра Kubernetes и реализуют интерфейс `CloudProvider`. + +Дополнительные сведения о разработке плагинов см. в разделе [Разработка диспетчера облачных контроллеров](/docs/tasks/administer-cluster/developing-cloud-controller-manager/). diff --git a/content/ru/docs/concepts/architecture/control-plane-node-communication.md b/content/ru/docs/concepts/architecture/control-plane-node-communication.md new file mode 100644 index 0000000000..ea5cc33921 --- /dev/null +++ b/content/ru/docs/concepts/architecture/control-plane-node-communication.md @@ -0,0 +1,70 @@ +--- +reviewers: +- dchen1107 +- liggitt +title: Связь между плоскостью управления и узлом +content_type: concept +weight: 20 +aliases: +- master-node-communication +--- + + + +Этот документ каталог связь между плоскостью управления (apiserver) и кластером Kubernetes. Цель состоит в том, чтобы позволить пользователям настраивать свою установку для усиления сетевой конфигурации, чтобы кластер мог работать в ненадежной сети (или на полностью общедоступных IP-адресах облачного провайдера). + + + + + +## Связь между плоскостью управления и узлом +В Kubernetes имеется API шаблон "hub-and-spoke". Все используемые API из узлов (или которые запускают pod-ы) завершает apiserver. Ни один из других компонентов плоскости управления не предназначен для предоставления удаленных сервисов. Apiserver настроен на прослушивание удаленных подключений через безопасный порт HTTPS. (обычно 443) с одной или несколькими включенными формами [идентификации](/docs/reference/access-authn-authz/authentication/) клиена. + +Должна быть включена одна или несколько форм [идентификации](/docs/reference/access-authn-authz/authorization/), особенно если разрешены [анонимные запросы](/docs/reference/access-authn-authz/authentication/#anonymous-requests) или [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens). + +Узлы должны быть снабжены общедоступным корневым сертификатом для кластера, чтобы они могли безопасно подключаться к apiserver-у вместе с действительными учетными данными клиента. Хороший подход заключается в том, что учетные данные клиента, предоставляемые kubelet, имеют форму клиентского сертификата. См. Информацию о загрузке Kubelet TLS [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) для автоматической подготовки клиентских сертификатов kubelet. + +pod-ы, которые хотят подключиться к apiserver, могут сделать это безопасно, используя учетную запись службы, чтобы Kubernetes автоматически вводил общедоступный корневой сертификат и действительный токен-носитель в pod при его создании. +Служба `kubernetes` (в пространстве имен `default`) is настроен с виртуальным IP-адресом, который перенаправляет (через kube-proxy) к endpoint HTTPS apiserver-а. + +Компоненты уровня управления также взаимодействуют с кластером apiserver-а через защищенный порт. + +В результате режим работы по умолчанию для соединений от узлов и модулей, работающих на узлах, к плоскости управления по умолчанию защищен и может работать в ненадежных и/или общедоступных сетях. + +## Узел к плоскости управления + +Существуют две пути взаимодействия от плоскости управления (apiserver) к узлам. Первый - от apiserver-а до kubelet процесса, который выполняется на каждом узле кластера. Второй - от apiserver к любому узлу, pod-у или службе через промежуточную функциональность apiserver-а. + +### apiserver в kubelet + +Соединение из apiserver-а к kubelet используются для: + +* Извлечения логов с pod-ов. +* Прикрепление (через kubectl) к запущенным pod-ам. +* Обеспечение функциональности переадресации портов kubelet. + +Эти соединения заверщаются в kubelet в endpoint HTTPS. По умолчанию apiserver не проверяет сертификат обслуживания kubelet-ов, что делает соединение подверженным к атаке человек по середине (man-in-the-middle) и **unsafe** запущенных в ненадежных или общедоступных сетях. + +Для проверки этого соединения, используется флаг `--kubelet-certificate-authority` чтобы предоставить apiserver-у набор корневых (root) сертификатов для проверки сертификата обслуживания kubelet-ов. + +Если это не возможно, используйте [SSH-тунелирование](#ssh-tunnels) между apiserver-ом и kubelet, если это необходимо во избежании подключения по ненадежной или общедоступной сети. + +Наконец, Должны быть включены [пудентификация или авторизация Kubelet](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) для защиты kubelet API. + +### apiserver для узлов, pod-ов, и служб + +Соединение с apiserver-ом к узлу, pod-у или службе по умолчанию осушествяляется по обычному HTTP-соединению и поэтому не проходят проверку подлиности и не шифрование. Они могут быть запущены по защищенному HTTPS-соединению, добавив префикс `https:` к имени узла, pod-а или службы в URL-адресе API, но они не будут проверять сертификат предоставленный HTTPS endpoint, также не будут предоставлять учетные данные клиента. Таким образом, хотя соединение будет зашифровано, оно не обеспечит никаких гарантий целостности. Эти соединения **are not currently safe** запущенных в ненадежных или общедоступных сетях. + +### SSH-тунели + +Kubernetes поддерживает SSH-туннели для защиты плоскости управления узлов от путей связи. В этой конфигурации apiserver инициирует SSH-туннель для каждого узла в кластере (подключается к ssh-серверу, прослушивая порт 22) и передает весь трафикпредназначенный для kubelet, узлу, pod-у или службе через тунель. Этот тунель гарантирует, что трафик не выводиться за пределы сети, в которой работает узел. + +SSH-туннели в настоящее время устарели, поэтому вы не должны использовать их, если не знаете, что делаете. Служба подключения является заменой этого канала связи. + +### Служба подключения + +{{< feature-state for_k8s_version="v1.18" state="beta" >}} + +В качестве замены SSH-туннелям, служба подключения обеспечивает уровень полномочие TCP для плоскости управления кластерной связи. Служба подключения состоит из двух частей: сервер подключения в сети плоскости управления и агентов подключения в сети узлов. Агенты службы подключения инициируют подключения к серверу подключения и поддерживают сетевое подключение. После включения службы подключения, весь трафик с плоскости управления на узлы проходит через эти соединения. + +Следуйте инструкциям [Задача службы подключения](/docs/tasks/extend-kubernetes/setup-konnectivity/) чтобы настроить службу подключения в кластере. diff --git a/content/ru/docs/concepts/architecture/controller.md b/content/ru/docs/concepts/architecture/controller.md new file mode 100644 index 0000000000..4f28a51836 --- /dev/null +++ b/content/ru/docs/concepts/architecture/controller.md @@ -0,0 +1,115 @@ +--- +title: Контроллеры +content_type: concept +weight: 30 +--- + + + +В робототехнике и автоматизации, _цикл управления_ - это непрерывный цикл, который регулирует состояние системы. + +Вот один из примеров контура управления: термостат в помещении. + +Когда вы устанавливаете температуру, это говорит термостату о вашем *желаемом состоянии*. Фактическая температура в помещении - это +*текущее состояние*. Термостат действует так, чтобы приблизить текущее состояние к елаемому состоянию, путем включения или выключения оборудования. + +{{< glossary_definition term_id="controller" length="short">}} + + + + + + +## Шаблон контроллера + +Контроллер отслеживает по крайней мере один тип ресурса Kubernetes. +Эти [объекты](/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects) +имеют поле спецификации, которое представляет желаемое состояние. Контроллер (ы) для этого ресурса несут ответственность за приближение текущего состояния к желаемому состоянию + +Контроллер может выполнить это действие сам; чаще всего в Kubernetes, +контроллер будет отправляет сообщения на +{{< glossary_tooltip text="сервер API" term_id="kube-apiserver" >}} которые имеют +полезные побочные эффекты. Пример этого вы можете увидеть ниже. + +{{< comment >}} +Некоторые встроенные контроллеры, такие как контроллер пространства имен, действуют на объекты, не имеющие спецификации. Для простоты эта страница опускает объяснение этих деталей. +{{< /comment >}} + +### Управление с помощью сервера API + +Контроллер {{< glossary_tooltip term_id="job" >}} является примером встроенного контроллера Kubernetes. Встроенные контроллеры управляют состоянием, взаимодействуя с кластером сервера API. + +Задание - это ресурс Kubernetes, который запускает +{{< glossary_tooltip term_id="pod" >}}, или возможно несколько Pod-ов, которые выполняют задание и затем останавливаются. + +(После [планирования](/docs/concepts/scheduling-eviction/), Pod объекты становятся частью желаемого состояния для kubelet). + +Когда контроллер задания видит новую задачу, он убеждается что где-то в вашем кластере kubelet-ы на множестве узлов запускают нужное количество Pod-ов для выполнения работы. +Контроллер задания сам по себе не запускает никакие Pod-ы или контейнеры. Вместо этого контроллер задания сообщает серверу API о создании или удалении Pod-ов. +Другие компоненты в +{{< glossary_tooltip text="плоскости управления" term_id="control-plane" >}} +действуют на основе информации (имеются ли новые запланированные Pod-ы для запуска), и в итоге работа завершается. + +После того, как вы создадите новое задание, желаемое состояние для этого задания будет завершено. Контроллер задания приближает текущее состояние этого задания к желаемому состоянию: создает Pod-ы, которые выполняют работу, которую вы хотели для этого задания, чтобы задание было ближе к завершению. + +Контроллеры также обровляют объекты которые их настраивают. +Например: как только работа выполнена для задания, контроллер задания обновляет этот объект задание, чтобы пометить его как `Завершенный`. + +(Это немного похоже на то, как некоторые термостаты выключают свет, чтобы указать, что теперь ваша комната имеет установленную вами температуру). + +### Прямое управление + +В отличие от Задания, некоторым контроллерам нужно вносить изменения в вещи за пределами вашего кластера. + +Например, если вы используете контур управления, чтобы убедиться, что в вашем кластере достаточно {{< glossary_tooltip text="Узлов" term_id="node" >}}, +тогда этому контроллеру нужно что-то вне текущего кластера, чтобы при необходимости запустить новые узлы. + +Контроллеры, которые взаимодействуют с внешним состоянием, находят свое желаемое состояние с сервера API, а затем напрямую взаимодействуют с внешней системой, чтобы приблизить текущее состояние. + +(На самом деле существует [контроллер](https://github.com/kubernetes/autoscaler/), который горизонтально маштабирует узлы в вашем кластере.) + +Важным моментом здесь является то, что контроллер вносит некоторые изменения, чтобы вызвать желаемое состояние, а затем сообщает текущее состояние обратно на сервер API вашего кластера. Другие контуры управления могут наблюдать за этими отчетными данными и предпринимать собственные действия. + +В примере с термостатом, если в помещении очень холодно, тогда другой контроллер может также включить обогреватель для защиты от замерзания. В кластерах Kubernetes, плоскость управления косвенно работает с инструментами управления IP-адресами,службами хранения данных, API облочных провайдеров и другими службами для релизации +[расширения Kubernetes](/docs/concepts/extend-kubernetes/). + +## Желаемое против текущего состояния {#desired-vs-current} + +Kubernetes использует систему вида cloud-native и способен справлятся с постоянными изменениями. + +Ваш кластер может изменяться в любой по мере выполнения работы и контуры управления автоматически устранают сбой. Это означает, что потенциально Ваш кластер никогда не достигнет стабильного состояния. + +Пока контроллеры вашего кластера работают и могут вносить полезные изменения, не имеет значения, является ли общее состояние стабильным или нет. + +## Дизайн + +В качестве принципа своей конструкции Kubernetes использует множество контроллеров, каждый из которых управляет определенным аспектом состояния кластера. Чаще всего конкретный контур управления (контроллер) использует один вид ресурса в качестве своего желаемого состояния и имеет другой вид ресурса, которым он управляет, чтобы это случилось. Например, контроллер для заданий отслеживает объекты заданий (для обнаружения новой работы) и объекты модулей (для выполнения заданий, а затем для того, чтобы видеть, когда работа завершена). В этом случае что-то еще создает задания, тогда как контроллер заданий создает Pod-ы. + +Полезно иметь простые контроллеры, а не один монолитный набор взаимосвязанных контуров управления. Контроллеры могут выйти из строя, поэтому Kubernetes предназначен для этого. + +{{< note >}} +Существует несколько контроллеров, которые создают или обновляют один и тот же тип объекта. За кулисами контроллеры Kubernetes следят за тем, чтобы обращать внимание только на ресурсы, связанные с их контролирующим ресурсом. + +Например, у вас могут быть развертывания и задания; они оба создают Pod-ы. Контроллер заданий не удаляет Pod-ы созданные вашим развертиыванием, потому что имеется информационные ({{< glossary_tooltip term_id="label" text="метки" >}}) +которые могут быть использованы контроллерами тем самым показывая отличие Pod-ов. +{{< /note >}} + +## Способы запуска контроллеров {#running-controllers} + +Kubernetes поставляется с набором встроенных контроллеров, которые работают внутри {{< glossary_tooltip term_id="kube-controller-manager" >}}. Эти встроенные контроллеры обеспечивают важные основные функции. + +Контроллер развертывания и контроллер заданий - это примеры контроллеров, которые входят в состав самого Kubernetes («встроенные» контроллеры). +Kubernetes позволяет вам запускать устойчивую плоскость управления, так что в случае отказа одного из встроенных контроллеров работу берет на себя другая часть плоскости управления. + +Вы можете найти контроллеры, которые работают вне плоскости управления, чтобы расширить Kubernetes. +Или, если вы хотите, можете написать новый контроллер самостоятельно. Вы можете запустить свой собственный контроллер виде наборов Pod-ов, +или внешнее в Kubernetes. Что подойдет лучше всего, будет зависеть от того, что делает этот конкретный контроллер. + + + +## {{% heading "whatsnext" %}} + +* Прочтите о [плоскости управления Kubernetes ](/docs/concepts/overview/components/#control-plane-components) +* Откройте для себя некоторые из основных [объектов Kubernetes ](/docs/concepts/overview/working-with-objects/kubernetes-objects/) +* Узнайте больше о [Kubernetes API](/docs/concepts/overview/kubernetes-api/) +* Если вы хотите написать собственный контроллер, см [Шаблоны расширения](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) в расширении Kubernetes. diff --git a/content/ru/docs/concepts/architecture/garbage-collection.md b/content/ru/docs/concepts/architecture/garbage-collection.md new file mode 100644 index 0000000000..f7ded8b44e --- /dev/null +++ b/content/ru/docs/concepts/architecture/garbage-collection.md @@ -0,0 +1,134 @@ +--- +title: Сборщик мусора +content_type: concept +weight: 50 +--- + + +{{}} Это позволить очистить ресурсы, такие как: + + * [Неудачные pod-ы](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) + * [Завершенные задания](/docs/concepts/workloads/controllers/ttlafterfinished/) + * [Объекты без ссылок на владельца Objects](#owners-dependents) + * [Не используемые контейнеры и образы контейнеров](#containers-images) + * [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](/docs/concepts/storage/persistent-volumes/#delete) + * [Устаревшие или просроченные запросы подписания сертификатов (CSR)](/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) + * {{}} удалено в следующих сценариях: + * В облаке, когда кластер использует [диспетчер облачных контроллеров](/docs/concepts/architecture/cloud-controller/) + * Локально когда кластер использует дополнение, аналогичное диспетчер облачных контроллеров + * [Объекты аренды узлов](/docs/concepts/architecture/nodes/#heartbeats) + +## Владельцы и зависимости {#owners-dependents} + +Многие объекты в Kubernetes ссылаются друг на друга через [*ссылки владельцев*](/docs/concepts/overview/working-with-objects/owners-dependents/). +Ссылки владельцев сообщают плоскости управления какие объекты зависят от других. +Kubernetes использует ссылки владельцев, чтобы предоставить плоскости управления и другим API +клиентам, возможность очистить связанные ресурсы передудалением объекта. В большинстве случаев, Kubernetes автоматический управляет ссылками владельцев. + +Владелец отличается от [меток и селекторов](/docs/concepts/overview/working-with-objects/labels/) +которые также используют некоторые ресурсы. Например, рассмотрим +{{}} которая создает объект +`EndpointSlice`. Служба использует *метки* чтобы позволить плоскости управления определить какие `EndpointSlice` объекты используются для этой службы. В дополнение +к меткам, каждый `EndpointSlice` управляет ои имени службы, имеет +ссылку владельца. Ссылки владельцев помогают различным частям Kubernetes избегать +вмешательства в объекты, которые они не контролируют. + +{{< note >}} +Ссылки на владельцев перекрестных пространств имен запрещены по дизайну. +Зависимости пространства имен могут указывать на область действия кластера или владельцев пространства имен. +Владелец пространства имен **должен** быть в том же пространстве имен что и зависимости. +Если это не возможно, cсылка владельца считается отсутствующей и зависимый объект подлежит удалению, как только будет проверено отсутствие всех владельцев. + +Зависимости области действия кластер может указывать только владельцев области действия кластера. +В версии v1.20+, если зависимость с областью действия кластера указывает на пространство имен как владелец, +тогда он рассматривается как имеющий неразрешимую ссылку на владельца и не может быть обработан сборщиком мусора. + +В версии v1.20+, если сборщик мусора обнаружит недопустимое перекрестное пространство имен `ownerReference`, +или зависящие от облости действия кластера `ownerReference` ссылка на тип пространства имен, предупреждающее событие с причиной `OwnerRefInvalidNamespace` и `involvedObject` сообщающеся о не действительной зависимости. +Вы можете проверить наличие такого рода событий, выполнив `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`. +{{< /note >}} + +## Каскадное удаление {#cascading-deletion} + +Kubernetes проверяет и удаляет объекты, на которые больше нет ссылок владельцев, так же как и pod-ов, оставленных после удаления ReplicaSet. Когда Вы удаляете объект, вы можете контролировать автоматический ли Kubernetes удаляет зависимые объекты автоматически в процессе вызова *каскадного удаления*. Существует два типа каскадного удаления, а именно: + + * Каскадное удалени Foreground + * Каскадное удаление Background + +Вы так же можете управлять как и когда сборщик мусора удаляет ресурсы, на которые ссылаются владельцы с помощью Kubernetes {{}}. + +### Каскадное удалени Foreground {#foreground-deletion} + +В Каскадном удалени Foreground, объект владельца, который вы удаляете, сначало переходить в состояние *в процессе удаления*. В этом состоянии с объектом-владельцем происходить следующее: + + * Сервер Kubernetes API устанавливает полю объекта `metadata.deletionTimestamp` + время, когда объект был помечен для удаления. + * Сервер Kubernetes API так же устанавливает метку `metadata.finalizers`для поля + `foregroundDeletion`. + * Объект остается видимым блогодоря Kubernetes API пока процесс удаления не завершиться + +После того, как владелец объекта переходит в состояние прогресса удаления, контроллер удаляет зависимые объекты. После удаления всех зависимых объектов, контроллер удаляет объект владельца. На этом этапе, объект больше не отображается в Kubernetes API. + +Во время каскадного удаления foreground, единственным зависимым, которые блокируют удаления владельца, являются те, у кого имеется поле `ownerReference.blockOwnerDeletion=true`. +Чтобы узнать больше. Смотрите [Использование каскадного удаления foreground](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion). + +### Каскадное удаление Background {#background-deletion} + +В каскадном удалении background, сервер Kubernetes API немедленно удаляет владельца объекта, а контроллер очищает зависимые объекты в фоновом режиме. По умолчанию, Kubernetes использует каскадное удаление background, если вы в ручную не используете удаление foreground или не решите отключить зависимые объекты. + +Чтобы узнать больше. Смотрите [Использование каскадного удаления background](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion). + +### Осиротевшие зависимости + +Когда Kubernetes удаляет владельца объекта, оставшиеся зависимости называются *осиротевшыми* объектами. По умолчанию, Kubernetes удаляет зависимые объекты. Чтобы узнать, как переопределить это повидение смотрите [Удаление объектов владельца и осиротевших зависимостей](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy). + +## Сбор мусора из неиспользуемых контейнеров и изобробразов {#containers-images} + +{{}} выполняет сбор мусора для неиспользуемых образов каждые пять минут и для неиспользуемых контейнеров каждую минуту. Вам следует избегать использования внешних инструментов для сборки мусора, так как они могут +нарушить поведение kubelet и удалить контейнеры, которые должны существовать. + +Чтобы настроить параметры для сборшика мусора для неиспользуемого контейнера и сборки мусора образа, подстройте +kubelet использую [конфигурационный файл](/docs/tasks/administer-cluster/kubelet-config-file/) +и измените параметры, связанные со сборшиком мусора используя тип ресурса +[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration). + +### Жизненный цикл контейнерных образов Container image lifecycle + +Kubernetes управляет жизненным циклом всех образов с помощью своего *менеджера образов*, которые являются частью kubelet, в сотрудничестве с cadvisor. При принятии решений о сборке мусора, kubelet учитывает следующие ограничения использования диска: + + * `HighThresholdPercent` + * `LowThresholdPercent` + +Использование диска выше настроенного значения `HighThresholdPercent` запускает сборку мусора, которая удаляет образы в порядке основанном на последнем использовании, начиная с самого старого. kubelet удлаяет образы до тех пор, пока использование диска не достигнет значения `LowThresholdPercent`. + +### Сборщик мусора контейнерных образов {#container-image-garbage-collection} + +kubelet собирает не используемые контейнеры на основе следующих переменных, которые вы можете определить: + + * `MinAge`: минимальный возраст, при котором kubelet может начать собирать мусор контейнеров. Отключить, установив значение `0`. + * `MaxPerPodContainer`: максимальное количество некативныз контейнеров, которое может быть у каджой пары Pod-ов. Отключить, установив значение меньше чем `0`. + * `MaxContainers`: максимальное количество не используемых контейнеров, которые могут быть в кластере. Отключить, установив значение меньше чем `0`. + +В дополнение к этим переменным, kubelet собирает неопознанные и удаленные контейнеры, обычно начиная с самого старого. + +`MaxPerPodContainer` и `MaxContainer` могут потенциально конфликтовать друг с другом в ситуациях, когда требуется максимальное количество контейнеров в Pod-е (`MaxPerPodContainer`) выйдет за пределы допустимого общего количества глобальных не используемых контейнеров (`MaxContainers`). В этой ситуации kubelet регулирует `MaxPodPerContainer` для устранения конфликта. наихудшим сценарием было бы понизить `MaxPerPodContainer` да `1` и изгнать самые старые контейнеры. +Кроме того, владельцы контейнеров в pod-е могут быть удалены, как только они становятся старше чем `MinAge`. + +{{}} +Kubelet собирает мусор только у контейнеров, которыми он управляет. +{{}} + +## Настройка сборщик мусора {#configuring-gc} + +Вы можете настроить сборку мусора ресурсов, настроив параметры, специфичные для контроллеров, управляющих этими ресурсами. В последующих страницах показанно, как настроить сборку мусора: + + * [Настройка каскадного удаления объектов Kubernetes](/docs/tasks/administer-cluster/use-cascading-deletion/) + * [Настройка очистки завершенных заданий](/docs/concepts/workloads/controllers/ttlafterfinished/) + + + +## {{% heading "whatsnext" %}} + +* Узнайте больше о [ownership of Kubernetes objects](/docs/concepts/overview/working-with-objects/owners-dependents/). +* Узнайте больше о Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/). +* Узнать о [TTL контроллере](/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) that cleans up finished Jobs. \ No newline at end of file diff --git a/content/ru/docs/concepts/architecture/nodes.md b/content/ru/docs/concepts/architecture/nodes.md index 7c10f75e1b..075c3140f5 100644 --- a/content/ru/docs/concepts/architecture/nodes.md +++ b/content/ru/docs/concepts/architecture/nodes.md @@ -235,8 +235,9 @@ ConditionUnknown, когда узел становится недоступны например, из-за того, что узел упал), и затем позже выселяет все поды с узла (используя мягкое (graceful) завершение) если узел продолжает быть недоступным. (По умолчанию таймауты составляют 40 секунд, чтобы начать сообщать `ConditionUnknown`, -и 5 минут после, чтобы начать выселять поды.) Контроллер узла проверяет состояние каждого узла -каждые `--node-monitor-period` секунд. +и 5 минут после, чтобы начать выселять поды.) + +Контроллер узла проверяет состояние каждого узла каждые `--node-monitor-period` секунд. #### Сердцебиения @@ -274,8 +275,9 @@ Kubelet отвечает за создание и обновление `NodeStat если кластер небольшой (т.е. количество узлов меньше или равно `--large-cluster-size-threshold` - по умолчанию, 50), то выселения прекращаются, в противном случае скорость выселения снижается до -`--secondary-node-eviction-rate` (по умолчанию, 0.01) в секунду. Причина, по которой -эти политики реализуются для каждой зоны доступности, заключается в том, +`--secondary-node-eviction-rate` (по умолчанию, 0.01) в секунду. + +Причина, по которой эти политики реализуются для каждой зоны доступности, заключается в том, что одна зона доступности может стать отделенной от мастера, в то время как другие остаются подключенными. Если ваш кластер не охватывает несколько зон доступности облачного провайдера, то существует только одна зона доступности (весь кластер). diff --git a/content/ru/docs/concepts/cluster-administration/_index.md b/content/ru/docs/concepts/cluster-administration/_index.md new file mode 100644 index 0000000000..b596e111f3 --- /dev/null +++ b/content/ru/docs/concepts/cluster-administration/_index.md @@ -0,0 +1,70 @@ +--- +title: Администрирование кластера +reviewers: +- davidopp +- lavalamp +weight: 100 +content_type: concept +description: > + Lower-level detail relevant to creating or administering a Kubernetes cluster. +no_list: true +--- + + +Обзор администрирования кластера предназначен для всех, кто создает или администрирует кластер Kubernetes. Это предполагает некоторое знакомство с основными [концепциями] (/docs/concepts/) Kubernetes. + + + +## Планирование кластера + +См. Руководства в разделе [настройка](/docs/setup/) для получения примеров того, как планировать, устанавливать и настраивать кластеры Kubernetes. Решения, перечисленные в этой статье, называются *distros*. + + {{< note >}} + не все дистрибутивы активно поддерживаются. Выбирайте дистрибутивы, протестированные с последней версией Kubernetes. + {{< /note >}} + +Прежде чем выбрать руководство, вот некоторые соображения: + + - Вы хотите опробовать Kubernetes на вашем компьюторе или собрать многоузловой кластер высокой доступности? Выбирайте дистрибутивы, наиболее подходящие для ваших нужд. + - будете ли вы использовать **размещенный кластер Kubernetes**, такой как [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) или **разместите собственный кластер**? + - Будет ли ваш кластер **в помещений** или **в облаке (IaaS)**? Kubernetes не поддерживает напрямую гибридные кластеры. Вместо этого вы можете настроить несколько кластеров. + - **Если вы будете настроаивать Kubernetes в помещений (локально)**, подумайте, какая [сетевая модель](/docs/concepts/cluster-administration/networking/) подходит лучше всего. + - Будете ли вы запускать Kubernetes на **оборудований "bare metal"** или на **вирутальных машинах (VMs)**? + - Вы хотите **запустить кластер** или планируете **активно разворачивать код проекта Kubernetes**? В последнем случае выберите активно разрабатываемый дистрибутив. Некоторые дистрибутивы используют только двоичные выпуски, но предлагают болле широкий выбор. + - Ознакомьтесь с [компонентами](/docs/concepts/overview/components/) необходивые для запуска кластера. + + +## Управление кластером + +* Узнайте как [управлять узлами](/docs/concepts/architecture/nodes/). + +* Узнайте как настроить и управлять [квотами ресурсов](/docs/concepts/policy/resource-quotas/) для общих кластеров. + +## Обеспечение безопасности кластера + +* [Сгенерировать сертификаты](/docs/tasks/administer-cluster/certificates/) описывает шаги по созданию сертификатов с использованием различных цепочек инструментов. + +* [Kubernetes Container Environment](/docs/concepts/containers/container-environment/) описывает среду для управляемых контейнеров Kubelet на узле Kubernetes. + +* [Управление доступом к Kubernetes API](/docs/concepts/security/controlling-access) описывает как Kubernetes реализует контроль доступа для своего собственного API. + +* [Аутентификация](/docs/reference/access-authn-authz/authentication/) объясняет аутентификацию в Kubernetes, включая различные варианты аутентификации. + +* [Авторизация](/docs/reference/access-authn-authz/authorization/) отделена от аутентификации и контролирует обработку HTTP-вызовов. + +* [Использование контроллеров допуска](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization. + +* [Использование Sysctls в кластере Kubernetes](/docs/tasks/administer-cluster/sysctl-cluster/) описывает администратору, как использовать sysctlинструмент командной строки для установки параметров ядра. + +* [Аудит](/docs/tasks/debug-application-cluster/audit/) описывает, как взаимодействовать с журналами аудита Kubernetes. + +### Обеспечение безопасности kubelet + * [Связь между плоскостью управления и узлом](/docs/concepts/architecture/control-plane-node-communication/) + * [Загрузка TLS](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) + * [Аутентификация/авторизация Kubelet](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) + +## Дополнительные кластерные услуги + +* [Интеграция DNS](/docs/concepts/services-networking/dns-pod-service/) описывает как разрешить DNS имя непосредственно службе Kubernetes. + +* [Ведение журнала и мониторинг активности кластера](/docs/concepts/cluster-administration/logging/) объясняет, как работает ведение журнала в Kubernetes и как его реализовать. diff --git a/content/ru/docs/concepts/cluster-administration/addons.md b/content/ru/docs/concepts/cluster-administration/addons.md new file mode 100644 index 0000000000..82c8ab1695 --- /dev/null +++ b/content/ru/docs/concepts/cluster-administration/addons.md @@ -0,0 +1,53 @@ +--- +title: Установка дополнений +content_type: concept +--- + + + +{{% thirdparty-content %}} + +Надстройки расширяют функциональность Kubernetes. + +На этой странице перечислены некоторые из доступных надстроек и ссылки на соответствующие инструкции по установке. + + + +## Сеть и сетевыя политика + +* [ACI](https://www.github.com/noironetworks/aci-containers) обеспечивает интегрированную сеть контейнеров и сетевую безопасность с помощью Cisco ACI. +* [Antrea](https://antrea.io/) работает на уровне 3, обеспечивая сетевые службы и службы безопасности для Kubernetes, используя Open vSwitch в качестве уровня сетевых данных. +* [Calico](https://docs.projectcalico.org/latest/introduction/) Calico поддерживает гибкий набор сетевых опций, поэтому вы можете выбрать наиболее эффективный вариант для вашей ситуации, включая сети без оверлея и оверлейные сети, с или без BGP. Calico использует тот же механизм для обеспечения соблюдения сетевой политики для хостов, модулей и (при использовании Istio и Envoy) приложений на уровне сервисной сети (mesh layer). +* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) объединяет Flannel и Calico, обеспечивая сеть и сетевую политик. +* [Cilium](https://github.com/cilium/cilium) - это плагин сети L3 и сетевой политики, который может прозрачно применять политики HTTP/API/L7. Поддерживаются как режим маршрутизации, так и режим наложения/инкапсуляции, и он может работать поверх других подключаемых модулей CNI. +* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) позволяет Kubernetes легко подключаться к выбору плагинов CNI, таких как Calico, Canal, Flannel, Romana или Weave. +* [Contiv](https://contiv.github.io) предоставляет настраиваемую сеть (собственный L3 с использованием BGP, слоя с использованием vxlan, классический L2 и Cisco-SDN/ACI) для различных вариантов использования и обширную структуру политик. Проект Contiv имеет полностью [открытый исходный код](https://github.com/contiv). [Установка](https://github.com/contiv/install) обеспечивает варианты на основе как kubeadm так и без kubeadm. +* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), основан на [Tungsten Fabric](https://tungsten.io), представляет собой платформу для виртуализации мультиоблачных сетей с открытым исходным кодом и управления политиками. Contrail и Tungsten Fabric are интегрированы с системами оркестровки, такими как Kubernetes, OpenShift, OpenStack и Mesos, и обеспечивают режимы изоляции для виртуальных машин, контейнеров/pod-ов и рабочих нагрузок без операционной системы. +* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) - это поставщик оверлейной сети, который можно использовать с Kubernetes. +* [Knitter](https://github.com/ZTE/Knitter/) - это плагин для поддержки нескольких сетевых интерфейсов Kubernetes pod-ов. +* [Multus](https://github.com/Intel-Corp/multus-cni) - это плагин Multi для поддержки нексольких сетейв Kubernetes для поддержки всех CNI плагинов (наприме: Calico, Cilium, Contiv, Flannel), в дополнение к рабочим нагрузкам основанных на SRIOV, DPDK, OVS-DPDK и VPP в Kubernetes. +* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) - это сетевой провайдер для Kubernetes основанный на [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), реализация виртуалной сети a появившейся в результате проекта Open vSwitch (OVS). OVN-Kubernetes обеспечивает сетевую реализацию на основе наложения для Kubernetes, включая реализацию балансировки нагрузки и сетевой политики на основе OVS. +* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) - это подключаемый модуль контроллера CNI на основе OVN для обеспечения облачной цепочки сервисных функций (SFC), несколько наложеных сетей OVN, динамического создания подсети, динамического создания виртуальных сетей, сети поставщика VLAN, сети прямого поставщика и подключаемого к другим Multi Сетевые плагины, идеально подходящие для облачных рабочих нагрузок на периферии в сети с несколькими кластерами. +* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) плагин для контейнера (NCP) обеспечивающий интеграцию между VMware NSX-T и контейнерами оркестраторов, таких как Kubernetes, а так же интеграцию между NSX-T и контейнеров на основе платформы CaaS/PaaS, таких как Pivotal Container Service (PKS) и OpenShift. +* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) - эта платформа SDN, которая обеспечивает сетевое взаимодействие на основе политик между Kubernetes Pod-ами и не Kubernetes окружением с отображением и мониторингом безопасности. +* [Romana](https://romana.io) - это сетевое решение уровня 3 для pod сетей, которое также поддерживает [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Подробности установки Kubeadm доступны [здесь](https://github.com/romana/romana/tree/master/containerize). +* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) обеспечивает сетевуюи политику сетей, будет работать в сетевого раздела и не требует внешней базы данных. + +## Обнаружение служб + +* [CoreDNS](https://coredns.io) - это гибкий, расширяемый DNS-сервер, который может быть [установлен](https://github.com/coredns/deployment/tree/master/kubernetes) в качестве внутрикластерного DNS для pod-ов. + +## Визуализация и контроль + +* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) - это веб-интерфейс панели инструментов для Kubernetes. +* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) - это инструмент для графической визуализации ваших контейнеров, pod-ов, сервисов и т.д. Используйте его вместе с [учетной записью Weave Cloud](https://cloud.weave.works/) или разместите пользовательский интерфейс самостоятельно. + +## Инфраструктура + +* [KubeVirt](https://kubevirt.io/user-guide/#/installation/installation) - это дополнение для запуска виртуальных машин в Kubernetes. Обычно работает на bare-metal кластерах. + +## Legacy Add-ons + +В устаревшем каталоге [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) задокументировано несколько других дополнений. + +Ссылки на те, в хорошем состоянии, должны быть здесь. PR приветствуются! diff --git a/content/ru/docs/concepts/overview/working-with-objects/names.md b/content/ru/docs/concepts/overview/working-with-objects/names.md index af4b2db071..73477a1475 100644 --- a/content/ru/docs/concepts/overview/working-with-objects/names.md +++ b/content/ru/docs/concepts/overview/working-with-objects/names.md @@ -37,13 +37,13 @@ weight: 20 Некоторые типы ресурсов должны соответствовать стандарту меток DNS, который описан в [RFC 1123](https://tools.ietf.org/html/rfc1123). Таким образом, имя должно: - содержать не более 63 символов -- содержать только строчные буквенно-цифровые символы или '.' +- содержать только строчные буквенно-цифровые символы или '-' - начинаться с буквенно-цифрового символа - заканчивается буквенно-цифровым символом ### Имена сегментов пути -Определённые имена типов ресурсов должны закодированы для использования в качестве сегмента пути. Проще говоря, имя не может быть "." или "..", а также не может содержать "/" или "%". +Определённые имена типов ресурсов должны быть закодированы для использования в качестве сегмента пути. Проще говоря, имя не может быть "." или "..", а также не может содержать "/" или "%". Пример файла манифеста пода `nginx-demo`. diff --git a/content/ru/docs/contribute/generate-ref-docs/contribute-upstream.md b/content/ru/docs/contribute/generate-ref-docs/contribute-upstream.md index 223aba429f..0834caa522 100644 --- a/content/ru/docs/contribute/generate-ref-docs/contribute-upstream.md +++ b/content/ru/docs/contribute/generate-ref-docs/contribute-upstream.md @@ -113,7 +113,6 @@ On branch master hack/update-generated-swagger-docs.sh hack/update-openapi-spec.sh hack/update-generated-protobuf.sh -hack/update-api-reference-docs.sh ``` Выполните команду `git status`, чтобы посмотреть, какие файлы изменились. @@ -122,8 +121,6 @@ hack/update-api-reference-docs.sh On branch master ... modified: api/openapi-spec/swagger.json - modified: api/swagger-spec/apps_v1.json - modified: docs/api-reference/apps/v1/definitions.html modified: staging/src/k8s.io/api/apps/v1/generated.proto modified: staging/src/k8s.io/api/apps/v1/types.go modified: staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go diff --git a/content/ru/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/ru/docs/contribute/generate-ref-docs/kubernetes-api.md index 90011b3dd2..e96bc29ea7 100644 --- a/content/ru/docs/contribute/generate-ref-docs/kubernetes-api.md +++ b/content/ru/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -75,16 +75,16 @@ git clone https://github.com/kubernetes/kubernetes $GOPATH/src/k8s.io/kubernetes ### Настройка переменных для сборки * `K8S_ROOT` со значением ``. -* `WEB_ROOT` со значением ``. +* `K8S_WEBROOT` со значением ``. * `K8S_RELEASE` со значением нужной версии документации. - Например, если вы хотите собрать документацию для Kubernetes версии 1.17, определите переменную окружения `K8S_RELEASE` со значением 1.17. + Например, если вы хотите собрать документацию для Kubernetes версии 1.17.0, определите переменную окружения `K8S_RELEASE` со значением 1.17.0. Примеры: ```shell -export WEB_ROOT=$(GOPATH)/src/github.com//website -export K8S_ROOT=$(GOPATH)/src/k8s.io/kubernetes -export K8S_RELEASE=1.17 +export K8S_WEBROOT=${GOPATH}/src/github.com//website +export K8S_ROOT=${GOPATH}/src/k8s.io/kubernetes +export K8S_RELEASE=1.17.0 ``` ### Создание версионированной директории и получение Open API spec @@ -113,8 +113,8 @@ make copyapi Убедитесь в том, что перечисленные ниже два файлы были сгенерированы: ```shell -[ -e "/gen-apidocs/generators/build/index.html" ] && echo "index.html built" || echo "no index.html" -[ -e "/gen-apidocs/generators/build/navData.js" ] && echo "navData.js built" || echo "no navData.js" +[ -e "/gen-apidocs/build/index.html" ] && echo "index.html built" || echo "no index.html" +[ -e "/gen-apidocs/build/navData.js" ] && echo "navData.js built" || echo "no navData.js" ``` Перейдите в корень директории `` и посмотрите, какие файлы были изменены: diff --git a/content/ru/docs/contribute/intermediate.md b/content/ru/docs/contribute/intermediate.md index ba3b06511f..303a0877e5 100644 --- a/content/ru/docs/contribute/intermediate.md +++ b/content/ru/docs/contribute/intermediate.md @@ -217,8 +217,8 @@ PR объединяется, когда у него есть комментар ```bash origin git@github.com:/website.git (fetch) origin git@github.com:/website.git (push) - upstream https://github.com/kubernetes/website (fetch) - upstream https://github.com/kubernetes/website (push) + upstream https://github.com/kubernetes/website.git (fetch) + upstream https://github.com/kubernetes/website.git (push) ``` ### Работа в локальном репозитории diff --git a/content/ru/docs/reference/glossary/cloud-controller-manager.md b/content/ru/docs/reference/glossary/cloud-controller-manager.md new file mode 100644 index 0000000000..d8f0615778 --- /dev/null +++ b/content/ru/docs/reference/glossary/cloud-controller-manager.md @@ -0,0 +1,19 @@ +--- +title: Диспетчер облачных контроллеров +id: cloud-controller-manager +date: 2018-04-12 +full_link: /docs/concepts/architecture/cloud-controller/ +short_description: > + Компонент плоскости управления, который интегрирует Kubernetes со сторонними облачными провайдерами. +aka: +tags: +- core-object +- architecture +- operation +--- +Компонент {{< glossary_tooltip text="панель управления" term_id="control-plane" >}} Kubernetes - это встраиваемый в логику управления облочная спецификация. Диспетчер облачных контроллеров позволяет связать кластер с API поставщика облачных услуг и отделить компоненты, взаимодействующие с этой облачной платформой, от компонентов, взаимодействующих только с вашим кластером. + + + +Отделяя логику взаимодействия между Kubernetes и базовой облачной инфраструктурой, компонент cloud-controller-manager позволяет поставщикам облачных услуг выпускать функции в другом темпе по сравнению с основным проектом Kubernetes. + diff --git a/content/ru/docs/reference/glossary/container-runtime.md b/content/ru/docs/reference/glossary/container-runtime.md index cea63dfa94..25916582e5 100644 --- a/content/ru/docs/reference/glossary/container-runtime.md +++ b/content/ru/docs/reference/glossary/container-runtime.md @@ -2,7 +2,7 @@ title: Среда выполнения контейнера id: container-runtime date: 2019-06-05 -full_link: /docs/reference/generated/container-runtime +full_link: /docs/setup/production-environment/container-runtimes short_description: > Среда выполнения контейнера — это программа, предназначенная для выполнения контейнеров. diff --git a/content/ru/docs/reference/glossary/garbage-collection.md b/content/ru/docs/reference/glossary/garbage-collection.md new file mode 100644 index 0000000000..defcd10476 --- /dev/null +++ b/content/ru/docs/reference/glossary/garbage-collection.md @@ -0,0 +1,23 @@ +--- +title: Сборшик мусора +id: garbage-collection +date: 2021-07-07 +full_link: /docs/concepts/workloads/controllers/garbage-collection/ +short_description: > + A collective term for the various mechanisms Kubernetes uses to clean up cluster + resources. + +aka: +tags: +- fundamental +- operation +--- + Сборщик мусора - это собирательный термин для различных механизмов? используемых Kubernetes для очистки ресурсов кластера. + + + +Kubernetes использует сборку мусора для очистки таких ресурсов, как [неиспользуемые контейнеры и образы](/docs/concepts/workloads/controllers/garbage-collection/#containers-images), +[неудачные Pod-ы](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection), +[объекты, принадлежащие целевому ресурсу](/docs/concepts/overview/working-with-objects/owners-dependents/), +[завершенные задачи](/docs/concepts/workloads/controllers/ttlafterfinished/), and resources +that have expired or failed. \ No newline at end of file diff --git a/content/ru/docs/reference/kubectl/docker-cli-to-kubectl.md b/content/ru/docs/reference/kubectl/docker-cli-to-kubectl.md index 99a9e20d8c..4d834098c6 100644 --- a/content/ru/docs/reference/kubectl/docker-cli-to-kubectl.md +++ b/content/ru/docs/reference/kubectl/docker-cli-to-kubectl.md @@ -34,12 +34,20 @@ kubectl: ```shell # запустить под, в котором работает nginx -kubectl run --image=nginx nginx-app --port=80 --env="DOMAIN=cluster" +kubectl create deployment --image=nginx nginx-app ``` ``` deployment "nginx-app" created ``` +```shell +# add env to nginx-app +kubectl set env deployment/nginx-app DOMAIN=cluster +``` +``` +deployment.apps/nginx-app env updated +``` + {{< note >}} Команды `kubectl` выводят тип и имя созданного или измененного ресурса, который затем может быть использован в последующих командах. После создания объекта Deployment можно открыть новый сервис Service. {{< /note >}} @@ -260,7 +268,7 @@ nginx-app 1/1 1 1 2m ``` ```shell -kubectl get po -l run=nginx-app +kubectl get po -l app=nginx-app ``` ``` NAME READY STATUS RESTARTS AGE @@ -274,7 +282,7 @@ deployment "nginx-app" deleted ``` ```shell -kubectl get po -l run=nginx-app +kubectl get po -l app=nginx-app # Return nothing ``` diff --git a/content/ru/docs/setup/_index.md b/content/ru/docs/setup/_index.md index 17b6efd198..69428da89c 100644 --- a/content/ru/docs/setup/_index.md +++ b/content/ru/docs/setup/_index.md @@ -29,7 +29,7 @@ content_type: concept * Пробуете или начинаете работу с Kubernetes * Локально разрабатываете и тестируете кластер -Выбрать [решение для запуска на локальной машине](/docs/setup/pick-right-solution/#local-machine-solutions). +Выбрать [решение для запуска на локальной машине](/docs/setup/learning-environment/). ## Управляемые решения diff --git a/content/uk/_index.html b/content/uk/_index.html index ae7873ea7a..ebf3f6ea18 100644 --- a/content/uk/_index.html +++ b/content/uk/_index.html @@ -62,12 +62,12 @@ Kubernetes - проект з відкритим вихідним кодом. В

    - Відвідайте KubeCon NA онлайн, 17-20 листопада 2020 року + Відвідайте KubeCon у Північній Америці, 11-15 жовтня 2021 року



    - Відвідайте KubeCon EU онлайн, 17-20 травня 2021 року + Відвідайте KubeCon в Європі, 17-20 травня 2022 року
    diff --git a/content/uk/docs/reference/glossary/service.md b/content/uk/docs/reference/glossary/service.md old mode 100755 new mode 100644 diff --git a/content/uk/docs/setup/release/_index.md b/content/uk/docs/setup/release/_index.md old mode 100755 new mode 100644 diff --git a/content/uk/docs/tutorials/_index.md b/content/uk/docs/tutorials/_index.md index 09c8b1e7a8..c87a5155a0 100644 --- a/content/uk/docs/tutorials/_index.md +++ b/content/uk/docs/tutorials/_index.md @@ -29,9 +29,9 @@ Before walking through each tutorial, you may want to bookmark the --> * [Основи Kubernetes](/docs/tutorials/kubernetes-basics/) - детальний навчальний матеріал з інтерактивними уроками, що допоможе вам зрозуміти Kubernetes і спробувати його базову функціональність. -* [Scalable Microservices with Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) +* [Масштабовані мікросервіси з Kubernetes (Udacity)](https://www.udacity.com/course/scalable-microservices-with-kubernetes--ud615) -* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) +* [Вступ до Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#) * [Привіт Minikube](/docs/tutorials/hello-minikube/) @@ -39,23 +39,25 @@ Before walking through each tutorial, you may want to bookmark the --> ## Конфігурація -* [Configuring Redis Using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/) +* [Приклад: Конфігурування Java мікросервісу](/docs/tutorials/configuration/configure-java-microservice/) + +* [Конфігурування Redis використовуючи ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/) ## Застосунки без стану (Stateless Applications) {#застосунки-без-стану} -* [Exposing an External IP Address to Access an Application in a Cluster](/docs/tutorials/stateless-application/expose-external-ip-address/) +* [Відкриття зовнішньої IP-адреси для доступу до програми в кластері](/docs/tutorials/stateless-application/expose-external-ip-address/) -* [Example: Deploying PHP Guestbook application with Redis](/docs/tutorials/stateless-application/guestbook/) +* [Приклад: Розгортання застосунку PHP Guestbook з Redis](/docs/tutorials/stateless-application/guestbook/) ## Застосунки зі станом (Stateful Applications) {#застосунки-зі-станом} -* [StatefulSet Basics](/docs/tutorials/stateful-application/basic-stateful-set/) +* [Основи StatefulSet](/docs/tutorials/stateful-application/basic-stateful-set/) -* [Example: WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) +* [Приклад: WordPress та MySQL із постійними томами](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) -* [Example: Deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/) +* [Приклад: Розгортання Cassandra зі Stateful Sets](/docs/tutorials/stateful-application/cassandra/) -* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/) +* [Запуск ZooKeeper, координатора розподіленої системи](/docs/tutorials/stateful-application/zookeeper/) ## Кластери @@ -63,7 +65,7 @@ Before walking through each tutorial, you may want to bookmark the ## Сервіси -* [Using Source IP](/docs/tutorials/services/source-ip/) +* [Використання Source IP](/docs/tutorials/services/source-ip/) diff --git a/content/vi/docs/reference/glossary/api-group.md b/content/vi/docs/reference/glossary/api-group.md index ce2cfd4532..66c215e0a6 100644 --- a/content/vi/docs/reference/glossary/api-group.md +++ b/content/vi/docs/reference/glossary/api-group.md @@ -2,7 +2,7 @@ title: API Group id: api-group date: 2019-12-16 -full_link: /docs/concepts/overview/kubernetes-api/#api-groups +full_link: /docs/concepts/overview/kubernetes-api/#api-groups-and-versioning short_description: > Một tập những đường dẫn tương đối đến Kubernetes API. @@ -18,4 +18,4 @@ Một tập những đường dẫn tương đối đến Kubernetes API. Bạn có thể cho phép hay vô hiệu từng API group bằng cách thay đổi cấu hình trên API server của mình. Đồng thời bạn cũng có thể vô hiệu hay kích hoạt các đường dẫn cho những tài nguyên cụ thể. API group đơn giản hóa việc mở rộng Kubernetes API. Nó được chỉ định dưới dạng REST và trong trường `apiVersion` của một đối tượng đã được chuyển hóa. -- Đọc thêm về [API Group](/docs/concepts/overview/kubernetes-api/#api-groups). \ No newline at end of file +- Đọc thêm về [API Group](/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning). \ No newline at end of file diff --git a/content/vi/docs/reference/kubectl/cheatsheet.md b/content/vi/docs/reference/kubectl/cheatsheet.md index 38e51750e6..079b36a42b 100644 --- a/content/vi/docs/reference/kubectl/cheatsheet.md +++ b/content/vi/docs/reference/kubectl/cheatsheet.md @@ -1,381 +1,381 @@ ---- -title: kubectl Cheat Sheet -reviewers: -- ngtuna -content_type: concept -card: - name: reference - weight: 30 ---- - - - -Xem thêm: [Kubectl Overview](/docs/reference/kubectl/overview/) và [JsonPath Guide](/docs/reference/kubectl/jsonpath). - -Trang này là trang tổng quan của lệnh `kubectl`. - - - - - -# kubectl - Cheat Sheet - -## Kubectl Autocomplete - -### BASH - -```bash -source <(kubectl completion bash) # thiết lập autocomplete trong bash vào shell hiện tại, gói bash-completion nên được cài đặt trước tiên -echo "source <(kubectl completion bash)" >> ~/.bashrc # thêm vĩnh viễn autocomplete vào trong bash shell -``` - -Bạn có thể dùng một alias cho `kubectl` cũng hoạt động với completion: - -```bash -alias k=kubectl -complete -F __start_kubectl k -``` - -### ZSH - -```bash -source <(kubectl completion zsh) # thiết lập autocomplete trong zsh vào shell hiện tại -echo "if [ $commands[kubectl] ]; then source <(kubectl completion zsh); fi" >> ~/.zshrc # thêm vĩnh viễn autocomplete vào trong zsh shell -``` - -## Ngữ cảnh và cấu hình kubectl - -Thiết lập cụm Kubernetes nào mà `kubectl` sẽ giao tiếp với và sửa đổi thông tin cấu hình. -Xem tài liệu [Xác thực giữa các cụm với kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) -để biết thông tin chi tiết của tệp cấu hình. - -```bash -kubectl config view # Hiển thị các thiết lập kubeconfig đã được merged - -# sử dụng nhiều tệp kubeconfig cùng một lúc và xem cấu hình hợp nhất -KUBECONFIG=~/.kube/config:~/.kube/kubconfig2 - -kubectl config view - -# lấy mật khẩu cho người dùng e2e -kubectl config view -o jsonpath='{.users[?(@.name == "e2e")].user.password}' - -kubectl config view -o jsonpath='{.users[].name}' # hiển thị người dùng đầu tiên -kubectl config view -o jsonpath='{.users[*].name}' # lấy danh sách người dùng -kubectl config get-contexts # hiển thị danh sách các ngữ cảnh -kubectl config current-context # hiển thị ngữ cảnh hiện tại -kubectl config use-context my-cluster-name # thiết lập ngữ cảnh mặc định cho my-cluster-name - -# thêm một cụm mới vào kubeconf hỗ trợ xác thực cơ bản -kubectl config set-credentials kubeuser/foo.kubernetes.com --username=kubeuser --password=kubepassword - -# lưu vĩnh viễn namespace cho tất cả các lệnh kubectl tiếp theo trong ngữ cảnh đó -kubectl config set-context --current --namespace=ggckad-s2 - -# thiết lập ngữ cảnh sử dụng tên người dùng và namespace cụ thể -kubectl config set-context gce --user=cluster-admin --namespace=foo \ - && kubectl config use-context gce - -kubectl config unset users.foo # xóa người dùng foo -``` - -## Apply -`apply` quản lý các ứng dụng thông qua các tệp định nghĩa tài nguyên Kubernetes. Nó tạo và cập nhật các tài nguyên trong một cụm thông qua việc chạy `kubectl apply`. Đây là cách được đề xuất để quản lý các ứng dụng Kubernetes trong thực tế. Xem thêm [Kubectl Book](https://kubectl.docs.kubernetes.io). - -## Tạo một đối tượng - -Kubernetes manifests có thể được định nghĩa trong tệp json hoặc yaml. Phần mở rộng `.yaml`, -`.yml`, và `.json` có thể được dùng. - -```bash -kubectl apply -f ./my-manifest.yaml # tạo tài nguyên -kubectl apply -f ./my1.yaml -f ./my2.yaml # tạo từ nhiều tệp -kubectl apply -f ./dir # tạo tài nguyên từ tất cả các tệp manifest trong thư mục dir -kubectl apply -f https://git.io/vPieo # tạo tài nguyên từ url -kubectl create deployment nginx --image=nginx # tạo một deployment nginx -kubectl explain pods,svc # lấy thông tin pod và service manifest - -# Tạo nhiều đối tượng YAML từ stdin -cat < pod.yaml - -kubectl attach my-pod -i # Đính kèm với container đang chạy -kubectl port-forward my-pod 5000:6000 # Lắng nghe trên cổng 5000 của máy local và chuyển tiếp sang cổng 6000 trên pod my-pod -kubectl exec my-pod -- ls / # Chạy lệnh trong một pod (trường hợp 1 container) -kubectl exec my-pod -c my-container -- ls / # Chạy lệnh trong pod (trường hợp nhiều container) -kubectl top pod POD_NAME --containers # Hiển thị số liệu của pod và container chạy trong nó -``` - -## Tương tác với các nodes và cụm - -```bash -kubectl cordon my-node # Đánh dấu my-node là không thể lập lịch -kubectl drain my-node # Gỡ my-node ra khỏi cụm để chuẩn bị cho việc bảo trì -kubectl uncordon my-node # Đánh dấu my-node có thể lập lịch trở lại -kubectl top node my-node # Hiển thị số liệu của node -kubectl cluster-info # Hiển thị địa chỉ master và các services -kubectl cluster-info dump # Kết xuất trạng thái hiện tại của cụm ra ngoài stdout -kubectl cluster-info dump --output-directory=/path/to/cluster-state # Kết xuất trạng thái hiện tại của cụm vào /path/to/cluster-state - -kubectl taint nodes foo dedicated=special-user:NoSchedule -``` - -### Các loại tài nguyên - -Liệt kê tất cả các loại tài nguyên được hỗ trợ cùng với tên viết tắt của chúng, [API group](/docs/concepts/overview/kubernetes-api/#api-groups), cho dù chúng là [namespaced](/docs/concepts/overview/working-with-objects/namespaces), và [Kind](/docs/concepts/overview/working-with-objects/kubernetes-objects): - -```bash -kubectl api-resources -``` - -Các hoạt động khác để khám phá các tài nguyên API: - -```bash -kubectl api-resources --namespaced=true # Tất cả các tài nguyên được đặt tên -kubectl api-resources --namespaced=false # Tất cả các tài nguyên không được đặt tên -kubectl api-resources -o name # Tất cả các tài nguyên với đầu ra đơn giản (chỉ gồm tên tài nguyên) -kubectl api-resources -o wide # Tất cả các tài nguyên với đầu ra mở rộng -kubectl api-resources --verbs=list,get # Tất cả các tài nguyên hỗ trợ yêu cầu "list" và "get" -kubectl api-resources --api-group=extensions # Tất cả tài nguyên trong nhóm API "tiện ích mở rộng" -``` - -### Định dạng đầu ra - -Để xuất thông tin chi tiết ra cửa sổ terminal của bạn theo một định dạng cụ thể, bạn có thể thêm các cờ `-o` hoặc `--output` vào lệnh `kubectl` được hỗ trợ. - -Định dạng đầu ra | Mô tả ---------------| ----------- -`-o=custom-columns=` | In một bảng bằng danh sách, các cột tùy chỉnh được phân tách bằng dấu phẩy -`-o=custom-columns-file=` | In một bảng bằng cách sử dụng mẫu cột tùy chỉnh trong tệp `` -`-o=json` | Xuất ra một đối tượng API theo định dạng JSON -`-o=jsonpath=